fix crypto4xx_core.c compilation error #33
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
…x_core.c: error: 'THIS_MODULE' undeclared here"
|
Linus typically doesn't do pull requests via GitHub AFAIK. |
VaibhavBedia-xx
pushed a commit
to VaibhavBedia-xx/linux
that referenced
this pull request
Jul 25, 2013
ERROR: do not initialise statics to 0 or NULL torvalds#24: FILE: scripts/pnmtologo.c:77: +static int is_plain_pbm = 0; WARNING: line over 80 characters torvalds#33: FILE: scripts/pnmtologo.c:108: + * between the digits. This is Ok cause we know a PBM can only have a '1' total: 1 errors, 1 warnings, 25 lines checked ./patches/scripts-pnmtologo-fix-for-plain-pbm.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: Andreas Bießmann <andreas@biessmann.de> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
swarren
pushed a commit
to swarren/linux-tegra
that referenced
this pull request
Oct 14, 2013
As the new x86 CPU bootup printout format code maintainer, I am taking immediate action to improve and clean (and thus indulge my OCD) the reporting of the cores when coming up online. Fix padding to a right-hand alignment, cleanup code and bind reporting width to the max number of supported CPUs on the system, like this: [ 0.074509] smpboot: Booting Node 0, Processors: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 OK [ 0.644008] smpboot: Booting Node 1, Processors: torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 OK [ 1.245006] smpboot: Booting Node 2, Processors: torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 OK [ 1.864005] smpboot: Booting Node 3, Processors: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 OK [ 2.489005] smpboot: Booting Node 4, Processors: torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 OK [ 3.093005] smpboot: Booting Node 5, Processors: torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 OK [ 3.698005] smpboot: Booting Node 6, Processors: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 OK [ 4.304005] smpboot: Booting Node 7, Processors: torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 OK [ 4.961413] Brought up 64 CPUs and this: [ 0.072367] smpboot: Booting Node 0, Processors: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 OK [ 0.686329] Brought up 8 CPUs Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Libin <huawei.libin@huawei.com> Cc: wangyijing@huawei.com Cc: fenghua.yu@intel.com Cc: guohanjun@huawei.com Cc: paul.gortmaker@windriver.com Link: http://lkml.kernel.org/r/20130927143554.GF4422@pd.tnic Signed-off-by: Ingo Molnar <mingo@kernel.org>
swarren
pushed a commit
to swarren/linux-tegra
that referenced
this pull request
Oct 14, 2013
Turn it into (for example): [ 0.073380] x86: Booting SMP configuration: [ 0.074005] .... node #0, CPUs: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 [ 0.603005] .... node #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>
swarren
pushed a commit
to swarren/linux-tegra
that referenced
this pull request
Feb 12, 2014
In function talitos_probe(), it will jump to err_out when getting an error in talitos_probe_irq(). Then the uninitialized list head priv->alg_list will be used in function talitos_remove(). In this case we would get a call trace like the following. So move up the initialization of priv->alg_list. Unable to handle kernel paging request for data at address 0x00000000 Faulting instruction address: 0xc0459ff4 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=8 P1020 RDB Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 3.13.0-08789-g54c0a4b46150 torvalds#33 task: cf050000 ti: cf04c000 task.ti: cf04c000 NIP: c0459ff4 LR: c0459fd4 CTR: c02f2438 REGS: cf04dcb0 TRAP: 0300 Tainted: G W (3.13.0-08789-g54c0a4b46150) MSR: 00029000 <CE,EE,ME> CR: 82000028 XER: 20000000 DEAR: 00000000 ESR: 00000000 GPR00: c045ac28 cf04dd60 cf050000 cf2579c0 00021000 00000000 c02f35b0 0000014e GPR08: c07e702c cf104300 c07e702c 0000014e 22000024 00000000 c0002a3c 00000000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 c082e4e0 000000df GPR24: 00000000 00100100 00200200 cf257a2c cf0efe10 cf2579c0 cf0efe10 00000000 NIP [c0459ff4] talitos_remove+0x3c/0x1c8 LR [c0459fd4] talitos_remove+0x1c/0x1c8 Call Trace: [cf04dd60] [c07485d8] __func__.13331+0x1241c8/0x1391c0 (unreliable) [cf04dd90] [c045ac28] talitos_probe+0x244/0x998 [cf04dde0] [c0306a74] platform_drv_probe+0x28/0x68 [cf04ddf0] [c0304d38] really_probe+0x78/0x250 [cf04de10] [c030505c] __driver_attach+0xc8/0xcc [cf04de30] [c0302e98] bus_for_each_dev+0x6c/0xb8 [cf04de60] [c03043cc] bus_add_driver+0x168/0x220 [cf04de80] [c0305798] driver_register+0x88/0x130 [cf04de90] [c0002458] do_one_initcall+0x14c/0x198 [cf04df00] [c079f904] kernel_init_freeable+0x138/0x1d4 [cf04df30] [c0002a50] kernel_init+0x14/0x124 [cf04df40] [c000ec40] ret_from_kernel_thread+0x5c/0x64 Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
swarren
pushed a commit
to swarren/linux-tegra
that referenced
this pull request
Mar 3, 2014
Currently, at module removal, one gets the following warnings: ------------[ cut here ]------------ WARNING: at drivers/clk/clk.c:780 clk_disable+0x18/0x24() Modules linked in: spi_imx(-) [last unloaded: ev76c560] CPU: 1 PID: 16337 Comm: rmmod Tainted: G W 3.10.17-80548-g90191eb-dirty torvalds#33 [<80013b4c>] (unwind_backtrace+0x0/0xf8) from [<800115dc>] (show_stack+0x10/0x14) [<800115dc>] (show_stack+0x10/0x14) from [<800257b8>] (warn_slowpath_common+0x4c/0x68) [<800257b8>] (warn_slowpath_common+0x4c/0x68) from [<800257f0>] (warn_slowpath_null+0x1c/0x24) [<800257f0>] (warn_slowpath_null+0x1c/0x24) from [<803f60ec>] (clk_disable+0x18/0x24) [<803f60ec>] (clk_disable+0x18/0x24) from [<7f02c9cc>] (spi_imx_remove+0x54/0x9c [spi_imx]) [<7f02c9cc>] (spi_imx_remove+0x54/0x9c [spi_imx]) from [<8025868c>] (platform_drv_remove+0x18/0x1c) [<8025868c>] (platform_drv_remove+0x18/0x1c) from [<80256f60>] (__device_release_driver+0x70/0xcc) [<80256f60>] (__device_release_driver+0x70/0xcc) from [<80257770>] (driver_detach+0xcc/0xd0) [<80257770>] (driver_detach+0xcc/0xd0) from [<80256d90>] (bus_remove_driver+0x7c/0xc0) [<80256d90>] (bus_remove_driver+0x7c/0xc0) from [<80068668>] (SyS_delete_module+0x144/0x1f8) [<80068668>] (SyS_delete_module+0x144/0x1f8) from [<8000e080>] (ret_fast_syscall+0x0/0x30) ---[ end trace 1f5df9ad54996300 ]--- ------------[ cut here ]------------ WARNING: at drivers/clk/clk.c:780 clk_disable+0x18/0x24() Modules linked in: spi_imx(-) [last unloaded: ev76c560] CPU: 1 PID: 16337 Comm: rmmod Tainted: G W 3.10.17-80548-g90191eb-dirty torvalds#33 [<80013b4c>] (unwind_backtrace+0x0/0xf8) from [<800115dc>] (show_stack+0x10/0x14) [<800115dc>] (show_stack+0x10/0x14) from [<800257b8>] (warn_slowpath_common+0x4c/0x68) [<800257b8>] (warn_slowpath_common+0x4c/0x68) from [<800257f0>] (warn_slowpath_null+0x1c/0x24) [<800257f0>] (warn_slowpath_null+0x1c/0x24) from [<803f60ec>] (clk_disable+0x18/0x24) [<803f60ec>] (clk_disable+0x18/0x24) from [<7f02c9e8>] (spi_imx_remove+0x70/0x9c [spi_imx]) [<7f02c9e8>] (spi_imx_remove+0x70/0x9c [spi_imx]) from [<8025868c>] (platform_drv_remove+0x18/0x1c) [<8025868c>] (platform_drv_remove+0x18/0x1c) from [<80256f60>] (__device_release_driver+0x70/0xcc) [<80256f60>] (__device_release_driver+0x70/0xcc) from [<80257770>] (driver_detach+0xcc/0xd0) [<80257770>] (driver_detach+0xcc/0xd0) from [<80256d90>] (bus_remove_driver+0x7c/0xc0) [<80256d90>] (bus_remove_driver+0x7c/0xc0) from [<80068668>] (SyS_delete_module+0x144/0x1f8) [<80068668>] (SyS_delete_module+0x144/0x1f8) from [<8000e080>] (ret_fast_syscall+0x0/0x30) ---[ end trace 1f5df9ad54996301 ]--- Since commit 9e556dc, "spi: spi-imx: only enable the clocks when we start to transfer a message", clocks are always disabled except when transmitting messages. There is thus no need to disable them at module removal. Fixes: 9e556dc (spi: spi-imx: only enable the clocks when we start to transfer a message) Signed-off-by: Philippe De Muyter <phdm@macqel.be> Acked-by: Huang Shijie <b32955@freescale.com> Signed-off-by: Mark Brown <broonie@linaro.org> Cc: stable@vger.kernel.org
brianlilly
pushed a commit
to crystalfontz/cfa_10036_kernel
that referenced
this pull request
Mar 26, 2014
commit fd40dcc upstream. Currently, at module removal, one gets the following warnings: ------------[ cut here ]------------ WARNING: at drivers/clk/clk.c:780 clk_disable+0x18/0x24() Modules linked in: spi_imx(-) [last unloaded: ev76c560] CPU: 1 PID: 16337 Comm: rmmod Tainted: G W 3.10.17-80548-g90191eb-dirty torvalds#33 [<80013b4c>] (unwind_backtrace+0x0/0xf8) from [<800115dc>] (show_stack+0x10/0x14) [<800115dc>] (show_stack+0x10/0x14) from [<800257b8>] (warn_slowpath_common+0x4c/0x68) [<800257b8>] (warn_slowpath_common+0x4c/0x68) from [<800257f0>] (warn_slowpath_null+0x1c/0x24) [<800257f0>] (warn_slowpath_null+0x1c/0x24) from [<803f60ec>] (clk_disable+0x18/0x24) [<803f60ec>] (clk_disable+0x18/0x24) from [<7f02c9cc>] (spi_imx_remove+0x54/0x9c [spi_imx]) [<7f02c9cc>] (spi_imx_remove+0x54/0x9c [spi_imx]) from [<8025868c>] (platform_drv_remove+0x18/0x1c) [<8025868c>] (platform_drv_remove+0x18/0x1c) from [<80256f60>] (__device_release_driver+0x70/0xcc) [<80256f60>] (__device_release_driver+0x70/0xcc) from [<80257770>] (driver_detach+0xcc/0xd0) [<80257770>] (driver_detach+0xcc/0xd0) from [<80256d90>] (bus_remove_driver+0x7c/0xc0) [<80256d90>] (bus_remove_driver+0x7c/0xc0) from [<80068668>] (SyS_delete_module+0x144/0x1f8) [<80068668>] (SyS_delete_module+0x144/0x1f8) from [<8000e080>] (ret_fast_syscall+0x0/0x30) ---[ end trace 1f5df9ad54996300 ]--- ------------[ cut here ]------------ WARNING: at drivers/clk/clk.c:780 clk_disable+0x18/0x24() Modules linked in: spi_imx(-) [last unloaded: ev76c560] CPU: 1 PID: 16337 Comm: rmmod Tainted: G W 3.10.17-80548-g90191eb-dirty torvalds#33 [<80013b4c>] (unwind_backtrace+0x0/0xf8) from [<800115dc>] (show_stack+0x10/0x14) [<800115dc>] (show_stack+0x10/0x14) from [<800257b8>] (warn_slowpath_common+0x4c/0x68) [<800257b8>] (warn_slowpath_common+0x4c/0x68) from [<800257f0>] (warn_slowpath_null+0x1c/0x24) [<800257f0>] (warn_slowpath_null+0x1c/0x24) from [<803f60ec>] (clk_disable+0x18/0x24) [<803f60ec>] (clk_disable+0x18/0x24) from [<7f02c9e8>] (spi_imx_remove+0x70/0x9c [spi_imx]) [<7f02c9e8>] (spi_imx_remove+0x70/0x9c [spi_imx]) from [<8025868c>] (platform_drv_remove+0x18/0x1c) [<8025868c>] (platform_drv_remove+0x18/0x1c) from [<80256f60>] (__device_release_driver+0x70/0xcc) [<80256f60>] (__device_release_driver+0x70/0xcc) from [<80257770>] (driver_detach+0xcc/0xd0) [<80257770>] (driver_detach+0xcc/0xd0) from [<80256d90>] (bus_remove_driver+0x7c/0xc0) [<80256d90>] (bus_remove_driver+0x7c/0xc0) from [<80068668>] (SyS_delete_module+0x144/0x1f8) [<80068668>] (SyS_delete_module+0x144/0x1f8) from [<8000e080>] (ret_fast_syscall+0x0/0x30) ---[ end trace 1f5df9ad54996301 ]--- Since commit 9e556dc, "spi: spi-imx: only enable the clocks when we start to transfer a message", clocks are always disabled except when transmitting messages. There is thus no need to disable them at module removal. Fixes: 9e556dc (spi: spi-imx: only enable the clocks when we start to transfer a message) Signed-off-by: Philippe De Muyter <phdm@macqel.be> Acked-by: Huang Shijie <b32955@freescale.com> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
ddstreet
referenced
this pull request
in ddstreet/linux
Apr 8, 2014
GIT 3b55c3c0ec2eb3f163f15559f3962df717f53ccb
commit 8dec067dc9c59f9fdcaf4357c22994cde3647eb8
Author: Tomasz Figa <t.figa@samsung.com>
Date: Fri Mar 21 02:59:30 2014 +0900
ARM: EXYNOS: Fix compilation error in cpuidle.c
The big series refactoring Exynos suspend to RAM handling missed the
cpuidle driver that is disabled in exynos_defconfig, leaving it
including old mach/pm_core.h header and using old s3c_cpu_resume symbol
instead of new exynos_cpu_resume, resulting in compilation failures with
CONFIG_ARCH_EXYNOS and CONFIG_CPU_IDLE enabled.
This patch fixes that silly mistake and performs necessary modification
to arhc/arm/exynos/cpuidle.c to make it compile again.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit 58f37b0d47e9839fc8ef90d712594ed55cfcb2c7
Author: Tomasz Figa <t.figa@samsung.com>
Date: Fri Mar 21 03:22:33 2014 +0900
ARM: S5P64X0: Explicitly include linux/serial_s3c.h in mach/pm-core.h
This patch fixes compilation failure due to missing explicit inclusion
of linux/serial_s3c.h in mach/pm-core.h, which contains definitions
required for further code in this header.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit b2cde2cc71f2382e4a4bfaaacd5263bd93f1e0d2
Author: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu Mar 20 10:53:23 2014 -0700
net: bcmgenet: manipulate netdev_queue directly
Instead of always invoking netdev_get_tx_queue() in bcmgenet_xmit() and
bcmgenet_tx_reclaim(), just get the corresponding netdev_queue pointer
once and for all and manipulate it throughout bcmgenet_xmit() and
bcmgenet_tx_reclaim().
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit d5c76f628d399f06785b0ee910c431770a01b807
Author: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu Mar 20 10:53:22 2014 -0700
net: bcmgenet: remove bogus tx queue checks
netdev_pick_tx already takes care of making sure that a given
skb->queue_mapping value will remain within the number of advertised
hardware queue number, there is no need to re-do this again in the
driver.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit d03825fba459d0d58e4fe162439babfc5f5eabc4
Author: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu Mar 20 10:53:21 2014 -0700
net: bcmgenet: add skb_tx_timestamp call
The BCMGENET driver was not TX timestamping the SKBs it queued for
transmission, do this in bcmgenet_xmit() right before kicking the
Transmit DMA engine.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 9460c936794fbcf82623e263926b17334ca5887a
Author: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu Mar 20 10:53:20 2014 -0700
net: bcmgenet: remove unused spinlock member
The spinlock cookie in bcmgenet_priv is never used, get rid of it.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit f738a13d8365b0f824f3f20450b413f55374f175
Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Date: Thu Mar 20 15:00:35 2014 +0100
sh_eth: Remove goto statements that jump straight to a return
"goto" is well accepted for error paths in the kernel but should not be
used unnecessarily. Return the correct value directly instead of using a
goto when possible.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit daacf03f0bbfefee3df107c3f7659d22e22538a7
Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Date: Thu Mar 20 15:00:34 2014 +0100
sh_eth: Register MDIO bus before registering the network device
Network API functions that rely on the MDIO bus can be called as soon as
the driver calls register_netdev(). Register the MDIO bus before the
network device to avoid race conditions.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit bd920ff553ba17f19372501a14e432d9d92b102b
Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Date: Thu Mar 20 15:00:33 2014 +0100
sh_eth: Simplify MDIO bus initialization and release
The network device passed to the sh_mdio_init and sh_mdio_release
functions is only used to access the sh_eth_private instance. Pass it
directly to those functions.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit a5bd60608936fbb84471a80592401ce29a68de71
Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Date: Thu Mar 20 15:00:32 2014 +0100
sh_eth: Use the platform device as the MDIO bus parent
The MDIO bus parent is set to the network device. Beside not reflecting
the hardware topology, this prevents registering the MDIO bus before
initializing the network device. Fix it by setting the MDIO bus parent
to the platform device.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit aa8d422510969b705656e49fc0166d862aca9246
Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Date: Thu Mar 20 15:00:31 2014 +0100
sh_eth: Use the platform device for memory allocation
Memory allocated for the MDIO bus with the devm_kzalloc() API is
associated with the network device. While this will cause memory to be
freed at the right time, it doesn't allow allocating memory before the
network device is initialized.
Replace the network device with the parent platform device for memory
allocation to remove that dependency. This also improves consistency
with the other devm_* calls in the driver that all use the platform
device.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 54af36e7136b5e111734ca5b06c6b4390d663cac
Author: Alexander Aring <alex.aring@gmail.com>
Date: Thu Mar 20 14:57:03 2014 +0100
ieee802154: dgram: cleanup set of broadcast panid
This patch is only a cleanup to use the right define for a panid field.
The broadcast address and panid broadcast is still the same value.
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Cc: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 06324f2f7c21e3ba3529546063a3ebf7da806ed0
Author: Alexander Aring <alex.aring@gmail.com>
Date: Thu Mar 20 14:57:02 2014 +0100
af_ieee802154: fix check on broadcast address
This patch fixes an issue which was introduced by commit
b70ab2e87f17176d18f67ef331064441a032b5f3 ("ieee802154: enforce
consistent endianness in the 802.15.4 stack").
The correct behaviour should be a check on the broadcast address field
which is 0xffff.
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Reported-by: Jan Luebbe <jlu@pengutronix.de>
Cc: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 3c6f5592203e8126b70717f040c6c59f953068b3
Author: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Date: Wed Mar 19 16:15:24 2014 -0600
of_mdio: Allow the DT to specify the phy ID and avoid autoprobing
This makes the generic of_mdiobus_register parse the DT compatible string for
the pattern ethernet-phy-idAAAA.BBBB. If present it should be a value that
matches the phy-id register normally readable through MDIO.
When the ID is given the phy autoprobing is defeated and the phy is
created directly.
This is necessary to support phy's that cannot be autoprobed when
of_mdiobus_register is called. Specifically, my case has the phy in reset at
of_mdiobus_register, the reset is only released once the ethernet driver
starts, before it attaches to the phy.
Tested on ARM Kirkwood with phy id 0x01410e90 (Marvell 88E1318)
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit f00e756ed12d3204583764c93e41b89e1ae7ee44
Author: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Date: Wed Mar 19 16:15:23 2014 -0600
dt: Document a compatible entry for MDIO ethernet Phys
This describes a compatible entry of the form:
ethernet-phy-idAAAA,BBBB
Which is modelled after the PCI structured compatible entry
(pciVVVV,DDDD.SSSS.ssss.RR)
If present the OF core will be able to use this information to
directly create the correct phy without auto probing the bus.
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 259fef033ffe4e70bf7f358c53400a09f1b5384e
Author: Ben Chan <benchan@chromium.org>
Date: Wed Mar 19 14:00:06 2014 -0700
net: cdc_ncm: respect operator preferred MTU reported by MBIM
According to "Universal Serial Bus Communications Class Subclass
Specification for Mobile Broadband Interface Model, Revision 1.0,
Errata-1" published by USB-IF, the wMTU field of the MBIM extended
functional descriptor indicates the operator preferred MTU for IP data
streams.
This patch modifies cdc_ncm_setup to ensure that the MTU value set on
the usbnet device does not exceed the operator preferred MTU indicated
by wMTU if the MBIM device exposes a MBIM extended functional
descriptor.
Signed-off-by: Ben Chan <benchan@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit bfe9b3f8c5229e5de4fd18e941866bc410d16334
Author: Ben Chan <benchan@chromium.org>
Date: Wed Mar 19 14:00:05 2014 -0700
USB: cdc: add MBIM extended functional descriptor structure
This patch adds the MBIM extended functional descriptor structure
defined in "Universal Serial Bus Communications Class Subclass
Specification for Mobile Broadband Interface Model, Revision 1.0,
Errata-1" published by USB-IF.
Signed-off-by: Ben Chan <benchan@chromium.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit f518338b16038beeb73e155e60d0f70beb9379f4
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Wed Mar 19 17:47:51 2014 +0100
ip6mr: fix mfc notification flags
Commit 812e44dd1829 ("ip6mr: advertise new mfc entries via rtnl") reuses the
function ip6mr_fill_mroute() to notify mfc events.
But this function was used only for dump and thus was always setting the
flag NLM_F_MULTI, which is wrong in case of a single notification.
Libraries like libnl will wait forever for NLMSG_DONE.
CC: Thomas Graf <tgraf@suug.ch>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 65886f439ab0fdc2dff20d1fa87afb98c6717472
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Wed Mar 19 17:47:50 2014 +0100
ipmr: fix mfc notification flags
Commit 8cd3ac9f9b7b ("ipmr: advertise new mfc entries via rtnl") reuses the
function ipmr_fill_mroute() to notify mfc events.
But this function was used only for dump and thus was always setting the
flag NLM_F_MULTI, which is wrong in case of a single notification.
Libraries like libnl will wait forever for NLMSG_DONE.
CC: Thomas Graf <tgraf@suug.ch>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 1c104a6bebf3c16b6248408b84f91d09ac8a26b6
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Wed Mar 19 17:47:49 2014 +0100
rtnetlink: fix fdb notification flags
Commit 3ff661c38c84 ("net: rtnetlink notify events for FDB NTF_SELF adds and
deletes") reuses the function nlmsg_populate_fdb_fill() to notify fdb events.
But this function was used only for dump and thus was always setting the
flag NLM_F_MULTI, which is wrong in case of a single notification.
Libraries like libnl will wait forever for NLMSG_DONE.
CC: Thomas Graf <tgraf@suug.ch>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 632623153196bf183a69686ed9c07eee98ff1bf8
Author: Eric Dumazet <edumazet@google.com>
Date: Wed Mar 19 21:02:21 2014 -0700
tcp: syncookies: do not use getnstimeofday()
While it is true that getnstimeofday() uses about 40 cycles if TSC
is available, it can use 1600 cycles if hpet is the clocksource.
Switch to get_jiffies_64(), as this is more than enough, and
go back to 60 seconds periods.
Fixes: 8c27bd75f04f ("tcp: syncookies: reduce cookie lifetime to 128 seconds")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Florian Westphal <fw@strlen.de>
Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit dd41cc3bb90efd455df514899a5d3cf245182eb1
Author: Matan Barak <matanb@mellanox.com>
Date: Wed Mar 19 18:11:53 2014 +0200
net/mlx4: Adapt num_vfs/probed_vf params for single port VF
A new syntax is added for the module parameters num_vfs and probe_vf.
num_vfs=p1,p2,p1+p2
probe_bf=p1,p2,p1+p2
Where p1(2) is the number of VFs on / probed VFs for physical
port1(2) and p1+p2 is the number of dual port VFs.
Single port VFs are currently supported only when the link type
for both ports of the device is Ethernet.
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 449fc48866f7d84b0d9a19201de18a4dd4d3488c
Author: Matan Barak <matanb@mellanox.com>
Date: Wed Mar 19 18:11:52 2014 +0200
net/mlx4: Adapt code for N-Port VF
Adds support for N-Port VFs, this includes:
1. Adding support in the wrapped FW command
In wrapped commands, we need to verify and convert
the slave's port into the real physical port.
Furthermore, when sending the response back to the slave,
a reverse conversion should be made.
2. Adjusting sqpn for QP1 para-virtualization
The slave assumes that sqpn is used for QP1 communication.
If the slave is assigned to a port != (first port), we need
to adjust the sqpn that will direct its QP1 packets into the
correct endpoint.
3. Adjusting gid[5] to modify the port for raw ethernet
In B0 steering, gid[5] contains the port. It needs
to be adjusted into the physical port.
4. Adjusting number of ports in the query / ports caps in the FW commands
When a slave queries the hardware, it needs to view only
the physical ports it's assigned to.
5. Adjusting the sched_qp according to the port number
The QP port is encoded in the sched_qp, thus in modify_qp we need
to encode the correct port in sched_qp.
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit f74462acf8f390528c8b7937f227c6c90d017f3b
Author: Matan Barak <matanb@mellanox.com>
Date: Wed Mar 19 18:11:51 2014 +0200
net/mlx4: Add utils for N-Port VFs
This patch adds the following utils:
1. Convert slave_id -> VF
2. Get the active ports by slave_id
3. Convert slave's port to real port
4. Get the slave's port from real port
5. Get all slaves that uses the i'th real port
6. Get all slaves that uses the i'th real port exclusively
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 1ab95d37bcc3ff2d69e3871e4f056bab7aed0b85
Author: Matan Barak <matanb@mellanox.com>
Date: Wed Mar 19 18:11:50 2014 +0200
net/mlx4: Add data structures to support N-Ports per VF
Adds the required data structures to support VFs with N (1 or 2)
ports instead of always using the number of physical ports.
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 82373701be26b893eaf7372db0af84235a51998a
Author: Matan Barak <matanb@mellanox.com>
Date: Wed Mar 19 18:11:49 2014 +0200
IB/mlx4_ib: Adapt code to use caps.num_ports instead of a constant
Some code in the mlx4 IB driver stack assumed MLX4_MAX_PORTS ports.
Instead, we should only loop until the number of actual ports in i
the device, which is stored in dev->caps.num_ports.
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 8798998c2cdbc0df3c64e8845c1502ed93ef1ebd
Author: Fabio Estevam <fabio.estevam@freescale.com>
Date: Wed Mar 19 11:22:06 2014 -0300
smsc911x: Change clock warning message to debug level
Since passing the clock is not mandatory, change the warning message to debug,
so that we avoid getting the following clock failure message on every boot:
smsc911x: Driver version 2008-10-21
smsc911x smsc911x (unregistered net_device): couldn't get clock -2
libphy: smsc911x-mdio: probed
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit e35bad5d876dc7b0bfd794a3ba328a442bd970e0
Author: Daniel Baluta <dbaluta@ixiacom.com>
Date: Wed Mar 19 15:58:25 2014 +0200
net: remove empty lines from tcp_syn_flood_action
Signed-off-by: Daniel Baluta <dbaluta@ixiacom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 1aa9c483d1be13831bc4e516ce4848d32ac3e944
Author: Sachin Kamat <sachin.kamat@linaro.org>
Date: Fri Mar 21 04:49:03 2014 +0900
ARM: EXYNOS: Remove hardware.h file
This is a dummy placeholder file. Delete it.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit 2bb1ad17d66da3549eb4d23e264786a98f9ab17b
Author: Sachin Kamat <sachin.kamat@linaro.org>
Date: Fri Mar 21 04:48:59 2014 +0900
ARM: SAMSUNG: Remove hardware.h inclusion
The contents of this header file are not referenced anywhere in the
included .c files except in devs.c. Remove its inclusion. For devs.c,
explicitly include sizes.h header for SZ_* macros.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit 144bf7b0a96e28266c6b2f47a6e04c7a4e4b3aa4
Author: Sachin Kamat <sachin.kamat@linaro.org>
Date: Fri Mar 21 04:48:07 2014 +0900
ARM: S3C24XX: Remove invalid code from hardware.h
Remove the code that is not referenced anywhere. While at it also
remove incorrect file path.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit 676141e48af7463717896352e69c10f945ac22dd
Author: Jens Axboe <axboe@fb.com>
Date: Thu Mar 20 13:29:18 2014 -0600
blk-mq: don't dump CPU -> hw queue map on driver load
Now that we are out of initial debug/bringup mode, remove
the verbose dump of the mapping table.
Provide the mapping table in sysfs, under the hardware queue
directory, in the cpu_list file.
Signed-off-by: Jens Axboe <axboe@fb.com>
commit 602408e3de70d132c115670a366f4c5ae657080c
Author: Tushar Behera <tushar.behera@linaro.org>
Date: Fri Mar 21 04:31:30 2014 +0900
dt-bindings: clock: Move exynos-audss-clk.h to dt-bindings/clock
Most of the clock related dt-binding header files are located in
dt-bindings/clock folder. It would be good to keep all the similar
header files at a single location.
Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
Reviewed-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit 55ace6b285d7350d5b562ba065656c8242629a32
Author: Tushar Behera <tushar.behera@linaro.org>
Date: Fri Mar 21 04:26:40 2014 +0900
ARM: dts: Keep some essential LDOs enabled for arndale-octa board
LDO3 and LDO23 need to be enabled in order for soft-reset to work.
Additionally LDO9 needs to be enabled for USB operations.
Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit 3da355c03a44bc45f3688bb68b51eefa738d1857
Author: Tushar Behera <tushar.behera@linaro.org>
Date: Fri Mar 21 04:26:40 2014 +0900
ARM: dts: Disable MDMA1 node for arndale-octa board
MDMA1 can support both secure and non-secure AXI transactions. When this
is enabled in the kernel for boards that run in secure mode, we get
imprecise external aborts causing the kernel to oops.
Unhandled fault: imprecise external abort (0x1406) at 0x00000000
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000007
Suggested-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
Tested-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit e1a9d00c689a5da2d1baf273891507c5fb063f4c
Author: Mark Brown <broonie@linaro.org>
Date: Fri Mar 21 02:57:18 2014 +0900
ARM: S3C64XX: Fix build for implicit serial_s3c.h inclusion
Some very recent change appears to have removed an implicit inclusion of
serial_s3c.h causing build failures due to references to UART registers
in the serial port restore code in next-20140318. Include it explicitly
to fix the build.
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit cf559ab94e058df65c841b4afc8d5346fdda19b3
Author: Mark Brown <broonie@linaro.org>
Date: Fri Mar 21 02:55:11 2014 +0900
serial: s3c: Fix build of header without serial_core.h preinclusion
serial_s3c.h uses upf_t which is defined in serial_core.h but does not
include that itself meaning that users which include serial_s3c.h by
itself don't build.
Signed-off-by: Mark Brown <broonie@linaro.org>
[t.figa: Moved inclusion under #ifndef __ASSEMBLY__ to fix mach-exynos]
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit dd8ac696b20c1be5ca4728045df10e882e01e91d
Author: Tomasz Figa <t.figa@samsung.com>
Date: Tue Mar 18 07:28:30 2014 +0900
ARM: EXYNOS: Allow wake-up using GIC interrupts
This patch restores the ability to receive wake-up events from internal
GIC interrupts, e.g. RTC tick or alarm interrupts.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit d710aa31874e2ff6e656dbd4807f4bd8d659eb93
Author: Tomasz Figa <t.figa@samsung.com>
Date: Tue Mar 18 07:28:27 2014 +0900
ARM: EXYNOS: Stop using legacy Samsung PM code
Since Exynos SoCs does not follow most of the semantics of older SoCs
when configuring the system to enter sleep, there is no reason to rely
on the legacy Samsung PM core anymore.
This patch adds local Exynos suspend ops and removes all the code left
unnecessary. As a side effect, suspend support on Exynos becomes
multiplatform-friendly.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit 559ba237999d723ccba5b4a75cf6b280bac1ab21
Author: Tomasz Figa <t.figa@samsung.com>
Date: Tue Mar 18 07:28:22 2014 +0900
ARM: EXYNOS: Remove PM initcalls and useless indirection
This patch simplifies Exynos PM initialization and makes it
multiplatform friendly by replacing initcalls used originally to invoke
all the initialization code with explicit function calls.
In addition, an useless subsys_interface is removed, as all its .add_dev
callback did was setting two function pointers.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit dbc5ca163dc46153a8e5249da627af571ae47c10
Author: Tomasz Figa <t.figa@samsung.com>
Date: Tue Mar 18 07:28:10 2014 +0900
ARM: EXYNOS: Fix abuse of CONFIG_PM
CONFIG_PM means that at least one of CONFIG_PM_SLEEP and
CONFIG_PM_RUNTIME is enabled, while multiple entries in
mach-exynos/Kconfig abused it to enable sleep- and runtime-specific
functionality.
This patch fixes this abuse by replacing dependencies on CONFIG_PM with
appropriate dependencies on either CONFIG_PM_SLEEP or CONFIG_PM_RUNTIME,
whichever is appropriate.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit f682426630c620a2b8ae488a4f0d85ec6c272d66
Author: Tomasz Figa <t.figa@samsung.com>
Date: Tue Mar 18 07:28:10 2014 +0900
ARM: SAMSUNG: Move s3c_pm_check_* prototypes to plat/pm-common.h
To allow using Samsung PM memory check helpers on platforms that do not
use the legacy Samsung PM core, this patch moves prototypes of relevant
functions to plat/pm-common.h header.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit b27899178c53226a5ff780a17657c84eb5e32338
Author: Tomasz Figa <t.figa@samsung.com>
Date: Tue Mar 18 07:28:10 2014 +0900
ARM: SAMSUNG: Move common save/restore helpers to separate file
To separate legacy PM code from generic helpers, this patch moves the
generic register save/restore helpers to a new file called pm-common.c
that is compiled always when CONFIG_PM_SLEEP is enabled, to allow
platforms that do not want to use the legacy PM code use the generic
helpers.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit 72551f6cf13e2f3a1d273b7007b5d7d7fd69c554
Author: Tomasz Figa <t.figa@samsung.com>
Date: Tue Mar 18 07:28:09 2014 +0900
ARM: SAMSUNG: Move Samsung PM debug code into separate file
Not all Samsung SoC platforms are going to use the legacy Samsung PM
code enabled by CONFIG_SAMSUNG_PM_DEBUG. To allow using Samsung PM debug
helpers on such platforms, related code is moved to separate file and
a plat/pm-common.h header is added to separate legacy and generic code.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit d38688a69fd88269eae3c7c66ec34fb02fb04fd1
Author: Tomasz Figa <t.figa@samsung.com>
Date: Tue Mar 18 07:28:09 2014 +0900
ARM: SAMSUNG: Consolidate PM debug functions
This patch removes one-line functions that was used just to pass
constant arguments to lower level functions. After previous patches the
need for those constants has been eliminated, so the main functions can
be called directly.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit 99b2fc2b8b40256538332769f11f2fe6ee942f6c
Author: Tomasz Figa <t.figa@samsung.com>
Date: Tue Mar 18 07:28:09 2014 +0900
ARM: SAMSUNG: Use debug_ll_addr() to get UART base address
This patch modifies Samsung PM debug helpers to use a multiplatform
friendly way of getting base address of debug UART port, so instead
of using a per-mach static macro, a generic debug_ll_addr() helper
is used.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit de7fe0807c08553b88028d039861a4b8ad04fc62
Author: Tomasz Figa <t.figa@samsung.com>
Date: Tue Mar 18 07:28:09 2014 +0900
ARM: SAMSUNG: Save UART DIVSLOT register based on SoC type
The only SoC that does not have DIVSLOT register is S3C2410, so instead
of exporting a variable for platforms to set if DIVSLOT register should
be preserved, it's enough to simply check whether we are running on
a S3C2410 instead.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit 04241069617d4f0bfd9f4a3aeefae13e1e5b55e1
Author: Tomasz Figa <t.figa@samsung.com>
Date: Tue Mar 18 07:28:09 2014 +0900
ARM: SAMSUNG: Add soc_is_s3c2410() helper
Due to the S3C2410 SoC being quite different from other S3C24xx SoCs
in some aspects, such as availability of DIVSLOT register in its UART
blocks, there is a need sometimes to check whether we are running on
this SoC, not just the S3C24xx series. This patch adds soc_is_s3c2410()
helper function for this purpose.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit 61557b8bac9c80a5c14d237d420c246703e5c2e2
Author: Tomasz Figa <t.figa@samsung.com>
Date: Tue Mar 18 07:28:09 2014 +0900
ARM: EXYNOS: Do not resume l2x0 if not enabled before suspend
Trying to resume l2x0 if it was not enabled before suspend leads to
system crash. This patch prevents this by checking if l2x0_regs_phys is
a valid pointer to l2x0 context data saved on initialization.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit 56981fbc1b044cb140f70279deb736b6ae8664fb
Author: Mike Snitzer <snitzer@redhat.com>
Date: Thu Mar 20 10:11:15 2014 -0400
dm cache: prevent corruption caused by discard_block_size > cache_block_size
If the discard block size is larger than the cache block size we will
not properly quiesce IO to a region that is about to be discarded. This
results in a race between a cache migration where no copy is needed, and
a write to an adjacent cache block that's within the same large discard
block.
Workaround this by limiting the discard_block_size to cache_block_size.
Also limit the max_discard_sectors to cache_block_size.
A more comprehensive fix that introduces range locking support in the
bio_prison and proper quiescing of a discard range that spans multiple
cache blocks is already in development.
Reported-by: Morgan Mears <Morgan.Mears@netapp.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Joe Thornber <ejt@redhat.com>
Acked-by: Heinz Mauelshagen <heinzm@redhat.com>
Cc: stable@vger.kernel.org
commit 88050049e7111f074e8887ba5a4cefc9f8fa8d41
Author: stephen hemminger <shemming@brocade.com>
Date: Wed Mar 19 21:54:20 2014 -0700
netlink: fix setsockopt in mmap examples in documentation
The documentation for how to use netlink mmap interface is incorrect.
The calls to setsockopt() require an additional argument.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit f9b8c4c8baded129535d82d74df8e87a7a369f54
Author: Ben Pfaff <blp@nicira.com>
Date: Thu Mar 20 10:45:21 2014 -0700
openvswitch: Correctly report flow used times for first 5 minutes after boot.
The kernel starts out its "jiffies" timer as 5 minutes below zero, as
shown in include/linux/jiffies.h:
/*
* Have the 32 bit jiffies value wrap 5 minutes after boot
* so jiffies wrap bugs show up earlier.
*/
#define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ))
The loop in ovs_flow_stats_get() starts out with 'used' set to 0, then
takes any "later" time. This means that for the first five minutes after
boot, flows will always be reported as never used, since 0 is greater than
any time already seen.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
commit 494314c415e2d3b308f57c9245ae6525166c70b8
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date: Thu Mar 20 12:59:09 2014 -0400
SUNRPC: rpc_restart_call/rpc_restart_call_prepare should clear task->tk_status
When restarting an rpc call, we should not be carrying over data from the
previous call.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
commit 6bd144160a5554e4af052c153a094c4851a4c6aa
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date: Thu Mar 20 12:53:54 2014 -0400
SUNRPC: Don't let rpc_delay() clobber non-timeout errors
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
commit d614f6d0bed7fa5a795708a6dc334370e1ca7951
Author: Yan Burman <yanb@mellanox.com>
Date: Tue Mar 11 14:41:47 2014 +0200
IB/mad: Check and handle potential DMA mapping errors
Running with DMA_API_DEBUG enabled and not checking for DMA mapping
errors triggers a kernel stack trace with "DMA-API: device driver
failed to check map error" message. Add these checks to the MAD
module, both to be be more robust and also eliminate these
false-positive stack traces.
Signed-off-by: Yan Burman <yanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit 76cf9cbb68f3234f54c0a12bde6372911157c650
Author: Selvin Xavier <selvin.xavier@emulex.com>
Date: Tue Mar 18 14:54:56 2014 +0530
RDMA/ocrdma: Unregister inet notifier when unloading ocrdma
Unregister the inet notifier during ocrdma unload to avoid a panic after
driver unload.
Signed-off-by: Selvin Xavier <selvin.xavier@emulex.com>
Signed-off-by: Devesh Sharma <devesh.sharma@emulex.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit 186f8ba062f796221d51077342f3ba5202838e9f
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu Jan 30 15:12:31 2014 +0300
IB/qib: Cleanup qib_register_observer()
Returning directly is easier to read than do-nothing gotos. Remove the
duplicative check on "olp" and pull the code in one indent level.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit 49c0e2414b20d868cf006addf14152570aef2605
Author: CQ Tang <cq.tang@intel.com>
Date: Thu Jan 30 17:36:00 2014 -0500
IB/qib: Change SDMA progression mode depending on single- or multi-rail
Improve performance by changing the behavour of the driver when all
SDMA descriptors are in use, and the processes adding new descriptors
are single- or multi-rail.
For single-rail processes, the driver will block the call and finish
posting all SDMA descriptors onto the hardware queue before returning
back to PSM. Repeated kernel calls are slower than blocking.
For multi-rail processes, the driver will return to PSM as quick as
possible so PSM can feed packets to other rail. If all hardware
queues are full, PSM will buffer the remaining SDMA descriptors until
notified by interrupt that space is available.
This patch builds a red-black tree to track the number rails opened by
a particular PID. If the number is more than one, it is a multi-rail
PSM process, otherwise, it is a single-rail process.
Reviewed-by: Dean Luick <dean.luick@intel.com>
Reviewed-by: John A Gregor <john.a.gregor@intel.com>
Reviewed-by: Mitko Haralanov <mitko.haralanov@intel.com>
Signed-off-by: CQ Tang <cq.tang@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit 8307281a5bceaaaa1566897dc0b57cdb62413ae8
Author: Roland Dreier <roland@purestorage.com>
Date: Mon Mar 17 23:14:17 2014 -0700
RDMA/ocrdma: Fix warnings about pointer <-> integer casts
We should cast pointers to and from unsigned long to turn them into ints.
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit 0d3a1e7e317b06d87b92011c62a5061f299820b9
Author: Devesh Sharma <Devesh.Sharma@Emulex.Com>
Date: Tue Feb 4 11:57:10 2014 +0530
RDMA/ocrdma: Code clean-up
Clean up code. Also modifying GSI QP to error during ocrdma_close is fixed.
Signed-off-by: Devesh Sharma <devesh.sharma@emulex.com>
Signed-off-by: Selvin Xavier <selvin.xavier@emulex.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit 9a31758308df672713ea0db9a9eff7c3cb348bc2
Author: Selvin Xavier <selvin.xavier@emulex.com>
Date: Tue Feb 4 11:57:09 2014 +0530
RDMA/ocrdma: Display FW version
Adding a sysfs file for getting the FW version.
Signed-off-by: Selvin Xavier <selvin.xavier@emulex.com>
Signed-off-by: Devesh Sharma <devesh.sharma@emulex.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit babe6b9ce0bdf964624435382a67c09f668bcab0
Author: Selvin Xavier <selvin.xavier@emulex.com>
Date: Tue Feb 4 11:57:07 2014 +0530
RDMA/ocrdma: Query controller information
Issue mailbox commands to query ocrdma controller information and phy
information and print them while adding ocrdma device.
Signed-off-by: Selvin Xavier <selvin.xavier@emulex.com>
Signed-off-by: Devesh Sharma <devesh.sharma@emulex.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit 8bdb31b4d1931a32264fbe4651e607eb72941ff0
Author: Sachin Kamat <sachin.kamat@linaro.org>
Date: Fri Mar 21 02:17:22 2014 +0900
ARM: dts: Update Exynos DT files with generic compatible strings
Add generic compatible strings to the respective board DT files.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit 4868123ceb6ef0d4fa04e3211a0f4cd948f418f9
Author: Sachin Kamat <sachin.kamat@linaro.org>
Date: Fri Mar 21 02:14:59 2014 +0900
ARM: EXYNOS: Add generic compatible strings
Add generic compatible strings for Exynos4 and 5 platforms so that
future SoCs can use them if there is nothing extra/specific to be
differentiated.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit cbf08b9ebdfc75bb13ef80ad3b8e3bea46d8c43a
Author: Sachin Kamat <sachin.kamat@linaro.org>
Date: Fri Mar 21 02:14:30 2014 +0900
ARM: EXYNOS: Consolidate exynos4 and exynos5 machine files
Since there is very little difference between these two files,
they can be easily combined into one with necessary SoC checks.
While at it also merge the common.c file into this as it does
not have any other users.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit 6eb84669cf7e94214593f162d4c1cf20424dd906
Author: Sachin Kamat <sachin.kamat@linaro.org>
Date: Fri Mar 21 02:09:39 2014 +0900
ARM: EXYNOS: Consolidate CPU init code
cpu_table was used to distinguish between different Exynos4 and 5
SoCs and based on the type do the initialization and io mapping.
exynos_init is dummy and no longer needed as we do a DT based booting.
By having a common io mapping function we can get rid of the whole
table and avoid populating it for every SoC.
Tested on Exynos4210, 5250 and 5420 based boards.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Tested-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit 7bd03c0ebe54db94f20cd7577b875d9d27e539a9
Author: Selvin Xavier <selvin.xavier@emulex.com>
Date: Tue Feb 4 11:57:06 2014 +0530
RDMA/ocrdma: Support non-embedded mailbox commands
Added a routine to issue non-embedded mailbox commands for handling
large mailbox request/response data.
Signed-off-by: Selvin Xavier <selvin.xavier@emulex.com>
Signed-off-by: Devesh Sharma <devesh.sharma@emulex.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit a1b8aff87d5f27022e6c14c43bf43226e75d2745
Author: Selvin Xavier <selvin.xavier@emulex.com>
Date: Tue Feb 4 11:57:05 2014 +0530
RDMA/ocrdma: Handle CQ overrun error
Signed-off-by: Selvin Xavier <selvin.xavier@emulex.com>
Signed-off-by: Devesh Sharma <devesh.sharma@emulex.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit 23631e15a7f3c01a1ebb34f2c176f658c27eb949
Author: Selvin Xavier <selvin.xavier@emulex.com>
Date: Tue Feb 4 11:57:04 2014 +0530
RDMA/ocrdma: Display proper value for max_mw
Signed-off-by: Selvin Xavier <selvin.xavier@emulex.com>
Signed-off-by: Devesh Sharma <devesh.sharma@emulex.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit c0e19755d56142b026b07b8020273301c8ed42bb
Author: Selvin Xavier <selvin.xavier@emulex.com>
Date: Tue Feb 4 11:57:03 2014 +0530
RDMA/ocrdma: Use non-zero tag in SRQ posting
As part of SRQ receive buffers posting we populate a non-zero tag
which will be returned in SRQ receive completions.
Signed-off-by: Selvin Xavier <selvin.xavier@emulex.com>
Signed-off-by: Devesh Sharma <devesh.sharma@emulex.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit def4eb8e5eacdfbc4788a6cb1bc0a3f118b5b349
Author: Selvin Xavier <selvin.xavier@emulex.com>
Date: Tue Feb 4 11:57:02 2014 +0530
RDMA/ocrdma: Memory leak fix in ocrdma_dereg_mr()
Signed-off-by: Selvin Xavier <selvin.xavier@emulex.com>
Signed-off-by: Devesh Sharma <devesh.sharma@emulex.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit 0f4d45e0845e63e54aeaf5a7444b8ef4b77e4895
Author: devesh.sharma@emulex.com <devesh.sharma@emulex.com>
Date: Tue Feb 4 11:57:01 2014 +0530
RDMA/ocrdma: Increment abi version count
Increment the ABI version count for driver/library interface.
Signed-off-by: Devesh Sharma <devesh.sharma@emulex.com>
Signed-off-by: Selvin Xavier <selvin.xavier@emulex.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit 5b5eb9421408080b46ce14210ca717714859dee4
Author: devesh.sharma@emulex.com <devesh.sharma@emulex.com>
Date: Tue Feb 4 11:57:00 2014 +0530
RDMA/ocrdma: Update version string
Update the driver vrsion string and node description string
Signed-off-by: Devesh Sharma <devesh.sharma@emulex.com>
Signed-off-by: Selvin Xavier <selvin.xavier@emulex.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit 91b3140a692e87733367521efdd24f9a3532889a
Author: devesh.sharma@emulex.com <devesh.sharma@emulex.com>
Date: Tue Feb 4 11:56:59 2014 +0530
be2net: Add abi version between be2net and ocrdma
This patch adds abi versioning between be2net and ocrdma driver modules
to catch functional incompatibilities in the two drivers.
Signed-off-by: Devesh Sharma <devesh.sharma@emulex.com>
Signed-off-by: Selvin Xavier <selvin.xavier@emulex.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit 973ce6ce272d2c79f7eb1094ec26c25d1d8b4b32
Author: devesh.sharma@emulex.com <devesh.sharma@emulex.com>
Date: Tue Feb 4 11:56:58 2014 +0530
RDMA/ocrdma: ABI versioning between ocrdma and be2net
While loading RoCE driver be2net driver should check for ABI version
to catch functional incompatibilities.
Signed-off-by: Devesh Sharma <devesh.sharma@emulex.com>
Signed-off-by: Selvin Xavier <selvin.xavier@emulex.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit db84035babf25f81be2a548f9332553b3a62865f
Author: devesh.sharma@emulex.com <devesh.sharma@emulex.com>
Date: Tue Feb 4 11:56:57 2014 +0530
RDMA/ocrdma: Allow DPP QP creation
Allow creating DPP QP even if inline-data is not requested. This is an
optimization to lower latency.
Signed-off-by: Devesh Sharma <devesh.sharma@emulex.com>
Signed-off-by: Selvin Xavier <selvin.xavier@emulex.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit d64c9414a4cc7c768d117ae035bf45cce760aeb5
Author: devesh.sharma@emulex.com <devesh.sharma@emulex.com>
Date: Tue Feb 4 11:56:56 2014 +0530
RDMA/ocrdma: Read ASIC_ID register to select asic_gen
ocrdma driver selects execution path based on sli_family and asic
generation number. This introduces code to read the asic gen number
from pci register instead of obtaining it from the Emulex NIC driver.
Signed-off-by: Devesh Sharma <devesh.sharma@emulex.com>
Signed-off-by: Selvin Xavier <selvin.xavier@emulex.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit da7d0e7699e6c5e3b076ba68680afe679e7379f0
Author: Devesh Sharma <Devesh.Sharma@Emulex.Com>
Date: Tue Feb 4 11:56:55 2014 +0530
RDMA/ocrdma: SQ and RQ doorbell offset clean up
Introducing new macros to define SQ and RQ doorbell offset.
Signed-off-by: Devesh Sharma <devesh.sharma@emulex.com>
Signed-off-by: Selvin Xavier <selvin.xavier@emulex.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit 1dbf741320af98620593c9a1d7481dd8b37f53fe
Author: devesh.sharma@emulex.com <devesh.sharma@emulex.com>
Date: Tue Feb 4 11:56:54 2014 +0530
RDMA/ocrdma: EQ full catastrophe avoidance
Stale entries in the CQ being destroyed causes hardware to generate
EQEs indefinitely for a given CQ. Thus causing uncontrolled execution
of irq_handler. This patch fixes this using following sementics:
* irq_handler will ring EQ doorbell atleast once and implement budgeting scheme.
* cq_destroy will count number of valid entires during destroy and ring
cq-db so that hardware does not generate uncontrolled EQE.
* cq_destroy will synchronize with last running irq_handler instance.
* arm_cq will always defer arming CQ till poll_cq, except for the first arm_cq call.
* poll_cq will always ring cq-db with arm=SET if arm_cq was called prior to enter poll_cq.
* poll_cq will always ring cq-db with arm=UNSET if arm_cq was not called prior to enter poll_cq.
Signed-off-by: Devesh Sharma <devesh.sharma@emulex.com>
Signed-off-by: Selvin Xavier <selvin.xavier@emulex.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit eda6d1d1b7932f90d55583f8f3835dd7d6b32543
Author: Steve Wise <swise@opengridcomputing.com>
Date: Wed Mar 19 17:44:45 2014 +0530
RDMA/cxgb4: Save the correct map length for fast_reg_page_lists
We cannot save the mapped length using the rdma max_page_list_len field
of the ib_fast_reg_page_list struct because the core code uses it. This
results in an incorrect unmap of the page list in c4iw_free_fastreg_pbl().
I found this with dma mapping debugging enabled in the kernel. The
fix is to save the length in the c4iw_fr_page_list struct.
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit df2d5130ece9118591c2f3fbf0ee4a79183b4ccc
Author: Steve Wise <swise@opengridcomputing.com>
Date: Wed Mar 19 17:44:44 2014 +0530
RDMA/cxgb4: Default peer2peer mode to 1
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit ba32de9d8d8173a1d6dd1ed608c519d5d0a623bb
Author: Steve Wise <swise@opengridcomputing.com>
Date: Wed Mar 19 17:44:43 2014 +0530
RDMA/cxgb4: Mind the sq_sig_all/sq_sig_type QP attributes
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit 8a9c399eeee8c2d99e22b975f6023001a1fde88f
Author: Steve Wise <swise@opengridcomputing.com>
Date: Wed Mar 19 17:44:42 2014 +0530
RDMA/cxgb4: Fix incorrect BUG_ON conditions
Based on original work from Jay Hernandez <jay@chelsio.com>
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit 58553078c1feb40e0a02d7c72ae41dd6b923f231
Author: Sachin Kamat <sachin.kamat@linaro.org>
Date: Fri Mar 21 02:00:21 2014 +0900
ARM: SAMSUNG: Introduce generic Exynos4 and 5 helpers
Add helpers to check for Exynos4 and 5 family of SoCs.
This will eliminate comparing long list of SoCs and make
code simpler.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit 7ed30015007c32c006783526dc54a2a88bd5e13b
Author: Sachin Kamat <sachin.kamat@linaro.org>
Date: Fri Mar 21 01:52:56 2014 +0900
ARM: EXYNOS: Add support to reserve memory for MFC-v7
Reserve memory for MFC-v7 IP.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit 8b3e8bbd132279be544a6f4dc22c22d244c98c23
Author: Tushar Behera <tushar.behera@linaro.org>
Date: Fri Mar 21 01:49:24 2014 +0900
ARM: SAMSUNG: Reorganize calls to reserve memory for MFC
Reorganize code so that "plat/mfc.h" is no more referred
from mach-exynos directory.
Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit ebf00060c33b9d0946384fa6f440df7ea35a569e
Author: Steve Wise <swise@opengridcomputing.com>
Date: Wed Mar 19 17:44:40 2014 +0530
RDMA/cxgb4: Always release neigh entry
Always release the neigh entry in rx_pkt().
Based on original work by Santosh Rastapur <santosh@chelsio.com>.
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit f8e819081f797df355cffbdedb9301ea50ae76b2
Author: Steve Wise <swise@opengridcomputing.com>
Date: Wed Mar 19 17:44:39 2014 +0530
RDMA/cxgb4: Allow loopback connections
find_route() must treat loopback as a valid egress interface.
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit ffd435924c86de055d33fe59941841819eef9f6a
Author: Steve Wise <swise@opengridcomputing.com>
Date: Wed Mar 19 17:44:38 2014 +0530
RDMA/cxgb4: Cap CQ size at T4_MAX_IQ_SIZE
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit e24a72a3302a638d4c6e77f0b40c45cc61c3f089
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Sat Oct 19 12:14:35 2013 +0300
RDMA/cxgb4: Fix four byte info leak in c4iw_create_cq()
There is a four byte hole at the end of the "uresp" struct after the
->qid_mask member.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit ff1706f4feb8e0e1a2e56a8dd57e17a4b45649b5
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Sat Oct 19 12:14:12 2013 +0300
RDMA/cxgb4: Fix underflows in c4iw_create_qp()
These sizes should be unsigned so we don't allow negative values and
have underflow bugs. These can come from the user so there may be
security implications, but I have not tested this.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
commit 4726e0b045b80c514377da35ca01467ef6a4de53
Author: Sagar Kamble <sagar.a.kamble@intel.com>
Date: Mon Mar 10 17:06:23 2014 +0530
drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support
With this patch we allow larger cursor planes of sizes 128x128
and 256x256.
v2: Added more precise check on size while setting cursor plane.
v3: Changes related to restructuring cursor size restrictions
and DRM_DEBUG usage.
v4: Indentation related changes for setting cursor control and
implementing DRM_CAP_CURSOR_WIDTH and DRM_CAP_CURSOR_HEIGHT
Testcase: igt/kms_cursor_crc
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: G, Pallavi <pallavi.g@intel.com>
Signed-off-by: Sagar Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 61b1a7fbda6f761ebe16a62124578ca0779d9365
Author: Johan Hedberg <johan.hedberg@intel.com>
Date: Thu Mar 20 12:54:16 2014 +0200
Bluetooth: Fix address value for early disconnection events
We need to ensure that we do not send events to user space with the
identity address if we have not yet notified user space of the IRK. The
code was previously trying to handle this for the mgmt_pair_device
response (which worked well enough) but this is not the only connection
related event that might be sent to user space before pairing is
successful: another important event is Device Disconnected.
The issue can actually be solved more simply than the solution
previously used for mgmt_pair_device. Since we do have the identity
address tracked as part of the remote IRK struct we can just copy it
over from there to the hci_conn struct once we've for real sent the mgmt
event for the new IRK.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
commit 204747c970c0d568721c76ab8a57dde0e5dcf0d5
Author: Guenter Roeck <linux@roeck-us.net>
Date: Thu Mar 20 08:12:28 2014 -0700
mfd: kempld-core: Fix potential hang-up during boot
On PXT and COMe-cPC2 boards it is observed that the hardware
mutex is acquired but not being released during initialization.
This can result in a hang-up during boot if the driver is built
into the kernel.
Releasing the mutex twice if it was acquired fixes the problem.
Subsequent request/release cycles work as expected, so the fix is
only needed during initialization.
Cc: <stable@vger.kernel.org>
Reviewed-by: Michael Brunner <michael.brunner@kontron.com>
Tested-by: Michael Brunner <michael.brunner@kontron.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
commit 5a78401623740c892868d5929b33f5cda8fe819e
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date: Tue Mar 18 14:11:26 2014 +0100
mfd: sec-core: Fix uninitialized 'regmap_rtc' on S2MPA01
Initialize the 'regmap_rtc' on S2MPA01 to some sane value. Sane at least
for S5M87X chipsets, not S2MPS/S2MPA but it won't be used because
rtc-s5m driver does not support S2MPA01.
This fixes following error:
drivers/mfd/sec-core.c:342:45: warning: ‘regmap_rtc’ may be used uninitialized in this function [-Wuninitialized]
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
commit 67b3bd4e65f0854aca70e0134d59b1daede49504
Author: Arend van Spriel <arend@broadcom.com>
Date: Thu Mar 20 10:18:03 2014 +0100
brcmfmac: fallback to mimo_bw_cap for older firmwares
In order to support the driver behaviour introduced by:
commit d0575a5a703978c43e25128421158c78534ba100
Author: Daniel Kim <dekim@broadcom.com>
Date: Wed Mar 12 18:12:14 2014 -0700
brcmfmac: Enable 40MHz bandwidth in 2GHz band and OBSS scanning
in devices that do not support bwcap firmware command a fallback
is added.
Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
commit 4d1a4f16c96d3f4cf6afd92ca3ffb4d2c24875e1
Author: Arend van Spriel <arend@broadcom.com>
Date: Thu Mar 20 10:18:02 2014 +0100
brcmfmac: only show error message when brcmf_sdiod_regrw_helper() fails
In the function brcmf_sdiod_request_data() an error message is logged,
but the calling function retries it. This patch will only log an error
message when retry limit is reached. The low-level error is still
logged by a SDIO debug message.
Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
commit 58e9df462fd70a1862378beb46b312f1f6bca94f
Author: Arend van Spriel <arend@broadcom.com>
Date: Thu Mar 20 10:18:01 2014 +0100
brcmfmac: reinit watchdog completion after handling watchdog
The watchdog thread waits on completion that is set from a timer. As
the completion is count based this could mean that on a busy system
the watchdog is handled multiple times with a very short interval.
This is not the intended behaviour. After handling the watchdog it
should wait for the next timer expiry. This is accomplished by
reinitializing the completion.
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
commit d23536796011cbeeb93fc866446800c52deb5603
Author: Daniel Kim <dekim@broadcom.com>
Date: Thu Mar 20 10:18:00 2014 +0100
brcmfmac: Enable 40MHz bandwidth in 2GHz band and OBSS scanning operations
This patch enables 40MHz bandwidth in 2GHz band after checking whether
cfg80211 allows it or not, and enables OBSS scanning operations to
to support 20/40 BSS coexistence.
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Daniel Kim <dekim@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
commit 1fa3e2eb9db07f30a605c66d1a2fdde4b24e74d5
Author: Steve Dickson <steved@redhat.com>
Date: Thu Mar 20 11:23:03 2014 -0400
SUNRPC: Ensure call_connect_status() deals correctly with SOFTCONN tasks
Don't schedule an rpc_delay before checking to see if the task
is a SOFTCONN because the tk_callback from the delay (__rpc_atrun)
clears the task status before the rpc_exit_task can be run.
Signed-off-by: Steve Dickson <steved@redhat.com>
Fixes: 561ec1603171c (SUNRPC: call_connect_status should recheck...)
Link: http://lkml.kernel.org/r/5329CF7C.7090308@RedHat.com
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
commit f5b972e9fbd2e99a2abc3221783d089799b69394
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date: Thu Mar 20 15:30:14 2014 +0100
compat: include linux/unistd.h within linux/compat.h
linux/compat.h does not include linux/unistd.h but the compat.h header
file contains various conditional
#ifdef __ARCH_WANT_COMPAT_...
asmlinkage long compat...()
#endif
compat system call function declarations.
If linux/unistd.h isn't included it depends on previous includes if those
__ARCH_WANT_COMPAT_... defines are defined or not. So add an additional
linux/unistd.h include.
Should fix this compile error on tile:
include/uapi/asm-generic/unistd.h:195:1: error: 'compat_sys_getdents64' undeclared
make[3]: *** [arch/tile/kernel/compat.o] Error 1
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Chris Metcalf <cmetcalf@tilera.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
commit e1b2dc176f2d5be7952c47a4e4e8f3b06a90db1c
Author: Tejun Heo <tj@kernel.org>
Date: Thu Mar 20 11:10:15 2014 -0400
cgroup: break kernfs active_ref protection in cgroup directory operations
cgroup_tree_mutex should nest above the kernfs active_ref protection;
however, cgroup_create() and cgroup_rename() were grabbing
cgroup_tree_mutex while under kernfs active_ref protection. This has
actualy possibility to lead to deadlocks in case these operations race
against cgroup_rmdir() which invokes kernfs_remove() on directory
kernfs_node while holding cgroup_tree_mutex.
Neither cgroup_create() or cgroup_rename() requires active_ref
protection. The former already has enough synchronization through
cgroup_lock_live_group() and the latter doesn't care, so this can be
fixed by updating both functions to break all active_ref protections
before grabbing cgroup_tree_mutex.
While this patch fixes the immediate issue, it probably needs further
work in the long term - kernfs directories should enable lockdep
annotations and maybe the better way to handle this is marking
directory nodes as not needing active_ref protection rather than
breaking it in each operation.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 80e0b6e8a001361316a2d62b748fe677ec46b860
Author: Richard Guy Briggs <rgb@redhat.com>
Date: Sun Mar 16 14:00:19 2014 -0400
sched: declare pid_alive as inline
We accidentally declared pid_alive without any extern/inline connotation.
Some platforms were fine with this, some like ia64 and mips were very angry.
If the function is inline, the prototype should be inline!
on ia64:
include/linux/sched.h:1718: warning: 'pid_alive' declared inline after
being called
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
Signed-off-by: Eric Paris <eparis@redhat.com>
commit 579ec9e1ab0bdca2dbc3c942aa1a530a6ec8c349
Author: Eric Paris <eparis@redhat.com>
Date: Tue Mar 11 12:55:42 2014 -0400
audit: use uapi/linux/audit.h for AUDIT_ARCH declarations
The syscall.h headers were including linux/audit.h but really only
needed the uapi/linux/audit.h to get the requisite defines. Switch to
the uapi headers.
Signed-off-by: Eric Paris <eparis@redhat.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mips@linux-mips.org
Cc: linux-s390@vger.kernel.org
Cc: x86@kernel.org
commit 5e937a9ae9137899c6641d718bd3820861099a09
Author: Eric Paris <eparis@redhat.com>
Date: Tue Mar 11 12:48:43 2014 -0400
syscall_get_arch: remove useless function arguments
Every caller of syscall_get_arch() uses current for the task and no
implementors of the function need args. So just get rid of both of
those things. Admittedly, since these are inline functions we aren't
wasting stack space, but it just makes the prototypes better.
Signed-off-by: Eric Paris <eparis@redhat.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mips@linux-mips.org
Cc: linux390@de.ibm.com
Cc: x86@kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-s390@vger.kernel.org
Cc: linux-arch@vger.kernel.org
commit b7550787fe8b5beffb5f56fa11a87712d699d085
Author: Joe Perches <jo…
torvalds
pushed a commit
that referenced
this pull request
Aug 6, 2014
Dave reported following splat, caused by improper use of IP_INC_STATS_BH() in process context. BUG: using __this_cpu_add() in preemptible [00000000] code: trinity-c117/14551 caller is __this_cpu_preempt_check+0x13/0x20 CPU: 3 PID: 14551 Comm: trinity-c117 Not tainted 3.16.0+ #33 ffffffff9ec898f0 0000000047ea7e23 ffff88022d32f7f0 ffffffff9e7ee207 0000000000000003 ffff88022d32f818 ffffffff9e397eaa ffff88023ee70b40 ffff88022d32f970 ffff8801c026d580 ffff88022d32f828 ffffffff9e397ee3 Call Trace: [<ffffffff9e7ee207>] dump_stack+0x4e/0x7a [<ffffffff9e397eaa>] check_preemption_disabled+0xfa/0x100 [<ffffffff9e397ee3>] __this_cpu_preempt_check+0x13/0x20 [<ffffffffc0839872>] sctp_packet_transmit+0x692/0x710 [sctp] [<ffffffffc082a7f2>] sctp_outq_flush+0x2a2/0xc30 [sctp] [<ffffffff9e0d985c>] ? mark_held_locks+0x7c/0xb0 [<ffffffff9e7f8c6d>] ? _raw_spin_unlock_irqrestore+0x5d/0x80 [<ffffffffc082b99a>] sctp_outq_uncork+0x1a/0x20 [sctp] [<ffffffffc081e112>] sctp_cmd_interpreter.isra.23+0x1142/0x13f0 [sctp] [<ffffffffc081c86b>] sctp_do_sm+0xdb/0x330 [sctp] [<ffffffff9e0b8f1b>] ? preempt_count_sub+0xab/0x100 [<ffffffffc083b350>] ? sctp_cname+0x70/0x70 [sctp] [<ffffffffc08389ca>] sctp_primitive_ASSOCIATE+0x3a/0x50 [sctp] [<ffffffffc083358f>] sctp_sendmsg+0x88f/0xe30 [sctp] [<ffffffff9e0d673a>] ? lock_release_holdtime.part.28+0x9a/0x160 [<ffffffff9e0d62ce>] ? put_lock_stats.isra.27+0xe/0x30 [<ffffffff9e73b624>] inet_sendmsg+0x104/0x220 [<ffffffff9e73b525>] ? inet_sendmsg+0x5/0x220 [<ffffffff9e68ac4e>] sock_sendmsg+0x9e/0xe0 [<ffffffff9e1c0c09>] ? might_fault+0xb9/0xc0 [<ffffffff9e1c0bae>] ? might_fault+0x5e/0xc0 [<ffffffff9e68b234>] SYSC_sendto+0x124/0x1c0 [<ffffffff9e0136b0>] ? syscall_trace_enter+0x250/0x330 [<ffffffff9e68c3ce>] SyS_sendto+0xe/0x10 [<ffffffff9e7f9be4>] tracesys+0xdd/0xe2 This is a followup of commits f1d8cba ("inet: fix possible seqlock deadlocks") and 7f88c6b ("ipv6: fix possible seqlock deadlock in ip6_finish_output2") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Reported-by: Dave Jones <davej@redhat.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net>
heftig
referenced
this pull request
in zen-kernel/zen-kernel
Aug 14, 2014
[ Upstream commit 757efd3 ] Dave reported following splat, caused by improper use of IP_INC_STATS_BH() in process context. BUG: using __this_cpu_add() in preemptible [00000000] code: trinity-c117/14551 caller is __this_cpu_preempt_check+0x13/0x20 CPU: 3 PID: 14551 Comm: trinity-c117 Not tainted 3.16.0+ #33 ffffffff9ec898f0 0000000047ea7e23 ffff88022d32f7f0 ffffffff9e7ee207 0000000000000003 ffff88022d32f818 ffffffff9e397eaa ffff88023ee70b40 ffff88022d32f970 ffff8801c026d580 ffff88022d32f828 ffffffff9e397ee3 Call Trace: [<ffffffff9e7ee207>] dump_stack+0x4e/0x7a [<ffffffff9e397eaa>] check_preemption_disabled+0xfa/0x100 [<ffffffff9e397ee3>] __this_cpu_preempt_check+0x13/0x20 [<ffffffffc0839872>] sctp_packet_transmit+0x692/0x710 [sctp] [<ffffffffc082a7f2>] sctp_outq_flush+0x2a2/0xc30 [sctp] [<ffffffff9e0d985c>] ? mark_held_locks+0x7c/0xb0 [<ffffffff9e7f8c6d>] ? _raw_spin_unlock_irqrestore+0x5d/0x80 [<ffffffffc082b99a>] sctp_outq_uncork+0x1a/0x20 [sctp] [<ffffffffc081e112>] sctp_cmd_interpreter.isra.23+0x1142/0x13f0 [sctp] [<ffffffffc081c86b>] sctp_do_sm+0xdb/0x330 [sctp] [<ffffffff9e0b8f1b>] ? preempt_count_sub+0xab/0x100 [<ffffffffc083b350>] ? sctp_cname+0x70/0x70 [sctp] [<ffffffffc08389ca>] sctp_primitive_ASSOCIATE+0x3a/0x50 [sctp] [<ffffffffc083358f>] sctp_sendmsg+0x88f/0xe30 [sctp] [<ffffffff9e0d673a>] ? lock_release_holdtime.part.28+0x9a/0x160 [<ffffffff9e0d62ce>] ? put_lock_stats.isra.27+0xe/0x30 [<ffffffff9e73b624>] inet_sendmsg+0x104/0x220 [<ffffffff9e73b525>] ? inet_sendmsg+0x5/0x220 [<ffffffff9e68ac4e>] sock_sendmsg+0x9e/0xe0 [<ffffffff9e1c0c09>] ? might_fault+0xb9/0xc0 [<ffffffff9e1c0bae>] ? might_fault+0x5e/0xc0 [<ffffffff9e68b234>] SYSC_sendto+0x124/0x1c0 [<ffffffff9e0136b0>] ? syscall_trace_enter+0x250/0x330 [<ffffffff9e68c3ce>] SyS_sendto+0xe/0x10 [<ffffffff9e7f9be4>] tracesys+0xdd/0xe2 This is a followup of commits f1d8cba ("inet: fix possible seqlock deadlocks") and 7f88c6b ("ipv6: fix possible seqlock deadlock in ip6_finish_output2") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Reported-by: Dave Jones <davej@redhat.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
heftig
referenced
this pull request
in zen-kernel/zen-kernel
Aug 14, 2014
[ Upstream commit 757efd3 ] Dave reported following splat, caused by improper use of IP_INC_STATS_BH() in process context. BUG: using __this_cpu_add() in preemptible [00000000] code: trinity-c117/14551 caller is __this_cpu_preempt_check+0x13/0x20 CPU: 3 PID: 14551 Comm: trinity-c117 Not tainted 3.16.0+ #33 ffffffff9ec898f0 0000000047ea7e23 ffff88022d32f7f0 ffffffff9e7ee207 0000000000000003 ffff88022d32f818 ffffffff9e397eaa ffff88023ee70b40 ffff88022d32f970 ffff8801c026d580 ffff88022d32f828 ffffffff9e397ee3 Call Trace: [<ffffffff9e7ee207>] dump_stack+0x4e/0x7a [<ffffffff9e397eaa>] check_preemption_disabled+0xfa/0x100 [<ffffffff9e397ee3>] __this_cpu_preempt_check+0x13/0x20 [<ffffffffc0839872>] sctp_packet_transmit+0x692/0x710 [sctp] [<ffffffffc082a7f2>] sctp_outq_flush+0x2a2/0xc30 [sctp] [<ffffffff9e0d985c>] ? mark_held_locks+0x7c/0xb0 [<ffffffff9e7f8c6d>] ? _raw_spin_unlock_irqrestore+0x5d/0x80 [<ffffffffc082b99a>] sctp_outq_uncork+0x1a/0x20 [sctp] [<ffffffffc081e112>] sctp_cmd_interpreter.isra.23+0x1142/0x13f0 [sctp] [<ffffffffc081c86b>] sctp_do_sm+0xdb/0x330 [sctp] [<ffffffff9e0b8f1b>] ? preempt_count_sub+0xab/0x100 [<ffffffffc083b350>] ? sctp_cname+0x70/0x70 [sctp] [<ffffffffc08389ca>] sctp_primitive_ASSOCIATE+0x3a/0x50 [sctp] [<ffffffffc083358f>] sctp_sendmsg+0x88f/0xe30 [sctp] [<ffffffff9e0d673a>] ? lock_release_holdtime.part.28+0x9a/0x160 [<ffffffff9e0d62ce>] ? put_lock_stats.isra.27+0xe/0x30 [<ffffffff9e73b624>] inet_sendmsg+0x104/0x220 [<ffffffff9e73b525>] ? inet_sendmsg+0x5/0x220 [<ffffffff9e68ac4e>] sock_sendmsg+0x9e/0xe0 [<ffffffff9e1c0c09>] ? might_fault+0xb9/0xc0 [<ffffffff9e1c0bae>] ? might_fault+0x5e/0xc0 [<ffffffff9e68b234>] SYSC_sendto+0x124/0x1c0 [<ffffffff9e0136b0>] ? syscall_trace_enter+0x250/0x330 [<ffffffff9e68c3ce>] SyS_sendto+0xe/0x10 [<ffffffff9e7f9be4>] tracesys+0xdd/0xe2 This is a followup of commits f1d8cba ("inet: fix possible seqlock deadlocks") and 7f88c6b ("ipv6: fix possible seqlock deadlock in ip6_finish_output2") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Reported-by: Dave Jones <davej@redhat.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
baerwolf
pushed a commit
to baerwolf/linux-stephan
that referenced
this pull request
Sep 19, 2014
[ Upstream commit 757efd3 ] Dave reported following splat, caused by improper use of IP_INC_STATS_BH() in process context. BUG: using __this_cpu_add() in preemptible [00000000] code: trinity-c117/14551 caller is __this_cpu_preempt_check+0x13/0x20 CPU: 3 PID: 14551 Comm: trinity-c117 Not tainted 3.16.0+ torvalds#33 ffffffff9ec898f0 0000000047ea7e23 ffff88022d32f7f0 ffffffff9e7ee207 0000000000000003 ffff88022d32f818 ffffffff9e397eaa ffff88023ee70b40 ffff88022d32f970 ffff8801c026d580 ffff88022d32f828 ffffffff9e397ee3 Call Trace: [<ffffffff9e7ee207>] dump_stack+0x4e/0x7a [<ffffffff9e397eaa>] check_preemption_disabled+0xfa/0x100 [<ffffffff9e397ee3>] __this_cpu_preempt_check+0x13/0x20 [<ffffffffc0839872>] sctp_packet_transmit+0x692/0x710 [sctp] [<ffffffffc082a7f2>] sctp_outq_flush+0x2a2/0xc30 [sctp] [<ffffffff9e0d985c>] ? mark_held_locks+0x7c/0xb0 [<ffffffff9e7f8c6d>] ? _raw_spin_unlock_irqrestore+0x5d/0x80 [<ffffffffc082b99a>] sctp_outq_uncork+0x1a/0x20 [sctp] [<ffffffffc081e112>] sctp_cmd_interpreter.isra.23+0x1142/0x13f0 [sctp] [<ffffffffc081c86b>] sctp_do_sm+0xdb/0x330 [sctp] [<ffffffff9e0b8f1b>] ? preempt_count_sub+0xab/0x100 [<ffffffffc083b350>] ? sctp_cname+0x70/0x70 [sctp] [<ffffffffc08389ca>] sctp_primitive_ASSOCIATE+0x3a/0x50 [sctp] [<ffffffffc083358f>] sctp_sendmsg+0x88f/0xe30 [sctp] [<ffffffff9e0d673a>] ? lock_release_holdtime.part.28+0x9a/0x160 [<ffffffff9e0d62ce>] ? put_lock_stats.isra.27+0xe/0x30 [<ffffffff9e73b624>] inet_sendmsg+0x104/0x220 [<ffffffff9e73b525>] ? inet_sendmsg+0x5/0x220 [<ffffffff9e68ac4e>] sock_sendmsg+0x9e/0xe0 [<ffffffff9e1c0c09>] ? might_fault+0xb9/0xc0 [<ffffffff9e1c0bae>] ? might_fault+0x5e/0xc0 [<ffffffff9e68b234>] SYSC_sendto+0x124/0x1c0 [<ffffffff9e0136b0>] ? syscall_trace_enter+0x250/0x330 [<ffffffff9e68c3ce>] SyS_sendto+0xe/0x10 [<ffffffff9e7f9be4>] tracesys+0xdd/0xe2 This is a followup of commits f1d8cba ("inet: fix possible seqlock deadlocks") and 7f88c6b ("ipv6: fix possible seqlock deadlock in ip6_finish_output2") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Reported-by: Dave Jones <davej@redhat.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
ddstreet
pushed a commit
to ddstreet/linux
that referenced
this pull request
Sep 25, 2014
I'm getting the spew below when booting with Haswell (Xeon E5-2699 v3) CPUs and the "Cluster-on-Die" (CoD) feature enabled in the BIOS. It seems similar to the issue that some folks from AMD ran in to on their systems and addressed in this commit: 161270f ("x86/smp: Fix topology checks on AMD MCM CPUs") Both these Intel and AMD systems break an assumption which is being enforced by topology_sane(): a socket may not contain more than one NUMA node. AMD special-cased their system by looking for a cpuid flag. The Intel mode is dependent on BIOS options and I do not know of a way which it is enumerated other than the tables being parsed during the CPU bringup process. In other words, we have to trust the ACPI tables <shudder>. This detects the situation where a NUMA node occurs at a place in the middle of the "CPU" sched domains. It replaces the default topology with one that relies on the NUMA information from the firmware (SRAT table) for all levels of sched domains above the hyperthreads. This also fixes a sysfs bug. We used to freak out when we saw the "mc" group cross a node boundary, so we stopped building the MC group. MC gets exported as the 'core_siblings_list' in /sys/devices/system/cpu/cpu*/topology/ and this caused CPUs with the same 'physical_package_id' to not be listed together in 'core_siblings_list'. This violates a statement from Documentation/ABI/testing/sysfs-devices-system-cpu: core_siblings: internal kernel map of cpu#'s hardware threads within the same physical_package_id. core_siblings_list: human-readable list of the logical CPU numbers within the same physical_package_id as cpu#. The sysfs effects here cause an issue with the hwloc tool where it gets confused and thinks there are more sockets than are physically present. Before this patch, there are two packages: # cd /sys/devices/system/cpu/ # cat cpu*/topology/physical_package_id | sort | uniq -c 18 0 18 1 But 4 _sets_ of core siblings: # cat cpu*/topology/core_siblings_list | sort | uniq -c 9 0-8 9 18-26 9 27-35 9 9-17 After this set, there are only 2 sets of core siblings, which is what we expect for a 2-socket system. # cat cpu*/topology/physical_package_id | sort | uniq -c 18 0 18 1 # cat cpu*/topology/core_siblings_list | sort | uniq -c 18 0-17 18 18-35 Example spew: ... NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. #2 #3 #4 #5 torvalds#6 torvalds#7 torvalds#8 .... node #1, CPUs: torvalds#9 ------------[ cut here ]------------ WARNING: CPU: 9 PID: 0 at /home/ak/hle/linux-hle-2.6/arch/x86/kernel/smpboot.c:306 topology_sane.isra.2+0x74/0x90() sched: CPU torvalds#9's mc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency. Modules linked in: CPU: 9 PID: 0 Comm: swapper/9 Not tainted 3.17.0-rc1-00293-g8e01c4d-dirty torvalds#631 Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS GRNDSDP1.86B.0036.R05.1407140519 07/14/2014 0000000000000009 ffff88046ddabe00 ffffffff8172e485 ffff88046ddabe48 ffff88046ddabe38 ffffffff8109691d 000000000000b001 0000000000000009 ffff88086fc12580 000000000000b020 0000000000000009 ffff88046ddabe98 Call Trace: [<ffffffff8172e485>] dump_stack+0x45/0x56 [<ffffffff8109691d>] warn_slowpath_common+0x7d/0xa0 [<ffffffff8109698c>] warn_slowpath_fmt+0x4c/0x50 [<ffffffff81074f94>] topology_sane.isra.2+0x74/0x90 [<ffffffff8107530e>] set_cpu_sibling_map+0x31e/0x4f0 [<ffffffff8107568d>] start_secondary+0x1ad/0x240 ---[ end trace 3fe5f587a9fcde61 ]--- torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 torvalds#16 torvalds#17 .... node #2, CPUs: torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 torvalds#24 torvalds#25 torvalds#26 .... node #3, CPUs: torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 torvalds#32 torvalds#33 torvalds#34 torvalds#35 Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> [ Added LLC domain and s/match_mc/match_die/ ] Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Borislav Petkov <bp@alien8.de> Cc: David Rientjes <rientjes@google.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Toshi Kani <toshi.kani@hp.com> Cc: brice.goglin@gmail.com Cc: "H. Peter Anvin" <hpa@linux.intel.com> Link: http://lkml.kernel.org/r/20140918193334.C065EBCE@viggo.jf.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
koct9i
referenced
this pull request
in koct9i/linux
Sep 27, 2014
GIT 2cf50762577a191f2f646e4034cc21f4764d90ab
commit 68c7ed167ef564c83a0022f2d0fe15cbdac0c5a4
Author: Peter Foley <pefoley2@pefoley.com>
Date: Thu Sep 25 10:34:04 2014 +1000
Documentation: disable vdso_test to avoid breakage with old glibc
glibc versions older than 2.16 don't include sys/auxv.h which this
executable uses.
Since we don't have a good way to test for specific glibc versions in
kbuild, just disable it for now.
Signed-off-by: Peter Foley <pefoley2@pefoley.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
commit 03979f1100aca61cf16ac7f3e464d7f11747e86b
Author: Peter Foley <pefoley2@pefoley.com>
Date: Thu Sep 25 10:34:04 2014 +1000
Documentation: update vDSO makefile to build portable examples
Signed-off-by: Peter Foley <pefoley2@pefoley.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
commit 13770826a9872de445703ee6c05b44f525f78513
Author: Peter Foley <pefoley2@pefoley.com>
Date: Thu Sep 25 10:34:04 2014 +1000
Documentation: update .gitignore files
Add some missing files to .gitignore.
Push Documentation/.gitignore down into subdirectories.
Signed-off-by: Peter Foley <pefoley2@pefoley.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
commit ce0f3b2691c066255fcf25c77e929ff8cda73417
Author: Peter Foley <pefoley2@pefoley.com>
Date: Thu Sep 25 10:34:03 2014 +1000
Documentation: support glibc versions without htole macros
glibc 2.9 introduced the htole<16/32/64> macros, add them to
tools/include to support older versions of glibc.
Reported-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Peter Foley <pefoley2@pefoley.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
commit 77cb6d96708f5b681969ce144057ae1ebda96057
Author: Mark Brown <broonie@kernel.org>
Date: Thu Sep 25 10:34:03 2014 +1000
v4l2-pci-skeleton: Only build if PCI is available
Currently arm64 does not support PCI but it does support v4l2. Since the
PCI skeleton driver is built unconditionally as a module with no dependency
on PCI this causes build failures for arm64 allmodconfig. Fix this by
defining a symbol VIDEO_PCI_SKELETON for the skeleton and conditionalising
the build on that.
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org> [added VIDEO dependencies]
commit 112a45ca901ced590ff71c5fd7d717f8771717ce
Author: Peter Foley <pefoley2@pefoley.com>
Date: Thu Sep 25 10:34:03 2014 +1000
Documentation: fix misc. warnings
Fix a few warnings that gcc emits during a default build.
Signed-off-by: Peter Foley <pefoley2@pefoley.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
commit b0fc375fe2c09477b5effc8e030668203d24c897
Author: Peter Foley <pefoley2@pefoley.com>
Date: Thu Sep 25 10:34:03 2014 +1000
Documentation: make functions static to avoid prototype warnings
Signed-off-by: Peter Foley <pefoley2@pefoley.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
commit 593ed472bcea93949c72ddc45e340fee47a05aa3
Author: Peter Foley <pefoley2@pefoley.com>
Date: Thu Sep 25 10:34:03 2014 +1000
Documentation: add makefiles for more targets
Add a bunch of previously unbuilt source files to the Documentation build
machinery.
Signed-off-by: Peter Foley <pefoley2@pefoley.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
commit cc67d673f252264535cef654c37c8dd621340e8b
Author: Peter Foley <pefoley2@pefoley.com>
Date: Thu Sep 25 10:34:02 2014 +1000
Documentation: use subdir-y to avoid unnecessary built-in.o files
Change the Documentation makefiles from obj-m to subdir-y
to avoid generating unnecessary built-in.o files since nothing
in Documentation/ is ever linked in to vmlinux.
Signed-off-by: Peter Foley <pefoley2@pefoley.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
commit bb69afeca345380203c89d2f19e95eca786b5a4c
Author: Peter Foley <pefoley2@pefoley.com>
Date: Thu Sep 25 10:34:02 2014 +1000
Documentation: remove networking/.gitignore
Remove empty networking/.gitignore
Signed-off-by: Peter Foley <pefoley2@pefoley.com>
Cc: rdunlap@infradead.org
Cc: linux-doc@vger.kernel.org
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
commit 4d96fb1ec81118c6406fe6d3670f172b2faaedf3
Author: Heiko Stuebner <heiko.stuebner@bq.com>
Date: Tue Sep 23 22:42:16 2014 +0200
power: gpio-charger: do not use gpio value directly
Some gpio implementations return interesting values for gpio_get_value when
the value is not 0 - as seen on a imx6sl board. Therefore do not use the
value returned from gpio_get_value directly but simply check for 0 or not 0.
Signed-off-by: Heiko Stuebner <heiko.stuebner@bq.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
commit ddd26dff757d08d4eb309a28bf2a02372387e71f
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date: Tue Sep 16 18:10:41 2014 +0200
power: max8925: Use of_get_child_by_name
Use of_get_child_by_name to obtain reference to charger node instead of
of_find_node_by_name which can walk outside of the parent node.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
commit 920ac5be91bc447c5ef82f457207a169aa79c5f6
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date: Tue Sep 16 18:10:40 2014 +0200
power: max8925: Fix NULL ptr dereference on memory allocation failure
Check the return value of devm_kzalloc() to fix possible NULL pointer
dereference and properly exit the probe() on memory allocation failure.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
commit 628ef02c56e515430dd8d8439126dd0ecb8ce8bb
Author: Puthikorn Voravootivat <puthik@chromium.org>
Date: Tue Sep 9 12:20:35 2014 -0700
bq27x00_battery: Add support to bq27742
Add support to bq27742 in bq27x00 driver. bq27742 register
addresses are mostly mostly the same as bq27500 addresses
with minor differences.
Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Rhyland Klein <rklein@nvidia.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
commit 042e1c79166b9250edd8262bea84e1703f27ad2e
Author: Jin Yao <yao.jin@linux.intel.com>
Date: Mon Sep 22 10:31:14 2014 -0700
Input: soc_button_array - convert to platform bus
ACPI device enumeration mechanism changed a lot since 3.16-rc1.
ACPI device objects with _HID will be enumerated to platform bus by default.
For the existing PNP drivers that probe the PNPACPI devices, the device ids
are listed explicitly in drivers/acpi/acpi_pnp.c.
But ACPI folks will continue their effort on shrinking this id list by
converting the PNP drivers to platform drivers, for the devices that don't
belong to PNP bus in nature.
Signed-off-by: Jin Yao <yao.jin@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
commit 3049683eafdbbbd7350b0e5ca02a2d8c026a3362
Author: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
Date: Wed Sep 24 16:00:33 2014 -0700
Input: i8042 - fix Asus X450LCP touchpad detection
We need to add this module to the nomux table to be able to detect the
touchpad.
Cc: stablevger.kernel.org
Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
commit 3f3d0463636e38a27c3000d59889b8bdc9072ce1
Author: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Date: Thu Sep 25 08:23:26 2014 +0900
ARM: dts: Remove display timings node from exynos5250-snow
Commit a3d72cad63ed ("ARM: dts: Clean up exynos5250-snow")
improved the Snow DTS but the patch was rebased due conflicting
changes and the merge resolution added a device node removed by
commit a98c3c23868f ("ARM: dts: update display related nodes for
exynos5250-snow").
This patch removes the node again to keep the DTS as before.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit dd12ac7fb3988be113465f499ad91b30b8aa4bdd
Author: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Date: Thu Sep 25 08:21:25 2014 +0900
ARM: dts: Fix chip select GPIO on exynos5250-smdk5250
Commit 65bbe3fee0e1 ("ARM: dts: Clean up exynos5250-smdk5250")
improved the smdk5250 DTS but the patch was rebased due conflicting
changes and the merge resolution added a regression of the bug fixed
in commit e138d4333aa0 ("ARM: dts: fix the chip select gpios definition
in the SPI nodes").
This patch fixes the issue by removing the old cs-gpio and using
the generic cs-gpios property.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
commit 5c4dd348af35a6f6db97b4f2401f74c71f7f3c7d
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Thu Sep 25 00:53:44 2014 +0200
Revert "PM / Hibernate: Iterate over set bits instead of PFNs in swsusp_free()"
Revert commit 6efde38f0769 (PM / Hibernate: Iterate over set bits
instead of PFNs in swsusp_free()) that introduced a NULL pointer
dereference during system resume from hibernation:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffff810a8cc1>] swsusp_free+0x21/0x190
PGD b39c2067 PUD b39c1067 PMD 0
Oops: 0000 [#1] SMP
Modules linked in: <irrelevant list of modules>
CPU: 1 PID: 4898 Comm: s2disk Tainted: G C 3.17-rc5-amd64 #1 Debian 3.17~rc5-1~exp1
Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
task: ffff88023155ea40 ti: ffff8800b3b14000 task.ti: ffff8800b3b14000
RIP: 0010:[<ffffffff810a8cc1>] [<ffffffff810a8cc1>]
swsusp_free+0x21/0x190
RSP: 0018:ffff8800b3b17ea8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8800b39bab00 RCX: 0000000000000001
RDX: ffff8800b39bab10 RSI: ffff8800b39bab00 RDI: 0000000000000000
RBP: 0000000000000010 R08: 0000000000000000 R09: 0000000000000000
R10: ffff8800b39bab10 R11: 0000000000000246 R12: ffffea0000000000
R13: ffff880232f485a0 R14: ffff88023ac27cd8 R15: ffff880232927590
FS: 00007f406d83b700(0000) GS:ffff88023bc80000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 00000000b3a62000 CR4: 00000000000007e0
Stack:
ffff8800b39bab00 0000000000000010 ffff880232927590 ffffffff810acb4a
ffff8800b39bab00 ffffffff811a955a ffff8800b39bab10 0000000000000000
ffff88023155f098 ffffffff81a6b8c0 ffff88023155ea40 0000000000000007
Call Trace:
[<ffffffff810acb4a>] ? snapshot_release+0x2a/0xb0
[<ffffffff811a955a>] ? __fput+0xca/0x1d0
[<ffffffff81080627>] ? task_work_run+0x97/0xd0
[<ffffffff81012d89>] ? do_notify_resume+0x69/0xa0
[<ffffffff8151452a>] ? int_signal+0x12/0x17
Code: 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 41 54 48 8b 05 ba 62 9c 00 49 bc 00 00 00 00 00 ea ff ff 48 8b 3d a1 62 9c 00 55 53 <48> 8b 10 48 89 50 18 48 8b 52 20 48 c7 40 28 00 00 00 00 c7 40
RIP [<ffffffff810a8cc1>] swsusp_free+0x21/0x190
RSP <ffff8800b3b17ea8>
CR2: 0000000000000000
---[ end trace f02be86a1ec0cccb ]---
due to forbidden_pages_map being NULL in swsusp_free().
Fixes: 6efde38f0769 "PM / Hibernate: Iterate over set bits instead of PFNs in swsusp_free()"
Reported-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
commit a928f97152ea39c31f8ea89b60dd30a169d4ed6e
Author: Peter Hüwe <PeterHuewe@gmx.de>
Date: Fri Sep 12 21:09:47 2014 +0200
i2c: acpi: Fix NULL Pointer dereference
If adapter->dev.parent == NULL there is a NULL pointer dereference in
acpi_i2c_install_space_handler and acpi_i2c_remove_space_handler.
This is present since introduction of this code:
366047515c6e "i2c: rework kernel config I2C_ACPI" or even
da3c6647ee08 "I2C/ACPI: Clean up I2C ACPI code and Add CONFIG_I2C_ACPI"
The adapter->dev.parent == NULL case is valid for the i2c_stub,
so loading i2c_stub with ACPI_I2C_OPREGION enabled results in an oops.
This is also valid at least for i2c_tiny_usb and i2c_robotfuzz_osif.
Fix by checking whether it is null before calling ACPI_HANDLE.
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
commit c15d821ddb9dac9ac6b5beb75bf942f3bc3a4004
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date: Tue Sep 23 10:35:54 2014 +0800
gpio / ACPI: Use pin index and bit length
Fix code when the operation region callback is for an gpio, which
is not at index 0 and for partial pins in a GPIO definition.
For example:
Name (GMOD, ResourceTemplate ()
{
//3 Outputs that define the Power mode of the device
GpioIo (Exclusive, PullDown, , , , "\\_SB.GPI2") {10, 11, 12}
})
}
If opregion callback calls is for:
- Set pin 10, then address = 0 and bit length = 1
- Set pin 11, then address = 1 and bit length = 1
- Set for both pin 11 and pin 12, then address = 1, bit length = 2
This change requires updated ACPICA gpio operation handler code to
send the pin index and bit length.
Fixes: 473ed7be0da0 (gpio / ACPI: Add support for ACPI GPIO operation regions)
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: 3.15+ <stable@vger.kernel.org> # 3.15+: 75ec6e55f138 ACPICA: Update to GPIO region handler interface.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
commit 75ec6e55f1384548311a13ce4fcb39c516053314
Author: Bob Moore <Robert.Moore@intel.com>
Date: Tue Sep 23 10:35:47 2014 +0800
ACPICA: Update to GPIO region handler interface.
Changes to correct several GPIO issues:
1) The update_rule in a GPIO field definition is now ignored;
a read-modify-write operation is never performed for GPIO fields.
(Internally, this means that the field assembly/disassembly
code is completely bypassed for GPIO.)
2) The Address parameter passed to a GPIO region handler is
now the bit offset of the field from a previous Connection()
operator. Thus, it becomes a "Pin Number Index" into the
Connection() resource descriptor.
3) The bit_width parameter passed to a GPIO region handler is
now the exact bit width of the GPIO field. Thus, it can be
interpreted as "number of pins".
Overall, we can now say that the region handler interface
to GPIO handlers is a raw "bit/pin" addressed interface, not
a byte-addressed interface like the system_memory handler interface.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: 3.15+ <stable@vger.kernel.org> # 3.15+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
commit 457920817e645a7dee42c2a75c81c5ed8e12ee1c
Author: Fu Zhonghui <zhonghui.fu@linux.intel.com>
Date: Wed Sep 24 22:42:26 2014 +0200
ACPI / platform / LPSS: disable async suspend/resume of LPSS devices
On some systems (Asus T100 in particular) there are strict ordering
dependencies between LPSS devices with respect to power management
that break if they suspend/resume asynchronously.
In theory it should be possible to follow those dependencies in the
async suspend/resume case too (the ACPI tables tell as that the
dependencies are there), but since we're missing infrastructure
for that at the moment, disable async suspend/resume for all of
the LPSS devices for the time being.
Link: http://marc.info/?l=linux-acpi&m=141158962321905&w=2
Fixes: 8ce62f85a81f (ACPI / platform / LPSS: Enable async suspend/resume of LPSS devices)
Signed-off-by: Li Aubrey <aubrey.li@linux.intel.com>
Signed-off-by: Fu Zhonghui <zhonghui.fu@linux.intel.com>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
commit c7da579763f29cf45a861ad4c339aba590d8b80d
Author: Johan Hedberg <johan.hedberg@intel.com>
Date: Wed Sep 24 22:41:46 2014 +0300
Bluetooth: Add retransmission effort into SCO parameter table
It is expected that new parameter combinations will have the
retransmission effort value different between some entries (mainly
because of the new S4 configuration added by HFP 1.7), so it makes sense
to move it into the table instead of having it hard coded based on the
selected SCO_AIRMODE_*.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
commit b2fc3f3c6d397d434174147eca3db1ec778195ce
Author: Olof Johansson <olof@lixom.net>
Date: Wed Sep 24 11:42:38 2014 -0700
drivers/soc: ti: fix build break with modules
Fixes below build break by not switching to stubs when the driver is a module:
drivers/soc/ti/knav_dma.c:418:7: error: redefinition of 'knav_dma_open_channel'
void *knav_dma_open_channel(struct device *dev, const char *name,
^
In file included from drivers/soc/ti/knav_dma.c:26:0:
include/linux/soc/ti/knav_dma.h:165:21: note: previous definition of 'knav_dma_open_channel' was here
static inline void *knav_dma_open_channel(struct device *dev, const char *name,
^
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
commit 2d9251e3501356ceb44444a8f9a393b57163dc6a
Author: Matthias Brugger <matthias.bgg@gmail.com>
Date: Mon Aug 18 16:58:00 2014 +0200
ARM: multi_v7_defconfig: Enable Mediatek platform
Enable Mediatek platform support for multi_v7_defconfig.
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
commit d66820853251e8a9b53125a95a773e482cd79136
Author: Matthias Brugger <matthias.bgg@gmail.com>
Date: Mon Aug 18 16:58:00 2014 +0200
ARM: mediatek: Add earlyprintk support for mt6589
Enable low-level debug for Mediatek mt6589 SoC on UART0.
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
commit 7e9b2828f25ec156623da0c2156604066de5514d
Author: Matthias Brugger <matthias.bgg@gmail.com>
Date: Mon Aug 18 16:58:00 2014 +0200
ARM: dts: mt6589: Change compatible string for GIC
This patch changes the compatible string of the GIC to the
new "arm,cortex-a7-gic" which does reflect the actual hardware.
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
commit 6e9cb2633698ddadd2493b3793dbc9723f570538
Author: Matthias Brugger <matthias.bgg@gmail.com>
Date: Mon Aug 18 16:58:00 2014 +0200
ARM: dts: mediatek: Add compatible property for aquaris5
Add the missing 'compatible' property to device tree root node of
- mt6589-aquaris5.dts
and document the new values.
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
commit d82df11466df3e0934c7e7aa2f5e08c284e1fd9d
Author: Matthias Brugger <matthias.bgg@gmail.com>
Date: Mon Aug 18 16:58:00 2014 +0200
ARM: dts: mt6589-aquaris5: Add boot argument earlyprintk
Add boot argument for earlyprintk to the aquaris5 device tree file.
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
commit 510f1d72e526e776243397142cbcd459dd2a2efa
Author: Matthias Brugger <matthias.bgg@gmail.com>
Date: Mon Aug 18 16:58:00 2014 +0200
ARM: dts: mt6589: Fix typo in GIC unit address
This changes the unit address of the gic node to it's first register area.
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
commit 995425883e4087a4bfd61d12e442089d1201fc5c
Author: Matthias Brugger <matthias.bgg@gmail.com>
Date: Mon Aug 18 16:58:00 2014 +0200
ARM: dts: Build dtb for Mediatek board
This allows the "make dtbs" to build the aquaris5 dtb for the Mediatek
SoC.
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
commit 00e978180b1fa211c30642139149ea448ff06c55
Author: Pawel Moll <pawel.moll@arm.com>
Date: Mon Sep 15 15:33:48 2014 +0100
bus: arm-ccn: Fix spurious warning message
Because CCN's cycle counter always runs, it will generate
an interrupt on overflow even if the relevant perf event
was not requested, causing a spurious warning message.
Fixed now by warning on only normal counter unwanted
overflows. Also cleaning the overflow mask at init now,
not to warn on event previously requested by firmware.
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
commit 94e57fea62020dbf6e5d0093eabcd28366e86044
Author: Francesco Ruggeri <fruggeri@arista.com>
Date: Wed Sep 24 10:12:41 2014 -0700
PCI: Move PCI_VENDOR_ID_VMWARE to pci_ids.h
Move PCI_VENDOR_ID_VMWARE from device-specific files to pci_ids.h.
It is useful to always have access to it, especially when accessing
subsystem_vendor_id on emulated devices.
[bhelgaas: keep pci_ids.h sorted and use lower-case hex]
Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
commit 17497acbdce9506fd6a75115dee4ab80c3cc5ee5
Author: Tejun Heo <tj@kernel.org>
Date: Wed Sep 24 13:31:50 2014 -0400
blk-mq, percpu_ref: start q->mq_usage_counter in atomic mode
blk-mq uses percpu_ref for its usage counter which tracks the number
of in-flight commands and used to synchronously drain the queue on
freeze. percpu_ref shutdown takes measureable wallclock time as it
involves a sched RCU grace period. This means that draining a blk-mq
takes measureable wallclock time. One would think that this shouldn't
matter as queue shutdown should be a rare event which takes place
asynchronously w.r.t. userland.
Unfortunately, SCSI probing involves synchronously setting up and then
tearing down a lot of request_queues back-to-back for non-existent
LUNs. This means that SCSI probing may take above ten seconds when
scsi-mq is used.
[ 0.949892] scsi host0: Virtio SCSI HBA
[ 1.007864] scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK 1.1. PQ: 0 ANSI: 5
[ 1.021299] scsi 0:0:1:0: Direct-Access QEMU QEMU HARDDISK 1.1. PQ: 0 ANSI: 5
[ 1.520356] tsc: Refined TSC clocksource calibration: 2491.910 MHz
<stall>
[ 16.186549] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 16.190478] sd 0:0:1:0: Attached scsi generic sg1 type 0
[ 16.194099] osd: LOADED open-osd 0.2.1
[ 16.203202] sd 0:0:0:0: [sda] 31457280 512-byte logical blocks: (16.1 GB/15.0 GiB)
[ 16.208478] sd 0:0:0:0: [sda] Write Protect is off
[ 16.211439] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 16.218771] sd 0:0:1:0: [sdb] 31457280 512-byte logical blocks: (16.1 GB/15.0 GiB)
[ 16.223264] sd 0:0:1:0: [sdb] Write Protect is off
[ 16.225682] sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
This is also the reason why request_queues start in bypass mode which
is ended on blk_register_queue() as shutting down a fully functional
queue also involves a RCU grace period and the queues for non-existent
SCSI devices never reach registration.
blk-mq basically needs to do the same thing - start the mq in a
degraded mode which is faster to shut down and then make it fully
functional only after the queue reaches registration. percpu_ref
recently grew facilities to force atomic operation until explicitly
switched to percpu mode, which can be used for this purpose. This
patch makes blk-mq initialize q->mq_usage_counter in atomic mode and
switch it to percpu mode only once blk_register_queue() is reached.
Note that this issue was previously worked around by 0a30288da1ae
("blk-mq, percpu_ref: implement a kludge for SCSI blk-mq stall during
probe") for v3.17. The temp fix was reverted in preparation of adding
persistent atomic mode to percpu_ref by 9eca80461a45 ("Revert "blk-mq,
percpu_ref: implement a kludge for SCSI blk-mq stall during probe"").
This patch and the prerequisite percpu_ref changes will be merged
during v3.18 devel cycle.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Christoph Hellwig <hch@infradead.org>
Link: http://lkml.kernel.org/g/20140919113815.GA10791@lst.de
Fixes: add703fda981 ("blk-mq: use percpu_ref for mq usage count")
Reviewed-by: Kent Overstreet <kmo@daterainc.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Johannes Weiner <hannes@cmpxchg.org>
commit e4de4d412fc0d07f820906dcd70ede06dad312e2
Author: Olof Johansson <olof@lixom.net>
Date: Wed Sep 24 10:34:06 2014 -0700
ARM: at91: Fix bad conflict resolution in board-dt-sama5.c
Signed-off-by: Olof Johansson <olof@lixom.net>
commit 3c9703a87bdda1fef221ab0957a3ec2a2126f129
Author: Olof Johansson <olof@lixom.net>
Date: Wed Sep 24 10:32:20 2014 -0700
Revert "ARM: make arrays containing machine compatible strings const"
I dropped it from next/cleanup, doing a revert on for-next instead of
rebuilding the branch.
This reverts commit fbce9bc876ab2c905f1f82a78bc25745e98760d9.
commit 1cae13e75b7a7848c03138636d4eb8d8a5054dd5
Author: Tejun Heo <tj@kernel.org>
Date: Wed Sep 24 13:31:50 2014 -0400
percpu_ref: make INIT_ATOMIC and switch_to_atomic() sticky
Currently, a percpu_ref which is initialized with
PERPCU_REF_INIT_ATOMIC or switched to atomic mode via
switch_to_atomic() automatically reverts to percpu mode on the first
percpu_ref_reinit(). This makes the atomic mode difficult to use for
cases where a percpu_ref is used as a persistent on/off switch which
may be cycled multiple times.
This patch makes such atomic state sticky so that it survives through
kill/reinit cycles. After this patch, atomic state is cleared only by
an explicit percpu_ref_switch_to_percpu() call.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Kent Overstreet <kmo@daterainc.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
commit 2aad2a86f6685c10360ec8a5a55eb9ab7059cb72
Author: Tejun Heo <tj@kernel.org>
Date: Wed Sep 24 13:31:50 2014 -0400
percpu_ref: add PERCPU_REF_INIT_* flags
With the recent addition of percpu_ref_reinit(), percpu_ref now can be
used as a persistent switch which can be turned on and off repeatedly
where turning off maps to killing the ref and waiting for it to drain;
however, there currently isn't a way to initialize a percpu_ref in its
off (killed and drained) state, which can be inconvenient for certain
persistent switch use cases.
Similarly, percpu_ref_switch_to_atomic/percpu() allow dynamic
selection of operation mode; however, currently a newly initialized
percpu_ref is always in percpu mode making it impossible to avoid the
latency overhead of switching to atomic mode.
This patch adds @flags to percpu_ref_init() and implements the
following flags.
* PERCPU_REF_INIT_ATOMIC : start ref in atomic mode
* PERCPU_REF_INIT_DEAD : start ref killed and drained
These flags should be able to serve the above two use cases.
v2: target_core_tpg.c conversion was missing. Fixed.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Kent Overstreet <kmo@daterainc.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
commit f47ad45784611297b699f3dffb6c7222b76afe64
Author: Tejun Heo <tj@kernel.org>
Date: Wed Sep 24 13:31:49 2014 -0400
percpu_ref: decouple switching to percpu mode and reinit
percpu_ref has treated the dropping of the base reference and
switching to atomic mode as an integral operation; however, there's
nothing inherent tying the two together.
The use cases for percpu_ref have been expanding continuously. While
the current init/kill/reinit/exit model can cover a lot, the coupling
of kill/reinit with atomic/percpu mode switching is turning out to be
too restrictive for use cases where many percpu_refs are created and
destroyed back-to-back with only some of them reaching extended
operation. The coupling also makes implementing always-atomic debug
mode difficult.
This patch separates out percpu mode switching into
percpu_ref_switch_to_percpu() and reimplements percpu_ref_reinit() on
top of it.
* DEAD still requires ATOMIC. A dead ref can't be switched to percpu
mode w/o going through reinit.
v2: __percpu_ref_switch_to_percpu() was missing static. Fixed.
Reported by Fengguang aka kbuild test robot.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Kent Overstreet <kmo@daterainc.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: kbuild test robot <fengguang.wu@intel.com>
commit 490c79a65708873228cf114cf00e32c204e4e907
Author: Tejun Heo <tj@kernel.org>
Date: Wed Sep 24 13:31:49 2014 -0400
percpu_ref: decouple switching to atomic mode and killing
percpu_ref has treated the dropping of the base reference and
switching to atomic mode as an integral operation; however, there's
nothing inherent tying the two together.
The use cases for percpu_ref have been expanding continuously. While
the current init/kill/reinit/exit model can cover a lot, the coupling
of kill/reinit with atomic/percpu mode switching is turning out to be
too restrictive for use cases where many percpu_refs are created and
destroyed back-to-back with only some of them reaching extended
operation. The coupling also makes implementing always-atomic debug
mode difficult.
This patch separates out atomic mode switching into
percpu_ref_switch_to_atomic() and reimplements
percpu_ref_kill_and_confirm() on top of it.
* The handling of __PERCPU_REF_ATOMIC and __PERCPU_REF_DEAD is now
differentiated. Among get/put operations, percpu_ref_tryget_live()
is the only one which cares about DEAD.
* percpu_ref_switch_to_atomic() can be called multiple times on the
same ref. This means that multiple @confirm_switch may get queued
up which we can't do reliably without extra memory area. This is
handled by making the later invocation synchronously wait for the
completion of the previous one. This isn't particularly desirable
but such synchronous waits shouldn't happen in most cases.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Kent Overstreet <kmo@daterainc.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
commit 27344a9017cdaff82a167827da3001a0918afdc3
Author: Tejun Heo <tj@kernel.org>
Date: Wed Sep 24 13:31:49 2014 -0400
percpu_ref: add PCPU_REF_DEAD
percpu_ref will be restructured so that percpu/atomic mode switching
and reference killing are dedoupled. In preparation, add
PCPU_REF_DEAD and PCPU_REF_ATOMIC_DEAD which is OR of ATOMIC and DEAD.
For now, ATOMIC and DEAD are changed together and all PCPU_REF_ATOMIC
uses are converted to PCPU_REF_ATOMIC_DEAD without causing any
behavior changes.
percpu_ref_init() now specifies an explicit alignment when allocating
the percpu counters so that the pointer has enough unused low bits to
accomodate the flags. Note that one flag was fine as min alignment
for percpu memory is 2 bytes but two flags are already too many for
the natural alignment of unsigned longs on archs like cris and m68k.
v2: The original patch had BUILD_BUG_ON() which triggers if unsigned
long's alignment isn't enough to accomodate the flags, which
triggered on cris and m64k. percpu_ref_init() updated to specify
the required alignment explicitly. Reported by Fengguang.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Kent Overstreet <kmo@daterainc.com>
Cc: kbuild test robot <fengguang.wu@intel.com>
commit 9e804d1f58da1eca079f796347c1cf1d1df564e2
Author: Tejun Heo <tj@kernel.org>
Date: Wed Sep 24 13:31:48 2014 -0400
percpu_ref: rename things to prepare for decoupling percpu/atomic mode switch
percpu_ref will be restructured so that percpu/atomic mode switching
and reference killing are dedoupled. In preparation, do the following
renames.
* percpu_ref->confirm_kill -> percpu_ref->confirm_switch
* __PERCPU_REF_DEAD -> __PERCPU_REF_ATOMIC
* __percpu_ref_alive() -> __ref_is_percpu()
This patch is pure rename and doesn't introduce any functional
changes.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Kent Overstreet <kmo@daterainc.com>
commit eecc16ba9a49b05dd847a317af166a6728eb56ca
Author: Tejun Heo <tj@kernel.org>
Date: Wed Sep 24 13:31:48 2014 -0400
percpu_ref: replace pcpu_ prefix with percpu_
percpu_ref uses pcpu_ prefix for internal stuff and percpu_ for
externally visible ones. This is the same convention used in the
percpu allocator implementation. It works fine there but percpu_ref
doesn't have too much internal-only stuff and scattered usages of
pcpu_ prefix are confusing than helpful.
This patch replaces all pcpu_ prefixes with percpu_. This is pure
rename and there's no functional change. Note that PCPU_REF_DEAD is
renamed to __PERCPU_REF_DEAD to signify that the flag is internal.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Kent Overstreet <kmo@daterainc.com>
commit 6251f9976af7656b6970a8820153f356430f5de2
Author: Tejun Heo <tj@kernel.org>
Date: Wed Sep 24 13:31:48 2014 -0400
percpu_ref: minor code and comment updates
* Some comments became stale. Updated.
* percpu_ref_tryget() unnecessarily initializes @ret. Removed.
* A blank line removed from percpu_ref_kill_rcu().
* Explicit function name in a WARN format string replaced with __func__.
* WARN_ON() in percpu_ref_reinit() converted to WARN_ON_ONCE().
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Kent Overstreet <kmo@daterainc.com>
commit a2237370194484ee6aeeff04b617e4b14d178966
Author: Tejun Heo <tj@kernel.org>
Date: Wed Sep 24 13:31:48 2014 -0400
percpu_ref: relocate percpu_ref_reinit()
percpu_ref is gonna go through restructuring. Move
percpu_ref_reinit() after percpu_ref_kill_and_confirm(). This will
make later changes easier to follow and result in cleaner
organization.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Kent Overstreet <kmo@daterainc.com>
commit 1aafa57340c6d906a285d7823e0fe68696c1ae07
Author: Wei Xu <xuwei5@hisilicon.com>
Date: Wed Sep 24 17:07:48 2014 +0800
ARM: hisi: Fix platmcpm compilation when ARMv6 is selected
When compiling with "ARCH=arm" and "allmodconfig",
with commit: 9cdc99919a95e8b54c1998b65bb1bfdabd47d27b [2/7] ARM: hisi: enable MCPM implementation
we will get:
/tmp/cc6DjYjT.s: Assembler messages:
/tmp/cc6DjYjT.s:63: Error: selected processor does not support ARM mode `ubfx r1,r0,#8,#8'
/tmp/cc6DjYjT.s:761: Error: selected processor does not support ARM mode `isb '
/tmp/cc6DjYjT.s:762: Error: selected processor does not support ARM mode `dsb '
/tmp/cc6DjYjT.s:769: Error: selected processor does not support ARM mode `isb '
/tmp/cc6DjYjT.s:775: Error: selected processor does not support ARM mode `isb '
/tmp/cc6DjYjT.s:776: Error: selected processor does not support ARM mode `dsb '
/tmp/cc6DjYjT.s:795: Error: selected processor does not support ARM mode `isb '
/tmp/cc6DjYjT.s:801: Error: selected processor does not support ARM mode `isb '
/tmp/cc6DjYjT.s:802: Error: selected processor does not support ARM mode `dsb '
Fix platmcpm compilation when ARMv6 is selected.
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
commit 495aa2e1facebf770224c33aae2a01541889e54e
Author: Liviu Dudau <Liviu.Dudau@arm.com>
Date: Tue Sep 23 20:01:14 2014 +0100
arm64: Add architectural support for PCI
Use the generic PCI domain and OF functions to provide support for PCI
on arm64.
[bhelgaas: Change comments to use generic PCI, not just PCIe. Nothing at
this level is PCIe-specific.]
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
commit b766eafe68281a12169f9eb8c06fd80d2e7897d7
Author: Liviu Dudau <Liviu.Dudau@arm.com>
Date: Tue Sep 23 20:01:13 2014 +0100
PCI: Add pci_remap_iospace() to map bus I/O resources
Add pci_remap_iospace() to map bus I/O resources into the CPU virtual
address space. Architectures with special needs may provide their own
version, but most should be able to use this one.
This function is useful for PCI host bridge drivers that need to map the
PCI I/O resources into virtual memory space.
[bhelgaas: phys_addr description, drop temporary "err" variable]
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
CC: Arnd Bergmann <arnd@arndb.de>
commit 5a4f662d44116022e3378b32a1a79b718e110096
Author: Liviu Dudau <Liviu.Dudau@arm.com>
Date: Tue Sep 23 20:01:12 2014 +0100
PCI: Assign unassigned bus resources in pci_scan_root_bus()
If the firmware has not assigned all the bus resources and we are not just
probing the PCI buses, it makes sense to assign the unassigned resources
in pci_scan_root_bus().
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
CC: Rob Herring <robh+dt@kernel.org>
commit 07428b62addb624a3b51b6e8a213fec9b97dbfd0
Author: Liviu Dudau <Liviu.Dudau@arm.com>
Date: Wed Sep 24 11:27:33 2014 -0600
of/pci: Add support for parsing PCI host bridge resources from DT
Provide a function to parse the PCI DT ranges that can be used to create a
pci_host_bridge structure together with its associated bus.
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
[make io_base parameter optional]
Signed-off-by: Robert Richter <rrichter@cavium.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Grant Likely <grant.likely@linaro.org>
CC: Rob Herring <robh+dt@kernel.org>
CC: Catalin Marinas <catalin.marinas@arm.com>
commit 9eca80461a45177e456219a9cd944c27675d6512
Author: Tejun Heo <tj@kernel.org>
Date: Wed Sep 24 13:07:33 2014 -0400
Revert "blk-mq, percpu_ref: implement a kludge for SCSI blk-mq stall during probe"
This reverts commit 0a30288da1aec914e158c2d7a3482a85f632750f, which
was a temporary fix for SCSI blk-mq stall issue. The following
patches will fix the issue properly by introducing atomic mode to
percpu_ref.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Kent Overstreet <kmo@daterainc.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Christoph Hellwig <hch@lst.de>
commit 83417b202bf5aa2cd82637aa81aa9f065cfe5f21
Author: Wolfram Sang <wsa@the-dreams.de>
Date: Mon Sep 22 19:41:00 2014 +0200
i2c: move acpi code back into the core
Commit 5d98e61d337c ("I2C/ACPI: Add i2c ACPI operation region support")
renamed the i2c-core module. This may cause regressions for
distributions, so put the ACPI code back into the core.
Reported-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Lan Tianyu <tianyu.lan@intel.com>
commit 964356938fcd3c0001a786f55b9f0a0fbe47656a
Author: Andreas Werner <andreas.werner@men.de>
Date: Wed Aug 27 19:53:06 2014 +0200
hwmon: (menf21bmc) Introduce MEN14F021P00 BMC HWMON driver
Added driver to support the 14F021P00 BMC Hardware Monitoring.
The BMC is a Board Management Controller including monitoring of the
board voltages.
Signed-off-by: Andreas Werner <andreas.werner@men.de>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
commit 38433639af915deeb0b0e28462dd740ce57b72fd
Author: Andreas Werner <andreas.werner@men.de>
Date: Wed Aug 27 19:52:36 2014 +0200
leds: leds-menf21bmc: Introduce MEN 14F021P00 BMC LED driver
Added driver to support the 14F021P00 BMC LEDs.
The BMC is a Board Management Controller including four LEDs which
can be switched on and off.
Signed-off-by: Andreas Werner <andreas.werner@men.de>
Acked-by: Bryan Wu <cooloney@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
commit 5033263992eece84e19946d2cab940c86ec862ba
Author: Andreas Werner <andreas.werner@men.de>
Date: Wed Aug 27 19:52:06 2014 +0200
watchdog: menf21bmc_wdt: Introduce MEN 14F021P00 BMC Watchdog driver
Added driver to support the 14F021P00 BMC Watchdog.
The BMC is a Board Management Controller including watchdog functionality.
Signed-off-by: Andreas Werner <andreas.werner@men.de>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
commit d6cc1f5824cbca392d099f3bb0c441efd9e54de9
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date: Fri Sep 12 08:54:00 2014 +0200
Documentation: charger: max14577: Document exported sysfs entry
Document the 'fast charge timer' setting exported by max14577 driver
through sysfs entry.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
commit 8d70d68d7a1b3082ca5a3808be18103a83ae348d
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date: Fri Sep 12 08:53:59 2014 +0200
devicetree: mfd: max14577: Add device tree bindings document
Add document describing device tree bindings for MAX14577 MFD
drivers: MFD core, extcon, regulator and charger.
Both MAX14577 and MAX77836 chipsets are documented.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
commit 2c33e9296202cd11bf2e2f801b69ffba0953748a
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date: Fri Sep 12 08:53:58 2014 +0200
power: max17040: Add ID for MAX77836 Fuel Gauge block
MAX77836 has the same Fuel Gauge as MAX17040/17048. The max17040 driver
can be safely re-used. The patch adds MAX77836 device to the array of
i2c_device_id. Additionally it removes the id associated with MAX17040
device as the value is not used.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
commit e30110e9c96f48aea01abc3e6dfadb369cbafec3
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date: Fri Sep 12 08:53:57 2014 +0200
charger: max14577: Configure battery-dependent settings from DTS and sysfs
Remove hard-coded values for:
- Fast Charge current,
- End Of Charge current,
- Fast Charge timer,
- Overvoltage Protection Threshold,
- Battery Constant Voltage,
and use DTS or sysfs to configure them. This allows using the max14577 charger
driver with different batteries.
Now the charger driver requires valid configuration data from DTS. In
case of wrong configuration data it fails during probe.
The fast charge timer is configured through sysfs entry.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
commit b8f139f68f2099b7f8b4ef470a1e53210e3aa025
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date: Fri Sep 12 08:53:56 2014 +0200
regulator/mfd: max14577: Export symbols for calculating charger current
This patch prepares for changing the max14577 charger driver to allow
configuring battery-dependent settings from DTS.
The patch moves from regulator driver to MFD core driver and exports:
- function for calculating register value for charger's current;
- table of limits for chargers (MAX14577, MAX77836).
Previously they were used only by the max14577 regulator driver. In next
patch the charger driver will use them as well. Exporting them will
reduce unnecessary code duplication.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: Mark Brown <broonie@linaro.org>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
commit 3682a8ee87f9107253e51733f42da10160ce41e3
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date: Fri Sep 12 08:53:55 2014 +0200
charger: max14577: Add support for MAX77836 charger
Add support for MAX77836 charger to the max14577 driver. The MAX77836
charger is almost the same as 14577 model except:
- No dead-battery detection;
- Support for special charger (like in MAX77693);
- Support for DX over-voltage protection (like in MAX77693);
- Lower values of charging current (two times lower current for
slow/fast charge, much lower EOC current);
- Slightly different values in ChgTyp field of STATUS2 register. On
MAX14577 0x6 is reserved and 0x7 dead battery. On the MAX77836 the
0x6 means special charger and 0x7 is reserved. Regardless of these
differences the driver maps them to one enum max14577_muic_charger_type.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
commit 2f4096e311ef0922c42cbf7bc5df44efb3aff716
Author: Quentin Lambert <lambert.quentin@gmail.com>
Date: Sun Sep 7 20:04:28 2014 +0200
PCI: Remove assignment from complicated "if" conditions
The modifications effectively change the value of len_tmp
in the case where the first condition is not met.
Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
commit 79e50e72986c9fcb06d707ce587cfd24fefa33e3
Author: Quentin Lambert <lambert.quentin@gmail.com>
Date: Sun Sep 7 20:03:32 2014 +0200
PCI: Remove assignment from "if" conditions
The following Coccinelle semantic patch was used to find and correct cases
of assignments in "if" conditions:
@@
expression var, expr;
statement S;
@@
+ var = expr;
if(
- (var = expr)
+ var
) S
Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
commit 656f978f9af9d8d77436e8159f51f7aa1e673309
Author: Quentin Lambert <lambert.quentin@gmail.com>
Date: Sun Sep 7 20:02:47 2014 +0200
PCI: Remove unnecessary curly braces
Remove curly braces in simple "if" cases.
No functional change.
Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
commit e0c524049f8279d00d2fbd4748b03234a2726fdd
Author: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Thu Jul 10 11:30:08 2014 -0400
MAINTAINERS: Add Keystone Multicore Navigator drivers entry
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
commit 88139ed030583557751e279968e13e892ae10825
Author: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Sun Mar 30 17:29:04 2014 -0400
soc: ti: add Keystone Navigator DMA support
The Keystone Navigator DMA driver sets up the dma channels and flows for
the QMSS(Queue Manager SubSystem) who triggers the actual data movements
across clients using destination queues. Every client modules like
NETCP(Network Coprocessor), SRIO(Serial Rapid IO) and CRYPTO
Engines has its own instance of packet dma hardware. QMSS has also
an internal packet DMA module which is used as an infrastructure
DMA with zero copy.
Initially this driver was proposed as DMA engine driver but since the
hardware is not typical DMA engine and hence doesn't comply with typical
DMA engine driver needs, that approach was naked. Link to that
discussion -
https://lkml.org/lkml/2014/3/18/340
As aligned, now we pair the Navigator DMA with its companion Navigator
QMSS subsystem driver.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Olof Johansson <olof@lixom.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sandeep Nair <sandeep_n@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
commit 8172296d8717be1951da4bb4feb2700a60e8cdde
Author: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Sun Mar 30 17:29:04 2014 -0400
Documentation: dt: soc: add Keystone Navigator DMA bindings
The Keystone Navigator DMA driver sets up the dma channels and flows for
the QMSS(Queue Manager SubSystem) who triggers the actual data movements
across clients using destination queues. Every client modules like
NETCP(Network Coprocessor), SRIO(Serial Rapid IO) and CRYPTO
Engines has its own instance of packet dma hardware. QMSS has also
an internal packet DMA module which is used as an infrastructure
DMA with zero copy.
Initially this driver was proposed as DMA engine driver but since the
hardware is not typical DMA engine and hence doesn't comply with typical
DMA engine driver needs, that approach was naked. Link to that
discussion -
https://lkml.org/lkml/2014/3/18/340
As aligned, now we pair the Navigator DMA with its companion Navigator
QMSS subsystem driver.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Olof Johansson <olof@lixom.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sandeep Nair <sandeep_n@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
commit 41f93af900a20d1a0a358b522b5129c89677e9dc
Author: Sandeep Nair <sandeep_n@ti.com>
Date: Fri Feb 28 10:47:50 2014 -0500
soc: ti: add Keystone Navigator QMSS driver
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
the main hardware sub system which forms the backbone of the Keystone
Multi-core Navigator. QMSS consist of queue managers, packed-data structure
processors(PDSP), linking RAM, descriptor pools and infrastructure
Packet DMA.
The Queue Manager is a hardware module that is responsible for accelerating
management of the packet queues. Packets are queued/de-queued by writing or
reading descriptor address to a particular memory mapped location. The PDSPs
perform QMSS related functions like accumulation, QoS, or event management.
Linking RAM registers are used to link the descriptors which are stored in
descriptor RAM. Descriptor RAM is configurable as internal or external memory.
The QMSS driver manages the PDSP setups, linking RAM regions,
queue pool management (allocation, push, pop and notify) and descriptor
pool management. The specifics on the device tree bindings for
QMSS can be found in:
Documentation/devicetree/bindings/soc/keystone-navigator-qmss.txt
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Olof Johansson <olof@lixom.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sandeep Nair <sandeep_n@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
commit a4dfb8c41043dd6c2b9defbe846c44389c4b6f02
Author: Sandeep Nair <sandeep_n@ti.com>
Date: Fri Feb 28 10:47:50 2014 -0500
Documentation: dt: soc: add Keystone Navigator QMSS bindings
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
the main hardware sub system which forms the backbone of the Keystone
Multi-core Navigator. QMSS consist of queue managers, packed-data structure
processors(PDSP), linking RAM, descriptor pools and infrastructure
Packet DMA.
The Queue Manager is a hardware module that is responsible for accelerating
management of the packet queues. Packets are queued/de-queued by writing or
reading descriptor address to a particular memory mapped location. The PDSPs
perform QMSS related functions like accumulation, QoS, or event management.
Linking RAM registers are used to link the descriptors which are stored in
descriptor RAM. Descriptor RAM is configurable as internal or external memory.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Olof Johansson <olof@lixom.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sandeep Nair <sandeep_n@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
commit 382a9c9adc1cd540f5b714b65db315fc1c0b553d
Author: Quentin Lambert <lambert.quentin@gmail.com>
Date: Sun Sep 7 20:02:04 2014 +0200
PCI: Add space before open parenthesis
Add space before open parenthesis as is conventional.
No functional change.
[bhelgaas: fix a few more in ibmphp, shpchp]
Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
commit fe6ce32189136370b3d236d1c32ab812b93cd0d8
Author: Yijing Wang <wangyijing@huawei.com>
Date: Wed Sep 24 11:09:59 2014 +0800
PCI/MSI: Rename __read_msi_msg() to read_msi_msg()
Rename __read_msi_msg() to read_msi_msg().
No functional change.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
commit c2eb2dc3461e522d6452e1f74e36194633d4db0d
Author: Yijing Wang <wangyijing@huawei.com>
Date: Wed Sep 24 11:09:53 2014 +0800
PCI/MSI: Remove unused read_msi_msg()
Now no one uses read_msi_msg(), so remove it.
No functional change.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
commit 11c013fd8afbc7c6b2e15608ed5fc2c249552998
Author: Yijing Wang <wangyijing@huawei.com>
Date: Wed Sep 24 11:09:45 2014 +0800
MSI/powerpc: Use __read_msi_msg() instead of read_msi_msg()
rtas_setup_msi_irqs() already has the struct msi_desc pointer required by
__read_msi_msg(), so call it directly instead of having read_msi_msg() look
it up from the IRQ.
No functional change.
[bhelgaas: changelog]
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: linuxppc-dev@lists.ozlabs.org
commit eeeda4cd06e828b331b15741a204ff9f5874d28d
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Wed Sep 24 13:30:12 2014 +0100
x86/relocs: Make per_cpu_load_addr static
per_cpu_load_addr is only used for 64-bit relocations, but is
declared in both configurations of relocs.c - with different
types. This has undefined behaviour in general. GNU ld is
documented to use the larger size in this case, but other tools
may differ and some warn about this.
References: https://bugs.debian.org/748577
Reported-by: Michael Tautschnig <mt@debian.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: 748577@bugs.debian.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/1411561812.3659.23.camel@decadent.org.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
commit 212be3b2320bcf33eff648bc4e1f0edbf4d90acf
Author: Oleg Nesterov <oleg@redhat.com>
Date: Sun Sep 21 20:42:32 2014 +0200
x86/lib/Makefile: Remove the unnecessary "+= thunk_64.o"
Trivial. We have "lib-y += thunk_$(BITS).o" at the start, no
need to add thunk_64.o if !CONFIG_X86_32.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/20140921184232.GB23727@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
commit 0ad6e3c5199be12c9745da8f8b9e3c9f8066c235
Author: Oleg Nesterov <oleg@redhat.com>
Date: Sun Sep 21 20:41:53 2014 +0200
x86: Speed up ___preempt_schedule*() by using THUNK helpers
___preempt_schedule() does SAVE_ALL/RESTORE_ALL but this is
suboptimal, we do not need to save/restore the callee-saved
register. And we already have arch/x86/lib/thunk_*.S which
implements the similar asm wrappers, so it makes sense to
redefine ___preempt_schedule() as "THUNK ..." and remove
preempt.S altogether.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Andy Lutomirski <luto@amacapital.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/20140921184153.GA23727@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
commit 03bd4e1f7265548832a76e7919a81f3137c44fd1
Author: Wanpeng Li <wanpeng.li@linux.intel.com>
Date: Wed Sep 24 16:38:05 2014 +0800
sched: Fix unreleased llc_shared_mask bit during CPU hotplug
The following bug can be triggered by hot adding and removing a large number of
xen domain0's vcpus repeatedly:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: [..] find_busiest_group
PGD 5a9d5067 PUD 13067 PMD 0
Oops: 0000 [#3] SMP
[...]
Call Trace:
load_balance
? _raw_spin_unlock_irqrestore
idle_balance
__schedule
schedule
schedule_timeout
? lock_timer_base
schedule_timeout_uninterruptible
msleep
lock_device_hotplug_sysfs
online_store
dev_attr_store
sysfs_write_file
vfs_write
SyS_write
system_call_fastpath
Last level cache shared mask is built during CPU up and the
build_sched_domain() routine takes advantage of it to setup
the sched domain CPU topology.
However, llc_shared_mask is not released during CPU disable,
which leads to an invalid sched domainCPU topology.
This patch fix it by releasing the llc_shared_mask correctly
during CPU disable.
Yasuaki also reported that this can happen on real hardware:
https://lkml.org/lkml/2014/7/22/1018
His case is here:
==
Here is an example on my system.
My system has 4 sockets and each socket has 15 cores and HT is
enabled. In this case, each core of sockes is numbered as
follows:
| CPU#
Socket#0 | 0-14 , 60-74
Socket#1 | 15-29, 75-89
Socket#2 | 30-44, 90-104
Socket#3 | 45-59, 105-119
Then llc_shared_mask of CPU#30 has 0x3fff80000001fffc0000000.
It means that last level cache of Socket#2 is shared with
CPU#30-44 and 90-104.
When hot-removing socket#2 and #3, each core of sockets is
numbered as follows:
| CPU#
Socket#0 | 0-14 , 60-74
Socket#1 | 15-29, 75-89
But llc_shared_mask is not cleared. So llc_shared_mask of CPU#30
remains having 0x3fff80000001fffc0000000.
After that, when hot-adding socket#2 and #3, each core of
sockets is numbered as follows:
| CPU#
Socket#0 | 0-14 , 60-74
Socket#1 | 15-29, 75-89
Socket#2 | 30-59
Socket#3 | 90-119
Then llc_shared_mask of CPU#30 becomes
0x3fff8000fffffffc0000000. It means that last level cache of
Socket#2 is shared with CPU#30-59 and 90-104. So the mask has
the wrong value.
Signed-off-by: Wanpeng Li <wanpeng.li@linux.intel.com>
Tested-by: Linn Crosetto <linn@hp.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: <stable@vger.kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Steven Rostedt <srostedt@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1411547885-48165-1-git-send-email-wanpeng.li@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
commit 24832b4de315ad00e5430a53772750dfcf18514d
Author: Minghuan Lian <Minghuan.Lian@freescale.com>
Date: Tue Sep 23 22:28:59 2014 +0800
PCI: designware: Add get_msi_data() to pcie_host_ops
Add a struct pcie_host_ops .get_msi_data() method for platforms to return
their special MSI message data.
Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Mohit KUMAR <mohit.kumar@st.com>
commit ee1b5b165c0a2f04d2107e634e51f05d0eb107de
Author: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Date: Wed Sep 24 00:26:24 2014 +0100
x86/intel/quark: Switch off CR4.PGE so TLB flush uses CR3 instead
Quark x1000 advertises PGE via the standard CPUID method
PGE bits exist in Quark X1000's PTEs. In order to flush
an individual PTE it is necessary to reload CR3 irrespective
of the PTE.PGE bit.
See Quark Core_DevMan_001.pdf section 6.4.11
This bug was fixed in Galileo kernels, unfixed vanilla kernels are expected to
crash and burn on this platform.
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Cc: Borislav Petkov <bp@alien8.de>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/1411514784-14885-1-git-send-email-pure.logic@nexus-software.ie
Signed-off-by: Ingo Molnar <mingo@kernel.org>
commit 450e344e421b9f555261a2d97952d9e71d4cb082
Author: Minghuan Lian <Minghuan.Lian@freescale.com>
Date: Tue Sep 23 22:28:58 2014 +0800
PCI: designware: Rename get_msi_data() to get_msi_addr()
The struct pcie_host_ops .get_msi_data() method returns the MSI message
address. To accurately express its purpose, rename it to .get_msi_addr().
Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Mohit KUMAR <mohit.kumar@st.com>
commit 0c61ea77cceafd1134225099961c2df0866b500f
Author: Minghuan Lian <Minghuan.Lian@fre…
aryabinin
referenced
this pull request
in aryabinin/linux
Oct 3, 2014
GIT 6fe676b243e5a0cb4cc4d9a4b094de8db0cdbf74
commit e500f488c27659bb6f5d313b336621f3daa67701
Author: Fabian Frederick <fabf@skynet.be>
Date: Wed Oct 1 06:52:06 2014 +0200
net/dccp/ccid.c: add __init to ccid_activate
ccid_activate is only called by __init ccid_initialize_builtins in same module.
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 0c5b8a46294d43fc63788839d3c18de0961ec1bc
Author: Fabian Frederick <fabf@skynet.be>
Date: Wed Oct 1 06:48:03 2014 +0200
net/dccp/proto.c: add __init to dccp_mib_init
dccp_mib_init is only called by __init dccp_init in same module.
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 082f58ac4a48d3f5cb4597232cb2ac6823a96f43
Author: Quinn Tran <quinn.tran@qlogic.com>
Date: Thu Sep 25 06:22:28 2014 -0400
target: Fix queue full status NULL pointer for SCF_TRANSPORT_TASK_SENSE
During temporary resource starvation at lower transport layer, command
is placed on queue full retry path, which expose this problem. The TCM
queue full handling of SCF_TRANSPORT_TASK_SENSE currently sends the same
cmd twice to lower layer. The 1st time led to cmd normal free path.
The 2nd time cause Null pointer access.
This regression bug was originally introduced v3.1-rc code in the
following commit:
commit e057f53308a5f071556ee80586b99ee755bf07f5
Author: Christoph Hellwig <hch@infradead.org>
Date: Mon Oct 17 13:56:41 2011 -0400
target: remove the transport_qf_callback se_cmd callback
Signed-off-by: Quinn Tran <quinn.tran@qlogic.com>
Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
Cc: <stable@vger.kernel.org> # v3.1+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
commit db3a99b9921f27fe71ca8c0f218ee810e0e7fb69
Author: Joern Engel <joern@logfs.org>
Date: Tue Sep 16 16:23:19 2014 -0400
qla_target: rearrange struct qla_tgt_prm
On most (non-x86) 64bit platforms this will remove 8 padding bytes
from the structure.
Signed-off-by: Joern Engel <joern@logfs.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
commit f9b6721a9cef94908467abf7a2cacbd15a7d23cb
Author: Joern Engel <joern@logfs.org>
Date: Tue Sep 16 16:23:18 2014 -0400
qla_target: improve qlt_unmap_sg()
Remove the inline attribute. Modern compilers ignore it and the
function has grown beyond where inline made sense anyway.
Remove the BUG_ON(!cmd->sg_mapped), and instead return if sg_mapped is
not set. Every caller is doing this check, so we might as well have it
in one place instead of four.
Signed-off-by: Joern Engel <joern@logfs.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
commit 55a9066fffd2f533e7ed434b072469ef09d6c476
Author: Joern Engel <joern@logfs.org>
Date: Tue Sep 16 16:23:15 2014 -0400
qla_target: make some global functions static
Also removes the declarations from the header - including two
declarations without function definitions or callers.
Signed-off-by: Joern Engel <joern@logfs.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
commit c57010420654aca179c500f61e86315a337244ca
Author: Joern Engel <joern@logfs.org>
Date: Tue Sep 16 16:23:14 2014 -0400
qla_target: remove unused parameter
Signed-off-by: Joern Engel <joern@logfs.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
commit f81ccb489a7a641c1bed41b49cf8d72c199c68d5
Author: Joern Engel <joern@logfs.org>
Date: Tue Sep 16 16:23:13 2014 -0400
target: simplify core_tmr_abort_task
list_for_each_entry_safe is necessary if list objects are deleted from
the list while traversing it. Not the case here, so we can use the base
list_for_each_entry variant.
Signed-off-by: Joern Engel <joern@logfs.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
commit 33940d09937276cd3c81f2874faf43e37c2db0e2
Author: Joern Engel <joern@logfs.org>
Date: Tue Sep 16 16:23:12 2014 -0400
target: encapsulate smp_mb__after_atomic()
The target code has a rather generous helping of smp_mb__after_atomic()
throughout the code base. Most atomic operations were followed by one
and none were preceded by smp_mb__before_atomic(), nor accompanied by a
comment explaining the need for a barrier.
Instead of trying to prove for every case whether or not it is needed,
this patch introduces atomic_inc_mb() and atomic_dec_mb(), which
explicitly include the memory barriers before and after the atomic
operation. For now they are defined in a target header, although they
could be of general use.
Most of the existing atomic/mb combinations were replaced by the new
helpers. In a few cases the atomic was sandwiched in
spin_lock/spin_unlock and I simply removed the barrier.
I suspect that in most cases the correct conversion would have been to
drop the barrier. I also suspect that a few cases exist where a) the
barrier was necessary and b) a second barrier before the atomic would
have been necessary and got added by this patch.
Signed-off-by: Joern Engel <joern@logfs.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
commit 74ed7e62289dc6d388996d7c8f89c2e7e95b9657
Author: Joern Engel <joern@logfs.org>
Date: Tue Sep 16 16:23:11 2014 -0400
target: remove some smp_mb__after_atomic()s
atomic_inc_return() already does an implicit memory barrier and the
second case was moved from an atomic to a plain flag operation. If a
barrier were needed in the second case, it would have to be smp_mb(),
not a variant optimized away for x86 and other architectures.
Signed-off-by: Joern Engel <joern@logfs.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
commit 8f83269048628d7b139dacbfc6cc97befcbdd2e9
Author: Joern Engel <joern@logfs.org>
Date: Tue Sep 16 16:23:10 2014 -0400
target: simplify core_tmr_release_req()
And while at it, do minimal coding style fixes in the area.
Signed-off-by: Joern Engel <joern@logfs.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
commit 9c7d6154bc4b9dfefd580490cdca5f7c72321464
Author: Andy Grover <agrover@redhat.com>
Date: Mon Jun 30 16:39:46 2014 -0700
target: Remove core_tpg_release_virtual_lun0 function
Simple and just called from one place.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andy Grover <agrover@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
commit cd9d7cbaec8b622eee4edcd8bf481c4047f74915
Author: Andy Grover <agrover@redhat.com>
Date: Mon Jun 30 16:39:44 2014 -0700
target: Change core_dev_del_lun to take a se_lun instead of unpacked_lun
Remove core_tpg_pre_dellun entirely, since we don't need to get/check
a pointer we already have.
Nothing else can return an error, so core_dev_del_lun can return void.
Rename core_tpg_post_dellun to remove_lun - a clearer name, now that
pre_dellun is gone.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andy Grover <agrover@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
commit cc83881f2c57caaf4b14adaffa65595640a59661
Author: Andy Grover <agrover@redhat.com>
Date: Mon Jun 30 16:39:43 2014 -0700
target: core_tpg_post_dellun can return void
Nothing in it can raise an error.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andy Grover <agrover@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
commit 49be17235c0acd96f2ff0fe282867fe3a83f554c
Author: hayeswang <hayeswang@realtek.com>
Date: Wed Oct 1 13:25:11 2014 +0800
r8152: disable power cut for RTL8153
The firmware would be clear when the power cut is enabled for
RTL8153.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 204c8704128943bf3f8b605f4b40bdc2b6bd89dc
Author: hayeswang <hayeswang@realtek.com>
Date: Wed Oct 1 13:25:10 2014 +0800
r8152: remove clearing bp
The xxx_clear_bp() is used to halt the firmware. It only necessary
for updating the new firmware. Besides, depend on the version of
the current firmware, it may have problem to halt the firmware
directly. Finally, halt the firmware would let the firmware code
useless, and the bugs which are fixed by the firmware would occur.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit aa55c8e2f7a395dfc9e67fc6637321e19ce9bfe1
Author: Masahiro Yamada <yamada.m@jp.panasonic.com>
Date: Tue Sep 9 20:02:24 2014 +0900
kbuild: handle C=... and M=... after entering into build directory
This commit avoids processing C=... and M=... twice
when O=... is also given.
Besides, we can also remove KBUILD_EXTMOD="$(KBUILD_EXTMOD)"
in the sub-make target.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Peter Foley <pefoley2@pefoley.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
commit 745a254322c898dadf019342cd7140f7867d2d0f
Author: Masahiro Yamada <yamada.m@jp.panasonic.com>
Date: Tue Sep 9 20:02:23 2014 +0900
kbuild: use $(Q) for sub-make target
Since commit 066b7ed9558087a7957a1128f27d7a3462ff117f
(kbuild: Do not print the build directory with make -s),
"Q" is defined above the sub-make target.
This commit takes advantage of that and replaces
"$(if $(KBUILD_VERBOSE:1=),@)" with "$(Q)".
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Peter Foley <pefoley2@pefoley.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
commit 7ff525712acf9325e9acdb27bbc93049ea2e850c
Author: Masahiro Yamada <yamada.m@jp.panasonic.com>
Date: Tue Sep 9 20:02:22 2014 +0900
kbuild: fake the "Entering directory ..." message more simply
Commit c2e28dc975ea87feed84415006ae143424912ac7
(kbuild: Print the name of the build directory)
added a gimmick to show the "Entering directory ...".
Instead of echoing the hard-coded message (that is, we need to know
the exact message), moving --no-print-directory would be easier.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Peter Foley <pefoley2@pefoley.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
commit 1b0ecb28b0cc216535ce6477d39aa610c3ff68a1
Author: Vlad Yasevich <vyasevich@gmail.com>
Date: Tue Sep 30 19:39:37 2014 -0400
bnx2: Correctly receive full sized 802.1ad fragmes
This driver, similar to tg3, has a check that will
cause full sized 802.1ad frames to be dropped. The
frame will be larger then the standard mtu due to the
presense of vlan header that has not been stripped.
The driver should not drop this frame and should process
it just like it does for 802.1q.
CC: Sony Chacko <sony.chacko@qlogic.com>
CC: Dept-HSGLinuxNICDev@qlogic.com
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 7d3083ee36b51e425b6abd76778a2046906b0fd3
Author: Vlad Yasevich <vyasevich@gmail.com>
Date: Tue Sep 30 19:39:36 2014 -0400
tg3: Allow for recieve of full-size 8021AD frames
When receiving a vlan-tagged frame that still contains
a vlan header, the length of the packet will be greater
then MTU+ETH_HLEN since it will account of the extra
vlan header. TG3 checks this for the case for 802.1Q,
but not for 802.1ad. As a result, full sized 802.1ad
frames get dropped by the card.
Add a check for 802.1ad protocol when receving full
sized frames.
Suggested-by: Prashant Sreedharan <prashant@broadcom.com>
CC: Prashant Sreedharan <prashant@broadcom.com>
CC: Michael Chan <mchan@broadcom.com>
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 1e918876853aa85435e0f17fd8b4a92dcfff53d6
Author: Florian Westphal <fw@strlen.de>
Date: Wed Oct 1 13:38:03 2014 +0200
r8169: add support for Byte Queue Limits
tested on RTL8168d/8111d model using 'super_netperf 40' with TCP/UDP_STREAM.
Output of
while true; do
for n in inflight limit; do
echo -n $n\ ; cat $n;
done;
sleep 1;
done
during netperf run, 100mbit peer:
inflight 0
limit 3028
inflight 6056
limit 4542
[ trimmed output for brevity, no limit/inflight changes during
test steady-state ]
limit 4542
inflight 3028
limit 6122
inflight 0
limit 6122
[ changed cable to 1gbit peer, restart netperf ]
inflight 37850
limit 36336
inflight 33308
limit 31794
inflight 33308
limit 31794
inflight 27252
limit 25738
[ again, no changes during test ]
inflight 27252
limit 25738
inflight 0
limit 28766
[ change cable to 100mbit peer, restart netperf ]
limit 28766
inflight 27370
limit 28766
inflight 4542
limit 5990
inflight 6056
limit 4542
[ .. ]
inflight 6056
limit 4542
inflight 0
[end of test]
Cc: Francois Romieu <romieu@fr.zoreil.com>
Cc: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Eric Dumazet <edumazet@google.com>
Acked-by: Tom Herbert <therbert@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit d0bf4a9e92b9a93ffeeacbd7b6cb83e0ee3dc2ef
Author: Eric Dumazet <edumazet@google.com>
Date: Mon Sep 29 13:29:15 2014 -0700
net: cleanup and document skb fclone layout
Lets use a proper structure to clearly document and implement
skb fast clones.
Then, we might experiment more easily alternative layouts.
This patch adds a new skb_fclone_busy() helper, used by tcp and xfrm,
to stop leaking of implementation details.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 0f1ca65ee50df042051e8fa3a14f73b0c71d45b9
Author: Arianna Avanzini <avanzini.arianna@gmail.com>
Date: Fri Aug 22 13:20:02 2014 +0200
xen, blkfront: factor out flush-related checks from do_blkif_request()
This commit factors out some checks related to the request insertion
path, which can be done in an function instead of by itself.
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
commit 61cecca865280bef4f8a9748d0a9afa5df351ac2
Author: Roger Pau Monné <roger.pau@citrix.com>
Date: Mon Sep 15 11:55:27 2014 +0200
xen-blkback: fix leak on grant map error path
Fix leaking a page when a grant mapping has failed.
CC: stable@vger.kernel.org
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reported-and-Tested-by: Tao Chen <boby.chen@huawei.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
commit 12ea729645ace01e08f9654df155622898d3aae6
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: Mon Sep 8 15:21:33 2014 +0200
xen/blkback: unmap all persistent grants when frontend gets disconnected
blkback does not unmap persistent grants when frontend goes to Closed
state (e.g. when blkfront module is being removed). This leads to the
following in guest's dmesg:
[ 343.243825] xen:grant_table: WARNING: g.e. 0x445 still in use!
[ 343.243825] xen:grant_table: WARNING: g.e. 0x42a still in use!
...
When load module -> use device -> unload module sequence is performed multiple times
it is possible to hit BUG() condition in blkfront module:
[ 343.243825] kernel BUG at drivers/block/xen-blkfront.c:954!
[ 343.243825] invalid opcode: 0000 [#1] SMP
[ 343.243825] Modules linked in: xen_blkfront(-) ata_generic pata_acpi [last unloaded: xen_blkfront]
...
[ 343.243825] Call Trace:
[ 343.243825] [<ffffffff814111ef>] ? unregister_xenbus_watch+0x16f/0x1e0
[ 343.243825] [<ffffffffa0016fbf>] blkfront_remove+0x3f/0x140 [xen_blkfront]
...
[ 343.243825] RIP [<ffffffffa0016aae>] blkif_free+0x34e/0x360 [xen_blkfront]
[ 343.243825] RSP <ffff88001eb8fdc0>
We don't need to keep these grants if we're disconnecting as frontend might already
forgot about them. Solve the issue by moving xen_blkbk_free_caches() call from
xen_blkif_free() to xen_blkif_disconnect().
Now we can see the following:
[ 928.590893] xen:grant_table: WARNING: g.e. 0x587 still in use!
[ 928.591861] xen:grant_table: WARNING: g.e. 0x372 still in use!
...
[ 929.592146] xen:grant_table: freeing g.e. 0x587
[ 929.597174] xen:grant_table: freeing g.e. 0x372
...
Backend does not keep persistent grants any more, reconnect works fine.
CC: stable@vger.kernel.org
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
commit b248230c34970a6c1c17c591d63b464e8d2cfc33
Author: Yuchung Cheng <ycheng@google.com>
Date: Mon Sep 29 13:20:38 2014 -0700
tcp: abort orphan sockets stalling on zero window probes
Currently we have two different policies for orphan sockets
that repeatedly stall on zero window ACKs. If a socket gets
a zero window ACK when it is transmitting data, the RTO is
used to probe the window. The socket is aborted after roughly
tcp_orphan_retries() retries (as in tcp_write_timeout()).
But if the socket was idle when it received the zero window ACK,
and later wants to send more data, we use the probe timer to
probe the window. If the receiver always returns zero window ACKs,
icsk_probes keeps getting reset in tcp_ack() and the orphan socket
can stall forever until the system reaches the orphan limit (as
commented in tcp_probe_timer()). This opens up a simple attack
to create lots of hanging orphan sockets to burn the memory
and the CPU, as demonstrated in the recent netdev post "TCP
connection will hang in FIN_WAIT1 after closing if zero window is
advertised." http://www.spinics.net/lists/netdev/msg296539.html
This patch follows the design in RTO-based probe: we abort an orphan
socket stalling on zero window when the probe timer reaches both
the maximum backoff and the maximum RTO. For example, an 100ms RTT
connection will timeout after roughly 153 seconds (0.3 + 0.6 +
.... + 76.8) if the receiver keeps the window shut. If the orphan
socket passes this check, but the system already has too many orphans
(as in tcp_out_of_resources()), we still abort it but we'll also
send an RST packet as the connection may still be active.
In addition, we change TCP_USER_TIMEOUT to cover (life or dead)
sockets stalled on zero-window probes. This changes the semantics
of TCP_USER_TIMEOUT slightly because it previously only applies
when the socket has pending transmission.
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Reported-by: Andrey Dmitrov <andrey.dmitrov@oktetlabs.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 3edfe0030bb7a82dab2a30a29ea6e1800e600c4b
Author: Helge Deller <deller@gmx.de>
Date: Wed Oct 1 22:11:01 2014 +0200
parisc: Fix serial console for machines with serial port on superio chip
Fix the serial console on machines where the serial port is located on
the SuperIO chip.
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: Peter Hurley <peter@hurleysoftware.com>
commit baf378126b08474de2e2428b16e62a69df0339d9
Author: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Wed Oct 1 14:07:39 2014 -0600
rsxx: Remove deprecated IRQF_DISABLED
This removes the use of the IRQF_DISABLED flag
from drivers/block/rsxx/core.c
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Acked-by Philip Kelleher <pjk1939@linux.vnet.ibm.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
commit cb57659a15c6c0576493cc8a10474ce7ffd44eb3
Author: Fabian Frederick <fabf@skynet.be>
Date: Wed Oct 1 19:30:03 2014 +0200
cipso: add __init to cipso_v4_cache_init
cipso_v4_cache_init is only called by __init cipso_v4_init
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 57a02c39c1c20ed03a86f8014c11a8c18b94cac3
Author: Fabian Frederick <fabf@skynet.be>
Date: Wed Oct 1 19:18:57 2014 +0200
inet: frags: add __init to ip4_frags_ctl_register
ip4_frags_ctl_register is only called by __init ipfrag_init
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 47d7a88c188f06ffaea3a539f84fe10cb4e77787
Author: Fabian Frederick <fabf@skynet.be>
Date: Wed Oct 1 18:27:50 2014 +0200
tcp: add __init to tcp_init_mem
tcp_init_mem is only called by __init tcp_init.
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit ee7a1beb9759c94aea67dd887faf5e447a5c6710
Author: Chun-Hao Lin <hau@realtek.com>
Date: Wed Oct 1 23:17:21 2014 +0800
r8169:call "rtl8168_driver_start" "rtl8168_driver_stop" only when hardware dash function is enabled
These two functions are used to inform dash firmware that driver is been
brought up or brought down. So call these two functions only when hardware dash
function is enabled.
Signed-off-by: Chun-Hao Lin <hau@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 2a9b4d9670e71784896d95c41c9b0acd50db1dbb
Author: Chun-Hao Lin <hau@realtek.com>
Date: Wed Oct 1 23:17:20 2014 +0800
r8169:modify the behavior of function "rtl8168_oob_notify"
In function "rtl8168_oob_notify", using function "rtl_eri_write" to access
eri register 0xe8, instead of using MAC register "ERIDR" and "ERIAR" to
access it.
For using function "rtl_eri_write" in function "rtl8168_oob_notify", need to
move down "rtl8168_oob_notify" related functions under the function
"rtl_eri_write".
Signed-off-by: Chun-Hao Lin <hau@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 2f8c040ce6791ef0477e6d59768ee3d5fd0df0fd
Author: Chun-Hao Lin <hau@realtek.com>
Date: Wed Oct 1 23:17:19 2014 +0800
r8169:change the name of function "r8168dp_check_dash" to "r8168_check_dash"
DASH function not only RTL8168DP can support, but also RTL8168EP.
So change the name of function "r8168dp_check_dash" to "r8168_check_dash".
Signed-off-by: Chun-Hao Lin <hau@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 706123d06c18b55da5e9da21e2d138ee789bf8f4
Author: Chun-Hao Lin <hau@realtek.com>
Date: Wed Oct 1 23:17:18 2014 +0800
r8169:change the name of function"rtl_w1w0_eri"
Change the name of function "rtl_w1w0_eri" to "rtl_w0w1_eri".
In this function, the local variable "val" is "write zeros then write ones".
Please see below code.
(val & ~m) | p
In this patch, change the function name from "xx_w1w0_xx" to "xx_w0w1_xx".
The changed function name is more suitable for it's behavior.
Signed-off-by: Chun-Hao Lin <hau@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 7656442824f6174b56a19c664fe560972df56ad4
Author: Chun-Hao Lin <hau@realtek.com>
Date: Wed Oct 1 23:17:17 2014 +0800
r8169:for function "rtl_w1w0_phy" change its name and behavior
Change function name from "rtl_w1w0_phy" to "rtl_w0w1_phy".
And its behavior from "write ones then write zeros" to
"write zeros then write ones".
In Realtek internal driver, bitwise operations are almost "write zeros then
write ones". For easy to port hardware parameters from Realtek internal driver
to Linux kernal driver "r8169", we would like to change this function's
behavior and its name.
Signed-off-by: Chun-Hao Lin <hau@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit ac85bcdbc0ffd3903d6db4abcd769ecacf98605b
Author: Chun-Hao Lin <hau@realtek.com>
Date: Wed Oct 1 23:17:16 2014 +0800
r8169:add more chips to support magic packet v2
For RTL8168F RTL8168FB RTL8168G RTL8168GU RTL8411 RTL8411B RTL8402 RTL8107E,
the magic packet enable bit is changed to eri 0xde bit0.
In this patch, change magic packet enable bit of these chips to eri 0xde bit0.
Signed-off-by: Chun-Hao Lin <hau@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 89cceb2729c752e6ff9b3bc8650a70f29884f116
Author: Chun-Hao Lin <hau@realtek.com>
Date: Wed Oct 1 23:17:15 2014 +0800
r8169:add support more chips to get mac address from backup mac address register
RTL8168FB RTL8168G RTL8168GU RTL8411 RTL8411B RTL8106EUS RTL8402 can
support get mac address from backup mac address register.
Signed-off-by: Chun-Hao Lin <hau@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 42fde7371035144037844f41bd16950de9912bdb
Author: Chun-Hao Lin <hau@realtek.com>
Date: Wed Oct 1 23:17:14 2014 +0800
r8169:add disable/enable RTL8411B pll function
RTL8411B can support disable/enable pll function.
Signed-off-by: Chun-Hao Lin <hau@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit b8e5e6ad7115befef13a4493f1d2b8e438abc058
Author: Chun-Hao Lin <hau@realtek.com>
Date: Wed Oct 1 23:17:13 2014 +0800
r8169:add disable/enable RTL8168G pll function
RTL8168G also can disable/enable pll function.
Signed-off-by: Chun-Hao Lin <hau@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 05b9687bb3606190304f08c2e4cd63de8717e30b
Author: Chun-Hao Lin <hau@realtek.com>
Date: Wed Oct 1 23:17:12 2014 +0800
r8169:change uppercase number to lowercase number
Signed-off-by: Chun-Hao Lin <hau@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit a29c9c43bb633a9965909cd548879fee4aa789a4
Author: David L Stevens <david.stevens@oracle.com>
Date: Wed Oct 1 11:05:27 2014 -0400
sunvnet: fix potential NULL pointer dereference
One of the error cases for vnet_start_xmit()'s "out_dropped" label
is port == NULL, so only mess with port->clean_timer when port is not NULL.
Signed-off-by: David L Stevens <david.stevens@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit e506d405ac7d34d03996c97ac68aa2ac010be64a
Author: Thierry Reding <treding@nvidia.com>
Date: Wed Oct 1 13:59:00 2014 +0200
net: dsa: Fix build warning for !PM_SLEEP
The dsa_switch_suspend() and dsa_switch_resume() functions are only used
when PM_SLEEP is enabled, so they need #ifdef CONFIG_PM_SLEEP protection
to avoid a compiler warning.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 84ac1f2ca41f5888cc995944c073a5220f3ed549
Author: Tanmay Inamdar <tinamdar@apm.com>
Date: Fri Sep 26 14:08:25 2014 -0700
arm64: dts: Add APM X-Gene PCIe device tree nodes
Add the device tree nodes for APM X-Gene PCIe host controller and PCIe
clock interface. Since X-Gene SOC supports maximum 5 ports, 5 dts nodes
are added.
Signed-off-by: Tanmay Inamdar <tinamdar@apm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
commit 2896e4418b17363f211e084471b589e3c06a7248
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Wed Oct 1 13:01:35 2014 -0600
PCI: xgene: Add APM X-Gene PCIe driver
Add the AppliedMicro X-Gene SOC PCIe host controller driver. The X-Gene
PCIe controller supports up to 8 lanes and GEN3 speed. The X-Gene SOC
supports up to 5 PCIe ports.
[bhelgaas: folded in MAINTAINERS and bindings updates]
Tested-by: Ming Lei <ming.lei@canonical.com>
Tested-by: Dann Frazier <dann.frazier@canonical.com>
Signed-off-by: Tanmay Inamdar <tinamdar@apm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Liviu Dudau <Liviu.Dudau@arm.com> (driver)
commit 3c87dcbfb36ce6d3d9087f0163c02ba5690d9a85
Author: Subbaraya Sundeep Bhatta <subbaraya.sundeep.bhatta@xilinx.com>
Date: Wed Oct 1 11:01:17 2014 +0200
net: ll_temac: Remove unnecessary ether_setup after alloc_etherdev
Calling ether_setup is redundant since alloc_etherdev calls it.
Signed-off-by: Subbaraya Sundeep Bhatta <sbhatta@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 8493ecca74a7b4a66e19676de1a0f14194179941
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date: Wed Oct 1 11:59:47 2014 -0400
HID: uHID: fix excepted report type
When uhid_get_report() or uhid_set_report() are called, they emit on the
char device a UHID_GET_REPORT or UHID_SET_REPORT message. Then, the
protocol says that the user space asnwers with UHID_GET_REPORT_REPLY
or UHID_SET_REPORT_REPLY.
Unfortunatelly, the current code waits for an event of type UHID_GET_REPORT
or UHID_SET_REPORT instead of the reply one.
Add 1 to UHID_GET_REPORT or UHID_SET_REPORT to actually wait for the
reply, and validate the reply.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
commit c8df6ac9452e8f47a6f660993c526d13e858a6f3
Author: Lucas Stach <l.stach@pengutronix.de>
Date: Tue Sep 30 18:36:27 2014 +0200
PCI: designware: Remove open-coded bitmap operations
Replace them by using the standard kernel bitmap ops. No functional
change, but makes the code a lot cleaner.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Pratyush Anand <pratyush.anand@st.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
commit 2199f0608864cf4e8c93d37842a5ee50c8d79843
Author: Mikulas Patocka <mpatocka@redhat.com>
Date: Fri Mar 28 15:51:56 2014 -0400
dm crypt: sort writes
Write requests are sorted in a red-black tree structure and are
submitted in the sorted order.
In theory the sorting should be performed by the underlying disk
scheduler, however, in practice the disk scheduler only accepts and
sorts a finite number of requests. To allow the sorting of all
requests, dm-crypt needs to implement its own own sorting.
The overhead associated with rbtree-based sorting is considered
negligible so it is not used conditionally. Even on SSD sorting can be
beneficial since in-order request dispatch promotes lower latency IO
completion to the upper layers.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
commit 648fee35be4c75667aa18bf513f7e7e65c01640b
Author: Mikulas Patocka <mpatocka@redhat.com>
Date: Fri Mar 28 15:51:56 2014 -0400
dm crypt: offload writes to thread
Submitting write bios directly in the encryption thread caused serious
performance degradation. On a multiprocessor machine, encryption requests
finish in a different order than they were submitted. Consequently, write
requests would be submitted in a different order and it could cause severe
performance degradation.
Move the submission of write requests to a separate thread so that the
requests can be sorted before submitting. But this commit improves
dm-crypt performance even without having dm-crypt perform request
sorting (in particular it enables IO schedulers like CFQ to sort more
effectively).
Note: it is required that a previous commit ("dm crypt: don't allocate
pages for a partial request") be applied before applying this patch.
Otherwise, this commit could introduce a crash.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
commit 4a0d7e0464226eee625a5b77484c339334453882
Author: Mikulas Patocka <mpatocka@redhat.com>
Date: Fri Mar 28 15:51:55 2014 -0400
dm crypt: use unbound workqueue for request processing
Use unbound workqueue so that work is automatically balanced between
available CPUs.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
commit 72bfc40ca3b393cb0bc6b5e2ce364e6c6ce0f390
Author: Mikulas Patocka <mpatocka@redhat.com>
Date: Thu May 29 14:18:12 2014 -0400
dm crypt: remove io_pending refcount member from dm_crypt_io
Commit "dm crypt: don't allocate pages for a partial request" changed
the code to allocate all pages for one request. There is always just
one pending request, so the io_pending refcount may be removed.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
commit 42196fec8945cc84c032b7f59deaffee82036245
Author: Mikulas Patocka <mpatocka@redhat.com>
Date: Fri Mar 28 15:51:56 2014 -0400
dm crypt: remove unused io_pool and _crypt_io_pool
The previous commits ("dm crypt: use per-bio data") and ("dm crypt:
don't allocate pages for a partial request") stopped using the
io_pool slab mempool and backing _crypt_io_pool kmem cache.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
commit ebfda24b1e1bf483accdb900f8625151d8f01383
Author: Mikulas Patocka <mpatocka@redhat.com>
Date: Fri Mar 28 15:51:56 2014 -0400
dm crypt: avoid deadlock in mempools
Fix a theoretical deadlock introduced in the previous commit ("dm crypt:
don't allocate pages for a partial request").
The function crypt_alloc_buffer may be called concurrently. If we allocate
from the mempool concurrently, there is a possibility of deadlock. For
example, if we have mempool of 256 pages, two processes, each wanting
256, pages allocate from the mempool concurrently, it may deadlock in a
situation where both processes have allocated 128 pages and the mempool
is exhausted.
In order to avoid such a scenario, we allocate the pages under a mutex.
In order to not degrade performance with excessive locking, we try
non-blocking allocations without a mutex first and if it fails, we
fallback to a blocking allocation with a mutex.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
commit b9ea7cb3fb237078be400522880932008c630fb7
Author: Mikulas Patocka <mpatocka@redhat.com>
Date: Fri Mar 28 15:51:56 2014 -0400
dm crypt: don't allocate pages for a partial request
Change crypt_alloc_buffer so that it only ever allocates pages for a
full request.
This change is a prerequisite for the commit "dm crypt: offload writes
to thread". Which implies this change is effectively required for the
upcoming cpu parallelization changes.
But this change simplifies the dm-crypt code at the expense of reduced
throughput in low memory conditions (where allocation for a partial
request is most useful).
This change also enables the removal of the io_pending refcount.
Note: the next commit ("dm-crypt: avoid deadlock in mempools") is needed
to fix a theoretical deadlock.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
commit 117cd3e12232afea97dd31489fbde8888ad22b3e
Author: Heinz Mauelshagen <heinzm@redhat.com>
Date: Wed Sep 24 17:47:19 2014 +0200
dm raid: add discard support for RAID levels 4, 5 and 6
In case of RAID levels 4, 5 and 6 we have to verify each RAID members'
ability to zero data on discards to avoid stripe data corruption -- if
discard_zeroes_data is not set for each RAID member discard support must
be disabled.
Also add an 'ignore_discard' table argument to the target in order to
ignore discard processing completely on a RAID array, hence not passing
down discards to MD personalities.
This 'ignore_discard' control provides the ability to:
- prohibit discards in case of _potential_ data corruptions in RAID4/5/6
(e.g. if ability to zero data on discard is flawed in a RAID member)
- avoid discard processing overhead
Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
commit 04c308f43a90a9b3b84c344b324d6af29288da05
Author: Mikulas Patocka <mpatocka@redhat.com>
Date: Wed Oct 1 13:29:48 2014 -0400
dm bufio: when done scanning return from __scan immediately
When __scan frees the required number of buffer entries that the
shrinker requested (nr_to_scan becomes zero) it must return. Before
this fix the __scan code exited only the inner loop and continued in the
outer loop.
Also, move dm_bufio_cond_resched to __scan's inner loop, so that
iterating the bufio client's lru lists doesn't result in scheduling
latency.
Reported-by: Joe Thornber <thornber@redhat.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org # 3.2+
commit 5ec094057c7df5ff80f5e7fe282f47ad205fb976
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Tue Sep 23 14:38:28 2014 -0600
PCI/MSI: Remove unnecessary temporary variable
The only use of "status" is to hold a value which is immediately returned,
so just return and remove the variable directly.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
commit 56b72b40957947f7c08771f030102351d4c906df
Author: Yijing Wang <wangyijing@huawei.com>
Date: Mon Sep 29 18:35:16 2014 -0600
PCI/MSI: Use __write_msi_msg() instead of write_msi_msg()
default_restore_msi_irq() already has the struct msi_desc pointer required
by __write_msi_msg(), so call it directly instead of having write_msi_msg()
look it up from the IRQ.
No functional change.
[bhelgaas: split into separate patch]
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
commit 1e8f4cc82eded0c3c97ef6e2f119782e42deda35
Author: Yijing Wang <wangyijing@huawei.com>
Date: Wed Sep 24 11:09:45 2014 +0800
MSI/powerpc: Use __read_msi_msg() instead of read_msi_msg()
rtas_setup_msi_irqs() already has the struct msi_desc pointer required by
__read_msi_msg(), so call it directly instead of having read_msi_msg() look
it up from the IRQ.
No functional change.
[bhelgaas: changelog]
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: linuxppc-dev@lists.ozlabs.org
commit 2b260085e466c345e78f23b1c9ad1d123d509ef8
Author: Yijing Wang <wangyijing@huawei.com>
Date: Tue Sep 23 13:27:25 2014 +0800
PCI/MSI: Use __get_cached_msi_msg() instead of get_cached_msi_msg()
Both callers of get_cached_msi_msg() start with a struct irq_data pointer,
look up the corresponding IRQ number, and pass it to get_cached_msi_msg(),
which then uses irq_get_irq_data() to look up the struct irq_data again to
call __get_cached_msi_msg().
Since we already have the struct irq_data, call __get_cached_msi_msg()
directly and skip the lookup work done by get_cached_msi_msg().
No functional change.
[bhelgaas: changelog]
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Tony Luck <tony.luck@intel.com>
CC: linux-ia64@vger.kernel.org
commit 468ff15a3ab98ed7153c29c68229ffb97f15a251
Author: Yijing Wang <wangyijing@huawei.com>
Date: Tue Sep 23 13:27:24 2014 +0800
PCI/MSI: Add "msi_bus" sysfs MSI/MSI-X control for endpoints
The "msi_bus" sysfs file for bridges sets a bus flag to allow or disallow
future driver requests for MSI or MSI-X. Previously, the sysfs file
existed for endpoints but did nothing.
Add "msi_bus" support for endpoints, so an administrator can prevent the
use of MSI and MSI-X for individual devices.
Note that as for bridges, these changes only affect future driver requests
for MSI or MSI-X, so drivers may need to be reloaded.
Add documentation for the "msi_bus" sysfs file.
[bhelgaas: changelog, comments, add "subordinate", add endpoint printk,
rework bus_flags setting, make bus_flags printk unconditional]
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
commit 48c3c38f003c25d50a09d3da558667c5ecd530aa
Author: Yijing Wang <wangyijing@huawei.com>
Date: Tue Sep 23 11:02:42 2014 -0600
PCI/MSI: Remove "pos" from the struct msi_desc msi_attrib
"msi_attrib.pos" is only used for MSI (not MSI-X), and we already cache the
MSI capability offset in "dev->msi_cap".
Remove "pos" from the struct msi_attrib and use "dev->msi_cap" directly.
[bhelgaas: changelog, fix whitespace]
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
commit 81052769e48609525c452d8f078a5786b673e178
Author: Yijing Wang <wangyijing@huawei.com>
Date: Tue Sep 23 13:27:22 2014 +0800
PCI/MSI: Remove unused kobject from struct msi_desc
After commit 1c51b50c2995 ("PCI/MSI: Export MSI mode using attributes, not
kobjects"), the kobject in struct msi_desc is unused.
Remove the unused struct kobject from struct msi_desc.
[bhelgaas: changelog]
Fixes: 1c51b50c2995 ("PCI/MSI: Export MSI mode using attributes, not kobjects")
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a06cd74cefe754341f747ddc4cf7b0058fa9bff8
Author: Alexander Gordeev <agordeev@redhat.com>
Date: Tue Sep 23 12:45:58 2014 -0600
PCI/MSI: Rename pci_msi_check_device() to pci_msi_supported()
Rename pci_msi_check_device() to pci_msi_supported() for clarity. Note
that pci_msi_supported() returns true if MSI/MSI-X is supported, so code
like:
if (pci_msi_supported(...))
reads naturally.
[bhelgaas: changelog, split to separate patch, reverse sense]
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
commit 27e20603c54ba633ed259284d006275f13c9f95b
Author: Alexander Gordeev <agordeev@redhat.com>
Date: Tue Sep 23 14:25:11 2014 -0600
PCI/MSI: Move D0 check into pci_msi_check_device()
Both callers of pci_msi_check_device() check that the device is in D0
state, so move the check from the callers into pci_msi_check_device()
itself.
In pci_enable_msi_range(), note that pci_msi_check_device() never returns a
positive value any more, so the loop that called it until it returns zero
or negative is no longer necessary.
[bhelgaas: changelog, split to separate patch]
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
commit ad975ebad4c3ce8dcc7d0bb4db26ea5aca4cfc99
Author: Alexander Gordeev <agordeev@redhat.com>
Date: Tue Sep 23 12:39:54 2014 -0600
PCI/MSI: Remove arch_msi_check_device()
No architectures implement arch_msi_check_device() or the struct msi_chip
.check_device() method, so remove them.
Remove the "type" parameter to pci_msi_check_device() because it was only
used to call arch_msi_check_device() and is no longer needed.
[bhelgaas: changelog, split to separate patch]
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
commit 3930115e0dd67f61b3b1882c7a34d0baeff1bb4c
Author: Alexander Gordeev <agordeev@redhat.com>
Date: Sun Sep 7 20:57:54 2014 +0200
irqchip: armada-370-xp: Remove arch_msi_check_device()
Move MSI checks from arch_msi_check_device() to arch_setup_msi_irqs().
This makes the code more compact and allows removing
arch_msi_check_device() from generic MSI code.
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
CC: Thomas Gleixner <tglx@linutronix.de>
commit 6b2fd7efeb888fa781c1f767de6c36497ac1596b
Author: Alexander Gordeev <agordeev@redhat.com>
Date: Sun Sep 7 20:57:53 2014 +0200
PCI/MSI/PPC: Remove arch_msi_check_device()
Move MSI checks from arch_msi_check_device() to arch_setup_msi_irqs().
This makes the code more compact and allows removing
arch_msi_check_device() from generic MSI code.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
commit 977104ece1568f2e2ad3f5fd8e55bd640e8ab55a
Author: Mark Charlebois <charlebm@gmail.com>
Date: Thu Sep 4 14:16:17 2014 -0700
arm: LLVMLinux: Use global stack register variable for percpu
Using global current_stack_pointer works on both clang and gcc.
current_stack_pointer is an unsigned long and needs to be cast
as a pointer to dereference.
KernelVersion: 3.17.0-rc6
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
Signed-off-by: Behan Webster <behanw@converseincode.com>
commit a35dc594542b29935cd3a92e53233ad4ba4e622f
Author: Behan Webster <behanw@converseincode.com>
Date: Tue Sep 3 22:27:27 2013 -0400
arm: LLVMLinux: Use current_stack_pointer in unwind_backtrace
Use the global current_stack_pointer to get the value of the stack pointer.
This change supports being able to compile the kernel with both gcc and clang.
KernelVersion: 3.17.0-rc6
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
commit 5c5da6724d8e1767405a3f4b611451a11ece99e2
Author: Behan Webster <behanw@converseincode.com>
Date: Tue Sep 3 22:27:27 2013 -0400
arm: LLVMLinux: Calculate current_thread_info from current_stack_pointer
Use the global current_stack_pointer to get the value of the stack pointer.
This change supports being able to compile the kernel with both gcc and clang.
KernelVersion: 3.17.0-rc6
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
commit f2b6d8c6c56c9a164a2d885ba34a09d613c959c9
Author: Behan Webster <behanw@converseincode.com>
Date: Tue Sep 3 22:27:27 2013 -0400
arm: LLVMLinux: Use current_stack_pointer in save_stack_trace_tsk
Use the global current_stack_pointer to get the value of the stack pointer.
This change supports being able to compile the kernel with both gcc and clang.
KernelVersion: 3.17.0-rc6
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
commit 40802b84566a3d9731a8fea43b144301d9ac450d
Author: Behan Webster <behanw@converseincode.com>
Date: Tue Sep 3 22:27:27 2013 -0400
arm: LLVMLinux: Use current_stack_pointer for return_address
Use the global current_stack_pointer to get the value of the stack pointer.
This change supports being able to compile the kernel with both gcc and Clang.
KernelVersion: 3.17.0-rc6
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
commit d80ced5236764b8c4ffda5545d5b357cf88c77c1
Author: Behan Webster <behanw@converseincode.com>
Date: Tue Sep 3 22:27:27 2013 -0400
arm: LLVMLinux: Use current_stack_pointer to calculate pt_regs address
Use the global current_stack_pointer to calculate the end of the stack for
current_pt_regs()
KernelVersion: 3.17.0-rc6
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
commit 9d0d6994806b36891453beb1e94b6253f853af61
Author: Behan Webster <behanw@converseincode.com>
Date: Tue Sep 3 22:27:26 2013 -0400
arm: LLVMLinux: Add global named register current_stack_pointer for ARM
Define a global named register for current_stack_pointer. The use of this new
variable guarantees that both gcc and clang can access this register in C code.
KernelVersion: 3.17.0-rc6
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
commit 2c804d0f8fc7799981d9fdd8c88653541b28c1a7
Author: Eric Dumazet <edumazet@google.com>
Date: Tue Sep 30 22:12:05 2014 -0700
ipv4: mentions skb_gro_postpull_rcsum() in inet_gro_receive()
Proper CHECKSUM_COMPLETE support needs to adjust skb->csum
when we remove one header. Its done using skb_gro_postpull_rcsum()
In the case of IPv4, we know that the adjustment is not really needed,
because the checksum over IPv4 header is 0. Lets add a comment to
ease code comprehension and avoid copy/paste errors.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit eb51bbaf8dedf142a54a7ff58514a29b40d515bb
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed Oct 1 17:00:49 2014 +1000
fm10k: using vmalloc requires including linux/vmalloc.h
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 078efae00ffc76381c3248006e9cf0988163488f
Author: Anish Bhatt <anish@chelsio.com>
Date: Mon Sep 15 17:44:18 2014 -0700
[SCSI] cxgb4i: avoid holding mutex in interrupt context
cxgbi_inet6addr_handler() can be called in interrupt context, so use rcu
protected list while finding netdev. This is observed as a scheduling in
atomic oops when running over ipv6.
Fixes: fc8d0590d914 ("libcxgbi: Add ipv6 api to driver")
Fixes: 759a0cc5a3e1 ("cxgb4i: Add ipv6 code to driver, call into libcxgbi ipv6 api")
Signed-off-by: Anish Bhatt <anish@chelsio.com>
Signed-off-by: Karen Xie <kxie@chelsio.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
commit 34549ab09e62db9703811c6ed4715f2ffa1fd7fb
Author: Jeff Layton <jlayton@primarydata.com>
Date: Wed Oct 1 08:05:22 2014 -0400
nfsd: eliminate "to_delegation" define
We now have cb_to_delegation and to_delegation, which do the same thing
and are defined separately in different .c files. Move the
cb_to_delegation definition into a header file and eliminate the
redundant to_delegation definition.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jeff Layton <jlayton@primarydata.com>
commit 4a0efdc933680d908de11712a774a2c9492c3d5a
Author: Hannes Reinecke <hare@suse.de>
Date: Wed Oct 1 14:32:31 2014 +0200
block: misplaced rq_complete tracepoint
The rq_complete tracepoint was never issued for empty requests,
causing the resulting blktrace information to never show any
completion for those request.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jens Axboe <axboe@fb.com>
commit fc2021fb9baf9ed375c8161b40b68e120e75c60e
Author: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Wed Oct 1 12:07:07 2014 +0200
block: hd: remove deprecated IRQF_DISABLED
This patch removes the use of the IRQF_DISABLED flag
from drivers/block/hd.c
It's a NOOP since 2.6.35 and it will be removed one day.
This also removes a related comment which is obsolete too.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
commit 19aeb5a65f1a6504fc665466c188241e7393d66f
Author: Bob Peterson <rpeterso@redhat.com>
Date: Mon Sep 29 08:52:04 2014 -0400
GFS2: Make rename not save dirent location
This patch fixes a regression in the patch "GFS2: Remember directory
insert point", commit 2b47dad866d04f14c328f888ba5406057b8c7d33.
The problem had to do with the rename function: The function found
space for the new dirent, and remembered that location. But then the
old dirent was removed, which often moved the eligible location for
the renamed dirent. Putting the new dirent at the saved location
caused file system corruption.
This patch adds a new "save_loc" variable to struct gfs2_diradd.
If 1, the dirent location is saved. If 0, the dirent location is not
saved and the buffer_head is released as per previous behavior.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
commit 5235166fbc332c8b5dcf49e3a498a8b510a77449
Author: Oliver Neukum <oneukum@suse.de>
Date: Tue Sep 30 12:54:56 2014 +0200
HID: usbhid: add another mouse that needs QUIRK_ALWAYS_POLL
There is a second mouse sharing the same vendor strings but different IDs.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
commit 2013add4ce73c93ae2148969a9ec3ecc8b1e26fa
Author: Gavin Shan <gwshan@linux.vnet.ibm.com>
Date: Wed Oct 1 14:34:51 2014 +1000
powerpc/eeh: Show hex prefix for PE state sysfs
As Michael suggested, the hex prefix for the output of EEH PE
state sysfs entry (/sys/bus/pci/devices/xxx/eeh_pe_state) is
always informative to users.
Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
commit 24c20f10583647e30afe87b6f6d5e14bc7b1cbc6
Author: Christoph Hellwig <hch@lst.de>
Date: Tue Sep 30 16:43:46 2014 +0200
scsi: add a CONFIG_SCSI_MQ_DEFAULT option
Add a Kconfig option to enable the blk-mq path for SCSI by default
to ease testing and deployment in setups that know they benefit
from blk-mq.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Robert Elliott <elliott@hp.com>
Tested-by: Robert Elliott <elliott@hp.com>
commit e785060ea3a1c8e37a8bc1449c79e36bff2b5b13
Author: Dolev Raviv <draviv@codeaurora.org>
Date: Thu Sep 25 15:32:36 2014 +0300
ufs: definitions for phy interface
- Adding some of the definitions missing in unipro.h, including power
enumeration.
- Read Modify Write Line helper function
- Indication for the type of suspend
Signed-off-by: Dolev Raviv <draviv@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
commit 374a246e4ebda1fc55d537877bf2412e511ecc7b
Author: Subhash Jadavani <subhashj@codeaurora.org>
Date: Thu Sep 25 15:32:35 2014 +0300
ufs: tune bkops while power managment events
Add capability to control the auto bkops during suspend.
If host explicitly enables the auto bkops (background operation) on device
then only device would perform the bkops on its own. If auto bkops is not
enabled explicitly and if the device reaches to state where it must do
background operation, device would raise the urgent bkops exception event
to host and then host will enable the auto bkops on device. This patch
adds the option to choose whether auto bkops should be enabled during
runtime suspend or not. Since we don't want to keep the device active to
perform the non critical bkops, host will enable urgent bkops only.
Keep auto-bkops enabled after resume if urgent bkops needed.
If device bkops status shows that its in critical need of executing
background operations, host should allow the device to continue doing
background operations.
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Dolev Raviv <draviv@codeaurora.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
commit 856b348305c98d4e0c8e5eafa97c61443197f8d3
Author: Sahitya Tummala <stummala@codeaurora.org>
Date: Thu Sep 25 15:32:34 2014 +0300
ufs: Add support for clock scaling using devfreq framework
The clocks for UFS device will be managed by generic DVFS (Dynamic
Voltage and Frequency Scaling) framework within kernel. This devfreq
framework works with different governors to scale the clocks. By default,
UFS devices uses simple_ondemand governor which scales the clocks up if
the load is more than upthreshold and scales down if the load is less than
downthreshold.
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Dolev Raviv <draviv@codeaurora.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
commit 4cff6d991e4a291cf50fe2659da2ea9ad46620bf
Author: Sahitya Tummala <stummala@codeaurora.org>
Date: Thu Sep 25 15:32:33 2014 +0300
ufs: Add freq-table-hz property for UFS device
Add freq-table-hz propery for UFS device to keep track of
<min max> frequencies supported by UFS clocks.
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Dolev Raviv <draviv@codeaurora.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
commit 1ab27c9cf8b63dd8dec9e17b5c17721c7f3b6cc7
Author: Sahitya Tummala <stummala@codeaurora.org>
Date: Thu Sep 25 15:32:32 2014 +0300
ufs: Add support for clock gating
The UFS controller clocks can be gated after certain period of
inactivity, which is typically less than runtime suspend timeout.
In addition to clocks the link will also be put into Hibern8 mode
to save more power.
The clock gating can be turned on by enabling the capability
UFSHCD_CAP_CLK_GATING. To enable entering into Hibern8 mode as part of
clock gating, set the capability UFSHCD_CAP_HIBERN8_WITH_CLK_GATING.
The tracing events for clock gating can be enabled through debugfs as:
echo 1 > /sys/kernel/debug/tracing/events/ufs/ufshcd_clk_gating/enable
cat /sys/kernel/debug/tracing/trace_pipe
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Dolev Raviv <draviv@codeaurora.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
commit 7eb584db73bebbc9852a14341431ed6935419bec
Author: Dolev Raviv <draviv@codeaurora.org>
Date: Thu Sep 25 15:32:31 2014 +0300
ufs: refactor configuring power mode
Sometimes, the device shall report its maximum power and speed
capabilities, but we might not wish to configure it to use those
maximum capabilities.
This change adds support for the vendor specific host driver to
implement power change notify callback.
To enable configuring different power modes (number of lanes,
gear number and fast/slow modes) it is necessary to split the
configuration stage from the stage that reads the device max power mode.
In addition, it is not required to read the configuration more than
once, thus the configuration is stored after reading it once.
Signed-off-by: Dolev Raviv <draviv@codeaurora.org>
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
commit 57d104c153d3d6d7bea60089e80f37501851ed2c
Author: Subhash Jadavani <subhashj@codeaurora.org>
Date: Thu Sep 25 15:32:30 2014 +0300
ufs: add UFS power management support
This patch adds support for UFS device and UniPro link power management
during runtime/system PM.
Main idea is to define multiple UFS low power levels based on UFS device
and UFS link power states. This would allow any specific platform or pci
driver to choose the best suited low power level during runtime and
system suspend based on their power goals.
bkops handlig:
To put the UFS device in sleep state when bkops is disabled, first query
the bkops status from the device and enable bkops on device only if
device needs time to perform the bkops.
START_STOP handling:
Before sending START_STOP_UNIT to the device well-known logical unit
(w-lun) to make sure that the device w-lun unit attention condition is
cleared.
Write protection:
UFS device specification allows LUs to be write protected, either
permanently or power on write protected. If any LU is power on write
protected and if the card is power cycled (by powering off VCCQ and/or
VCC rails), LU's write protect status would be lost. So this means those
LUs can be written now. To ensures that UFS device is power cycled only
if the power on protect is not set for any of the LUs, check if power on
write protect is set and if device is in sleep/power-off state & link in
inactive state (Hibern8 or OFF state).
If none of the Logical Units on UFS device is power on write protected
then all UFS device power rails (VCC, VCCQ & VCCQ2) can be turned off if
UFS device is in power-off state and UFS link is in OFF state. But current
implementation would disable all device power rails even if UFS link is
not in OFF state.
Low power mode:
If UFS link is in OFF state then UFS host controller can be power collapsed
to avoid leakage current from it. Note that if UFS host controller is power
collapsed, full UFS reinitialization will be required on resume to
re-establish the link between host and device.
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Dolev Raviv <draviv@codeaurora.org>
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
commit 0ce147d48a3e3352859f0c185e98e8392bee7a25
Author: Subhash Jadavani <subhashj@codeaurora.org>
Date: Thu Sep 25 15:32:29 2014 +0300
ufs: introduce well known logical unit in ufs
UFS device may have standard LUs and LUN id could be from 0x00 to 0x7F.
UFS device specification use "Peripheral Device Addressing Format"
(SCSI SAM-5) for standard LUs.
UFS device may also have the Well Known LUs (also referred as W-LU) which
again could be from 0x00 to 0x7F. For W-LUs, UFS device specification only
allows the "Extended Addressing Format" (SCSI SAM-5) which means the W-LUNs
would start from 0xC100 onwards.
This means max. LUN number reported from UFS device could be 0xC17F hence
this patch advertise the "max_lun" as 0xC17F which will allow SCSI mid
layer to detect the W-LUs as well.
But once the W-LUs are detected, UFSHCD driver may get the commands with
SCSI LUN id upto 0xC17F but UPIU LUN id field is only 8-bit wide so it
requires the mapping of SCSI LUN id to UPIU LUN id. This patch also add
support for this mapping.
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Dolev Raviv <draviv@codeaurora.org>
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
commit 2a8fa600445c45222632810a4811ce820279d106
Author: Subhash Jadavani <su…
pstglia
pushed a commit
to pstglia/linux
that referenced
this pull request
Oct 6, 2014
In function talitos_probe(), it will jump to err_out when getting an error in talitos_probe_irq(). Then the uninitialized list head priv->alg_list will be used in function talitos_remove(). In this case we would get a call trace like the following. So move up the initialization of priv->alg_list. Unable to handle kernel paging request for data at address 0x00000000 Faulting instruction address: 0xc0459ff4 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=8 P1020 RDB Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 3.13.0-08789-g54c0a4b46150 torvalds#33 task: cf050000 ti: cf04c000 task.ti: cf04c000 NIP: c0459ff4 LR: c0459fd4 CTR: c02f2438 REGS: cf04dcb0 TRAP: 0300 Tainted: G W (3.13.0-08789-g54c0a4b46150) MSR: 00029000 <CE,EE,ME> CR: 82000028 XER: 20000000 DEAR: 00000000 ESR: 00000000 GPR00: c045ac28 cf04dd60 cf050000 cf2579c0 00021000 00000000 c02f35b0 0000014e GPR08: c07e702c cf104300 c07e702c 0000014e 22000024 00000000 c0002a3c 00000000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 c082e4e0 000000df GPR24: 00000000 00100100 00200200 cf257a2c cf0efe10 cf2579c0 cf0efe10 00000000 NIP [c0459ff4] talitos_remove+0x3c/0x1c8 LR [c0459fd4] talitos_remove+0x1c/0x1c8 Call Trace: [cf04dd60] [c07485d8] __func__.13331+0x1241c8/0x1391c0 (unreliable) [cf04dd90] [c045ac28] talitos_probe+0x244/0x998 [cf04dde0] [c0306a74] platform_drv_probe+0x28/0x68 [cf04ddf0] [c0304d38] really_probe+0x78/0x250 [cf04de10] [c030505c] __driver_attach+0xc8/0xcc [cf04de30] [c0302e98] bus_for_each_dev+0x6c/0xb8 [cf04de60] [c03043cc] bus_add_driver+0x168/0x220 [cf04de80] [c0305798] driver_register+0x88/0x130 [cf04de90] [c0002458] do_one_initcall+0x14c/0x198 [cf04df00] [c079f904] kernel_init_freeable+0x138/0x1d4 [cf04df30] [c0002a50] kernel_init+0x14/0x124 [cf04df40] [c000ec40] ret_from_kernel_thread+0x5c/0x64 Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
mikey
pushed a commit
to mikey/linux
that referenced
this pull request
Oct 7, 2014
BugLink: http://bugs.launchpad.net/bugs/1338919 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1338919/comments/11 I'm getting the spew below when booting with Haswell (Xeon E5-2699 v3) CPUs and the "Cluster-on-Die" (CoD) feature enabled in the BIOS. It seems similar to the issue that some folks from AMD ran in to on their systems and addressed in this commit: 161270f ("x86/smp: Fix topology checks on AMD MCM CPUs") Both these Intel and AMD systems break an assumption which is being enforced by topology_sane(): a socket may not contain more than one NUMA node. AMD special-cased their system by looking for a cpuid flag. The Intel mode is dependent on BIOS options and I do not know of a way which it is enumerated other than the tables being parsed during the CPU bringup process. In other words, we have to trust the ACPI tables <shudder>. This detects the situation where a NUMA node occurs at a place in the middle of the "CPU" sched domains. It replaces the default topology with one that relies on the NUMA information from the firmware (SRAT table) for all levels of sched domains above the hyperthreads. This also fixes a sysfs bug. We used to freak out when we saw the "mc" group cross a node boundary, so we stopped building the MC group. MC gets exported as the 'core_siblings_list' in /sys/devices/system/cpu/cpu*/topology/ and this caused CPUs with the same 'physical_package_id' to not be listed together in 'core_siblings_list'. This violates a statement from Documentation/ABI/testing/sysfs-devices-system-cpu: core_siblings: internal kernel map of cpu#'s hardware threads within the same physical_package_id. core_siblings_list: human-readable list of the logical CPU numbers within the same physical_package_id as cpu#. The sysfs effects here cause an issue with the hwloc tool where it gets confused and thinks there are more sockets than are physically present. Before this patch, there are two packages: 18 0 18 1 But 4 _sets_ of core siblings: 9 0-8 9 18-26 9 27-35 9 9-17 After this set, there are only 2 sets of core siblings, which is what we expect for a 2-socket system. 18 0 18 1 18 0-17 18 18-35 Example spew: ... NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. #2 #3 #4 #5 torvalds#6 torvalds#7 torvalds#8 .... node #1, CPUs: torvalds#9 ------------[ cut here ]------------ WARNING: CPU: 9 PID: 0 at /home/ak/hle/linux-hle-2.6/arch/x86/kernel/smpboot.c:306 topology_sane.isra.2+0x74/0x90() sched: CPU torvalds#9's mc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency. Modules linked in: CPU: 9 PID: 0 Comm: swapper/9 Not tainted 3.17.0-rc1-00293-g8e01c4d-dirty torvalds#631 Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS GRNDSDP1.86B.0036.R05.1407140519 07/14/2014 0000000000000009 ffff88046ddabe00 ffffffff8172e485 ffff88046ddabe48 ffff88046ddabe38 ffffffff8109691d 000000000000b001 0000000000000009 ffff88086fc12580 000000000000b020 0000000000000009 ffff88046ddabe98 Call Trace: [<ffffffff8172e485>] dump_stack+0x45/0x56 [<ffffffff8109691d>] warn_slowpath_common+0x7d/0xa0 [<ffffffff8109698c>] warn_slowpath_fmt+0x4c/0x50 [<ffffffff81074f94>] topology_sane.isra.2+0x74/0x90 [<ffffffff8107530e>] set_cpu_sibling_map+0x31e/0x4f0 [<ffffffff8107568d>] start_secondary+0x1ad/0x240 ---[ end trace 3fe5f587a9fcde61 ]--- torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 torvalds#16 torvalds#17 .... node #2, CPUs: torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 torvalds#24 torvalds#25 torvalds#26 .... node #3, CPUs: torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 torvalds#32 torvalds#33 torvalds#34 torvalds#35 Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> [ Added LLC domain and s/match_mc/match_die/ ] Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Borislav Petkov <bp@alien8.de> Cc: David Rientjes <rientjes@google.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Toshi Kani <toshi.kani@hp.com> Cc: brice.goglin@gmail.com Cc: "H. Peter Anvin" <hpa@linux.intel.com> Link: http://lkml.kernel.org/r/20140918193334.C065EBCE@viggo.jf.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
kees
pushed a commit
to kees/linux
that referenced
this pull request
Oct 9, 2014
BugLink: http://bugs.launchpad.net/bugs/1371601 [ Upstream commit 757efd3 ] Dave reported following splat, caused by improper use of IP_INC_STATS_BH() in process context. BUG: using __this_cpu_add() in preemptible [00000000] code: trinity-c117/14551 caller is __this_cpu_preempt_check+0x13/0x20 CPU: 3 PID: 14551 Comm: trinity-c117 Not tainted 3.16.0+ torvalds#33 ffffffff9ec898f0 0000000047ea7e23 ffff88022d32f7f0 ffffffff9e7ee207 0000000000000003 ffff88022d32f818 ffffffff9e397eaa ffff88023ee70b40 ffff88022d32f970 ffff8801c026d580 ffff88022d32f828 ffffffff9e397ee3 Call Trace: [<ffffffff9e7ee207>] dump_stack+0x4e/0x7a [<ffffffff9e397eaa>] check_preemption_disabled+0xfa/0x100 [<ffffffff9e397ee3>] __this_cpu_preempt_check+0x13/0x20 [<ffffffffc0839872>] sctp_packet_transmit+0x692/0x710 [sctp] [<ffffffffc082a7f2>] sctp_outq_flush+0x2a2/0xc30 [sctp] [<ffffffff9e0d985c>] ? mark_held_locks+0x7c/0xb0 [<ffffffff9e7f8c6d>] ? _raw_spin_unlock_irqrestore+0x5d/0x80 [<ffffffffc082b99a>] sctp_outq_uncork+0x1a/0x20 [sctp] [<ffffffffc081e112>] sctp_cmd_interpreter.isra.23+0x1142/0x13f0 [sctp] [<ffffffffc081c86b>] sctp_do_sm+0xdb/0x330 [sctp] [<ffffffff9e0b8f1b>] ? preempt_count_sub+0xab/0x100 [<ffffffffc083b350>] ? sctp_cname+0x70/0x70 [sctp] [<ffffffffc08389ca>] sctp_primitive_ASSOCIATE+0x3a/0x50 [sctp] [<ffffffffc083358f>] sctp_sendmsg+0x88f/0xe30 [sctp] [<ffffffff9e0d673a>] ? lock_release_holdtime.part.28+0x9a/0x160 [<ffffffff9e0d62ce>] ? put_lock_stats.isra.27+0xe/0x30 [<ffffffff9e73b624>] inet_sendmsg+0x104/0x220 [<ffffffff9e73b525>] ? inet_sendmsg+0x5/0x220 [<ffffffff9e68ac4e>] sock_sendmsg+0x9e/0xe0 [<ffffffff9e1c0c09>] ? might_fault+0xb9/0xc0 [<ffffffff9e1c0bae>] ? might_fault+0x5e/0xc0 [<ffffffff9e68b234>] SYSC_sendto+0x124/0x1c0 [<ffffffff9e0136b0>] ? syscall_trace_enter+0x250/0x330 [<ffffffff9e68c3ce>] SyS_sendto+0xe/0x10 [<ffffffff9e7f9be4>] tracesys+0xdd/0xe2 This is a followup of commits f1d8cba ("inet: fix possible seqlock deadlocks") and 7f88c6b ("ipv6: fix possible seqlock deadlock in ip6_finish_output2") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Reported-by: Dave Jones <davej@redhat.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
torvalds
pushed a commit
that referenced
this pull request
Oct 29, 2014
This patch wires up the new syscall sys_bpf() on powerpc.
Passes the tests in samples/bpf:
#0 add+sub+mul OK
#1 unreachable OK
#2 unreachable2 OK
#3 out of range jump OK
#4 out of range jump2 OK
#5 test1 ld_imm64 OK
#6 test2 ld_imm64 OK
#7 test3 ld_imm64 OK
#8 test4 ld_imm64 OK
#9 test5 ld_imm64 OK
#10 no bpf_exit OK
#11 loop (back-edge) OK
#12 loop2 (back-edge) OK
#13 conditional loop OK
#14 read uninitialized register OK
#15 read invalid register OK
#16 program doesn't init R0 before exit OK
#17 stack out of bounds OK
#18 invalid call insn1 OK
#19 invalid call insn2 OK
#20 invalid function call OK
#21 uninitialized stack1 OK
#22 uninitialized stack2 OK
#23 check valid spill/fill OK
#24 check corrupted spill/fill OK
#25 invalid src register in STX OK
#26 invalid dst register in STX OK
#27 invalid dst register in ST OK
#28 invalid src register in LDX OK
#29 invalid dst register in LDX OK
#30 junk insn OK
#31 junk insn2 OK
#32 junk insn3 OK
#33 junk insn4 OK
#34 junk insn5 OK
#35 misaligned read from stack OK
#36 invalid map_fd for function call OK
#37 don't check return value before access OK
#38 access memory with incorrect alignment OK
#39 sometimes access memory with incorrect alignment OK
#40 jump test 1 OK
#41 jump test 2 OK
#42 jump test 3 OK
#43 jump test 4 OK
Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
[mpe: test using samples/bpf]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
dabrace
referenced
this pull request
in dabrace/linux
Nov 10, 2014
This patch wires up the new syscall sys_bpf() on powerpc.
Passes the tests in samples/bpf:
#0 add+sub+mul OK
#1 unreachable OK
#2 unreachable2 OK
#3 out of range jump OK
#4 out of range jump2 OK
#5 test1 ld_imm64 OK
#6 test2 ld_imm64 OK
#7 test3 ld_imm64 OK
#8 test4 ld_imm64 OK
#9 test5 ld_imm64 OK
#10 no bpf_exit OK
#11 loop (back-edge) OK
#12 loop2 (back-edge) OK
#13 conditional loop OK
#14 read uninitialized register OK
#15 read invalid register OK
#16 program doesn't init R0 before exit OK
#17 stack out of bounds OK
#18 invalid call insn1 OK
#19 invalid call insn2 OK
#20 invalid function call OK
#21 uninitialized stack1 OK
#22 uninitialized stack2 OK
#23 check valid spill/fill OK
#24 check corrupted spill/fill OK
#25 invalid src register in STX OK
#26 invalid dst register in STX OK
#27 invalid dst register in ST OK
#28 invalid src register in LDX OK
#29 invalid dst register in LDX OK
#30 junk insn OK
#31 junk insn2 OK
#32 junk insn3 OK
#33 junk insn4 OK
#34 junk insn5 OK
#35 misaligned read from stack OK
#36 invalid map_fd for function call OK
#37 don't check return value before access OK
#38 access memory with incorrect alignment OK
#39 sometimes access memory with incorrect alignment OK
#40 jump test 1 OK
#41 jump test 2 OK
#42 jump test 3 OK
#43 jump test 4 OK
Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
[mpe: test using samples/bpf]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
aejsmith
pushed a commit
to aejsmith/linux
that referenced
this pull request
Jun 26, 2015
jz4780 LCR driver added This isn't the 'perfect'/upstreamable way to handle LCR driver because the register overlaps with the cgu one. And there are other bits in the register that might be used by the cgu driver. Something like sharing via mfd/syscon might be needed while upstreaming. Should be ok for simple gpu/vpu/scpu enable/disable in 3.18
krzk
pushed a commit
to krzk/linux
that referenced
this pull request
Jul 9, 2015
While proving lock, the following warning happens and it is fixed after initializing lock in the setup function INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.27-02861-g39df285-dirty torvalds#33 [<c00154ac>] (unwind_backtrace+0x0/0xf4) from [<c0011b50>] (show_stack+0x10/0x14) [<c0011b50>] (show_stack+0x10/0x14) from [<c00689ac>] (__lock_acquire+0x900/0xb14) [<c00689ac>] (__lock_acquire+0x900/0xb14) from [<c0069394>] (lock_acquire+0x68/0x7c) [<c0069394>] (lock_acquire+0x68/0x7c) from [<c04958f8>] (_raw_spin_lock_irqsave+0x48/0x5c) [<c04958f8>] (_raw_spin_lock_irqsave+0x48/0x5c) from [<c0381e6c>] (clk_gate_endisable+0x28/0x88) [<c0381e6c>] (clk_gate_endisable+0x28/0x88) from [<c0381ee0>] (clk_gate_enable+0xc/0x14) [<c0381ee0>] (clk_gate_enable+0xc/0x14) from [<c0386c68>] (flexgen_enable+0x28/0x40) [<c0386c68>] (flexgen_enable+0x28/0x40) from [<c037f260>] (__clk_enable+0x5c/0x9c) [<c037f260>] (__clk_enable+0x5c/0x9c) from [<c037f558>] (clk_enable+0x18/0x2c) [<c037f558>] (clk_enable+0x18/0x2c) from [<c064a1dc>] (st_lpc_of_register+0xc0/0x248) [<c064a1dc>] (st_lpc_of_register+0xc0/0x248) from [<c0649e44>] (clocksource_of_init+0x34/0x58) [<c0649e44>] (clocksource_of_init+0x34/0x58) from [<c0637ddc>] (sti_timer_init+0x10/0x18) [<c0637ddc>] (sti_timer_init+0x10/0x18) from [<c06343f8>] (time_init+0x20/0x30) [<c06343f8>] (time_init+0x20/0x30) from [<c0632984>] (start_kernel+0x20c/0x2e8) [<c0632984>] (start_kernel+0x20c/0x2e8) from [<40008074>] (0x40008074) Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@linaro.org> Fixes: b116517 ("clk: st: STiH407: Support for Flexgen Clocks") Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
kernelOfTruth
pushed a commit
to kernelOfTruth/linux
that referenced
this pull request
Jul 15, 2015
Nikolay has reported a hang when a memcg reclaim got stuck with the following backtrace: PID: 18308 TASK: ffff883d7c9b0a30 CPU: 1 COMMAND: "rsync" #0 [ffff88177374ac60] __schedule at ffffffff815ab152 #1 [ffff88177374acb0] schedule at ffffffff815ab76e #2 [ffff88177374acd0] schedule_timeout at ffffffff815ae5e5 #3 [ffff88177374ad70] io_schedule_timeout at ffffffff815aad6a #4 [ffff88177374ada0] bit_wait_io at ffffffff815abfc6 #5 [ffff88177374adb0] __wait_on_bit at ffffffff815abda5 torvalds#6 [ffff88177374ae00] wait_on_page_bit at ffffffff8111fd4f torvalds#7 [ffff88177374ae50] shrink_page_list at ffffffff81135445 torvalds#8 [ffff88177374af50] shrink_inactive_list at ffffffff81135845 torvalds#9 [ffff88177374b060] shrink_lruvec at ffffffff81135ead torvalds#10 [ffff88177374b150] shrink_zone at ffffffff811360c3 torvalds#11 [ffff88177374b220] shrink_zones at ffffffff81136eff torvalds#12 [ffff88177374b2a0] do_try_to_free_pages at ffffffff8113712f torvalds#13 [ffff88177374b300] try_to_free_mem_cgroup_pages at ffffffff811372be torvalds#14 [ffff88177374b380] try_charge at ffffffff81189423 torvalds#15 [ffff88177374b430] mem_cgroup_try_charge at ffffffff8118c6f5 torvalds#16 [ffff88177374b470] __add_to_page_cache_locked at ffffffff8112137d torvalds#17 [ffff88177374b4e0] add_to_page_cache_lru at ffffffff81121618 torvalds#18 [ffff88177374b510] pagecache_get_page at ffffffff8112170b torvalds#19 [ffff88177374b560] grow_dev_page at ffffffff811c8297 torvalds#20 [ffff88177374b5c0] __getblk_slow at ffffffff811c91d6 torvalds#21 [ffff88177374b600] __getblk_gfp at ffffffff811c92c1 torvalds#22 [ffff88177374b630] ext4_ext_grow_indepth at ffffffff8124565c torvalds#23 [ffff88177374b690] ext4_ext_create_new_leaf at ffffffff81246ca8 torvalds#24 [ffff88177374b6e0] ext4_ext_insert_extent at ffffffff81246f09 torvalds#25 [ffff88177374b750] ext4_ext_map_blocks at ffffffff8124a848 torvalds#26 [ffff88177374b870] ext4_map_blocks at ffffffff8121a5b7 torvalds#27 [ffff88177374b910] mpage_map_one_extent at ffffffff8121b1fa torvalds#28 [ffff88177374b950] mpage_map_and_submit_extent at ffffffff8121f07b torvalds#29 [ffff88177374b9b0] ext4_writepages at ffffffff8121f6d5 torvalds#30 [ffff88177374bb20] do_writepages at ffffffff8112c490 torvalds#31 [ffff88177374bb30] __filemap_fdatawrite_range at ffffffff81120199 torvalds#32 [ffff88177374bb80] filemap_flush at ffffffff8112041c torvalds#33 [ffff88177374bb90] ext4_alloc_da_blocks at ffffffff81219da1 torvalds#34 [ffff88177374bbb0] ext4_rename at ffffffff81229b91 torvalds#35 [ffff88177374bcd0] ext4_rename2 at ffffffff81229e32 torvalds#36 [ffff88177374bce0] vfs_rename at ffffffff811a08a5 torvalds#37 [ffff88177374bd60] SYSC_renameat2 at ffffffff811a3ffc torvalds#38 [ffff88177374bf60] sys_renameat2 at ffffffff811a408e torvalds#39 [ffff88177374bf70] sys_rename at ffffffff8119e51e torvalds#40 [ffff88177374bf80] system_call_fastpath at ffffffff815afa89 Dave Chinner has properly pointed out that this is a deadlock in the reclaim code because ext4 doesn't submit pages which are marked by PG_writeback right away. The heuristic was introduced by e62e384 ("memcg: prevent OOM with too many dirty pages") and it was applied only when may_enter_fs was specified. The code has been changed by c3b94f4 ("memcg: further prevent OOM with too many dirty pages") which has removed the __GFP_FS restriction with a reasoning that we do not get into the fs code. But this is not sufficient apparently because the fs doesn't necessarily submit pages marked PG_writeback for IO right away. ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily submit the bio. Instead it tries to map more pages into the bio and mpage_map_one_extent might trigger memcg charge which might end up waiting on a page which is marked PG_writeback but hasn't been submitted yet so we would end up waiting for something that never finishes. Fix this issue by replacing __GFP_IO by __GFP_FS check (for case 2) before we go to wait on the writeback. The page fault path, which is the only path that triggers memcg oom killer since 3.12, shouldn't require GFP_NOFS and so we shouldn't reintroduce the premature OOM killer issue which was originally addressed by the heuristic. As per David Chinner the xfs is doing similar thing since 2.6.15 already so ext4 is not the only affected filesystem. Moreover he notes: : For example: IO completion might require unwritten extent conversion : which executes filesystem transactions and GFP_NOFS allocations. The : writeback flag on the pages can not be cleared until unwritten : extent conversion completes. Hence memory reclaim cannot wait on : page writeback to complete in GFP_NOFS context because it is not : safe to do so, memcg reclaim or otherwise. Cc: stable # 3.6+ [tytso@mit.edu: check for __GFP_FS rather than __GFP_IO] Fixes: c3b94f4 ("memcg: further prevent OOM with too many dirty pages") Reported-by: Nikolay Borisov <kernel@kyup.com> Signed-off-by: Michal Hocko <mhocko@suse.cz> --- mm/vmscan.c | 24 ++++++++++-------------- 1 file changed, 10 insertions(+), 14 deletions(-)
martinezjavier
pushed a commit
to martinezjavier/linux
that referenced
this pull request
Jul 30, 2015
Nikolay has reported a hang when a memcg reclaim got stuck with the following backtrace: PID: 18308 TASK: ffff883d7c9b0a30 CPU: 1 COMMAND: "rsync" #0 [ffff88177374ac60] __schedule at ffffffff815ab152 #1 [ffff88177374acb0] schedule at ffffffff815ab76e #2 [ffff88177374acd0] schedule_timeout at ffffffff815ae5e5 #3 [ffff88177374ad70] io_schedule_timeout at ffffffff815aad6a #4 [ffff88177374ada0] bit_wait_io at ffffffff815abfc6 #5 [ffff88177374adb0] __wait_on_bit at ffffffff815abda5 torvalds#6 [ffff88177374ae00] wait_on_page_bit at ffffffff8111fd4f torvalds#7 [ffff88177374ae50] shrink_page_list at ffffffff81135445 torvalds#8 [ffff88177374af50] shrink_inactive_list at ffffffff81135845 torvalds#9 [ffff88177374b060] shrink_lruvec at ffffffff81135ead torvalds#10 [ffff88177374b150] shrink_zone at ffffffff811360c3 torvalds#11 [ffff88177374b220] shrink_zones at ffffffff81136eff torvalds#12 [ffff88177374b2a0] do_try_to_free_pages at ffffffff8113712f torvalds#13 [ffff88177374b300] try_to_free_mem_cgroup_pages at ffffffff811372be torvalds#14 [ffff88177374b380] try_charge at ffffffff81189423 torvalds#15 [ffff88177374b430] mem_cgroup_try_charge at ffffffff8118c6f5 torvalds#16 [ffff88177374b470] __add_to_page_cache_locked at ffffffff8112137d torvalds#17 [ffff88177374b4e0] add_to_page_cache_lru at ffffffff81121618 torvalds#18 [ffff88177374b510] pagecache_get_page at ffffffff8112170b torvalds#19 [ffff88177374b560] grow_dev_page at ffffffff811c8297 torvalds#20 [ffff88177374b5c0] __getblk_slow at ffffffff811c91d6 torvalds#21 [ffff88177374b600] __getblk_gfp at ffffffff811c92c1 torvalds#22 [ffff88177374b630] ext4_ext_grow_indepth at ffffffff8124565c torvalds#23 [ffff88177374b690] ext4_ext_create_new_leaf at ffffffff81246ca8 torvalds#24 [ffff88177374b6e0] ext4_ext_insert_extent at ffffffff81246f09 torvalds#25 [ffff88177374b750] ext4_ext_map_blocks at ffffffff8124a848 torvalds#26 [ffff88177374b870] ext4_map_blocks at ffffffff8121a5b7 torvalds#27 [ffff88177374b910] mpage_map_one_extent at ffffffff8121b1fa torvalds#28 [ffff88177374b950] mpage_map_and_submit_extent at ffffffff8121f07b torvalds#29 [ffff88177374b9b0] ext4_writepages at ffffffff8121f6d5 torvalds#30 [ffff88177374bb20] do_writepages at ffffffff8112c490 torvalds#31 [ffff88177374bb30] __filemap_fdatawrite_range at ffffffff81120199 torvalds#32 [ffff88177374bb80] filemap_flush at ffffffff8112041c torvalds#33 [ffff88177374bb90] ext4_alloc_da_blocks at ffffffff81219da1 torvalds#34 [ffff88177374bbb0] ext4_rename at ffffffff81229b91 torvalds#35 [ffff88177374bcd0] ext4_rename2 at ffffffff81229e32 torvalds#36 [ffff88177374bce0] vfs_rename at ffffffff811a08a5 torvalds#37 [ffff88177374bd60] SYSC_renameat2 at ffffffff811a3ffc torvalds#38 [ffff88177374bf60] sys_renameat2 at ffffffff811a408e torvalds#39 [ffff88177374bf70] sys_rename at ffffffff8119e51e torvalds#40 [ffff88177374bf80] system_call_fastpath at ffffffff815afa89 Dave Chinner has properly pointed out that this is a deadlock in the reclaim code because ext4 doesn't submit pages which are marked by PG_writeback right away. The heuristic was introduced by e62e384 ("memcg: prevent OOM with too many dirty pages") and it was applied only when may_enter_fs was specified. The code has been changed by c3b94f4 ("memcg: further prevent OOM with too many dirty pages") which has removed the __GFP_FS restriction with a reasoning that we do not get into the fs code. But this is not sufficient apparently because the fs doesn't necessarily submit pages marked PG_writeback for IO right away. ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily submit the bio. Instead it tries to map more pages into the bio and mpage_map_one_extent might trigger memcg charge which might end up waiting on a page which is marked PG_writeback but hasn't been submitted yet so we would end up waiting for something that never finishes. Fix this issue by replacing __GFP_IO by __GFP_FS check (for case 2) before we go to wait on the writeback. The page fault path, which is the only path that triggers memcg oom killer since 3.12, shouldn't require GFP_NOFS and so we shouldn't reintroduce the premature OOM killer issue which was originally addressed by the heuristic. As per David Chinner the xfs is doing similar thing since 2.6.15 already so ext4 is not the only affected filesystem. Moreover he notes: : For example: IO completion might require unwritten extent conversion : which executes filesystem transactions and GFP_NOFS allocations. The : writeback flag on the pages can not be cleared until unwritten : extent conversion completes. Hence memory reclaim cannot wait on : page writeback to complete in GFP_NOFS context because it is not : safe to do so, memcg reclaim or otherwise. Fixes: c3b94f4 ("memcg: further prevent OOM with too many dirty pages") [tytso@mit.edu: check for __GFP_FS rather than __GFP_IO] Signed-off-by: Michal Hocko <mhocko@suse.cz> Reported-by: Nikolay Borisov <kernel@kyup.com> Cc: Theodore Ts'o <tytso@mit.edu> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Dave Chinner <david@fromorbit.com> Cc: Marian Marinov <mm@1h.com> Cc: Hugh Dickins <hughd@google.com> Cc: <stable@vger.kernel.org> [3.6+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ddstreet
pushed a commit
to ddstreet/linux
that referenced
this pull request
Jul 31, 2015
Nikolay has reported a hang when a memcg reclaim got stuck with the following backtrace: PID: 18308 TASK: ffff883d7c9b0a30 CPU: 1 COMMAND: "rsync" #0 [ffff88177374ac60] __schedule at ffffffff815ab152 #1 [ffff88177374acb0] schedule at ffffffff815ab76e #2 [ffff88177374acd0] schedule_timeout at ffffffff815ae5e5 #3 [ffff88177374ad70] io_schedule_timeout at ffffffff815aad6a #4 [ffff88177374ada0] bit_wait_io at ffffffff815abfc6 #5 [ffff88177374adb0] __wait_on_bit at ffffffff815abda5 torvalds#6 [ffff88177374ae00] wait_on_page_bit at ffffffff8111fd4f torvalds#7 [ffff88177374ae50] shrink_page_list at ffffffff81135445 torvalds#8 [ffff88177374af50] shrink_inactive_list at ffffffff81135845 torvalds#9 [ffff88177374b060] shrink_lruvec at ffffffff81135ead torvalds#10 [ffff88177374b150] shrink_zone at ffffffff811360c3 torvalds#11 [ffff88177374b220] shrink_zones at ffffffff81136eff torvalds#12 [ffff88177374b2a0] do_try_to_free_pages at ffffffff8113712f torvalds#13 [ffff88177374b300] try_to_free_mem_cgroup_pages at ffffffff811372be torvalds#14 [ffff88177374b380] try_charge at ffffffff81189423 torvalds#15 [ffff88177374b430] mem_cgroup_try_charge at ffffffff8118c6f5 torvalds#16 [ffff88177374b470] __add_to_page_cache_locked at ffffffff8112137d torvalds#17 [ffff88177374b4e0] add_to_page_cache_lru at ffffffff81121618 torvalds#18 [ffff88177374b510] pagecache_get_page at ffffffff8112170b torvalds#19 [ffff88177374b560] grow_dev_page at ffffffff811c8297 torvalds#20 [ffff88177374b5c0] __getblk_slow at ffffffff811c91d6 torvalds#21 [ffff88177374b600] __getblk_gfp at ffffffff811c92c1 torvalds#22 [ffff88177374b630] ext4_ext_grow_indepth at ffffffff8124565c torvalds#23 [ffff88177374b690] ext4_ext_create_new_leaf at ffffffff81246ca8 torvalds#24 [ffff88177374b6e0] ext4_ext_insert_extent at ffffffff81246f09 torvalds#25 [ffff88177374b750] ext4_ext_map_blocks at ffffffff8124a848 torvalds#26 [ffff88177374b870] ext4_map_blocks at ffffffff8121a5b7 torvalds#27 [ffff88177374b910] mpage_map_one_extent at ffffffff8121b1fa torvalds#28 [ffff88177374b950] mpage_map_and_submit_extent at ffffffff8121f07b torvalds#29 [ffff88177374b9b0] ext4_writepages at ffffffff8121f6d5 torvalds#30 [ffff88177374bb20] do_writepages at ffffffff8112c490 torvalds#31 [ffff88177374bb30] __filemap_fdatawrite_range at ffffffff81120199 torvalds#32 [ffff88177374bb80] filemap_flush at ffffffff8112041c torvalds#33 [ffff88177374bb90] ext4_alloc_da_blocks at ffffffff81219da1 torvalds#34 [ffff88177374bbb0] ext4_rename at ffffffff81229b91 torvalds#35 [ffff88177374bcd0] ext4_rename2 at ffffffff81229e32 torvalds#36 [ffff88177374bce0] vfs_rename at ffffffff811a08a5 torvalds#37 [ffff88177374bd60] SYSC_renameat2 at ffffffff811a3ffc torvalds#38 [ffff88177374bf60] sys_renameat2 at ffffffff811a408e torvalds#39 [ffff88177374bf70] sys_rename at ffffffff8119e51e torvalds#40 [ffff88177374bf80] system_call_fastpath at ffffffff815afa89 Dave Chinner has properly pointed out that this is a deadlock in the reclaim code because ext4 doesn't submit pages which are marked by PG_writeback right away. The heuristic was introduced by e62e384 ("memcg: prevent OOM with too many dirty pages") and it was applied only when may_enter_fs was specified. The code has been changed by c3b94f4 ("memcg: further prevent OOM with too many dirty pages") which has removed the __GFP_FS restriction with a reasoning that we do not get into the fs code. But this is not sufficient apparently because the fs doesn't necessarily submit pages marked PG_writeback for IO right away. ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily submit the bio. Instead it tries to map more pages into the bio and mpage_map_one_extent might trigger memcg charge which might end up waiting on a page which is marked PG_writeback but hasn't been submitted yet so we would end up waiting for something that never finishes. Fix this issue by replacing __GFP_IO by __GFP_FS check (for case 2) before we go to wait on the writeback. The page fault path, which is the only path that triggers memcg oom killer since 3.12, shouldn't require GFP_NOFS and so we shouldn't reintroduce the premature OOM killer issue which was originally addressed by the heuristic. As per David Chinner the xfs is doing similar thing since 2.6.15 already so ext4 is not the only affected filesystem. Moreover he notes: : For example: IO completion might require unwritten extent conversion : which executes filesystem transactions and GFP_NOFS allocations. The : writeback flag on the pages can not be cleared until unwritten : extent conversion completes. Hence memory reclaim cannot wait on : page writeback to complete in GFP_NOFS context because it is not : safe to do so, memcg reclaim or otherwise. Fixes: c3b94f4 ("memcg: further prevent OOM with too many dirty pages") [tytso@mit.edu: check for __GFP_FS rather than __GFP_IO] Signed-off-by: Michal Hocko <mhocko@suse.cz> Reported-by: Nikolay Borisov <kernel@kyup.com> Cc: Theodore Ts'o <tytso@mit.edu> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Dave Chinner <david@fromorbit.com> Cc: Marian Marinov <mm@1h.com> Cc: Hugh Dickins <hughd@google.com> Cc: <stable@vger.kernel.org> [3.6+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
torvalds
pushed a commit
that referenced
this pull request
Aug 5, 2015
Nikolay has reported a hang when a memcg reclaim got stuck with the following backtrace: PID: 18308 TASK: ffff883d7c9b0a30 CPU: 1 COMMAND: "rsync" #0 __schedule at ffffffff815ab152 #1 schedule at ffffffff815ab76e #2 schedule_timeout at ffffffff815ae5e5 #3 io_schedule_timeout at ffffffff815aad6a #4 bit_wait_io at ffffffff815abfc6 #5 __wait_on_bit at ffffffff815abda5 #6 wait_on_page_bit at ffffffff8111fd4f #7 shrink_page_list at ffffffff81135445 #8 shrink_inactive_list at ffffffff81135845 #9 shrink_lruvec at ffffffff81135ead #10 shrink_zone at ffffffff811360c3 #11 shrink_zones at ffffffff81136eff #12 do_try_to_free_pages at ffffffff8113712f #13 try_to_free_mem_cgroup_pages at ffffffff811372be #14 try_charge at ffffffff81189423 #15 mem_cgroup_try_charge at ffffffff8118c6f5 #16 __add_to_page_cache_locked at ffffffff8112137d #17 add_to_page_cache_lru at ffffffff81121618 #18 pagecache_get_page at ffffffff8112170b #19 grow_dev_page at ffffffff811c8297 #20 __getblk_slow at ffffffff811c91d6 #21 __getblk_gfp at ffffffff811c92c1 #22 ext4_ext_grow_indepth at ffffffff8124565c #23 ext4_ext_create_new_leaf at ffffffff81246ca8 #24 ext4_ext_insert_extent at ffffffff81246f09 #25 ext4_ext_map_blocks at ffffffff8124a848 #26 ext4_map_blocks at ffffffff8121a5b7 #27 mpage_map_one_extent at ffffffff8121b1fa #28 mpage_map_and_submit_extent at ffffffff8121f07b #29 ext4_writepages at ffffffff8121f6d5 #30 do_writepages at ffffffff8112c490 #31 __filemap_fdatawrite_range at ffffffff81120199 #32 filemap_flush at ffffffff8112041c #33 ext4_alloc_da_blocks at ffffffff81219da1 #34 ext4_rename at ffffffff81229b91 #35 ext4_rename2 at ffffffff81229e32 #36 vfs_rename at ffffffff811a08a5 #37 SYSC_renameat2 at ffffffff811a3ffc #38 sys_renameat2 at ffffffff811a408e #39 sys_rename at ffffffff8119e51e #40 system_call_fastpath at ffffffff815afa89 Dave Chinner has properly pointed out that this is a deadlock in the reclaim code because ext4 doesn't submit pages which are marked by PG_writeback right away. The heuristic was introduced by commit e62e384 ("memcg: prevent OOM with too many dirty pages") and it was applied only when may_enter_fs was specified. The code has been changed by c3b94f4 ("memcg: further prevent OOM with too many dirty pages") which has removed the __GFP_FS restriction with a reasoning that we do not get into the fs code. But this is not sufficient apparently because the fs doesn't necessarily submit pages marked PG_writeback for IO right away. ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily submit the bio. Instead it tries to map more pages into the bio and mpage_map_one_extent might trigger memcg charge which might end up waiting on a page which is marked PG_writeback but hasn't been submitted yet so we would end up waiting for something that never finishes. Fix this issue by replacing __GFP_IO by may_enter_fs check (for case 2) before we go to wait on the writeback. The page fault path, which is the only path that triggers memcg oom killer since 3.12, shouldn't require GFP_NOFS and so we shouldn't reintroduce the premature OOM killer issue which was originally addressed by the heuristic. As per David Chinner the xfs is doing similar thing since 2.6.15 already so ext4 is not the only affected filesystem. Moreover he notes: : For example: IO completion might require unwritten extent conversion : which executes filesystem transactions and GFP_NOFS allocations. The : writeback flag on the pages can not be cleared until unwritten : extent conversion completes. Hence memory reclaim cannot wait on : page writeback to complete in GFP_NOFS context because it is not : safe to do so, memcg reclaim or otherwise. Cc: stable@vger.kernel.org # 3.9+ [tytso@mit.edu: corrected the control flow] Fixes: c3b94f4 ("memcg: further prevent OOM with too many dirty pages") Reported-by: Nikolay Borisov <kernel@kyup.com> Signed-off-by: Michal Hocko <mhocko@suse.cz> Signed-off-by: Hugh Dickins <hughd@google.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ddstreet
pushed a commit
to ddstreet/linux
that referenced
this pull request
Aug 6, 2015
GIT 4469942 commit fc1a812 Author: Alex Williamson <alex.williamson@redhat.com> Date: Tue Aug 4 10:58:26 2015 -0600 KVM: MTRR: Use default type for non-MTRR-covered gfn before WARN_ON The patch was munged on commit to re-order these tests resulting in excessive warnings when trying to do device assignment. Return to original ordering: https://lkml.org/lkml/2015/7/15/769 Fixes: 3e5d2fd ("KVM: MTRR: simplify kvm_mtrr_get_guest_memory_type") Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Xiao Guangrong <guangrong.xiao@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> commit ecf5fc6 Author: Michal Hocko <mhocko@suse.cz> Date: Tue Aug 4 14:36:58 2015 -0700 mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations Nikolay has reported a hang when a memcg reclaim got stuck with the following backtrace: PID: 18308 TASK: ffff883d7c9b0a30 CPU: 1 COMMAND: "rsync" #0 __schedule at ffffffff815ab152 #1 schedule at ffffffff815ab76e #2 schedule_timeout at ffffffff815ae5e5 #3 io_schedule_timeout at ffffffff815aad6a #4 bit_wait_io at ffffffff815abfc6 #5 __wait_on_bit at ffffffff815abda5 torvalds#6 wait_on_page_bit at ffffffff8111fd4f torvalds#7 shrink_page_list at ffffffff81135445 torvalds#8 shrink_inactive_list at ffffffff81135845 torvalds#9 shrink_lruvec at ffffffff81135ead torvalds#10 shrink_zone at ffffffff811360c3 torvalds#11 shrink_zones at ffffffff81136eff torvalds#12 do_try_to_free_pages at ffffffff8113712f torvalds#13 try_to_free_mem_cgroup_pages at ffffffff811372be torvalds#14 try_charge at ffffffff81189423 torvalds#15 mem_cgroup_try_charge at ffffffff8118c6f5 torvalds#16 __add_to_page_cache_locked at ffffffff8112137d torvalds#17 add_to_page_cache_lru at ffffffff81121618 torvalds#18 pagecache_get_page at ffffffff8112170b torvalds#19 grow_dev_page at ffffffff811c8297 torvalds#20 __getblk_slow at ffffffff811c91d6 torvalds#21 __getblk_gfp at ffffffff811c92c1 torvalds#22 ext4_ext_grow_indepth at ffffffff8124565c torvalds#23 ext4_ext_create_new_leaf at ffffffff81246ca8 torvalds#24 ext4_ext_insert_extent at ffffffff81246f09 torvalds#25 ext4_ext_map_blocks at ffffffff8124a848 torvalds#26 ext4_map_blocks at ffffffff8121a5b7 torvalds#27 mpage_map_one_extent at ffffffff8121b1fa torvalds#28 mpage_map_and_submit_extent at ffffffff8121f07b torvalds#29 ext4_writepages at ffffffff8121f6d5 torvalds#30 do_writepages at ffffffff8112c490 torvalds#31 __filemap_fdatawrite_range at ffffffff81120199 torvalds#32 filemap_flush at ffffffff8112041c torvalds#33 ext4_alloc_da_blocks at ffffffff81219da1 torvalds#34 ext4_rename at ffffffff81229b91 torvalds#35 ext4_rename2 at ffffffff81229e32 torvalds#36 vfs_rename at ffffffff811a08a5 torvalds#37 SYSC_renameat2 at ffffffff811a3ffc torvalds#38 sys_renameat2 at ffffffff811a408e torvalds#39 sys_rename at ffffffff8119e51e torvalds#40 system_call_fastpath at ffffffff815afa89 Dave Chinner has properly pointed out that this is a deadlock in the reclaim code because ext4 doesn't submit pages which are marked by PG_writeback right away. The heuristic was introduced by commit e62e384 ("memcg: prevent OOM with too many dirty pages") and it was applied only when may_enter_fs was specified. The code has been changed by c3b94f4 ("memcg: further prevent OOM with too many dirty pages") which has removed the __GFP_FS restriction with a reasoning that we do not get into the fs code. But this is not sufficient apparently because the fs doesn't necessarily submit pages marked PG_writeback for IO right away. ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily submit the bio. Instead it tries to map more pages into the bio and mpage_map_one_extent might trigger memcg charge which might end up waiting on a page which is marked PG_writeback but hasn't been submitted yet so we would end up waiting for something that never finishes. Fix this issue by replacing __GFP_IO by may_enter_fs check (for case 2) before we go to wait on the writeback. The page fault path, which is the only path that triggers memcg oom killer since 3.12, shouldn't require GFP_NOFS and so we shouldn't reintroduce the premature OOM killer issue which was originally addressed by the heuristic. As per David Chinner the xfs is doing similar thing since 2.6.15 already so ext4 is not the only affected filesystem. Moreover he notes: : For example: IO completion might require unwritten extent conversion : which executes filesystem transactions and GFP_NOFS allocations. The : writeback flag on the pages can not be cleared until unwritten : extent conversion completes. Hence memory reclaim cannot wait on : page writeback to complete in GFP_NOFS context because it is not : safe to do so, memcg reclaim or otherwise. Cc: stable@vger.kernel.org # 3.9+ [tytso@mit.edu: corrected the control flow] Fixes: c3b94f4 ("memcg: further prevent OOM with too many dirty pages") Reported-by: Nikolay Borisov <kernel@kyup.com> Signed-off-by: Michal Hocko <mhocko@suse.cz> Signed-off-by: Hugh Dickins <hughd@google.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> commit fcdf31a Author: Ross Lagerwall <ross.lagerwall@citrix.com> Date: Fri Jul 31 14:30:42 2015 +0100 xen/events/fifo: Handle linked events when closing a port An event channel bound to a CPU that was offlined may still be linked on that CPU's queue. If this event channel is closed and reused, subsequent events will be lost because the event channel is never unlinked and thus cannot be linked onto the correct queue. When a channel is closed and the event is still linked into a queue, ensure that it is unlinked before completing. If the CPU to which the event channel bound is online, spin until the event is handled by that CPU. If that CPU is offline, it can't handle the event, so clear the event queue during the close, dropping the events. This fixes the missing interrupts (and subsequent disk stalls etc.) when offlining a CPU. Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> Cc: <stable@vger.kernel.org> Signed-off-by: David Vrabel <david.vrabel@citrix.com> commit 6ea76f3 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Aug 3 17:24:11 2015 +0200 drm/atomic-helpers: Make encoder picking more robust We've had a few issues with atomic where subtle bugs in the encoder picking logic lead to accidental self-stealing of the encoder, resulting in a NULL connector_state->crtc in update_connector_routing and subsequent. Linus applied some duct-tape for an mst regression in commit 27667f4 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Wed Jul 29 22:18:16 2015 -0700 i915: temporary fix for DP MST docking station NULL pointer dereference But that was incomplete (the code will still oops when debuggin is enabled) and mangled the state even further. So instead WARN and bail out as the more future-proof option. Cc: Theodore Ts'o <tytso@mit.edu> Cc: Linus Torvalds <torvalds@linux-foundation.org> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> commit 42639ba Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Aug 3 17:24:10 2015 +0200 drm/dp-mst: Remove debug WARN_ON Apparently been in there since forever and fairly easy to hit when hotplugging really fast. I can do that since my mst hub has a manual button to flick the hpd line for reprobing. The resulting WARNING spam isn't pretty. Cc: Dave Airlie <airlied@gmail.com> Cc: stable@vger.kernel.org Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> commit 459485a Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Aug 3 17:24:09 2015 +0200 drm/i915: Fixup dp mst encoder selection In commit 8c7b5cc Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Tue Apr 21 17:13:19 2015 +0300 drm/i915: Use atomic helpers for computing changed flags we've switched over to the atomic version to compute the crtc->encoder->connector routing from the i915 variant. That one relies upon the ->best_encoder callback, but the i915-private version relied upon intel_find_encoder. Which didn't matter except for dp mst, where the encoder depends upon the selected crtc. Fix this functional bug by implemented a correct atomic-state based encoder selector for dp mst. Note that we can't get rid of the legacy best_encoder callback since the fbdev emulation uses that still. That means it's incorrect there still, but that's been the case ever since i915 dp mst support was merged so not a regression. Best to fix that by converting fbdev over to atomic too. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> commit 3b8a684 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Aug 3 17:24:08 2015 +0200 drm/atomic-helper: Add an atomice best_encoder callback With legacy helpers all the routing was already set up when calling best_encoder and so could be inspected. But with atomic it's staged, hence we need a new atomic compliant callback for drivers which need to inspect the requested state and can't just decided the best encoder statically. This is needed to fix up i915 dp mst where we need to pick the right encoder depending upon the requested CRTC for the connector. v2: Don't forget to amend the kerneldoc Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Theodore Ts'o <tytso@mit.edu> Acked-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> commit 5413fcd Author: Salvatore Mesoraca <s.mesoraca16@gmail.com> Date: Mon Aug 3 12:40:51 2015 +0200 Adding YAMA hooks also when YAMA is not stacked. Without this patch YAMA will not work at all if it is chosen as the primary LSM instead of being "stacked". Signed-off-by: Salvatore Mesoraca <s.mesoraca16@gmail.com> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com> commit 49895bc Author: NeilBrown <neilb@suse.com> Date: Mon Aug 3 17:09:57 2015 +1000 md/raid5: don't let shrink_slab shrink too far. I have a report of drop_one_stripe() called from raid5_cache_scan() apparently finding ->max_nr_stripes == 0. This should not be allowed. So add a test to keep max_nr_stripes above min_nr_stripes. Also use a 'mask' rather than a 'mod' in drop_one_stripe to ensure 'hash' is valid even if max_nr_stripes does reach zero. Fixes: edbe83a ("md/raid5: allow the stripe_cache to grow and shrink.") Cc: stable@vger.kernel.org (4.1 - please release with 2d5b569) Reported-by: Tomas Papan <tomas.papan@gmail.com> Signed-off-by: NeilBrown <neilb@suse.com> commit b6878d9 Author: Benjamin Randazzo <benjamin@randazzo.fr> Date: Sat Jul 25 16:36:50 2015 +0200 md: use kzalloc() when bitmap is disabled In drivers/md/md.c get_bitmap_file() uses kmalloc() for creating a mdu_bitmap_file_t called "file". 5769 file = kmalloc(sizeof(*file), GFP_NOIO); 5770 if (!file) 5771 return -ENOMEM; This structure is copied to user space at the end of the function. 5786 if (err == 0 && 5787 copy_to_user(arg, file, sizeof(*file))) 5788 err = -EFAULT But if bitmap is disabled only the first byte of "file" is initialized with zero, so it's possible to read some bytes (up to 4095) of kernel space memory from user space. This is an information leak. 5775 /* bitmap disabled, zero the first byte and copy out */ 5776 if (!mddev->bitmap_info.file) 5777 file->pathname[0] = '\0'; Signed-off-by: Benjamin Randazzo <benjamin@randazzo.fr> Signed-off-by: NeilBrown <neilb@suse.com> commit 423f04d Author: NeilBrown <neilb@suse.com> Date: Mon Jul 27 11:48:52 2015 +1000 md/raid1: extend spinlock to protect raid1_end_read_request against inconsistencies raid1_end_read_request() assumes that the In_sync bits are consistent with the ->degaded count. raid1_spare_active updates the In_sync bit before the ->degraded count and so exposes an inconsistency, as does error() So extend the spinlock in raid1_spare_active() and error() to hide those inconsistencies. This should probably be part of Commit: 34cab6f ("md/raid1: fix test for 'was read error from last working device'.") as it addresses the same issue. It fixes the same bug and should go to -stable for same reasons. Fixes: 7607305 ("md/raid1: clean up read_balance.") Cc: stable@vger.kernel.org (v3.0+) Signed-off-by: NeilBrown <neilb@suse.com> commit e331146 Author: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Date: Mon Jul 27 17:30:48 2015 +0300 i2c: fix leaked device refcount on of_find_i2c_* error path If of_find_i2c_device_by_node() or of_find_i2c_adapter_by_node() find a device by node, but its type does not match, a reference to that device is still held. This change fixes the problem. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> commit 8fcd461 Author: Jeff Layton <jlayton@poochiereds.net> Date: Thu Jul 30 06:57:46 2015 -0400 nfsd: do nfs4_check_fh in nfs4_check_file instead of nfs4_check_olstateid Currently, preprocess_stateid_op calls nfs4_check_olstateid which verifies that the open stateid corresponds to the current filehandle in the call by calling nfs4_check_fh. If the stateid is a NFS4_DELEG_STID however, then no such check is done. This could cause incorrect enforcement of permissions, because the nfsd_permission() call in nfs4_check_file uses current the current filehandle, but any subsequent IO operation will use the file descriptor in the stateid. Move the call to nfs4_check_fh into nfs4_check_file instead so that it can be done for all stateid types. Signed-off-by: Jeff Layton <jeff.layton@primarydata.com> Cc: stable@vger.kernel.org [bfields: moved fh check to avoid NULL deref in special stateid case] Signed-off-by: J. Bruce Fields <bfields@redhat.com> commit e952849 Author: Masanari Iida <standby24x7@gmail.com> Date: Tue Jul 28 20:11:23 2015 +0900 i2c: Fix typo in i2c-bfin-twi.c This patch fix some typos found in a printk message and MODULE_DESCRIPTION. Signed-off-by: Masanari Iida <standby24x7@gmail.com> Acked-by: Sonic Zhang <sonic.zhang@analog.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> commit 828e66c Author: Jan Luebbe <jlu@pengutronix.de> Date: Wed Jul 8 16:35:27 2015 +0200 i2c: omap: fix bus recovery setup At least on the AM335x, enabling OMAP_I2C_SYSTEST_ST_EN is not enough to allow direct access to the SCL and SDA pins. In addition to ST_EN, we need to set the TMODE to 0b11 (Loop back & SDA/SCL IO mode select). Also, as the reset values of SCL_O and SDA_O are 0 (which means "drive low level"), we need to set them to 1 (which means "high-impedance") to avoid unwanted changes on the pins. As a precaution, reset all these bits to their default values after recovery is complete. Signed-off-by: Jan Luebbe <jlu@pengutronix.de> Tested-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> commit 8b06260 Author: Jan Luebbe <jlu@pengutronix.de> Date: Wed Jul 8 16:35:06 2015 +0200 i2c: core: only use set_scl for bus recovery after calling prepare_recovery Using set_scl may be ineffective before calling the driver specific prepare_recovery callback, which might change into a test mode. So instead of setting SCL in i2c_generic_scl_recovery, move it to i2c_generic_recovery (after the optional prepare_recovery). Signed-off-by: Jan Luebbe <jlu@pengutronix.de> Acked-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> commit d12c0aa Author: Vladimir Zapolskiy <vz@mleia.com> Date: Mon Jul 27 00:18:51 2015 +0300 misc: eeprom: at24: clean up at24_bin_write() The change removes redundant sysfs binary file boundary check, since this task is already done on caller side in fs/sysfs/file.c Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> commit 1f02329 Author: Vladimir Zapolskiy <vz@mleia.com> Date: Mon Jul 27 00:16:31 2015 +0300 i2c: slave eeprom: clean up sysfs bin attribute read()/write() The change removes redundant sysfs binary file boundary checks, since this task is already done on caller side in fs/sysfs/file.c Note, on file size overflow read() now returns 0, and this is a correct and expected EOF notification according to POSIX. Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> commit 2761713 Author: Ilya Dryomov <idryomov@gmail.com> Date: Thu Jul 16 17:36:11 2015 +0300 rbd: fix copyup completion race For write/discard obj_requests that involved a copyup method call, the opcode of the first op is CEPH_OSD_OP_CALL and the ->callback is rbd_img_obj_copyup_callback(). The latter frees copyup pages, sets ->xferred and delegates to rbd_img_obj_callback(), the "normal" image object callback, for reporting to block layer and putting refs. rbd_osd_req_callback() however treats CEPH_OSD_OP_CALL as a trivial op, which means obj_request is marked done in rbd_osd_trivial_callback(), *before* ->callback is invoked and rbd_img_obj_copyup_callback() has a chance to run. Marking obj_request done essentially means giving rbd_img_obj_callback() a license to end it at any moment, so if another obj_request from the same img_request is being completed concurrently, rbd_img_obj_end_request() may very well be called on such prematurally marked done request: <obj_request-1/2 reply> handle_reply() rbd_osd_req_callback() rbd_osd_trivial_callback() rbd_obj_request_complete() rbd_img_obj_copyup_callback() rbd_img_obj_callback() <obj_request-2/2 reply> handle_reply() rbd_osd_req_callback() rbd_osd_trivial_callback() for_each_obj_request(obj_request->img_request) { rbd_img_obj_end_request(obj_request-1/2) rbd_img_obj_end_request(obj_request-2/2) <-- } Calling rbd_img_obj_end_request() on such a request leads to trouble, in particular because its ->xfferred is 0. We report 0 to the block layer with blk_update_request(), get back 1 for "this request has more data in flight" and then trip on rbd_assert(more ^ (which == img_request->obj_request_count)); with rhs (which == ...) being 1 because rbd_img_obj_end_request() has been called for both requests and lhs (more) being 1 because we haven't got a chance to set ->xfferred in rbd_img_obj_copyup_callback() yet. To fix this, leverage that rbd wants to call class methods in only two cases: one is a generic method call wrapper (obj_request is standalone) and the other is a copyup (obj_request is part of an img_request). So make a dedicated handler for CEPH_OSD_OP_CALL and directly invoke rbd_img_obj_copyup_callback() from it if obj_request is part of an img_request, similar to how CEPH_OSD_OP_READ handler invokes rbd_img_obj_request_read_callback(). Since rbd_img_obj_copyup_callback() is now being called from the OSD request callback (only), it is renamed to rbd_osd_copyup_callback(). Cc: Alex Elder <elder@linaro.org> Cc: stable@vger.kernel.org # 3.10+, needs backporting for < 3.18 Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Alex Elder <elder@linaro.org> commit fc927cd Author: Yan, Zheng <zyan@redhat.com> Date: Mon Jul 20 09:50:58 2015 +0800 ceph: always re-send cap flushes when MDS recovers commit e548e9b makes the kclient only re-send cap flush once during MDS failover. If the kclient sends a cap flush after MDS enters reconnect stage but before MDS recovers. The kclient will skip re-sending the same cap flush when MDS recovers. This causes problem for newly created inode. The MDS handles cap flushes before replaying unsafe requests, so it's possible that MDS find corresponding inode is missing when handling cap flush. The fix is reverting to old behaviour: always re-send when MDS recovers Signed-off-by: Yan, Zheng <zyan@redhat.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com> commit f6762cb Author: Yan, Zheng <zyan@redhat.com> Date: Tue Jul 7 16:18:46 2015 +0800 ceph: fix ceph_encode_locks_to_buffer() posix locks should be in ctx->flc_posix list Signed-off-by: Yan, Zheng <zyan@redhat.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com> commit 586b7cc Author: Christian Borntraeger <borntraeger@de.ibm.com> Date: Tue Jul 28 15:03:05 2015 +0200 KVM: s390: Fix hang VCPU hang/loop regression commit 785dbef ("KVM: s390: optimize round trip time in request handling") introduced a regression. This regression was seen with CPU hotplug in the guest and switching between 1 or 2 CPUs. This will set/reset the IBS control via synced request. Whenever we make a synced request, we first set the vcpu->requests bit and then block the vcpu. The handler, on the other hand, unblocks itself, processes vcpu->requests (by clearing them) and unblocks itself once again. Now, if the requester sleeps between setting of vcpu->requests and blocking, the handler will clear the vcpu->requests bit and try to unblock itself (although no bit is set). When the requester wakes up, it blocks the VCPU and we have a blocked VCPU without requests. Solution is to always unset the block bit. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Fixes: 785dbef ("KVM: s390: optimize round trip time in request handling") commit fe0d34d Author: Rusty Russell <rusty@rustcorp.com.au> Date: Wed Jul 29 05:52:14 2015 +0930 module: weaken locking assertion for oops path. We don't actually hold the module_mutex when calling find_module_all from module_kallsyms_lookup_name: that's because it's used by the oops code and we don't want to deadlock. However, access to the list read-only is safe if preempt is disabled, so we can weaken the assertion. Keep a strong version for external callers though. Fixes: 0be964b ("module: Sanitize RCU usage and locking") Reported-by: He Kuang <hekuang@huawei.com> Cc: stable@kernel.org Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> commit 17fb874 Author: Martin Schwidefsky <schwidefsky@de.ibm.com> Date: Fri Jul 24 13:13:30 2015 +0200 hwrng: core - correct error check of kthread_run call The kthread_run() function can return two different error values but the hwrng core only checks for -ENOMEM. If the other error value -EINTR is returned it is assigned to hwrng_fill and later used on a kthread_stop() call which naturally crashes. Cc: stable@vger.kernel.org Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> commit f898c52 Author: Herbert Xu <herbert@gondor.apana.org.au> Date: Wed Jul 22 18:05:35 2015 +0800 crypto: ixp4xx - Remove bogus BUG_ON on scattered dst buffer This patch removes a bogus BUG_ON in the ablkcipher path that triggers when the destination buffer is different from the source buffer and is scattered. Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> commit 6f043b5 Author: Tadeusz Struk <tadeusz.struk@intel.com> Date: Tue Jul 21 22:07:47 2015 -0700 crypto: qat - Fix invalid synchronization between register/unregister sym algs The synchronization method used atomic was bogus. Use a proper synchronization with mutex. Cc: stable@vger.kernel.org Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> commit 3d1450d Author: Jason A. Donenfeld <Jason@zx2c4.com> Date: Tue Jul 7 20:26:07 2015 +0200 Makefile: Force gzip and xz on module install Running `make modules_install` ordinarily will overwrite existing modules. This is the desired behavior, and is how pretty much every other `make install` target works. However, if CONFIG_MODULE_COMPRESS is enabled, modules are passed through gzip and xz which then do the file writing. Both gzip and xz will error out if the file already exists, unless -f is passed. This patch adds -f so that the behavior is uniform. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Michal Marek <mmarek@suse.com> commit 6dd3f13 Author: Michal Marek <mmarek@suse.com> Date: Thu Jul 16 18:23:53 2015 +0200 kbuild: Do not pick up ARCH_{CPP,A,C}FLAGS from the environment Initialize the ARCH_* overrides before including the arch Makefile, to avoid picking up the values from the environment. The variables can still be overriden on the make command line, but this won't happen by accident. Signed-off-by: Michal Marek <mmarek@suse.com> commit 1ca4b88 Author: Kinglong Mee <kinglongmee@gmail.com> Date: Thu Jul 9 17:38:26 2015 +0800 nfsd: Fix a file leak on nfsd4_layout_setlease failure If nfsd4_layout_setlease fails, nfsd will not put ls->ls_file. Fix commit c5c707f "nfsd: implement pNFS layout recalls". Signed-off-by: Kinglong Mee <kinglongmee@gmail.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com> commit c2227a3 Author: Kinglong Mee <kinglongmee@gmail.com> Date: Tue Jul 7 10:16:37 2015 +0800 nfsd: Drop BUG_ON and ignore SECLABEL on absent filesystem On an absent filesystem (one served by another server), we need to be able to handle requests for certain attributest (like fs_locations, so the client can find out which server does have the filesystem), but others we can't. We forgot to take that into account when adding another attribute bitmask work for the SECURITY_LABEL attribute. There an export entry with the "refer" option can result in: [ 88.414272] kernel BUG at fs/nfsd/nfs4xdr.c:2249! [ 88.414828] invalid opcode: 0000 [#1] SMP [ 88.415368] Modules linked in: rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache nfsd xfs libcrc32c iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi iosf_mbi ppdev btrfs coretemp crct10dif_pclmul crc32_pclmul crc32c_intel xor ghash_clmulni_intel raid6_pq vmw_balloon parport_pc parport i2c_piix4 shpchp vmw_vmci acpi_cpufreq auth_rpcgss nfs_acl lockd grace sunrpc vmwgfx drm_kms_helper ttm drm mptspi mptscsih serio_raw mptbase e1000 scsi_transport_spi ata_generic pata_acpi [last unloaded: nfsd] [ 88.417827] CPU: 0 PID: 2116 Comm: nfsd Not tainted 4.0.7-300.fc22.x86_64 #1 [ 88.418448] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014 [ 88.419093] task: ffff880079146d50 ti: ffff8800785d8000 task.ti: ffff8800785d8000 [ 88.419729] RIP: 0010:[<ffffffffa04b3c10>] [<ffffffffa04b3c10>] nfsd4_encode_fattr+0x820/0x1f00 [nfsd] [ 88.420376] RSP: 0000:ffff8800785db998 EFLAGS: 00010206 [ 88.421027] RAX: 0000000000000001 RBX: 000000000018091a RCX: ffff88006668b980 [ 88.421676] RDX: 00000000fffef7fc RSI: 0000000000000000 RDI: ffff880078d05000 [ 88.422315] RBP: ffff8800785dbb58 R08: ffff880078d043f8 R09: ffff880078d4a000 [ 88.422968] R10: 0000000000010000 R11: 0000000000000002 R12: 0000000000b0a23a [ 88.423612] R13: ffff880078d05000 R14: ffff880078683100 R15: ffff88006668b980 [ 88.424295] FS: 0000000000000000(0000) GS:ffff88007c600000(0000) knlGS:0000000000000000 [ 88.424944] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.425597] CR2: 00007f40bc370f90 CR3: 0000000035af5000 CR4: 00000000001407f0 [ 88.426285] Stack: [ 88.426921] ffff8800785dbaa8 ffffffffa049e4af ffff8800785dba08 ffffffff813298f0 [ 88.427585] ffff880078683300 ffff8800769b0de8 0000089d00000001 0000000087f805e0 [ 88.428228] ffff880000000000 ffff880079434a00 0000000000000000 ffff88006668b980 [ 88.428877] Call Trace: [ 88.429527] [<ffffffffa049e4af>] ? exp_get_by_name+0x7f/0xb0 [nfsd] [ 88.430168] [<ffffffff813298f0>] ? inode_doinit_with_dentry+0x210/0x6a0 [ 88.430807] [<ffffffff8123833e>] ? d_lookup+0x2e/0x60 [ 88.431449] [<ffffffff81236133>] ? dput+0x33/0x230 [ 88.432097] [<ffffffff8123f214>] ? mntput+0x24/0x40 [ 88.432719] [<ffffffff812272b2>] ? path_put+0x22/0x30 [ 88.433340] [<ffffffffa049ac87>] ? nfsd_cross_mnt+0xb7/0x1c0 [nfsd] [ 88.433954] [<ffffffffa04b54e0>] nfsd4_encode_dirent+0x1b0/0x3d0 [nfsd] [ 88.434601] [<ffffffffa04b5330>] ? nfsd4_encode_getattr+0x40/0x40 [nfsd] [ 88.435172] [<ffffffffa049c991>] nfsd_readdir+0x1c1/0x2a0 [nfsd] [ 88.435710] [<ffffffffa049a530>] ? nfsd_direct_splice_actor+0x20/0x20 [nfsd] [ 88.436447] [<ffffffffa04abf30>] nfsd4_encode_readdir+0x120/0x220 [nfsd] [ 88.437011] [<ffffffffa04b58cd>] nfsd4_encode_operation+0x7d/0x190 [nfsd] [ 88.437566] [<ffffffffa04aa6dd>] nfsd4_proc_compound+0x24d/0x6f0 [nfsd] [ 88.438157] [<ffffffffa0496103>] nfsd_dispatch+0xc3/0x220 [nfsd] [ 88.438680] [<ffffffffa006f0cb>] svc_process_common+0x43b/0x690 [sunrpc] [ 88.439192] [<ffffffffa0070493>] svc_process+0x103/0x1b0 [sunrpc] [ 88.439694] [<ffffffffa0495a57>] nfsd+0x117/0x190 [nfsd] [ 88.440194] [<ffffffffa0495940>] ? nfsd_destroy+0x90/0x90 [nfsd] [ 88.440697] [<ffffffff810bb728>] kthread+0xd8/0xf0 [ 88.441260] [<ffffffff810bb650>] ? kthread_worker_fn+0x180/0x180 [ 88.441762] [<ffffffff81789e58>] ret_from_fork+0x58/0x90 [ 88.442322] [<ffffffff810bb650>] ? kthread_worker_fn+0x180/0x180 [ 88.442879] Code: 0f 84 93 05 00 00 83 f8 ea c7 85 a0 fe ff ff 00 00 27 30 0f 84 ba fe ff ff 85 c0 0f 85 a5 fe ff ff e9 e3 f9 ff ff 0f 1f 44 00 00 <0f> 0b 66 0f 1f 44 00 00 be 04 00 00 00 4c 89 ef 4c 89 8d 68 fe [ 88.444052] RIP [<ffffffffa04b3c10>] nfsd4_encode_fattr+0x820/0x1f00 [nfsd] [ 88.444658] RSP <ffff8800785db998> [ 88.445232] ---[ end trace 6cb9d0487d94a29f ]--- Signed-off-by: Kinglong Mee <kinglongmee@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields <bfields@redhat.com> commit 929423f Author: Juergen Gross <jgross@suse.com> Date: Mon Jul 20 13:49:39 2015 +0200 xen: release lock occasionally during ballooning When dom0 is being ballooned balloon_process() will hold the balloon mutex until it is finished. This will block e.g. creation of new domains as the device backends for the new domain need some autoballooned pages for the ring buffers. Avoid this by releasing the balloon mutex from time to time during ballooning. Adjust the comment above balloon_process() regarding multiple instances of balloon_process(). Instead of open coding it, just use cond_resched(). Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: David Vrabel <david.vrabel@citrix.com> commit c9ddbac Author: Michael S. Tsirkin <mst@redhat.com> Date: Tue Jul 14 18:27:46 2015 -0500 PCI: Restore PCI_MSIX_FLAGS_BIRMASK definition 09a2c73 ("PCI: Remove unused PCI_MSIX_FLAGS_BIRMASK definition") removed PCI_MSIX_FLAGS_BIRMASK from an exported header because it was unused in the kernel. But that breaks user programs that were using it (QEMU in particular). Restore the PCI_MSIX_FLAGS_BIRMASK definition. [bhelgaas: changelog] Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.13+ commit 30b03d0 Author: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Date: Fri Jun 26 03:28:24 2015 +0200 xen/gntdevt: Fix race condition in gntdev_release() While gntdev_release() is called the MMU notifier is still registered and can traverse priv->maps list even if no pages are mapped (which is the case -- gntdev_release() is called after all). But gntdev_release() will clear that list, so make sure that only one of those things happens at the same time. Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Cc: <stable@vger.kernel.org> Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
damentz
referenced
this pull request
in zen-kernel/zen-kernel
Aug 10, 2015
commit 0f4f2af upstream. While proving lock, the following warning happens and it is fixed after initializing lock in the setup function INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.27-02861-g39df285-dirty #33 [<c00154ac>] (unwind_backtrace+0x0/0xf4) from [<c0011b50>] (show_stack+0x10/0x14) [<c0011b50>] (show_stack+0x10/0x14) from [<c00689ac>] (__lock_acquire+0x900/0xb14) [<c00689ac>] (__lock_acquire+0x900/0xb14) from [<c0069394>] (lock_acquire+0x68/0x7c) [<c0069394>] (lock_acquire+0x68/0x7c) from [<c04958f8>] (_raw_spin_lock_irqsave+0x48/0x5c) [<c04958f8>] (_raw_spin_lock_irqsave+0x48/0x5c) from [<c0381e6c>] (clk_gate_endisable+0x28/0x88) [<c0381e6c>] (clk_gate_endisable+0x28/0x88) from [<c0381ee0>] (clk_gate_enable+0xc/0x14) [<c0381ee0>] (clk_gate_enable+0xc/0x14) from [<c0386c68>] (flexgen_enable+0x28/0x40) [<c0386c68>] (flexgen_enable+0x28/0x40) from [<c037f260>] (__clk_enable+0x5c/0x9c) [<c037f260>] (__clk_enable+0x5c/0x9c) from [<c037f558>] (clk_enable+0x18/0x2c) [<c037f558>] (clk_enable+0x18/0x2c) from [<c064a1dc>] (st_lpc_of_register+0xc0/0x248) [<c064a1dc>] (st_lpc_of_register+0xc0/0x248) from [<c0649e44>] (clocksource_of_init+0x34/0x58) [<c0649e44>] (clocksource_of_init+0x34/0x58) from [<c0637ddc>] (sti_timer_init+0x10/0x18) [<c0637ddc>] (sti_timer_init+0x10/0x18) from [<c06343f8>] (time_init+0x20/0x30) [<c06343f8>] (time_init+0x20/0x30) from [<c0632984>] (start_kernel+0x20c/0x2e8) [<c0632984>] (start_kernel+0x20c/0x2e8) from [<40008074>] (0x40008074) Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@linaro.org> Fixes: b116517 ("clk: st: STiH407: Support for Flexgen Clocks") Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 10, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 10, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 10, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 11, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 11, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 11, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 11, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 11, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 11, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 11, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 11, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 12, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 12, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 12, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 12, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 12, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 12, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 12, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 12, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 13, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 13, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 13, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 13, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 13, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 13, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 13, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 13, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 14, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Nov 14, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: NipaLocal <nipa@local>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Nov 14, 2024
Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb torvalds#33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/20241108-ipmr_rcu-v2-1-c718998e209b@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.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.
This tiny pull request fixes...
compilation error.