commit 538069756ce13f9d0e0ccb7a17b6935a0bfb7cad Author: Greg Kroah-Hartman Date: Wed Dec 4 11:03:31 2013 -0800 Linux 3.10.22 commit 88a810def754d5516252b9a8b9efc34d875d399f Author: Wei Liu Date: Mon Dec 2 17:49:54 2013 +0000 xen-netback: fix refcnt unbalance for 3.10 With the introduction of "xen-netback: Don't destroy the netdev until the vif is shut down" (upstream commit id 279f438e36), vif disconnect and free are separated. However in the backported version reference counting code was not correctly modified, and the reset of vif->irq was lost. If frontend goes through vif life cycle more than once the reference counting is skewed. This patch adds back the missing vif->irq reset line. It also moves several lines of the reference counting code to vif_free, so the moved code corresponds to the counterpart in vif_alloc, thus the reference counting is balanced. Signed-off-by: Wei Liu Acked-by: Ian Campbell Cc: Konrad Wilk Cc: David Vrabel Signed-off-by: Greg Kroah-Hartman commit 69848a721c5a84b63f1801e340cc2e6cdde17c61 Author: Stanislaw Gruszka Date: Mon Jul 1 14:19:30 2013 +0200 iwl4965: better skb management in rx path commit c1de4a9557d9e25e41fc4ba034b9659152205539 upstream. 4965 version of Eric patch "iwl3945: better skb management in rx path". It fixes several problems : 1) skb->truesize is underestimated. We really consume PAGE_SIZE bytes for a fragment, not the frame length. 2) 128 bytes of initial headroom is a bit low and forces reallocations. 3) We can avoid consuming a full page for small enough frames. Signed-off-by: Stanislaw Gruszka Acked-by: Eric Dumazet Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 2c4805f3ae216cfd6fc2a386ea523d5a6eee6fdc Author: Eric Dumazet Date: Fri Jun 28 08:05:06 2013 -0700 iwl3945: better skb management in rx path commit 45fe142cefa864b685615bcb930159f6749c3667 upstream. Steinar reported reallocations of skb->head with IPv6, leading to a warning in skb_try_coalesce() It turns out iwl3945 has several problems : 1) skb->truesize is underestimated. We really consume PAGE_SIZE bytes for a fragment, not the frame length. 2) 128 bytes of initial headroom is a bit low and forces reallocations. 3) We can avoid consuming a full page for small enough frames. Reported-by: Steinar H. Gunderson Signed-off-by: Eric Dumazet Cc: Paul Stewart Acked-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit d4e937777fa1a97b21916eecd7d7d9dd8534d3d1 Author: Johannes Koch Date: Wed Jul 17 14:28:16 2013 -0300 media: cx23885: Fix TeVii S471 regression since introduction of ts2020 commit b43ea8068d2090cb1e44632c8a938ab40d2c7419 upstream. Patch to make TeVii S471 cards use the ts2020 tuner, since ds3000 driver no longer contains tuning code. Signed-off-by: Johannes Koch Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 78ab8cbc11ee095ec27d7f6edde91e2c3af1540d Author: Michal Kubecek Date: Wed Sep 11 10:17:27 2013 +0200 netfilter: nf_conntrack: use RCU safe kfree for conntrack extensions commit c13a84a830a208fb3443628773c8ca0557773cc7 upstream. Commit 68b80f11 (netfilter: nf_nat: fix RCU races) introduced RCU protection for freeing extension data when reallocation moves them to a new location. We need the same protection when freeing them in nf_ct_ext_free() in order to prevent a use-after-free by other threads referencing a NAT extension data via bysource list. Signed-off-by: Michal Kubecek Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit a1daae5dbf42e8f4446c122a63a24fdb8b2c854b Author: Emmanuel Grumbach Date: Sun Sep 15 11:37:17 2013 +0300 iwlwifi: don't WARN on host commands sent when firmware is dead commit 8ca95995e64f5d270889badb3e449dca91106a2b upstream. This triggers automatic bug reports and add no valuable information. Print a simple error instead and drop the host command. Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit d2e99b2fc1056d2c5f4bf7fd691d37ba216c1455 Author: Alex Deucher Date: Thu Oct 10 11:47:01 2013 -0400 drm/radeon: re-enable sw ACR support on pre-DCE4 commit b852c985010a77c850b7548d64bbb964ca462b02 upstream. HW ACR support may have issues on some older chips, so use SW ACR for now until we've tested further. Signed-off-by: Alex Deucher CC: Rafał Miłecki Signed-off-by: Greg Kroah-Hartman commit 26f99321a04b01d59cedc434788830fd31b3c7d9 Author: Alex Deucher Date: Fri Sep 27 18:22:15 2013 -0400 drm/radeon: use hw generated CTS/N values for audio commit ee0fec312a1c4e26f255955da942562cd8908a4b upstream. Use the hw generated values rather than calculating them in the driver. There may be some older r6xx asics where this doesn't work correctly. This remains to be seen. See bug: https://bugs.freedesktop.org/show_bug.cgi?id=69675 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit eebf839b51416e440d40660d00a8ea465bfa74c6 Author: Alex Deucher Date: Fri Sep 27 18:19:42 2013 -0400 drm/radeon: fix N/CTS clock matching for audio commit e7d12c2f98ae1e68c7298e5028048d150fa553a1 upstream. The drm code that calculates the 1001 clocks rounds up rather than truncating. This allows the table to match properly on those modes. See bug: https://bugs.freedesktop.org/show_bug.cgi?id=69675 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 78c3ae2cb101bc10f3b9cc851e826484246088e1 Author: Alex Deucher Date: Fri Sep 27 18:09:54 2013 -0400 drm/radeon: use 64-bit math to calculate CTS values for audio (v2) commit 062c2e4363451d49ef840232fe65e8bff0dde2a5 upstream. Avoid losing precision. See bug: https://bugs.freedesktop.org/show_bug.cgi?id=69675 v2: fix math as per Anssi's comments. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit b18cd40e6228da53f2781f37f9b94a1930c6ee9c Author: Nanno Langstraat Date: Mon Oct 14 16:07:15 2013 +0200 HID: apple: option to swap the 'Option' ("Alt") and 'Command' ("Flag") keys. commit 43c831468b3d26dbe8f2e061ccaf1abaf9cc1b8b upstream. Use case: people who use both Apple and PC keyboards regularly, and desire to keep&use their PC muscle memory. A particular use case: an Apple compact external keyboard connected to a PC laptop. (This use case can't be covered well by X.org key remappings etc.) Signed-off-by: Nanno Langstraat Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit bb4522d30c7d110d33cece574f50db128016a69e Author: Tristan Rice Date: Tue Nov 12 19:06:23 2013 +0100 HID: enable Mayflash USB Gamecube Adapter commit e17f5d7667c5414b8f12a93ef14aae0824bd2beb upstream. This is a patch that adds the new Mayflash Gamecube Controller to USB adapter (ID 1a34:f705 ACRUX) to the ACRUX driver (drivers/hid/hid-axff.c) with full force feedback support. Signed-off-by: Tristan Rice Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 4370a0d55bc5f14e02b2e79b8bd5ef8f713e4a0c Author: Stefan Achatz Date: Fri Nov 8 14:12:00 2013 +0100 HID: roccat: add missing special driver declarations commit e078809df5611600965f4d3420c3256260fc3e3d upstream. Forgot two special driver declarations and sorted the list. Signed-off-by: Stefan Achatz Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 95f5725870267aa819025237a14c2ccacd78b85b Author: Stefan Achatz Date: Sun Nov 3 06:25:33 2013 +0100 HID: roccat: fix Coverity CID 141438 commit 7be63f20b00840a6f1c718dcee00855688d64acd upstream. Add missing switch breaks. Signed-off-by: Stefan Achatz Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 405052f57cb5f3b7e6042c36c952d3980375fd5b Author: Stefan Achatz Date: Mon Oct 28 18:52:03 2013 +0100 HID: roccat: add new device return value commit 14fc4290df2fb94a28f39dab9ed32feaa5527bef upstream. Ryos uses a new return value for critical errors, others have been confirmed. Signed-off-by: Stefan Achatz Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit d8f0a31aa3ccf94e1902ff6c0c68410e3b68ecca Author: David Howells Date: Tue Jun 18 17:40:44 2013 +0100 X.509: Remove certificate date checks commit 124df926090b32a998483f6e43ebeccdbe5b5302 upstream. Remove the certificate date checks that are performed when a certificate is parsed. There are two checks: a valid from and a valid to. The first check is causing a lot of problems with system clocks that don't keep good time and the second places an implicit expiry date upon the kernel when used for module signing, so do we really need them? Signed-off-by: David Howells cc: David Woodhouse cc: Rusty Russell cc: Josh Boyer cc: Alexander Holler Signed-off-by: Greg Kroah-Hartman commit ffc0c180edbae4149206ad5eb8485d3040cb350e Author: Mauro Carvalho Chehab Date: Sat Nov 2 04:29:42 2013 -0300 media: s5h1420: Don't use dynamic static allocation commit 9736a89dafe07359d9c86bf9c3b815a250b354bc upstream. Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/dvb-frontends/s5h1420.c:851:1: warning: 's5h1420_tuner_i2c_tuner_xfer' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. In the specific case of this frontend, only ttpci uses it. The maximum number of messages there is two, on I2C read operations. As the logic can add an extra operation, change the size to 3. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 830658240837a0545307e689c612b637bd4f9b22 Author: Mauro Carvalho Chehab Date: Sat Nov 2 05:05:18 2013 -0300 media: dvb-frontends: Don't use dynamic static allocation commit 8393796dfa4cf5dffcceec464c7789bec3a2f471 upstream. Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/dvb-frontends/bcm3510.c:230:1: warning: 'bcm3510_do_hab_cmd' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/itd1000.c:69:1: warning: 'itd1000_write_regs.constprop.0' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/mt312.c:126:1: warning: 'mt312_write' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/nxt200x.c:111:1: warning: 'nxt200x_writebytes' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/stb6100.c:216:1: warning: 'stb6100_write_reg_range.constprop.3' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/stv6110.c:98:1: warning: 'stv6110_write_regs' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/stv6110x.c:85:1: warning: 'stv6110x_write_regs' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/tda18271c2dd.c:147:1: warning: 'WriteRegs' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/zl10039.c:119:1: warning: 'zl10039_write' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. Considering that I2C transfers are generally limited, and that devices used on USB has a max data length of 64 bytes for the control URBs. So, it seem safe to use 64 bytes as the hard limit for all those devices. On most cases, the limit is a way lower than that, but this limit is small enough to not affect the Kernel stack, and it is a no brain limit, as using smaller ones would require to either carefully each driver or to take a look on each datasheet. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 10184cdc523eb232ff416c6aa5819dfbcb681870 Author: Mauro Carvalho Chehab Date: Sat Nov 2 05:11:47 2013 -0300 media: dvb-frontends: Don't use dynamic static allocation commit 37ebaf6891ee81687bb558e8375c0712d8264ed8 upstream. Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/dvb-frontends/af9013.c:77:1: warning: 'af9013_wr_regs_i2c' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/af9033.c:188:1: warning: 'af9033_wr_reg_val_tab' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/af9033.c:68:1: warning: 'af9033_wr_regs' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/bcm3510.c:230:1: warning: 'bcm3510_do_hab_cmd' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/cxd2820r_core.c:84:1: warning: 'cxd2820r_rd_regs_i2c.isra.1' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/rtl2830.c:56:1: warning: 'rtl2830_wr' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/rtl2832.c:187:1: warning: 'rtl2832_wr' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/tda10071.c:52:1: warning: 'tda10071_wr_regs' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/tda10071.c:84:1: warning: 'tda10071_rd_regs' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. Considering that I2C transfers are generally limited, and that devices used on USB has a max data length of 64 bytes for the control URBs. So, it seem safe to use 64 bytes as the hard limit for all those devices. On most cases, the limit is a way lower than that, but this limit is small enough to not affect the Kernel stack, and it is a no brain limit, as using smaller ones would require to either carefully each driver or to take a look on each datasheet. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Hans Verkuil Reviewed-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 845b09830c162084301f65c947894389cd48e8b6 Author: Mauro Carvalho Chehab Date: Sat Nov 2 05:14:58 2013 -0300 media: stb0899_drv: Don't use dynamic static allocation commit ba4746423488aafa435739c32bfe0758f3dd5d77 upstream. Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/dvb-frontends/stb0899_drv.c:540:1: warning: 'stb0899_write_regs' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. Considering that I2C transfers are generally limited, and that devices used on USB has a max data length of 64 bytes for the control URBs. So, it seem safe to use 64 bytes as the hard limit for all those devices. On most cases, the limit is a way lower than that, but this limit is small enough to not affect the Kernel stack, and it is a no brain limit, as using smaller ones would require to either carefully each driver or to take a look on each datasheet. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 6d3ac5e79294ecf2c437de63e9a38d125b7c5922 Author: Mauro Carvalho Chehab Date: Sat Nov 2 05:17:01 2013 -0300 media: stv0367: Don't use dynamic static allocation commit 9aca4fb0571ce9cfef680ceb08d19dd008015307 upstream. Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/dvb-frontends/stv0367.c:791:1: warning: 'stv0367_writeregs.constprop.4' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. Considering that I2C transfers are generally limited, and that devices used on USB has a max data length of 64 bytes for the control URBs. So, it seem safe to use 64 bytes as the hard limit for all those devices. On most cases, the limit is a way lower than that, but this limit is small enough to not affect the Kernel stack, and it is a no brain limit, as using smaller ones would require to either carefully each driver or to take a look on each datasheet. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit bea929cb3ef0887cccf8e30331574f23f530ba99 Author: Mauro Carvalho Chehab Date: Sat Nov 2 05:18:49 2013 -0300 media: stv090x: Don't use dynamic static allocation commit f7a35df15b1f7de7823946aebc9164854e66ea07 upstream. Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/dvb-frontends/stv090x.c:750:1: warning: 'stv090x_write_regs.constprop.6' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. Considering that I2C transfers are generally limited, and that devices used on USB has a max data length of 64 bytes for the control URBs. So, it seem safe to use 64 bytes as the hard limit for all those devices. On most cases, the limit is a way lower than that, but this limit is small enough to not affect the Kernel stack, and it is a no brain limit, as using smaller ones would require to either carefully each driver or to take a look on each datasheet. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 9269743b3dcb031fb94d962ca90d14836dc8b4c4 Author: Mauro Carvalho Chehab Date: Sat Nov 2 06:07:42 2013 -0300 media: tuners: Don't use dynamic static allocation commit f1baab870f6e93b668af7b34d6f6ba49f1b0e982 upstream. Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses dynamic stack allocation [enabled by default] drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses dynamic stack allocation [enabled by default] drivers/media/tuners/fc2580.c:66:1: warning: 'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by default] drivers/media/tuners/fc2580.c:98:1: warning: 'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default] drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses dynamic stack allocation [enabled by default] drivers/media/tuners/tda18212.c:90:1: warning: 'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default] drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses dynamic stack allocation [enabled by default] drivers/media/tuners/tda18218.c:92:1: warning: 'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. Considering that I2C transfers are generally limited, and that devices used on USB has a max data length of 64 bytes for the control URBs. So, it seem safe to use 64 bytes as the hard limit for all those devices. On most cases, the limit is a way lower than that, but this limit is small enough to not affect the Kernel stack, and it is a no brain limit, as using smaller ones would require to either carefully each driver or to take a look on each datasheet. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Hans Verkuil Reviewed-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit e4b95ceb002456b9628512cb0bd898bf1b62936c Author: Mauro Carvalho Chehab Date: Sat Nov 2 06:13:11 2013 -0300 media: tuner-xc2028: Don't use dynamic static allocation commit 56ac033725ec93a45170caf3979eb2b1211a59a8 upstream. Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/tuners/tuner-xc2028.c:651:1: warning: 'load_firmware' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. In the specific case of this driver, the maximum limit is 80, used only on tm6000 driver. This limit is due to the size of the USB control URBs. Ok, it would be theoretically possible to use a bigger size on PCI devices, but the firmware load time is already good enough. Anyway, if some usage requires more, it is just a matter of also increasing the buffer size at load_firmware(). Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 85217792a27009a1fd48832269fb5fd181f4834a Author: Mauro Carvalho Chehab Date: Sat Nov 2 08:16:47 2013 -0300 media: lirc_zilog: Don't use dynamic static allocation commit ac5b4b6bf0c84c48d7e2e3fce22e35b04282ba76 upstream. Dynamic static allocation is evil, as Kernel stack is too low, and ompilation complains about it on some archs: drivers/staging/media/lirc/lirc_zilog.c:967:1: warning: 'read' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer to be 64. That should be more than enough. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit ef144824aceec873f0e61c1bb8a95c618534b21f Author: Mauro Carvalho Chehab Date: Fri Nov 1 13:09:47 2013 -0300 media: cx18: struct i2c_client is too big for stack commit 1d212cf0c2d89adf3d0a6d62d729076f49f087dc upstream. drivers/media/pci/cx18/cx18-driver.c: In function 'cx18_read_eeprom': drivers/media/pci/cx18/cx18-driver.c:357:1: warning: the frame size of 1072 bytes is larger than 1024 bytes [-Wframe-larger-than=] That happens because the routine allocates 256 bytes for an eeprom buffer, plus the size of struct i2c_client, with is big. Change the logic to dynamically allocate/deallocate space for struct i2c_client, instead of using the stack. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit e84c43168ac1837d2dab02d141ddc1172c75fea5 Author: Mauro Carvalho Chehab Date: Sat Nov 2 06:17:47 2013 -0300 media: cimax2: Don't use dynamic static allocation commit 278ba83a3a1932805be726bdd7dfb3156286d33a upstream. Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/pci/cx23885/cimax2.c:149:1: warning: 'netup_write_i2c' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. Considering that I2C transfers are generally limited, and that devices used on USB has a max data length of 64 bytes for the control URBs. So, it seem safe to use 64 bytes as the hard limit for all those devices. On most cases, the limit is a way lower than that, but this limit is small enough to not affect the Kernel stack, and it is a no brain limit, as using smaller ones would require to either carefully each driver or to take a look on each datasheet. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 227aebf46dddbff678fe4248cc424ac11f5267dc Author: Mauro Carvalho Chehab Date: Sat Nov 2 05:51:59 2013 -0300 media: av7110_hw: Don't use dynamic static allocation commit 5bf30b3bc4ff80ef71a733a1f459cca4fa507892 upstream. Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/pci/ttpci/av7110_hw.c:510:1: warning: 'av7110_fw_cmd' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. In the specific case of this driver, the maximum fw command size is 6 + 2, as checked using: $ git grep -A1 av7110_fw_cmd drivers/media/pci/ttpci/ So, use 8 for the buffer size. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit a691956557756a05d948ce37a23b7011b88a53b7 Author: Mauro Carvalho Chehab Date: Sat Nov 2 07:18:09 2013 -0300 media: cxusb: Don't use dynamic static allocation commit 64f7ef8afbf89f3c72c4d2472e4914ca198c0668 upstream. Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/usb/dvb-usb/cxusb.c:209:1: warning: 'cxusb_i2c_xfer' uses dynamic stack allocation [enabled by default] drivers/media/usb/dvb-usb/cxusb.c:69:1: warning: 'cxusb_ctrl_msg' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer to be the max size of a control URB payload data (64 bytes). Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 7ce9cdbe07651a2417a00d0a37c8b9fefae12f4b Author: Mauro Carvalho Chehab Date: Sat Nov 2 07:23:49 2013 -0300 media: dibusb-common: Don't use dynamic static allocation commit 1d7fa359d4c0fbb2756fa01cc47212908d90b7b0 upstream. Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/usb/dvb-usb/dibusb-common.c:124:1: warning: 'dibusb_i2c_msg' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer to be the max size of a control URB payload data (64 bytes). Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit b49dfbeea93ebd078fa57404913d7e89320e94fa Author: Mauro Carvalho Chehab Date: Sat Nov 2 07:43:40 2013 -0300 media: dw2102: Don't use dynamic static allocation commit 0065a79a8698a953e4b201c5fce8db8940530578 upstream. Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/usb/dvb-usb/dw2102.c:368:1: warning: 'dw2102_earda_i2c_transfer' uses dynamic stack allocation [enabled by default] drivers/media/usb/dvb-usb/dw2102.c:449:1: warning: 'dw2104_i2c_transfer' uses dynamic stack allocation [enabled by default] drivers/media/usb/dvb-usb/dw2102.c:512:1: warning: 'dw3101_i2c_transfer' uses dynamic stack allocation [enabled by default] drivers/media/usb/dvb-usb/dw2102.c:621:1: warning: 's6x0_i2c_transfer' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer to be the max size of a control URB payload data (64 bytes). Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 08c049cf8a259c6c1f204451ab2ed661be3c5dd5 Author: Mauro Carvalho Chehab Date: Sat Nov 2 07:52:04 2013 -0300 media: af9015: Don't use dynamic static allocation commit 65e2f1cb3fe0f0630834b9517ba8f631936f325c upstream. Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/usb/dvb-usb-v2/af9015.c:433:1: warning: 'af9015_eeprom_hash' uses dynamic stack allocation [enabled by default] In this specific case, it is a gcc bug, as the size is a const, but it is easy to just change it from const to a #define, getting rid of the gcc warning. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Hans Verkuil Reviewed-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit fd30877d2b8ef6a7cd82d780c4f21f13f2263144 Author: Mauro Carvalho Chehab Date: Sat Nov 2 08:07:12 2013 -0300 media: af9035: Don't use dynamic static allocation commit 7760e148350bf6df95662bc0db3734e9d991cb03 upstream. Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/usb/dvb-usb-v2/af9035.c:142:1: warning: 'af9035_wr_regs' uses dynamic stack allocation [enabled by default] drivers/media/usb/dvb-usb-v2/af9035.c:305:1: warning: 'af9035_i2c_master_xfer' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer to be the max size of a control URB payload data (64 bytes). Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Hans Verkuil Reviewed-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit b20dcb6c21f4f670569b8f756ed2c5f1ba1e44e4 Author: Mauro Carvalho Chehab Date: Sat Nov 2 08:13:02 2013 -0300 media: mxl111sf: Don't use dynamic static allocation commit c98300a0e8cf160aaea60bc05d2cd156a7666173 upstream. Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/usb/dvb-usb-v2/mxl111sf.c:74:1: warning: 'mxl111sf_ctrl_msg' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer to be the max size of a control URB payload data (64 bytes). Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit f98c4b05dc4582055fdb58635d99232e3c6ffc47 Author: Johannes Berg Date: Mon Oct 21 11:33:35 2013 +0200 cfg80211: fix scheduled scan pointer access commit 79845c662eeb95c9a180b9bd0d3ad848ee65b94c upstream. Since rdev->sched_scan_req is dereferenced outside the lock protecting it, this might be done at the wrong time, causing crashes. Move the dereference to where it should be - inside the RTNL locked section. Reviewed-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 7c5f3874d9d697f9e21acbdd8be9e65af6f5a880 Author: Alex Deucher Date: Wed Nov 13 15:25:35 2013 -0500 drm/radeon/vm: don't attempt to update ptes if ib allocation fails commit 4cc948b94a222c310ae089c36718aac7a03aec90 upstream. If we fail to allocate an indirect buffer (ib) when updating the ptes, return an error instead of trying to use the ib. Avoids a null pointer dereference. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=58621 v2 (chk): rebased on drm-fixes-3.12 for stable inclusion Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit a6647e9e4bdd231a008a12302d008a6cd81596bf Author: Tejun Heo Date: Fri Nov 22 17:14:39 2013 -0500 cgroup: use a dedicated workqueue for cgroup destruction commit e5fca243abae1445afbfceebda5f08462ef869d3 upstream. Since be44562613851 ("cgroup: remove synchronize_rcu() from cgroup_diput()"), cgroup destruction path makes use of workqueue. css freeing is performed from a work item from that point on and a later commit, ea15f8ccdb430 ("cgroup: split cgroup destruction into two steps"), moves css offlining to workqueue too. As cgroup destruction isn't depended upon for memory reclaim, the destruction work items were put on the system_wq; unfortunately, some controller may block in the destruction path for considerable duration while holding cgroup_mutex. As large part of destruction path is synchronized through cgroup_mutex, when combined with high rate of cgroup removals, this has potential to fill up system_wq's max_active of 256. Also, it turns out that memcg's css destruction path ends up queueing and waiting for work items on system_wq through work_on_cpu(). If such operation happens while system_wq is fully occupied by cgroup destruction work items, work_on_cpu() can't make forward progress because system_wq is full and other destruction work items on system_wq can't make forward progress because the work item waiting for work_on_cpu() is holding cgroup_mutex, leading to deadlock. This can be fixed by queueing destruction work items on a separate workqueue. This patch creates a dedicated workqueue - cgroup_destroy_wq - for this purpose. As these work items shouldn't have inter-dependencies and mostly serialized by cgroup_mutex anyway, giving high concurrency level doesn't buy anything and the workqueue's @max_active is set to 1 so that destruction work items are executed one by one on each CPU. Hugh Dickins: Because cgroup_init() is run before init_workqueues(), cgroup_destroy_wq can't be allocated from cgroup_init(). Do it from a separate core_initcall(). In the future, we probably want to reorder so that workqueue init happens before cgroup_init(). Signed-off-by: Tejun Heo Reported-by: Hugh Dickins Reported-by: Shawn Bohrer Link: http://lkml.kernel.org/r/20131111220626.GA7509@sbohrermbp13-local.rgmadvisors.com Link: http://lkml.kernel.org/g/alpine.LNX.2.00.1310301606080.2333@eggly.anvils Cc: stable@vger.kernel.org # v3.9+ Signed-off-by: Greg Kroah-Hartman commit 52915b499962c637289f1ac04cc0858e690bbfe4 Author: Linus Walleij Date: Wed Nov 27 08:47:02 2013 +0100 gpio: pl061: move irqdomain initialization commit 2ba3154d9cb13697b97723cce75633b48adfe826 upstream. The PL061 driver had the irqdomain initialization in an unfortunate place: when used with device tree (and thus passing the base IRQ 0) the driver would work, as this registers an irqdomain and waits for mappings to be done dynamically as the devices request their IRQs, whereas when booting using platform data the irqdomain core would attempt to allocate IRQ descriptors dynamically (which works fine) but also to associate the irq_domain_associate_many() on all IRQs, which in turn will call the mapping function which at this point will try to set the type of the IRQ and then tries to acquire a non-initialized spinlock yielding a backtrace like this: CPU: 0 PID: 1 Comm: swapper Not tainted 3.13.0-rc1+ #652 Backtrace: [] (dump_backtrace) from [] (show_stack+0x18/0x1c) r6:c798ace0 r5:00000000 r4:c78257e0 r3:00200140 [] (show_stack) from [] (dump_stack+0x20/0x28) [] (dump_stack) from [] (__lock_acquire+0x1c0/0x1b80) [] (__lock_acquire) from [] (lock_acquire+0x6c/0x80) r10:00000000 r9:c0455234 r8:00000060 r7:c047d798 r6:600000d3 r5:00000000 r4:c782c000 [] (lock_acquire) from [] (_raw_spin_lock_irqsave+0x60/0x74) r6:c01a1100 r5:800000d3 r4:c798acd0 [] (_raw_spin_lock_irqsave) from [] (pl061_irq_type+0x28/0x) r6:00000000 r5:00000000 r4:c798acd0 [] (pl061_irq_type) from [] (__irq_set_trigger+0x70/0x104) r6:00000000 r5:c01a10d8 r4:c046da1c r3:c01a10d8 [] (__irq_set_trigger) from [] (irq_set_irq_type+0x40/0x60) r10:c043240c r8:00000060 r7:00000000 r6:c046da1c r5:00000060 r4:00000000 [] (irq_set_irq_type) from [] (pl061_irq_map+0x40/0x54) r6:c79693c0 r5:c798acd0 r4:00000060 [] (pl061_irq_map) from [] (irq_domain_associate+0xc0/0x190) r5:00000060 r4:c046da1c [] (irq_domain_associate) from [] (irq_domain_associate_man) r8:00000008 r7:00000000 r6:c79693c0 r5:00000060 r4:00000000 [] (irq_domain_associate_many) from [] (irq_domain_add_simp) r8:c046578c r7:c035b72c r6:c79693c0 r5:00000060 r4:00000008 r3:00000008 [] (irq_domain_add_simple) from [] (pl061_probe+0xc4/0x22c) r6:00000060 r5:c0464380 r4:c798acd0 [] (pl061_probe) from [] (amba_probe+0x74/0xe0) r10:c043240c r9:c0455234 r8:00000000 r7:c047d7f8 r6:c047d744 r5:00000000 r4:c0464380 This moves the irqdomain initialization to a point where the spinlock and GPIO chip are both fully propulated, so the callbacks can be used without crashes. I had some problem reproducing the crash, as the devm_kzalloc():ed zeroed memory would seemingly mask the spinlock as something OK, but by poisoning the lock like this: u32 *dum; dum = (u32 *) &chip->lock; *dum = 0xaaaaaaaaU; I could reproduce, fix and test the patch. Reported-by: Russell King Cc: Rob Herring Cc: Haojian Zhuang Cc: Baruch Siach Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit d53217196e679ed97e85f86f75800def863beb08 Author: Simon Wood Date: Thu Oct 10 08:20:12 2013 -0600 HID: lg: fix ReportDescriptor for Logitech Formula Vibration commit 7f50547059bd55ac6a98c29fd1989421bdc36ec9 upstream. By default the Logitech Formula Vibration presents a combined accel/brake axis ('Y'). This patch modifies the HID descriptor to present seperate accel/brake axes ('Y' and 'Z'). Signed-off-by: Simon Wood Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 43f0ba99fcd871a936df8c25b438759708884df8 Author: Simon Wood Date: Wed Nov 6 12:30:43 2013 -0700 HID:hid-lg4ff: Initialize device properties before we touch autocentering. commit 114a55cf9dd1576e7ac56189832cd4d7dc56c218 upstream. Re-arrange code slightly to ensure that device properties are configured before calling auto-center command. Reported-by: Michal Malý Signed-off-by: Simon Wood Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit b806304bde504aff3b74f9a75e579b7170b5d65a Author: Simon Wood Date: Wed Nov 6 12:30:41 2013 -0700 HID:hid-lg4ff: Switch autocentering off when strength is set to zero. commit d2c02da549b468bbb28e67d269bd3c9e10683ff5 upstream. When the autocenter is set to zero, this patch issues a command to totally disable the autocenter - this results in less resistance in the wheel. Reported-by: Elias Vanderstuyft Signed-off-by: Simon Wood Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 236b365b1a65da3f18d1eda848418421c1601396 Author: Simon Wood Date: Wed Nov 6 12:30:40 2013 -0700 HID:hid-lg4ff: Scale autocentering force properly on Logitech wheel commit f8c231569a7a455dfa1907294a46ba52b3aa8859 upstream. Adjust the scaling and lineartity to match that of the Windows driver (from MOMO testing). Reported-by: Elias Vanderstuyft Signed-off-by: Simon Wood Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 7d366a5ec599406ca43fd4b967d0a81307c3bce4 Author: KaiChung Cheng Date: Thu Nov 21 10:04:30 2013 +0100 HID: multicouh: add PID VID to support 1 new Wistron optical touch device commit bf9d121efc18c30caa2caad85358cf9408eca117 upstream. This patch adds PID VID to support for the Wistron Inc. Optical touch panel. Signed-off-by: KaiChung Cheng Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 505014c1880ece595f7ac118c10efc432213bf58 Author: Srinivas Pandruvada Date: Sat Oct 26 10:04:09 2013 -0700 HID: hid-sensor-hub: fix report size commit d4b1bba76171cb783e32441b28462fe841073ed8 upstream. Most of the hid sensor field size is reported in report_size field in the report descriptor. For rotation fusion sensor the quaternion data is 16 byte field, the report size was set to 4 and report count field is set to 4. So the total size is 16 bytes. But the current driver has a bug and not taking account for report count field. This causes user space to see only 4 bytes of data sent via IIO interface. The number of bytes in a field needs to take account of report_count field. Need to multiply report_size and report_count to get total number of bytes. Signed-off-by: Srinivas Pandruvada Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit a7a6904f5f39e7aeb3740415900020346e0a9f01 Author: Forest Bond Date: Mon Oct 21 12:38:49 2013 -0400 HID: hid-multitouch: add support for SiS panels commit a6802e008e19845fd9669511b895f7515ef9c48b upstream. Add support for SiS multitouch panels. Signed-off-by: Forest Bond Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 82a645a3ecd757206d4d6be182d7e47d50a7dd4c Author: Elias Vanderstuyft Date: Mon Oct 7 19:48:12 2013 +0300 HID: logitech - lg2ff: Add IDs for Formula Vibration Feedback Wheel commit bd04363d3990c0727b7512a79a08c68436878bb0 upstream. Add USB IDs for Logitech Formula Vibration Feedback Wheel (046d:ca04). The lg2ff force feedback subdriver is used for vibration and HID_GD_MULTIAXIS is set to avoid deadzone like other Logitech wheels. Kconfig description etc are also updated accordingly. Signed-off-by: Elias Vanderstuyft [anssi.hannula@iki.fi: added description and CCs] Signed-off-by: Anssi Hannula Signed-off-by: Simon Wood Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit be8c7f057c6c9257956eb796b58500c5c4f939c3 Author: Luosong Date: Wed Oct 2 11:20:00 2013 +0200 HID: multitouch: Fix GeneralTouch products and add more PIDs commit 7b2262920db2b98fe2cd32cde52141f02fd9eecf upstream. GeneralTouch products should use the quirk SLOT_IS_CONTACTID instead of SLOT_IS_CONTACTNUMBER. Adding PIDs 0101,e100,0102,0106,010a from the new products. Tested on new and older products by GeneralTouch engineers. Signed-off-by: Luosong Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 7e7ea1bd73f1307df3d375f2df4fa0d6783510de Author: Michael Marineau Date: Sun Aug 11 00:53:45 2013 -0400 9p: send uevent after adding/removing mount_tag attribute commit e0d6cb9cd3a3ac8a3b8e5b22b83c4f8619786f22 upstream. This driver adds an attribute to the existing virtio device so a CHANGE event is required in order udev rules to make use of it. The ADD event happens before this driver is probed and unlike a more typical driver like a block device there isn't a higher level device to watch for. Signed-off-by: Michael Marineau Signed-off-by: Eric Van Hensbergen Signed-off-by: Greg Kroah-Hartman commit 0e6a2932d63564f8f5eb81c9fbe22ba1ba8d19df Author: Simon Guinot Date: Thu Oct 3 12:05:02 2013 +0200 clk: armada-370: fix tclk frequencies commit 1022c75f5abd3a3b25e679bc8793d21bedd009b4 upstream. This patch fixes the tclk frequency array for the Armada-370 SoC. This bug has been introduced by commit 6b72333d ("clk: mvebu: add Armada 370 SoC-centric clock init"). A wrong tclk frequency affects the following drivers: mvsdio, mvneta, i2c-mv64xxx and mvebu-devbus. This list may be incomplete. About the mvneta Ethernet driver, note that the tclk frequency is used to compute the Rx time coalescence. Then, this bug harms the coalescence configuration and also degrades the networking performances with the default values. Signed-off-by: Simon Guinot Cc: Andrew Lunn Cc: Gregory CLEMENT Cc: Sebastian Hesselbarth Acked-by: Jason Cooper Signed-off-by: Michael Turquette Signed-off-by: Greg Kroah-Hartman commit 16802f7ac3a42b6e97af4e9b203adfa7bbb25994 Author: Mark Langsdorf Date: Tue Oct 1 10:30:24 2013 -0500 cpufreq: highbank-cpufreq: Enable Midway/ECX-2000 commit fbbc5bfb44a22e7a8ef753a1c8dfb448d7ac8b85 upstream. Calxeda's new ECX-2000 part uses the same cpufreq interface as highbank, so add it to the driver's compatibility list. This is a minor change that can safely be applied to the 3.10 and 3.11 stable trees. Signed-off-by: Mark Langsdorf Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit c2dd82b43dcc08aad0e139e23509efb195ad6fc1 Author: Forest Bond Date: Mon Oct 21 12:38:18 2013 -0400 Input: usbtouchscreen: ignore eGalax/D-Wav/EETI HIDs commit ae2aa3a512fa5f50f67feba9e66bc2efb394bd63 upstream. The HID driver now handles these devices, regardless of what protocol the device claims it supports. Signed-off-by: Forest Bond Acked-by: Dmitry Torokhov Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 59f466a632b8502d2fb35b2cd119a061f8922021 Author: Forest Bond Date: Mon Oct 21 12:38:02 2013 -0400 HID: don't ignore eGalax/D-Wav/EETI HIDs commit 95d50b6c5e18ff7351c5f2a6ff53afaed5f7e664 upstream. Certain devices with class HID, protocol None did not work with the HID driver at one point, and as a result were bound to usbtouchscreen instead as of commit 139ebe8 ("Input: usbtouchscreen - fix eGalax HID ignoring"). This change was prompted by the following report: https://lkml.org/lkml/2009/1/25/127 Unfortunately, the device mentioned in this report is no longer available for testing. We've recently discovered that some devices with class HID, protocol None do not work with usbtouchscreen, but do work with usbhid. Here is the report that made this evident: http://comments.gmane.org/gmane.linux.kernel.input/31710 Driver binding for these devices has flip-flopped a few times, so both of the above reports were regressions. This situation would appear to leave us with no easy way to bind every device to the right driver. However, in my own testing with several devices I have not found a device with class HID that does not work with the current HID driver. It is my belief that changes to the HID driver since the original report have likely fixed the issue(s) that made it unsuitable at the time, and that we should prefer it over usbtouchscreen for these devices. In particular, HID quirks affecting these devices were added/removed in the following commits since then: fe6065d HID: add multi-input quirk for eGalax Touchcontroller 77933c3 Merge branch 'egalax' into for-linus ebd11fe HID: Add quirk for eGalax touch controler. d34c4aa HID: add no-get quirk for eGalax touch controller This patch makes the HID driver no longer ignore eGalax/D-Wav/EETI devices with class HID. If there are in fact devices with class HID that still do not work with the HID driver, we will see another round of regressions. In that case I propose we investigate why the device is not working with the HID driver rather than re-introduce regressions for functioning HID devices by again binding them to usbtouchscreen. The corresponding change to usbtouchscreen will be made separately. Signed-off-by: Forest Bond Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit d84c1fcb5bdb1ac919fe7262505306a2ca1a6281 Author: Tom Gundersen Date: Thu Oct 31 00:33:54 2013 -0700 Input: i8042 - add PNP modaliases commit 78551277e4df57864b0b0e7f85c23ede2be2edb8 upstream. This allows the module to be autoloaded in the common case. In order to work on non-PnP systems the module should be compiled in or loaded unconditionally at boot (c.f. modules-load.d(5)), as before. Signed-off-by: Tom Gundersen Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 5b1c45c29961824f123ae8ed1020db2bd8d072ba Author: Joseph Salisbury Date: Wed Oct 16 09:19:40 2013 -0700 Input: cypress_ps2 - do not consider data bad if palm is detected commit 5df682b297f6b23ec35615ed7bb50cbb25d25869 upstream. If hardware (or firmware) detects palm on the surface of the device it does not mean that the data packet is bad from the protocol standpoint. Instead of reporting PSMOUSE_BAD_DATA in this case simply threat it as if nothing touches the surface. BugLink: http://bugs.launchpad.net/bugs/1229361 Signed-off-by: Joseph Salisbury Tested-by: Kamal Mostafa Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit cb8e5e98aeae9e0d845576f6f59227c9ad8f76ff Author: Daniel Stone Date: Thu Oct 31 00:25:34 2013 -0700 Input: evdev - fall back to vmalloc for client event buffer commit 92eb77d0ffbaa71b501a0a8dabf09a351bf4267f upstream. evdev always tries to allocate the event buffer for clients using kzalloc rather than vmalloc, presumably to avoid mapping overhead where possible. However, drivers like bcm5974, which claims support for reporting 16 fingers simultaneously, can have an extraordinarily large buffer. The resultant contiguous order-4 allocation attempt fails due to fragmentation, and the device is thus unusable until reboot. Try kzalloc if we can to avoid the mapping overhead, but if that fails, fall back to vzalloc. Signed-off-by: Daniel Stone Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 1bfdf02fc01d8b4c96cd536ee9e2552268e67784 Author: Steven Rostedt (Red Hat) Date: Tue Nov 26 09:22:54 2013 -0500 tracing: Allow events to have NULL strings commit 4e58e54754dc1fec21c3a9e824bc108b05fdf46e upstream. If an TRACE_EVENT() uses __assign_str() or __get_str on a NULL pointer then the following oops will happen: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] strlen+0x10/0x1a *pde = 00000000 ^M Oops: 0000 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.13.0-rc1-test+ #2 Hardware name: /DG965MQ, BIOS MQ96510J.86A.0372.2006.0605.1717 06/05/2006^M task: f5cde9f0 ti: f5e5e000 task.ti: f5e5e000 EIP: 0060:[] EFLAGS: 00210046 CPU: 1 EIP is at strlen+0x10/0x1a EAX: 00000000 EBX: c2472da8 ECX: ffffffff EDX: c2472da8 ESI: c1c5e5fc EDI: 00000000 EBP: f5e5fe84 ESP: f5e5fe80 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 CR0: 8005003b CR2: 00000000 CR3: 01f32000 CR4: 000007d0 Stack: f5f18b90 f5e5feb8 c10687a8 0759004f 00000005 00000005 00000005 00200046 00000002 00000000 c1082a93 f56c7e28 c2472da8 c1082a93 f5e5fee4 c106bc61^M 00000000 c1082a93 00000000 00000000 00000001 00200046 00200082 00000000 Call Trace: [] ftrace_raw_event_lock+0x39/0xc0 [] ? ktime_get+0x29/0x69 [] ? ktime_get+0x29/0x69 [] lock_release+0x57/0x1a5 [] ? ktime_get+0x29/0x69 [] read_seqcount_begin.constprop.7+0x4d/0x75 [] ? ktime_get+0x29/0x69^M [] ktime_get+0x29/0x69 [] __tick_nohz_idle_enter+0x1e/0x426 [] ? lock_release_holdtime.part.19+0x48/0x4d [] ? time_hardirqs_off+0xe/0x28 [] ? trace_hardirqs_off_caller+0x3f/0xaf [] tick_nohz_idle_enter+0x59/0x62 [] cpu_startup_entry+0x64/0x192 [] start_secondary+0x277/0x27c Code: 90 89 c6 89 d0 88 c4 ac 38 e0 74 09 84 c0 75 f7 be 01 00 00 00 89 f0 48 5e 5d c3 55 89 e5 57 66 66 66 66 90 83 c9 ff 89 c7 31 c0 ae f7 d1 8d 41 ff 5f 5d c3 55 89 e5 57 66 66 66 66 90 31 ff EIP: [] strlen+0x10/0x1a SS:ESP 0068:f5e5fe80 CR2: 0000000000000000 ---[ end trace 01bc47bf519ec1b2 ]--- New tracepoints have been added that have allowed for NULL pointers being assigned to strings. To fix this, change the TRACE_EVENT() code to check for NULL and if it is, it will assign "(null)" to it instead (similar to what glibc printf does). Reported-by: Shuah Khan Reported-by: Jovi Zhangwei Link: http://lkml.kernel.org/r/CAGdX0WFeEuy+DtpsJzyzn0343qEEjLX97+o1VREFkUEhndC+5Q@mail.gmail.com Link: http://lkml.kernel.org/r/528D6972.9010702@samsung.com Fixes: 9cbf117662e2 ("tracing/events: provide string with undefined size support") Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit fe070ad95a7f94a658273f5f359a6875ad3cd38c Author: Takashi Iwai Date: Thu Nov 28 11:05:28 2013 +0100 ALSA: hda - Check leaf nodes to find aamix amps commit 2ded3e5b61d61d0bc90bebb8004db6184c7db6eb upstream. The current generic parser assumes blindly that the volume and mute amps are found in the aamix node itself. But on some codecs, typically Analog Devices ones, the aamix amps are separately implemented in each leaf node of the aamix node, and the current driver can't establish the correct amp controls. This is a regression compared with the previous static quirks. This patch extends the search for the amps to the leaf nodes for allowing the aamix controls again on such codecs. In this implementation, I didn't code to loop through the whole paths, since usually one depth should suffice, and we can't search too deeply, as it may result in the conflicting control assignments. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=65641 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7f9bf8ad0ea7457c6f3d5c6b04fe6c7b99fec63d Author: Takashi Iwai Date: Thu Nov 28 15:21:21 2013 +0100 ALSA: hda - Initialize missing bass speaker pin for ASUS AIO ET2700 commit 1f0bbf03cb829162ec8e6d03c98aaaed88c6f534 upstream. Add a fixup entry for the missing bass speaker pin 0x16 on ASUS ET2700 AiO desktop. The channel map will be added in the next patch, so that this can be backported easily to stable kernels. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=65961 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 41d7a448d028d328ce608b9207172a64ece4a005 Author: Takashi Iwai Date: Tue Nov 26 08:33:45 2013 +0100 ALSA: hda - Create Headhpone Mic Jack Mode when really needed commit ced4cefc75fdb8be95eaee325ad0f6b2fc0a484b upstream. When a headphone jack is configurable as input, the generic parser tries to make it retaskable as Headphone Mic. The switching can be done smoothly if Capture Source control exists (i.e. there is another input source). Or when user explicitly enables the creation of jack mode controls, "Headhpone Mic Jack Mode" will be created accordingly. However, if the headphone mic is the only input source, we have to create "Headphone Mic Jack Mode" control because there is no capture source selection. Otherwise, the generic parser assumes that the input is constantly enabled, thus the headphone is permanently set as input. This situation happens on the old MacBook Airs where no input is supported properly, for example. This patch fixes the problem: now "Headphone Mic Jack Mode" is created when such an input selection isn't possible. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=65681 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5fb0e7deb22f290a47686898a01fb39a581f9970 Author: Takashi Iwai Date: Tue Nov 26 08:44:26 2013 +0100 ALSA: hda - Fix hp-mic mode without VREF bits commit 16c0cefe8951b2c4b824fd06011ac1b359b1ab3b upstream. When the hp mic pin has no VREF bits, the driver forgot to set PIN_IN bit. Spotted during debugging old MacBook Airs. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=65681 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit eda7913868a57fe6047459290b59d66007f99053 Author: Kailang Yang Date: Tue Nov 26 15:17:50 2013 +0800 ALSA: hda/realtek - Add support of ALC231 codec commit ba4c4d0a9021ab034554d532a98133d668b87599 upstream. It's compatible with ALC269. Signed-off-by: Kailang Yang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e1a8b1a389031976d9e40c93662beff169a10d06 Author: Kailang Yang Date: Tue Nov 26 15:41:40 2013 +0800 ALSA: hda/realtek - Set pcbeep amp for ALC668 commit 9ad54547cf6f4410eba83bb95dfd2a0966718d6d upstream. Set the missing pcbeep default amp for ALC668. Signed-off-by: Kailang Yang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ddff5adaf7ec9d2591718b04074605914f9987cd Author: Peter Zijlstra Date: Tue Nov 26 15:03:41 2013 +0100 cpuset: Fix memory allocator deadlock commit 0fc0287c9ed1ffd3706f8b4d9b314aa102ef1245 upstream. Juri hit the below lockdep report: [ 4.303391] ====================================================== [ 4.303392] [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ] [ 4.303394] 3.12.0-dl-peterz+ #144 Not tainted [ 4.303395] ------------------------------------------------------ [ 4.303397] kworker/u4:3/689 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 4.303399] (&p->mems_allowed_seq){+.+...}, at: [] new_slab+0x6c/0x290 [ 4.303417] [ 4.303417] and this task is already holding: [ 4.303418] (&(&q->__queue_lock)->rlock){..-...}, at: [] blk_execute_rq_nowait+0x5b/0x100 [ 4.303431] which would create a new lock dependency: [ 4.303432] (&(&q->__queue_lock)->rlock){..-...} -> (&p->mems_allowed_seq){+.+...} [ 4.303436] [ 4.303898] the dependencies between the lock to be acquired and SOFTIRQ-irq-unsafe lock: [ 4.303918] -> (&p->mems_allowed_seq){+.+...} ops: 2762 { [ 4.303922] HARDIRQ-ON-W at: [ 4.303923] [] __lock_acquire+0x65a/0x1ff0 [ 4.303926] [] lock_acquire+0x93/0x140 [ 4.303929] [] kthreadd+0x86/0x180 [ 4.303931] [] ret_from_fork+0x7c/0xb0 [ 4.303933] SOFTIRQ-ON-W at: [ 4.303933] [] __lock_acquire+0x68c/0x1ff0 [ 4.303935] [] lock_acquire+0x93/0x140 [ 4.303940] [] kthreadd+0x86/0x180 [ 4.303955] [] ret_from_fork+0x7c/0xb0 [ 4.303959] INITIAL USE at: [ 4.303960] [] __lock_acquire+0x344/0x1ff0 [ 4.303963] [] lock_acquire+0x93/0x140 [ 4.303966] [] kthreadd+0x86/0x180 [ 4.303969] [] ret_from_fork+0x7c/0xb0 [ 4.303972] } Which reports that we take mems_allowed_seq with interrupts enabled. A little digging found that this can only be from cpuset_change_task_nodemask(). This is an actual deadlock because an interrupt doing an allocation will hit get_mems_allowed()->...->__read_seqcount_begin(), which will spin forever waiting for the write side to complete. Cc: John Stultz Cc: Mel Gorman Reported-by: Juri Lelli Signed-off-by: Peter Zijlstra Tested-by: Juri Lelli Acked-by: Li Zefan Acked-by: Mel Gorman Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit ced4ac92852e8f17fabcbed7492ba459619640aa Author: Tejun Heo Date: Thu Sep 5 12:30:04 2013 -0400 workqueue: fix ordered workqueues in NUMA setups commit 8a2b75384444488fc4f2cbb9f0921b6a0794838f upstream. An ordered workqueue implements execution ordering by using single pool_workqueue with max_active == 1. On a given pool_workqueue, work items are processed in FIFO order and limiting max_active to 1 enforces the queued work items to be processed one by one. Unfortunately, 4c16bd327c ("workqueue: implement NUMA affinity for unbound workqueues") accidentally broke this guarantee by applying NUMA affinity to ordered workqueues too. On NUMA setups, an ordered workqueue would end up with separate pool_workqueues for different nodes. Each pool_workqueue still limits max_active to 1 but multiple work items may be executed concurrently and out of order depending on which node they are queued to. Fix it by using dedicated ordered_wq_attrs[] when creating ordered workqueues. The new attrs match the unbound ones except that no_numa is always set thus forcing all NUMA nodes to share the default pool_workqueue. While at it, add sanity check in workqueue creation path which verifies that an ordered workqueues has only the default pool_workqueue. Signed-off-by: Tejun Heo Reported-by: Libin Cc: Lai Jiangshan Signed-off-by: Greg Kroah-Hartman commit 3df594a7ac9a732413ecaad15682945715df4443 Author: Heiko Carstens Date: Thu Nov 21 16:22:17 2013 +0100 s390/uaccess: add missing page table walk range check commit 71a86ef055f569b93bc6901f007bdf447dbf515f upstream. When translating a user space address, the address must be checked against the ASCE limit of the process. If the address is larger than the maximum address that is reachable with the ASCE, an ASCE type exception must be generated. The current code simply ignored the higher order bits. This resulted in an address wrap around in user space instead of an exception in user space. Reviewed-by: Gerald Schaefer Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 1a2d670b28befe626d50a39af579da44ecd22245 Author: Frank Zago Date: Wed Nov 13 22:53:00 2013 +0000 iio:accel:kxsd9 fix missing mutex unlock commit 0ee005c7dc2803125275e24598f0fb37775a6af3 upstream. This will leave a lock held after reading from the device, preventing any further reads. Signed-off-by: Frank Zago Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 8e7314052be20d6a00bc524648a2a8daf7139d46 Author: Michael Neuling Date: Mon Nov 25 11:12:20 2013 +1100 powerpc/signals: Improved mark VSX not saved with small contexts fix commit ec67ad82814bee92251fd963bf01c7a173856555 upstream. In a recent patch: commit c13f20ac48328b05cd3b8c19e31ed6c132b44b42 Author: Michael Neuling powerpc/signals: Mark VSX not saved with small contexts We fixed an issue but an improved solution was later discussed after the patch was merged. Firstly, this patch doesn't handle the 64bit signals case, which could also hit this issue (but has never been reported). Secondly, the original patch isn't clear what MSR VSX should be set to. The new approach below always clears the MSR VSX bit (to indicate no VSX is in the context) and sets it only in the specific case where VSX is available (ie. when VSX has been used and the signal context passed has space to provide the state). This reverts the original patch and replaces it with the improved solution. It also adds a 64 bit version. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 5b80fd00af8b03e0b03ec52aec90485525eb2e73 Author: David Herrmann Date: Tue Nov 26 13:58:18 2013 +0100 HID: uhid: fix leak for 64/32 UHID_CREATE commit 80897aa787ecd58eabb29deab7cbec9249c9b7e6 upstream. UHID allows short writes so user-space can omit unused fields. We automatically set them to 0 in the kernel. However, the 64/32 bit compat-handler didn't do that in the UHID_CREATE fallback. This will reveal random kernel heap data (of random size, even) to user-space. Fixes: befde0226a59 ('HID: uhid: make creating devices work on 64/32 systems') Reported-by: Ben Hutchings Signed-off-by: David Herrmann Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 8e43aac1ec86b5955ecf396395f6fd8b4be42157 Author: NeilBrown Date: Thu Nov 14 15:16:15 2013 +1100 md: fix calculation of stacking limits on level change. commit 02e5f5c0a0f726e66e3d8506ea1691e344277969 upstream. The various ->run routines of md personalities assume that the 'queue' has been initialised by the blk_set_stacking_limits() call in md_alloc(). However when the level is changed (by level_store()) the ->run routine for the new level is called for an array which has already had the stacking limits modified. This can result in incorrect final settings. So call blk_set_stacking_limits() before ->run in level_store(). A specific consequence of this bug is that it causes discard_granularity to be set incorrectly when reshaping a RAID4 to a RAID0. This is suitable for any -stable kernel since 3.3 in which blk_set_stacking_limits() was introduced. Reported-and-tested-by: "Baldysiak, Pawel" Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 9d41513cef9d3e3083a0cb83216b88074492f461 Author: Steve French Date: Fri Nov 15 20:41:32 2013 -0600 setfacl removes part of ACL when setting POSIX ACLs to Samba commit b1d93356427be6f050dc55c86eb019d173700af6 upstream. setfacl over cifs mounts can remove the default ACL when setting the (non-default part of) the ACL and vice versa (we were leaving at 0 rather than setting to -1 the count field for the unaffected half of the ACL. For example notice the setfacl removed the default ACL in this sequence: steven@steven-GA-970A-DS3:~/cifs-2.6$ getfacl /mnt/test-dir ; setfacl -m default:user:test:rwx,user:test:rwx /mnt/test-dir getfacl: Removing leading '/' from absolute path names user::rwx group::r-x other::r-x default:user::rwx default:user:test:rwx default:group::r-x default:mask::rwx default:other::r-x steven@steven-GA-970A-DS3:~/cifs-2.6$ getfacl /mnt/test-dir getfacl: Removing leading '/' from absolute path names user::rwx user:test:rwx group::r-x mask::rwx other::r-x Signed-off-by: Steve French Acked-by: Jeremy Allison Signed-off-by: Greg Kroah-Hartman commit 57a5b135c2fd42bfcab2fa4b25395234038e4a16 Author: Robert Richter Date: Thu Oct 10 18:23:38 2013 +0200 edac, highbank: Fix interrupt setup of mem and l2 controller commit a72b8859fd3941cc1d2940d5c43026d2c6fb959e upstream. Register and enable interrupts after the edac registration. Otherwise incomming ecc error interrupts lead to crashes during device setup. Fixing this in drivers for mc and l2. Signed-off-by: Robert Richter Acked-by: Rob Herring Signed-off-by: Robert Richter Signed-off-by: Greg Kroah-Hartman commit 65007af07bb8c82207a7b2d2428773b28a3d614e Author: Jerome Glisse Date: Tue Nov 12 10:51:16 2013 -0500 radeon: workaround pinning failure on low ram gpu commit 97b6ff6be9da7675aab339334fda996d6c5077d9 upstream. GPU with low amount of ram can fails at pinning new framebuffer before unpinning old one. On such failure, retry with unpinning old one before pinning new one allowing to work around the issue. This is somewhat ugly but only affect those old GPU we care about. Signed-off-by: Jerome Glisse Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit ed540279a8af2c4005430303f74df05ca5576879 Author: Alex Deucher Date: Thu Oct 31 16:43:27 2013 -0400 drm/radeon: don't share PPLLs on DCE4.1 commit 70471860ff9f335c60c004d42ebd48945bfa5403 upstream. Sharing PPLLs seems to cause problems on some boards. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=45334 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 08ab0aac9ec2d6c07acb6bd96f3e9e872b3dfbaf Author: Christian König Date: Wed Oct 30 12:56:04 2013 +0100 drm/radeon: activate UVD clocks before sending the destroy msg commit c154a76311293f9671439286834aa325b7ef59fe upstream. Make sure the UVD clocks are still active before sending the destroy message, otherwise the hw might hang. Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 48527487543e8290ae7127b27cce5dd7d9df567f Author: Alex Deucher Date: Mon Oct 28 10:56:23 2013 -0400 drm/radeon/si: fix define for MC_SEQ_TRAIN_WAKEUP_CNTL commit d5693761b2b4ff530c8af8af9ec55b6eae76e617 upstream. Typo in the register offset. Noticed-by: Sylvain BERTRAND Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 31278c7029bfeb279e367a437ddeeb45307321a7 Author: Ben Skeggs Date: Wed Nov 13 15:18:32 2013 +1000 drm/nouveau: when bailing out of a pushbuf ioctl, do not remove previous fence commit 9360bd1112d8874d21942e2ae74f5416b00a8db6 upstream. Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 0c405f5ffe3415927a937fec905393cae640e24e Author: Daniel Vetter Date: Mon Nov 4 08:13:45 2013 +0100 drm/i915: flush cursors harder commit b2ea8ef559b4d94190009f3651b5b3ab7c05afd3 upstream. Apparently they need the same treatment as primary planes. This fixes modesetting failures because of stuck cursors (!) on Thomas' i830M machine. I've figured while at it I'll also roll it out for the ivb 3 pipe version of this function. I didn't do this for i845/i865 since Bspec says the update mechanism works differently, and there's some additional rules about what can be updated in which order. Tested-by: Thomas Richter Cc: Thomas Richter Cc: Ville Syrjälä Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 6c3c00e3f509af95f7ca80492311a3ce485528e2 Author: Thomas Hellstrom Date: Wed Oct 30 03:29:50 2013 -0700 drm/ttm: Fix ttm_bo_move_memcpy commit da95c788ef0c645378ffccb7060a0df1a33aee38 upstream. All error paths will want to keep the mm node, so handle this at the function exit. This fixes an ioremap failure error path. Also add some comments to make the function a bit easier to understand. Signed-off-by: Thomas Hellstrom Reviewed-by: Jakob Bornecrantz Signed-off-by: Greg Kroah-Hartman commit f692d2d8bebddeb8c8faedfc41e4732f3dc23e5b Author: Jakob Bornecrantz Date: Wed Oct 30 02:46:56 2013 -0700 drm/ttm: Handle in-memory region copies commit 9a0599ddeae012a771bba5e23393fc52d8a59d89 upstream. Fix the case where the ttm pointer may be NULL causing a NULL pointer dereference. Signed-off-by: Jakob Bornecrantz Signed-off-by: Thomas Hellström Signed-off-by: Greg Kroah-Hartman commit 4f94b6e4b43ca3a1027803bd3cab21e72bbb991e Author: Thomas Hellstrom Date: Mon Oct 28 02:02:19 2013 -0700 drm/ttm: Fix memory type compatibility check commit 59c8e66378fb78adbcd05f0d09783dde6fef282b upstream. Also check the busy placements before deciding to move a buffer object. Failing to do this may result in a completely unneccessary move within a single memory type. Signed-off-by: Thomas Hellstrom Reviewed-by: Jakob Bornecrantz Signed-off-by: Greg Kroah-Hartman commit 2940c25bec92f40a3f7f32504b8ea115d1701892 Author: Steven Rostedt (Red Hat) Date: Mon Nov 25 20:59:46 2013 -0500 ftrace: Fix function graph with loading of modules commit 8a56d7761d2d041ae5e8215d20b4167d8aa93f51 upstream. Commit 8c4f3c3fa9681 "ftrace: Check module functions being traced on reload" fixed module loading and unloading with respect to function tracing, but it missed the function graph tracer. If you perform the following # cd /sys/kernel/debug/tracing # echo function_graph > current_tracer # modprobe nfsd # echo nop > current_tracer You'll get the following oops message: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 2910 at /linux.git/kernel/trace/ftrace.c:1640 __ftrace_hash_rec_update.part.35+0x168/0x1b9() Modules linked in: nfsd exportfs nfs_acl lockd ipt_MASQUERADE sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables uinput snd_hda_codec_idt CPU: 2 PID: 2910 Comm: bash Not tainted 3.13.0-rc1-test #7 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007 0000000000000668 ffff8800787efcf8 ffffffff814fe193 ffff88007d500000 0000000000000000 ffff8800787efd38 ffffffff8103b80a 0000000000000668 ffffffff810b2b9a ffffffff81a48370 0000000000000001 ffff880037aea000 Call Trace: [] dump_stack+0x4f/0x7c [] warn_slowpath_common+0x81/0x9b [] ? __ftrace_hash_rec_update.part.35+0x168/0x1b9 [] warn_slowpath_null+0x1a/0x1c [] __ftrace_hash_rec_update.part.35+0x168/0x1b9 [] ? __mutex_lock_slowpath+0x364/0x364 [] ftrace_shutdown+0xd7/0x12b [] unregister_ftrace_graph+0x49/0x78 [] graph_trace_reset+0xe/0x10 [] tracing_set_tracer+0xa7/0x26a [] tracing_set_trace_write+0x8b/0xbd [] ? ftrace_return_to_handler+0xb2/0xde [] ? __sb_end_write+0x5e/0x5e [] vfs_write+0xab/0xf6 [] ftrace_graph_caller+0x85/0x85 [] SyS_write+0x59/0x82 [] ftrace_graph_caller+0x85/0x85 [] system_call_fastpath+0x16/0x1b ---[ end trace 940358030751eafb ]--- The above mentioned commit didn't go far enough. Well, it covered the function tracer by adding checks in __register_ftrace_function(). The problem is that the function graph tracer circumvents that (for a slight efficiency gain when function graph trace is running with a function tracer. The gain was not worth this). The problem came with ftrace_startup() which should always be called after __register_ftrace_function(), if you want this bug to be completely fixed. Anyway, this solution moves __register_ftrace_function() inside of ftrace_startup() and removes the need to call them both. Reported-by: Dave Wysochanski Fixes: ed926f9b35cd ("ftrace: Use counters to enable functions to trace") Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit ad03714db9cd8085abbf03891db70daf3cfdcb8b Author: Dan Williams Date: Fri Nov 8 13:39:44 2013 -0600 prism54: set netdev type to "wlan" commit 8e3ffa471091c560deb6738ed9ab7445b7a5fd04 upstream. Userspace uses the netdev devtype for stuff like device naming and type detection. Be nice and set it. Remove the pointless #if/#endif around SET_NETDEV_DEV too. Signed-off-by: Dan Williams Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 378c1677f76df7f3b9c65cdd839a18e922d389d7 Author: Andreas Bießmann Date: Thu Oct 24 12:31:04 2013 +0200 avr32: fix out-of-range jump in large kernels commit d617b338bbfdd77e9cbd8e7dc949cee3dd73d575 upstream. This patch fixes following error (for big kernels): ---8<--- arch/avr32/boot/u-boot/head.o: In function `no_tag_table': (.init.text+0x44): relocation truncated to fit: R_AVR32_22H_PCREL against symbol `panic' defined in .text.unlikely section in kernel/built-in.o arch/avr32/kernel/built-in.o: In function `bad_return': (.ex.text+0x236): relocation truncated to fit: R_AVR32_22H_PCREL against symbol `panic' defined in .text.unlikely section in kernel/built-in.o --->8--- It comes up when the kernel increases and 'panic()' is too far away to fit in the +/- 2MiB range. Which in turn issues from the 21-bit displacement in 'br{cond4}' mnemonic which is one of the two ways to do jumps (rjmp has just 10-bit displacement and therefore a way smaller range). This fact was stated before in 8d29b7b9f81d6b83d869ff054e6c189d6da73f1f. One solution to solve this is to add a local storage for the symbol address and just load the $pc with that value. Signed-off-by: Andreas Bießmann Acked-by: Hans-Christian Egtvedt Cc: Haavard Skinnemoen Signed-off-by: Greg Kroah-Hartman commit bf4730f3ac2dcfce9bf3d50a138aa4065283d1d9 Author: Andreas Bießmann Date: Thu Oct 24 12:31:03 2013 +0200 avr32: setup crt for early panic() commit 7a2a74f4b856993218aa7cdeeb6c3103101340db upstream. Before the CRT was (fully) set up in kernel_entry (bss cleared before in _start, but also not before jump to panic() in no_tag_table case). This patch fixes this up to have a fully working CRT when branching to panic() in no_tag_table. Signed-off-by: Andreas Bießmann Acked-by: Hans-Christian Egtvedt Cc: Haavard Skinnemoen Signed-off-by: Greg Kroah-Hartman commit 6be060cda95bb7d65d209b382add52bd2dee7662 Author: Paul Moore Date: Thu Sep 26 17:00:46 2013 -0400 selinux: correct locking in selinux_netlbl_socket_connect) commit 42d64e1add3a1ce8a787116036163b8724362145 upstream. The SELinux/NetLabel glue code has a locking bug that affects systems with NetLabel enabled, see the kernel error message below. This patch corrects this problem by converting the bottom half socket lock to a more conventional, and correct for this call-path, lock_sock() call. =============================== [ INFO: suspicious RCU usage. ] 3.11.0-rc3+ #19 Not tainted ------------------------------- net/ipv4/cipso_ipv4.c:1928 suspicious rcu_dereference_protected() usage! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 2 locks held by ping/731: #0: (slock-AF_INET/1){+.-...}, at: [...] selinux_netlbl_socket_connect #1: (rcu_read_lock){.+.+..}, at: [<...>] netlbl_conn_setattr stack backtrace: CPU: 1 PID: 731 Comm: ping Not tainted 3.11.0-rc3+ #19 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 0000000000000001 ffff88006f659d28 ffffffff81726b6a ffff88003732c500 ffff88006f659d58 ffffffff810e4457 ffff88006b845a00 0000000000000000 000000000000000c ffff880075aa2f50 ffff88006f659d90 ffffffff8169bec7 Call Trace: [] dump_stack+0x54/0x74 [] lockdep_rcu_suspicious+0xe7/0x120 [] cipso_v4_sock_setattr+0x187/0x1a0 [] netlbl_conn_setattr+0x187/0x190 [] ? netlbl_conn_setattr+0x5/0x190 [] selinux_netlbl_socket_connect+0xae/0xc0 [] selinux_socket_connect+0x135/0x170 [] ? might_fault+0x57/0xb0 [] security_socket_connect+0x16/0x20 [] SYSC_connect+0x73/0x130 [] ? sysret_check+0x22/0x5d [] ? trace_hardirqs_on_caller+0xfd/0x1c0 [] ? trace_hardirqs_on_thunk+0x3a/0x3f [] SyS_connect+0xe/0x10 [] system_call_fastpath+0x16/0x1b Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 1ba9563629aced9bd4471cd088fbffe11910e6f2 Author: Toshi Kani Date: Wed Nov 20 14:25:34 2013 +0100 ACPI / hotplug: Fix conflicted PCI bridge notify handlers commit ca499fc87ed945094d952da0eb7eea7dbeb1feec upstream. The PCI host bridge scan handler installs its own notify handler, handle_hotplug_event_root(), by itself. Nevertheless, the ACPI hotplug framework also installs the common notify handler, acpi_hotplug_notify_cb(), for PCI root bridges. This causes acpi_hotplug_notify_cb() to call _OST method with unsupported error as hotplug.enabled is not set. To address this issue, introduce hotplug.ignore flag, which indicates that the scan handler installs its own notify handler by itself. The ACPI hotplug framework does not install the common notify handler when this flag is set. Signed-off-by: Toshi Kani [rjw: Changed the name of the new flag] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit cad6526a7a12079819b73c63cefdff076858830e Author: Yinghai Lu Date: Mon Nov 18 17:02:45 2013 -0700 PCI: Remove duplicate pci_disable_device() from pcie_portdrv_remove() commit e7cc5cf74544d97d7b69e2701595037474db1f96 upstream. The pcie_portdrv .probe() method calls pci_enable_device() once, in pcie_port_device_register(), but the .remove() method calls pci_disable_device() twice, in pcie_port_device_remove() and in pcie_portdrv_remove(). That causes a "disabling already-disabled device" warning when removing a PCIe port device. This happens all the time when removing Thunderbolt devices, but is also easy to reproduce with, e.g., "echo 0000:00:1c.3 > /sys/bus/pci/drivers/pcieport/unbind" This patch removes the disable from pcie_portdrv_remove(). [bhelgaas: changelog, tag for stable] Reported-by: David Bulkow Reported-by: Mika Westerberg Signed-off-by: Yinghai Lu Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 3733596c40dc8ef2be53b2945e978373d86312c6 Author: Jeff Layton Date: Wed May 8 10:32:23 2013 -0400 audit: log the audit_names record type commit d3aea84a4ace5ff9ce7fb7714cee07bebef681c2 upstream. ...to make it clear what the intent behind each record's operation was. In many cases you can infer this, based on the context of the syscall and the result. In other cases it's not so obvious. For instance, in the case where you have a file being renamed over another, you'll have two different records with the same filename but different inode info. By logging this information we can clearly tell which one was created and which was deleted. This fixes what was broken in commit bfcec708. Commit 79f6530c should also be backported to stable v3.7+. Signed-off-by: Jeff Layton Signed-off-by: Eric Paris Signed-off-by: Richard Guy Briggs Signed-off-by: Eric Paris Signed-off-by: Greg Kroah-Hartman commit 1ec12a816c2312d55a51a0bcf8748e9c7049d015 Author: Jeff Layton Date: Wed May 8 10:25:58 2013 -0400 audit: add child record before the create to handle case where create fails commit 14e972b4517128ac8e30e3de2ee4fbd995084223 upstream. Historically, when a syscall that creates a dentry fails, you get an audit record that looks something like this (when trying to create a file named "new" in "/tmp/tmp.SxiLnCcv63"): type=PATH msg=audit(1366128956.279:965): item=0 name="/tmp/tmp.SxiLnCcv63/new" inode=2138308 dev=fd:02 mode=040700 ouid=0 ogid=0 rdev=00:00 obj=staff_u:object_r:user_tmp_t:s15:c0.c1023 This record makes no sense since it's associating the inode information for "/tmp/tmp.SxiLnCcv63" with the path "/tmp/tmp.SxiLnCcv63/new". The recent patch I posted to fix the audit_inode call in do_last fixes this, by making it look more like this: type=PATH msg=audit(1366128765.989:13875): item=0 name="/tmp/tmp.DJ1O8V3e4f/" inode=141 dev=fd:02 mode=040700 ouid=0 ogid=0 rdev=00:00 obj=staff_u:object_r:user_tmp_t:s15:c0.c1023 While this is more correct, if the creation of the file fails, then we have no record of the filename that the user tried to create. This patch adds a call to audit_inode_child to may_create. This creates an AUDIT_TYPE_CHILD_CREATE record that will sit in place until the create succeeds. When and if the create does succeed, then this record will be updated with the correct inode info from the create. This fixes what was broken in commit bfcec708. Commit 79f6530c should also be backported to stable v3.7+. Signed-off-by: Jeff Layton Signed-off-by: Eric Paris Signed-off-by: Richard Guy Briggs Signed-off-by: Eric Paris Signed-off-by: Greg Kroah-Hartman commit 24dccf86dd157e545698fdea4723ddf6f699ed87 Author: Jeff Layton Date: Mon Jul 8 15:59:36 2013 -0700 audit: fix mq_open and mq_unlink to add the MQ root as a hidden parent audit_names record commit 79f6530cb59e2a0af6953742a33cc29e98ca631c upstream. The old audit PATH records for mq_open looked like this: type=PATH msg=audit(1366282323.982:869): item=1 name=(null) inode=6777 dev=00:0c mode=041777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmpfs_t:s15:c0.c1023 type=PATH msg=audit(1366282323.982:869): item=0 name="test_mq" inode=26732 dev=00:0c mode=0100700 ouid=0 ogid=0 rdev=00:00 obj=staff_u:object_r:user_tmpfs_t:s15:c0.c1023 ...with the audit related changes that went into 3.7, they now look like this: type=PATH msg=audit(1366282236.776:3606): item=2 name=(null) inode=66655 dev=00:0c mode=0100700 ouid=0 ogid=0 rdev=00:00 obj=staff_u:object_r:user_tmpfs_t:s15:c0.c1023 type=PATH msg=audit(1366282236.776:3606): item=1 name=(null) inode=6926 dev=00:0c mode=041777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmpfs_t:s15:c0.c1023 type=PATH msg=audit(1366282236.776:3606): item=0 name="test_mq" Both of these look wrong to me. As Steve Grubb pointed out: "What we need is 1 PATH record that identifies the MQ. The other PATH records probably should not be there." Fix it to record the mq root as a parent, and flag it such that it should be hidden from view when the names are logged, since the root of the mq filesystem isn't terribly interesting. With this change, we get a single PATH record that looks more like this: type=PATH msg=audit(1368021604.836:484): item=0 name="test_mq" inode=16914 dev=00:0c mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:user_tmpfs_t:s0 In order to do this, a new audit_inode_parent_hidden() function is added. If we do it this way, then we avoid having the existing callers of audit_inode needing to do any sort of flag conversion if auditing is inactive. Signed-off-by: Jeff Layton Reported-by: Jiri Jaburek Cc: Steve Grubb Cc: Eric Paris Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3dc7095c8e78dfeb20dce066fe8bfdfd8497212e Author: Mathias Krause Date: Mon Sep 30 22:04:24 2013 +0200 audit: fix info leak in AUDIT_GET requests commit 64fbff9ae0a0a843365d922e0057fc785f23f0e3 upstream. We leak 4 bytes of kernel stack in response to an AUDIT_GET request as we miss to initialize the mask member of status_set. Fix that. Cc: Al Viro Cc: Eric Paris Signed-off-by: Mathias Krause Signed-off-by: Richard Guy Briggs Signed-off-by: Eric Paris Signed-off-by: Greg Kroah-Hartman commit d6770065f950cf0f7a2d89b4b419af6c0499ccfe Author: Mathias Krause Date: Mon Sep 30 22:04:25 2013 +0200 audit: use nlmsg_len() to get message payload length commit 4d8fe7376a12bf4524783dd95cbc00f1fece6232 upstream. Using the nlmsg_len member of the netlink header to test if the message is valid is wrong as it includes the size of the netlink header itself. Thereby allowing to send short netlink messages that pass those checks. Use nlmsg_len() instead to test for the right message length. The result of nlmsg_len() is guaranteed to be non-negative as the netlink message already passed the checks of nlmsg_ok(). Also switch to min_t() to please checkpatch.pl. Cc: Al Viro Cc: Eric Paris Signed-off-by: Mathias Krause Signed-off-by: Richard Guy Briggs Signed-off-by: Eric Paris Signed-off-by: Greg Kroah-Hartman commit b1427212a66869dde67ab630a400bf69fce5dbc0 Author: Tyler Hicks Date: Thu Jul 25 18:02:55 2013 -0700 audit: printk USER_AVC messages when audit isn't enabled commit 0868a5e150bc4c47e7a003367cd755811eb41e0b upstream. When the audit=1 kernel parameter is absent and auditd is not running, AUDIT_USER_AVC messages are being silently discarded. AUDIT_USER_AVC messages should be sent to userspace using printk(), as mentioned in the commit message of 4a4cd633 ("AUDIT: Optimise the audit-disabled case for discarding user messages"). When audit_enabled is 0, audit_receive_msg() discards all user messages except for AUDIT_USER_AVC messages. However, audit_log_common_recv_msg() refuses to allocate an audit_buffer if audit_enabled is 0. The fix is to special case AUDIT_USER_AVC messages in both functions. It looks like commit 50397bd1 ("[AUDIT] clean up audit_receive_msg()") introduced this bug. Signed-off-by: Tyler Hicks Cc: Al Viro Cc: Eric Paris Cc: linux-audit@redhat.com Acked-by: Kees Cook Signed-off-by: Richard Guy Briggs Signed-off-by: Eric Paris Signed-off-by: Greg Kroah-Hartman commit 88870d019e42cb9a9d594c77ea2bdd52e6a68361 Author: Ujjal Roy Date: Tue Nov 5 15:01:45 2013 -0800 mwifiex: fix wrong eth_hdr usage for bridged packets in AP mode commit 8d93f1f309d38b65fce0b9f0de91ba6c96990c07 upstream. The eth_hdr is never defined in this driver but it gets compiled without any warning/error because kernel has defined eth_hdr. Fix it by defining our own p_ethhdr and use it instead of eth_hdr. Signed-off-by: Ujjal Roy Signed-off-by: Amitkumar Karwar Signed-off-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 0c17d9208119338ccb95d1b55ee74d7062928336 Author: Avinash Patil Date: Tue Nov 5 15:01:44 2013 -0800 mwifiex: correct packet length for packets from SDIO interface commit d03b4aa77e1187b77dfe37d14a923547f00baa66 upstream. While receiving a packet on SDIO interface, we allocate skb with size multiple of SDIO block size. We need to resize this skb after RX using packet length from RX header. Signed-off-by: Avinash Patil Signed-off-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit fb675efa409c853ca3464ad93c4cf5d8577ef5e0 Author: Dave Airlie Date: Mon Nov 4 16:38:08 2013 +1000 qxl: avoid an oops in the deferred io code. commit cc87509d87696d7cd393882f5dedea01e03e41a9 upstream. If we are using deferred io due to plymouth or X.org fbdev driver we will oops in memcpy due to this pointless multiply here, removing it fixes fbdev to start and not oops. Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 2aed351e3f2014138a9551e0cb481128d3f3bd91 Author: Rafael J. Wysocki Date: Thu Nov 7 01:51:15 2013 +0100 PM / runtime: Use pm_runtime_put_sync() in __device_release_driver() commit baab52ded242c35a2290e1fa82e0cc147d0d8c1a upstream. Commit fa180eb448fa (PM / Runtime: Idle devices asynchronously after probe|release) modified __device_release_driver() to call pm_runtime_put(dev) instead of pm_runtime_put_sync(dev) before detaching the driver from the device. However, that was a mistake, because pm_runtime_put(dev) causes rpm_idle() to be queued up and the driver may be gone already when that function is executed. That breaks the assumptions the drivers have the right to make about the core's behavior on the basis of the existing documentation and actually causes problems to happen, so revert that part of commit fa180eb448fa and restore the previous behavior of __device_release_driver(). Reported-by: Tomi Valkeinen Fixes: fa180eb448fa (PM / Runtime: Idle devices asynchronously after probe|release) Signed-off-by: Rafael J. Wysocki Acked-by: Kevin Hilman Acked-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 67b51f87ef941607e1e891bf477bd18df53ce6f1 Author: Aaron Lu Date: Wed Nov 6 08:41:31 2013 +0800 PM / hibernate: Avoid overflow in hibernate_preallocate_memory() commit fd432b9f8c7c88428a4635b9f5a9c6e174df6e36 upstream. When system has a lot of highmem (e.g. 16GiB using a 32 bits kernel), the code to calculate how much memory we need to preallocate in normal zone may cause overflow. As Leon has analysed: It looks that during computing 'alloc' variable there is overflow: alloc = (3943404 - 1970542) - 1978280 = -5418 (signed) And this function goes to err_out. Fix this by avoiding that overflow. References: https://bugzilla.kernel.org/show_bug.cgi?id=60817 Reported-and-tested-by: Leon Drugi Signed-off-by: Aaron Lu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit d8db1a5f3133ec936bcbaced67890f229551d24f Author: Mikulas Patocka Date: Mon Oct 14 12:11:36 2013 -0400 blk-core: Fix memory corruption if blkcg_init_queue fails commit fff4996b7db7955414ac74386efa5e07fd766b50 upstream. If blkcg_init_queue fails, blk_alloc_queue_node doesn't call bdi_destroy to clean up structures allocated by the backing dev. ------------[ cut here ]------------ WARNING: at lib/debugobjects.c:260 debug_print_object+0x85/0xa0() ODEBUG: free active (active state 0) object type: percpu_counter hint: (null) Modules linked in: dm_loop dm_mod ip6table_filter ip6_tables uvesafb cfbcopyarea cfbimgblt cfbfillrect fbcon font bitblit fbcon_rotate fbcon_cw fbcon_ud fbcon_ccw softcursor fb fbdev ipt_MASQUERADE iptable_nat nf_nat_ipv4 msr nf_conntrack_ipv4 nf_defrag_ipv4 xt_state ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc tun ipv6 cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand cpufreq_conservative spadfs fuse hid_generic usbhid hid raid0 md_mod dmi_sysfs nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack lm85 hwmon_vid snd_usb_audio snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_hwdep snd_usbmidi_lib snd_rawmidi snd soundcore acpi_cpufreq freq_table mperf sata_svw serverworks kvm_amd ide_core ehci_pci ohci_hcd libata ehci_hcd kvm usbcore tg3 usb_common libphy k10temp pcspkr ptp i2c_piix4 i2c_core evdev microcode hwmon rtc_cmos pps_core e100 skge floppy mii processor button unix CPU: 0 PID: 2739 Comm: lvchange Tainted: G W 3.10.15-devel #14 Hardware name: empty empty/S3992-E, BIOS 'V1.06 ' 06/09/2009 0000000000000009 ffff88023c3c1ae8 ffffffff813c8fd4 ffff88023c3c1b20 ffffffff810399eb ffff88043d35cd58 ffffffff81651940 ffff88023c3c1bf8 ffffffff82479d90 0000000000000005 ffff88023c3c1b80 ffffffff81039a67 Call Trace: [] dump_stack+0x19/0x1b [] warn_slowpath_common+0x6b/0xa0 [] warn_slowpath_fmt+0x47/0x50 [] ? debug_check_no_obj_freed+0xcf/0x250 [] debug_print_object+0x85/0xa0 [] debug_check_no_obj_freed+0x203/0x250 [] kmem_cache_free+0x20c/0x3a0 [] blk_alloc_queue_node+0x2a9/0x2c0 [] blk_alloc_queue+0xe/0x10 [] dm_create+0x1a3/0x530 [dm_mod] [] ? list_version_get_info+0xe0/0xe0 [dm_mod] [] dev_create+0x57/0x2b0 [dm_mod] [] ? list_version_get_info+0xe0/0xe0 [dm_mod] [] ? list_version_get_info+0xe0/0xe0 [dm_mod] [] ctl_ioctl+0x268/0x500 [dm_mod] [] ? get_lock_stats+0x22/0x70 [] dm_ctl_ioctl+0xe/0x20 [dm_mod] [] do_vfs_ioctl+0x2ed/0x520 [] ? fget_light+0x377/0x4e0 [] SyS_ioctl+0x4b/0x90 [] system_call_fastpath+0x1a/0x1f ---[ end trace 4b5ff0d55673d986 ]--- ------------[ cut here ]------------ This fix should be backported to stable kernels starting with 2.6.37. Note that in the kernels prior to 3.5 the affected code is different, but the bug is still there - bdi_init is called and bdi_destroy isn't. Signed-off-by: Mikulas Patocka Acked-by: Tejun Heo Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 36dabd38dc3432fdb0c922357a60f9331c9334f4 Author: Dan Williams Date: Wed Nov 13 10:37:36 2013 -0800 ioatdma: fix selection of 16 vs 8 source path commit 21e96c7313486390c694919522a76dfea0a86c59 upstream. When performing continuations there are implied sources that need to be added to the source count. Quoting dma_set_maxpq: /* dma_maxpq - reduce maxpq in the face of continued operations * @dma - dma device with PQ capability * @flags - to check if DMA_PREP_CONTINUE and DMA_PREP_PQ_DISABLE_P are set * * When an engine does not support native continuation we need 3 extra * source slots to reuse P and Q with the following coefficients: * 1/ {00} * P : remove P from Q', but use it as a source for P' * 2/ {01} * Q : use Q to continue Q' calculation * 3/ {00} * Q : subtract Q from P' to cancel (2) * * In the case where P is disabled we only need 1 extra source: * 1/ {01} * Q : use Q to continue Q' calculation */ ...fix the selection of the 16 source path to take these implied sources into account. Note this also kills the BUG_ON(src_cnt < 9) check in __ioat3_prep_pq16_lock(). Besides not accounting for implied sources the check is redundant given we already made the path selection. Cc: Dave Jiang Acked-by: Dave Jiang Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit b8e15d48cdbbac38b5815b95dd99ac85a0b05edb Author: Dan Williams Date: Wed Nov 13 10:15:42 2013 -0800 ioatdma: fix sed pool selection commit 5d48b9b5d80e3aa38a5161565398b1e48a650573 upstream. The array to lookup the sed pool based on the number of sources (pq16_idx_to_sedi) is 16 entries and expects a max source index. However, we pass the total source count which runs off the end of the array when src_cnt == 16. The minimal fix is to just pass src_cnt-1, but given we know the source count is > 8 we can just calculate the sed pool by (src_cnt - 2) >> 3. Cc: Dave Jiang Acked-by: Dave Jiang Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 4c52f001344510d1e26a33cfdf971a12338a63d9 Author: Mikulas Patocka Date: Thu Oct 31 13:55:45 2013 -0400 dm: allocate buffer for messages with small number of arguments using GFP_NOIO commit f36afb3957353d2529cb2b00f78fdccd14fc5e9c upstream. dm-mpath and dm-thin must process messages even if some device is suspended, so we allocate argv buffer with GFP_NOIO. These messages have a small fixed number of arguments. On the other hand, dm-switch needs to process bulk data using messages so excessive use of GFP_NOIO could cause trouble. The patch also lowers the default number of arguments from 64 to 8, so that there is smaller load on GFP_NOIO allocations. Signed-off-by: Mikulas Patocka Acked-by: Alasdair G Kergon Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 8fafee9829f539e17ea8678a6f56d2b897ffe3cc Author: Joe Thornber Date: Wed Oct 30 17:11:58 2013 +0000 dm cache: fix a race condition between queuing new migrations and quiescing for a shutdown commit 66cb1910df17b38334153462ec8166e48058035f upstream. The code that was trying to do this was inadequate. The postsuspend method (in ioctl context), needs to wait for the worker thread to acknowledge the request to quiesce. Otherwise the migration count may drop to zero temporarily before the worker thread realises we're quiescing. In this case the target will be taken down, but the worker thread may have issued a new migration, which will cause an oops when it completes. Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 0c5fd99e89b5f288ffe5c2ed301d2ffaac091891 Author: Joe Thornber Date: Wed Oct 30 11:19:59 2013 +0000 dm array: fix bug in growing array commit 9c1d4de56066e4d6abc66ec188faafd7b303fb08 upstream. Entries would be lost if the old tail block was partially filled. Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 9fb1b9d041cb34f4381038e2622900dfdc4cd7b0 Author: Shiva Krishna Merla Date: Wed Oct 30 03:26:38 2013 +0000 dm mpath: fix race condition between multipath_dtr and pg_init_done commit 954a73d5d3073df2231820c718fdd2f18b0fe4c9 upstream. Whenever multipath_dtr() is happening we must prevent queueing any further path activation work. Implement this by adding a new 'pg_init_disabled' flag to the multipath structure that denotes future path activation work should be skipped if it is set. By disabling pg_init and then re-enabling in flush_multipath_work() we also avoid the potential for pg_init to be initiated while suspending an mpath device. Without this patch a race condition exists that may result in a kernel panic: 1) If after pg_init_done() decrements pg_init_in_progress to 0, a call to wait_for_pg_init_completion() assumes there are no more pending path management commands. 2) If pg_init_required is set by pg_init_done(), due to retryable mode_select errors, then process_queued_ios() will again queue the path activation work. 3) If free_multipath() completes before activate_path() work is called a NULL pointer dereference like the following can be seen when accessing members of the recently destructed multipath: BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 RIP: 0010:[] [] activate_path+0x1b/0x30 [dm_multipath] [] worker_thread+0x170/0x2a0 [] ? autoremove_wake_function+0x0/0x40 [switch to disabling pg_init in flush_multipath_work & header edits by Mike Snitzer] Signed-off-by: Shiva Krishna Merla Reviewed-by: Krishnasamy Somasundaram Tested-by: Speagle Andy Acked-by: Junichi Nomura Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 63a23e393fed93ca823f7c7fc415795e2ffe7670 Author: Rodolfo Giometti Date: Mon Sep 9 17:31:59 2013 +0200 mmc: atmel-mci: fix oops in atmci_tasklet_func commit fbd986cd420d1deeabf1039ec4e74075a5639db5 upstream. In some cases, a NULL pointer dereference happens because data is NULL when STATE_END_REQUEST case is reached in atmci_tasklet_func. Signed-off-by: Rodolfo Giometti Acked-by: Ludovic Desroches Acked-by: Nicolas Ferre Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit 6edfd0331f788a5d62736c6a422488708175b4c4 Author: Ludovic Desroches Date: Mon Sep 9 17:29:56 2013 +0200 mmc: atmel-mci: abort transfer on timeout error commit c1fa3426aa5c782724c97394303d52228206eda4 upstream. When a software timeout occurs, the transfer is not stopped. In DMA case, it causes DMA channel to be stuck because the transfer is still active causing following transfers to be queued but not computed. Signed-off-by: Ludovic Desroches Reported-by: Alexander Morozov Acked-by: Nicolas Ferre Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit 3cbafaa72d3afc4a4177f0d76178cd26a525589b Author: Akira Takeuchi Date: Tue Nov 12 15:08:21 2013 -0800 mm: ensure get_unmapped_area() returns higher address than mmap_min_addr commit 2afc745f3e3079ab16c826be4860da2529054dd2 upstream. This patch fixes the problem that get_unmapped_area() can return illegal address and result in failing mmap(2) etc. In case that the address higher than PAGE_SIZE is set to /proc/sys/vm/mmap_min_addr, the address lower than mmap_min_addr can be returned by get_unmapped_area(), even if you do not pass any virtual address hint (i.e. the second argument). This is because the current get_unmapped_area() code does not take into account mmap_min_addr. This leads to two actual problems as follows: 1. mmap(2) can fail with EPERM on the process without CAP_SYS_RAWIO, although any illegal parameter is not passed. 2. The bottom-up search path after the top-down search might not work in arch_get_unmapped_area_topdown(). Note: The first and third chunk of my patch, which changes "len" check, are for more precise check using mmap_min_addr, and not for solving the above problem. [How to reproduce] --- test.c ------------------------------------------------- #include #include #include #include int main(int argc, char *argv[]) { void *ret = NULL, *last_map; size_t pagesize = sysconf(_SC_PAGESIZE); do { last_map = ret; ret = mmap(0, pagesize, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); // printf("ret=%p\n", ret); } while (ret != MAP_FAILED); if (errno != ENOMEM) { printf("ERR: unexpected errno: %d (last map=%p)\n", errno, last_map); } return 0; } --------------------------------------------------------------- $ gcc -m32 -o test test.c $ sudo sysctl -w vm.mmap_min_addr=65536 vm.mmap_min_addr = 65536 $ ./test (run as non-priviledge user) ERR: unexpected errno: 1 (last map=0x10000) Signed-off-by: Akira Takeuchi Signed-off-by: Kiyoshi Owada Reviewed-by: Naoya Horiguchi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit df3e475e43ae5e2112a464335c28368092d53edd Author: Stanislaw Gruszka Date: Tue Oct 15 14:28:48 2013 +0200 rt2400pci: fix RSSI read commit 2bf127a5cc372b9319afcbae10b090663b621c8b upstream. RSSI value is provided on word3 not on word2. Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 9dc2f267425869786d195a99eadbc2aad3f4edaa Author: Ursula Braun Date: Wed Nov 6 09:04:52 2013 +0100 qeth: avoid buffer overflow in snmp ioctl commit 6fb392b1a63ae36c31f62bc3fc8630b49d602b62 upstream. Check user-defined length in snmp ioctl request and allow request only if it fits into a qeth command buffer. Signed-off-by: Ursula Braun Signed-off-by: Frank Blaschka Reviewed-by: Heiko Carstens Reported-by: Nico Golde Reported-by: Fabian Yamaguchi Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e6a159898766541f6ed3bb48fe45dbba19ffa7eb Author: Larry Finger Date: Tue Nov 5 15:15:29 2013 -0600 rtlwifi: rtl8192cu: Fix incorrect signal strength for unassociated AP commit 78dbfecb95be4635b995af3bd29fa10013409fcd upstream. The routine that processes received frames was returning the RSSI value for the signal strength; however, that value is available only for associated APs. As a result, the strength was the absurd value of 10 dBm. As a result, scans return incorrect values for the strength, which causes unwanted attempts to roam. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit b642081da4873e8fa3d7097076d2df9ba557d54e Author: Larry Finger Date: Tue Nov 5 15:15:28 2013 -0600 rtlwifi: rtl8192se: Fix incorrect signal strength for unassociated AP commit b4ade797668e33b4e8353c2701ce01d7084dfafa upstream. The routine that processes received frames was returning the RSSI value for the signal strength; however, that value is available only for associated APs. As a result, the strength was the absurd value of 10 dBm. As a result, scans return incorrect values for the strength, which causes unwanted attempts to roam. This patch fixes https://bugzilla.kernel.org/show_bug.cgi?id=63881. Signed-off-by: Larry Finger Reported-by: Matthieu Baerts Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 16bc5bbba363d71baf24917ec1642962fa273c97 Author: Larry Finger Date: Tue Nov 5 15:15:30 2013 -0600 rtlwifi: rtl8192de: Fix incorrect signal strength for unassociated AP commit 3545f3d5f4af715c914394123ce7725a9cf0a1c4 upstream. The routine that processes received frames was returning the RSSI value for the signal strength; however, that value is available only for associated APs. As a result, the strength was the absurd value of 10 dBm. As a result, scans return incorrect values for the strength, which causes unwanted attempts to roam. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit d0ac18ce1a3d607ad650fd4b9d371be75a5c8e3a Author: Vegard Nossum Date: Thu Sep 5 13:00:14 2013 +0200 xen/blkback: fix reference counting commit ea5ec76d76da9279d12027c1828544c5ccbe7932 upstream. If the permission check fails, we drop a reference to the blkif without having taken it in the first place. The bug was introduced in commit 604c499cbbcc3d5fe5fb8d53306aa0fae1990109 (xen/blkback: Check device permissions before allowing OP_DISCARD). Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Signed-off-by: Vegard Nossum Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit ef0d74867fc7e440b0e945e7fe47a862dbc9c9ef Author: Theodore Ts'o Date: Thu Oct 31 23:00:24 2013 -0400 ext4: avoid bh leak in retry path of ext4_expand_extra_isize_ea() commit dcb9917ba041866686fe152850364826c4622a36 upstream. Reported-by: Dave Jones Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 17dd1396ef45390758e18d19f06b1e1408af9c03 Author: Huang Shijie Date: Mon Nov 11 12:13:45 2013 +0800 mtd: gpmi: fix kernel BUG due to racing DMA operations commit 7b3d2fb92067bcb29f0f085a9fa9fa64920a6646 upstream. [1] The gpmi uses the nand_command_lp to issue the commands to NAND chips. The gpmi issues a DMA operation with gpmi_cmd_ctrl when it handles a NAND_CMD_NONE control command. So when we read a page(NAND_CMD_READ0) from the NAND, we may send two DMA operations back-to-back. If we do not serialize the two DMA operations, we will meet a bug when 1.1) we enable CONFIG_DMA_API_DEBUG, CONFIG_DMADEVICES_DEBUG, and CONFIG_DEBUG_SG. 1.2) Use the following commands in an UART console and a SSH console: cmd 1: while true;do dd if=/dev/mtd0 of=/dev/null;done cmd 1: while true;do dd if=/dev/mmcblk0 of=/dev/null;done The kernel log shows below: ----------------------------------------------------------------- kernel BUG at lib/scatterlist.c:28! Unable to handle kernel NULL pointer dereference at virtual address 00000000 ......................... [<80044a0c>] (__bug+0x18/0x24) from [<80249b74>] (sg_next+0x48/0x4c) [<80249b74>] (sg_next+0x48/0x4c) from [<80255398>] (debug_dma_unmap_sg+0x170/0x1a4) [<80255398>] (debug_dma_unmap_sg+0x170/0x1a4) from [<8004af58>] (dma_unmap_sg+0x14/0x6c) [<8004af58>] (dma_unmap_sg+0x14/0x6c) from [<8027e594>] (mxs_dma_tasklet+0x18/0x1c) [<8027e594>] (mxs_dma_tasklet+0x18/0x1c) from [<8007d444>] (tasklet_action+0x114/0x164) ----------------------------------------------------------------- 1.3) Assume the two DMA operations is X (first) and Y (second). The root cause of the bug: Assume process P issues DMA X, and sleep on the completion @this->dma_done. X's tasklet callback is dma_irq_callback. It firstly wake up the process sleeping on the completion @this->dma_done, and then trid to unmap the scatterlist S. The waked process P will issue Y in another ARM core. Y initializes S->sg_magic to zero with sg_init_one(), while dma_irq_callback is unmapping S at the same time. See the diagram: ARM core 0 | ARM core 1 ------------------------------------------------------------- (P issues DMA X, then sleep) --> | | (X's tasklet wakes P) --> | | | <-- (P begin to issue DMA Y) | (X's tasklet unmap the | scatterlist S with dma_unmap_sg) --> | <-- (Y calls sg_init_one() to init | scatterlist S) | [2] This patch serialize both the X and Y in the following way: Unmap the DMA scatterlist S firstly, and wake up the process at the end of the DMA callback, in such a way, Y will be executed after X. After this patch: ARM core 0 | ARM core 1 ------------------------------------------------------------- (P issues DMA X, then sleep) --> | | (X's tasklet unmap the | scatterlist S with dma_unmap_sg) --> | | (X's tasklet wakes P) --> | | | <-- (P begin to issue DMA Y) | | <-- (Y calls sg_init_one() to init | scatterlist S) | Signed-off-by: Huang Shijie Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit 1da42d7c5ff4dbee6b7c60cbcba9035422a7a1f8 Author: Wang Haitao Date: Thu Aug 22 19:32:38 2013 +0800 mtd: map: fixed bug in 64-bit systems commit a4d62babf988fe5dfde24437fa135ef147bc7aa0 upstream. Hardware: CPU: XLP832,the 64-bit OS NOR Flash:S29GL128S 128M Software: Kernel:2.6.32.41 Filesystem:JFFS2 When writing files, errors appear: Write len 182 but return retlen 180 Write of 182 bytes at 0x072c815c failed. returned -5, retlen 180 Write len 186 but return retlen 184 Write of 186 bytes at 0x072caff4 failed. returned -5, retlen 184 These errors exist only in 64-bit systems,not in 32-bit systems. After analysis, we found that the left shift operation is wrong in map_word_load_partial. For instance: unsigned char buf[3] ={0x9e,0x3a,0xea}; map_bankwidth(map) is 4; for (i=0; i < 3; i++) { int bitpos; bitpos = (map_bankwidth(map)-1-i)*8; orig.x[0] &= ~(0xff << bitpos); orig.x[0] |= buf[i] << bitpos; } The value of orig.x[0] is expected to be 0x9e3aeaff, but in this situation(64-bit System) we'll get the wrong value of 0xffffffff9e3aeaff due to the 64-bit sign extension: buf[i] is defined as "unsigned char" and the left-shift operation will convert it to the type of "signed int", so when left-shift buf[i] by 24 bits, the final result will get the wrong value: 0xffffffff9e3aeaff. If the left-shift bits are less than 24, then sign extension will not occur. Whereas the bankwidth of the nor flash we used is 4, therefore this BUG emerges. Signed-off-by: Pang Xunlei Signed-off-by: Zhang Yi Signed-off-by: Lu Zhongjun Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit 017beeafb0bd8a13118b71d568ed0912b6bf9f69 Author: Brian Norris Date: Tue Aug 27 18:45:10 2013 -0700 mtd: nand: hack ONFI for non-power-of-2 dimensions commit 4355b70cf48363c50a9de450b01178c83aba8f6a upstream. Some bright specification writers decided to write this in the ONFI spec (from ONFI 3.0, Section 3.1): "The number of blocks and number of pages per block is not required to be a power of two. In the case where one of these values is not a power of two, the corresponding address shall be rounded to an integral number of bits such that it addresses a range up to the subsequent power of two value. The host shall not access upper addresses in a range that is shown as not supported." This breaks every assumption MTD makes about NAND block/chip-size dimensions -- they *must* be a power of two! And of course, an enterprising manufacturer has made use of this lovely freedom. Exhibit A: Micron MT29F32G08CBADAWP "- Plane size: 2 planes x 1064 blocks per plane - Device size: 32Gb: 2128 blockss [sic]" This quickly hits a BUG() in nand_base.c, since the extra dimensions overflow so we think it's a second chip (on my single-chip setup): ONFI param page 0 valid ONFI flash detected NAND device: Manufacturer ID: 0x2c, Chip ID: 0x44 (Micron MT29F32G08CBADAWP), 4256MiB, page size: 8192, OOB size: 744 ------------[ cut here ]------------ kernel BUG at drivers/mtd/nand/nand_base.c:203! Internal error: Oops - BUG: 0 [#1] SMP ARM [... trim ...] [] (nand_select_chip+0x18/0x2c) from [] (nand_do_read_ops+0x90/0x424) [] (nand_do_read_ops+0x90/0x424) from [] (nand_read+0x54/0x78) [] (nand_read+0x54/0x78) from [] (mtd_read+0x84/0xbc) [] (mtd_read+0x84/0xbc) from [] (scan_read.clone.4+0x4c/0x64) [] (scan_read.clone.4+0x4c/0x64) from [] (search_bbt+0x148/0x290) [] (search_bbt+0x148/0x290) from [] (nand_scan_bbt+0xd4/0x5c0) [... trim ...] ---[ end trace 0c9363860d865ff2 ]--- So to fix this, just truncate these dimensions down to the greatest power-of-2 dimension that is less than or equal to the specified dimension. Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit ff236289a23351c72359f4507071d3639e3b7e6d Author: Mikulas Patocka Date: Tue Oct 15 14:14:38 2013 -0600 loop: fix crash when using unassigned loop device commit ef7e7c82e02b602f29c2b87f42dcd6143a6777da upstream. When the loop module is loaded, it creates 8 loop devices /dev/loop[0-7]. The devices have no request routine and thus, when they are used without being assigned, a crash happens. For example, these commands cause crash (assuming there are no used loop devices): Kernel Fault: Code=26 regs=000000007f420980 (Addr=0000000000000010) CPU: 1 PID: 50 Comm: kworker/1:1 Not tainted 3.11.0 #1 Workqueue: ksnaphd do_metadata [dm_snapshot] task: 000000007fcf4078 ti: 000000007f420000 task.ti: 000000007f420000 [ 116.319988] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00001000000001001111111100001111 Not tainted r00-03 000000ff0804ff0f 00000000408bf5d0 00000000402d8204 000000007b7ff6c0 r04-07 00000000408a95d0 000000007f420950 000000007b7ff6c0 000000007d06c930 r08-11 000000007f4205c0 0000000000000001 000000007f4205c0 000000007f4204b8 r12-15 0000000000000010 0000000000000000 0000000000000000 0000000000000000 r16-19 000000001108dd48 000000004061cd7c 000000007d859800 000000000800000f r20-23 0000000000000000 0000000000000008 0000000000000000 0000000000000000 r24-27 00000000ffffffff 000000007b7ff6c0 000000007d859800 00000000408a95d0 r28-31 0000000000000000 000000007f420950 000000007f420980 000000007f4208e8 sr00-03 0000000000000000 0000000000000000 0000000000000000 0000000000303000 sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 117.549988] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000402d82fc 00000000402d8300 IIR: 53820020 ISR: 0000000000000000 IOR: 0000000000000010 CPU: 1 CR30: 000000007f420000 CR31: ffffffffffffffff ORIG_R28: 0000000000000001 IAOQ[0]: generic_make_request+0x11c/0x1a0 IAOQ[1]: generic_make_request+0x120/0x1a0 RP(r2): generic_make_request+0x24/0x1a0 Backtrace: [<00000000402d83f0>] submit_bio+0x70/0x140 [<0000000011087c4c>] dispatch_io+0x234/0x478 [dm_mod] [<0000000011087f44>] sync_io+0xb4/0x190 [dm_mod] [<00000000110883bc>] dm_io+0x2c4/0x310 [dm_mod] [<00000000110bfcd0>] do_metadata+0x28/0xb0 [dm_snapshot] [<00000000401591d8>] process_one_work+0x160/0x460 [<0000000040159bc0>] worker_thread+0x300/0x478 [<0000000040161a70>] kthread+0x118/0x128 [<0000000040104020>] end_fault_vector+0x20/0x28 [<0000000040177220>] task_tick_fair+0x420/0x4d0 [<00000000401aa048>] invoke_rcu_core+0x50/0x60 [<00000000401ad5b8>] rcu_check_callbacks+0x210/0x8d8 [<000000004014aaa0>] update_process_times+0xa8/0xc0 [<00000000401ab86c>] rcu_process_callbacks+0x4b4/0x598 [<0000000040142408>] __do_softirq+0x250/0x2c0 [<00000000401789d0>] find_busiest_group+0x3c0/0xc70 [ 119.379988] Kernel panic - not syncing: Kernel Fault Rebooting in 1 seconds.. Signed-off-by: Mikulas Patocka Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 6be5caa68ad7d194173eafd35c9f8aeba00adb00 Author: Mikulas Patocka Date: Mon Oct 14 12:12:24 2013 -0400 loop: fix crash if blk_alloc_queue fails commit 3ec981e30fae1f3c8728a05c730acaa1f627bcfb upstream. loop: fix crash if blk_alloc_queue fails If blk_alloc_queue fails, loop_add cleans up, but it doesn't clean up the identifier allocated with idr_alloc. That causes crash on module unload in idr_for_each(&loop_index_idr, &loop_exit_cb, NULL); where we attempt to remove non-existed device with that id. BUG: unable to handle kernel NULL pointer dereference at 0000000000000380 IP: [] del_gendisk+0x19/0x2d0 PGD 43d399067 PUD 43d0ad067 PMD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: loop(-) dm_snapshot dm_zero dm_mirror dm_region_hash dm_log dm_loop dm_mod ip6table_filter ip6_tables uvesafb cfbcopyarea cfbimgblt cfbfillrect fbcon font bitblit fbcon_rotate fbcon_cw fbcon_ud fbcon_ccw softcursor fb fbdev msr ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc tun ipv6 cpufreq_userspace cpufreq_stats cpufreq_ondemand cpufreq_conservative cpufreq_powersave spadfs fuse hid_generic usbhid hid raid0 md_mod dmi_sysfs nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack snd_usb_audio snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc lm85 hwmon_vid snd_hwdep snd_usbmidi_lib snd_rawmidi snd soundcore acpi_cpufreq ohci_hcd freq_table tg3 ehci_pci mperf ehci_hcd kvm_amd kvm sata_svw serverworks libphy libata ide_core k10temp usbcore hwmon microcode ptp pcspkr pps_core e100 skge mii usb_common i2c_piix4 floppy evdev rtc_cmos i2c_core processor but! ton unix CPU: 7 PID: 2735 Comm: rmmod Tainted: G W 3.10.15-devel #15 Hardware name: empty empty/S3992-E, BIOS 'V1.06 ' 06/09/2009 task: ffff88043d38e780 ti: ffff88043d21e000 task.ti: ffff88043d21e000 RIP: 0010:[] [] del_gendisk+0x19/0x2d0 RSP: 0018:ffff88043d21fe10 EFLAGS: 00010282 RAX: ffffffffa05102e0 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88043ea82800 RDI: 0000000000000000 RBP: ffff88043d21fe48 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000000 R12: 00000000000000ff R13: 0000000000000080 R14: 0000000000000000 R15: ffff88043ea82800 FS: 00007ff646534700(0000) GS:ffff880447000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000380 CR3: 000000043e9bf000 CR4: 00000000000007e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Stack: ffffffff8100aba4 0000000000000092 ffff88043d21fe48 ffff88043ea82800 00000000000000ff ffff88043d21fe98 0000000000000000 ffff88043d21fe60 ffffffffa05102b4 0000000000000000 ffff88043d21fe70 ffffffffa05102ec Call Trace: [] ? native_sched_clock+0x24/0x80 [] loop_remove+0x14/0x40 [loop] [] loop_exit_cb+0xc/0x10 [loop] [] idr_for_each+0x104/0x190 [] ? loop_remove+0x40/0x40 [loop] [] ? trace_hardirqs_on_caller+0x105/0x1d0 [] loop_exit+0x34/0xa58 [loop] [] SyS_delete_module+0x13a/0x260 [] ? trace_hardirqs_on_thunk+0x3a/0x3f [] system_call_fastpath+0x1a/0x1f Code: f0 4c 8b 6d f8 c9 c3 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 56 41 55 4c 8d af 80 00 00 00 41 54 53 48 89 fb 48 83 ec 18 <48> 83 bf 80 03 00 00 00 74 4d e8 98 fe ff ff 31 f6 48 c7 c7 20 RIP [] del_gendisk+0x19/0x2d0 RSP CR2: 0000000000000380 ---[ end trace 64ec069ec70f1309 ]--- Signed-off-by: Mikulas Patocka Acked-by: Tejun Heo Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c0be79254f31d3e19fa584bb2e7ca8d152074bbc Author: Bart Van Assche Date: Thu Oct 10 13:53:25 2013 +0200 IB/srp: Report receive errors correctly commit cd4e38542a5c2cab94e5410fb17c1cc004a60792 upstream. The IB spec does not guarantee that the opcode is available in error completions. Hence do not rely on it. See also commit 948d1e889e5b ("IB/srp: Introduce srp_handle_qp_err()"). Signed-off-by: Bart Van Assche Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit 71d7bd9b865fb91fb39501260fafd88c791d9dc5 Author: Mike Marciniszyn Date: Fri Oct 25 11:17:59 2013 -0400 IB/qib: Fix txselect regression commit 2fadd83184d58701f1116ca578465b5a75f9417c upstream. Commit 7fac33014f54("IB/qib: checkpatch fixes") was overzealous in removing a simple_strtoul for a parse routine, setup_txselect(). That routine is required to handle a multi-value string. Unwind that aspect of the fix. Signed-off-by: Mike Marciniszyn Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit eef5ed304aa7b49b8f58720855dd299163329db2 Author: Jan Kara Date: Fri Oct 4 09:29:06 2013 -0400 IB/ipath: Convert ipath_user_sdma_pin_pages() to use get_user_pages_fast() commit 4adcf7fb6783e354aab38824d803fa8c4f8e8a27 upstream. ipath_user_sdma_queue_pkts() gets called with mmap_sem held for writing. Except for get_user_pages() deep down in ipath_user_sdma_pin_pages() we don't seem to need mmap_sem at all. Even more interestingly the function ipath_user_sdma_queue_pkts() (and also ipath_user_sdma_coalesce() called somewhat later) call copy_from_user() which can hit a page fault and we deadlock on trying to get mmap_sem when handling that fault. So just make ipath_user_sdma_pin_pages() use get_user_pages_fast() and leave mmap_sem locking for mm. This deadlock has actually been observed in the wild when the node is under memory pressure. Signed-off-by: Jan Kara Signed-off-by: Mike Marciniszyn [ Merged in fix for call to get_user_pages_fast from Tetsuo Handa . - Roland ] Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit 6aec95b47deb9e3dad4cb2e6db87f3b03544224d Author: Eric Seppanen Date: Wed Nov 20 14:19:52 2013 -0800 iscsi-target: chap auth shouldn't match username with trailing garbage commit 86784c6bdeeef78eed94d298be7a8879f6a97ee2 upstream. In iSCSI negotiations with initiator CHAP enabled, usernames with trailing garbage are permitted, because the string comparison only checks the strlen of the configured username. e.g. "usernameXXXXX" will be permitted to match "username". Just check one more byte so the trailing null char is also matched. Signed-off-by: Eric Seppanen Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit e97f132f0e66893138f64b681cddff2d2ff37b53 Author: Eric Seppanen Date: Wed Nov 20 14:19:51 2013 -0800 iscsi-target: fix extract_param to handle buffer length corner case commit 369653e4fb511928511b0ce81f41c812ff1f28b6 upstream. extract_param() is called with max_length set to the total size of the output buffer. It's not safe to allow a parameter length equal to the buffer size as the terminating null would be written one byte past the end of the output buffer. Signed-off-by: Eric Seppanen Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit cf516effc76c78f948e6eb7cc46d4515003b423d Author: Nicholas Bellinger Date: Tue Nov 12 17:54:56 2013 -0800 iscsi-target: Fix mutex_trylock usage in iscsit_increment_maxcmdsn commit 5e8e6b4b3adebf01a9d97056cbbfd8c44330df99 upstream. This patch fixes a >= v3.10 regression bug with mutex_trylock() usage within iscsit_increment_maxcmdsn(), that was originally added to allow for a special case where ->cmdsn_mutex was already held from the iscsit_execute_cmd() exception path for ib_isert. When !mutex_trylock() was occuring under contention during normal RX/TX process context codepaths, the bug was manifesting itself as the following protocol error: Received CmdSN: 0x000fcbb7 is greater than MaxCmdSN: 0x000fcbb6, protocol error. Received CmdSN: 0x000fcbb8 is greater than MaxCmdSN: 0x000fcbb6, protocol error. This patch simply avoids the direct ib_isert callback in lio_queue_status() for the special iscsi_execute_cmd() exception cases, that allows the problematic mutex_trylock() usage in iscsit_increment_maxcmdsn() to go away. Reported-by: Moussa Ba Tested-by: Moussa Ba Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 61688ba3da37952114be1bef89e2f4a3b0217624 Author: Samir Benmendil Date: Sun Nov 17 23:56:17 2013 +0100 ahci: add Marvell 9230 to the AHCI PCI device list commit 6d5278a68a75891db1df5ae1ecf83d288fc58c65 upstream. Tested with a DAWICONTROL DC-624e on 3.10.10 Signed-off-by: Samir Benmendil Signed-off-by: Tejun Heo Reviewed-by: Levente Kurusa Signed-off-by: Greg Kroah-Hartman commit 420df0f5c514a3d6f44829c2dacfcb44964f6517 Author: xiangliang yu Date: Sun Oct 27 08:03:04 2013 -0400 ahci: disabled FBS prior to issuing software reset commit 89dafa20f3daab5b3e0c13d0068a28e8e64e2102 upstream. Tested with Marvell 88se9125, attached with one port mulitplier(5 ports) and one disk, we will get following boot log messages if using current code: ata8: SATA link up 6.0 Gbps (SStatus 133 SControl 330) ata8.15: Port Multiplier 1.2, 0x1b4b:0x9715 r160, 5 ports, feat 0x1/0x1f ahci 0000:03:00.0: FBS is enabled ata8.00: hard resetting link ata8.00: SATA link down (SStatus 0 SControl 330) ata8.01: hard resetting link ata8.01: SATA link down (SStatus 0 SControl 330) ata8.02: hard resetting link ata8.02: SATA link down (SStatus 0 SControl 330) ata8.03: hard resetting link ata8.03: SATA link up 6.0 Gbps (SStatus 133 SControl 133) ata8.04: hard resetting link ata8.04: failed to resume link (SControl 133) ata8.04: failed to read SCR 0 (Emask=0x40) ata8.04: failed to read SCR 0 (Emask=0x40) ata8.04: failed to read SCR 1 (Emask=0x40) ata8.04: failed to read SCR 0 (Emask=0x40) ata8.03: native sectors (2) is smaller than sectors (976773168) ata8.03: ATA-8: ST3500413AS, JC4B, max UDMA/133 ata8.03: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32) ata8.03: configured for UDMA/133 ata8.04: failed to IDENTIFY (I/O error, err_mask=0x100) ata8.15: hard resetting link ata8.15: SATA link up 6.0 Gbps (SStatus 133 SControl 330) ata8.15: Port Multiplier vendor mismatch '0x1b4b' != '0x133' ata8.15: PMP revalidation failed (errno=-19) ata8.15: hard resetting link ata8.15: SATA link up 6.0 Gbps (SStatus 133 SControl 330) ata8.15: Port Multiplier vendor mismatch '0x1b4b' != '0x133' ata8.15: PMP revalidation failed (errno=-19) ata8.15: limiting SATA link speed to 3.0 Gbps ata8.15: hard resetting link ata8.15: SATA link up 3.0 Gbps (SStatus 123 SControl 320) ata8.15: Port Multiplier vendor mismatch '0x1b4b' != '0x133' ata8.15: PMP revalidation failed (errno=-19) ata8.15: failed to recover PMP after 5 tries, giving up ata8.15: Port Multiplier detaching ata8.03: disabled ata8.00: disabled ata8: EH complete The reason is that current detection code doesn't follow AHCI spec: First,the port multiplier detection process look like this: ahci_hardreset(link, class, deadline) if (class == ATA_DEV_PMP) { sata_pmp_attach(dev) /* will enable FBS */ sata_pmp_init_links(ap, nr_ports); ata_for_each_link(link, ap, EDGE) { sata_std_hardreset(link, class, deadline); if (link_is_online) /* do soft reset */ ahci_softreset(link, class, deadline); } } But, according to chapter 9.3.9 in AHCI spec: Prior to issuing software reset, software shall clear PxCMD.ST to '0' and then clear PxFBS.EN to '0'. The patch test ok with kernel 3.11.1. tj: Patch white space contaminated, applied manually with trivial updates. Signed-off-by: Xiangliang Yu Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 296cfdecbe6cf01b12f6073a521694db2073af5e Author: James Ralston Date: Mon Nov 4 09:24:58 2013 -0800 ahci: Add Device IDs for Intel Wildcat Point-LP commit 9f961a5f6efc87a79571d7166257b36af28ffcfe upstream. This patch adds the AHCI-mode SATA Device IDs for the Intel Wildcat Point-LP PCH. Signed-off-by: James Ralston Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 873be93b1af2d62b6541b053f99a46771f5d9234 Author: Manfred Spraul Date: Wed Oct 16 13:46:45 2013 -0700 ipc/sem.c: synchronize semop and semctl with IPC_RMID commit 6e224f94597842c5eb17f1fc2208d20b6f7f7d49 upstream. After acquiring the semlock spinlock, operations must test that the array is still valid. - semctl() and exit_sem() would walk stale linked lists (ugly, but should be ok: all lists are empty) - semtimedop() would sleep forever - and if woken up due to a signal - access memory after free. The patch also: - standardizes the tests for .deleted, so that all tests in one function leave the function with the same approach. - unconditionally tests for .deleted immediately after every call to sem_lock - even it it means that for semctl(GETALL), .deleted will be tested twice. Both changes make the review simpler: After every sem_lock, there must be a test of .deleted, followed by a goto to the cleanup code (if the function uses "goto cleanup"). The only exception is semctl_down(): If sem_ids().rwsem is locked, then the presence in ids->ipcs_idr is equivalent to !.deleted, thus no additional test is required. Signed-off-by: Manfred Spraul Cc: Mike Galbraith Acked-by: Davidlohr Bueso Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3f47cff85a8737780a5eba628cae112cd07496de Author: Davidlohr Bueso Date: Wed Oct 16 13:46:45 2013 -0700 ipc: update locking scheme comments commit 18ccee263c7e250a57f01c9434658f11f4118a64 upstream. The initial documentation was a bit incomplete, update accordingly. [akpm@linux-foundation.org: make it more readable in 80 columns] Signed-off-by: Davidlohr Bueso Acked-by: Manfred Spraul Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a12503f53b7555a639869527d47eef61ff33cd00 Author: Mathias Krause Date: Sun Nov 3 12:36:28 2013 +0100 ipc, msg: forbid negative values for "msg{max,mnb,mni}" commit 9bf76ca325d5e9208eb343f7bd4cc666f703ed30 upstream. Negative message lengths make no sense -- so don't do negative queue lenghts or identifier counts. Prevent them from getting negative. Also change the underlying data types to be unsigned to avoid hairy surprises with sign extensions in cases where those variables get evaluated in unsigned expressions with bigger data types, e.g size_t. In case a user still wants to have "unlimited" sizes she could just use INT_MAX instead. Signed-off-by: Mathias Krause Cc: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4b825b95aaa48c706d24c804f7edff228bd6af70 Author: Mathias Krause Date: Tue Nov 12 15:11:47 2013 -0800 ipc, msg: fix message length check for negative values commit 4e9b45a19241354daec281d7a785739829b52359 upstream. On 64 bit systems the test for negative message sizes is bogus as the size, which may be positive when evaluated as a long, will get truncated to an int when passed to load_msg(). So a long might very well contain a positive value but when truncated to an int it would become negative. That in combination with a small negative value of msg_ctlmax (which will be promoted to an unsigned type for the comparison against msgsz, making it a big positive value and therefore make it pass the check) will lead to two problems: 1/ The kmalloc() call in alloc_msg() will allocate a too small buffer as the addition of alen is effectively a subtraction. 2/ The copy_from_user() call in load_msg() will first overflow the buffer with userland data and then, when the userland access generates an access violation, the fixup handler copy_user_handle_tail() will try to fill the remainder with zeros -- roughly 4GB. That almost instantly results in a system crash or reset. ,-[ Reproducer (needs to be run as root) ]-- | #include | #include | #include | #include | | int main(void) { | long msg = 1; | int fd; | | fd = open("/proc/sys/kernel/msgmax", O_WRONLY); | write(fd, "-1", 2); | close(fd); | | msgsnd(0, &msg, 0xfffffff0, IPC_NOWAIT); | | return 0; | } '--- Fix the issue by preventing msgsz from getting truncated by consistently using size_t for the message length. This way the size checks in do_msgsnd() could still be passed with a negative value for msg_ctlmax but we would fail on the buffer allocation in that case and error out. Also change the type of m_ts from int to size_t to avoid similar nastiness in other code paths -- it is used in similar constructs, i.e. signed vs. unsigned checks. It should never become negative under normal circumstances, though. Setting msg_ctlmax to a negative value is an odd configuration and should be prevented. As that might break existing userland, it will be handled in a separate commit so it could easily be reverted and reworked without reintroducing the above described bug. Hardening mechanisms for user copy operations would have catched that bug early -- e.g. checking slab object sizes on user copy operations as the usercopy feature of the PaX patch does. Or, for that matter, detect the long vs. int sign change due to truncation, as the size overflow plugin of the very same patch does. [akpm@linux-foundation.org: fix i386 min() warnings] Signed-off-by: Mathias Krause Cc: Pax Team Cc: Davidlohr Bueso Cc: Brad Spengler Cc: Manfred Spraul Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bfe84321327047afc355bcfc4c0bd30c25fddccc Author: Larry Finger Date: Sun Nov 10 22:11:16 2013 -0600 rtlwifi: rtl8192cu: Fix more pointer arithmetic errors commit eafbdde9c5629bea58df07275c5917eb42afbbe7 upstream. This driver uses a number of macros to get and set various fields in the RX and TX descriptors. To work correctly, a u8 pointer to the descriptor must be used; however, in some cases a descriptor structure pointer is used instead. In addition, a duplicated statement is removed. Signed-off-by: Larry Finger Reported-by: Mark Cave-Ayland Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit d6843050f97d777d843d113d3214cc04ca31bcca Author: Felipe Pena Date: Fri Oct 18 21:52:40 2013 -0300 rtlwifi: rtl8192se: Fix wrong assignment commit 3aef7dde8dcf09e0124f0a2665845a507331972b upstream. There is a typo in the struct member name on assignment when checking rtlphy->current_chan_bw == HT_CHANNEL_WIDTH_20_40, the check uses pwrgroup_ht40 for bound limit and uses pwrgroup_ht20 when assigning instead. Signed-off-by: Felipe Pena Acked-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit dea4a8294ab66e105ed689e9ea3f2b2c0e0d4101 Author: Mark Cave-Ayland Date: Sat Nov 2 14:28:35 2013 -0500 rtlwifi: Fix endian error in extracting packet type commit 0c5d63f0ab6728f05ddefa25aff55e31297f95e6 upstream. All of the rtlwifi drivers have an error in the routine that tests if the data is "special". If it is, the subsequant transmission will be at the lowest rate to enhance reliability. The 16-bit quantity is big-endian, but was being extracted in native CPU mode. One of the effects of this bug is to inhibit association under some conditions as the TX rate is too high. Based on suggestions by Joe Perches, the entire routine is rewritten. One of the local headers contained duplicates of some of the ETH_P_XXX definitions. These are deleted. Signed-off-by: Larry Finger Cc: Mark Cave-Ayland Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit aaa3a8c7685d7ce2b779e89f25109e27e0c7c2a7 Author: Larry Finger Date: Wed Sep 25 12:57:48 2013 -0500 rtlwifi: rtl8188ee: Fix smatch warning in rtl8188ee/hw.c commit dab3df5e88b979f8d09860f873ccfaa7a55758d2 upstream. Smatch lists the following: CHECK drivers/net/wireless/rtlwifi/rtl8188ee/hw.c drivers/net/wireless/rtlwifi/rtl8188ee/hw.c:149 _rtl88ee_set_fw_clock_on() info: ignoring unreachable code. drivers/net/wireless/rtlwifi/rtl8188ee/hw.c:149 _rtl88ee_set_fw_clock_on() info: ignoring unreachable code. This info message is the result of a real error due to a missing break statement in a "while (1)" loop. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 7135a8a100fb1bc8d15f90a31e72faccdb4d7118 Author: Ryan Mallon Date: Tue Nov 12 15:08:51 2013 -0800 vsprintf: check real user/group id for %pK commit 312b4e226951f707e120b95b118cbc14f3d162b2 upstream. Some setuid binaries will allow reading of files which have read permission by the real user id. This is problematic with files which use %pK because the file access permission is checked at open() time, but the kptr_restrict setting is checked at read() time. If a setuid binary opens a %pK file as an unprivileged user, and then elevates permissions before reading the file, then kernel pointer values may be leaked. This happens for example with the setuid pppd application on Ubuntu 12.04: $ head -1 /proc/kallsyms 00000000 T startup_32 $ pppd file /proc/kallsyms pppd: In file /proc/kallsyms: unrecognized option 'c1000000' This will only leak the pointer value from the first line, but other setuid binaries may leak more information. Fix this by adding a check that in addition to the current process having CAP_SYSLOG, that effective user and group ids are equal to the real ids. If a setuid binary reads the contents of a file which uses %pK then the pointer values will be printed as NULL if the real user is unprivileged. Update the sysctl documentation to reflect the changes, and also correct the documentation to state the kptr_restrict=0 is the default. This is a only temporary solution to the issue. The correct solution is to do the permission check at open() time on files, and to replace %pK with a function which checks the open() time permission. %pK uses in printk should be removed since no sane permission check can be done, and instead protected by using dmesg_restrict. Signed-off-by: Ryan Mallon Cc: Kees Cook Cc: Alexander Viro Cc: Joe Perches Cc: "Eric W. Biederman" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 922b22ffb72220e659e58fec784e11dec9922ec4 Author: Shan Hai Date: Mon Oct 28 16:08:01 2013 +0800 drivers/libata: Set max sector to 65535 for Slimtype DVD A DS8A9SH drive commit 0523f037f65dba10191b0fa9c51266f90ba64630 upstream. The "Slimtype DVD A DS8A9SH" drive locks up with following backtrace when the max sector is smaller than 65535 bytes, fix it by adding a quirk to set the max sector to 65535 bytes. INFO: task flush-11:0:663 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. flush-11:0 D 00000000ffff5ceb 0 663 2 0x00000000 ffff88026d3b1710 0000000000000046 0000000000000001 0000000000000000 ffff88026f2530c0 ffff88026d365860 ffff88026d3b16e0 ffffffff812ffd52 ffff88026d4fd3d0 0000000100000001 ffff88026d3b16f0 ffff88026d3b1fd8 Call Trace: [] ? cfq_may_queue+0x52/0xf0 [] schedule+0x18/0x30 [] io_schedule+0x42/0x60 [] get_request_wait+0xeb/0x1f0 [] ? autoremove_wake_function+0x0/0x40 [] ? elv_merge+0x42/0x210 [] __make_request+0x8e/0x4e0 [] generic_make_request+0x21e/0x5e0 [] submit_bio+0x5d/0xd0 [] submit_bh+0xf2/0x130 [] __block_write_full_page+0x1dc/0x3a0 [] ? end_buffer_async_write+0x0/0x120 [] ? blkdev_get_block+0x0/0x70 [] ? blkdev_get_block+0x0/0x70 [] ? end_buffer_async_write+0x0/0x120 [] block_write_full_page_endio+0xde/0x100 [] block_write_full_page+0x10/0x20 [] blkdev_writepage+0x13/0x20 [] __writepage+0x15/0x40 [] write_cache_pages+0x1cf/0x3e0 [] ? __writepage+0x0/0x40 [] generic_writepages+0x22/0x30 [] do_writepages+0x1f/0x40 [] writeback_single_inode+0xe7/0x3b0 [] writeback_sb_inodes+0x184/0x280 [] writeback_inodes_wb+0x6b/0x1a0 [] wb_writeback+0x23b/0x2a0 [] wb_do_writeback+0x17d/0x190 [] bdi_writeback_task+0x4b/0xe0 [] ? bdi_start_fn+0x0/0x100 [] bdi_start_fn+0x81/0x100 [] ? bdi_start_fn+0x0/0x100 [] kthread+0x8e/0xa0 [] ? finish_task_switch+0x54/0xc0 [] kernel_thread_helper+0x4/0x10 [] ? kthread+0x0/0xa0 [] ? kernel_thread_helper+0x0/0x10 The above trace was triggered by "dd if=/dev/zero of=/dev/sr0 bs=2048 count=32768" Signed-off-by: Shan Hai Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 929742b8d766876b34f92fd3e40aed8d189dade4 Author: Gwendal Grignou Date: Fri Oct 25 16:28:57 2013 -0700 libata: Fix display of sata speed commit 3e85c3ecbc520751324a191d23bb94873ed01b10 upstream. 6.0 Gbps link speed was not decoded properly: speed was reported at 3.0 Gbps only. Tested: On a machine where libata reports 6.0 Gbps in /var/log/messages: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Before: cat /sys/class/ata_link/link1/sata_spd 3.0 Gbps After: cat /sys/class/ata_link/link1/sata_spd 6.0 Gbps Signed-off-by: Gwendal Grignou Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit a878002b71bf238810b6e2a885455601222ac140 Author: Dan Carpenter Date: Thu Nov 7 10:56:51 2013 +0300 gpio: rcar: NULL dereference on error in probe() commit 0c8aab8e65e450f2bfea494c1b6a86ded653f88c upstream. It's not obvious from the label name but "err1" tries to release "p->irq_domain" which leads to a NULL dereference. Fixes: 119f5e448d32 ('gpio: Renesas R-Car GPIO driver V3') Signed-off-by: Dan Carpenter Acked-by: Magnus Damm Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit aeb94017f672ba2ca8592e7d91fbcc0c3ff63031 Author: Dan Carpenter Date: Thu Nov 7 10:50:19 2013 +0300 gpio: mvebu: make mvchip->irqbase signed for error handling commit d535922691fc026479fcc03e78ac3d931a54e75a upstream. There is a bug in mvebu_gpio_probe() where we do: mvchip->irqbase = irq_alloc_descs(-1, 0, ngpios, -1); if (mvchip->irqbase < 0) { The problem is that mvchip->irqbase is unsigned so the error handling doesn't work. I have changed it to be a regular int. Signed-off-by: Dan Carpenter Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit af8888ac768fbe9d2e526329e632700c1ff6b2fa Author: Tony Lindgren Date: Mon Nov 18 15:22:49 2013 -0800 gpio: twl4030: Fix regression for twl gpio output commit 0b2aa8bed3e13892fcac77e4f50ec6e80125469d upstream. Commit c111feabe2e2 (gpio: twl4030: Cache the direction and output states in private data) improved things in general, but caused a regression for setting the GPIO output direction. The change reorganized twl_direction_out() and twl_set() and swapped the function names around in the process. While doing that, a bug got introduced that's not obvious while reading the patch as it appears as no change to the code. The bug is we now call function twl4030_set_gpio_dataout() twice in both twl_direction_out() and twl_set(). Instead, we should first call twl_direction_out() in twl_direction_out() followed by twl4030_set_gpio_dataout() in twl_set(). This regression probably has gone unnoticed for a long time as the bootloader may have set the GPIO direction properly in many cases. This fixes at least the LCD panel not turning on omap3 LDP for example. Cc: linux-gpio@vger.kernel.org Reviewed-by: Peter Ujfalusi Acked-by: Linus Walleij Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit e7b2933095b228e2e668bd191b4fddeff4f21815 Author: Stephen Warren Date: Mon Nov 25 20:35:42 2013 -0700 ARM: bcm2835: add missing #xxx-cells to I2C nodes commit a31ab44ef5d07c6707df4a9ad2c8affd2d62ff4b upstream. The I2C controller node needs #address-cells and #size-cells properties, but these are currently missing. Add them. This allows child nodes to be parsed correctly. Signed-off-by: Stephen Warren Signed-off-by: Olof Johansson Signed-off-by: Greg Kroah-Hartman commit c1acc1db4649a44b38ded7d432a6d2fd24526b1b Author: Doug Anderson Date: Wed Oct 23 06:11:01 2013 -0700 ARM: dts: Add max77686 RTC interrupt to cros5250-common commit c61248afa8190ae3f47ee67f46e3c9b584a73d31 upstream. Without the interrupt you'll get problems if you enable CONFIG_RTC_DRV_MAX77686. Setup the interrupt properly in the device tree. Signed-off-by: Doug Anderson Tested-by: Marc Zyngier Signed-off-by: Olof Johansson Signed-off-by: Greg Kroah-Hartman commit d9d317655d19d5cb583333e5643b0ada4ef5b48e Author: Ionut Nicu Date: Fri Oct 11 14:17:10 2013 +0200 i2c: mux: gpio: use gpio_set_value_cansleep() commit 250ad590d6f12d93f4d85be305b0a598d609232e upstream. Some gpio chips may have get/set operations that can sleep. gpio_set_value() only works for chips which do not sleep, for the others we will get a kernel warning. Using gpio_set_value_cansleep() will work for both chips that do sleep and those who don't. Signed-off-by: Ionut Nicu Acked-by: Peter Korsgaard Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 12ea4499abf3cabc3dcea7efed13d15b99930405 Author: Ionut Nicu Date: Fri Oct 11 12:09:57 2013 +0200 i2c: mux: gpio: use reg value for i2c_add_mux_adapter commit 8c0ec2500eeb89749341884a972860d7f9e56f9c upstream. The i2c-mux driver requires that the chan_id parameter passed to the i2c_add_mux_adapter() function is equal to the reg value for that adapter: for_each_child_of_node(mux_dev->of_node, child) { ret = of_property_read_u32(child, "reg", ®); if (ret) continue; if (chan_id == reg) { priv->adap.dev.of_node = child; break; } } The i2c-mux-gpio driver uses an internal logical index for chan_id when calling i2c_add_mux_adapter() instead of using the reg value. Because of this, there will problems in selecting the right adapter when the i2c-mux-gpio's index into mux->data.values doesn't match the reg value. An example of such a case: mux->data.values = { 1, 0 } For chan_id = 0, i2c-mux will bind the adapter to the of_node with reg = <0>, but when it will call the select() callback with chan_id set to 0, the i2c-mux-gpio will use it as an index into mux->data.values and it will actually select the bus with reg = <1>. Signed-off-by: Ionut Nicu Acked-by: Alexander Sverdlin Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 2e3179de1d002a148f7e540e30f7227111992421 Author: Marc Kleine-Budde Date: Fri Sep 27 12:15:05 2013 +0200 can: flexcan: fix flexcan_chip_start() on imx6 commit 0d1862ea1a5bb876cf05555a7307080cb75bf379 upstream. In the flexcan_chip_start() function first the flexcan core is going through the soft reset sequence, then the RX FIFO is enabled. With the hardware is put into FIFO mode, message buffers 1...7 are reserved by the FIFO engine. The remaining message buffers are in reset default values. This patch removes the bogus initialization of the message buffers, as it causes an imprecise external abort on imx6. Reported-by: Lothar Waßmann Tested-by: Lothar Waßmann [mkl: adjusted context for stable] Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 8f7e823f18150b6767e5e03ede80a0896a4adf06 Author: Helge Deller Date: Mon Oct 14 21:04:13 2013 +0200 parisc: break out SOCK_NONBLOCK define to own asm header file commit 38c7937379276a5ea8c54481205003af2f2b5694 upstream. Break SOCK_NONBLOCK out to its own asm-file as other arches do. This fixes build errors with auditd and probably other packages. Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit cc447613b50aa83ff466878dd6245153b1cfb95c Author: Ilija Hadzic Date: Tue Nov 12 15:11:45 2013 -0800 devpts: plug the memory leak in kill_sb commit 66da0e1f9034140ae2f571ef96e254a25083906c upstream. When devpts is unmounted, there may be a no-longer-used IDR tree hanging off the superblock we are about to kill. This needs to be cleaned up before destroying the SB. The leak is usually not a big deal because unmounting devpts is typically done when shutting down the whole machine. However, shutting down an LXC container instead of a physical machine exposes the problem (the garbage is detectable with kmemleak). Signed-off-by: Ilija Hadzic Cc: Sukadev Bhattiprolu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 884181395dc053f31759ae0bd0c8ff88d143eb4e Author: Roel Kluin Date: Mon Oct 14 01:27:27 2013 +0200 pinctrl: dove: unset twsi option3 for gconfig as well commit 6d0a4ed2b90a12e1403d3e7d9d8c2cc7fdc301b5 upstream. This fixes a typo which left twsi config3 option enabled. Signed-off-by: Roel Kluin Acked-by: Sebastian Hesselbarth Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 4501cfd0e3a1c06e5539c9f806866f8408232393 Author: KOSAKI Motohiro Date: Mon Oct 14 17:33:16 2013 -0400 alarmtimer: return EINVAL instead of ENOTSUPP if rtcdev doesn't exist commit 98d6f4dd84a134d942827584a3c5f67ffd8ec35f upstream. Fedora Ruby maintainer reported latest Ruby doesn't work on Fedora Rawhide on ARM. (http://bugs.ruby-lang.org/issues/9008) Because of, commit 1c6b39ad3f (alarmtimers: Return -ENOTSUPP if no RTC device is present) intruduced to return ENOTSUPP when clock_get{time,res} can't find a RTC device. However this is incorrect. First, ENOTSUPP isn't exported to userland (ENOTSUP or EOPNOTSUP are the closest userland equivlents). Second, Posix and Linux man pages agree that clock_gettime and clock_getres should return EINVAL if clk_id argument is invalid. While the arugment that the clockid is valid, but just not supported on this hardware could be made, this is just a technicality that doesn't help userspace applicaitons, and only complicates error handling. Thus, this patch changes the code to use EINVAL. Cc: Thomas Gleixner Cc: Frederic Weisbecker Reported-by: Vit Ondruch Signed-off-by: KOSAKI Motohiro [jstultz: Tweaks to commit message to include full rational] Signed-off-by: John Stultz Signed-off-by: Greg Kroah-Hartman commit 9dfd005a3f4e1c648cb4aa1dc70604bb370c5e7b Author: Michael Hudson-Doyle Date: Thu Oct 31 16:47:45 2013 -0700 perf tools: Remove cast of non-variadic function to variadic commit 53805eca3d89b095062c11a6798689bb0af09216 upstream. The 4fb71074a570 (perf ui/hist: Consolidate hpp helpers) cset introduced a cast of percent_color_snprintf to a function pointer type with varargs. Change percent_color_snprintf to be variadic and remove the cast. The symptom of this was all percentages being reported as 0.00% in perf report --stdio output on the armhf arch. Signed-off-by: Michael Hudson-Doyle Acked-by: Namhyung Kim Acked-by: Will Deacon Cc: Jean Pihet Cc: Jiri Olsa Cc: Will Deacon Link: http://lkml.kernel.org/r/87zjppvw7y.fsf@canonical.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit f9bdb31ae29c0cf60b35ed83c98e7a4043873336 Author: Charles Keepax Date: Tue Nov 19 10:51:29 2013 +0000 ASoC: wm5110: Add post SYSCLK register patch for rev D chip commit f69f86b1ba6493126a7f093a65a8952bcb183de2 upstream. Certain registers require patching after the SYSCLK has been brought up add support for this into the CODEC driver. Signed-off-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d2099a50522c4002a2888c70a39560aab20d0926 Author: Richard Fitzgerald Date: Wed Nov 20 14:37:09 2013 +0000 ASoC: arizona: Set FLL to free-run before disabling commit 3e68ce1bc72e5d6615677ec5a8b0a9bcb6c7a490 upstream. The FLL must be placed into free-run mode before disabling to allow it to entirely shut down. Signed-off-by: Richard Fitzgerald Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b63d5e491bbbab6f97cc4432334d3a2539cd4a1c Author: Oskar Schirmer Date: Tue Nov 12 15:46:38 2013 +0000 ASoC: fsl: imx-pcm-fiq: omit fiq counter to avoid harm in unbalanced situations commit fc7dc61d9a87011aaf8a6eb3144ebf9552adf5d2 upstream. Unbalanced calls to snd_imx_pcm_trigger() may result in endless FIQ activity and thus provoke eternal sound. While on the first glance, the switch statement looks pretty symmetric, the SUSPEND/RESUME pair is not: the suspend case comes along snd_pcm_suspend_all(), which for fsl/imx-pcm-fiq is called only at snd_soc_suspend(), but the resume case originates straight from the SNDRV_PCM_IOCTL_RESUME. This way userland may provoke an unbalanced resume, which might cause the fiq_enable counter to increase and never return to zero again, so eventually imx_pcm_fiq is never disabled. Simply removing the fiq_enable will solve the problem, as long as one never goes play and capture game simultaneously, but beware trying both at once, the early TRIGGER_STOP will cut off the other activity prematurely. So now playing and capturing is scrutinized separately, instead of by counting. Signed-off-by: Oskar Schirmer Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit ddf2f8881b5a608c9a55f3944b6e39a3decc5e4b Author: Takashi Iwai Date: Wed Nov 13 17:15:00 2013 +0100 ASoC: blackfin: Fix missing break commit afed4dbe3a043dbd833a53b6b4951e155708afd2 upstream. Fixes: 4b2ffc205cb9 ('ASoC: Blackfin I2S: add 8-bit sample support') Reported-by: David Binderman Signed-off-by: Takashi Iwai Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 59d5384899d0e8567dfd7875d4e174cce311de63 Author: Nicolin Chen Date: Thu Nov 14 11:59:21 2013 +0800 ASoC: wm8962: Turn on regcache_cache_only before disabling regulator commit 50bfcf2df2fadf77e143d6099150e6fa7ef4d78c upstream. It's safer to turn on regcache_cache_only before disabling regulator since the driver will turn off the regcache_cache_only after enabling regulator. If we remain cache_only false, some command like 'amixer cset' would get failure if being run before wm8962_resume(). Signed-off-by: Nicolin Chen Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 8559f25c6b72ebed12cf42ec60934b7ccdc96098 Author: Brian Austin Date: Thu Nov 14 11:46:12 2013 -0600 ASoC: cs42l52: Correct MIC CTL mask commit 3d800c6d75b8c92fa928a0bcaf95cd7ac5fd1ce5 upstream. The mask for CS42L52_MIC_CTL_TYPE_MASK was wrong keeping the mic config from being set correctly. Signed-off-by: Brian Austin Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2807631534a8356005fd965fa3927de95fa95004 Author: Phil Edworthy Date: Thu Oct 31 23:06:17 2013 -0700 ASoC: ak4642: prevent un-necessary changes to SG_SL1 commit 7b5bfb82882b9b1c8423ce0ed6852ca3762d967a upstream. If you record the sound during playback, the playback sound becomes silent. Modify so that the codec driver does not clear SG_SL1::DACL bit which is controlled under widget Signed-off-by: Phil Edworthy Signed-off-by: Kuninori Morimoto Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 06909ca39fbac8b66421dbf8397d029879e81cfa Author: Johan Hovold Date: Tue Nov 12 15:09:38 2013 -0800 backlight: atmel-pwm-bl: fix reported brightness commit 185d91442550110db67a7dc794a32efcea455a36 upstream. The driver supports 16-bit brightness values, but the value returned from get_brightness was truncated to eight bits. Signed-off-by: Johan Hovold Cc: Jingoo Han Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fe619f64b93df39d3d6f4b60cd9fa3474e61ce5f Author: Johan Hovold Date: Tue Nov 12 15:09:39 2013 -0800 backlight: atmel-pwm-bl: fix gpio polarity in remove commit ad5066d4c2b1d696749f8d7816357c23b648c4d3 upstream. Make sure to honour gpio polarity also at remove so that the backlight is actually disabled on boards with active-low enable pin. Signed-off-by: Johan Hovold Acked-by: Jingoo Han Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 368289b373137db191a35ed9e6865e42ff7d0263 Author: Malcolm Priestley Date: Thu Nov 7 21:49:04 2013 +0000 staging: vt6656: [BUG] Fix for TX USB resets from vendors driver. commit 9df682927c2e3a92f43803d6b52095992e3b2ab8 upstream. This fixes resets on heavy TX data traffic. Vendor driver VT6656_Linux_src_v1.21.03_x86_11.04.zip http://www.viaembedded.com/servlet/downloadSvl?id=1890&download_file_id=14704 This is GPL-licensed code. original code BBbVT3184Init ... //2007-0725, RobertChang add, Enable Squelch detect reset option(SQ_RST_Opt), USB (register4, bit1) CONTROLnsRequestIn(pDevice, MESSAGE_TYPE_READ, (WORD)0x600+4, // USB's Reg4's bit1 MESSAGE_REQUEST_MEM, 1, (PBYTE) &byData); byData = byData|2 ; CONTROLnsRequestOut(pDevice, MESSAGE_TYPE_WRITE, (WORD)0x600+4, // USB's Reg4's bit1 MESSAGE_REQUEST_MEM, 1, (PBYTE) &byData); return TRUE;//ntStatus; .... A back port patch is needed for kernels less than 3.10. Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman commit 6871b98011fd07991f9259c9be339b1bde34d527 Author: Olav Haugan Date: Fri Nov 22 09:30:41 2013 -0800 staging: zsmalloc: Ensure handle is never 0 on success commit 67296874eb1cc80317bf2a8fba22b494e21eb29b upstream. zsmalloc encodes a handle using the pfn and an object index. On hardware platforms with physical memory starting at 0x0 the pfn can be 0. This causes the encoded handle to be 0 and is incorrectly interpreted as an allocation failure. This issue affects all current and future SoCs with physical memory starting at 0x0. All MSM8974 SoCs which includes Google Nexus 5 devices are affected. To prevent this false error we ensure that the encoded handle will not be 0 when allocation succeeds. Signed-off-by: Olav Haugan Signed-off-by: Greg Kroah-Hartman commit 51de4ecd7c25fae75eb8d0936a443119e13384f9 Author: Greg Kroah-Hartman Date: Wed Nov 27 09:32:49 2013 -0800 Staging: tidspbridge: disable driver commit 930ba4a374b96560ef9fde2145cdc454a164ddcc upstream. There seems to be no active maintainer for the driver, and there is an unfixed security bug, so disable the driver for now. Hopefully someone steps up to be the maintainer, and works to get this out of staging, otherwise it will be deleted soon. Reported-by: Nico Golde Reported-by: Dan Carpenter Cc: Omar Ramirez Luna Cc: Omar Ramirez Luna Cc: Kanigeri, Hari Cc: Ameya Palande Cc: Guzman Lugo, Fernando Cc: Hebbar, Shivananda Cc: Ramos Falcon, Ernesto Cc: Felipe Contreras Cc: Anna, Suman Cc: Gupta, Ramesh Cc: Gomez Castellanos, Ivan Cc: Andy Shevchenko Cc: Armando Uribe De Leon Cc: Deepak Chitriki Cc: Menon, Nishanth Cc: Phil Carmody Cc: Ohad Ben-Cohen Cc: stable Signed-off-by: Greg Kroah-Hartman commit c51fe27dc3cc7b43ee09edfb192d01ae6fa1c0cf Author: Jiada Wang Date: Wed Oct 30 04:25:51 2013 -0700 ARM: i.MX6q: fix the wrong parent of can_root clock commit 9b3d423707c3b1f6633be1be7e959623e10c596b upstream. instead of pll3_usb_otg the parent of can_root clock should be pll3_60m. Signed-off-by: Jiada Wang Signed-off-by: Shawn Guo Cc: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 6ce3ee9af1ad697c71766067ffa1a35352dfdcfd Author: Johan Hovold Date: Wed Oct 16 11:56:15 2013 +0200 ARM: at91: fix hanged boot due to early rtt-interrupt commit 94c4c79f2f1acca6e69a50bff5a7d9027509c16b upstream. Make sure the RTT-interrupts are masked at boot by adding a new helper function to be used at SOC-init. This fixes hanged boot on all AT91 SOCs with an RTT, for example, if an RTT-alarm goes off after a non-clean shutdown (e.g. when using RTC wakeup). The RTC and RTT-peripherals are powered by backup power (VDDBU) (on all AT91 SOCs but RM9200) and are not reset on wake-up, user, watchdog or software reset. This means that their interrupts may be enabled during early boot if, for example, they where not disabled during a previous shutdown (e.g. due to a buggy driver or a non-clean shutdown such as a user reset). Furthermore, an RTC or RTT-alarm may also be active. The RTC and RTT-interrupts use the shared system-interrupt line, which is also used by the PIT, and if an interrupt occurs before a handler (e.g. RTC-driver) has been installed this leads to the system interrupt being disabled and prevents the system from booting. Note that when boot hangs due to an early RTC or RTT-interrupt, the only way to get the system to start again is to remove the backup power (e.g. battery) or to disable the interrupt manually from the bootloader. In particular, a user reset is not sufficient. Signed-off-by: Johan Hovold Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman commit 54f830b7337ed016b6708cf5a2ac297d4cee227d Author: Johan Hovold Date: Wed Oct 16 11:56:14 2013 +0200 ARM: at91: fix hanged boot due to early rtc-interrupt commit 6de714c21a8ea315fffba6a93bbe537f4c1bf4f0 upstream. Make sure the RTC-interrupts are masked at boot by adding a new helper function to be used at SOC-init. This fixes hanged boot on all AT91 SOCs with an RTC (but RM9200), for example, after a reset during an RTC-update or if an RTC-alarm goes off after shutdown (e.g. when using RTC wakeup). The RTC and RTT-peripherals are powered by backup power (VDDBU) (on all AT91 SOCs but RM9200) and are not reset on wake-up, user, watchdog or software reset. This means that their interrupts may be enabled during early boot if, for example, they where not disabled during a previous shutdown (e.g. due to a buggy driver or a non-clean shutdown such as a user reset). Furthermore, an RTC or RTT-alarm may also be active. The RTC and RTT-interrupts use the shared system-interrupt line, which is also used by the PIT, and if an interrupt occurs before a handler (e.g. RTC-driver) has been installed this leads to the system interrupt being disabled and prevents the system from booting. Note that when boot hangs due to an early RTC or RTT-interrupt, the only way to get the system to start again is to remove the backup power (e.g. battery) or to disable the interrupt manually from the bootloader. In particular, a user reset is not sufficient. Signed-off-by: Johan Hovold Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman commit 208a11c4412dee65ccf76503fb980d7fb3c5c743 Author: Jonathan Austin Date: Thu Aug 29 18:41:11 2013 +0100 ARM: integrator_cp: Set LCD{0,1} enable lines when turning on CLCD commit 30aeadd44deea3f3b0df45b9a70ee0fd5f8d6dc2 upstream. This turns on the internal integrator LCD display(s). It seems that the code to do this got lost in refactoring of the CLCD driver. Signed-off-by: Jonathan Austin Acked-by: Linus Walleij Signed-off-by: Olof Johansson Signed-off-by: Greg Kroah-Hartman commit 45a8ae89ee0f4d4b33f75b2e619f4112810ff822 Author: Marc Zyngier Date: Mon Nov 4 11:42:29 2013 +0100 ARM: 7876/1: clear Thumb-2 IT state on exception handling commit e16b31bf47738f4498d7ce632e12d7d2a6a2492a upstream. The exception handling code fails to clear the IT state, potentially leading to incorrect execution of the fixup if the size of the IT block is more than one. Let fixup_exception do the IT sanitizing if a fixup has been found, and restore CPSR from the stack when returning from a data abort. Cc: Will Deacon Reviewed-by: Catalin Marinas Signed-off-by: Marc Zyngier Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 853e96428c8e8f2ac95e1b6a144114340694a244 Author: Russell King Date: Wed Oct 16 00:09:02 2013 +0100 ARM: sa11x0/assabet: ensure CS2 is configured appropriately commit f3964fe1c9d9a887d65faf594669852e4dec46e0 upstream. The CS2 region contains the Assabet board configuration and status registers, which are 32-bit. Unfortunately, some boot loaders do not configure this region correctly, leaving it setup as a 16-bit region. Fix this. Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 6ca235a5703b6d30df5d4c8d47d6f8d6695d46fd Author: Markus Pargmann Date: Thu Oct 17 09:18:38 2013 +0200 ARM: OMAP2+: irq, AM33XX add missing register check commit 0bebda684857f76548ea48c8886785198701d8d3 upstream. am33xx has a INTC_PENDING_IRQ3 register that is not checked for pending interrupts. This patch adds AM33XX to the ifdef of SOCs that have to check this register. Signed-off-by: Markus Pargmann Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit c44d83ec7018dd23255c23897492b3c8d43785df Author: Helge Deller Date: Wed Nov 6 23:38:59 2013 +0100 parisc: sticon - unbreak on 64bit kernel commit 0219132fe7c26574371232b50db085573f6fbd3f upstream. STI text console (sticon) was broken on 64bit machines with more than 4GB RAM and this lead in some cases to a kernel crash. Since sticon uses the 32bit STI API it needs to keep pointers to memory below 4GB. But on a 64bit kernel some memory regions (e.g. the kernel stack) might be above 4GB which then may crash the kernel in the STI functions. Additionally sticon didn't selected the built-in framebuffer fonts by default. This is now fixed. On a side-note: Theoretically we could enhance the sticon driver to use the 64bit STI API. But - beside the fact that some machines don't provide a 64bit STI ROM - this would just add complexity. Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman