Add period for consistency #79
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In a list of items, the other items end in a period. Adding a period to make the list items consistent.
Puneeth-n
pushed a commit
to Puneeth-n/linux
that referenced
this pull request
Mar 18, 2014
Turn it into (for example): [ 0.073380] x86: Booting SMP configuration: [ 0.074005] .... node #0, CPUs: alexander-zimmermann#1 #2 #3 #4 #5 torvalds#6 torvalds#7 [ 0.603005] .... node alexander-zimmermann#1, CPUs: torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 [ 1.200005] .... node #2, CPUs: torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 [ 1.796005] .... node #3, CPUs: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 [ 2.393005] .... node #4, CPUs: torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 [ 2.996005] .... node #5, CPUs: torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 [ 3.600005] .... node torvalds#6, CPUs: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 [ 4.202005] .... node torvalds#7, CPUs: torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 [ 4.811005] .... node torvalds#8, CPUs: torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71 [ 5.421006] .... node torvalds#9, CPUs: torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 [ 6.032005] .... node torvalds#10, CPUs: torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 [ 6.648006] .... node torvalds#11, CPUs: torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95 [ 7.262005] .... node torvalds#12, CPUs: torvalds#96 torvalds#97 torvalds#98 torvalds#99 torvalds#100 torvalds#101 torvalds#102 torvalds#103 [ 7.865005] .... node torvalds#13, CPUs: torvalds#104 torvalds#105 torvalds#106 torvalds#107 torvalds#108 torvalds#109 torvalds#110 torvalds#111 [ 8.466005] .... node torvalds#14, CPUs: torvalds#112 torvalds#113 torvalds#114 torvalds#115 torvalds#116 torvalds#117 torvalds#118 torvalds#119 [ 9.073006] .... node torvalds#15, CPUs: torvalds#120 torvalds#121 torvalds#122 torvalds#123 torvalds#124 torvalds#125 torvalds#126 torvalds#127 [ 9.679901] x86: Booted up 16 nodes, 128 CPUs and drop useless elements. Change num_digits() to hpa's division-avoiding, cell-phone-typed version which he went at great lengths and pains to submit on a Saturday evening. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: huawei.libin@huawei.com Cc: wangyijing@huawei.com Cc: fenghua.yu@intel.com Cc: guohanjun@huawei.com Cc: paul.gortmaker@windriver.com Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20130930095624.GB16383@pd.tnic Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
Wonderful, but Linus doesn't accept PR's on github. |
|
Please stfu Elizabeth myers
|
|
Second that. Stfu Elizabeth. Back in the kitchen Sent from my iPhone
|
|
Yes please, you are spamming our inboxes with this garbage. On Thu, Jan 8, 2015 at 9:14 AM, Steve McMullin notifications@github.com
|
krzk
pushed a commit
to krzk/linux
that referenced
this pull request
May 2, 2015
ERROR: code indent should use tabs where possible torvalds#76: FILE: mm/cma_debug.c:88: + int pages = val;$ WARNING: please, no spaces at the start of a line torvalds#76: FILE: mm/cma_debug.c:88: + int pages = val;$ ERROR: code indent should use tabs where possible torvalds#79: FILE: mm/cma_debug.c:91: + return cma_free_mem(cma, pages);$ WARNING: please, no spaces at the start of a line torvalds#79: FILE: mm/cma_debug.c:91: + return cma_free_mem(cma, pages);$ total: 2 errors, 2 warnings, 69 lines checked NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or scripts/cleanfile ./patches/mm-cma-release-trigger.patch has style problems, please review. If any of these errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
tiwai
pushed a commit
to tiwai/sound
that referenced
this pull request
May 5, 2015
Commit a41d122 ("ALSA: hda - Embed bus into controller object") introduced a regression in the Tegra HDA driver that causes the following oops during boot: [ 2.333458] Unable to handle kernel NULL pointer dereference at virtual address 000004c4 [ 2.341537] pgd = c0004000 [ 2.344312] [000004c4] *pgd=00000000 [ 2.347898] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 2.353200] Modules linked in: [ 2.356264] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 4.1.0-rc2-next-20150505-00344-g8577890defbf torvalds#79 [ 2.366682] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree) [ 2.372939] task: ee0d8b40 ti: ee0da000 task.ti: ee0da000 [ 2.378336] PC is at azx_bus_init+0x18/0xf4 [ 2.382516] LR is at hda_tegra_probe+0x6c/0x478 [ 2.387043] pc : [<c06156c4>] lr : [<c061cf00>] psr: 60000113 [ 2.387043] sp : ee0dbe38 ip : 00000000 fp : 00000000 [ 2.398501] r10: ed874c00 r9 : 000000fd r8 : 00000000 [ 2.403717] r7 : ed874c10 r6 : 00000000 r5 : 00000000 r4 : ed016810 [ 2.410232] r3 : c08a2ad4 r2 : c08a1ea0 r1 : 00000000 r0 : ed016810 [ 2.416750] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 2.424046] Control: 10c5387d Table: 8000406a DAC: 00000015 [ 2.429783] Process swapper/0 (pid: 1, stack limit = 0xee0da210) [ 2.435778] Stack: (0xee0dbe38 to 0xee0dc000) [ 2.440129] be20: 00000000 ed016810 [ 2.448297] be40: 00000000 c061cf00 00000000 ee0dbe5c ed8735d0 c0a7bc48 ed02fd50 ed016000 [ 2.456462] be60: c1250164 ed874c10 c0c66bf8 fffffdfb 00000000 000000fd c0b8dc98 c046664c [ 2.464628] be80: c0466608 c1250164 ed874c10 00000000 c0c66bf8 c0464eb4 ed874c10 c0c66bf8 [ 2.472793] bea0: ed874c44 c0c43458 00000000 c04650d0 00000000 c0c66bf8 c046503c c04633b4 [ 2.480959] bec0: ee11bea4 ed85f390 c0c66bf8 ed017ac0 00000000 c0464634 c0ab2b7c c0c66bf8 [ 2.489125] bee0: c0bfde20 c0c66bf8 c0bfde20 ed01ce40 c0b7b414 c04656e8 c04665b0 c0bfde20 [ 2.497291] bf00: c0bfde20 c0009770 ee0d8b40 c0c02488 60000113 00000000 00000000 00000003 [ 2.505458] bf20: 00000000 c0c02488 60000113 00000000 c0b54598 c0b16a90 ef7fcc57 c0041228 [ 2.513624] bf40: c0a9150c ef7fcc5f 00000006 00000006 00000000 c0bf1fa8 c0bf2354 00000006 [ 2.521790] bf60: c0b8dc90 c0c7c000 c0c7c000 c0b8dc98 00000000 c0b54dd8 00000006 00000006 [ 2.529956] bf80: c0b54598 00000000 00000000 c07ff08c 00000000 00000000 00000000 00000000 [ 2.538122] bfa0: 00000000 c07ff094 00000000 c000f5a0 00000000 00000000 00000000 00000000 [ 2.546286] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 2.554451] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 fffff7ff c013f264 [ 2.562624] [<c06156c4>] (azx_bus_init) from [<c061cf00>] (hda_tegra_probe+0x6c/0x478) [ 2.570535] [<c061cf00>] (hda_tegra_probe) from [<c046664c>] (platform_drv_probe+0x44/0xa4) [ 2.578879] [<c046664c>] (platform_drv_probe) from [<c0464eb4>] (driver_probe_device+0x174/0x2b8) [ 2.587739] [<c0464eb4>] (driver_probe_device) from [<c04650d0>] (__driver_attach+0x94/0x98) [ 2.596172] [<c04650d0>] (__driver_attach) from [<c04633b4>] (bus_for_each_dev+0x6c/0xa0) [ 2.604342] [<c04633b4>] (bus_for_each_dev) from [<c0464634>] (bus_add_driver+0x148/0x1f0) [ 2.612597] [<c0464634>] (bus_add_driver) from [<c04656e8>] (driver_register+0x78/0xf8) [ 2.620593] [<c04656e8>] (driver_register) from [<c0009770>] (do_one_initcall+0x8c/0x1d4) [ 2.628765] [<c0009770>] (do_one_initcall) from [<c0b54dd8>] (kernel_init_freeable+0x144/0x1e4) [ 2.637459] [<c0b54dd8>] (kernel_init_freeable) from [<c07ff094>] (kernel_init+0x8/0xe8) [ 2.645543] [<c07ff094>] (kernel_init) from [<c000f5a0>] (ret_from_fork+0x14/0x34) This is caused by azx_bus_init() trying to dereference chip->card, which for the Tegra driver doesn't get initialized until sometime later during the call to hda_tegra_create(). Fix this by mimicking the behaviour of the Intel driver and defer HDA bus initialization until right before the call to snd_device_new(). Fixes: a41d122 ('ALSA: hda - Embed bus into controller object') Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
hzhuang1
pushed a commit
to hzhuang1/linux
that referenced
this pull request
Jun 2, 2015
…id-v2 Bluetooth: tty_hci: add LED support
ddstreet
referenced
this pull request
in ddstreet/linux
Jun 4, 2015
GIT c00d5a6ebd165ac9708dd76514ce7cd437714ec4
commit e3d8ecb70e16412b14fb11c1b68ecb533bd4ea64
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Mon May 11 15:57:31 2015 +0200
netns: return RTM_NEWNSID instead of RTM_GETNSID on a get
Usually, RTM_NEWxxx is returned on a get (same as a dump).
Fixes: 0c7aecd4bde4 ("netns: add rtnl cmd to add and get peer netns ids")
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit ff284f37fc0e6f3b51ede85c5944d571b640ac0f
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Wed May 13 00:44:14 2015 +0200
Revert "ACPICA: Permanently set _REV to the value '2'."
Revert commit b1ef29725865 (ACPICA: Permanently set _REV to the value
'2'.) as it causes a sound regression to happen on Dell XPS 13 (2015).
Reported-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
commit 4ceec22d6d89360ff7ebbf53dd3ab4e29e3d8a09
Author: Scott Feldman <sfeldma@gmail.com>
Date: Sun May 10 09:48:09 2015 -0700
switchdev: bring documentation up-to-date
Much need updated of switchdev documentation to cover what's been
implmented to-date. There are some XXX comments in the text for
unimplemented or broken items. I'd like to keep these in there (poor-man's
TODO list) and update the document once each issue is resolved.
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 4725ceb9b70115b210a01d73318ce4430e4f0125
Author: Scott Feldman <sfeldma@gmail.com>
Date: Sun May 10 09:48:08 2015 -0700
rocker: make checkpatch -f clean
Well almost clean: ignore the CHECKs for space after cast operator and some
longer-than-80 char cases where for readability it's better to keep as-is.
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 7889cbee8357aaed85898d028829dfb4f75bae2c
Author: Scott Feldman <sfeldma@gmail.com>
Date: Sun May 10 09:48:07 2015 -0700
switchdev: remove NETIF_F_HW_SWITCH_OFFLOAD feature flag
Roopa said remove the feature flag for this series and she'll work on
bringing it back if needed at a later date.
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 58c2cb16b116d7feace621bd6b647bbabacfa225
Author: Scott Feldman <sfeldma@gmail.com>
Date: Sun May 10 09:48:06 2015 -0700
switchdev: convert fib_ipv4_add/del over to switchdev_port_obj_add/del
The IPv4 FIB ops convert nicely to the switchdev objs and we're left with
only four switchdev ops: port get/set and port add/del. Other objs will
follow, such as FDB. So go ahead and convert IPv4 FIB over to switchdev
obj for consistency, anticipating more objs to come.
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 85fdb956726ff2af609e2f6ea7be781e4db74a07
Author: Scott Feldman <sfeldma@gmail.com>
Date: Sun May 10 09:48:05 2015 -0700
switchdev: cut over to new switchdev_port_bridge_getlink
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 8793d0a664a8a2c5e18e929c1f995c784c105705
Author: Scott Feldman <sfeldma@gmail.com>
Date: Sun May 10 09:48:04 2015 -0700
switchdev: add new switchdev_port_bridge_getlink
Like bridge_setlink, add switchdev wrapper to handle bridge_getlink and
call into port driver to get port attrs. For now, only BR_LEARNING and
BR_LEARNING_SYNC are returned. To add more, we'll probably want to break
away from ndo_dflt_bridge_getlink() and build the netlink skb directly in
the switchdev code.
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 8508025c598bdee33d9afa153e9c00c7771e7d63
Author: Scott Feldman <sfeldma@gmail.com>
Date: Sun May 10 09:48:03 2015 -0700
bridge: revert br_dellink change back to original
This is revert of:
commit 68e331c785b8 ("bridge: offload bridge port attributes to switch asic
if feature flag set")
Restore br_dellink back to original and don't call into SELF port driver.
rtnetlink.c:bridge_dellink() already does a call into port driver for SELF.
bridge vlan add/del cmd defaults to MASTER. From man page for bridge vlan
add/del cmd:
self the vlan is configured on the specified physical device.
Required if the device is the bridge device.
master the vlan is configured on the software bridge (default).
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 87a5dae59e7abaad911ab719caa5548dd6df5557
Author: Scott Feldman <sfeldma@gmail.com>
Date: Sun May 10 09:48:02 2015 -0700
switchdev: remove unused switchdev_port_bridge_dellink
Now we can remove old wrappers for dellink.
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 54ba5a0bbc739ae77a217d7340149e6f35934c4b
Author: Scott Feldman <sfeldma@gmail.com>
Date: Sun May 10 09:48:01 2015 -0700
switchdev: cut over to new switchdev_port_bridge_dellink
Rocker, bonding and team and switch over to the new
switchdev_port_bridge_dellink to avoid duplicating code in each driver.
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 5c34e0221423aeabc0b085adc5fccda3f91e2c49
Author: Scott Feldman <sfeldma@gmail.com>
Date: Sun May 10 09:48:00 2015 -0700
switchdev: add new switchdev_port_bridge_dellink
Same change as setlink. Provide the wrapper op for SELF ndo_bridge_dellink
and call into the switchdev driver to delete afspec VLANs.
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 41c498b9359e360f08723b7605ec0c40926ec415
Author: Scott Feldman <sfeldma@gmail.com>
Date: Sun May 10 09:47:59 2015 -0700
bridge: restore br_setlink back to original
This is revert of:
commit 68e331c785b8 ("bridge: offload bridge port attributes to switch asic
if feature flag set")
Restore br_setlink back to original and don't call into SELF port driver.
rtnetlink.c:bridge_setlink() already does a call into port driver for SELF.
bridge set link cmd defaults to MASTER. From man page for bridge link set
cmd:
self link setting is configured on specified physical device
master link setting is configured on the software bridge (default)
The link setting has two values: the device-side value and the software
bridge-side value. These are independent and settable using the bridge
link set cmd by specifying some combination of [master] | [self].
Furthermore, the device-side and bridge-side settings have their own
initial value, viewable from bridge -d link show cmd.
Restoring br_setlink back to original makes rocker (the only in-kernel user
of SELF link settings) work as first implement: two-sided values.
It's true that when both MASTER and SELF are specified from the command,
two netlink notifications are generated, one for each side of the settings.
The user-space app can distiquish between the two notifications by
observing the MASTER or SELF flag.
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit e71f220b342d78cfb8ee9f1b60f1351f7183f2a5
Author: Scott Feldman <sfeldma@gmail.com>
Date: Sun May 10 09:47:58 2015 -0700
switchdev: remove old switchdev_port_bridge_setlink
New attr-based bridge_setlink can recurse lower devs and recover on err, so
remove old wrapper (including ndo_dflt_switchdev_port_bridge_setlink).
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit fc8f40d8644f15f0fd5fbc49012802a00f36ad55
Author: Scott Feldman <sfeldma@gmail.com>
Date: Sun May 10 09:47:57 2015 -0700
switchdev: cut over to new switchdev_port_bridge_setlink
Rocker, bonding, and team can now use the switchdev bridge setlink to parse
raw netlink; no need to duplicate this code in each driver.
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 47f8328bb1a4115413e35b9b20d04b061ed544f8
Author: Scott Feldman <sfeldma@gmail.com>
Date: Sun May 10 09:47:56 2015 -0700
switchdev: add new switchdev bridge setlink
Add new switchdev_port_bridge_setlink that can be used by drivers
implementing .ndo_bridge_setlink to set switchdev bridge attributes.
Basically turn the raw rtnl_bridge_setlink netlink into switchdev attr
sets. Proper netlink attr policy checking is done on the protinfo part of
the netlink msg.
Currently, for protinfo, only bridge port attrs BR_LEARNING and
BR_LEARNING_SYNC are parsed and passed to port driver.
For afspec, VLAN objs are passed so switchdev driver can set VLANs assigned
to SELF. To illustrate with iproute2 cmd, we have:
bridge vlan add vid 10 dev sw1p1 self master
To add VLAN 10 to port sw1p1 for both the bridge (master) and the device
(self).
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 6004c86718998aee1337efd3b087d6e17284632d
Author: Scott Feldman <sfeldma@gmail.com>
Date: Sun May 10 09:47:55 2015 -0700
switchdev: add bridge port flags attr
rocker: use switchdev get/set attr for bridge port flags
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 9228ad26abeec99caf139e6d641e0199c95fd677
Author: Scott Feldman <sfeldma@gmail.com>
Date: Sun May 10 09:47:54 2015 -0700
rocker: use switchdev add/del obj for bridge port vlans
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 6fc3016da7c1587aa59e71f8c4dbc4cf1343eab2
Author: Scott Feldman <sfeldma@gmail.com>
Date: Sun May 10 09:47:53 2015 -0700
switchdev: add port vlan obj
VLAN obj has flags (PVID and untagged) as well as start and end vid ranges.
The switchdev driver can optimize programing the device using the ranges.
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 491d0f1533ac750260406dbf84cdad44fd3d8a29
Author: Scott Feldman <sfeldma@gmail.com>
Date: Sun May 10 09:47:52 2015 -0700
switchdev: introduce switchdev add/del obj ops
Like switchdev attr get/set, add new switchdev obj add/del. switchdev objs
will be things like VLANs or FIB entries, so add/del fits better for
objects than get/set used for attributes.
Use same two-phase prepare-commit transaction model as in attr set.
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 3563606258cf3b8f02eabddb1cb45a94c44d9611
Author: Scott Feldman <sfeldma@gmail.com>
Date: Sun May 10 09:47:51 2015 -0700
switchdev: convert STP update to switchdev attr set
STP update is just a settable port attribute, so convert
switchdev_port_stp_update to an attr set.
For DSA, the prepare phase is skipped and STP updates are only done in the
commit phase. This is because currently the DSA drivers don't need to
allocate any memory for STP updates and the STP update will not fail to HW
(unless something horrible goes wrong on the MDIO bus, in which case the
prepare phase wouldn't have been able to predict anyway).
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit c4f20321d9680760a291991d77bc5b6d0eb2ed78
Author: Scott Feldman <sfeldma@gmail.com>
Date: Sun May 10 09:47:50 2015 -0700
rocker: support prepare-commit transaction model
For rocker, support prepare-commit transaction model for setting attributes
(and for adding objects). This requires rocker to preallocate memory
needed for the commit up front in the prepare phase. Since rtnl_lock is
held between prepare-commit, store the allocated memory on a queue hanging
off of the rocker_port. Also, in prepare phase, do everything right up to
calling into HW. The same code paths are tranversed in the driver for both
prepare and commit phases. In some cases, any state modified in the
prepare phase must be reverted before returning so the commit phase makes
the same decisions.
As a consequence of holding rtnl_lock in process context for all attr sets
(and obj adds), all memory is GFP_KERNEL allocated and we don't need to
busy spin waiting for the device to complete the command. So the bulk of
this patch is simplifying the memory allocations to only use GFP_KERNEL and
to remove the nowait flag and busy spin loop.
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit f8e20a9f87d33865cc1d67f13da0db8d457fc3c9
Author: Scott Feldman <sfeldma@gmail.com>
Date: Sun May 10 09:47:49 2015 -0700
switchdev: convert parent_id_get to switchdev attr get
Switch ID is just a gettable port attribute. Convert switchdev op
switchdev_parent_id_get to a switchdev attr.
Note: for sysfs and netlink interfaces, SWITCHDEV_ATTR_PORT_PARENT_ID is
called with SWITCHDEV_F_NO_RECUSE to limit switch ID user-visiblity to only
port netdevs. So when a port is stacked under bond/bridge, the user can
only query switch id via the switch ports, but not via the upper devices
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 3094333d9089d43e8b8f0418676fa6ae06c27b51
Author: Scott Feldman <sfeldma@gmail.com>
Date: Sun May 10 09:47:48 2015 -0700
switchdev: introduce get/set attrs ops
Add two new swdev ops for get/set switch port attributes. Most swdev
interactions on a port are gets or sets on port attributes, so rather than
adding ops for each attribute, let's define clean get/set ops for all
attributes, and then we can have clear, consistent rules on how attributes
propagate on stacked devs.
Add the basic algorithms for get/set attr ops. Use the same recusive algo
to walk lower devs we've used for STP updates, for example. For get,
compare attr value for each lower dev and only return success if attr
values match across all lower devs. For sets, set the same attr value for
all lower devs. We'll use a two-phase prepare-commit transaction model for
sets. In the first phase, the driver(s) are asked if attr set is OK. If
all OK, the commit attr set in second phase. A driver would NACK the
prepare phase if it can't set the attr due to lack of resources or support,
within it's control. RTNL lock must be held across both phases because
we'll recurse all lower devs first in prepare phase, and then recurse all
lower devs again in commit phase. If any lower dev fails the prepare
phase, we need to abort the transaction for all lower devs.
If lower dev recusion isn't desired, allow a flag SWITCHDEV_F_NO_RECURSE to
indicate get/set only work on port (lowest) device.
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 9d47c0a2d958e06322c88245749278633d333cca
Author: Jiri Pirko <jiri@resnulli.us>
Date: Sun May 10 09:47:47 2015 -0700
switchdev: s/swdev_/switchdev_/
Turned out that "switchdev" sticks. So just unify all related terms to use
this prefix.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Acked-by: Andy Gospodarek <gospo@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit ebb9a03a590e2325f747be43c8db450e92509501
Author: Jiri Pirko <jiri@resnulli.us>
Date: Sun May 10 09:47:46 2015 -0700
switchdev: s/netdev_switch_/switchdev_/ and s/NETDEV_SWITCH_/SWITCHDEV_/
Turned out that "switchdev" sticks. So just unify all related terms to use
this prefix.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Acked-by: Andy Gospodarek <gospo@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit a3eb95f891d6130b1fc03dd07a8b54cf0a5c8ab8
Author: David Ward <david.ward@ll.mit.edu>
Date: Sat May 9 22:01:46 2015 -0400
net_sched: gred: add TCA_GRED_LIMIT attribute
In a GRED qdisc, if the default "virtual queue" (VQ) does not have drop
parameters configured, then packets for the default VQ are not subjected
to RED and are only dropped if the queue is larger than the net_device's
tx_queue_len. This behavior is useful for WRED mode, since these packets
will still influence the calculated average queue length and (therefore)
the drop probability for all of the other VQs. However, for some drivers
tx_queue_len is zero. In other cases the user may wish to make the limit
the same for all VQs (including the default VQ with no drop parameters).
This change adds a TCA_GRED_LIMIT attribute to set the GRED queue limit,
in bytes, during qdisc setup. (This limit is in bytes to be consistent
with the drop parameters.) The default limit is the same as for a bfifo
queue (tx_queue_len * psched_mtu). If the drop parameters of any VQ are
configured with a smaller limit than the GRED queue limit, that VQ will
still observe the smaller limit instead.
Signed-off-by: David Ward <david.ward@ll.mit.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 24e737c1ebacf0a19cb1d2671949de12b3361f4d
Author: Nicolas Schichan <nschichan@freebox.fr>
Date: Thu May 7 15:00:13 2015 +0200
ARM: net: add JIT support for loads from struct seccomp_data.
Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 27b6952fda71768fa7ffe17a3fe88cf124f32ad7
Author: Joshua Kinard <kumba@gentoo.org>
Date: Sun Apr 19 21:45:25 2015 -0400
MIPS: IP32: Fix build errors in reset code in DS1685 platform hook.
Fix two build errors in reset code introduced in DS1685 platform hook patch.
Signed-off-by: Joshua Kinard <kumba@gentoo.org>
Fixes: 15beb694c661: "mips: ip32: add platform data hooks to use DS1685 driver"
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: LKML <linux-kernel@vger.kernel.org>
Cc: rtc-linux@googlegroups.com
Cc: Linux MIPS List <linux-mips@linux-mips.org>
Patchwork: https://patchwork.linux-mips.org/patch/9787/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
commit 5f508c43a7648baa892528922402f1e13f258bd4
Author: Nicholas Mc Guire <hofrat@osadl.org>
Date: Fri May 8 17:38:52 2015 +0200
MIPS: KVM: Fix unused variable build warning
As kvm_mips_complete_mmio_load() did not yet modify PC at this point
as James Hogans <james.hogan@imgtec.com> explained the curr_pc variable
and the comments along with it can be dropped.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Link: http://lkml.org/lkml/2015/5/8/422
Cc: Gleb Natapov <gleb@kernel.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: kvm@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/9993/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
commit 207c505c6a2771e0a16d478b9b52b0a839437e29
Author: Petri Gynther <pgynther@google.com>
Date: Fri May 8 15:10:10 2015 -0700
MIPS: traps: print Exception Code in __show_regs()
Print Exception Code when printing the Cause register.
Signed-off-by: Petri Gynther <pgynther@google.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9998/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
commit 2d2ec2f7c9560aa12417e5d8c26fe159cfdd3827
Author: Petri Gynther <pgynther@google.com>
Date: Fri May 8 15:10:00 2015 -0700
MIPS: traps: remove extra Tainted: line from __show_regs() output
__show_regs() calls show_regs_print_info(), which already outputs
the Tainted: information. So, no need to output it twice.
Signed-off-by: Petri Gynther <pgynther@google.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9997/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
commit 73d8f99ce42c7da97822faed6aa14578a708b19d
Author: Aaro Koskinen <aaro.koskinen@iki.fi>
Date: Mon May 11 23:37:05 2015 +0300
MIPS: Fix wrong CHECKFLAGS (sparse builds) with GCC 5.1
GCC 5.1 defines __REGISTER_PREFIX__ to $. This will break sparse
command line (and build fails with: /bin/sh: syntax error:
unexpected "(") since make tries to expand starting with the dollar
sign with a make variable. Prevent that by using double dollar sign.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/10025/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
commit c6d94e9354139e8a0ef3bd3286b2a5ac30f8f6aa
Author: Rafał Miłecki <zajec5@gmail.com>
Date: Tue May 12 13:05:18 2015 +0200
MIPS: BCM47xx: Read board info for all bcma buses
Extra bcma buses may be totally different models, see following dump:
boardtype=0x0646
pci/1/1/boardtype=0x0545
pci/2/1/boardtype=0x62b
We need to detect them properly to allow drivers apply some board
specific hacks.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Cc: linux-mips@linux-mips.org
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Patchwork: https://patchwork.linux-mips.org/patch/10028/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
commit f391caa84c3cd09be9012bc5d383235a854ce646
Author: Rafał Miłecki <zajec5@gmail.com>
Date: Tue May 12 11:54:48 2015 +0200
MIPS: BCM47xx: Extract info about et2 interface
New devices may have more than 1 Ethernet core (device). We should
extract info about them to make it available to Ethernet drivers.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Cc: linux-mips@linux-mips.org
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: Hante Meuleman <meuleman@broadcom.com>
Cc: Ian Kent <raven@themaw.net>
Patchwork: https://patchwork.linux-mips.org/patch/10027/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
commit b7be0a04d0457f7fec7abcf0149b8ce5c56bad7e
Author: Rafał Miłecki <zajec5@gmail.com>
Date: Tue May 12 11:31:02 2015 +0200
MIPS: BCM47xx: Extract all boardflags to new u32 fields
For years we planned to get rid of old u16 fields, let's start doing it
with MIPS code. This process will take some time, it requires doing the
same in ssb/bcma and then switching all drivers to new fields. This will
be handled in separated patches submitted to appropriate trees.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Cc: linux-mips@linux-mips.org
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Patchwork: https://patchwork.linux-mips.org/patch/10026/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
commit 03dce595270f22d59a6f37e9170287c1afd94bc2
Author: Maciej W. Rozycki <macro@linux-mips.org>
Date: Tue May 12 15:20:57 2015 +0100
MIPS: Fix a preemption issue with thread's FPU defaults
Fix "BUG: using smp_processor_id() in preemptible" reported in accesses
to thread's FPU defaults: the value to initialise FSCR to at program
startup, the FCSR r/w mask and the contents of FIR in full FPU
emulation, removing a regression introduced with 9b26616c [MIPS: Respect
the ISA level in FCSR handling] and f6843626 [MIPS: math-emu: Set FIR
feature flags for full emulation].
Use `boot_cpu_data' to obtain the data from, following the approach that
`cpu_has_*' macros take and avoiding the call to `smp_processor_id' made
in the reference to `current_cpu_data'. The contents of FSCR have to be
consistent across processors in an SMP system, the settings there must
not change as a thread is migrated across processors. And the contents
of FIR are guaranteed to be consistent in FPU emulation, by definition.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Tested-by: Ezequiel Garcia <ezequiel.garcia@imgtec.com>
Tested-by: Paul Martin <paul.martin@codethink.co.uk>
Cc: Markos Chandras <Markos.Chandras@imgtec.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/10030/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
commit 28837bc3e732610ebc7c88ce205dbe43245b1cb8
Author: Arnd Bergmann <arnd@arndb.de>
Date: Tue May 12 23:03:16 2015 +0200
arm-soc: document merges
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
commit 45e8a10a15b2a99ba046b6d4d85603e8b59b7e62
Author: Rafał Miłecki <zajec5@gmail.com>
Date: Tue May 12 18:46:12 2015 +0200
MIPS: BCM47XX: Simplify function looking for NVRAM entry
First of all it shouldn't modify copied NVRAM just to make sure it can
loop over all entries. It's enough to just compare current position
pointer with the end of buffer address.
Secondly buffer is guaranteed to be \0 ended, so we don't need strnchr.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Cc: linux-mips@linux-mips.org
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: Hante Meuleman <meuleman@broadcom.com>
Cc: Ian Kent <raven@themaw.net>
Patchwork: https://patchwork.linux-mips.org/patch/10032/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
commit ee59b98bb1821e2234453e48218dff5ae28fe55c
Author: Rafał Miłecki <zajec5@gmail.com>
Date: Tue May 12 18:46:11 2015 +0200
MIPS: BCM47XX: Make sure NVRAM buffer ends with \0
This will simplify reading its contents.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Cc: linux-mips@linux-mips.org
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: Hante Meuleman <meuleman@broadcom.com>
Cc: Ian Kent <raven@themaw.net>
Patchwork: https://patchwork.linux-mips.org/patch/10031/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
commit f6505fbabc426b9e293da5bb702ace2eb1ccf87d
Author: Feng Kan <fkan@apm.com>
Date: Fri Apr 24 15:17:50 2015 -0700
i2c: add SLIMpro I2C device driver on APM X-Gene platform
Add SLIMpro I2C device driver on APM X-Gene platform. This I2C
device driver use the SLIMpro Mailbox driver to tunnel message to
the SLIMpro coprocessor to do the work of accessing I2C components.
Signed-off-by: Feng Kan <fkan@apm.com>
Signed-off-by: Hieu Le <hnle@apm.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
commit 7b57472fb6cbd87a8b10209897636df3c7bff087
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Mon May 11 12:06:38 2015 +0200
ARM: multi_v7_defconfig: enable asm and NEON accelerated crypto modules
Enable all drivers under CONFIG_ARM_CRYPTO as modules. Enable
CONFIG_KERNEL_MODE_NEON as well so that the modules that either
contain a NEON alternative or consist solely of a NEON (or ARMv8
crypto extensions) accelerated implementation are enabled fully as
well.
Note that the ARMv8 modules will only be built if the detected
toolchain version is recent enough (binutils 2.23 or higher).
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
commit d045c77c1a69703143a36169c224429c48b9eecd
Author: Helge Deller <deller@gmx.de>
Date: Mon May 11 22:01:27 2015 +0200
parisc,metag: Fix crashes due to stack randomization on stack-grows-upwards architectures
On architectures where the stack grows upwards (CONFIG_STACK_GROWSUP=y,
currently parisc and metag only) stack randomization sometimes leads to crashes
when the stack ulimit is set to lower values than STACK_RND_MASK (which is 8 MB
by default if not defined in arch-specific headers).
The problem is, that when the stack vm_area_struct is set up in fs/exec.c, the
additional space needed for the stack randomization (as defined by the value of
STACK_RND_MASK) was not taken into account yet and as such, when the stack
randomization code added a random offset to the stack start, the stack
effectively got smaller than what the user defined via rlimit_max(RLIMIT_STACK)
which then sometimes leads to out-of-stack situations and crashes.
This patch fixes it by adding the maximum possible amount of memory (based on
STACK_RND_MASK) which theoretically could be added by the stack randomization
code to the initial stack size. That way, the user-defined stack size is always
guaranteed to be at minimum what is defined via rlimit_max(RLIMIT_STACK).
This bug is currently not visible on the metag architecture, because on metag
STACK_RND_MASK is defined to 0 which effectively disables stack randomization.
The changes to fs/exec.c are inside an "#ifdef CONFIG_STACK_GROWSUP"
section, so it does not affect other platformws beside those where the
stack grows upwards (parisc and metag).
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: linux-parisc@vger.kernel.org
Cc: James Hogan <james.hogan@imgtec.com>
Cc: linux-metag@vger.kernel.org
Cc: stable@vger.kernel.org # v3.16+
commit ddcad7e9068ebc6526728df1f34f1dde4b7dbbab
Author: Michael Welling <mwelling@ieee.org>
Date: Tue May 12 12:38:57 2015 -0500
spi: omap2-mcspi: Fix native cs with new set_cs
GPIO chip select patch series appears to have broken the native chip select
support. This patch pulls the manual native chip select toggling out of
the transfer_one routine and adds a set_cs routine.
Tested natively on AM3354 with SPI serial flash on spi0cs0.
Reported-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Michael Welling <mwelling@ieee.org>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 9dcb0e7b999db6c420c70fd32497a979a044fcdf
Author: Felipe Balbi <balbi@ti.com>
Date: Wed May 6 11:50:27 2015 -0500
i2c: omap: implement bus recovery
implement bus recovery methods for i2c-omap
so we can recover from situations where SCL/SDA
are stuck low.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
commit 7a8c78675f3c81760cde8ef31a9fcb0cb9ace231
Author: Zidan Wang <zidan.wang@freescale.com>
Date: Tue May 12 14:58:21 2015 +0800
ASoC: wm8960: add 32 bit word length support
According to referance manual, right justify mode can't
support 32 bit word length.
Signed-off-by: Zidan Wang <zidan.wang@freescale.com>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 0e50b51aa22fea0b6762f9d932541ec6f922928f
Author: Zidan Wang <zidan.wang@freescale.com>
Date: Tue May 12 14:58:08 2015 +0800
ASoC: wm8960: Let wm8960 driver configure its bit clock and frame clock
wm8960 codec driver missing configure its bit clock and frame clock for codec
master mode, so add support for it. It will calculate a appropriate frequency
dividing ratio according to the system clock, bit clock and frame clock, then
set the corresponding registers.
Signed-off-by: Zidan Wang <zidan.wang@freescale.com>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 17fc2e0a3db11889e942c5ab15a1fcb876638f25
Author: Zidan Wang <zidan.wang@freescale.com>
Date: Tue May 12 14:58:50 2015 +0800
ASoC: wm8994: correct BCLK DIV 348 to 384
According to the RM of wm8958, BCLK DIV 348 doesn't exist, correct it
to 384.
Signed-off-by: Zidan Wang <zidan.wang@freescale.com>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
commit 85e36a1f4a735d991ba5106781ea48e89a0b8901
Author: Zidan Wang <zidan.wang@freescale.com>
Date: Tue May 12 14:58:36 2015 +0800
ASoC: wm8960: fix "RINPUT3" audio route error
It should be "RINPUT3" instead of "LINPUT3" route to "Right Input
Mixer".
Signed-off-by: Zidan Wang <zidan.wang@freescale.com>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
commit 05a9b46a718f664fce5d236abe72bffb8200d616
Author: John Lin <john.lin@realtek.com>
Date: Tue May 12 20:43:05 2015 +0800
ASoC: rt5645: fix jack type detect error
rt5645_jack_detect doesn't report the correct jack type consistently.
It mistakes OMTP type headset to CTIA type in particular HW design.
Register changes are needed for this issue. This patch can make it
more stable.
Signed-off-by: John Lin <john.lin@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit b7f22478c01dbb44545f7b8192a6111d5e992a59
Author: John Lin <john.lin@realtek.com>
Date: Tue May 12 20:43:04 2015 +0800
ASoC: rt5645: fix IRQ error in jack detection
IRQ of jack and button detection is abnormal if "LDO2" and
"Mic Det Power" power disable in rt5645_jack_detect.
This patch make these two power keep enabled until jack out.
Signed-off-by: John Lin <john.lin@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 47ba5bb295431c7d2bd0e48b63b4cdce600248d3
Author: John Lin <john.lin@realtek.com>
Date: Tue May 12 20:43:03 2015 +0800
ASoC: rt5645: remove unnecessary power in JD function
The power of "micbias1" and "micbias2" are unnecessary for jack detection.
So, we remove it in rt5645_set_jack_detect function.
Signed-off-by: John Lin <john.lin@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit d12d6c4ef252dd2c40786860c859ab09e0311857
Author: John Lin <john.lin@realtek.com>
Date: Tue May 12 20:43:02 2015 +0800
ASoC: rt5645: improve headphone depop function
We add a calibration function and call it at the beginning of i2c_probe.
The calibration value will be kept until codec is shutdown. We will reset
the codec after the calibration is finished. So, we set cache_bypass in
the calibration function. The benefit is we can shorter the delay time
in headphone depop.
We also change the register setting in the depop sequence which will
reduce the pop noise in headphone playback.
Signed-off-by: John Lin <john.lin@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 908f47190584c400357a8f9c1482d9ef0ceea8fe
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Mon May 11 13:55:47 2015 -0700
rcutorture: Allow repetition factors in Kconfig-fragment lists
Although it is currently possible to run the same test in parallel,
'--config "TINY01 TINY01 TINY01"' can get a bit verbose, especially
if you want to run 48 instances of TINY01 in parallel. This commit
therefore allows prefixing the Kconfig fragment with a repeat count,
for example, '--config "48*TINY01"' to run 48 instances in parallel.
At least assuming that you have 48 CPUs and also gave '--cpus 48'.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
commit 24b18006e763ca6ad807c77ef4c6707c32b001d1
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Thu Apr 23 12:55:54 2015 -0700
rcutorture: Display "make oldconfig" errors
The current rcutorture scripting fails to dump out errors from
"make oldconfig", so this commit addresses this issue.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
commit 30ad6624ccb82d2e0367b9e86468948faa6743bd
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Wed Apr 22 07:20:51 2015 -0700
rcutorture: Update TREE_RCU-kconfig.txt
This commit updates TREE_RCU-kconfig.txt to reflect changes in RCU's
Kconfig setup. This commit also updates rcutorture's Kconfig fragments
to account for Kconfig parameters that are now driven directly off of
other Kconfig parameters.
Reported-by: Pranith Kumar <bobby.prani@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
commit f543280228cbbe9cda8f683edb5ef906e235eaf9
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Mon Apr 20 12:36:10 2015 -0700
rcutorture: Make rcutorture scripts force RCU_EXPERT
This commit causes the rcutorture scripts to force RCU_EXPERT so that
these scripts can cause rcutorture to torture RCU in the various required
configurations. However, SRCU-P, TASKS03, and TREE09 retain !RCU_EXPERT
in order to ensure testing of the vanilla configuration.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Pranith Kumar <bobby.prani@gmail.com>
commit 5631a4bb5261eee3d2191adca52ea7e87bea6c6b
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Mon Apr 20 10:41:13 2015 -0700
rcutorture: Update configuration fragments for rcutree.rcu_fanout_exact
This commit updates rcutortures configuration-fragment files to account
for the move from the CONFIG_RCU_FANOUT_EXACT Kconfig parameter to the
new rcutree.rcu_fanout_exact= boot parameter.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Pranith Kumar <bobby.prani@gmail.com>
commit ca638da52218068f958484c644d409fdf40c39e5
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Mon Apr 20 06:12:16 2015 -0700
rcutorture: TASKS_RCU set directly, so don't explicitly set it
The TASKS01, TASKS02, and TASKS03 rcutorture config fragments currently
set CONFIG_TASKS_RCU. However, now that the value of this Kconfig
parameter is set via "select" statements, it is no longer necessary to
set it explicitly. This commit therefore removes it from the Kconfig
fragments.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Pranith Kumar <bobby.prani@gmail.com>
commit 93beaff5843b91d5c6251276c0306fdbddd11cdc
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Tue Apr 14 12:28:22 2015 -0700
rcutorture: Test SRCU cleanup code path
The current rcutorture testing does not do any cleanup operations.
This works because the srcu_struct is statically allocated, but it
does represent a memory leak of the associated dynamically allocated
->per_cpu_ref per-CPU variables. However, rcutorture currently uses
a statically allocated srcu_struct, which cannot legally be passed to
cleanup_srcu_struct(). Therefore, this commit adds a second form
of srcu (called srcud) that dynamically allocates and frees the
associated per-CPU variables. This commit also adds a ->cleanup()
member to rcu_torture_ops that is invoked at the end of the test,
after ->cb_barriers(). This ->cleanup() pointer is NULL for all
existing tests, and thus only used for scrud. Finally, the SRCU-P
torture-test configuration selects scrud instead of srcu, with SRCU-N
continuing to use srcu, thereby testing both static and dynamic
srcu_struct structures.
Reported-by: "Ahmed, Iftekhar" <ahmedi@onid.oregonstate.edu>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
commit 67c31e24621a9d8e4dbc9a8a88d89eb795acf312
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Mon Apr 13 11:58:08 2015 -0700
rcutorture: Replace barriers with smp_store_release() and smp_load_acquire()
The rcutorture.c file uses several explicit memory barriers that can
easily be converted to smp_store_release() and smp_load_acquire(), which
improves maintainability and also improves performance a bit.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
commit b7a5523004befeb45c250229a53e9fc25ef7b04b
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Wed Apr 1 08:42:27 2015 -0700
locktorture: Change longdelay_us to longdelay_ms
The locktorture long delays are in milliseconds rather than microseconds,
so this commit changes the name of the corresponding variable from
longdelay_us to longdelay_ms.
Reported-by: Ben Goodwyn <bgoodwyn@softnas.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
commit 80e81928a1d9528c5b43a8430fa85de0d3e4ba7c
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Thu Mar 12 13:55:48 2015 -0700
rcutorture: Allow negative values of nreaders to oversubscribe
By default, with rcutorture.nreaders equal to -1, rcutorture provisions
N-1 reader kthreads, where N is the number of CPUs. This avoids
rcutorture-induced stalls, but also avoids heavier levels of torture.
This commit therefore allows negative values of rcutorture.nreaders
to specify larger numbers of reader kthreads, so that for example
rcutorture.nreaders=-2 provisions N kthreads and rcutorture.nreaders=-5
provisions N+3 kthreads.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
commit 67f58ecc17d77f64ae476974fdb2813124b6f5a1
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Thu Mar 12 11:42:48 2015 -0700
rcutorture: Exchange TREE03 and TREE08 NR_CPUS, speed up CPU hotplug
TREE03 has been especially effective at finding bugs lately. This commit
makes it even more effective by speeding up its CPU hotplug testing and
increasing its NR_CPUs from 8 to 16. TREE08's NR_CPUS is decreased from
16 to 8 in order to maintain the same test duration.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
commit b74874a95163379617c6ec59f445cbe3008bc4f3
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Wed Mar 11 15:25:53 2015 -0700
rcutorture: Exchange TREE03 and TREE04 geometries
Given that the combination of PREEMPT_RCU and HOTPLUG_CPU is producing the
most bugs lately, this commit swaps the TREE03 and TREE04 rcu_node-tree
geometries so that the test exercising PREEMPT_RCU and HOTPLUG_CPU has
three-level rather than two-level rcu_node trees.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
commit 69a4a73c8d14aef587dcf25830195b1f3498a3d2
Author: Alexey Kodanev <alexey.kodanev@oracle.com>
Date: Sat Mar 7 03:06:53 2015 +0300
locktorture: fix deadlock in 'rw_lock_irq' type
torture_rwlock_read_unlock_irq() must use read_unlock_irqrestore()
instead of write_unlock_irqrestore().
Use read_unlock_irqrestore() instead of write_unlock_irqrestore().
Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
commit e5cbec617f1791256197ebaca8b04c0eb96fc574
Author: Julien Grall <julien.grall@citrix.com>
Date: Wed May 13 03:49:04 2015 +0900
ARM: EXYNOS: Don't try to initialize suspend on old DT
Since commit 8b283c025443 ("ARM: exynos4/5: convert pmu wakeup to
stacked domains"), a suspend/resume is not supported on old DT.
Although, rather than printing a warning and continue to boot, the
kernel will segfault just after:
------------[ cut here ]------------
WARNING: CPU: 1 PID: 1 at arch/arm/mach-exynos/suspend.c:726 exynos_pm_init+0x4c/0xc8()
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.1.0-rc3 #1
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[<c02181c4>] (unwind_backtrace) from [<c0213b2c>] (show_stack+0x10/0x14)
[<c0213b2c>] (show_stack) from [<c0949890>] (dump_stack+0x70/0x8c)
[<c0949890>] (dump_stack) from [<c024f0b0>] (warn_slowpath_common+0x74/0xac)
[<c024f0b0>] (warn_slowpath_common) from [<c024f104>] (warn_slowpath_null+0x1c/0x24)
[<c024f104>] (warn_slowpath_null) from [<c0cf1d28>] (exynos_pm_init+0x4c/0xc8)
[<c0cf1d28>] (exynos_pm_init) from [<c0ceaae8>] (init_machine_late+0x1c/0x28)
[<c0ceaae8>] (init_machine_late) from [<c020aa64>] (do_one_initcall+0x80/0x1d0)
[<c020aa64>] (do_one_initcall) from [<c0ce8d4c>] (kernel_init_freeable+0x10c/0x1d8)
[<c0ce8d4c>] (kernel_init_freeable) from [<c0944a2c>] (kernel_init+0x8/0xe4)
[<c0944a2c>] (kernel_init) from [<c0210e60>] (ret_from_fork+0x14/0x34)
---[ end trace 335bd937d409f3c7 ]---
Outdated DT detected, suspend/resume will NOT work
Unable to handle kernel NULL pointer dereference at virtual address 00000608
pgd = c0204000
[00000608] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.1.0-rc3 #1
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
task: db06c000 ti: db05a000 task.ti: db05a000
PC is at exynos_pm_init+0x6c/0xc8
LR is at exynos_pm_init+0x54/0xc8
pc : [<c0cf1d48>] lr : [<c0cf1d30>] psr: 60000113
sp : db05bee8 ip : 00000000 fp : 00000000
r10: 00000116 r9 : c0dab2d4 r8 : d8d5f440
r7 : c0db7ad8 r6 : c0db7ad8 r5 : 00000000 r4 : c0ceaacc
r3 : c0eb2aec r2 : c0951e40 r1 : 00000000 r0 : c0eb2acc
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 6020406a DAC: 00000015
Process swapper/0 (pid: 1, stack limit = 0xdb05a220)
Stack: (0xdb05bee8 to 0xdb05c000)
bee0: c0db7ad8 c0d8fe34 c0cf17c8 c0ceaae8 00000000 c020aa64
bf00: 00000033 c09580b8 db04fd00 c0ed79a4 c0eb1000 c0ce8588 c0ca2bc4 c0353fcc
bf20: 00000000 c0df358c 60000113 00000000 dbfffba4 00000000 c0ca2bc4 c026654c
bf40: c0b80134 c0ca1a64 00000007 00000007 c0df3554 c0d6c2f4 00000007 c0d6c2d4
bf60: c0eb1000 c0ce8588 c0dab2d4 00000116 00000000 c0ce8d4c 00000007 00000007
bf80: c0ce8588 c0944a24 00000000 c0944a24 00000000 00000000 00000000 00000000
bfa0: 00000000 c0944a2c 00000000 c0210e60 00000000 00000000 00000000 00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[<c0cf1d48>] (exynos_pm_init) from [<c0ceaae8>] (init_machine_late+0x1c/0x28)
[<c0ceaae8>] (init_machine_late) from [<c020aa64>] (do_one_initcall+0x80/0x1d0)
[<c020aa64>] (do_one_initcall) from [<c0ce8d4c>] (kernel_init_freeable+0x10c/0x1d8)
[<c0ce8d4c>] (kernel_init_freeable) from [<c0944a2c>] (kernel_init+0x8/0xe4)
[<c0944a2c>] (kernel_init) from [<c0210e60>] (ret_from_fork+0x14/0x34)
Code: e59f005c e59220c0 e5901000 e5832000 (e591e608)
---[ end trace 335bd937d409f3c8 ]---
This is happening because pmu_base_addr is only initialized when the
PMU is an interrupt controller. It's not the case on old DT.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Signed-off-by: Kukjin Kim <kgene@kernel.org>
commit 16f0acd0ca5dd6103df5b789553da86ff3d5c505
Author: Fabio Estevam <fabio.estevam@freescale.com>
Date: Tue May 12 01:23:00 2015 -0300
ASoC: max98095: Pass the IRQF_ONESHOT flag
Since commit 1c6c69525b40eb76de8adf039409722015927dc3 ("genirq: Reject
bogus threaded irq requests") threaded IRQs without a primary handler
need to be requested with IRQF_ONESHOT, otherwise the request will fail.
So pass the IRQF_ONESHOT flag in this case.
The semantic patch that makes this change is available
in scripts/coccinelle/misc/irqf_oneshot.cocci.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 208ba89b402d4f63a1352ae289fb8428cb92e7ec
Author: Fabio Estevam <fabio.estevam@freescale.com>
Date: Tue May 12 01:22:59 2015 -0300
ASoC: twl6040: Pass the IRQF_ONESHOT flag
Since commit 1c6c69525b40eb76de8adf039409722015927dc3 ("genirq: Reject
bogus threaded irq requests") threaded IRQs without a primary handler
need to be requested with IRQF_ONESHOT, otherwise the request will fail.
So pass the IRQF_ONESHOT flag in this case.
The semantic patch that makes this change is available
in scripts/coccinelle/misc/irqf_oneshot.cocci.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit d78395ce7825a74c4cbd1aebdd6cc6912d834f47
Author: Fabio Estevam <fabio.estevam@freescale.com>
Date: Tue May 12 01:22:58 2015 -0300
ASoC: wm8994: Pass the IRQF_ONESHOT flag
Since commit 1c6c69525b40eb76de8adf039409722015927dc3 ("genirq: Reject
bogus threaded irq requests") threaded IRQs without a primary handler
need to be requested with IRQF_ONESHOT, otherwise the request will fail.
So pass the IRQF_ONESHOT flag in this case.
The semantic patch that makes this change is available
in scripts/coccinelle/misc/irqf_oneshot.cocci.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 3d907cc30d072829b6682fda791005de5768f34e
Author: Fabio Estevam <fabio.estevam@freescale.com>
Date: Tue May 12 01:22:57 2015 -0300
ASoC: wm5100: Pass the IRQF_ONESHOT flag
Since commit 1c6c69525b40eb76de8adf039409722015927dc3 ("genirq: Reject
bogus threaded irq requests") threaded IRQs without a primary handler
need to be requested with IRQF_ONESHOT, otherwise the request will fail.
So pass the IRQF_ONESHOT flag in this case.
The semantic patch that makes this change is available
in scripts/coccinelle/misc/irqf_oneshot.cocci.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit b6b4aae7a75457877abe77afba30aa2301815808
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Mon May 11 11:13:05 2015 -0700
rcu: Correctly handle non-empty Tiny RCU callback list with none ready
If, at the time __rcu_process_callbacks() is invoked, there are callbacks
in Tiny RCU's callback list, but none of them are ready to be invoked,
the current list-management code will knit the non-ready callbacks out
of the list. This can result in hangs and possibly worse. This commit
therefore inserts a check for there being no callbacks that can be
invoked immediately.
This bug is unlikely to occur -- you have to get a new callback between
the time rcu_sched_qs() or rcu_bh_qs() was called, but before we get to
__rcu_process_callbacks(). It was detected by the addition of RCU-bh
testing to rcutorture, which in turn was instigated by Iftekhar Ahmed's
mutation testing. Although this bug was made much more likely by
915e8a4fe45e (rcu: Remove fastpath from __rcu_process_callbacks()), this
did not cause the bug, but rather made it much more probable. That
said, it takes more than 40 hours of rcutorture testing, on average,
for this bug to appear, so this fix cannot be considered an emergency.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org>
commit 22c758f3936008b4bc438a92dc5266dc43432e19
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Tue Apr 21 12:11:23 2015 -0700
rcutorture: Test both RCU-sched and RCU-bh for Tiny RCU
Reported-by: "Ahmed, Iftekhar" <ahmedi@onid.oregonstate.edu>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
commit 9322c6e07d5ec4972e480df10476ce955f606acb
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Tue Apr 21 11:15:30 2015 -0700
rcu: Further shrink Tiny RCU by making empty functions static inlines
The Tiny RCU counterparts to rcu_idle_enter(), rcu_idle_exit(),
rcu_irq_enter(), and rcu_irq_exit() are empty functions, but each
has EXPORT_SYMBOL_GPL(), which, in kernels built with module support,
needlessly consumes some memory. This commit therefore moves these
functions to static inlines in rcutiny.h, removing the need for
exports.
This won't affect the size of the tiniest kernels, which are likely
built without module support, but might help semi-tiny kernels that
might include module support.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
commit ed043aebe6ece3e13a02b6574447f150c3557378
Author: Fabio Estevam <fabio.estevam@freescale.com>
Date: Tue May 12 01:22:56 2015 -0300
ASoC: wm8996: Pass the IRQF_ONESHOT flag
Since commit 1c6c69525b40eb76de8adf039409722015927dc3 ("genirq: Reject
bogus threaded irq requests") threaded IRQs without a primary handler
need to be requested with IRQF_ONESHOT, otherwise the request will fail.
So pass the IRQF_ONESHOT flag in this case.
The semantic patch that makes this change is available
in scripts/coccinelle/misc/irqf_oneshot.cocci.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit e4dcfe3a648b436c713a7a4eb6b501af2eac3f25
Author: Patrick Marlier <patrick.marlier@gmail.com>
Date: Tue Mar 24 11:21:05 2015 +0100
netfilter: Fix list_entry_rcu usage
Signed-off-by: Patrick Marlier <patrick.marlier@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
commit d51f746961ec896ce23c0fb8b3ce7e873ef14648
Author: Markus Reichl <m.reichl@fivetechno.de>
Date: Wed May 13 03:45:22 2015 +0900
ARM: dts: Add HS400 support for exynos5422-odroidxu3
HS400 timing values are added for exynos5422-odroidxu3 board.
Signed-off-by: Markus Reichl <m.reichl@fivetechno.de>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Kukjin Kim <kgene@kernel.org>
commit 8af36ed0474f21f6b29bf091192e6245c424639a
Author: Patrick Marlier <patrick.marlier@gmail.com>
Date: Tue Mar 24 11:22:10 2015 +0100
md/bitmap: Fix list_entry_rcu usage
Signed-off-by: Patrick Marlier <patrick.marlier@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
commit 65ca9a4f70e67ee95d6355c8abb13454349cb62b
Author: Patrick Marlier <patrick.marlier@gmail.com>
Date: Tue Mar 24 11:16:55 2015 +0100
rculist: Fix list_entry_rcu to read ptr with rcu_dereference_raw
Change to read effectively ptr with rcu_dereference_raw and not the
__ptr variable on the stack.
Signed-off-by: Patrick Marlier <patrick.marlier@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
commit eba012dcdabbe29d9d62c5dc300689fa2b68b246
Author: Ying Xue <ying.xue@windriver.com>
Date: Thu Mar 26 13:27:08 2015 +0800
rculist: Fix another sparse warning
This fixes the following sparse warnings:
make C=1 CF=-D__CHECK_ENDIAN__ net/tipc/name_table.o
net/tipc/name_table.c:977:17: error: incompatible types in comparison expression (different address spaces)
net/tipc/name_table.c:977:17: error: incompatible types in comparison expression (different address spaces)
To silence these spare complaints, an RCU annotation should be added to
"next" pointer of hlist_node structure through hlist_next_rcu() macro
when iterating over a hlist with hlist_for_each_entry_from_rcu().
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
commit c5f4823babfd5e1b34494310e0a9f7cab44cadb9
Author: Zidan Wang <zidan.wang@freescale.com>
Date: Mon May 11 18:24:43 2015 +0800
ASoC: fsl_sai: add 12kHz, 24kHz, 176.4kHz and 192kHz sample rate support
Normally we don't support 12kHz, 24kHz in audio driver, alsa didn't
have formal definition of 12kHz, 24kHz, but alsa supply a way to
support these sample rates. And add 176.4kHz and 192kHz support.
Signed-off-by: Zidan Wang <zidan.wang@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 9e8aa513222973d2b22d875eaddcedf90499bd9a
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Tue May 5 23:04:22 2015 -0700
rcu: Conditionally compile RCU's eqs warnings
This commit applies some warning-omission micro-optimizations to RCU's
various extended-quiescent-state functions, which are on the kernel/user
hotpath for CONFIG_NO_HZ_FULL=y.
Reported-by: Rik van Riel <riel@redhat.com>
Reported by: Mike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
commit f4bf39ae153987f07f1f7cf543344bd99f5d6e2d
Author: Pranith Kumar <bobby.prani@gmail.com>
Date: Tue Apr 21 17:29:42 2015 -0400
rcu: Remove prompt for RCU implementation
The RCU implementation is chosen based on PREEMPT and SMP config options
and is not really a user-selectable choice. This commit removes the
menu entry, given that there is not much point in calling something a
choice when there is in fact no choice.. The TINY_RCU, TREE_RCU, and
PREEMPT_RCU Kconfig options continue to be selected based solely on the
values of the PREEMPT and SMP options.
Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
commit 0b920085c1ddec4b295ce6a73de3af343ac86d50
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Tue Apr 21 09:22:14 2015 -0700
rcu: Make RCU able to tolerate undefined CONFIG_RCU_KTHREAD_PRIO
This commit updates the initialization of the kthread_prio boot parameter
so that RCU will build even when CONFIG_RCU_KTHREAD_PRIO is undefined.
The kthread_prio boot parameter is set to CONFIG_RCU_KTHREAD_PRIO if
that is defined, otherwise to 1 if CONFIG_RCU_BOOST is defined and
to zero otherwise. This commit then makes CONFIG_RCU_KTHREAD_PRIO
depend on CONFIG_RCU_EXPERT, so that Kconfig users won't be asked about
CONFIG_RCU_KTHREAD_PRIO unless they want to be.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Reported-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Pranith Kumar <bobby.prani@gmail.com>
commit 75cc99a0162030476c5dcacdef96eaabf109dfd2
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Tue Apr 21 09:12:13 2015 -0700
rcu: Make RCU able to tolerate undefined CONFIG_RCU_FANOUT_LEAF
This commit introduces an RCU_FANOUT_LEAF C-preprocessor macro so
that RCU will build even when CONFIG_RCU_FANOUT_LEAF is undefined.
The RCU_FANOUT_LEAF macro is set to the value of CONFIG_RCU_FANOUT_LEAF
when defined, otherwise it is set to 32 for 32-bit systems and 64 for
64-bit systems. This commit then makes CONFIG_RCU_FANOUT_LEAF depend
on CONFIG_RCU_EXPERT, so that Kconfig users won't be asked about
CONFIG_RCU_FANOUT_LEAF unless they want to be.
Reported-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Pranith Kumar <bobby.prani@gmail.com>
commit 372b4ad2c36081e92a033a380e99d08fa1fa0e5e
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Mon Apr 20 14:27:43 2015 -0700
rcu: Make RCU able to tolerate undefined CONFIG_RCU_FANOUT
This commit introduces an RCU_FANOUT C-preprocessor macro so that RCU will
build even when CONFIG_RCU_FANOUT is undefined. The RCU_FANOUT macro is
set to the value of CONFIG_RCU_FANOUT when defined, otherwise it is set
to 32 for 32-bit systems and 64 for 64-bit systems. This commit then
makes CONFIG_RCU_FANOUT depend on CONFIG_RCU_EXPERT, so that Kconfig
users won't be asked about CONFIG_RCU_FANOUT unless they want to be.
Reported-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Pranith Kumar <bobby.prani@gmail.com>
commit 634c66b0c7bcb769fb0887c92deaa60d0a15779d
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Mon Apr 20 18:27:54 2015 -0700
rcu: Break dependency of RCU_FANOUT_LEAF on RCU_FANOUT
RCU_FANOUT_LEAF's range and default values depend on the value of
RCU_FANOUT, which at the time seemed like a cute way to save two lines
of Kconfig code. However, adding a dependency from both of these
Kconfig parameters on RCU_EXPERT requires that RCU_FANOUT_LEAF operate
correctly even if RCU_FANOUT is undefined. This commit therefore
allows RCU_FANOUT_LEAF to take on the full range of permitted values,
even in cases where RCU_FANOUT is undefined.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
[ paulmck: Eliminate redundant "default" as suggested by Pranith Kumar. ]
Reviewed-by: Pranith Kumar <bobby.prani@gmail.com>
commit 9e2b8d1031f9cb2454b173a5d788254091210eda
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Mon Apr 20 12:19:45 2015 -0700
rcu: Create RCU_EXPERT Kconfig and hide booleans behind it
This commit creates an RCU_EXPERT Kconfig and hides the independent
boolean RCU-related user-visible Kconfig parameters behind it, namely
RCU_FAST_NO_HZ and RCU_BOOST. This prevents Kconfig from asking about
these parameters unless the user really wants to be asked.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Pranith Kumar <bobby.prani@gmail.com>
commit 55cb0b70a4383bb75084c27df2ac8a6511690aba
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Mon Apr 20 11:40:50 2015 -0700
rcu: Enable diagnostic dump of rcu_node combining tree
The purpose of this commit is to make it easier to verify that RCU's
combining tree is set up correctly, which is useful to have when making
changes in how that tree is initialized.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Pranith Kumar <bobby.prani@gmail.com>
[ paulmck: Fold fix found by Fengguang's 0-day test robot. ]
commit ea4736e4a00c965b8cd79f75f0bf702b9bd5dfd6
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Mon Apr 20 10:27:15 2015 -0700
rcu: Convert CONFIG_RCU_FANOUT_EXACT to boot parameter
The CONFIG_RCU_FANOUT_EXACT Kconfig parameter is used primarily (and
perhaps only) by rcutorture to verify that RCU works correctly in specific
rcu_node combining-tree configurations. It therefore does not make
much sense have this as a question to people attempting to configure
their kernels. So this commit creates an rcutree.rcu_fanout_exact=
boot parameter that rcutorture can use, and eliminates the original
CONFIG_RCU_FANOUT_EXACT Kconfig parameter.
Reported-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Pranith Kumar <bobby.prani@gmail.com>
commit 548e691de6ec85a1143a2323c357573390b30cbe
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Mon Apr 20 06:17:15 2015 -0700
rcu: Directly drive RCU_USER_QS from Kconfig
Currently, Kconfig will ask the user whether RCU_USER_QS should be set.
…
ddstreet
referenced
this pull request
in ddstreet/linux
Jun 20, 2015
GIT c5901c20eb0341722035975a272a2a7b647fbb32
commit eeb64c14275e52740d6410632e62e0ad9b88ca70
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Sat Jun 6 11:44:39 2015 -0700
tty/vt/keyboard: define LED triggers for VT keyboard lock states
In addition to defining triggers for VT LED states, let's define triggers
for VT keyboard lock states, such as "kbd-shiftlock", "kbd-altgrlock", etc.
This permits to fix #7063 from userland by using a modifier to implement
proper CapsLock behavior and have the keyboard caps lock led show that
modifier state.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Tested-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
commit 5235552273e6b68abbed3b3047af6344e2e60c2c
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Mon Mar 16 21:19:44 2015 -0700
tty/vt/keyboard: define LED triggers for VT LED states
Now that input core allows controlling keyboards LEDs via standard LED
subsystem triggers let's switch VT keyboard code to make use of this
feature. We will define the following standard triggers: "kbd-scrollock",
"kbd-numlock", "kbd-capslock", and "kbd-kanalock" which are default
triggers for respective LEDs on keyboards.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Tested-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
commit 10e87dc42a086c256b25334b6c1c89214feba9a7
Author: Andrew Duggan <aduggan@synaptics.com>
Date: Tue Jun 16 14:08:41 2015 -0700
HID: rmi: Disable populating F30 when the touchpad has physical buttons
Physical buttons do not use F30 to report their state and in some cases the
data reported in F30 is incorrect and inconsistent with what is reported by
the HID descriptor. When physical buttons are present, ignore F30 and let
hid-input report buttons based on what is defined in the HID descriptor.
Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
commit ba8d134e75deb1904b146a4decb0bc6a217333cd
Author: Nishanth Menon <nm@ti.com>
Date: Mon Apr 20 19:51:34 2015 -0500
rtc: ds1307: Enable the mcp794xx alarm after programming time
Alarm interrupt enable register is at offset 0x7, while the time
registers for the alarm follow that. When we program Alarm interrupt
enable prior to programming the time, it is possible that previous
time value could be close or match at the time of alarm enable
resulting in interrupt trigger which is unexpected (and does not match
the time we expect it to trigger).
To prevent this scenario from occuring, program the ALM0_EN bit only
after the alarm time is appropriately programmed.
Ofcourse, I2C programming is non-atomic, so there are loopholes where
the interrupt wont trigger if the time requested is in the past at
the time of programming the ALM0_EN bit. However, we will not have
unexpected interrupts while the time is programmed after the interrupt
are enabled.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@linaro.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
commit b7ae128d728c42583dac9db48dce9a44bc0fb900
Author: Robert Richter <rrichter@cavium.com>
Date: Fri Jun 5 19:49:26 2015 +0200
ahci: Add support for Cavium's ThunderX host controller
This patch adds support for Cavium's ThunderX host controller. The
controller resides on the SoC and is a AHCI compatible SATA controller
with one port, compliant with Serial ATA 3.1 and AHCI Revision 1.31.
There can exists multiple SATA controllers on the SoC.
The controller depends on MSI-X support since the PCI ECAM controller
on the SoC does not implement MSI nor lagacy intx interrupt support.
Thus, during device initialization, if MSI fails MSI-X will be used to
enable the device's interrupts.
The controller uses non-standard BAR0 for its register range. The
already existing device lookup (vendor and device id) that is already
implemented for other host controllers is used to change the PCI BAR.
Signed-off-by: Robert Richter <rrichter@cavium.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
commit ee2aad42e4b6eaa9721196f07f7d5d8d049e6530
Author: Robert Richter <rrichter@cavium.com>
Date: Fri Jun 5 19:49:25 2015 +0200
ahci: Add generic MSI-X support for single interrupts to SATA PCI driver
This patch adds generic MSI-X support for single interrupts to the
SATA PCI driver. MSI-X support is needed for host controller that only
have MSI-X support implemented, but no MSI or intx. This patch only
adds support for single interrupts, multiple per-port MSI-X interrupts
are not yet implemented.
The new implementation still initializes MSIs first. Only if that
fails, the code tries to enable MSI-X. If that fails too, setup is
continued with intx interrupts.
To not break other chips by this generic code change, there are the
following precautions:
* Interrupt ranges are not enabled at all.
* Only single interrupt mode is enabled for msix cap devices. Thus,
only one interrupt will be setup.
* During the discussion with Tejun we agreed to change the init
sequence from msix-msi-intx to msi-msix-intx. Thus, if a device
offers msi and init does not fail, the msix init code will not be
executed. This is equivalent to current code.
With this, the code only setups single mode msix as a last resort if
msi fails. No interrupt range is enabled at all. Only one interrupt
will be enabled.
tj: comment edits.
Changes of the patch series:
v5:
* updated patch subject that the patch only implements single IRQ
* moved Cavium specific code to a separate patch
* detect Cavium ThunderX device with PCI_CLASS_STORAGE_SATA_AHCI
instead of vendor/dev id
* added more comments to the code
* enable single msix support for all kind of devices (removing strict
check)
* rebased onto update libata/for-4.2 with patch 1, 2 applied
v4:
* removed implementation of ahci_init_intx()
* improved patch descriptions
* rebased onto libata/for-4.2
v3:
* store irq number in struct ahci_host_priv
* change initialization order from msix-msi-intx to msi-msix-intx
* improve comments in ahci_init_msix()
* improve error message in ahci_init_msix()
* do not enable MSI-X if MSI is actively disabled for the device
v2:
* determine irq vector from pci_dev->msi_list
Based on a patch from Sunil Goutham <sgoutham@cavium.com>.
Signed-off-by: Robert Richter <rrichter@cavium.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
commit e0dd268a2c983acf2b52130b489b3b5724e26b39
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date: Fri Jun 12 00:35:43 2015 -0700
leds: aat1290: pass flags parameter to devm_gpiod_get
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
In this case the driver cannot easily be simplified but as the flags
parameter will become mandatory soon this change is necessary
beforehand.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
commit c8e27605c687d2d628217bef721e955d4baa1ce1
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date: Fri Jun 12 00:32:23 2015 -0700
leds: ktd2692: pass flags parameter to devm_gpiod_get
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
In this case the driver cannot easily be simplified but as the flags
parameter will become mandatory soon this change is necessary
beforehand.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
commit bc3e452003d02b8ec21546490aaed36003a83864
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:13:42 2015 -0400
module: relocate module_init from init.h to module.h
Modular users will always be users of init functionality, but
users of init functionality are not necessarily always modules.
Hence any functionality like module_init and module_exit would
be more at home in the module.h file. And module.h should
explicitly include init.h to make the dependency clear.
We've already done all the legwork needed to ensure that this
move does not cause any build regressions due to implicit
header file include assumptions about where module_init lives.
Cc: Rusty Russell <rusty@rustcorp.com.au>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit b0c6d93014c8f2f53b70e9362b9fbec13b8e3aa0
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Mon Jun 15 09:56:26 2015 -0400
MIPS: don't use module_init in non-modular cobalt/mtd.c file
As of commit 34b1252bd91851f77f89fbb6829a04efad900f41 ("MIPS:
Cobalt: Do not build MTD platform device registration code as module.")
this file became built-in instead of modular. So we should also
stop using module_init as an alias for __initcall as that can be
rather misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Direct use of __initcall is discouraged, vs prioritized ones.
Use of device_initcall is consistent with what __initcall
maps onto, and hence does not change the init order, making the
impact of this change zero.
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 33d69ca12b44ef3c7be8f948ffa5a35652e1f2ff
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Mon Jun 15 16:48:22 2015 -0500
drivers/leds: don't use module_init in non-modular leds-cobalt-raq.c
This file is built for a bool Kconfig variable, and hence this
code is either present or absent. It currently can never be
modular, so using module_init as an alias for __initcall can be
somewhat misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of device_initcall
directly in this change means that the runtime impact is
zero -- it will remain at level 6 in initcall ordering.
And since it can't be modular, we remove all the __exitcall
stuff related to module_exit() -- it is dead code that won't
ever be executed.
Cc: Bryan Wu <cooloney@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Cc: linux-leds@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 32e805e7c6a343894c95a3431973e8ddad4aa2cf
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri Jun 5 09:37:19 2015 -0400
tile: add init.h to usb.c to avoid compile failure
Pending header cleanups will reveal this file is using the
init.h content implicitly with the following fail:
arch/tile/kernel/usb.c:69:1: warning: data definition has no type or storage class [enabled by default]
arch/tile/kernel/usb.c:69:1: error: type defaults to 'int' in declaration of 'arch_initcall'
arch/tile/kernel/usb.c:69:1: warning: parameter names (without types) in function declaration [enabled by default]
arch/tile/kernel/usb.c:62:19: warning: 'tilegx_usb_init' defined but not used
Explicitly add init.h to get arch_initcall and avoid this.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Chris Metcalf <cmetcalf@ezchip.com>
Acked-by: Chris Metcalf <cmetcalf@ezchip.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 9b9cf81a2d1f5336de2bebae71a9f2b8d5f1a8de
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:13:42 2015 -0400
arm: fix implicit #include <linux/init.h> in entry asm.
They use the "_INIT" macro and friends, and hence need to
source this header file, vs. relying on getting it implicitly.
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 70c4f78b23c69013c908222d55a07c96fea4bba1
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:13:42 2015 -0400
x86: replace __init_or_module with __init in non-modular vsmp_64.c
The __init_or_module is from commit 05e12e1c4c09cd35ac9f4e6af1e
("x86: fix 27-rc crash on vsmp due to paravirt during module load").
But as of commit 70511134f61bd6e5eed19f767381f9fb3e762d49
("Revert "x86: don't compile vsmp_64 for 32bit") this file became
obj-y and hence is now only for built-in. That makes any
"_or_module" support no longer necessary.
We need to distinguish between the two in order to do some header
reorganization between init.h and module.h and we don't want to
be including module.h in non-modular code.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 77459a0feca4ae8757a905fd1791f039479e8e1e
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Wed Jun 3 11:20:05 2015 -0400
drivers/clk: convert sunxi/clk-mod0.c to use builtin_platform_driver
This driver builds based on obj-y and hence will not ever be
modular. Change it to use the non-modular registration so that it
won't suffer a compile fail once a header move places the modular
registration within the module.h file.
Cc: "Emilio López" <emilio@elopez.com.ar>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: linux-clk@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit e35415e59f86d6b546a3681e2cda4f22b5b142c0
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:10:58 2015 -0400
drivers/power: Convert non-modular syscon-reboot to use builtin_platform_driver
This file depends on Kconfig options all of which are a bool, so
we use the appropriate registration function, which avoids us
relying on an implicit inclusion of <module.h> which we are
doing currently.
While this currently works, we really don't want to be including
the module.h header in non-modular code, which we'd be forced
to do, pending some upcoming code relocation from init.h into
module.h. So we fix it now by using the non-modular equivalent.
Cc: Sebastian Reichel <sre@kernel.org>
Acked-By: Sebastian Reichel <sre@kernel.org>
Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: linux-pm@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 0159ae95e6a923f565937f10518aa3c919527733
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:10:57 2015 -0400
drivers/soc: Convert non-modular soc-realview to use builtin_platform_driver
This file depends on Kconfig SOC_REALVIEW which is a bool, so
we use the appropriate registration function, which avoids us
relying on an implicit inclusion of <module.h> which we are
doing currently.
While this currently works, we really don't want to be including
the module.h header in non-modular code, which we'd be forced
to do, pending some upcoming code relocation from init.h into
module.h. So we fix it now by using the non-modular equivalent.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 7d4d9ed6ef5219857865dd57d425f9729d0a39ff
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:10:57 2015 -0400
drivers/soc: Convert non-modular tegra/pmc to use builtin_platform_driver
This file depends on Kconfig ARCH_TEGRA which is a bool, so
we use the appropriate registration function, which avoids us
relying on an implicit inclusion of <module.h> which we are
doing currently.
While this currently works, we really don't want to be including
the module.h header in non-modular code, which we'd be forced
to do, pending some upcoming code relocation from init.h into
module.h. So we fix it now by using the non-modular equivalent.
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-tegra@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 5b64127e0529387d4538ecc3dfd49248baf619c5
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:10:57 2015 -0400
drivers/cpufreq: Convert non-modular s5pv210-cpufreq.c to use builtin_platform_driver
This file depends on a Kconfig option which is a bool, so
we use the appropriate registration function, which avoids us
relying on an implicit inclusion of <module.h> which we are
doing currently.
While this currently works, we really don't want to be including
the module.h header in non-modular code, which we'd be forced
to do, pending some upcoming code relocation from init.h into
module.h. So we fix it now by using the non-modular equivalent.
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Kukjin Kim <kgene@kernel.org>
Cc: linux-pm@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 090d1cf103725f583b3f41fc3185698ae5a7aa64
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:10:57 2015 -0400
drivers/cpuidle: Convert non-modular drivers to use builtin_platform_driver
All these drivers are configured with Kconfig options that are
declared as bool. Hence it is not possible for the code
to be built as modular. However the code is currently using the
module_platform_driver() macro for driver registration.
While this currently works, we really don't want to be including
the module.h header in non-modular code, which we'll be forced
to do, pending some upcoming code relocation from init.h into
module.h. So we fix it now by using the non-modular equivalent.
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 1dda2b42db1bbc788bf6de0a8141a305484f963b
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:10:57 2015 -0400
drivers/platform: Convert non-modular pdev_bus to use builtin_platform_driver
This driver is configured with a Kconfig option that is
declared as a bool. Hence it is not possible for the code
to be built as modular. However the code is currently using
the module_platform_driver() macro for driver registration.
While this currently works, we really don't want to be including
the module.h header in non-modular code, which we'll be forced
to do, pending some upcoming code relocation from init.h into
module.h. So we fix it now by using the non-modular equivalent.
And since we've already established that the code is non-modular,
we can completely drop any code relating to module_exit.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit f309d4443130bf814e991f836e919dca22df37ae
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:10:57 2015 -0400
platform_device: better support builtin boilerplate avoidance
We have macros that help reduce the boilerplate for modules
that register with no extra init/exit complexity other than the
most standard use case. However we see an increasing number of
non-modular drivers using these modular_driver() type register
functions.
There are several downsides to this:
1) The code can appear modular to a reader of the code, and they
won't know if the code really is modular without checking the
Makefile and Kconfig to see if compilation is governed by a
bool or tristate.
2) Coders of drivers may be tempted to code up an __exit function
that is never used, just in order to satisfy the required three
args of the modular registration function.
3) Non-modular code ends up including the <module.h> which increases
CPP overhead that they don't need.
4) It hinders us from performing better separation of the module
init code and the generic init code.
Here we introduce similar macros, with the mapping from module_driver
to builtin_driver and similar, so that simple changes of:
module_platform_driver() ---> builtin_platform_driver()
module_platform_driver_probe() ---> builtin_platform_driver_probe().
can help us avoid #3 above, without having to code up the same
__init functions and device_initcall() boilerplate.
For non modular code, module_init becomes __initcall. But direct use
of __initcall is discouraged, vs. one of the priority categorized
subgroups. As __initcall gets mapped onto device_initcall, our
use of device_initcall directly in this change means that the
runtime impact is zero -- drivers will remain at level 6 in the
initcall ordering.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 5b00c1eb94e5936e5bf5cdd9ad1ddfbed0c39159
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 21:57:34 2015 -0400
x86: perf_event_intel_pt.c: use arch_initcall to hook in enabling
This was using module_init, but the current Kconfig situation is
as follows:
In arch/x86/kernel/cpu/Makefile:
obj-$(CONFIG_CPU_SUP_INTEL) += perf_event_intel_pt.o perf_event_intel_bts.o
and in arch/x86/Kconfig.cpu:
config CPU_SUP_INTEL
default y
bool "Support Intel processors" if PROCESSOR_SELECT
So currently, the end user can not build this code into a module.
If in the future, there is desire for this to be modular, then
it can be changed to include <linux/module.h> and use module_init.
But currently, in the non-modular case, a module_init becomes a
device_initcall. But this really isn't a device, so we should
choose a more appropriate initcall bucket to put it in.
The obvious choice here seems to be arch_initcall, but that does
make it earlier than it was currently through device_initcall.
As long as perf_pmu_register() is functional, we should be OK.
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit ca41d24cf56458a699b44e918c5a19b7077df422
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 21:57:34 2015 -0400
x86: perf_event_intel_bts.c: use arch_initcall to hook in enabling
This was using module_init, but the current Kconfig situation is
as follows:
In arch/x86/kernel/cpu/Makefile:
obj-$(CONFIG_CPU_SUP_INTEL) += perf_event_intel_pt.o perf_event_intel_bts.o
and in arch/x86/Kconfig.cpu:
config CPU_SUP_INTEL
default y
bool "Support Intel processors" if PROCESSOR_SELECT
So currently, the end user can not build this code into a module.
If in the future, there is desire for this to be modular, then
it can be changed to include <linux/module.h> and use module_init.
But currently, in the non-modular case, a module_init becomes a
device_initcall. But this really isn't a device, so we should
choose a more appropriate initcall bucket to put it in.
The obvious choice here seems to be arch_initcall, but that does
make it earlier than it was currently through device_initcall.
As long as perf_pmu_register() is functional, we should be OK.
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 44c5af96de8230ff7268500f48995f9fea5cffe7
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 21:57:34 2015 -0400
mm/page_owner.c: use late_initcall to hook in enabling
This was using module_init, but there is no way this code can
be modular. In the non-modular case, a module_init becomes a
device_initcall, but this really isn't a device. So we should
choose a more appropriate initcall bucket to put it in.
In order of execution, our close choices are:
fs_initcall(fn)
rootfs_initcall(fn)
device_initcall(fn)
late_initcall(fn)
..and since the initcall here goes after debugfs, we really
should be post-rootfs, which means late_initcall makes the
most sense here.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 4c7217f1f0fe70af7b9e213ef16f1d2f4a4bacaf
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 21:57:34 2015 -0400
lib/list_sort: use late_initcall to hook in self tests
This was using module_init, but there is no way this code can
be modular. In the non-modular case, a module_init becomes a
device_initcall, but this really isn't a device. So we should
choose a more appropriate initcall bucket to put it in.
Assuming boot time self tests need to be observed over a console
to be useful, and that the console device could possibly not be
fully functional until after device_initcall, we move this to the
late_initcall bucket, which is immediately after device_initcall.
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 89f08f64408b630df7d559223f63e616d0814509
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:08:21 2015 -0400
arm: use subsys_initcall in non-modular pl320 IPC code
The drivers/mailbox/pl320-ipc.o is dependent on config PL320_MBOX
which is declared as a bool. Hence the code is never going to be
modular. So using module_init as an alias for __initcall can be
somewhat misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing. Also add an inclusion of init.h, as
that was previously implicit.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of subsys_initcall (which
seems to make sense for IPC code) will thus change this
registration from level 6-device to level 4-subsys (i.e. slightly
earlier). However no impact of that small difference is expected.
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 6f114281c4ad543392f5b7c8345e11e103675cee
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:08:21 2015 -0400
powerpc: don't use module_init for non-modular core hugetlb code
The hugetlbpage.o is obj-y (always built in). It will never
be modular, so using module_init as an alias for __initcall is
somewhat misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of arch_initcall (which
makes sense for arch code) will thus change this registration
from level 6-device to level 3-arch (i.e. slightly earlier).
However no observable impact of that small difference has
been observed during testing, or is expected.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 383d14a5365879bc193d29ad2ed17ac5299753c3
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:08:21 2015 -0400
powerpc: use subsys_initcall for Freescale Local Bus
The FSL_SOC option is bool, and hence this code is either
present or absent. It will never be modular, so using
module_init as an alias for __initcall is rather misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of subsys_initcall (which
makes sense for bus code) will thus change this registration
from level 6-device to level 4-subsys (i.e. slightly earlier).
However no observable impact of that small difference has
been observed during testing, or is expected.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Scott Wood <scottwood@freescale.com>
Acked-by: Scott Wood <scottwood@freescale.com>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 1206f53589237b7e00b9b0a4e42815f14aedad2d
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:08:21 2015 -0400
x86: don't use module_init for non-modular core bootflag code
The bootflag.o is obj-y (always built in). It will never be
modular, so using module_init as an alias for __initcall is
somewhat misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of arch_initcall (which
makes sense for arch code) will thus change this registration
from level 6-device to level 3-arch (i.e. slightly earlier).
However no observable impact of that small difference has
been observed during testing, or is expected.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 55331060096f0e9a57356ec36476a49e4bf22bc1
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:08:20 2015 -0400
netfilter: don't use module_init/exit in core IPV4 code
The file net/ipv4/netfilter.o is created based on whether
CONFIG_NETFILTER is set. However that is defined as a bool, and
hence this file with the core netfilter hooks will never be
modular. So using module_init as an alias for __initcall can be
somewhat misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing. Also add an inclusion of init.h, as
that was previously implicit here in the netfilter.c file.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of subsys_initcall (which
seems to make sense for netfilter code) will thus change this
registration from level 6-device to level 4-subsys (i.e. slightly
earlier). However no observable impact of that small difference
has been observed during testing, or is expected. (i.e. the
location of the netfilter messages in dmesg remains unchanged
with respect to all the other surrounding messages.)
As for the module_exit, rather than replace it with __exitcall,
we simply remove it, since it appears only UML does anything
with those, and even for UML, there is no relevant cleanup
to be done here.
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netfilter-devel@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit c013d5a4581203e074a1065e17378984544fcaef
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:08:20 2015 -0400
fs/notify: don't use module_init for non-modular inotify_user code
The INOTIFY_USER option is bool, and hence this code is either
present or absent. It will never be modular, so using
module_init as an alias for __initcall is rather misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of fs_initcall (which
makes sense for fs code) will thus change this registration
from level 6-device to level 5-fs (i.e. slightly earlier).
However no observable impact of that small difference has
been observed during testing, or is expected.
Cc: John McCutchan <john@johnmccutchan.com>
Cc: Robert Love <rlove@rlove.org>
Cc: Eric Paris <eparis@parisplace.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit a4bc6fc79f94c5b4f850aabca9c5249adc597094
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:08:20 2015 -0400
mm: replace module_init usages with subsys_initcall in nommu.c
Compiling some arm/m68k configs with "# CONFIG_MMU is not set" reveals
two more instances of module_init being used for code that can't
possibly be modular, as CONFIG_MMU is either on or off.
We replace them with subsys_initcall as per what was done in other
mmu-enabled code.
Note that direct use of __initcall is discouraged, vs. one of the
priority categorized subgroups. As __initcall gets mapped onto
device_initcall, our use of subsys_initcall (which makes sense for these
files) will thus change this registration from level 6-device to level
4-subsys (i.e. slightly earlier).
One might think that core_initcall (l2) or postcore_initcall (l3) would
be more appropriate for anything in mm/ but if we look at the actual init
functions themselves, we see they are just sysctl setup stuff, and
hence the choice of subsys_initcall (l4) seems reasonable. At the same
time it minimizes the risk of changing the priority too drastically all
at once. We can adjust further in the future.
Also, a couple instances of missing ";" at EOL are fixed.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 84c3e5bf1defc035d63869bbb0f5f80d276c1fc7
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Sun Jun 14 16:55:25 2015 -0400
cris: don't use module_init for non-modular core eeprom.c code
The eeprom.c code is compiled based on the Kconfig setting
ETRAX_I2C_EEPROM, which is bool. So the code is either built in
or absent. It will never be modular, so using module_init as an
alias for __initcall is rather misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Direct use of __initcall is discouraged, vs prioritized ones.
Use of device_initcall is consistent with what __initcall
maps onto, and hence does not change the init order, making the
impact of this change zero. Should someone with real hardware
for boot testing want to change it later to arch_initcall or
something different, they can do that at a later date.
Cc: Mikael Starvik <starvik@axis.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: linux-cris-kernel@axis.com
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 4d38e5c48f4095be21343869ad741676ab4e518f
Author: James Hogan <james.hogan@imgtec.com>
Date: Fri Jun 5 22:17:18 2015 +0100
tty/metag_da: Avoid module_init/module_exit in non-modular code
The metag_da TTY driver can't get built as a module at the moment, but
it still uses module_init() and module_exit(). Those macros are moving
to module.h which isn't included by metag_da.c, which will result in the
following build warnings (remarkably no build errors) and an apparent
failure to boot as the TTY driver won't be loaded.
drivers/tty/metag_da.c:660: warning: data definition has no type or storage class
drivers/tty/metag_da.c:660: warning: type defaults to ‘int’ in declaration of ‘module_init’
drivers/tty/metag_da.c:660: warning: parameter names (without types) in function declaration
drivers/tty/metag_da.c:661: warning: data definition has no type or storage class
drivers/tty/metag_da.c:661: warning: type defaults to ‘int’ in declaration of ‘module_exit’
drivers/tty/metag_da.c:661: warning: parameter names (without types) in function declaration
drivers/tty/metag_da.c:572: warning: ‘dashtty_init’ defined but not used
drivers/tty/metag_da.c:645: warning: ‘dashtty_exit’ defined but not used
drivers/tty/metag_da.c In function ‘dash_console_write’:
drivers/tty/metag_da.c:670 : warning: passing argument 4 of ‘chancall’ discards qualifiers from pointer target type
Instead of just adding the module.h include, now would be a good time to
remove the use of these macros, replacing the module_init with
device_initcall, and removing the exit function altogether since it
isn't needed. If module support is added later the code can always be
resurrected.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: linux-metag@vger.kernel.org
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 791ed0bb5558dfdc4040563bd0b7dc24450fa732
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:05:51 2015 -0400
drivers/clk: don't use module_init in clk-nomadik.c which is non-modular
The clk-nomadik.o is built for ARCH_NOMADIK -- which is bool, and
hence this code is either present or absent. It will never be
modular, so using module_init as an alias for __initcall can be
somewhat misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of device_initcall
directly in this change means that the runtime impact is
zero -- it will remain at level 6 in initcall ordering.
Cc: Mike Turquette <mturquette@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 30e3c6428f18b5b8e78602a5a7cc653aee3bfe99
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:05:50 2015 -0400
xtensa: don't use module_init for non-modular core network.c code
The network.c code is piggybacking off of the arch independent
CONFIG_NET, which is bool. So the code is either built in or
absent. It will never be modular, so using module_init as an
alias for __initcall is rather misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Direct use of __initcall is discouraged, vs prioritized ones.
Use of device_initcall is consistent with what __initcall
maps onto, and hence does not change the init order, making the
impact of this change zero. Should someone with real hardware
for boot testing want to change it later to arch_initcall or
something different, they can do that at a later date.
Cc: Chris Zankel <chris@zankel.net>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: Thomas Meyer <thomas@m3y3r.de>
Cc: linux-xtensa@linux-xtensa.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit b205118bdb4b515b4b4f5058aa9f5a12668386c3
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:05:50 2015 -0400
sh: don't use module_init in non-modular psw.c code
The psw.o is built for obj-y -- and hence this code is always
present. It will never be modular, so using module_init as an alias
for __initcall can be somewhat misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of device_initcall
directly in this change means that the runtime impact is
zero -- it will remain at level 6 in initcall ordering.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: linux-sh@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 1b4d5beecbeb4608a0fdb77c3b8ba182f0cfb4b6
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:05:50 2015 -0400
mn10300: don't use module_init in non-modular flash.c code
The flash.o is built for obj-y -- and hence this code is always
present. It will never be modular, so using module_init as an alias
for __initcall can be somewhat misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of device_initcall
directly in this change means that the runtime impact is
zero -- it will remain at level 6 in initcall ordering.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: David Howells <dhowells@redhat.com>
Acked-by: David Howells <dhowells@redhat.com>
Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
Cc: linux-am33-list@redhat.com
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 15becabd89fa3fec6aa864fbd1b50b5b1871eee2
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:05:50 2015 -0400
parisc64: don't use module_init for non-modular core perf code
The perf.c code depends on CONFIG_64BIT, so it is either built-in
or absent. It will never be modular, so using module_init as an
alias for __initcall is rather misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing. Aside from it not making sense, it also
causes a ~10% increase in CPP overhead due to module.h having a
large list of headers itself -- for example compare line counts:
device_initcall() and <linux/init.h>
20238 arch/parisc/kernel/perf.i
module_init() and <linux/module.h>
22194 arch/parisc/kernel/perf.i
Direct use of __initcall is discouraged, vs prioritized ones.
Use of device_initcall is consistent with what __initcall
maps onto, and hence does not change the init order, making the
impact of this change zero. Should someone with real hardware
for boot testing want to change it later to arch_initcall or
something different, they can do that at a later date.
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: Helge Deller <deller@gmx.de>
Cc: linux-parisc@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit aed6850a1390c2b208b91b2fae0199fc14b94a26
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:05:50 2015 -0400
parisc: don't use module_init for non-modular core pdc_cons code
The pdc_cons.c code is always built in. It will never be modular,
so using module_init as an alias for __initcall is rather
misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Direct use of __initcall is discouraged, vs prioritized ones.
Use of device_initcall is consistent with what __initcall
maps onto, and hence does not change the init order, making the
impact of this change zero. Should someone with real hardware
for boot testing want to change it later to arch_initcall or
something different, they can do that at a later date.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: Helge Deller <deller@gmx.de>
Cc: linux-parisc@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 73de14e8cdc733bbc8eda006f813d5aa51511139
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:05:50 2015 -0400
cris: don't use module_init for non-modular core intmem.c code
The intmem.c code is always built in. It will never be modular,
so using module_init as an alias for __initcall is rather
misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Direct use of __initcall is discouraged, vs prioritized ones.
Use of device_initcall is consistent with what __initcall
maps onto, and hence does not change the init order, making the
impact of this change zero. Should someone with real hardware
for boot testing want to change it later to arch_initcall or
something different, they can do that at a later date.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Mikael Starvik <starvik@axis.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: linux-cris-kernel@axis.com
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 2a177fd1d92f669f8f493a61e195ff4e3c50f95f
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:05:50 2015 -0400
ia64: don't use module_init in non-modular sim/simscsi.c code
The simscsi.o is built for HP_SIMSCSI -- which is bool, and hence
this code is either present or absent. It will never be modular,
so using module_init as an alias for __initcall can be somewhat
misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of device_initcall
directly in this change means that the runtime impact is
zero -- it will remain at level 6 in initcall ordering.
And since it can't be modular, we remove all the __exitcall
stuff related to module_exit() -- it is dead code that won't
ever be executed.
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: linux-ia64@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 2e21fa2d11ab61e1827bd5bb1e0e2484931d68e1
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:05:49 2015 -0400
ia64: don't use module_init for non-modular core kernel/mca.c code
The mca.c code is always built in. It will never be modular,
so using module_init as an alias for __initcall is rather
misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Direct use of __initcall is discouraged, vs prioritized ones.
Use of device_initcall is consistent with what __initcall
maps onto, and hence does not change the init order, making the
impact of this change zero. Should someone with real hardware
for boot testing want to change it later to arch_initcall or
something different, they can do that at a later date.
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: linux-ia64@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 4a0ece7ceceab251e92e7f98e7926642a065727b
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:05:49 2015 -0400
arm: don't use module_init in non-modular mach-vexpress/spc.c code
The spc.o is built for ARCH_VEXPRESS_SPC -- which is bool, and hence
this code is either present or absent. It will never be modular,
so using module_init as an alias for __initcall can be somewhat
misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of device_initcall
directly in this change means that the runtime impact is
zero -- it will remain at level 6 in initcall ordering.
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit a390a2f18147533359d4e45cb13438d42580da84
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:05:49 2015 -0400
powerpc: don't use module_init in non-modular 83xx suspend code
The suspend.o is built for SUSPEND -- which is bool, and hence
this code is either present or absent. It will never be modular,
so using module_init as an alias for __initcall can be somewhat
misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of device_initcall
directly in this change means that the runtime impact is
zero -- it will remain at level 6 in initcall ordering.
Cc: Scott Wood <scottwood@freescale.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 8f6b9512ceadc6bd52777c299111dc642b4c65b6
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:05:49 2015 -0400
powerpc: use device_initcall for registering rtc devices
Currently these two RTC devices are in core platform code
where it is not possible for them to be modular. It will
never be modular, so using module_init as an alias for
__initcall can be somewhat misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of device_initcall
directly in this change means that the runtime impact is
zero -- they will remain at level 6 in initcall ordering.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Geoff Levand <geoff@infradead.org>
Acked-by: Geoff Levand <geoff@infradead.org>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit d54b675a6b0007422dc13acbecdb1ca2b1a53aeb
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:05:49 2015 -0400
x86: don't use module_init in non-modular devicetree.c code
The devicetree.o is built for "OF" -- which is bool, and hence
this code is either present or absent. It will never be modular,
so using module_init as an alias for __initcall can be somewhat
misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of device_initcall
directly in this change means that the runtime impact is
zero -- it will remain at level 6 in initcall ordering.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 4711e2f9caedaa07e7cdcb5e058a18762d6be9b1
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:05:49 2015 -0400
x86: don't use module_init in non-modular intel_mid_vrtc.c
The X86_INTEL_MID option is bool, and hence this code is either
present or absent. It will never be modular, so using
module_init as an alias for __initcall is rather misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of device_initcall
directly in this change means that the runtime impact is
zero -- it will remain at level 6 in initcall ordering.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 7cac34370a4dde12e6430c2f0985926d4ef0f459
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri Jun 5 11:25:18 2015 -0400
frv: add module.h to mb93090-mb00/flash.c to avoid compile fail
This file is built off of a tristate Kconfig option and also contains
modular function calls so it should explicitly include module.h to
avoid compile breakage during header shuffles done in the future.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 743492ccd53008736f169f242479bac6245f8379
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Wed Jun 3 15:45:21 2015 -0400
drivers/cpufreq: include <module.h> for modular exynos-cpufreq.c code
This file is built off of a tristate Kconfig option ("ARM_EXYNOS_CPUFREQ")
and also contains modular function calls so it should explicitly include
module.h to avoid compile breakage during pending header shuffles.
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit a7e9bc55cc144dc40e809e579bd932ef2ec324de
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:02:31 2015 -0400
drivers/staging: include <module.h> for modular android tegra_ion code
This file is built off of a tristate Kconfig option and also contains
modular function calls so it should explicitly include module.h to
avoid compile breakage during header shuffles done in the future.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Arve Hj�nnev�g" <arve@android.com>
Cc: Riley Andrews <riandrews@android.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: devel@driverdev.osuosl.org
Cc: linux-tegra@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 88775588b71d28a9020a7faa4ad95bbf76d8bb45
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 21:29:53 2015 -0400
crypto/asymmetric_keys: pkcs7_key_type needs module.h
This driver builds off of the tristate CONFIG_PKCS7_TEST_KEY and calls
module_init and module_exit. So it should explicitly include module.h
to avoid compile breakage during header shuffles done in the future.
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 0bbad249a6a4934203b50d574f5d5f9f480b389e
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:02:31 2015 -0400
sh: mach-highlander/psw.c is tristate and should use module.h
This file is controlled by a tristate Kconfig option, and hence
needs to include module.h so that it can get module_init() once
we relocate it from init.h into module.h in the future.
Note that module_exit() appears to be missing from the driver, so
it is questionable whether it would actually work for a removal
and reload cycle if it was configured for a modular build.
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: linux-sh@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit ca1c8e93c37e5a5e27e6149cd3612eb2247e0e4a
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:02:31 2015 -0400
drivers/regulator: include <module.h> for modular max77802 code
This file is built off of a tristate Kconfig option and also contains
modular function calls so it should explicitly include module.h to
avoid compile breakage during header shuffles done in the future.
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 5468f887bc861b2fe2fa24a44bc6a616a5d33a73
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:02:31 2015 -0400
drivers/pcmcia: include <module.h> for modular xxs1500_ss code
This file is built off of a tristate Kconfig option and also contains
modular function calls so it should explicitly include module.h to
avoid compile breakage during header shuffles done in the future.
Cc: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-pcmcia@lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit a1a0bec593623f49740d7900e4b862c534f219bf
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:02:30 2015 -0400
drivers/hsi: include <module.h> for modular omap_ssi code
These files are built off of a tristate Kconfig option and also contain
modular function calls so they should explicitly include module.h to
avoid compile breakage during header shuffles done in the future.
We change the one header file wich gives us coverage on both files:
drivers/hsi/controllers/omap_ssi.c
drivers/hsi/controllers/omap_ssi_port.c
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
commit 00fe614863eed7ca39fc72a307c6dff57b690476
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri May 1 20:02:30 2015 -0400
drivers/gpu: in…
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Oct 18, 2015
WARNING: 'happend' may be misspelled - perhaps 'happened'? torvalds#79: FILE: Documentation/kasan.txt:121: +The header of the report discribe what kind of bug happend and what kind of total: 0 errors, 1 warnings, 82 lines checked ./patches/kasan-various-fixes-in-documentation.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Oct 21, 2015
WARNING: 'happend' may be misspelled - perhaps 'happened'? torvalds#79: FILE: Documentation/kasan.txt:121: +The header of the report discribe what kind of bug happend and what kind of total: 0 errors, 1 warnings, 82 lines checked ./patches/kasan-various-fixes-in-documentation.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Oct 22, 2015
WARNING: 'happend' may be misspelled - perhaps 'happened'? torvalds#79: FILE: Documentation/kasan.txt:121: +The header of the report discribe what kind of bug happend and what kind of total: 0 errors, 1 warnings, 82 lines checked ./patches/kasan-various-fixes-in-documentation.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
nhoriguchi
pushed a commit
to nhoriguchi/linux
that referenced
this pull request
Oct 30, 2015
WARNING: 'happend' may be misspelled - perhaps 'happened'? torvalds#79: FILE: Documentation/kasan.txt:121: +The header of the report discribe what kind of bug happend and what kind of total: 0 errors, 1 warnings, 82 lines checked ./patches/kasan-various-fixes-in-documentation.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Feb 1, 2016
When using a 5G-capable device with VHT rates enabled, the following warning results: WARNING: CPU: 3 PID: 2253 at net/mac80211/rate.c:625 ieee80211_get_tx_rates+0x22e/0x620 [mac80211]() Modules linked in: rtl8821ae btcoexist rtl_pci rtlwifi fuse drbg ansi_cprng ctr ccm bnep bluetooth af_packet nfs fscache vboxpci(O) vboxnetadp(O) vboxne tflt(O) vboxdrv(O) arc4 snd_hda_codec_generic x86_pkg_temp_thermal rtsx_pci_sdmmc mmc_core rtsx_pci_ms kvm_intel memstick iwlmvm kvm mac80211 snd_hda_intel snd_hda_cod ec snd_hwdep snd_hda_core irqbypass snd_pcm iwlwifi crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 snd_timer lrw gf128mul glue_h elper ablk_helper cryptd snd cfg80211 pcspkr serio_raw e1000e rtsx_pci lpc_ich ptp xhci_pci mfd_core pps_core xhci_hcd soundcore toshiba_acpi thermal sparse_keymap wmi toshiba_bluetooth rfkill acpi_cpufreq battery ac processor dm_mod i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm sr_mod cdrom video button sg autofs4 [last unloaded: rtlwifi] CPU: 3 PID: 2253 Comm: Timer Tainted: G W O 4.5.0-rc1-wl+ torvalds#79 Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.20 04/17/2014 ffffffffa05c4be6 ffff8802262036d8 ffffffff813d7912 0000000000000000 ffff880226203710 ffffffff8106bcb6 ffff8800c6831300 ffff8800c6831330 0000000000000000 ffff8800c683133c ffff880065923638 ffff880226203720 Call Trace: <IRQ> [<ffffffff813d7912>] dump_stack+0x4b/0x79 [<ffffffff8106bcb6>] warn_slowpath_common+0x86/0xc0 [<ffffffff8106bdaa>] warn_slowpath_null+0x1a/0x20 [<ffffffffa05511ee>] ieee80211_get_tx_rates+0x22e/0x620 [mac80211] [<ffffffffa0782232>] ? rtl_is_special_data+0x32/0x240 [rtlwifi] [<ffffffffa055209e>] ? rate_control_get_rate+0xce/0x150 [mac80211] [<ffffffff810bfc7d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff81071cc5>] ? __local_bh_enable_ip+0x65/0xd0
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Feb 8, 2016
When using a 5G-capable device with VHT (802.11ac) rates enabled was not working (packets were not delivered) and the following mac80211 warning was printed: WARNING: CPU: 3 PID: 2253 at net/mac80211/rate.c:625 ieee80211_get_tx_rates+0x22e/0x620 [mac80211]() Modules linked in: rtl8821ae btcoexist rtl_pci rtlwifi fuse drbg ansi_cprng ctr ccm bnep bluetooth af_packet nfs fscache vboxpci(O) vboxnetadp(O) vboxne tflt(O) vboxdrv(O) arc4 snd_hda_codec_generic x86_pkg_temp_thermal rtsx_pci_sdmmc mmc_core rtsx_pci_ms kvm_intel memstick iwlmvm kvm mac80211 snd_hda_intel snd_hda_cod ec snd_hwdep snd_hda_core irqbypass snd_pcm iwlwifi crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 snd_timer lrw gf128mul glue_h elper ablk_helper cryptd snd cfg80211 pcspkr serio_raw e1000e rtsx_pci lpc_ich ptp xhci_pci mfd_core pps_core xhci_hcd soundcore toshiba_acpi thermal sparse_keymap wmi toshiba_bluetooth rfkill acpi_cpufreq battery ac processor dm_mod i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm sr_mod cdrom video button sg autofs4 [last unloaded: rtlwifi] CPU: 3 PID: 2253 Comm: Timer Tainted: G W O 4.5.0-rc1-wl+ torvalds#79 Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.20 04/17/2014 ffffffffa05c4be6 ffff8802262036d8 ffffffff813d7912 0000000000000000 ffff880226203710 ffffffff8106bcb6 ffff8800c6831300 ffff8800c6831330 0000000000000000 ffff8800c683133c ffff880065923638 ffff880226203720 Call Trace: <IRQ> [<ffffffff813d7912>] dump_stack+0x4b/0x79 [<ffffffff8106bcb6>] warn_slowpath_common+0x86/0xc0 [<ffffffff8106bdaa>] warn_slowpath_null+0x1a/0x20 [<ffffffffa05511ee>] ieee80211_get_tx_rates+0x22e/0x620 [mac80211] [<ffffffffa0782232>] ? rtl_is_special_data+0x32/0x240 [rtlwifi] [<ffffffffa055209e>] ? rate_control_get_rate+0xce/0x150 [mac80211] [<ffffffff810bfc7d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff81071cc5>] ? __local_bh_enable_ip+0x65/0xd0 Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
May 24, 2016
…patch-fixes WARNING: Missing a blank line after declarations torvalds#34: FILE: include/linux/page_idle.h:50: + struct page_ext *page_ext; + page_ext = lookup_page_ext(page); WARNING: Missing a blank line after declarations torvalds#45: FILE: include/linux/page_idle.h:60: + struct page_ext *page_ext; + page_ext = lookup_page_ext(page); WARNING: Missing a blank line after declarations torvalds#57: FILE: include/linux/page_idle.h:70: + struct page_ext *page_ext; + page_ext = lookup_page_ext(page); WARNING: Missing a blank line after declarations torvalds#68: FILE: include/linux/page_idle.h:80: + struct page_ext *page_ext; + page_ext = lookup_page_ext(page); WARNING: Missing a blank line after declarations torvalds#79: FILE: include/linux/page_idle.h:90: + struct page_ext *page_ext; + page_ext = lookup_page_ext(page); WARNING: Missing a blank line after declarations torvalds#90: FILE: include/linux/page_idle.h:100: + struct page_ext *page_ext; + page_ext = lookup_page_ext(page); total: 1 errors, 6 warnings, 196 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-check-the-return-value-of-lookup_page_ext-for-all-call-sites.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Yang Shi <yang.shi@linaro.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
May 27, 2016
…patch-fixes WARNING: Missing a blank line after declarations torvalds#34: FILE: include/linux/page_idle.h:50: + struct page_ext *page_ext; + page_ext = lookup_page_ext(page); WARNING: Missing a blank line after declarations torvalds#45: FILE: include/linux/page_idle.h:60: + struct page_ext *page_ext; + page_ext = lookup_page_ext(page); WARNING: Missing a blank line after declarations torvalds#57: FILE: include/linux/page_idle.h:70: + struct page_ext *page_ext; + page_ext = lookup_page_ext(page); WARNING: Missing a blank line after declarations torvalds#68: FILE: include/linux/page_idle.h:80: + struct page_ext *page_ext; + page_ext = lookup_page_ext(page); WARNING: Missing a blank line after declarations torvalds#79: FILE: include/linux/page_idle.h:90: + struct page_ext *page_ext; + page_ext = lookup_page_ext(page); WARNING: Missing a blank line after declarations torvalds#90: FILE: include/linux/page_idle.h:100: + struct page_ext *page_ext; + page_ext = lookup_page_ext(page); total: 1 errors, 6 warnings, 196 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-check-the-return-value-of-lookup_page_ext-for-all-call-sites.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Yang Shi <yang.shi@linaro.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 2, 2017
__skb_flow_dissect can be called with a skb or a data packet, either can be NULL. All calls seems to have been moved to __skb_header_pointer except the pptp handling which is still calling skb_header_pointer. skb_header_pointer will use skb->data and thus: [ 109.556866] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080 [ 109.557102] IP: [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0 [ 109.557263] PGD 0 [ 109.557338] [ 109.557484] Oops: 0000 [#1] SMP [ 109.557562] Modules linked in: chaoskey [ 109.557783] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0 torvalds#79 [ 109.557867] Hardware name: Supermicro A1SRM-LN7F/LN5F/A1SRM-LN7F-2758, BIOS 1.0c 11/04/2015 [ 109.557957] task: ffff94085c27bc00 task.stack: ffffb745c0068000 [ 109.558041] RIP: 0010:[<ffffffff88dc02f8>] [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0 [ 109.558203] RSP: 0018:ffff94087fc83d40 EFLAGS: 00010206 [ 109.558286] RAX: 0000000000000130 RBX: ffffffff8975bf80 RCX: ffff94084fab6800 [ 109.558373] RDX: 0000000000000010 RSI: 000000000000000c RDI: 0000000000000000 [ 109.558460] RBP: 0000000000000b88 R08: 0000000000000000 R09: 0000000000000022 [ 109.558547] R10: 0000000000000008 R11: ffff94087fc83e04 R12: 0000000000000000 [ 109.558763] R13: ffff94084fab6800 R14: ffff94087fc83e04 R15: 000000000000002f [ 109.558979] FS: 0000000000000000(0000) GS:ffff94087fc80000(0000) knlGS:0000000000000000 [ 109.559326] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 109.559539] CR2: 0000000000000080 CR3: 0000000281809000 CR4: 00000000001026e0 [ 109.559753] Stack: [ 109.559957] 000000000000000c ffff94084fab6822 0000000000000001 ffff94085c2b5fc0 [ 109.560578] 0000000000000001 0000000000002000 0000000000000000 0000000000000000 [ 109.561200] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 109.561820] Call Trace: [ 109.562027] <IRQ> [ 109.562108] [<ffffffff88dfb4fa>] ? eth_get_headlen+0x7a/0xf0 [ 109.562522] [<ffffffff88c5a35a>] ? igb_poll+0x96a/0xe80 [ 109.562737] [<ffffffff88dc912b>] ? net_rx_action+0x20b/0x350 [ 109.562953] [<ffffffff88546d68>] ? __do_softirq+0xe8/0x280 [ 109.563169] [<ffffffff8854704a>] ? irq_exit+0xaa/0xb0 [ 109.563382] [<ffffffff8847229b>] ? do_IRQ+0x4b/0xc0 [ 109.563597] [<ffffffff8902d4ff>] ? common_interrupt+0x7f/0x7f [ 109.563810] <EOI> [ 109.563890] [<ffffffff88d57530>] ? cpuidle_enter_state+0x130/0x2c0 [ 109.564304] [<ffffffff88d57520>] ? cpuidle_enter_state+0x120/0x2c0 [ 109.564520] [<ffffffff8857eacf>] ? cpu_startup_entry+0x19f/0x1f0 [ 109.564737] [<ffffffff8848d55a>] ? start_secondary+0x12a/0x140 [ 109.564950] Code: 83 e2 20 a8 80 0f 84 60 01 00 00 c7 04 24 08 00 00 00 66 85 d2 0f 84 be fe ff ff e9 69 fe ff ff 8b 34 24 89 f2 83 c2 04 66 85 c0 <41> 8b 84 24 80 00 00 00 0f 49 d6 41 8d 31 01 d6 41 2b 84 24 84 [ 109.569959] RIP [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0 [ 109.570245] RSP <ffff94087fc83d40> [ 109.570453] CR2: 0000000000000080 Fixes: ab10dcc ("rps: Inspect PPTP encapsulated by GRE to get flow hash") Signed-off-by: Ian Kumlien <ian.kumlien@gmail.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 2, 2017
__skb_flow_dissect can be called with a skb or a data packet, either can be NULL. All calls seems to have been moved to __skb_header_pointer except the pptp handling which is still calling skb_header_pointer. skb_header_pointer will use skb->data and thus: [ 109.556866] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080 [ 109.557102] IP: [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0 [ 109.557263] PGD 0 [ 109.557338] [ 109.557484] Oops: 0000 [#1] SMP [ 109.557562] Modules linked in: chaoskey [ 109.557783] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0 torvalds#79 [ 109.557867] Hardware name: Supermicro A1SRM-LN7F/LN5F/A1SRM-LN7F-2758, BIOS 1.0c 11/04/2015 [ 109.557957] task: ffff94085c27bc00 task.stack: ffffb745c0068000 [ 109.558041] RIP: 0010:[<ffffffff88dc02f8>] [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0 [ 109.558203] RSP: 0018:ffff94087fc83d40 EFLAGS: 00010206 [ 109.558286] RAX: 0000000000000130 RBX: ffffffff8975bf80 RCX: ffff94084fab6800 [ 109.558373] RDX: 0000000000000010 RSI: 000000000000000c RDI: 0000000000000000 [ 109.558460] RBP: 0000000000000b88 R08: 0000000000000000 R09: 0000000000000022 [ 109.558547] R10: 0000000000000008 R11: ffff94087fc83e04 R12: 0000000000000000 [ 109.558763] R13: ffff94084fab6800 R14: ffff94087fc83e04 R15: 000000000000002f [ 109.558979] FS: 0000000000000000(0000) GS:ffff94087fc80000(0000) knlGS:0000000000000000 [ 109.559326] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 109.559539] CR2: 0000000000000080 CR3: 0000000281809000 CR4: 00000000001026e0 [ 109.559753] Stack: [ 109.559957] 000000000000000c ffff94084fab6822 0000000000000001 ffff94085c2b5fc0 [ 109.560578] 0000000000000001 0000000000002000 0000000000000000 0000000000000000 [ 109.561200] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 109.561820] Call Trace: [ 109.562027] <IRQ> [ 109.562108] [<ffffffff88dfb4fa>] ? eth_get_headlen+0x7a/0xf0 [ 109.562522] [<ffffffff88c5a35a>] ? igb_poll+0x96a/0xe80 [ 109.562737] [<ffffffff88dc912b>] ? net_rx_action+0x20b/0x350 [ 109.562953] [<ffffffff88546d68>] ? __do_softirq+0xe8/0x280 [ 109.563169] [<ffffffff8854704a>] ? irq_exit+0xaa/0xb0 [ 109.563382] [<ffffffff8847229b>] ? do_IRQ+0x4b/0xc0 [ 109.563597] [<ffffffff8902d4ff>] ? common_interrupt+0x7f/0x7f [ 109.563810] <EOI> [ 109.563890] [<ffffffff88d57530>] ? cpuidle_enter_state+0x130/0x2c0 [ 109.564304] [<ffffffff88d57520>] ? cpuidle_enter_state+0x120/0x2c0 [ 109.564520] [<ffffffff8857eacf>] ? cpu_startup_entry+0x19f/0x1f0 [ 109.564737] [<ffffffff8848d55a>] ? start_secondary+0x12a/0x140 [ 109.564950] Code: 83 e2 20 a8 80 0f 84 60 01 00 00 c7 04 24 08 00 00 00 66 85 d2 0f 84 be fe ff ff e9 69 fe ff ff 8b 34 24 89 f2 83 c2 04 66 85 c0 <41> 8b 84 24 80 00 00 00 0f 49 d6 41 8d 31 01 d6 41 2b 84 24 84 [ 109.569959] RIP [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0 [ 109.570245] RSP <ffff94087fc83d40> [ 109.570453] CR2: 0000000000000080 Fixes: ab10dcc ("rps: Inspect PPTP encapsulated by GRE to get flow hash") Signed-off-by: Ian Kumlien <ian.kumlien@gmail.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 3, 2017
__skb_flow_dissect can be called with a skb or a data packet, either can be NULL. All calls seems to have been moved to __skb_header_pointer except the pptp handling which is still calling skb_header_pointer. skb_header_pointer will use skb->data and thus: [ 109.556866] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080 [ 109.557102] IP: [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0 [ 109.557263] PGD 0 [ 109.557338] [ 109.557484] Oops: 0000 [#1] SMP [ 109.557562] Modules linked in: chaoskey [ 109.557783] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0 torvalds#79 [ 109.557867] Hardware name: Supermicro A1SRM-LN7F/LN5F/A1SRM-LN7F-2758, BIOS 1.0c 11/04/2015 [ 109.557957] task: ffff94085c27bc00 task.stack: ffffb745c0068000 [ 109.558041] RIP: 0010:[<ffffffff88dc02f8>] [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0 [ 109.558203] RSP: 0018:ffff94087fc83d40 EFLAGS: 00010206 [ 109.558286] RAX: 0000000000000130 RBX: ffffffff8975bf80 RCX: ffff94084fab6800 [ 109.558373] RDX: 0000000000000010 RSI: 000000000000000c RDI: 0000000000000000 [ 109.558460] RBP: 0000000000000b88 R08: 0000000000000000 R09: 0000000000000022 [ 109.558547] R10: 0000000000000008 R11: ffff94087fc83e04 R12: 0000000000000000 [ 109.558763] R13: ffff94084fab6800 R14: ffff94087fc83e04 R15: 000000000000002f [ 109.558979] FS: 0000000000000000(0000) GS:ffff94087fc80000(0000) knlGS:0000000000000000 [ 109.559326] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 109.559539] CR2: 0000000000000080 CR3: 0000000281809000 CR4: 00000000001026e0 [ 109.559753] Stack: [ 109.559957] 000000000000000c ffff94084fab6822 0000000000000001 ffff94085c2b5fc0 [ 109.560578] 0000000000000001 0000000000002000 0000000000000000 0000000000000000 [ 109.561200] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 109.561820] Call Trace: [ 109.562027] <IRQ> [ 109.562108] [<ffffffff88dfb4fa>] ? eth_get_headlen+0x7a/0xf0 [ 109.562522] [<ffffffff88c5a35a>] ? igb_poll+0x96a/0xe80 [ 109.562737] [<ffffffff88dc912b>] ? net_rx_action+0x20b/0x350 [ 109.562953] [<ffffffff88546d68>] ? __do_softirq+0xe8/0x280 [ 109.563169] [<ffffffff8854704a>] ? irq_exit+0xaa/0xb0 [ 109.563382] [<ffffffff8847229b>] ? do_IRQ+0x4b/0xc0 [ 109.563597] [<ffffffff8902d4ff>] ? common_interrupt+0x7f/0x7f [ 109.563810] <EOI> [ 109.563890] [<ffffffff88d57530>] ? cpuidle_enter_state+0x130/0x2c0 [ 109.564304] [<ffffffff88d57520>] ? cpuidle_enter_state+0x120/0x2c0 [ 109.564520] [<ffffffff8857eacf>] ? cpu_startup_entry+0x19f/0x1f0 [ 109.564737] [<ffffffff8848d55a>] ? start_secondary+0x12a/0x140 [ 109.564950] Code: 83 e2 20 a8 80 0f 84 60 01 00 00 c7 04 24 08 00 00 00 66 85 d2 0f 84 be fe ff ff e9 69 fe ff ff 8b 34 24 89 f2 83 c2 04 66 85 c0 <41> 8b 84 24 80 00 00 00 0f 49 d6 41 8d 31 01 d6 41 2b 84 24 84 [ 109.569959] RIP [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0 [ 109.570245] RSP <ffff94087fc83d40> [ 109.570453] CR2: 0000000000000080 Fixes: ab10dcc ("rps: Inspect PPTP encapsulated by GRE to get flow hash") Signed-off-by: Ian Kumlien <ian.kumlien@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Feb 7, 2017
Debug interrupts can be taken during regular program or a standard
interrupt, the EA of the instruction causing the interrupt will be
kept in DSRR0.
Kernel will check if this value is between [interrupt_base_book3e,
__end_interrupts].
However, when the kernel build with CONFIG_RELOCATABLE, it can't get
EA of those lables by LOAD_REG_IMMEDIATE(r14,interrupt_base_book3e)
and LOAD_REG_IMMEDIATE(r15,__end_interrupts),then it cases problems
later.
At the same time, r2(toc) are not usable here, so LOAD_REG_ADDR()
dosen't work neither. So we use the *name@got* to get the EV of two
lables directly.
This patch can fix the problem and remove the oops when we gdb a
program with single-step.
Test programs test.c shows as follows:
#include <fcntl.h>
#include <stdio.h>
int main(int argc, char *argv[])
{
if (access("/proc/sys/kernel/perf_event_paranoid", F_OK) == -1)
printf("Kernel doesn't have perf_event support\n");
}
Steps to reproduce the bug, for example:
1) ./gdb ./test
2) (gdb) b access
3) (gdb) r
4) (gdb) s
Then will trigger the oops, it looks like:
(gdb) s
Single stepping Oops: Exception in kernel mode, sig: 5 [#2]
PREEMPT CoreNet Generic
Modules linked in:
CPU: 0 PID: 1135 Comm: test Tainted: G D Linux (none) 4.9.5 torvalds#79
task: c000000079199580 ti: c00000007ffc4000 task.ti: c000000074064000
NIP: c00000000001a1e4 LR: 000000001000103c CTR: 000000001000100c
REGS: c00000007ffc7cf0 TRAP: 0d08 Tainted: G D (Linux (none) 4.9.5)
MSR: 0000000080021000 <CE,ME> CR: 24000442 XER: 00000000
SOFTE: 1
GPR00: 0000000010001274 00000000ffffeba0 00000000100ab4b0 00000000100764a4
GPR04: 0000000000000000 00000000ffffee2c 00000000ffffee54 00000000100a44c8
GPR08: 0000000000000001 0000000010070000 00000000100a0000 0000000000000001
GPR12: 000000004347432f 00000000100aa648 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR24: 0000000000000000 0000000010001950 0000000010001850 0000000000000000
GPR28: 0000000000000000 00000000100000f4 0000000000000000 00000000ffffeba0
NIP [c00000000001a1e4] interrupt_base_book3e+0x1e4/0x348
LR [000000001000103c] 0x1000103c
Call Trace:
Instruction dump:
00000000 00000000 00000000 60000000 4800e600 00000000 00000000 00000000
00000000 00000000 00000000 60000000 <4800e588> 00000000 00000000 00000000
Signed-off-by: Liu Hailong <liu.hailong6@zte.com.cn>
Signed-off-by: Jiang Xuexin <jiang.xuexin@zte.com.cn>
Reviewed-by: Jiang Biao <jiang.biao2@zte.com.cn>
Reviewed-by: Liu Song <liu.song11@zte.com.cn>
Reviewed-by: Huang Jian <huang.jian@zte.com.cn>
malaterre
pushed a commit
to malaterre/linux
that referenced
this pull request
Oct 18, 2017
…-fixes Ci20 v3.18 stability fixes. Cautionary note: Increases stability at the cost of reduced SMP performance until a proper solution for the cpu idle driver is implemented.
ldu4
pushed a commit
to ldu4/linux
that referenced
this pull request
Dec 21, 2017
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 0123456789ab ("commit description")'
torvalds#8:
(before eab0953 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE"))
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 0123456789ab ("commit description")'
torvalds#15:
further from the stack (eab0953 and later by c715b72 ("mm:
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 0123456789ab ("commit description")'
torvalds#17:
stack consumption early during execve fully stopped by da029c1
WARNING: 'segement' may be misspelled - perhaps 'segment'?
torvalds#64: FILE: arch/metag/kernel/process.c:421:
+ pr_info("%d (%s): Uhuuh, elf segement at %p requested but the memory is mapped already\n",
ERROR: "(foo*)" should be "(foo *)"
torvalds#65: FILE: arch/metag/kernel/process.c:422:
+ task_pid_nr(current), tsk->comm, (void*)addr);
WARNING: 'segement' may be misspelled - perhaps 'segment'?
torvalds#78: FILE: fs/binfmt_elf.c:381:
+ pr_info("%d (%s): Uhuuh, elf segement at %p requested but the memory is mapped already\n",
WARNING: line over 80 characters
torvalds#79: FILE: fs/binfmt_elf.c:382:
+ task_pid_nr(current), current->comm, (void*)addr);
ERROR: "(foo*)" should be "(foo *)"
torvalds#79: FILE: fs/binfmt_elf.c:382:
+ task_pid_nr(current), current->comm, (void*)addr);
total: 5 errors, 3 warnings, 60 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
./patches/fs-elf-drop-map_fixed-usage-from-elf_map.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Dec 24, 2017
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 0123456789ab ("commit description")'
torvalds#8:
(before eab0953 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE"))
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 0123456789ab ("commit description")'
torvalds#15:
further from the stack (eab0953 and later by c715b72 ("mm:
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 0123456789ab ("commit description")'
torvalds#17:
stack consumption early during execve fully stopped by da029c1
WARNING: 'segement' may be misspelled - perhaps 'segment'?
torvalds#64: FILE: arch/metag/kernel/process.c:421:
+ pr_info("%d (%s): Uhuuh, elf segement at %p requested but the memory is mapped already\n",
ERROR: "(foo*)" should be "(foo *)"
torvalds#65: FILE: arch/metag/kernel/process.c:422:
+ task_pid_nr(current), tsk->comm, (void*)addr);
WARNING: 'segement' may be misspelled - perhaps 'segment'?
torvalds#78: FILE: fs/binfmt_elf.c:381:
+ pr_info("%d (%s): Uhuuh, elf segement at %p requested but the memory is mapped already\n",
WARNING: line over 80 characters
torvalds#79: FILE: fs/binfmt_elf.c:382:
+ task_pid_nr(current), current->comm, (void*)addr);
ERROR: "(foo*)" should be "(foo *)"
torvalds#79: FILE: fs/binfmt_elf.c:382:
+ task_pid_nr(current), current->comm, (void*)addr);
total: 5 errors, 3 warnings, 60 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
./patches/fs-elf-drop-map_fixed-usage-from-elf_map.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
mlyle
pushed a commit
to mlyle/linux
that referenced
this pull request
Jan 2, 2018
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 0123456789ab ("commit description")'
torvalds#8:
(before eab0953 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE"))
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 0123456789ab ("commit description")'
torvalds#15:
further from the stack (eab0953 and later by c715b72 ("mm:
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 0123456789ab ("commit description")'
torvalds#17:
stack consumption early during execve fully stopped by da029c1
WARNING: 'segement' may be misspelled - perhaps 'segment'?
torvalds#64: FILE: arch/metag/kernel/process.c:421:
+ pr_info("%d (%s): Uhuuh, elf segement at %p requested but the memory is mapped already\n",
ERROR: "(foo*)" should be "(foo *)"
torvalds#65: FILE: arch/metag/kernel/process.c:422:
+ task_pid_nr(current), tsk->comm, (void*)addr);
WARNING: 'segement' may be misspelled - perhaps 'segment'?
torvalds#78: FILE: fs/binfmt_elf.c:381:
+ pr_info("%d (%s): Uhuuh, elf segement at %p requested but the memory is mapped already\n",
WARNING: line over 80 characters
torvalds#79: FILE: fs/binfmt_elf.c:382:
+ task_pid_nr(current), current->comm, (void*)addr);
ERROR: "(foo*)" should be "(foo *)"
torvalds#79: FILE: fs/binfmt_elf.c:382:
+ task_pid_nr(current), current->comm, (void*)addr);
total: 5 errors, 3 warnings, 60 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
./patches/fs-elf-drop-map_fixed-usage-from-elf_map.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
mlyle
pushed a commit
to mlyle/linux
that referenced
this pull request
Jan 5, 2018
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 0123456789ab ("commit description")'
torvalds#8:
(before eab0953 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE"))
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 0123456789ab ("commit description")'
torvalds#15:
further from the stack (eab0953 and later by c715b72 ("mm:
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 0123456789ab ("commit description")'
torvalds#17:
stack consumption early during execve fully stopped by da029c1
WARNING: 'segement' may be misspelled - perhaps 'segment'?
torvalds#64: FILE: arch/metag/kernel/process.c:421:
+ pr_info("%d (%s): Uhuuh, elf segement at %p requested but the memory is mapped already\n",
ERROR: "(foo*)" should be "(foo *)"
torvalds#65: FILE: arch/metag/kernel/process.c:422:
+ task_pid_nr(current), tsk->comm, (void*)addr);
WARNING: 'segement' may be misspelled - perhaps 'segment'?
torvalds#78: FILE: fs/binfmt_elf.c:381:
+ pr_info("%d (%s): Uhuuh, elf segement at %p requested but the memory is mapped already\n",
WARNING: line over 80 characters
torvalds#79: FILE: fs/binfmt_elf.c:382:
+ task_pid_nr(current), current->comm, (void*)addr);
ERROR: "(foo*)" should be "(foo *)"
torvalds#79: FILE: fs/binfmt_elf.c:382:
+ task_pid_nr(current), current->comm, (void*)addr);
total: 5 errors, 3 warnings, 60 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
./patches/fs-elf-drop-map_fixed-usage-from-elf_map.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 9, 2018
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 0123456789ab ("commit description")'
torvalds#8:
(before eab0953 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE"))
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 0123456789ab ("commit description")'
torvalds#15:
further from the stack (eab0953 and later by c715b72 ("mm:
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 0123456789ab ("commit description")'
torvalds#17:
stack consumption early during execve fully stopped by da029c1
WARNING: 'segement' may be misspelled - perhaps 'segment'?
torvalds#64: FILE: arch/metag/kernel/process.c:421:
+ pr_info("%d (%s): Uhuuh, elf segement at %p requested but the memory is mapped already\n",
ERROR: "(foo*)" should be "(foo *)"
torvalds#65: FILE: arch/metag/kernel/process.c:422:
+ task_pid_nr(current), tsk->comm, (void*)addr);
WARNING: 'segement' may be misspelled - perhaps 'segment'?
torvalds#78: FILE: fs/binfmt_elf.c:381:
+ pr_info("%d (%s): Uhuuh, elf segement at %p requested but the memory is mapped already\n",
WARNING: line over 80 characters
torvalds#79: FILE: fs/binfmt_elf.c:382:
+ task_pid_nr(current), current->comm, (void*)addr);
ERROR: "(foo*)" should be "(foo *)"
torvalds#79: FILE: fs/binfmt_elf.c:382:
+ task_pid_nr(current), current->comm, (void*)addr);
total: 5 errors, 3 warnings, 60 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
./patches/fs-elf-drop-map_fixed-usage-from-elf_map.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 21, 2018
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 0123456789ab ("commit description")'
torvalds#8:
(before eab0953 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE"))
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 0123456789ab ("commit description")'
torvalds#15:
further from the stack (eab0953 and later by c715b72 ("mm:
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 0123456789ab ("commit description")'
torvalds#17:
stack consumption early during execve fully stopped by da029c1
WARNING: 'segement' may be misspelled - perhaps 'segment'?
torvalds#64: FILE: arch/metag/kernel/process.c:421:
+ pr_info("%d (%s): Uhuuh, elf segement at %p requested but the memory is mapped already\n",
ERROR: "(foo*)" should be "(foo *)"
torvalds#65: FILE: arch/metag/kernel/process.c:422:
+ task_pid_nr(current), tsk->comm, (void*)addr);
WARNING: 'segement' may be misspelled - perhaps 'segment'?
torvalds#78: FILE: fs/binfmt_elf.c:381:
+ pr_info("%d (%s): Uhuuh, elf segement at %p requested but the memory is mapped already\n",
WARNING: line over 80 characters
torvalds#79: FILE: fs/binfmt_elf.c:382:
+ task_pid_nr(current), current->comm, (void*)addr);
ERROR: "(foo*)" should be "(foo *)"
torvalds#79: FILE: fs/binfmt_elf.c:382:
+ task_pid_nr(current), current->comm, (void*)addr);
total: 5 errors, 3 warnings, 60 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
./patches/fs-elf-drop-map_fixed-usage-from-elf_map.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ioworker0
pushed a commit
to ioworker0/linux
that referenced
this pull request
Jun 20, 2024
…stics 'vmap allocation for size %lu failed: use vmalloc=<size> to increase size' The above warning is seen in the kernel functionality for allocation of the restricted virtual memory range till exhaustion. This message is misleading because 'vmalloc=' is supported on arm32, x86 platforms and is not a valid kernel parameter on a number of other platforms (in particular its not supported on arm64, alpha, loongarch, arc, csky, hexagon, microblaze, mips, nios2, openrisc, parisc, m64k, powerpc, riscv, sh, um, xtensa, s390, sparc). With the update, the output gets modified to include the function parameters along with the start and end of the virtual memory range allowed. The warning message after fix on kernel version 6.10.0-rc1+: vmalloc_node_range for size 33619968 failed: Address range restricted between 0xffff800082640000 - 0xffff800084650000 Backtrace with the misleading error message: vmap allocation for size 33619968 failed: use vmalloc=<size> to increase size insmod: vmalloc error: size 33554432, vm_struct allocation failed, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 46 PID: 1977 Comm: insmod Tainted: G E 6.10.0-rc1+ torvalds#79 Hardware name: INGRASYS Yushan Server iSystem TEMP-S000141176+10/Yushan Motherboard, BIOS 2.10.20230517 (SCP: xxx) yyyy/mm/dd Call trace: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x78/0x90 dump_stack+0x18/0x28 warn_alloc+0x12c/0x1b8 __vmalloc_node_range_noprof+0x28c/0x7e0 custom_init+0xb4/0xfff8 [test_driver] do_one_initcall+0x60/0x290 do_init_module+0x68/0x250 load_module+0x236c/0x2428 init_module_from_file+0x8c/0xd8 __arm64_sys_finit_module+0x1b4/0x388 invoke_syscall+0x78/0x108 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x130 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x190/0x198 Link: https://lkml.kernel.org/r/MN2PR01MB59025CC02D1D29516527A693F5C62@MN2PR01MB5902.prod.exchangelabs.com Reviewed-by: Christoph Lameter (Ampere) <cl@linux.com> Signed-off-by: Shubhang Kaushik <shubhang@os.amperecomputing.com> Cc: Christoph Lameter <cl@linux.com> Cc: Guo Ren <guoren@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Uladzislau Rezki (Sony) <urezki@gmail.com> Cc: Xiongwei Song <xiongwei.song@windriver.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ioworker0
pushed a commit
to ioworker0/linux
that referenced
this pull request
Jun 20, 2024
…stics 'vmap allocation for size %lu failed: use vmalloc=<size> to increase size' The above warning is seen in the kernel functionality for allocation of the restricted virtual memory range till exhaustion. This message is misleading because 'vmalloc=' is supported on arm32, x86 platforms and is not a valid kernel parameter on a number of other platforms (in particular its not supported on arm64, alpha, loongarch, arc, csky, hexagon, microblaze, mips, nios2, openrisc, parisc, m64k, powerpc, riscv, sh, um, xtensa, s390, sparc). With the update, the output gets modified to include the function parameters along with the start and end of the virtual memory range allowed. The warning message after fix on kernel version 6.10.0-rc1+: vmalloc_node_range for size 33619968 failed: Address range restricted between 0xffff800082640000 - 0xffff800084650000 Backtrace with the misleading error message: vmap allocation for size 33619968 failed: use vmalloc=<size> to increase size insmod: vmalloc error: size 33554432, vm_struct allocation failed, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 46 PID: 1977 Comm: insmod Tainted: G E 6.10.0-rc1+ torvalds#79 Hardware name: INGRASYS Yushan Server iSystem TEMP-S000141176+10/Yushan Motherboard, BIOS 2.10.20230517 (SCP: xxx) yyyy/mm/dd Call trace: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x78/0x90 dump_stack+0x18/0x28 warn_alloc+0x12c/0x1b8 __vmalloc_node_range_noprof+0x28c/0x7e0 custom_init+0xb4/0xfff8 [test_driver] do_one_initcall+0x60/0x290 do_init_module+0x68/0x250 load_module+0x236c/0x2428 init_module_from_file+0x8c/0xd8 __arm64_sys_finit_module+0x1b4/0x388 invoke_syscall+0x78/0x108 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x130 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x190/0x198 Link: https://lkml.kernel.org/r/MN2PR01MB59025CC02D1D29516527A693F5C62@MN2PR01MB5902.prod.exchangelabs.com Reviewed-by: Christoph Lameter (Ampere) <cl@linux.com> Signed-off-by: Shubhang Kaushik <shubhang@os.amperecomputing.com> Cc: Christoph Lameter <cl@linux.com> Cc: Guo Ren <guoren@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Uladzislau Rezki (Sony) <urezki@gmail.com> Cc: Xiongwei Song <xiongwei.song@windriver.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ioworker0
pushed a commit
to ioworker0/linux
that referenced
this pull request
Jun 22, 2024
…stics 'vmap allocation for size %lu failed: use vmalloc=<size> to increase size' The above warning is seen in the kernel functionality for allocation of the restricted virtual memory range till exhaustion. This message is misleading because 'vmalloc=' is supported on arm32, x86 platforms and is not a valid kernel parameter on a number of other platforms (in particular its not supported on arm64, alpha, loongarch, arc, csky, hexagon, microblaze, mips, nios2, openrisc, parisc, m64k, powerpc, riscv, sh, um, xtensa, s390, sparc). With the update, the output gets modified to include the function parameters along with the start and end of the virtual memory range allowed. The warning message after fix on kernel version 6.10.0-rc1+: vmalloc_node_range for size 33619968 failed: Address range restricted between 0xffff800082640000 - 0xffff800084650000 Backtrace with the misleading error message: vmap allocation for size 33619968 failed: use vmalloc=<size> to increase size insmod: vmalloc error: size 33554432, vm_struct allocation failed, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 46 PID: 1977 Comm: insmod Tainted: G E 6.10.0-rc1+ torvalds#79 Hardware name: INGRASYS Yushan Server iSystem TEMP-S000141176+10/Yushan Motherboard, BIOS 2.10.20230517 (SCP: xxx) yyyy/mm/dd Call trace: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x78/0x90 dump_stack+0x18/0x28 warn_alloc+0x12c/0x1b8 __vmalloc_node_range_noprof+0x28c/0x7e0 custom_init+0xb4/0xfff8 [test_driver] do_one_initcall+0x60/0x290 do_init_module+0x68/0x250 load_module+0x236c/0x2428 init_module_from_file+0x8c/0xd8 __arm64_sys_finit_module+0x1b4/0x388 invoke_syscall+0x78/0x108 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x130 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x190/0x198 Link: https://lkml.kernel.org/r/MN2PR01MB59025CC02D1D29516527A693F5C62@MN2PR01MB5902.prod.exchangelabs.com Reviewed-by: Christoph Lameter (Ampere) <cl@linux.com> Signed-off-by: Shubhang Kaushik <shubhang@os.amperecomputing.com> Cc: Christoph Lameter <cl@linux.com> Cc: Guo Ren <guoren@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Uladzislau Rezki (Sony) <urezki@gmail.com> Cc: Xiongwei Song <xiongwei.song@windriver.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ioworker0
pushed a commit
to ioworker0/linux
that referenced
this pull request
Jun 25, 2024
…stics 'vmap allocation for size %lu failed: use vmalloc=<size> to increase size' The above warning is seen in the kernel functionality for allocation of the restricted virtual memory range till exhaustion. This message is misleading because 'vmalloc=' is supported on arm32, x86 platforms and is not a valid kernel parameter on a number of other platforms (in particular its not supported on arm64, alpha, loongarch, arc, csky, hexagon, microblaze, mips, nios2, openrisc, parisc, m64k, powerpc, riscv, sh, um, xtensa, s390, sparc). With the update, the output gets modified to include the function parameters along with the start and end of the virtual memory range allowed. The warning message after fix on kernel version 6.10.0-rc1+: vmalloc_node_range for size 33619968 failed: Address range restricted between 0xffff800082640000 - 0xffff800084650000 Backtrace with the misleading error message: vmap allocation for size 33619968 failed: use vmalloc=<size> to increase size insmod: vmalloc error: size 33554432, vm_struct allocation failed, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 46 PID: 1977 Comm: insmod Tainted: G E 6.10.0-rc1+ torvalds#79 Hardware name: INGRASYS Yushan Server iSystem TEMP-S000141176+10/Yushan Motherboard, BIOS 2.10.20230517 (SCP: xxx) yyyy/mm/dd Call trace: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x78/0x90 dump_stack+0x18/0x28 warn_alloc+0x12c/0x1b8 __vmalloc_node_range_noprof+0x28c/0x7e0 custom_init+0xb4/0xfff8 [test_driver] do_one_initcall+0x60/0x290 do_init_module+0x68/0x250 load_module+0x236c/0x2428 init_module_from_file+0x8c/0xd8 __arm64_sys_finit_module+0x1b4/0x388 invoke_syscall+0x78/0x108 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x130 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x190/0x198 Link: https://lkml.kernel.org/r/MN2PR01MB59025CC02D1D29516527A693F5C62@MN2PR01MB5902.prod.exchangelabs.com Reviewed-by: Christoph Lameter (Ampere) <cl@linux.com> Signed-off-by: Shubhang Kaushik <shubhang@os.amperecomputing.com> Cc: Christoph Lameter <cl@linux.com> Cc: Guo Ren <guoren@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Uladzislau Rezki (Sony) <urezki@gmail.com> Cc: Xiongwei Song <xiongwei.song@windriver.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ioworker0
pushed a commit
to ioworker0/linux
that referenced
this pull request
Jun 25, 2024
…stics 'vmap allocation for size %lu failed: use vmalloc=<size> to increase size' The above warning is seen in the kernel functionality for allocation of the restricted virtual memory range till exhaustion. This message is misleading because 'vmalloc=' is supported on arm32, x86 platforms and is not a valid kernel parameter on a number of other platforms (in particular its not supported on arm64, alpha, loongarch, arc, csky, hexagon, microblaze, mips, nios2, openrisc, parisc, m64k, powerpc, riscv, sh, um, xtensa, s390, sparc). With the update, the output gets modified to include the function parameters along with the start and end of the virtual memory range allowed. The warning message after fix on kernel version 6.10.0-rc1+: vmalloc_node_range for size 33619968 failed: Address range restricted between 0xffff800082640000 - 0xffff800084650000 Backtrace with the misleading error message: vmap allocation for size 33619968 failed: use vmalloc=<size> to increase size insmod: vmalloc error: size 33554432, vm_struct allocation failed, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 46 PID: 1977 Comm: insmod Tainted: G E 6.10.0-rc1+ torvalds#79 Hardware name: INGRASYS Yushan Server iSystem TEMP-S000141176+10/Yushan Motherboard, BIOS 2.10.20230517 (SCP: xxx) yyyy/mm/dd Call trace: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x78/0x90 dump_stack+0x18/0x28 warn_alloc+0x12c/0x1b8 __vmalloc_node_range_noprof+0x28c/0x7e0 custom_init+0xb4/0xfff8 [test_driver] do_one_initcall+0x60/0x290 do_init_module+0x68/0x250 load_module+0x236c/0x2428 init_module_from_file+0x8c/0xd8 __arm64_sys_finit_module+0x1b4/0x388 invoke_syscall+0x78/0x108 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x130 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x190/0x198 Link: https://lkml.kernel.org/r/MN2PR01MB59025CC02D1D29516527A693F5C62@MN2PR01MB5902.prod.exchangelabs.com Reviewed-by: Christoph Lameter (Ampere) <cl@linux.com> Signed-off-by: Shubhang Kaushik <shubhang@os.amperecomputing.com> Cc: Christoph Lameter <cl@linux.com> Cc: Guo Ren <guoren@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Uladzislau Rezki (Sony) <urezki@gmail.com> Cc: Xiongwei Song <xiongwei.song@windriver.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ioworker0
pushed a commit
to ioworker0/linux
that referenced
this pull request
Jun 25, 2024
…stics 'vmap allocation for size %lu failed: use vmalloc=<size> to increase size' The above warning is seen in the kernel functionality for allocation of the restricted virtual memory range till exhaustion. This message is misleading because 'vmalloc=' is supported on arm32, x86 platforms and is not a valid kernel parameter on a number of other platforms (in particular its not supported on arm64, alpha, loongarch, arc, csky, hexagon, microblaze, mips, nios2, openrisc, parisc, m64k, powerpc, riscv, sh, um, xtensa, s390, sparc). With the update, the output gets modified to include the function parameters along with the start and end of the virtual memory range allowed. The warning message after fix on kernel version 6.10.0-rc1+: vmalloc_node_range for size 33619968 failed: Address range restricted between 0xffff800082640000 - 0xffff800084650000 Backtrace with the misleading error message: vmap allocation for size 33619968 failed: use vmalloc=<size> to increase size insmod: vmalloc error: size 33554432, vm_struct allocation failed, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 46 PID: 1977 Comm: insmod Tainted: G E 6.10.0-rc1+ torvalds#79 Hardware name: INGRASYS Yushan Server iSystem TEMP-S000141176+10/Yushan Motherboard, BIOS 2.10.20230517 (SCP: xxx) yyyy/mm/dd Call trace: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x78/0x90 dump_stack+0x18/0x28 warn_alloc+0x12c/0x1b8 __vmalloc_node_range_noprof+0x28c/0x7e0 custom_init+0xb4/0xfff8 [test_driver] do_one_initcall+0x60/0x290 do_init_module+0x68/0x250 load_module+0x236c/0x2428 init_module_from_file+0x8c/0xd8 __arm64_sys_finit_module+0x1b4/0x388 invoke_syscall+0x78/0x108 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x130 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x190/0x198 Link: https://lkml.kernel.org/r/MN2PR01MB59025CC02D1D29516527A693F5C62@MN2PR01MB5902.prod.exchangelabs.com Reviewed-by: Christoph Lameter (Ampere) <cl@linux.com> Signed-off-by: Shubhang Kaushik <shubhang@os.amperecomputing.com> Cc: Christoph Lameter <cl@linux.com> Cc: Guo Ren <guoren@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Uladzislau Rezki (Sony) <urezki@gmail.com> Cc: Xiongwei Song <xiongwei.song@windriver.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ioworker0
pushed a commit
to ioworker0/linux
that referenced
this pull request
Jun 26, 2024
…stics 'vmap allocation for size %lu failed: use vmalloc=<size> to increase size' The above warning is seen in the kernel functionality for allocation of the restricted virtual memory range till exhaustion. This message is misleading because 'vmalloc=' is supported on arm32, x86 platforms and is not a valid kernel parameter on a number of other platforms (in particular its not supported on arm64, alpha, loongarch, arc, csky, hexagon, microblaze, mips, nios2, openrisc, parisc, m64k, powerpc, riscv, sh, um, xtensa, s390, sparc). With the update, the output gets modified to include the function parameters along with the start and end of the virtual memory range allowed. The warning message after fix on kernel version 6.10.0-rc1+: vmalloc_node_range for size 33619968 failed: Address range restricted between 0xffff800082640000 - 0xffff800084650000 Backtrace with the misleading error message: vmap allocation for size 33619968 failed: use vmalloc=<size> to increase size insmod: vmalloc error: size 33554432, vm_struct allocation failed, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 46 PID: 1977 Comm: insmod Tainted: G E 6.10.0-rc1+ torvalds#79 Hardware name: INGRASYS Yushan Server iSystem TEMP-S000141176+10/Yushan Motherboard, BIOS 2.10.20230517 (SCP: xxx) yyyy/mm/dd Call trace: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x78/0x90 dump_stack+0x18/0x28 warn_alloc+0x12c/0x1b8 __vmalloc_node_range_noprof+0x28c/0x7e0 custom_init+0xb4/0xfff8 [test_driver] do_one_initcall+0x60/0x290 do_init_module+0x68/0x250 load_module+0x236c/0x2428 init_module_from_file+0x8c/0xd8 __arm64_sys_finit_module+0x1b4/0x388 invoke_syscall+0x78/0x108 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x130 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x190/0x198 Link: https://lkml.kernel.org/r/MN2PR01MB59025CC02D1D29516527A693F5C62@MN2PR01MB5902.prod.exchangelabs.com Reviewed-by: Christoph Lameter (Ampere) <cl@linux.com> Signed-off-by: Shubhang Kaushik <shubhang@os.amperecomputing.com> Cc: Christoph Lameter <cl@linux.com> Cc: Guo Ren <guoren@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Uladzislau Rezki (Sony) <urezki@gmail.com> Cc: Xiongwei Song <xiongwei.song@windriver.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ioworker0
pushed a commit
to ioworker0/linux
that referenced
this pull request
Jun 27, 2024
…stics 'vmap allocation for size %lu failed: use vmalloc=<size> to increase size' The above warning is seen in the kernel functionality for allocation of the restricted virtual memory range till exhaustion. This message is misleading because 'vmalloc=' is supported on arm32, x86 platforms and is not a valid kernel parameter on a number of other platforms (in particular its not supported on arm64, alpha, loongarch, arc, csky, hexagon, microblaze, mips, nios2, openrisc, parisc, m64k, powerpc, riscv, sh, um, xtensa, s390, sparc). With the update, the output gets modified to include the function parameters along with the start and end of the virtual memory range allowed. The warning message after fix on kernel version 6.10.0-rc1+: vmalloc_node_range for size 33619968 failed: Address range restricted between 0xffff800082640000 - 0xffff800084650000 Backtrace with the misleading error message: vmap allocation for size 33619968 failed: use vmalloc=<size> to increase size insmod: vmalloc error: size 33554432, vm_struct allocation failed, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 46 PID: 1977 Comm: insmod Tainted: G E 6.10.0-rc1+ torvalds#79 Hardware name: INGRASYS Yushan Server iSystem TEMP-S000141176+10/Yushan Motherboard, BIOS 2.10.20230517 (SCP: xxx) yyyy/mm/dd Call trace: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x78/0x90 dump_stack+0x18/0x28 warn_alloc+0x12c/0x1b8 __vmalloc_node_range_noprof+0x28c/0x7e0 custom_init+0xb4/0xfff8 [test_driver] do_one_initcall+0x60/0x290 do_init_module+0x68/0x250 load_module+0x236c/0x2428 init_module_from_file+0x8c/0xd8 __arm64_sys_finit_module+0x1b4/0x388 invoke_syscall+0x78/0x108 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x130 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x190/0x198 Link: https://lkml.kernel.org/r/MN2PR01MB59025CC02D1D29516527A693F5C62@MN2PR01MB5902.prod.exchangelabs.com Reviewed-by: Christoph Lameter (Ampere) <cl@linux.com> Signed-off-by: Shubhang Kaushik <shubhang@os.amperecomputing.com> Cc: Christoph Lameter <cl@linux.com> Cc: Guo Ren <guoren@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Uladzislau Rezki (Sony) <urezki@gmail.com> Cc: Xiongwei Song <xiongwei.song@windriver.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ioworker0
pushed a commit
to ioworker0/linux
that referenced
this pull request
Jun 28, 2024
…stics 'vmap allocation for size %lu failed: use vmalloc=<size> to increase size' The above warning is seen in the kernel functionality for allocation of the restricted virtual memory range till exhaustion. This message is misleading because 'vmalloc=' is supported on arm32, x86 platforms and is not a valid kernel parameter on a number of other platforms (in particular its not supported on arm64, alpha, loongarch, arc, csky, hexagon, microblaze, mips, nios2, openrisc, parisc, m64k, powerpc, riscv, sh, um, xtensa, s390, sparc). With the update, the output gets modified to include the function parameters along with the start and end of the virtual memory range allowed. The warning message after fix on kernel version 6.10.0-rc1+: vmalloc_node_range for size 33619968 failed: Address range restricted between 0xffff800082640000 - 0xffff800084650000 Backtrace with the misleading error message: vmap allocation for size 33619968 failed: use vmalloc=<size> to increase size insmod: vmalloc error: size 33554432, vm_struct allocation failed, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 46 PID: 1977 Comm: insmod Tainted: G E 6.10.0-rc1+ torvalds#79 Hardware name: INGRASYS Yushan Server iSystem TEMP-S000141176+10/Yushan Motherboard, BIOS 2.10.20230517 (SCP: xxx) yyyy/mm/dd Call trace: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x78/0x90 dump_stack+0x18/0x28 warn_alloc+0x12c/0x1b8 __vmalloc_node_range_noprof+0x28c/0x7e0 custom_init+0xb4/0xfff8 [test_driver] do_one_initcall+0x60/0x290 do_init_module+0x68/0x250 load_module+0x236c/0x2428 init_module_from_file+0x8c/0xd8 __arm64_sys_finit_module+0x1b4/0x388 invoke_syscall+0x78/0x108 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x130 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x190/0x198 Link: https://lkml.kernel.org/r/MN2PR01MB59025CC02D1D29516527A693F5C62@MN2PR01MB5902.prod.exchangelabs.com Reviewed-by: Christoph Lameter (Ampere) <cl@linux.com> Signed-off-by: Shubhang Kaushik <shubhang@os.amperecomputing.com> Cc: Christoph Lameter <cl@linux.com> Cc: Guo Ren <guoren@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Uladzislau Rezki (Sony) <urezki@gmail.com> Cc: Xiongwei Song <xiongwei.song@windriver.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ioworker0
pushed a commit
to ioworker0/linux
that referenced
this pull request
Jun 29, 2024
…stics 'vmap allocation for size %lu failed: use vmalloc=<size> to increase size' The above warning is seen in the kernel functionality for allocation of the restricted virtual memory range till exhaustion. This message is misleading because 'vmalloc=' is supported on arm32, x86 platforms and is not a valid kernel parameter on a number of other platforms (in particular its not supported on arm64, alpha, loongarch, arc, csky, hexagon, microblaze, mips, nios2, openrisc, parisc, m64k, powerpc, riscv, sh, um, xtensa, s390, sparc). With the update, the output gets modified to include the function parameters along with the start and end of the virtual memory range allowed. The warning message after fix on kernel version 6.10.0-rc1+: vmalloc_node_range for size 33619968 failed: Address range restricted between 0xffff800082640000 - 0xffff800084650000 Backtrace with the misleading error message: vmap allocation for size 33619968 failed: use vmalloc=<size> to increase size insmod: vmalloc error: size 33554432, vm_struct allocation failed, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 46 PID: 1977 Comm: insmod Tainted: G E 6.10.0-rc1+ torvalds#79 Hardware name: INGRASYS Yushan Server iSystem TEMP-S000141176+10/Yushan Motherboard, BIOS 2.10.20230517 (SCP: xxx) yyyy/mm/dd Call trace: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x78/0x90 dump_stack+0x18/0x28 warn_alloc+0x12c/0x1b8 __vmalloc_node_range_noprof+0x28c/0x7e0 custom_init+0xb4/0xfff8 [test_driver] do_one_initcall+0x60/0x290 do_init_module+0x68/0x250 load_module+0x236c/0x2428 init_module_from_file+0x8c/0xd8 __arm64_sys_finit_module+0x1b4/0x388 invoke_syscall+0x78/0x108 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x130 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x190/0x198 Link: https://lkml.kernel.org/r/MN2PR01MB59025CC02D1D29516527A693F5C62@MN2PR01MB5902.prod.exchangelabs.com Reviewed-by: Christoph Lameter (Ampere) <cl@linux.com> Signed-off-by: Shubhang Kaushik <shubhang@os.amperecomputing.com> Cc: Christoph Lameter <cl@linux.com> Cc: Guo Ren <guoren@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Uladzislau Rezki (Sony) <urezki@gmail.com> Cc: Xiongwei Song <xiongwei.song@windriver.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ioworker0
pushed a commit
to ioworker0/linux
that referenced
this pull request
Jun 29, 2024
…stics 'vmap allocation for size %lu failed: use vmalloc=<size> to increase size' The above warning is seen in the kernel functionality for allocation of the restricted virtual memory range till exhaustion. This message is misleading because 'vmalloc=' is supported on arm32, x86 platforms and is not a valid kernel parameter on a number of other platforms (in particular its not supported on arm64, alpha, loongarch, arc, csky, hexagon, microblaze, mips, nios2, openrisc, parisc, m64k, powerpc, riscv, sh, um, xtensa, s390, sparc). With the update, the output gets modified to include the function parameters along with the start and end of the virtual memory range allowed. The warning message after fix on kernel version 6.10.0-rc1+: vmalloc_node_range for size 33619968 failed: Address range restricted between 0xffff800082640000 - 0xffff800084650000 Backtrace with the misleading error message: vmap allocation for size 33619968 failed: use vmalloc=<size> to increase size insmod: vmalloc error: size 33554432, vm_struct allocation failed, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 46 PID: 1977 Comm: insmod Tainted: G E 6.10.0-rc1+ torvalds#79 Hardware name: INGRASYS Yushan Server iSystem TEMP-S000141176+10/Yushan Motherboard, BIOS 2.10.20230517 (SCP: xxx) yyyy/mm/dd Call trace: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x78/0x90 dump_stack+0x18/0x28 warn_alloc+0x12c/0x1b8 __vmalloc_node_range_noprof+0x28c/0x7e0 custom_init+0xb4/0xfff8 [test_driver] do_one_initcall+0x60/0x290 do_init_module+0x68/0x250 load_module+0x236c/0x2428 init_module_from_file+0x8c/0xd8 __arm64_sys_finit_module+0x1b4/0x388 invoke_syscall+0x78/0x108 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x130 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x190/0x198 [Shubhang@os.amperecomputing.com: v5] Link: https://lkml.kernel.org/r/CH2PR01MB5894B0182EA0B28DF2EFB916F5C72@CH2PR01MB5894.prod.exchangelabs.com Link: https://lkml.kernel.org/r/MN2PR01MB59025CC02D1D29516527A693F5C62@MN2PR01MB5902.prod.exchangelabs.com Signed-off-by: Shubhang Kaushik <shubhang@os.amperecomputing.com> Reviewed-by: Christoph Lameter (Ampere) <cl@linux.com> Cc: Christoph Lameter <cl@linux.com> Cc: Guo Ren <guoren@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Uladzislau Rezki (Sony) <urezki@gmail.com> Cc: Xiongwei Song <xiongwei.song@windriver.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
leberus
pushed a commit
to leberus/linux
that referenced
this pull request
Jul 4, 2024
…stics 'vmap allocation for size %lu failed: use vmalloc=<size> to increase size' The above warning is seen in the kernel functionality for allocation of the restricted virtual memory range till exhaustion. This message is misleading because 'vmalloc=' is supported on arm32, x86 platforms and is not a valid kernel parameter on a number of other platforms (in particular its not supported on arm64, alpha, loongarch, arc, csky, hexagon, microblaze, mips, nios2, openrisc, parisc, m64k, powerpc, riscv, sh, um, xtensa, s390, sparc). With the update, the output gets modified to include the function parameters along with the start and end of the virtual memory range allowed. The warning message after fix on kernel version 6.10.0-rc1+: vmalloc_node_range for size 33619968 failed: Address range restricted between 0xffff800082640000 - 0xffff800084650000 Backtrace with the misleading error message: vmap allocation for size 33619968 failed: use vmalloc=<size> to increase size insmod: vmalloc error: size 33554432, vm_struct allocation failed, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 46 PID: 1977 Comm: insmod Tainted: G E 6.10.0-rc1+ torvalds#79 Hardware name: INGRASYS Yushan Server iSystem TEMP-S000141176+10/Yushan Motherboard, BIOS 2.10.20230517 (SCP: xxx) yyyy/mm/dd Call trace: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x78/0x90 dump_stack+0x18/0x28 warn_alloc+0x12c/0x1b8 __vmalloc_node_range_noprof+0x28c/0x7e0 custom_init+0xb4/0xfff8 [test_driver] do_one_initcall+0x60/0x290 do_init_module+0x68/0x250 load_module+0x236c/0x2428 init_module_from_file+0x8c/0xd8 __arm64_sys_finit_module+0x1b4/0x388 invoke_syscall+0x78/0x108 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x130 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x190/0x198 [Shubhang@os.amperecomputing.com: v5] Link: https://lkml.kernel.org/r/CH2PR01MB5894B0182EA0B28DF2EFB916F5C72@CH2PR01MB5894.prod.exchangelabs.com Link: https://lkml.kernel.org/r/MN2PR01MB59025CC02D1D29516527A693F5C62@MN2PR01MB5902.prod.exchangelabs.com Signed-off-by: Shubhang Kaushik <shubhang@os.amperecomputing.com> Reviewed-by: Christoph Lameter (Ampere) <cl@linux.com> Cc: Christoph Lameter <cl@linux.com> Cc: Guo Ren <guoren@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Uladzislau Rezki (Sony) <urezki@gmail.com> Cc: Xiongwei Song <xiongwei.song@windriver.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ioworker0
pushed a commit
to ioworker0/linux
that referenced
this pull request
Jul 12, 2024
When tries to demote 1G hugetlb folios, a lockdep warning is observed: ============================================ WARNING: possible recursive locking detected 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Not tainted -------------------------------------------- bash/710 is trying to acquire lock: ffffffff8f0a7850 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0x244/0x460 but task is already holding lock: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&h->resize_lock); lock(&h->resize_lock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by bash/710: #0: ffff8f118439c3f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff8f11893b9e88 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff8f1183dc4428 (kn->active#98){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 stack backtrace: CPU: 3 PID: 710 Comm: bash Not tainted 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 __lock_acquire+0x10f2/0x1ca0 lock_acquire+0xbe/0x2d0 __mutex_lock+0x6d/0x400 demote_store+0x244/0x460 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa61db14887 RSP: 002b:00007ffc56c48358 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fa61db14887 RDX: 0000000000000002 RSI: 000055a030050220 RDI: 0000000000000001 RBP: 000055a030050220 R08: 00007fa61dbd1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 00007fa61dc1b780 R14: 00007fa61dc17600 R15: 00007fa61dc16a00 </TASK> Lockdep considers this an AA deadlock because the different resize_lock mutexes reside in the same lockdep class, but this is a false positive. Place them in distinct classes to avoid these warnings. Link: https://lkml.kernel.org/r/20240712031314.2570452-1-linmiaohe@huawei.com Fixes: 8531fc6 ("hugetlb: add hugetlb demote page support") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Acked-by: Muchun Song <muchun.song@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ioworker0
pushed a commit
to ioworker0/linux
that referenced
this pull request
Jul 13, 2024
When tries to demote 1G hugetlb folios, a lockdep warning is observed: ============================================ WARNING: possible recursive locking detected 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Not tainted -------------------------------------------- bash/710 is trying to acquire lock: ffffffff8f0a7850 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0x244/0x460 but task is already holding lock: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&h->resize_lock); lock(&h->resize_lock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by bash/710: #0: ffff8f118439c3f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff8f11893b9e88 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff8f1183dc4428 (kn->active#98){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 stack backtrace: CPU: 3 PID: 710 Comm: bash Not tainted 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 __lock_acquire+0x10f2/0x1ca0 lock_acquire+0xbe/0x2d0 __mutex_lock+0x6d/0x400 demote_store+0x244/0x460 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa61db14887 RSP: 002b:00007ffc56c48358 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fa61db14887 RDX: 0000000000000002 RSI: 000055a030050220 RDI: 0000000000000001 RBP: 000055a030050220 R08: 00007fa61dbd1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 00007fa61dc1b780 R14: 00007fa61dc17600 R15: 00007fa61dc16a00 </TASK> Lockdep considers this an AA deadlock because the different resize_lock mutexes reside in the same lockdep class, but this is a false positive. Place them in distinct classes to avoid these warnings. Link: https://lkml.kernel.org/r/20240712031314.2570452-1-linmiaohe@huawei.com Fixes: 8531fc6 ("hugetlb: add hugetlb demote page support") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Acked-by: Muchun Song <muchun.song@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ioworker0
pushed a commit
to ioworker0/linux
that referenced
this pull request
Jul 16, 2024
When tries to demote 1G hugetlb folios, a lockdep warning is observed: ============================================ WARNING: possible recursive locking detected 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Not tainted -------------------------------------------- bash/710 is trying to acquire lock: ffffffff8f0a7850 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0x244/0x460 but task is already holding lock: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&h->resize_lock); lock(&h->resize_lock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by bash/710: #0: ffff8f118439c3f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff8f11893b9e88 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff8f1183dc4428 (kn->active#98){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 stack backtrace: CPU: 3 PID: 710 Comm: bash Not tainted 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 __lock_acquire+0x10f2/0x1ca0 lock_acquire+0xbe/0x2d0 __mutex_lock+0x6d/0x400 demote_store+0x244/0x460 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa61db14887 RSP: 002b:00007ffc56c48358 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fa61db14887 RDX: 0000000000000002 RSI: 000055a030050220 RDI: 0000000000000001 RBP: 000055a030050220 R08: 00007fa61dbd1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 00007fa61dc1b780 R14: 00007fa61dc17600 R15: 00007fa61dc16a00 </TASK> Lockdep considers this an AA deadlock because the different resize_lock mutexes reside in the same lockdep class, but this is a false positive. Place them in distinct classes to avoid these warnings. Link: https://lkml.kernel.org/r/20240712031314.2570452-1-linmiaohe@huawei.com Fixes: 8531fc6 ("hugetlb: add hugetlb demote page support") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Acked-by: Muchun Song <muchun.song@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ioworker0
pushed a commit
to ioworker0/linux
that referenced
this pull request
Jul 16, 2024
When tries to demote 1G hugetlb folios, a lockdep warning is observed: ============================================ WARNING: possible recursive locking detected 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Not tainted -------------------------------------------- bash/710 is trying to acquire lock: ffffffff8f0a7850 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0x244/0x460 but task is already holding lock: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&h->resize_lock); lock(&h->resize_lock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by bash/710: #0: ffff8f118439c3f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff8f11893b9e88 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff8f1183dc4428 (kn->active#98){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 stack backtrace: CPU: 3 PID: 710 Comm: bash Not tainted 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 __lock_acquire+0x10f2/0x1ca0 lock_acquire+0xbe/0x2d0 __mutex_lock+0x6d/0x400 demote_store+0x244/0x460 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa61db14887 RSP: 002b:00007ffc56c48358 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fa61db14887 RDX: 0000000000000002 RSI: 000055a030050220 RDI: 0000000000000001 RBP: 000055a030050220 R08: 00007fa61dbd1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 00007fa61dc1b780 R14: 00007fa61dc17600 R15: 00007fa61dc16a00 </TASK> Lockdep considers this an AA deadlock because the different resize_lock mutexes reside in the same lockdep class, but this is a false positive. Place them in distinct classes to avoid these warnings. Link: https://lkml.kernel.org/r/20240712031314.2570452-1-linmiaohe@huawei.com Fixes: 8531fc6 ("hugetlb: add hugetlb demote page support") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Acked-by: Muchun Song <muchun.song@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ioworker0
pushed a commit
to ioworker0/linux
that referenced
this pull request
Jul 17, 2024
When tries to demote 1G hugetlb folios, a lockdep warning is observed: ============================================ WARNING: possible recursive locking detected 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Not tainted -------------------------------------------- bash/710 is trying to acquire lock: ffffffff8f0a7850 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0x244/0x460 but task is already holding lock: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&h->resize_lock); lock(&h->resize_lock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by bash/710: #0: ffff8f118439c3f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff8f11893b9e88 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff8f1183dc4428 (kn->active#98){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 stack backtrace: CPU: 3 PID: 710 Comm: bash Not tainted 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 __lock_acquire+0x10f2/0x1ca0 lock_acquire+0xbe/0x2d0 __mutex_lock+0x6d/0x400 demote_store+0x244/0x460 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa61db14887 RSP: 002b:00007ffc56c48358 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fa61db14887 RDX: 0000000000000002 RSI: 000055a030050220 RDI: 0000000000000001 RBP: 000055a030050220 R08: 00007fa61dbd1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 00007fa61dc1b780 R14: 00007fa61dc17600 R15: 00007fa61dc16a00 </TASK> Lockdep considers this an AA deadlock because the different resize_lock mutexes reside in the same lockdep class, but this is a false positive. Place them in distinct classes to avoid these warnings. Link: https://lkml.kernel.org/r/20240712031314.2570452-1-linmiaohe@huawei.com Fixes: 8531fc6 ("hugetlb: add hugetlb demote page support") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Acked-by: Muchun Song <muchun.song@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
rgushchin
pushed a commit
to rgushchin/linux
that referenced
this pull request
Jul 18, 2024
When tries to demote 1G hugetlb folios, a lockdep warning is observed: ============================================ WARNING: possible recursive locking detected 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Not tainted -------------------------------------------- bash/710 is trying to acquire lock: ffffffff8f0a7850 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0x244/0x460 but task is already holding lock: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&h->resize_lock); lock(&h->resize_lock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by bash/710: #0: ffff8f118439c3f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff8f11893b9e88 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff8f1183dc4428 (kn->active#98){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 stack backtrace: CPU: 3 PID: 710 Comm: bash Not tainted 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 __lock_acquire+0x10f2/0x1ca0 lock_acquire+0xbe/0x2d0 __mutex_lock+0x6d/0x400 demote_store+0x244/0x460 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa61db14887 RSP: 002b:00007ffc56c48358 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fa61db14887 RDX: 0000000000000002 RSI: 000055a030050220 RDI: 0000000000000001 RBP: 000055a030050220 R08: 00007fa61dbd1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 00007fa61dc1b780 R14: 00007fa61dc17600 R15: 00007fa61dc16a00 </TASK> Lockdep considers this an AA deadlock because the different resize_lock mutexes reside in the same lockdep class, but this is a false positive. Place them in distinct classes to avoid these warnings. Link: https://lkml.kernel.org/r/20240712031314.2570452-1-linmiaohe@huawei.com Fixes: 8531fc6 ("hugetlb: add hugetlb demote page support") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Acked-by: Muchun Song <muchun.song@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Jul 30, 2024
commit 667574e upstream. When tries to demote 1G hugetlb folios, a lockdep warning is observed: ============================================ WARNING: possible recursive locking detected 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Not tainted -------------------------------------------- bash/710 is trying to acquire lock: ffffffff8f0a7850 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0x244/0x460 but task is already holding lock: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&h->resize_lock); lock(&h->resize_lock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by bash/710: #0: ffff8f118439c3f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff8f11893b9e88 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff8f1183dc4428 (kn->active#98){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 stack backtrace: CPU: 3 PID: 710 Comm: bash Not tainted 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 __lock_acquire+0x10f2/0x1ca0 lock_acquire+0xbe/0x2d0 __mutex_lock+0x6d/0x400 demote_store+0x244/0x460 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa61db14887 RSP: 002b:00007ffc56c48358 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fa61db14887 RDX: 0000000000000002 RSI: 000055a030050220 RDI: 0000000000000001 RBP: 000055a030050220 R08: 00007fa61dbd1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 00007fa61dc1b780 R14: 00007fa61dc17600 R15: 00007fa61dc16a00 </TASK> Lockdep considers this an AA deadlock because the different resize_lock mutexes reside in the same lockdep class, but this is a false positive. Place them in distinct classes to avoid these warnings. Link: https://lkml.kernel.org/r/20240712031314.2570452-1-linmiaohe@huawei.com Fixes: 8531fc6 ("hugetlb: add hugetlb demote page support") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Acked-by: Muchun Song <muchun.song@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Jul 30, 2024
commit 667574e upstream. When tries to demote 1G hugetlb folios, a lockdep warning is observed: ============================================ WARNING: possible recursive locking detected 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Not tainted -------------------------------------------- bash/710 is trying to acquire lock: ffffffff8f0a7850 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0x244/0x460 but task is already holding lock: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&h->resize_lock); lock(&h->resize_lock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by bash/710: #0: ffff8f118439c3f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff8f11893b9e88 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff8f1183dc4428 (kn->active#98){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 stack backtrace: CPU: 3 PID: 710 Comm: bash Not tainted 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 __lock_acquire+0x10f2/0x1ca0 lock_acquire+0xbe/0x2d0 __mutex_lock+0x6d/0x400 demote_store+0x244/0x460 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa61db14887 RSP: 002b:00007ffc56c48358 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fa61db14887 RDX: 0000000000000002 RSI: 000055a030050220 RDI: 0000000000000001 RBP: 000055a030050220 R08: 00007fa61dbd1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 00007fa61dc1b780 R14: 00007fa61dc17600 R15: 00007fa61dc16a00 </TASK> Lockdep considers this an AA deadlock because the different resize_lock mutexes reside in the same lockdep class, but this is a false positive. Place them in distinct classes to avoid these warnings. Link: https://lkml.kernel.org/r/20240712031314.2570452-1-linmiaohe@huawei.com Fixes: 8531fc6 ("hugetlb: add hugetlb demote page support") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Acked-by: Muchun Song <muchun.song@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Jul 30, 2024
commit 667574e upstream. When tries to demote 1G hugetlb folios, a lockdep warning is observed: ============================================ WARNING: possible recursive locking detected 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Not tainted -------------------------------------------- bash/710 is trying to acquire lock: ffffffff8f0a7850 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0x244/0x460 but task is already holding lock: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&h->resize_lock); lock(&h->resize_lock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by bash/710: #0: ffff8f118439c3f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff8f11893b9e88 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff8f1183dc4428 (kn->active#98){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 stack backtrace: CPU: 3 PID: 710 Comm: bash Not tainted 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 __lock_acquire+0x10f2/0x1ca0 lock_acquire+0xbe/0x2d0 __mutex_lock+0x6d/0x400 demote_store+0x244/0x460 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa61db14887 RSP: 002b:00007ffc56c48358 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fa61db14887 RDX: 0000000000000002 RSI: 000055a030050220 RDI: 0000000000000001 RBP: 000055a030050220 R08: 00007fa61dbd1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 00007fa61dc1b780 R14: 00007fa61dc17600 R15: 00007fa61dc16a00 </TASK> Lockdep considers this an AA deadlock because the different resize_lock mutexes reside in the same lockdep class, but this is a false positive. Place them in distinct classes to avoid these warnings. Link: https://lkml.kernel.org/r/20240712031314.2570452-1-linmiaohe@huawei.com Fixes: 8531fc6 ("hugetlb: add hugetlb demote page support") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Acked-by: Muchun Song <muchun.song@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Jul 30, 2024
commit 667574e upstream. When tries to demote 1G hugetlb folios, a lockdep warning is observed: ============================================ WARNING: possible recursive locking detected 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Not tainted -------------------------------------------- bash/710 is trying to acquire lock: ffffffff8f0a7850 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0x244/0x460 but task is already holding lock: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&h->resize_lock); lock(&h->resize_lock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by bash/710: #0: ffff8f118439c3f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff8f11893b9e88 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff8f1183dc4428 (kn->active#98){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 stack backtrace: CPU: 3 PID: 710 Comm: bash Not tainted 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 __lock_acquire+0x10f2/0x1ca0 lock_acquire+0xbe/0x2d0 __mutex_lock+0x6d/0x400 demote_store+0x244/0x460 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa61db14887 RSP: 002b:00007ffc56c48358 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fa61db14887 RDX: 0000000000000002 RSI: 000055a030050220 RDI: 0000000000000001 RBP: 000055a030050220 R08: 00007fa61dbd1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 00007fa61dc1b780 R14: 00007fa61dc17600 R15: 00007fa61dc16a00 </TASK> Lockdep considers this an AA deadlock because the different resize_lock mutexes reside in the same lockdep class, but this is a false positive. Place them in distinct classes to avoid these warnings. Link: https://lkml.kernel.org/r/20240712031314.2570452-1-linmiaohe@huawei.com Fixes: 8531fc6 ("hugetlb: add hugetlb demote page support") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Acked-by: Muchun Song <muchun.song@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kaz205
pushed a commit
to Kaz205/linux
that referenced
this pull request
Jul 31, 2024
commit 667574e upstream. When tries to demote 1G hugetlb folios, a lockdep warning is observed: ============================================ WARNING: possible recursive locking detected 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Not tainted -------------------------------------------- bash/710 is trying to acquire lock: ffffffff8f0a7850 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0x244/0x460 but task is already holding lock: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&h->resize_lock); lock(&h->resize_lock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by bash/710: #0: ffff8f118439c3f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff8f11893b9e88 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff8f1183dc4428 (kn->active#98){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 stack backtrace: CPU: 3 PID: 710 Comm: bash Not tainted 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 __lock_acquire+0x10f2/0x1ca0 lock_acquire+0xbe/0x2d0 __mutex_lock+0x6d/0x400 demote_store+0x244/0x460 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa61db14887 RSP: 002b:00007ffc56c48358 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fa61db14887 RDX: 0000000000000002 RSI: 000055a030050220 RDI: 0000000000000001 RBP: 000055a030050220 R08: 00007fa61dbd1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 00007fa61dc1b780 R14: 00007fa61dc17600 R15: 00007fa61dc16a00 </TASK> Lockdep considers this an AA deadlock because the different resize_lock mutexes reside in the same lockdep class, but this is a false positive. Place them in distinct classes to avoid these warnings. Link: https://lkml.kernel.org/r/20240712031314.2570452-1-linmiaohe@huawei.com Fixes: 8531fc6 ("hugetlb: add hugetlb demote page support") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Acked-by: Muchun Song <muchun.song@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Jul 31, 2024
commit 667574e upstream. When tries to demote 1G hugetlb folios, a lockdep warning is observed: ============================================ WARNING: possible recursive locking detected 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Not tainted -------------------------------------------- bash/710 is trying to acquire lock: ffffffff8f0a7850 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0x244/0x460 but task is already holding lock: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&h->resize_lock); lock(&h->resize_lock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by bash/710: #0: ffff8f118439c3f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff8f11893b9e88 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff8f1183dc4428 (kn->active#98){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 stack backtrace: CPU: 3 PID: 710 Comm: bash Not tainted 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 __lock_acquire+0x10f2/0x1ca0 lock_acquire+0xbe/0x2d0 __mutex_lock+0x6d/0x400 demote_store+0x244/0x460 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa61db14887 RSP: 002b:00007ffc56c48358 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fa61db14887 RDX: 0000000000000002 RSI: 000055a030050220 RDI: 0000000000000001 RBP: 000055a030050220 R08: 00007fa61dbd1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 00007fa61dc1b780 R14: 00007fa61dc17600 R15: 00007fa61dc16a00 </TASK> Lockdep considers this an AA deadlock because the different resize_lock mutexes reside in the same lockdep class, but this is a false positive. Place them in distinct classes to avoid these warnings. Link: https://lkml.kernel.org/r/20240712031314.2570452-1-linmiaohe@huawei.com Fixes: 8531fc6 ("hugetlb: add hugetlb demote page support") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Acked-by: Muchun Song <muchun.song@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kaz205
pushed a commit
to Kaz205/linux
that referenced
this pull request
Jul 31, 2024
commit 667574e upstream. When tries to demote 1G hugetlb folios, a lockdep warning is observed: ============================================ WARNING: possible recursive locking detected 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Not tainted -------------------------------------------- bash/710 is trying to acquire lock: ffffffff8f0a7850 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0x244/0x460 but task is already holding lock: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&h->resize_lock); lock(&h->resize_lock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by bash/710: #0: ffff8f118439c3f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff8f11893b9e88 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff8f1183dc4428 (kn->active#98){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 stack backtrace: CPU: 3 PID: 710 Comm: bash Not tainted 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 __lock_acquire+0x10f2/0x1ca0 lock_acquire+0xbe/0x2d0 __mutex_lock+0x6d/0x400 demote_store+0x244/0x460 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa61db14887 RSP: 002b:00007ffc56c48358 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fa61db14887 RDX: 0000000000000002 RSI: 000055a030050220 RDI: 0000000000000001 RBP: 000055a030050220 R08: 00007fa61dbd1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 00007fa61dc1b780 R14: 00007fa61dc17600 R15: 00007fa61dc16a00 </TASK> Lockdep considers this an AA deadlock because the different resize_lock mutexes reside in the same lockdep class, but this is a false positive. Place them in distinct classes to avoid these warnings. Link: https://lkml.kernel.org/r/20240712031314.2570452-1-linmiaohe@huawei.com Fixes: 8531fc6 ("hugetlb: add hugetlb demote page support") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Acked-by: Muchun Song <muchun.song@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Aug 1, 2024
commit 667574e upstream. When tries to demote 1G hugetlb folios, a lockdep warning is observed: ============================================ WARNING: possible recursive locking detected 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Not tainted -------------------------------------------- bash/710 is trying to acquire lock: ffffffff8f0a7850 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0x244/0x460 but task is already holding lock: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&h->resize_lock); lock(&h->resize_lock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by bash/710: #0: ffff8f118439c3f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff8f11893b9e88 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff8f1183dc4428 (kn->active#98){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 stack backtrace: CPU: 3 PID: 710 Comm: bash Not tainted 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 __lock_acquire+0x10f2/0x1ca0 lock_acquire+0xbe/0x2d0 __mutex_lock+0x6d/0x400 demote_store+0x244/0x460 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa61db14887 RSP: 002b:00007ffc56c48358 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fa61db14887 RDX: 0000000000000002 RSI: 000055a030050220 RDI: 0000000000000001 RBP: 000055a030050220 R08: 00007fa61dbd1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 00007fa61dc1b780 R14: 00007fa61dc17600 R15: 00007fa61dc16a00 </TASK> Lockdep considers this an AA deadlock because the different resize_lock mutexes reside in the same lockdep class, but this is a false positive. Place them in distinct classes to avoid these warnings. Link: https://lkml.kernel.org/r/20240712031314.2570452-1-linmiaohe@huawei.com Fixes: 8531fc6 ("hugetlb: add hugetlb demote page support") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Acked-by: Muchun Song <muchun.song@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
kraj
pushed a commit
to kraj/linux
that referenced
this pull request
Aug 3, 2024
commit 667574e upstream. When tries to demote 1G hugetlb folios, a lockdep warning is observed: ============================================ WARNING: possible recursive locking detected 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Not tainted -------------------------------------------- bash/710 is trying to acquire lock: ffffffff8f0a7850 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0x244/0x460 but task is already holding lock: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&h->resize_lock); lock(&h->resize_lock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by bash/710: #0: ffff8f118439c3f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff8f11893b9e88 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff8f1183dc4428 (kn->active#98){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 stack backtrace: CPU: 3 PID: 710 Comm: bash Not tainted 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 __lock_acquire+0x10f2/0x1ca0 lock_acquire+0xbe/0x2d0 __mutex_lock+0x6d/0x400 demote_store+0x244/0x460 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa61db14887 RSP: 002b:00007ffc56c48358 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fa61db14887 RDX: 0000000000000002 RSI: 000055a030050220 RDI: 0000000000000001 RBP: 000055a030050220 R08: 00007fa61dbd1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 00007fa61dc1b780 R14: 00007fa61dc17600 R15: 00007fa61dc16a00 </TASK> Lockdep considers this an AA deadlock because the different resize_lock mutexes reside in the same lockdep class, but this is a false positive. Place them in distinct classes to avoid these warnings. Link: https://lkml.kernel.org/r/20240712031314.2570452-1-linmiaohe@huawei.com Fixes: 8531fc6 ("hugetlb: add hugetlb demote page support") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Acked-by: Muchun Song <muchun.song@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Aug 3, 2024
commit 667574e upstream. When tries to demote 1G hugetlb folios, a lockdep warning is observed: ============================================ WARNING: possible recursive locking detected 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Not tainted -------------------------------------------- bash/710 is trying to acquire lock: ffffffff8f0a7850 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0x244/0x460 but task is already holding lock: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&h->resize_lock); lock(&h->resize_lock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by bash/710: #0: ffff8f118439c3f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff8f11893b9e88 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff8f1183dc4428 (kn->active#98){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 stack backtrace: CPU: 3 PID: 710 Comm: bash Not tainted 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 __lock_acquire+0x10f2/0x1ca0 lock_acquire+0xbe/0x2d0 __mutex_lock+0x6d/0x400 demote_store+0x244/0x460 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa61db14887 RSP: 002b:00007ffc56c48358 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fa61db14887 RDX: 0000000000000002 RSI: 000055a030050220 RDI: 0000000000000001 RBP: 000055a030050220 R08: 00007fa61dbd1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 00007fa61dc1b780 R14: 00007fa61dc17600 R15: 00007fa61dc16a00 </TASK> Lockdep considers this an AA deadlock because the different resize_lock mutexes reside in the same lockdep class, but this is a false positive. Place them in distinct classes to avoid these warnings. Link: https://lkml.kernel.org/r/20240712031314.2570452-1-linmiaohe@huawei.com Fixes: 8531fc6 ("hugetlb: add hugetlb demote page support") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Acked-by: Muchun Song <muchun.song@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Aug 3, 2024
commit 667574e upstream. When tries to demote 1G hugetlb folios, a lockdep warning is observed: ============================================ WARNING: possible recursive locking detected 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Not tainted -------------------------------------------- bash/710 is trying to acquire lock: ffffffff8f0a7850 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0x244/0x460 but task is already holding lock: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&h->resize_lock); lock(&h->resize_lock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by bash/710: #0: ffff8f118439c3f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff8f11893b9e88 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff8f1183dc4428 (kn->active#98){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 stack backtrace: CPU: 3 PID: 710 Comm: bash Not tainted 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 __lock_acquire+0x10f2/0x1ca0 lock_acquire+0xbe/0x2d0 __mutex_lock+0x6d/0x400 demote_store+0x244/0x460 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa61db14887 RSP: 002b:00007ffc56c48358 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fa61db14887 RDX: 0000000000000002 RSI: 000055a030050220 RDI: 0000000000000001 RBP: 000055a030050220 R08: 00007fa61dbd1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 00007fa61dc1b780 R14: 00007fa61dc17600 R15: 00007fa61dc16a00 </TASK> Lockdep considers this an AA deadlock because the different resize_lock mutexes reside in the same lockdep class, but this is a false positive. Place them in distinct classes to avoid these warnings. Link: https://lkml.kernel.org/r/20240712031314.2570452-1-linmiaohe@huawei.com Fixes: 8531fc6 ("hugetlb: add hugetlb demote page support") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Acked-by: Muchun Song <muchun.song@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1054009064
pushed a commit
to 1054009064/linux
that referenced
this pull request
Sep 9, 2024
commit 667574e upstream. When tries to demote 1G hugetlb folios, a lockdep warning is observed: ============================================ WARNING: possible recursive locking detected 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Not tainted -------------------------------------------- bash/710 is trying to acquire lock: ffffffff8f0a7850 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0x244/0x460 but task is already holding lock: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&h->resize_lock); lock(&h->resize_lock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by bash/710: #0: ffff8f118439c3f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff8f11893b9e88 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff8f1183dc4428 (kn->active#98){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 stack backtrace: CPU: 3 PID: 710 Comm: bash Not tainted 6.10.0-rc6-00452-ga4d0275fa660-dirty torvalds#79 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 __lock_acquire+0x10f2/0x1ca0 lock_acquire+0xbe/0x2d0 __mutex_lock+0x6d/0x400 demote_store+0x244/0x460 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa61db14887 RSP: 002b:00007ffc56c48358 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fa61db14887 RDX: 0000000000000002 RSI: 000055a030050220 RDI: 0000000000000001 RBP: 000055a030050220 R08: 00007fa61dbd1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 00007fa61dc1b780 R14: 00007fa61dc17600 R15: 00007fa61dc16a00 </TASK> Lockdep considers this an AA deadlock because the different resize_lock mutexes reside in the same lockdep class, but this is a false positive. Place them in distinct classes to avoid these warnings. Link: https://lkml.kernel.org/r/20240712031314.2570452-1-linmiaohe@huawei.com Fixes: 8531fc6 ("hugetlb: add hugetlb demote page support") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Acked-by: Muchun Song <muchun.song@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In a list of items, the other items end in a period. Adding a period to make the list items consistent.