commit bce42abf2e94d34c3a0cff4bf51740d27792dd88 Author: Jiri Slaby Date: Sat May 16 09:27:10 2015 +0200 Linux 3.12.43 commit b87840a44e4a2e94fbe84c4437bcd401165d51c0 Author: Lv Zheng Date: Mon Apr 13 11:48:52 2015 +0800 ACPICA: Utilities: Cleanup to remove useless ACPI_PRINTF/FORMAT_xxx helpers. commit 1d0a0b2f6df2bf2643fadc990eb143361eca6ada upstream. ACPICA commit b60612373a4ef63b64a57c124576d7ddb6d8efb6 For physical addresses, since the address may exceed 32-bit address range after calculation, we should use 0x%8.8X%8.8X instead of ACPI_PRINTF_UINT and ACPI_FORMAT_UINT64() instead of ACPI_FORMAT_NATIVE_UINT()/ACPI_FORMAT_TO_UINT(). This patch also removes above replaced macros as there are no users. This is a preparation to switch acpi_physical_address to 64-bit on 32-bit kernel builds. Link: https://github.com/acpica/acpica/commit/b6061237 Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki Signed-off-by: Dirk Behme Signed-off-by: George G. Davis Signed-off-by: Jiri Slaby commit 789d5040e3060a6d8682cf3a2952b3c842ed4d3a Author: Lv Zheng Date: Mon Apr 13 11:48:46 2015 +0800 ACPICA: Utilities: Cleanup to convert physical address printing formats. commit cc2080b0e5a7c6c33ef5e9ffccbc2b8f6f861393 upstream. ACPICA commit 7f06739db43a85083a70371c14141008f20b2198 For physical addresses, since the address may exceed 32-bit address range after calculation, we should use %8.8X%8.8X (see ACPI_FORMAT_UINT64()) to convert the %p formats. This is a preparation to switch acpi_physical_address to 64-bit on 32-bit kernel builds. Link: https://github.com/acpica/acpica/commit/7f06739d Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki Signed-off-by: Dirk Behme [gdavis: Apply changes to drivers/acpi/acpica/{tbutils,tbxfload}.c] Signed-off-by: George G. Davis Signed-off-by: Jiri Slaby commit 99295520a9e3babeae49caa9b4fa87fc088821f2 Author: Lv Zheng Date: Mon Apr 13 11:48:37 2015 +0800 ACPICA: Utilities: Cleanup to enforce ACPI_PHYSADDR_TO_PTR()/ACPI_PTR_TO_PHYSADDR(). commit 6d3fd3cc33d50e4c0d0c0bd172de02caaec3127c upstream. ACPICA commit 154f6d074dd38d6ebc0467ad454454e6c5c9ecdf There are code pieces converting pointers using "(acpi_physical_address) x" or "ACPI_CAST_PTR (t, x)" formats, this patch cleans up them. Known issues: 1. Cleanup of "(ACPI_PHYSICAL_ADDRRESS) x" for a table field For the conversions around the table fields, it is better to fix it with alignment also fixed. So this patch doesn't modify such code. There should be no functional problem by leaving them unchanged. Link: https://github.com/acpica/acpica/commit/154f6d07 Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki Signed-off-by: Dirk Behme Signed-off-by: George G. Davis Signed-off-by: Jiri Slaby commit 6224888940730d22169ef6557aa1833e26a63c39 Author: Lv Zheng Date: Mon Apr 13 11:48:18 2015 +0800 ACPICA: Tables: Change acpi_find_root_pointer() to use acpi_physical_address. commit f254e3c57b9d952e987502aefa0804c177dd2503 upstream. ACPICA commit 7d9fd64397d7c38899d3dc497525f6e6b044e0e3 OSPMs like Linux expect an acpi_physical_address returning value from acpi_find_root_pointer(). This triggers warnings if sizeof (acpi_size) doesn't equal to sizeof (acpi_physical_address): drivers/acpi/osl.c:275:3: warning: passing argument 1 of 'acpi_find_root_pointer' from incompatible pointer type [enabled by default] In file included from include/acpi/acpi.h:64:0, from include/linux/acpi.h:36, from drivers/acpi/osl.c:41: include/acpi/acpixf.h:433:1: note: expected 'acpi_size *' but argument is of type 'acpi_physical_address *' This patch corrects acpi_find_root_pointer(). Link: https://github.com/acpica/acpica/commit/7d9fd643 Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki Signed-off-by: Dirk Behme Signed-off-by: George G. Davis Signed-off-by: Jiri Slaby commit fae12cf4a9a5ba5dd95f3bc9dc39c75287d51414 Author: Alexey Khoroshilov Date: Sat Apr 18 02:53:25 2015 +0300 sound/oss: fix deadlock in sequencer_ioctl(SNDCTL_SEQ_OUTOFBAND) commit bc26d4d06e337ade069f33d3f4377593b24e6e36 upstream. A deadlock can be initiated by userspace via ioctl(SNDCTL_SEQ_OUTOFBAND) on /dev/sequencer with TMR_ECHO midi event. In this case the control flow is: sound_ioctl() -> case SND_DEV_SEQ: case SND_DEV_SEQ2: sequencer_ioctl() -> case SNDCTL_SEQ_OUTOFBAND: spin_lock_irqsave(&lock,flags); play_event(); -> case EV_TIMING: seq_timing_event() -> case TMR_ECHO: seq_copy_to_input() -> spin_lock_irqsave(&lock,flags); It seems that spin_lock_irqsave() around play_event() is not necessary, because the only other call location in seq_startplay() makes the call without acquiring spinlock. So, the patch just removes spinlocks around play_event(). By the way, it removes unreachable code in seq_timing_event(), since (seq_mode == SEQ_2) case is handled in the beginning. Compile tested only. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Signed-off-by: Takashi Iwai Cc: Willy Tarreau Signed-off-by: Jiri Slaby commit b1c8515067ef5a55542ae0fc114feb087fb0dd09 Author: Takeshi Kihara Date: Thu Apr 30 02:03:51 2015 +0900 mmc: sh_mmcif: Fix timeout value for command request commit bad4371d87d1d1ed1aecd9c9cc21c41ac3f289c8 upstream. f9fd54f22e ("mmc: sh_mmcif: Use msecs_to_jiffies() for host->timeout") changed the timeout value from 1000 jiffies to 1s. In the case where HZ is 1000 the values are the same. However, for smaller HZ values the timeout is now smaller, 1s instead of 10s in the case of HZ=100. Since the timeout occurs in spite of a normal data transfer a timeout of 10s seems more appropriate. This restores the previous timeout in the case where HZ=100 and results in an increase over the previous timeout for larger values of HZ. Fixes: f9fd54f22e ("mmc: sh_mmcif: Use msecs_to_jiffies() for host->timeout") Signed-off-by: Takeshi Kihara [horms: rewrote changelog to refer to HZ] Signed-off-by: Simon Horman Signed-off-by: Yoshihiro Kaneko Signed-off-by: Ulf Hansson Signed-off-by: Jiri Slaby commit e90f66563d7223315a1f54d0a91216d5d6313506 Author: Grygorii Strashko Date: Thu Apr 23 13:43:43 2015 +0300 mmc: core: add missing pm event in mmc_pm_notify to fix hib restore commit 184af16b09360d6273fd6160e6ff7f8e2482ef23 upstream. The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(), as result mmc_rescan() could be scheduled and executed at late hibernation restore stages when MMC device is suspended already - which, in turn, will lead to system crash on TI dra7-evm board: WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x258/0x374() 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in User mode during Functional access Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify(). Fixes: 4c2ef25fe0b8 (mmc: fix all hangs related to mmc/sd card...) Signed-off-by: Grygorii Strashko Signed-off-by: Ulf Hansson Signed-off-by: Jiri Slaby commit a9f6271231a37ca834571e12c066774454326e2f Author: Chuanxiao Dong Date: Tue Aug 12 12:01:30 2014 +0800 mmc: card: Don't access RPMB partitions for normal read/write commit 4e93b9a6abc0d028daf3c8a00cb77b679d8a4df4 upstream. During kernel boot, it will try to read some logical sectors of each block device node for the possible partition table. But since RPMB partition is special and can not be accessed by normal eMMC read / write CMDs, it will cause below error messages during kernel boot: ... mmc0: Got data interrupt 0x00000002 even though no data operation was in progress. mmcblk0rpmb: error -110 transferring data, sector 0, nr 32, cmd response 0x900, card status 0xb00 mmcblk0rpmb: retrying using single block read mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 end_request: I/O error, dev mmcblk0rpmb, sector 0 Buffer I/O error on device mmcblk0rpmb, logical block 0 end_request: I/O error, dev mmcblk0rpmb, sector 8 Buffer I/O error on device mmcblk0rpmb, logical block 1 end_request: I/O error, dev mmcblk0rpmb, sector 16 Buffer I/O error on device mmcblk0rpmb, logical block 2 end_request: I/O error, dev mmcblk0rpmb, sector 24 Buffer I/O error on device mmcblk0rpmb, logical block 3 ... This patch will discard the access request in eMMC queue if it is RPMB partition access request. By this way, it avoids trigger above error messages. Fixes: 090d25fe224c ("mmc: core: Expose access to RPMB partition") Signed-off-by: Yunpeng Gao Signed-off-by: Chuanxiao Dong Tested-by: Michael Shigorin Signed-off-by: Ulf Hansson Signed-off-by: Jiri Slaby commit fc2c7294f83544fabaa7f9e5cf45a74ccc91e198 Author: Doug Anderson Date: Fri May 1 09:01:27 2015 -0700 pinctrl: Don't just pretend to protect pinctrl_maps, do it for real commit c5272a28566b00cce79127ad382406e0a8650690 upstream. Way back, when the world was a simpler place and there was no war, no evil, and no kernel bugs, there was just a single pinctrl lock. That was how the world was when (57291ce pinctrl: core device tree mapping table parsing support) was written. In that case, there were instances where the pinctrl mutex was already held when pinctrl_register_map() was called, hence a "locked" parameter was passed to the function to indicate that the mutex was already locked (so we shouldn't lock it again). A few years ago in (42fed7b pinctrl: move subsystem mutex to pinctrl_dev struct), we switched to a separate pinctrl_maps_mutex. ...but (oops) we forgot to re-think about the whole "locked" parameter for pinctrl_register_map(). Basically the "locked" parameter appears to still refer to whether the bigger pinctrl_dev mutex is locked, but we're using it to skip locks of our (now separate) pinctrl_maps_mutex. That's kind of a bad thing(TM). Probably nobody noticed because most of the calls to pinctrl_register_map happen at boot time and we've got synchronous device probing. ...and even cases where we're asynchronous don't end up actually hitting the race too often. ...but after banging my head against the wall for a bug that reproduced 1 out of 1000 reboots and lots of looking through kgdb, I finally noticed this. Anyway, we can now safely remove the "locked" parameter and go back to a war-free, evil-free, and kernel-bug-free world. Fixes: 42fed7ba44e4 ("pinctrl: move subsystem mutex to pinctrl_dev struct") Signed-off-by: Doug Anderson Signed-off-by: Linus Walleij Signed-off-by: Jiri Slaby commit 1dda6bfdae9bc08af6aa90193bcd7cb36094e548 Author: Christian König Date: Thu May 7 15:19:24 2015 +0200 drm/radeon: more strictly validate the UVD codec commit d52cdfa4a0c6406bbfb33206341eaf1fb1555994 upstream. MPEG 2/4 are only supported since UVD3. Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit 0e60ce501de39fc149ffe63944732e1d035cc650 Author: Christian König Date: Thu May 7 15:19:23 2015 +0200 drm/radeon: make UVD handle checking more strict commit a1b403da70e038ca6c6c6fe434d1d873546873a3 upstream. Invalid messages can crash the hw otherwise. Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit 0863c19a3cbae70e8005d8d6a1b9a55ecc3f39ef Author: Christian König Date: Fri May 1 12:34:12 2015 +0200 drm/radeon: disable semaphores for UVD V1 (v2) commit 013ead48a843442e63b9426e3bd5df18ca5d054a upstream. Hardware doesn't seem to work correctly, just block userspace in this case. v2: add missing defines Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=85320 Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit d3f178ebebb3f2bfff0f8182c1d488405ae9cc58 Author: Lukas Wunner Date: Mon May 4 15:06:49 2015 +0200 drm/i915: Add missing MacBook Pro models with dual channel LVDS commit 3916e3fd81021fb795bfbdb17f375b6b3685bced upstream. Single channel LVDS maxes out at 112 MHz. The 15" pre-retina models shipped with 1440x900 (106 MHz) by default or 1680x1050 (119 MHz) as a BTO option, both versions used dual channel LVDS even though the smaller one would have fit into a single channel. Notes: Bug report showing that the MacBookPro8,2 with 1440x900 uses dual channel LVDS (this lead to it being hardcoded in intel_lvds.c by Daniel Vetter with commit 618563e3945b9d0864154bab3c607865b557cecc): https://bugzilla.kernel.org/show_bug.cgi?id=42842 If i915.lvds_channel_mode=2 is missing even though the machine needs it, every other vertical line is white and consequently, only the left half of the screen is visible (verified by myself on a MacBookPro9,1). Forum posting concerning a MacBookPro6,2 with 1440x900, author is using i915.lvds_channel_mode=2 on the kernel command line, proving that the machine uses dual channels: https://bbs.archlinux.org/viewtopic.php?id=185770 Chi Mei N154C6-L04 with 1440x900 is a replacement panel for all MacBook Pro "A1286" models, and that model number encompasses the MacBookPro6,2 / 8,2 / 9,1. Page 17 of the panel's datasheet shows it's driven with dual channel LVDS: http://www.ebay.com/itm/-/400690878560 http://www.everymac.com/ultimate-mac-lookup/?search_keywords=A1286 http://www.taopanel.com/chimei/datasheet/N154C6-L04.pdf Those three 15" models, MacBookPro6,2 / 8,2 / 9,1, are the only ones with i915 graphics and dual channel LVDS, so that list should be complete. And the 8,2 is already in intel_lvds.c. Possible motivation to use dual channel LVDS even on the 1440x900 models: Reduce the number of different parts, i.e. use identical logic boards and display cabling on both versions and the only differing component is the panel. Signed-off-by: Lukas Wunner Acked-by: Jani Nikula [Jani: included notes in the commit message for posterity] Signed-off-by: Jani Nikula Signed-off-by: Jiri Slaby commit 1a35bb7805c622859a86cc6caa8a8042d813faff Author: Ulf Hansson Date: Mon Apr 20 16:02:33 2015 +0200 ARM: ux500: Enable GPIO regulator for SD-card for snowball commit 11133db7a836b0cb411faa048f07a38e994d1382 upstream. Fixes: c94a4ab7af3f ("ARM: ux500: Disable the MMCI gpio-regulator by default") Signed-off-by: Ulf Hansson Reviewed-by: Bjorn Andersson Signed-off-by: Linus Walleij Signed-off-by: Jiri Slaby commit 9fd8c880af01243e71cc55248d7b1839730b189d Author: Ulf Hansson Date: Mon Apr 20 16:02:32 2015 +0200 ARM: ux500: Enable GPIO regulator for SD-card for HREF boards commit f9a8c3914ba85f19c3360b19612d77c47adb8942 upstream. Fixes: c94a4ab7af3f ("ARM: ux500: Disable the MMCI gpio-regulator by default") Signed-off-by: Ulf Hansson Reviewed-by: Bjorn Andersson Signed-off-by: Linus Walleij Signed-off-by: Jiri Slaby commit 9e52c9e0ce899403f788a939325fdfe4f5d008e4 Author: Ulf Hansson Date: Mon Apr 20 16:02:31 2015 +0200 ARM: ux500: Move GPIO regulator for SD-card into board DTSs commit 53d2669844263fd5fdc70f0eb6a2eb8a21086d8e upstream. The GPIO regulator for the SD-card isn't a ux500 SOC configuration, but instead it's specific to the board. Move the definition of it, into the board DTSs. Fixes: c94a4ab7af3f ("ARM: ux500: Disable the MMCI gpio-regulator by default") Signed-off-by: Ulf Hansson Reviewed-by: Bjorn Andersson Signed-off-by: Linus Walleij Signed-off-by: Jiri Slaby commit bce4dcf9b23201c4ccd6a87cbe95b5dc8b9e0581 Author: Gregory CLEMENT Date: Tue Apr 14 11:50:13 2015 +0200 ARM: mvebu: armada-xp-openblocks-ax3-4: Disable internal RTC commit 750e30d4076ae5e02ad13a376e96c95a2627742c upstream. There is no crystal connected to the internal RTC on the Open Block AX3. So let's disable it in order to prevent the kernel probing the driver uselessly. Eventually this patches removes the following warning message from the boot log: "rtc-mv d0010300.rtc: internal RTC not ticking" Acked-by: Andrew Lunn Signed-off-by: Gregory CLEMENT Signed-off-by: Jiri Slaby commit d8354736bc0e37737ff1b06e56a1018006756d05 Author: Fabio Estevam Date: Tue Apr 14 11:05:04 2015 -0300 ARM: dts: imx23-olinuxino: Fix polarity of LED GPIO commit cfe8c59762244251fd9a5e281d48808095ff4090 upstream. On imx23-olinuxino the LED turns on when level logic high is aplied to GPIO2_1. Fix the gpios property accordingly. Fixes: b34aa1850244 ("ARM: dts: imx23-olinuxino: Remove unneeded "default-on"") Reported-by: Stefan Wahren Signed-off-by: Fabio Estevam Tested-by: Stefan Wahren Signed-off-by: Shawn Guo Signed-off-by: Jiri Slaby commit a77374f8c2a293569167ade7589c7b26e574ecf2 Author: Stefan Wahren Date: Tue Apr 14 20:37:26 2015 +0000 ARM: dts: imx23-olinuxino: Fix dr_mode of usb0 commit 0fdebe1a2f4d3a8fc03754022fabf8ba95e131a3 upstream. The dr_mode of usb0 on imx233-olinuxino is left to default "otg". Since the green LED (GPIO2_1) on imx233-olinuxino is connected to the same pin as USB_OTG_ID it's possible to disable USB host by LED toggling: echo 0 > /sys/class/leds/green/brightness [ 1068.890000] ci_hdrc ci_hdrc.0: remove, state 1 [ 1068.890000] usb usb1: USB disconnect, device number 1 [ 1068.920000] usb 1-1: USB disconnect, device number 2 [ 1068.920000] usb 1-1.1: USB disconnect, device number 3 [ 1069.070000] usb 1-1.2: USB disconnect, device number 4 [ 1069.450000] ci_hdrc ci_hdrc.0: USB bus 1 deregistered [ 1074.460000] ci_hdrc ci_hdrc.0: timeout waiting for 00000800 in 11 This patch fixes the issue by setting dr_mode to "host" in the dts file. Reported-by: Harald Geyer Signed-off-by: Stefan Wahren Reviewed-by: Fabio Estevam Reviewed-by: Marek Vasut Acked-by: Peter Chen Fixes: b49312948285 ("ARM: dts: imx23-olinuxino: Add USB host support") Signed-off-by: Shawn Guo Signed-off-by: Jiri Slaby commit 854939cb40ee48e0adc6f573d673638ff218e960 Author: Marek Vasut Date: Fri Apr 24 13:29:47 2015 +0200 ARM: dts: imx28: Fix AUART4 TX-DMA interrupt name commit 4ada77e37a773168fea484899201e272ab44ba8b upstream. Fix a typo in the TX DMA interrupt name for AUART4. This patch makes AUART4 operational again. Signed-off-by: Marek Vasut Fixes: f30fb03d4d3a ("ARM: dts: add generic DMA device tree binding for mxs-dma") Acked-by: Stefan Wahren Signed-off-by: Shawn Guo Signed-off-by: Jiri Slaby commit 58305b1704cc6dda4185218dc82c74bd54041747 Author: Markus Pargmann Date: Fri Apr 24 09:27:33 2015 +0200 ARM: dts: imx25: Add #pwm-cells to pwm4 commit f90d3f0d0a11fa77918fd5497cb616dd2faa8431 upstream. The property '#pwm-cells' is currently missing. It is not possible to use pwm4 without this property. Signed-off-by: Markus Pargmann Fixes: 5658a68fb578 ("ARM i.MX25: Add devicetree") Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Jiri Slaby commit 213522e3099484515afbb07878a199dc6206bbf4 Author: Boris Ostrovsky Date: Wed Apr 29 17:10:14 2015 -0400 xen/console: Update console event channel on resume commit b9d934f27c91b878c4b2e64299d6e419a4022f8d upstream. After a resume the hypervisor/tools may change console event channel number. We should re-query it. Signed-off-by: Boris Ostrovsky Signed-off-by: David Vrabel Signed-off-by: Jiri Slaby commit 5babf6ec822b6fd79e8941dd3b1c7aa58d8620f6 Author: Naoya Horiguchi Date: Tue May 5 16:23:46 2015 -0700 mm: soft-offline: fix num_poisoned_pages counting on concurrent events commit 602498f9aa43d4951eece3fd6ad95a6d0a78d537 upstream. If multiple soft offline events hit one free page/hugepage concurrently, soft_offline_page() can handle the free page/hugepage multiple times, which makes num_poisoned_pages counter increased more than once. This patch fixes this wrong counting by checking TestSetPageHWPoison for normal papes and by checking the return value of dequeue_hwpoisoned_huge_page() for hugepages. Signed-off-by: Naoya Horiguchi Acked-by: Dean Nelson Cc: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 62d7a1a87954f16f6c43d345f347afc2a0ee80ac Author: Tejun Heo Date: Tue Apr 21 16:49:13 2015 -0400 writeback: use |1 instead of +1 to protect against div by zero commit 464d1387acb94dc43ba772b35242345e3d2ead1b upstream. mm/page-writeback.c has several places where 1 is added to the divisor to prevent division by zero exceptions; however, if the original divisor is equivalent to -1, adding 1 leads to division by zero. There are three places where +1 is used for this purpose - one in pos_ratio_polynom() and two in bdi_position_ratio(). The second one in bdi_position_ratio() actually triggered div-by-zero oops on a machine running a 3.10 kernel. The divisor is x_intercept - bdi_setpoint + 1 == span + 1 span is confirmed to be (u32)-1. It isn't clear how it ended up that but it could be from write bandwidth calculation underflow fixed by c72efb658f7c ("writeback: fix possible underflow in write bandwidth calculation"). At any rate, +1 isn't a proper protection against div-by-zero. This patch converts all +1 protections to |1. Note that bdi_update_dirty_ratelimit() was already using |1 before this patch. Signed-off-by: Tejun Heo Reviewed-by: Jan Kara Signed-off-by: Jens Axboe Signed-off-by: Jiri Slaby commit 7e161621624a31c4a001731c1a83b22356c94afd Author: Naoya Horiguchi Date: Tue May 5 16:23:35 2015 -0700 mm/memory-failure: call shake_page() when error hits thp tail page commit 09789e5de18e4e442870b2d700831f5cb802eb05 upstream. Currently memory_failure() calls shake_page() to sweep pages out from pcplists only when the victim page is 4kB LRU page or thp head page. But we should do this for a thp tail page too. Consider that a memory error hits a thp tail page whose head page is on a pcplist when memory_failure() runs. Then, the current kernel skips shake_pages() part, so hwpoison_user_mappings() returns without calling split_huge_page() nor try_to_unmap() because PageLRU of the thp head is still cleared due to the skip of shake_page(). As a result, me_huge_page() runs for the thp, which is broken behavior. One effect is a leak of the thp. And another is to fail to isolate the memory error, so later access to the error address causes another MCE, which kills the processes which used the thp. This patch fixes this problem by calling shake_page() for thp tail case. Fixes: 385de35722c9 ("thp: allow a hwpoisoned head page to be put back to LRU") Signed-off-by: Naoya Horiguchi Reviewed-by: Andi Kleen Acked-by: Dean Nelson Cc: Andrea Arcangeli Cc: Hidetoshi Seto Cc: Jin Dongming Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 95c021d8b720eb3ade60e98b593f38a47df039fb Author: Eric W. Biederman Date: Fri May 8 16:36:50 2015 -0500 mnt: Fix fs_fully_visible to verify the root directory is visible commit 7e96c1b0e0f495c5a7450dc4aa7c9a24ba4305bd upstream. This fixes a dumb bug in fs_fully_visible that allows proc or sys to be mounted if there is a bind mount of part of /proc/ or /sys/ visible. Reported-by: Eric Windisch Signed-off-by: "Eric W. Biederman" Signed-off-by: Jiri Slaby commit e8ed8a03c3526f0932ac5dc085a2d52644a18651 Author: Johan Hovold Date: Tue Apr 21 17:42:09 2015 +0200 gpio: sysfs: fix memory leaks and device hotplug commit 483d821108791092798f5d230686868112927044 upstream. Unregister GPIOs requested through sysfs at chip remove to avoid leaking the associated memory and sysfs entries. The stale sysfs entries prevented the gpio numbers from being exported when the gpio range was later reused (e.g. at device reconnect). This also fixes the related module-reference leak. Note that kernfs makes sure that any on-going sysfs operations finish before the class devices are unregistered and that further accesses fail. The chip exported flag is used to prevent gpiod exports during removal. This also makes it harder to trigger, but does not fix, the related race between gpiochip_remove and export_store, which is really a race with gpiod_request that needs to be addressed separately. Also note that this would prevent the crashes (e.g. NULL-dereferences) at reconnect that affects pre-3.18 kernels, as well as use-after-free on operations on open attribute files on pre-3.14 kernels (prior to kernfs). Fixes: d8f388d8dc8d ("gpio: sysfs interface") Signed-off-by: Johan Hovold Signed-off-by: Linus Walleij Signed-off-by: Jiri Slaby commit e7a8407b62058c296d0087cf6a3a867cbe14057f Author: Johan Hovold Date: Mon Jan 12 17:12:29 2015 +0100 gpio: unregister gpiochip device before removing it commit 01cca93a9491ed95992523ff7e79dd9bfcdea8e0 upstream. Unregister gpiochip device (used to export information through sysfs) before removing it internally. This way removal will reverse addition. Signed-off-by: Johan Hovold Signed-off-by: Linus Walleij Signed-off-by: Jiri Slaby commit 1c5c833e1a16bdb7597d26c74a543bdf12435e31 Author: Jason Gunthorpe Date: Mon Apr 20 14:01:11 2015 -0600 RDMA/CMA: Canonize IPv4 on IPV6 sockets properly commit 285214409a9e5fceba2215461b4682b6069d8e77 upstream. When accepting a new IPv4 connect to an IPv6 socket, the CMA tries to canonize the address family to IPv4, but does not properly process the listening sockaddr to get the listening port, and does not properly set the address family of the canonized sockaddr. Fixes: e51060f08a61 ("IB: IP address based RDMA connection manager") Reported-By: Yotam Kenneth Signed-off-by: Jason Gunthorpe Tested-by: Haggai Eran Signed-off-by: Doug Ledford Signed-off-by: Jiri Slaby commit 579524b1a966ee12d83ab116140c493eb8e2baaa Author: Ryusuke Konishi Date: Tue May 5 16:24:00 2015 -0700 nilfs2: fix sanity check of btree level in nilfs_btree_root_broken() commit d8fd150fe3935e1692bf57c66691e17409ebb9c1 upstream. The range check for b-tree level parameter in nilfs_btree_root_broken() is wrong; it accepts the case of "level == NILFS_BTREE_LEVEL_MAX" even though the level is limited to values in the range of 0 to (NILFS_BTREE_LEVEL_MAX - 1). Since the level parameter is read from storage device and used to index nilfs_btree_path array whose element count is NILFS_BTREE_LEVEL_MAX, it can cause memory overrun during btree operations if the boundary value is set to the level parameter on device. This fixes the broken sanity check and adds a comment to clarify that the upper bound NILFS_BTREE_LEVEL_MAX is exclusive. Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit ad02ca86cf07d341bc6b85ade0e5b7f5e96839ba Author: Junxiao Bi Date: Tue May 5 16:24:02 2015 -0700 ocfs2: dlm: fix race between purge and get lock resource commit b1432a2a35565f538586774a03bf277c27fc267d upstream. There is a race window in dlm_get_lock_resource(), which may return a lock resource which has been purged. This will cause the process to hang forever in dlmlock() as the ast msg can't be handled due to its lock resource not existing. dlm_get_lock_resource { ... spin_lock(&dlm->spinlock); tmpres = __dlm_lookup_lockres_full(dlm, lockid, namelen, hash); if (tmpres) { spin_unlock(&dlm->spinlock); >>>>>>>> race window, dlm_run_purge_list() may run and purge the lock resource spin_lock(&tmpres->spinlock); ... spin_unlock(&tmpres->spinlock); } } Signed-off-by: Junxiao Bi Cc: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 2b4396f4b2c1d873749c1fb25637555bdf560dc3 Author: Leon Yu Date: Wed Mar 25 15:55:11 2015 -0700 mm: fix anon_vma->degree underflow in anon_vma endless growing prevention commit 3fe89b3e2a7bbf3e97657104b9b33a9d81b950b3 upstream. I have constantly stumbled upon "kernel BUG at mm/rmap.c:399!" after upgrading to 3.19 and had no luck with 4.0-rc1 neither. So, after looking into new logic introduced by commit 7a3ef208e662 ("mm: prevent endless growth of anon_vma hierarchy"), I found chances are that unlink_anon_vmas() is called without incrementing dst->anon_vma->degree in anon_vma_clone() due to allocation failure. If dst->anon_vma is not NULL in error path, its degree will be incorrectly decremented in unlink_anon_vmas() and eventually underflow when exiting as a result of another call to unlink_anon_vmas(). That's how "kernel BUG at mm/rmap.c:399!" is triggered for me. This patch fixes the underflow by dropping dst->anon_vma when allocation fails. It's safe to do so regardless of original value of dst->anon_vma because dst->anon_vma doesn't have valid meaning if anon_vma_clone() fails. Besides, callers don't care dst->anon_vma in such case neither. Also suggested by Michal Hocko, we can clean up vma_adjust() a bit as anon_vma_clone() now does the work. [akpm@linux-foundation.org: tweak comment] Fixes: 7a3ef208e662 ("mm: prevent endless growth of anon_vma hierarchy") Signed-off-by: Leon Yu Signed-off-by: Konstantin Khlebnikov Reviewed-by: Michal Hocko Acked-by: Rik van Riel Acked-by: David Rientjes Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 4cd01168571b39f9e5bbdab6e43b88757df61067 Author: Konstantin Khlebnikov Date: Sun Jan 11 16:54:06 2015 +0300 mm: fix corner case in anon_vma endless growing prevention commit b800c91a0517071156e772d4fb329ad33590da62 upstream. Fix for BUG_ON(anon_vma->degree) splashes in unlink_anon_vmas() ("kernel BUG at mm/rmap.c:399!") caused by commit 7a3ef208e662 ("mm: prevent endless growth of anon_vma hierarchy") Anon_vma_clone() is usually called for a copy of source vma in destination argument. If source vma has anon_vma it should be already in dst->anon_vma. NULL in dst->anon_vma is used as a sign that it's called from anon_vma_fork(). In this case anon_vma_clone() finds anon_vma for reusing. Vma_adjust() calls it differently and this breaks anon_vma reusing logic: anon_vma_clone() links vma to old anon_vma and updates degree counters but vma_adjust() overrides vma->anon_vma right after that. As a result final unlink_anon_vmas() decrements degree for wrong anon_vma. This patch assigns ->anon_vma before calling anon_vma_clone(). Signed-off-by: Konstantin Khlebnikov Reported-and-tested-by: Chris Clayton Reported-and-tested-by: Oded Gabbay Reported-and-tested-by: Chih-Wei Huang Acked-by: Rik van Riel Acked-by: Vlastimil Babka Cc: Daniel Forrest Cc: Michal Hocko Cc: stable@vger.kernel.org # to match back-porting of 7a3ef208e662 Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit f3c423ebda4a11c3a44ebc6d82d47a49bc4a2372 Author: Konstantin Khlebnikov Date: Thu Jan 8 14:32:15 2015 -0800 mm: prevent endless growth of anon_vma hierarchy commit 7a3ef208e662f4b63d43a23f61a64a129c525bbc upstream. Constantly forking task causes unlimited grow of anon_vma chain. Each next child allocates new level of anon_vmas and links vma to all previous levels because pages might be inherited from any level. This patch adds heuristic which decides to reuse existing anon_vma instead of forking new one. It adds counter anon_vma->degree which counts linked vmas and directly descending anon_vmas and reuses anon_vma if counter is lower than two. As a result each anon_vma has either vma or at least two descending anon_vmas. In such trees half of nodes are leafs with alive vmas, thus count of anon_vmas is no more than two times bigger than count of vmas. This heuristic reuses anon_vmas as few as possible because each reuse adds false aliasing among vmas and rmap walker ought to scan more ptes when it searches where page is might be mapped. Link: http://lkml.kernel.org/r/20120816024610.GA5350@evergreen.ssec.wisc.edu Fixes: 5beb49305251 ("mm: change anon_vma linking to fix multi-process server scalability issue") [akpm@linux-foundation.org: fix typo, per Rik] Signed-off-by: Konstantin Khlebnikov Reported-by: Daniel Forrest Tested-by: Michal Hocko Tested-by: Jerome Marchand Reviewed-by: Michal Hocko Reviewed-by: Rik van Riel Cc: [2.6.34+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 77167581c8a317d95e15b164acd323ea3aef0a2c Author: Heiko Carstens Date: Wed Jul 2 15:22:37 2014 -0700 fs/seq_file: fallback to vmalloc allocation commit 058504edd02667eef8fac9be27ab3ea74332e9b4 upstream. There are a couple of seq_files which use the single_open() interface. This interface requires that the whole output must fit into a single buffer. E.g. for /proc/stat allocation failures have been observed because an order-4 memory allocation failed due to memory fragmentation. In such situations reading /proc/stat is not possible anymore. Therefore change the seq_file code to fallback to vmalloc allocations which will usually result in a couple of order-0 allocations and hence also work if memory is fragmented. For reference a call trace where reading from /proc/stat failed: sadc: page allocation failure: order:4, mode:0x1040d0 CPU: 1 PID: 192063 Comm: sadc Not tainted 3.10.0-123.el7.s390x #1 [...] Call Trace: show_stack+0x6c/0xe8 warn_alloc_failed+0xd6/0x138 __alloc_pages_nodemask+0x9da/0xb68 __get_free_pages+0x2e/0x58 kmalloc_order_trace+0x44/0xc0 stat_open+0x5a/0xd8 proc_reg_open+0x8a/0x140 do_dentry_open+0x1bc/0x2c8 finish_open+0x46/0x60 do_last+0x382/0x10d0 path_openat+0xc8/0x4f8 do_filp_open+0x46/0xa8 do_sys_open+0x114/0x1f0 sysc_tracego+0x14/0x1a Signed-off-by: Heiko Carstens Tested-by: David Rientjes Cc: Ian Kent Cc: Hendrik Brueckner Cc: Thorsten Diehl Cc: Andrea Righi Cc: Christoph Hellwig Cc: Al Viro Cc: Stefan Bader Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit bb1317a3eb0f8cc3615e77cfa83b2902f35906d8 Author: Al Viro Date: Tue Nov 19 01:20:43 2013 +0000 seq_file: always clear m->count when we free m->buf commit 801a76050bcf8d4e500eb8d048ff6265f37a61c8 upstream. Once we'd freed m->buf, m->count should become zero - we have no valid contents reachable via m->buf. Reported-by: Charley (Hao Chuan) Chu Signed-off-by: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit a58d83a1a10afa8b19a026859bcb6c47832975a8 Author: Heiko Carstens Date: Wed Jul 2 15:22:37 2014 -0700 /proc/stat: convert to single_open_size() commit f74373a5cc7a0155d232c4e999648c7a95435bb2 upstream. These two patches are supposed to "fix" failed order-4 memory allocations which have been observed when reading /proc/stat. The problem has been observed on s390 as well as on x86. To address the problem change the seq_file memory allocations to fallback to use vmalloc, so that allocations also work if memory is fragmented. This approach seems to be simpler and less intrusive than changing /proc/stat to use an interator. Also it "fixes" other users as well, which use seq_file's single_open() interface. This patch (of 2): Use seq_file's single_open_size() to preallocate a buffer that is large enough to hold the whole output, instead of open coding it. Also calculate the requested size using the number of online cpus instead of possible cpus, since the size of the output only depends on the number of online cpus. Signed-off-by: Heiko Carstens Acked-by: David Rientjes Cc: Ian Kent Cc: Hendrik Brueckner Cc: Thorsten Diehl Cc: Andrea Righi Cc: Christoph Hellwig Cc: Al Viro Cc: Stefan Bader Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit dcaf4bff1bba0a745df18096902770179a307503 Author: Vineet Gupta Date: Thu Mar 26 11:14:41 2015 +0530 ARC: signal handling robustify commit e4140819dadc3624accac8294881bca8a3cba4ed upstream. A malicious signal handler / restorer can DOS the system by fudging the user regs saved on stack, causing weird things such as sigreturn returning to user mode PC but cpu state still being kernel mode.... Ensure that in sigreturn path status32 always has U bit; any other bogosity (gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms. Reproducer signal handler: void handle_sig(int signo, siginfo_t *info, void *context) { ucontext_t *uc = context; struct user_regs_struct *regs = &(uc->uc_mcontext.regs); regs->scratch.status32 = 0; } Before the fix, kernel would go off to weeds like below: --------->8----------- [ARCLinux]$ ./signal-test Path: /signal-test CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65 task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000 [ECR ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698 [EFA ]: 0x00000010 [BLINK ]: 0x2007c1ee [ERET ]: 0x10698 [STAT32]: 0x00000000 : <-------- BTA: 0x00010680 SP: 0x5ffe7e48 FP: 0x00000000 LPS: 0x20003c6c LPE: 0x20003c70 LPC: 0x00000000 ... --------->8----------- Reported-by: Alexey Brodkin Signed-off-by: Vineet Gupta Signed-off-by: Jiri Slaby commit f3c24356e695a6009be72730778151acc853db8f Author: K. Y. Srinivasan Date: Thu Mar 19 08:11:34 2015 -0700 Drivers: hv: vmbus: Don't wait after requesting offers commit 73cffdb65e679b98893f484063462c045adcf212 upstream. Don't wait after sending request for offers to the host. This wait is unnecessary and simply adds 5 seconds to the boot time. Signed-off-by: K. Y. Srinivasan Cc: Signed-off-by: Jiri Slaby commit 8ea7695e4dcbaaacf989484b81237fe4318bf524 Author: Andrzej Pietrasiewicz Date: Tue Mar 3 10:52:05 2015 +0100 usb: gadget: printer: enqueue printer's response for setup request commit eb132ccbdec5df46e29c9814adf76075ce83576b upstream. Function-specific setup requests should be handled in such a way, that apart from filling in the data buffer, the requests are also actually enqueued: if function-specific setup is called from composte_setup(), the "usb_ep_queue()" block of code in composite_setup() is skipped. The printer function lacks this part and it results in e.g. get device id requests failing: the host expects some response, the device prepares it but does not equeue it for sending to the host, so the host finally asserts timeout. This patch adds enqueueing the prepared responses. Fixes: 2e87edf49227: "usb: gadget: make g_printer use composite" Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Felipe Balbi [ported to stable 3.10 and 3.14] Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Jiri Slaby commit af80e75ed332c76add5cc6ea3a0a0a036bf312dd Author: Felipe Balbi Date: Fri Feb 13 14:42:25 2015 -0600 usb: host: ehci: use new USB_RESUME_TIMEOUT commit ea16328f80ca8d74434352157f37ef60e2f55ce2 upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit 905759186a3337741e4d68ad0176ca577c85488e Author: Felipe Balbi Date: Fri Feb 13 14:57:54 2015 -0600 usb: host: oxu210hp: use new USB_RESUME_TIMEOUT commit 84c0d178eb9f3a3ae4d63dc97a440266cf17f7f5 upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit 8af6ea1b5e1ab12cf40a1ce7779ab2fcbc0d1205 Author: Felipe Balbi Date: Fri Feb 13 14:46:27 2015 -0600 usb: musb: use new USB_RESUME_TIMEOUT commit 309be239369609929d5d3833ee043f7c5afc95d1 upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Based on original work by Bin Liu > Cc: Bin Liu Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit 459ff94edc341ad2f78620c395d61a855420f0ec Author: Alex Deucher Date: Mon Apr 27 09:51:43 2015 -0400 drm/radeon: add SI DPM quirk for Sapphire R9 270 Dual-X 2G GDDR5 commit cd17e02ff4db58ec32d35cf331c705d295779930 upstream. Seems to have problems with high mclks. bug: https://bugs.freedesktop.org/show_bug.cgi?id=76490 Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit d5b20f8669e4109e91ee7d6daf3bbd46d8385b03 Author: Christoph Hellwig Date: Thu Apr 23 09:48:49 2015 +0200 3w-sas: fix command completion race commit 579d69bc1fd56d5af5761969aa529d1d1c188300 upstream. The 3w-sas driver needs to tear down the dma mappings before returning the command to the midlayer, as there is no guarantee the sglist and count are valid after that point. Also remove the dma mapping helpers which have another inherent race due to the request_id index. Signed-off-by: Christoph Hellwig Reported-by: Torsten Luettgert Tested-by: Bernd Kardatzki Acked-by: Adam Radford Signed-off-by: James Bottomley Signed-off-by: Jiri Slaby commit c5907e12ec84e9e9990f9309ca0beae8200b4369 Author: Christoph Hellwig Date: Thu Apr 23 09:48:51 2015 +0200 3w-9xxx: fix command completion race commit 118c855b5623f3e2e6204f02623d88c09e0c34de upstream. The 3w-9xxx driver needs to tear down the dma mappings before returning the command to the midlayer, as there is no guarantee the sglist and count are valid after that point. Also remove the dma mapping helpers which have another inherent race due to the request_id index. Signed-off-by: Christoph Hellwig Acked-by: Adam Radford Signed-off-by: James Bottomley Signed-off-by: Jiri Slaby commit a91071e3085ecdcf00a4c3c80199cdc8b2123c02 Author: Christoph Hellwig Date: Thu Apr 23 09:48:50 2015 +0200 3w-xxxx: fix command completion race commit 9cd9554615cba14f0877cc9972a6537ad2bdde61 upstream. The 3w-xxxx driver needs to tear down the dma mappings before returning the command to the midlayer, as there is no guarantee the sglist and count are valid after that point. Also remove the dma mapping helpers which have another inherent race due to the request_id index. Signed-off-by: Christoph Hellwig Acked-by: Adam Radford Signed-off-by: James Bottomley Signed-off-by: Jiri Slaby commit 50a61d0ce8cadb9185b6fc47bcc99ce7bf69c62c Author: Lukas Czerner Date: Sat May 2 21:36:55 2015 -0400 ext4: fix data corruption caused by unwritten and delayed extents commit d2dc317d564a46dfc683978a2e5a4f91434e9711 upstream. Currently it is possible to lose whole file system block worth of data when we hit the specific interaction with unwritten and delayed extents in status extent tree. The problem is that when we insert delayed extent into extent status tree the only way to get rid of it is when we write out delayed buffer. However there is a limitation in the extent status tree implementation so that when inserting unwritten extent should there be even a single delayed block the whole unwritten extent would be marked as delayed. At this point, there is no way to get rid of the delayed extents, because there are no delayed buffers to write out. So when a we write into said unwritten extent we will convert it to written, but it still remains delayed. When we try to write into that block later ext4_da_map_blocks() will set the buffer new and delayed and map it to invalid block which causes the rest of the block to be zeroed loosing already written data. For now we can fix this by simply not allowing to set delayed status on written extent in the extent status tree. Also add WARN_ON() to make sure that we notice if this happens in the future. This problem can be easily reproduced by running the following xfs_io. xfs_io -f -c "pwrite -S 0xaa 4096 2048" \ -c "falloc 0 131072" \ -c "pwrite -S 0xbb 65536 2048" \ -c "fsync" /mnt/test/fff echo 3 > /proc/sys/vm/drop_caches xfs_io -c "pwrite -S 0xdd 67584 2048" /mnt/test/fff This can be theoretically also reproduced by at random by running fsx, but it's not very reliable, though on machines with bigger page size (like ppc) this can be seen more often (especially xfstest generic/127) Signed-off-by: Lukas Czerner Signed-off-by: Theodore Ts'o Signed-off-by: Jiri Slaby commit 8ed0623b0a8604c336c51a44259aa5581343ba6f Author: Ilya Dryomov Date: Sat Apr 25 15:56:15 2015 +0300 rbd: end I/O the entire obj_request on error commit 082a75dad84d79d1c15ea9e50f31cb4bb4fa7fd6 upstream. When we end I/O struct request with error, we need to pass obj_request->length as @nr_bytes so that the entire obj_request worth of bytes is completed. Otherwise block layer ends up confused and we trip on rbd_assert(more ^ (which == img_request->obj_request_count)); in rbd_img_obj_callback() due to more being true no matter what. We already do it in most cases but we are missing some, in particular those where we don't even get a chance to submit any obj_requests, due to an early -ENOMEM for example. A number of obj_request->xferred assignments seem to be redundant but I haven't touched any of obj_request->xferred stuff to keep this small and isolated. Cc: Alex Elder Reported-by: Shawn Edwards Reviewed-by: Sage Weil Signed-off-by: Ilya Dryomov Signed-off-by: Jiri Slaby commit 7a90b15c3bb64b4d59badac51d5dda9a735087e3 Author: Ludovic Desroches Date: Thu Apr 16 16:58:12 2015 +0200 tty/serial: at91: maxburst was missing for dma transfers commit a8d4e01637902311c5643b69a5c80e2805f04054 upstream. Maxburst was not set when doing the dma slave configuration. This value is checked by the recently introduced xdmac. It causes an error when doing the slave configuration and so prevents from using dma. Signed-off-by: Ludovic Desroches Acked-by: Nicolas Ferre Signed-off-by: Jiri Slaby commit 76fa87f69181daa6a93a3215a99eeb21aa396afe Author: Charles Keepax Date: Wed Apr 22 13:58:47 2015 +0100 ASoC: dapm: Enable autodisable on SOC_DAPM_SINGLE_TLV_AUTODISABLE commit a2d97723cb3a7741af81868427b36bba274b681b upstream. Correct small copy and paste error where autodisable was not being enabled for the SOC_DAPM_SINGLE_TLV_AUTODISABLE control. Signed-off-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit b2ca4db9080145428a76c97e740bb0f857f27e2f Author: Michal Simek Date: Tue Apr 14 12:03:09 2015 +0200 serial: of-serial: Remove device_type = "serial" registration commit 6befa9d883385c580369a2cc9e53fbf329771f6d upstream. Do not probe all serial drivers by of_serial.c which are using device_type = "serial"; property. Only drivers which have valid compatible strings listed in the driver should be probed. When PORT_UNKNOWN is setup probe will fail anyway. Arnd quotation about driver historical background: "when I wrote that driver initially, the idea was that it would get used as a stub to hook up all other serial drivers but after that, the common code learned to create platform devices from DT" This patch fix the problem with on the system with xilinx_uartps and 16550a where of_serial failed to register for xilinx_uartps and because of irq_dispose_mapping() removed irq_desc. Then when xilinx_uartps was asking for irq with request_irq() EINVAL is returned. Signed-off-by: Michal Simek Acked-by: Arnd Bergmann Signed-off-by: Jiri Slaby commit 5de7565b4e5cf5e5e21027968d3a9bdad23c162c Author: Takashi Iwai Date: Mon Apr 27 10:36:11 2015 +0200 ALSA: hda - Fix mute-LED fixed mode commit ee52e56e7b12834476cd0031c5986254ba1b6317 upstream. The mute-LED mode control has the fixed on/off states that are supposed to remain on/off regardless of the master switch. However, this doesn't work actually because the vmaster hook is called in the vmaster code itself. This patch fixes it by calling the hook indirectly after checking the mute LED mode. Reported-and-tested-by: Pali Rohár Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit f10cdffde1c8d4ca09ea045742e4092006230163 Author: Peter Zubaj Date: Tue Apr 28 21:57:29 2015 +0200 ALSA: emu10k1: Emu10k2 32 bit DMA mode commit 7241ea558c6715501e777396b5fc312c372e11d9 upstream. Looks like audigy emu10k2 (probably emu10k1 - sb live too) support two modes for DMA. Second mode is useful for 64 bit os with more then 2 GB of ram (fixes problems with big soundfont loading) 1) 32MB from 2 GB address space using 8192 pages (used now as default) 2) 16MB from 4 GB address space using 4096 pages Mode is set using HCFG_EXPANDED_MEM flag in HCFG register. Also format of emu10k2 page table is then different. Signed-off-by: Peter Zubaj Tested-by: Takashi Iwai Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit f04628654e140b8ee8296ace05c322eb60de3cd2 Author: Takashi Iwai Date: Mon Apr 27 13:00:09 2015 +0200 ALSA: emu10k1: Fix card shortname string buffer overflow commit d02260824e2cad626fb2a9d62e27006d34b6dedc upstream. Some models provide too long string for the shortname that has 32bytes including the terminator, and it results in a non-terminated string exposed to the user-space. This isn't too critical, though, as the string is stopped at the succeeding longname string. This patch fixes such entries by dropping "SB" prefix (it's enough to fit within 32 bytes, so far). Meanwhile, it also changes strcpy() with strlcpy() to make sure that this kind of problem won't happen in future, too. Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 3844eb5438e0f0040aac8b92157a69155e1b8923 Author: Takashi Iwai Date: Tue Apr 28 17:11:44 2015 +0200 ALSA: emux: Fix mutex deadlock in OSS emulation commit 1c94e65c668f44d2c69ae7e7fc268ab3268fba3e upstream. The OSS emulation in synth-emux helper has a potential AB/BA deadlock at the simultaneous closing and opening: close -> snd_seq_release() -> sne_seq_free_client() -> snd_seq_delete_all_ports(): takes client->ports_mutex -> port_delete() -> snd_emux_unuse(): takes emux->register_mutex open -> snd_seq_oss_open() -> snd_emux_open_seq_oss(): takes emux->register_mutex -> snd_seq_event_port_attach() -> snd_seq_create_port(): takes client->ports_mutex This patch addresses the deadlock by reducing the rance taking emux->register_mutex in snd_emux_open_seq_oss(). The lock is needed for the refcount handling, so move it locally. The calls in emux_seq.c are already with the mutex, thus they are replaced with the version without mutex lock/unlock. Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 743fd776fbd6eeb3ead93208453c82f5f00e559f Author: Takashi Iwai Date: Mon Apr 27 14:50:39 2015 +0200 ALSA: emux: Fix mutex deadlock at unloading commit 07b0e5d49d227e3950cb13a3e8caf248ef2a310e upstream. The emux-synth driver has a possible AB/BA mutex deadlock at unloading the emu10k1 driver: snd_emux_free() -> snd_emux_detach_seq(): mutex_lock(&emu->register_mutex) -> snd_seq_delete_kernel_client() -> snd_seq_free_client(): mutex_lock(®ister_mutex) snd_seq_release() -> snd_seq_free_client(): mutex_lock(®ister_mutex) -> snd_seq_delete_all_ports() -> snd_emux_unuse(): mutex_lock(&emu->register_mutex) Basically snd_emux_detach_seq() doesn't need a protection of emu->register_mutex as it's already being unregistered. So, we can get rid of this for avoiding the deadlock. Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 359b12b2647191a879bbc10b3d18a46cb8a604b3 Author: hujianyang Date: Tue Dec 30 11:56:09 2014 +0800 UBI: fix soft lockup in ubi_check_volume() commit 9aa272b492e7551a9ee0e2c83c720ea013698485 upstream. Running mtd-utils/tests/ubi-tests/io_basic.c could cause soft lockup or watchdog reset. It is because *updatevol* will perform ubi_check_volume() after updating finish and this function will full scan the updated lebs if the volume is initialized as STATIC_VOLUME. This patch adds *cond_resched()* in the loop of lebs scan to avoid soft lockup. Helped by Richard Weinberger [ 2158.067096] INFO: rcu_sched self-detected stall on CPU { 1} (t=2101 jiffies g=1606 c=1605 q=56) [ 2158.172867] CPU: 1 PID: 2073 Comm: io_basic Tainted: G O 3.10.53 #21 [ 2158.172898] [] (unwind_backtrace+0x0/0x120) from [] (show_stack+0x10/0x14) [ 2158.172918] [] (show_stack+0x10/0x14) from [] (rcu_check_callbacks+0x1c0/0x660) [ 2158.172936] [] (rcu_check_callbacks+0x1c0/0x660) from [] (update_process_times+0x38/0x64) [ 2158.172953] [] (update_process_times+0x38/0x64) from [] (tick_sched_handle+0x54/0x60) [ 2158.172966] [] (tick_sched_handle+0x54/0x60) from [] (tick_sched_timer+0x44/0x74) [ 2158.172978] [] (tick_sched_timer+0x44/0x74) from [] (__run_hrtimer+0xc8/0x1b8) [ 2158.172992] [] (__run_hrtimer+0xc8/0x1b8) from [] (hrtimer_interrupt+0x128/0x2a4) [ 2158.173007] [] (hrtimer_interrupt+0x128/0x2a4) from [] (arch_timer_handler_virt+0x28/0x30) [ 2158.173022] [] (arch_timer_handler_virt+0x28/0x30) from [] (handle_percpu_devid_irq+0x9c/0x124) [ 2158.173036] [] (handle_percpu_devid_irq+0x9c/0x124) from [] (generic_handle_irq+0x20/0x30) [ 2158.173049] [] (generic_handle_irq+0x20/0x30) from [] (handle_IRQ+0x64/0x8c) [ 2158.173060] [] (handle_IRQ+0x64/0x8c) from [] (gic_handle_irq+0x3c/0x60) [ 2158.173074] [] (gic_handle_irq+0x3c/0x60) from [] (__irq_svc+0x40/0x50) [ 2158.173083] Exception stack(0xc4043c98 to 0xc4043ce0) [ 2158.173092] 3c80: c4043ce4 00000019 [ 2158.173102] 3ca0: 1f8a865f c050ad10 1f8a864c 00000031 c04b5970 0003ebce 00000000 f3550000 [ 2158.173113] 3cc0: bf00bc68 00000800 0003ebce c4043ce0 c0186d14 c0186cb8 80000013 ffffffff [ 2158.173130] [] (__irq_svc+0x40/0x50) from [] (read_current_timer+0x4/0x38) [ 2158.173145] [] (read_current_timer+0x4/0x38) from [<1f8a865f>] (0x1f8a865f) [ 2183.927097] BUG: soft lockup - CPU#1 stuck for 22s! [io_basic:2073] [ 2184.002229] Modules linked in: nandflash(O) [last unloaded: nandflash] Signed-off-by: Wang Kai Signed-off-by: hujianyang Signed-off-by: Richard Weinberger Signed-off-by: Jiri Slaby commit 8a9a51ba2eff62e1a899daad7b623becfed8f3f1 Author: David S. Miller Date: Fri May 1 22:02:47 2015 -0400 ipv4: Missing sk_nulls_node_init() in ping_unhash(). [ Upstream commit a134f083e79fb4c3d0a925691e732c56911b4326 ] If we don't do that, then the poison value is left in the ->pprev backlink. This can cause crashes if we do a disconnect, followed by a connect(). Tested-by: Linus Torvalds Reported-by: Wen Xu Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 9767736a1c00e6603c61cac30e4f5a4a67ce16c7 Author: Sudip Mukherjee Date: Tue Mar 24 16:29:32 2015 +0530 staging: panel: fix lcd type commit 2c20d92dad5db6440cfa88d811b69fd605240ce4 upstream. the lcd type as defined in the Kconfig is not matching in the code. as a result the rs, rw and en pins were getting interchanged. Kconfig defines the value of PANEL_LCD to be 1 if we select custom configuration but in the code LCD_TYPE_CUSTOM is defined as 5. my hardware is LCD_TYPE_CUSTOM, but the pins were assigned to it as pins of LCD_TYPE_OLD, and it was not working. Now values are corrected with referenece to the values defined in Kconfig and it is working. checked on JHD204A lcd with LCD_TYPE_CUSTOM configuration. Cc: # 2.6.32+ Signed-off-by: Sudip Mukherjee Acked-by: Willy Tarreau Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit 5f30307e19b93df1e80b073b15967f53850ad33d Author: Kirill A. Shutemov Date: Fri Dec 20 15:10:03 2013 +0200 mm: Fix NULL pointer dereference in madvise(MADV_WILLNEED) support commit ee53664bda169f519ce3c6a22d378f0b946c8178 upstream. Sasha Levin found a NULL pointer dereference that is due to a missing page table lock, which in turn is due to the pmd entry in question being a transparent huge-table entry. The code - introduced in commit 1998cc048901 ("mm: make madvise(MADV_WILLNEED) support swap file prefetch") - correctly checks for this situation using pmd_none_or_trans_huge_or_clear_bad(), but it turns out that that function doesn't work correctly. pmd_none_or_trans_huge_or_clear_bad() expected that pmd_bad() would trigger if the transparent hugepage bit was set, but it doesn't do that if pmd_numa() is also set. Note that the NUMA bit only gets set on real NUMA machines, so people trying to reproduce this on most normal development systems would never actually trigger this. Fix it by removing the very subtle (and subtly incorrect) expectation, and instead just checking pmd_trans_huge() explicitly. Reported-by: Sasha Levin Acked-by: Andrea Arcangeli [ Additionally remove the now stale test for pmd_trans_huge() inside the pmd_bad() case - Linus ] Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 5176b77f1aacdc560eaeac4685ade444bb814689 Author: Jann Horn Date: Sun Apr 19 02:48:39 2015 +0200 fs: take i_mutex during prepare_binprm for set[ug]id executables commit 8b01fc86b9f425899f8a3a8fc1c47d73c2c20543 upstream. This prevents a race between chown() and execve(), where chowning a setuid-user binary to root would momentarily make the binary setuid root. This patch was mostly written by Linus Torvalds. Signed-off-by: Jann Horn Signed-off-by: Linus Torvalds Signed-off-by: Charles Williams Signed-off-by: Jiri Slaby commit 91350acb28a60304636f9a8d6f739e0b2e99ef10 Author: Junjie Mao Date: Wed Jan 28 10:02:44 2015 +0800 driver core: bus: Goto appropriate labels on failure in bus_add_device commit 1c34203a1496d1849ba978021b878b3447d433c8 upstream. It is not necessary to call device_remove_groups() when device_add_groups() fails. The group added by device_add_groups() should be removed if sysfs_create_link() fails. Fixes: fa6fdb33b486 ("driver core: bus_type: add dev_groups") Signed-off-by: Junjie Mao Signed-off-by: Jiri Slaby commit b9935667725633145bda55b53bd1694f64af6a42 Author: Dan Carpenter Date: Thu Apr 16 12:48:35 2015 -0700 memstick: mspro_block: add missing curly braces commit 13f6b191aaa11c7fd718d35a0c565f3c16bc1d99 upstream. Using the indenting we can see the curly braces were obviously intended. This is a static checker fix, but my guess is that we don't read enough bytes, because we don't calculate "t_len" correctly. Fixes: f1d82698029b ('memstick: use fully asynchronous request processing') Signed-off-by: Dan Carpenter Cc: Alex Dubov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit ba394ccc0727dbe469d7320ef5edb2d26cf161d6 Author: Nishanth Menon Date: Sat Mar 7 03:39:05 2015 -0600 C6x: time: Ensure consistency in __init commit f4831605f2dacd12730fe73961c77253cc2ea425 upstream. time_init invokes timer64_init (which is __init annotation) since all of these are invoked at init time, lets maintain consistency by ensuring time_init is marked appropriately as well. This fixes the following warning with CONFIG_DEBUG_SECTION_MISMATCH=y WARNING: vmlinux.o(.text+0x3bfc): Section mismatch in reference from the function time_init() to the function .init.text:timer64_init() The function time_init() references the function __init timer64_init(). This is often because time_init lacks a __init annotation or the annotation of timer64_init is wrong. Fixes: 546a39546c64 ("C6X: time management") Signed-off-by: Nishanth Menon Signed-off-by: Mark Salter Signed-off-by: Jiri Slaby commit 1b2a7da9eef52482bbc5a80dcf1b9c86d6997373 Author: Vutla, Lokesh Date: Tue Mar 31 09:52:25 2015 +0530 crypto: omap-aes - Fix support for unequal lengths commit 6d7e7e02a044025237b6f62a20521170b794537f upstream. For cases where total length of an input SGs is not same as length of the input data for encryption, omap-aes driver crashes. This happens in the case when IPsec is trying to use omap-aes driver. To avoid this, we copy all the pages from the input SG list into a contiguous buffer and prepare a single element SG list for this buffer with length as the total bytes to crypt, which is similar thing that is done in case of unaligned lengths. Fixes: 6242332ff2f3 ("crypto: omap-aes - Add support for cases of unaligned lengths") Signed-off-by: Lokesh Vutla Signed-off-by: Herbert Xu Signed-off-by: Jiri Slaby commit dbbf764b9d245967c8a86e17e33e2bc89a6cfecc Author: Nicolas Iooss Date: Fri Mar 13 15:17:14 2015 +0800 wl18xx: show rx_frames_per_rates as an array as it really is commit a3fa71c40f1853d0c27e8f5bc01a722a705d9682 upstream. In struct wl18xx_acx_rx_rate_stat, rx_frames_per_rates field is an array, not a number. This means WL18XX_DEBUGFS_FWSTATS_FILE can't be used to display this field in debugfs (it would display a pointer, not the actual data). Use WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY instead. This bug has been found by adding a __printf attribute to wl1271_format_buffer. gcc complained about "format '%u' expects argument of type 'unsigned int', but argument 5 has type 'u32 *'". Fixes: c5d94169e818 ("wl18xx: use new fw stats structures") Signed-off-by: Nicolas Iooss Signed-off-by: Kalle Valo Signed-off-by: Jiri Slaby commit bf0e4b9ab5fbbd3488246d841032776e45238341 Author: mancha security Date: Wed Mar 18 18:47:25 2015 +0100 lib: memzero_explicit: use barrier instead of OPTIMIZER_HIDE_VAR commit 0b053c9518292705736329a8fe20ef4686ffc8e9 upstream. OPTIMIZER_HIDE_VAR(), as defined when using gcc, is insufficient to ensure protection from dead store optimization. For the random driver and crypto drivers, calls are emitted ... $ gdb vmlinux (gdb) disassemble memzero_explicit Dump of assembler code for function memzero_explicit: 0xffffffff813a18b0 <+0>: push %rbp 0xffffffff813a18b1 <+1>: mov %rsi,%rdx 0xffffffff813a18b4 <+4>: xor %esi,%esi 0xffffffff813a18b6 <+6>: mov %rsp,%rbp 0xffffffff813a18b9 <+9>: callq 0xffffffff813a7120 0xffffffff813a18be <+14>: pop %rbp 0xffffffff813a18bf <+15>: retq End of assembler dump. (gdb) disassemble extract_entropy [...] 0xffffffff814a5009 <+313>: mov %r12,%rdi 0xffffffff814a500c <+316>: mov $0xa,%esi 0xffffffff814a5011 <+321>: callq 0xffffffff813a18b0 0xffffffff814a5016 <+326>: mov -0x48(%rbp),%rax [...] ... but in case in future we might use facilities such as LTO, then OPTIMIZER_HIDE_VAR() is not sufficient to protect gcc from a possible eviction of the memset(). We have to use a compiler barrier instead. Minimal test example when we assume memzero_explicit() would *not* be a call, but would have been *inlined* instead: static inline void memzero_explicit(void *s, size_t count) { memset(s, 0, count); } int main(void) { char buff[20]; snprintf(buff, sizeof(buff) - 1, "test"); printf("%s", buff); memzero_explicit(buff, sizeof(buff)); return 0; } With := OPTIMIZER_HIDE_VAR(): (gdb) disassemble main Dump of assembler code for function main: [...] 0x0000000000400464 <+36>: callq 0x400410 0x0000000000400469 <+41>: xor %eax,%eax 0x000000000040046b <+43>: add $0x28,%rsp 0x000000000040046f <+47>: retq End of assembler dump. With := barrier(): (gdb) disassemble main Dump of assembler code for function main: [...] 0x0000000000400464 <+36>: callq 0x400410 0x0000000000400469 <+41>: movq $0x0,(%rsp) 0x0000000000400471 <+49>: movq $0x0,0x8(%rsp) 0x000000000040047a <+58>: movl $0x0,0x10(%rsp) 0x0000000000400482 <+66>: xor %eax,%eax 0x0000000000400484 <+68>: add $0x28,%rsp 0x0000000000400488 <+72>: retq End of assembler dump. As can be seen, movq, movq, movl are being emitted inlined via memset(). Reference: http://thread.gmane.org/gmane.linux.kernel.cryptoapi/13764/ Fixes: d4c5efdb9777 ("random: add and use memzero_explicit() for clearing data") Cc: Theodore Ts'o Signed-off-by: mancha security Signed-off-by: Daniel Borkmann Acked-by: Hannes Frederic Sowa Acked-by: Stephan Mueller Signed-off-by: Herbert Xu Signed-off-by: Jiri Slaby commit 47cd2dc5042d17bfa81e6d6ca52c6e019af0a871 Author: Sabrina Dubroca Date: Thu Feb 26 05:35:41 2015 +0000 e1000: add dummy allocator to fix race condition between mtu change and netpoll commit 08e8331654d1d7b2c58045e549005bc356aa7810 upstream. There is a race condition between e1000_change_mtu's cleanups and netpoll, when we change the MTU across jumbo size: Changing MTU frees all the rx buffers: e1000_change_mtu -> e1000_down -> e1000_clean_all_rx_rings -> e1000_clean_rx_ring Then, close to the end of e1000_change_mtu: pr_info -> ... -> netpoll_poll_dev -> e1000_clean -> e1000_clean_rx_irq -> e1000_alloc_rx_buffers -> e1000_alloc_frag And when we come back to do the rest of the MTU change: e1000_up -> e1000_configure -> e1000_configure_rx -> e1000_alloc_jumbo_rx_buffers alloc_jumbo finds the buffers already != NULL, since data (shared with page in e1000_rx_buffer->rxbuf) has been re-alloc'd, but it's garbage, or at least not what is expected when in jumbo state. This results in an unusable adapter (packets don't get through), and a NULL pointer dereference on the next call to e1000_clean_rx_ring (other mtu change, link down, shutdown): BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] put_compound_page+0x7e/0x330 [...] Call Trace: [] put_page+0x55/0x60 [] e1000_clean_rx_ring+0x134/0x200 [] e1000_clean_all_rx_rings+0x45/0x60 [] e1000_down+0x1c0/0x1d0 [] ? deactivate_slab+0x7f0/0x840 [] e1000_change_mtu+0xdc/0x170 [] dev_set_mtu+0xa0/0x140 [] do_setlink+0x218/0xac0 [] ? nla_parse+0xb9/0x120 [] rtnl_newlink+0x6d0/0x890 [] ? kvm_clock_read+0x20/0x40 [] ? sched_clock_cpu+0xa8/0x100 [] rtnetlink_rcv_msg+0x92/0x260 By setting the allocator to a dummy version, netpoll can't mess up our rx buffers. The allocator is set back to a sane value in e1000_configure_rx. Fixes: edbbb3ca1077 ("e1000: implement jumbo receive with partial descriptors") Signed-off-by: Sabrina Dubroca Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Jiri Slaby commit 4e75ff4f0985418801dd55d90208dcf989f3c9fd Author: Calvin Owens Date: Tue Jan 13 13:16:18 2015 -0800 ksoftirqd: Enable IRQs and call cond_resched() before poking RCU commit 28423ad283d5348793b0c45cc9b1af058e776fd6 upstream. While debugging an issue with excessive softirq usage, I encountered the following note in commit 3e339b5dae24a706 ("softirq: Use hotplug thread infrastructure"): [ paulmck: Call rcu_note_context_switch() with interrupts enabled. ] ...but despite this note, the patch still calls RCU with IRQs disabled. This seemingly innocuous change caused a significant regression in softirq CPU usage on the sending side of a large TCP transfer (~1 GB/s): when introducing 0.01% packet loss, the softirq usage would jump to around 25%, spiking as high as 50%. Before the change, the usage would never exceed 5%. Moving the call to rcu_note_context_switch() after the cond_sched() call, as it was originally before the hotplug patch, completely eliminated this problem. Signed-off-by: Calvin Owens Signed-off-by: Paul E. McKenney Signed-off-by: Mike Galbraith Signed-off-by: Jiri Slaby commit 6e310c82af1ba014a4bb312551d1a74d1c71761a Author: Al Viro Date: Fri Apr 24 15:47:07 2015 -0400 RCU pathwalk breakage when running into a symlink overmounting something commit 3cab989afd8d8d1bc3d99fef0e7ed87c31e7b647 upstream. Calling unlazy_walk() in walk_component() and do_last() when we find a symlink that needs to be followed doesn't acquire a reference to vfsmount. That's fine when the symlink is on the same vfsmount as the parent directory (which is almost always the case), but it's not always true - one _can_ manage to bind a symlink on top of something. And in such cases we end up with excessive mntput(). Signed-off-by: Al Viro Signed-off-by: Jiri Slaby commit 378e22f618cf6c4274fd7b928fd7b10ec380c6f6 Author: Dmitry Torokhov Date: Tue Apr 21 09:49:11 2015 -0700 drm/i915: cope with large i2c transfers commit 9535c4757b881e06fae72a857485ad57c422b8d2 upstream. The hardware, according to the specs, is limited to 256 byte transfers, and current driver has no protections in case users attempt to do larger transfers. The code will just stomp over status register and mayhem ensues. Let's split larger transfers into digestable chunks. Doing this allows Atmel MXT driver on Pixel 1 function properly (it hasn't since commit 9d8dc3e529a19e427fd379118acd132520935c5d "Input: atmel_mxt_ts - implement T44 message handling" which tries to consume multiple touchscreen/touchpad reports in a single transaction). Reviewed-by: Chris Wilson Signed-off-by: Dmitry Torokhov Signed-off-by: Jani Nikula Signed-off-by: Jiri Slaby commit b1a930b834adf2625e71af96577bb1088c91dda4 Author: Alex Deucher Date: Tue Feb 24 11:29:21 2015 -0500 drm/radeon: fix doublescan modes (v2) commit fd99a0943ffaa0320ea4f69d09ed188f950c0432 upstream. Use the correct flags for atom. v2: handle DRM_MODE_FLAG_DBLCLK Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit 5d916df878fb0537484bb3f62a290fb91ff86bb0 Author: Mark Brown Date: Wed Apr 15 19:18:39 2015 +0100 i2c: core: Export bus recovery functions commit c1c21f4e60ed4523292f1a89ff45a208bddd3849 upstream. Current -next fails to link an ARM allmodconfig because drivers that use the core recovery functions can be built as modules but those functions are not exported: ERROR: "i2c_generic_gpio_recovery" [drivers/i2c/busses/i2c-davinci.ko] undefined! ERROR: "i2c_generic_scl_recovery" [drivers/i2c/busses/i2c-davinci.ko] undefined! ERROR: "i2c_recover_bus" [drivers/i2c/busses/i2c-davinci.ko] undefined! Add exports to fix this. Fixes: 5f9296ba21b3c (i2c: Add bus recovery infrastructure) Signed-off-by: Mark Brown Signed-off-by: Wolfram Sang Signed-off-by: Jiri Slaby commit ef7c261897ba8bdf1cf0f5e5839ecc13f655314b Author: Erez Shitrit Date: Thu Apr 2 13:39:05 2015 +0300 IB/mlx4: Fix WQE LSO segment calculation commit ca9b590caa17bcbbea119594992666e96cde9c2f upstream. The current code decreases from the mss size (which is the gso_size from the kernel skb) the size of the packet headers. It shouldn't do that because the mss that comes from the stack (e.g IPoIB) includes only the tcp payload without the headers. The result is indication to the HW that each packet that the HW sends is smaller than what it could be, and too many packets will be sent for big messages. An easy way to demonstrate one more aspect of the problem is by configuring the ipoib mtu to be less than 2*hlen (2*56) and then run app sending big TCP messages. This will tell the HW to send packets with giant (negative value which under unsigned arithmetics becomes a huge positive one) length and the QP moves to SQE state. Fixes: b832be1e4007 ('IB/mlx4: Add IPoIB LSO support') Reported-by: Matthew Finlay Signed-off-by: Erez Shitrit Signed-off-by: Or Gerlitz Signed-off-by: Doug Ledford Signed-off-by: Jiri Slaby commit 06c7b3ec2c41cb80c573846b0fb23bbe015950ad Author: Yann Droneaud Date: Mon Apr 13 14:56:23 2015 +0200 IB/core: don't disallow registering region starting at 0x0 commit 66578b0b2f69659f00b6169e6fe7377c4b100d18 upstream. In a call to ib_umem_get(), if address is 0x0 and size is already page aligned, check added in commit 8494057ab5e4 ("IB/uverbs: Prevent integer overflow in ib_umem_get address arithmetic") will refuse to register a memory region that could otherwise be valid (provided vm.mmap_min_addr sysctl and mmap_low_allowed SELinux knobs allow userspace to map something at address 0x0). This patch allows back such registration: ib_umem_get() should probably don't care of the base address provided it can be pinned with get_user_pages(). There's two possible overflows, in (addr + size) and in PAGE_ALIGN(addr + size), this patch keep ensuring none of them happen while allowing to pin memory at address 0x0. Anyway, the case of size equal 0 is no more (partially) handled as 0-length memory region are disallowed by an earlier check. Link: http://mid.gmane.org/cover.1428929103.git.ydroneaud@opteya.com Cc: Shachar Raindel Cc: Jack Morgenstein Cc: Or Gerlitz Signed-off-by: Yann Droneaud Reviewed-by: Sagi Grimberg Reviewed-by: Haggai Eran Signed-off-by: Doug Ledford Signed-off-by: Jiri Slaby commit 345726e427333c88b88ac8add3c0e6ab3120d21d Author: Yann Droneaud Date: Mon Apr 13 14:56:22 2015 +0200 IB/core: disallow registering 0-sized memory region commit 8abaae62f3fdead8f4ce0ab46b4ab93dee39bab2 upstream. If ib_umem_get() is called with a size equal to 0 and an non-page aligned address, one page will be pinned and a 0-sized umem will be returned to the caller. This should not be allowed: it's not expected for a memory region to have a size equal to 0. This patch adds a check to explicitly refuse to register a 0-sized region. Link: http://mid.gmane.org/cover.1428929103.git.ydroneaud@opteya.com Cc: Shachar Raindel Cc: Jack Morgenstein Cc: Or Gerlitz Signed-off-by: Yann Droneaud Signed-off-by: Doug Ledford Signed-off-by: Jiri Slaby commit 19b7fcb14241ac44c184abbfa004574b1e7a0203 Author: Ezequiel Garcia Date: Tue Mar 10 11:37:14 2015 -0300 stk1160: Make sure current buffer is released commit aeff09276748b66072f2db2e668cec955cf41959 upstream. The available (i.e. not used) buffers are returned by stk1160_clear_queue(), on the stop_streaming() path. However, this is insufficient and the current buffer must be released as well. Fix it. Signed-off-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jiri Slaby commit e0344d11157175acfc18600b5645a59cc7c3b715 Author: James Bottomley Date: Wed Apr 15 22:16:01 2015 -0700 mvsas: fix panic on expander attached SATA devices commit 56cbd0ccc1b508de19561211d7ab9e1c77e6b384 upstream. mvsas is giving a General protection fault when it encounters an expander attached ATA device. Analysis of mvs_task_prep_ata() shows that the driver is assuming all ATA devices are locally attached and obtaining the phy mask by indexing the local phy table (in the HBA structure) with the phy id. Since expanders have many more phys than the HBA, this is causing the index into the HBA phy table to overflow and returning rubbish as the pointer. mvs_task_prep_ssp() instead does the phy mask using the port properties. Mirror this in mvs_task_prep_ata() to fix the panic. Reported-by: Adam Talbot Tested-by: Adam Talbot Signed-off-by: James Bottomley Signed-off-by: Jiri Slaby commit ec091a7e9aad7a56e4991c8fe3891fb8c0352d31 Author: K. Y. Srinivasan Date: Fri Feb 27 11:26:04 2015 -0800 Drivers: hv: vmbus: Fix a bug in the error path in vmbus_open() commit 40384e4bbeb9f2651fe9bffc0062d9f31ef625bf upstream. Correctly rollback state if the failure occurs after we have handed over the ownership of the buffer to the host. Signed-off-by: K. Y. Srinivasan Signed-off-by: Jiri Slaby commit a4bba4c18227fdcb246115d08507621b1181af40 Author: Gregory CLEMENT Date: Thu Apr 2 17:11:11 2015 +0200 gpio: mvebu: Fix mask/unmask managment per irq chip type commit 61819549f572edd7fce53f228c0d8420cdc85f71 upstream. Level IRQ handlers and edge IRQ handler are managed by tow different sets of registers. But currently the driver uses the same mask for the both registers. It lead to issues with the following scenario: First, an IRQ is requested on a GPIO to be triggered on front. After, this an other IRQ is requested for a GPIO of the same bank but triggered on level. Then the first one will be also setup to be triggered on level. It leads to an interrupt storm. The different kind of handler are already associated with two different irq chip type. With this patch the driver uses a private mask for each one which solves this issue. It has been tested on an Armada XP based board and on an Armada 375 board. For the both boards, with this patch is applied, there is no such interrupt storm when running the previous scenario. This bug was already fixed but in a different way in the legacy version of this driver by Evgeniy Dushistov: 9ece8839b1277fb9128ff6833411614ab6c88d68 "ARM: orion: Fix for certain sequence of request_irq can cause irq storm". The fact the new version of the gpio drive could be affected had been discussed there: http://thread.gmane.org/gmane.linux.ports.arm.kernel/344670/focus=364012 Reported-by: Evgeniy A. Dushistov Signed-off-by: Gregory CLEMENT Signed-off-by: Linus Walleij Signed-off-by: Jiri Slaby commit 26ef1aba66950f3ee8f527cc5a63794957a3ce85 Author: Max Filippov Date: Fri Apr 3 09:56:21 2015 +0300 xtensa: ISS: fix locking in TAP network adapter commit 24e94454c8cb6a13634f5a2f5a01da53a546a58d upstream. - don't lock lp->lock in the iss_net_timer for the call of iss_net_poll, it will lock it itself; - invert order of lp->lock and opened_lock acquisition in the iss_net_open to make it consistent with iss_net_poll; - replace spin_lock with spin_lock_bh when acquiring locks used in iss_net_timer from non-atomic context; - replace spin_lock_irqsave with spin_lock_bh in the iss_net_start_xmit as the driver doesn't use lp->lock in the hard IRQ context; - replace __SPIN_LOCK_UNLOCKED(lp.lock) with spin_lock_init, otherwise lockdep is unhappy about using non-static key. Signed-off-by: Max Filippov Signed-off-by: Jiri Slaby commit f7000522e85ef754db1bd73f8ccdb1990178c23d Author: Max Filippov Date: Fri Feb 27 11:02:38 2015 +0300 xtensa: provide __NR_sync_file_range2 instead of __NR_sync_file_range commit 01e84c70fe40c8111f960987bcf7f931842e6d07 upstream. xtensa actually uses sync_file_range2 implementation, so it should define __NR_sync_file_range2 as other architectures that use that function. That fixes userspace interface (that apparently never worked) and avoids special-casing xtensa in libc implementations. See the thread ending at http://lists.busybox.net/pipermail/uclibc/2015-February/048833.html for more details. Signed-off-by: Max Filippov Signed-off-by: Jiri Slaby commit daf87596a7be66054c13f59dfbe3997b8aa69028 Author: Max Filippov Date: Fri Feb 27 06:28:00 2015 +0300 xtensa: xtfpga: fix hardware lockup caused by LCD driver commit 4949009eb8d40a441dcddcd96e101e77d31cf1b2 upstream. LCD driver is always built for the XTFPGA platform, but its base address is not configurable, and is wrong for ML605/KC705. Its initialization locks up KC705 board hardware. Make the whole driver optional, and its base address and bus width configurable. Implement 4-bit bus access method. Signed-off-by: Max Filippov Signed-off-by: Jiri Slaby commit a77ea427cc3d75a4a2d07f6bcc96b49ed67ebe7c Author: Lv Zheng Date: Mon Apr 13 11:48:58 2015 +0800 ACPICA: Utilities: split IO address types from data type models. commit 2b8760100e1de69b6ff004c986328a82947db4ad upstream. ACPICA commit aacf863cfffd46338e268b7415f7435cae93b451 It is reported that on a physically 64-bit addressed machine, 32-bit kernel can trigger crashes in accessing the memory regions that are beyond the 32-bit boundary. The region field's start address should still be 32-bit compliant, but after a calculation (adding some offsets), it may exceed the 32-bit boundary. This case is rare and buggy, but there are real BIOSes leaked with such issues (see References below). This patch fixes this gap by always defining IO addresses as 64-bit, and allows OSPMs to optimize it for a real 32-bit machine to reduce the size of the internal objects. Internal acpi_physical_address usages in the structures that can be fixed by this change include: 1. struct acpi_object_region: acpi_physical_address address; 2. struct acpi_address_range: acpi_physical_address start_address; acpi_physical_address end_address; 3. struct acpi_mem_space_context; acpi_physical_address address; 4. struct acpi_table_desc acpi_physical_address address; See known issues 1 for other usages. Note that acpi_io_address which is used for ACPI_PROCESSOR may also suffer from same problem, so this patch changes it accordingly. For iasl, it will enforce acpi_physical_address as 32-bit to generate 32-bit OSPM compatible tables on 32-bit platforms, we need to define ACPI_32BIT_PHYSICAL_ADDRESS for it in acenv.h. Known issues: 1. Cleanup of mapped virtual address In struct acpi_mem_space_context, acpi_physical_address is used as a virtual address: acpi_physical_address mapped_physical_address; It is better to introduce acpi_virtual_address or use acpi_size instead. This patch doesn't make such a change. Because this should be done along with a change to acpi_os_map_memory()/acpi_os_unmap_memory(). There should be no functional problem to leave this unchanged except that only this structure is enlarged unexpectedly. Link: https://github.com/acpica/acpica/commit/aacf863c Reference: https://bugzilla.kernel.org/show_bug.cgi?id=87971 Reference: https://bugzilla.kernel.org/show_bug.cgi?id=79501 Reported-and-tested-by: Paul Menzel Reported-and-tested-by: Sial Nije Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki Signed-off-by: Jiri Slaby commit c22a2c6107e75e256ec79b070aee683767752ef1 Author: Dave Olson Date: Thu Apr 2 21:28:45 2015 -0700 powerpc: Fix missing L2 cache size in /sys/devices/system/cpu commit f7e9e358362557c3aa2c1ec47490f29fe880a09e upstream. This problem appears to have been introduced in 2.6.29 by commit 93197a36a9c1 "Rewrite sysfs processor cache info code". This caused lscpu to error out on at least e500v2 devices, eg: error: cannot open /sys/devices/system/cpu/cpu0/cache/index2/size: No such file or directory Some embedded powerpc systems use cache-size in DTS for the unified L2 cache size, not d-cache-size, so we need to allow for both DTS names. Added a new CACHE_TYPE_UNIFIED_D cache_type_info structure to handle this. Fixes: 93197a36a9c1 ("powerpc: Rewrite sysfs processor cache info code") Signed-off-by: Dave Olson Signed-off-by: Michael Ellerman Signed-off-by: Jiri Slaby commit 15dc904c9a3c816efb06182b538031e61e1e91c6 Author: Alexander Ploumistos Date: Fri Feb 13 21:05:11 2015 +0200 Bluetooth: ath3k: Add support Atheros AR5B195 combo Mini PCIe card commit 2eeff0b4317a02f0e281df891d990194f0737aae upstream. Add 04f2:aff1 to ath3k.c supported devices list and btusb.c blacklist, so that the device can load the ath3k firmware and re-enumerate itself as an AR3011 device. T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04f2 ProdID=aff1 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Alexander Ploumistos Signed-off-by: Marcel Holtmann Signed-off-by: Jiri Slaby commit 15a557ae69ea1e86aa8db5c9a48f7406d9235b72 Author: Nicholas Bellinger Date: Tue Apr 7 21:53:27 2015 +0000 target: Fix COMPARE_AND_WRITE with SG_TO_MEM_NOALLOC handling commit c8e639852ad720499912acedfd6b072325fd2807 upstream. This patch fixes a bug for COMPARE_AND_WRITE handling with fabrics using SCF_PASSTHROUGH_SG_TO_MEM_NOALLOC. It adds the missing allocation for cmd->t_bidi_data_sg within transport_generic_new_cmd() that is used by COMPARE_AND_WRITE for the initial READ payload, even if the fabric is already providing a pre-allocated buffer for cmd->t_data_sg. Also, fix zero-length COMPARE_AND_WRITE handling within the compare_and_write_callback() and target_complete_ok_work() to queue the response, skipping the initial READ. This fixes COMPARE_AND_WRITE emulation with loopback, vhost, and xen-backend fabric drivers using SG_TO_MEM_NOALLOC. Reported-by: Christoph Hellwig Cc: Christoph Hellwig Signed-off-by: Nicholas Bellinger Signed-off-by: Jiri Slaby commit 616d9390b1db74097735ac58346d164d2fa2d16b Author: K. Y. Srinivasan Date: Fri Mar 27 00:27:18 2015 -0700 scsi: storvsc: Fix a bug in copy_from_bounce_buffer() commit 8de580742fee8bc34d116f57a20b22b9a5f08403 upstream. We may exit this function without properly freeing up the maapings we may have acquired. Fix the bug. Signed-off-by: K. Y. Srinivasan Reviewed-by: Long Li Signed-off-by: James Bottomley Signed-off-by: Jiri Slaby commit 6e86d18aa0f3615c66d7ae47d78c7717e8ef0234 Author: Brian Norris Date: Sat Feb 28 02:23:28 2015 -0800 UBI: fix check for "too many bytes" commit 299d0c5b27346a77a0777c993372bf8777d4f2e5 upstream. The comparison from the previous line seems to have been erroneously (partially) copied-and-pasted onto the next. The second line should be checking req.bytes, not req.lnum. Coverity CID #139400 Signed-off-by: Brian Norris [rw: Fixed comparison] Signed-off-by: Richard Weinberger Signed-off-by: Jiri Slaby commit 066f6610ef5196373fd2422e82e6844f38dbb95f Author: Brian Norris Date: Sat Feb 28 02:23:27 2015 -0800 UBI: initialize LEB number variable commit f16db8071ce18819fbd705ddcc91c6f392fb61f8 upstream. In some of the 'out_not_moved' error paths, lnum may be used uninitialized. Don't ignore the warning; let's fix it. This uninitialized variable doesn't have much visible effect in the end, since we just schedule the PEB for erasure, and its LEB number doesn't really matter (it just gets printed in debug messages). But let's get it straight anyway. Coverity CID #113449 Signed-off-by: Brian Norris Signed-off-by: Richard Weinberger Signed-off-by: Jiri Slaby commit 8926a8a1855b8edc24780c31b6a734901cb42f43 Author: Brian Norris Date: Sat Feb 28 02:23:26 2015 -0800 UBI: fix out of bounds write commit d74adbdb9abf0d2506a6c4afa534d894f28b763f upstream. If aeb->len >= vol->reserved_pebs, we should not be writing aeb into the PEB->LEB mapping. Caught by Coverity, CID #711212. Signed-off-by: Brian Norris Signed-off-by: Richard Weinberger Signed-off-by: Jiri Slaby commit fa4a3fc61b8cfc9c9ee19215906f496804d30751 Author: Brian Norris Date: Sat Feb 28 02:23:25 2015 -0800 UBI: account for bitflips in both the VID header and data commit 8eef7d70f7c6772c3490f410ee2bceab3b543fa1 upstream. We are completely discarding the earlier value of 'bitflips', which could reflect a bitflip found in ubi_io_read_vid_hdr(). Let's use the bitwise OR of header and data 'bitflip' statuses instead. Coverity CID #1226856 Signed-off-by: Brian Norris Signed-off-by: Richard Weinberger Signed-off-by: Jiri Slaby commit 3d24bbbe6638ce1d873e9ebe56861499688c4d3f Author: Thomas D Date: Mon Jan 5 21:37:23 2015 +0100 tools/power turbostat: Use $(CURDIR) instead of $(PWD) and add support for O= option in Makefile commit f82263c6989c31ae9b94cecddffb29dcbec38710 upstream. Since commit ee0778a30153 ("tools/power: turbostat: make Makefile a bit more capable") turbostat's Makefile is using [...] BUILD_OUTPUT := $(PWD) [...] which obviously causes trouble when building "turbostat" with make -C /usr/src/linux/tools/power/x86/turbostat ARCH=x86 turbostat because GNU make does not update nor guarantee that $PWD is set. This patch changes the Makefile to use $CURDIR instead, which GNU make guarantees to set and update (i.e. when using "make -C ...") and also adds support for the O= option (see "make help" in your root of your kernel source tree for more details). Link: https://bugs.gentoo.org/show_bug.cgi?id=533918 Fixes: ee0778a30153 ("tools/power: turbostat: make Makefile a bit more capable") Signed-off-by: Thomas D. Cc: Mark Asselstine Signed-off-by: Len Brown Signed-off-by: Jiri Slaby commit ed890db87d70676e40528cdb7cf4aa2fb9e9c80f Author: Steven Rostedt (Red Hat) Date: Tue Mar 24 09:57:55 2015 -0400 tools lib traceevent kbuffer: Remove extra update to data pointer in PADDING commit c5e691928bf166ac03430e957038b60adba3cf6c upstream. When a event PADDING is hit (a deleted event that is still in the ring buffer), translate_data() sets the length of the padding and also updates the data pointer which is passed back to the caller. This is unneeded because the caller also updates the data pointer with the passed back length. translate_data() should not update the pointer, only set the length. Signed-off-by: Steven Rostedt Cc: Andrew Morton Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lkml.kernel.org/r/20150324135923.461431960@goodmis.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Jiri Slaby commit d15e6bc4606b27f53ef70a99d05690fa5a0e6c45 Author: Anton Blanchard Date: Tue Apr 14 07:51:03 2015 +1000 powerpc/perf: Cap 64bit userspace backtraces to PERF_MAX_STACK_DEPTH commit 9a5cbce421a283e6aea3c4007f141735bf9da8c3 upstream. We cap 32bit userspace backtraces to PERF_MAX_STACK_DEPTH (currently 127), but we forgot to do the same for 64bit backtraces. Signed-off-by: Anton Blanchard Signed-off-by: Michael Ellerman Signed-off-by: Jiri Slaby commit f7b22e25281cd03ed8c7f5ebb559dc109bb592cc Author: Lukas Czerner Date: Fri Apr 3 10:46:58 2015 -0400 ext4: make fsync to sync parent dir in no-journal for real this time commit e12fb97222fc41e8442896934f76d39ef99b590a upstream. Previously commit 14ece1028b3ed53ffec1b1213ffc6acaf79ad77c added a support for for syncing parent directory of newly created inodes to make sure that the inode is not lost after a power failure in no-journal mode. However this does not work in majority of cases, namely: - if the directory has inline data - if the directory is already indexed - if the directory already has at least one block and: - the new entry fits into it - or we've successfully converted it to indexed So in those cases we might lose the inode entirely even after fsync in the no-journal mode. This also includes ext2 default mode obviously. I've noticed this while running xfstest generic/321 and even though the test should fail (we need to run fsck after a crash in no-journal mode) I could not find a newly created entries even when if it was fsynced before. Fix this by adjusting the ext4_add_entry() successful exit paths to set the inode EXT4_STATE_NEWENTRY so that fsync has the chance to fsync the parent directory as well. Signed-off-by: Lukas Czerner Signed-off-by: Theodore Ts'o Reviewed-by: Jan Kara Cc: Frank Mayhar Signed-off-by: Jiri Slaby commit c74cbd65467dea55558b9c22fbd5ebfb4e95a5a6 Author: Arun Chandran Date: Thu Jun 26 15:16:03 2014 +0530 arm64: vdso: fix build error when switching from LE to BE commit 1915e2ad1cf548217c963121e4076b3d44dd0169 upstream. Building a kernel with CPU_BIG_ENDIAN fails if there are stale objects from a !CPU_BIG_ENDIAN build. Due to a missing FORCE prerequisite on an if_changed rule in the VDSO Makefile, we attempt to link a stale LE object into the new BE kernel. According to Documentation/kbuild/makefiles.txt, FORCE is required for if_changed rules and forgetting it is a common mistake, so fix it by 'Forcing' the build of vdso. This patch fixes build errors like these: arch/arm64/kernel/vdso/note.o: compiled for a little endian system and target is big endian failed to merge target specific data of file arch/arm64/kernel/vdso/note.o arch/arm64/kernel/vdso/sigreturn.o: compiled for a little endian system and target is big endian failed to merge target specific data of file arch/arm64/kernel/vdso/sigreturn.o Tested-by: Mark Rutland Signed-off-by: Arun Chandran Signed-off-by: Will Deacon Cc: Guenter Roeck Signed-off-by: Jiri Slaby commit bc6cd5f4d195af0baec777d2faf4697a9cc404f3 Author: Marek Vasut Date: Thu Mar 26 02:16:06 2015 +0100 rtlwifi: rtl8192cu: Add new device ID commit 9374e7d2fdcad3c36dafc8d3effd554bc702c4b6 upstream. Add new ID for ASUS N10 WiFi dongle. Signed-off-by: Marek Vasut Tested-by: Marek Vasut Cc: Larry Finger Cc: John W. Linville Acked-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Jiri Slaby commit 01bce3652e7b2d517b61c27abb10693ed746779b Author: Larry Finger Date: Mon Mar 23 18:14:10 2015 -0500 rtlwifi: rtl8192cu: Add new USB ID commit 2f92b314f4daff2117847ac5343c54d3d041bf78 upstream. USB ID 2001:330d is used for a D-Link DWA-131. Signed-off-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Jiri Slaby commit ac9008f85a2507f531b21e92f99f519521d152a4 Author: Oleg Nesterov Date: Thu Apr 16 12:47:29 2015 -0700 ptrace: fix race between ptrace_resume() and wait_task_stopped() commit b72c186999e689cb0b055ab1c7b3cd8fffbeb5ed upstream. ptrace_resume() is called when the tracee is still __TASK_TRACED. We set tracee->exit_code and then wake_up_state() changes tracee->state. If the tracer's sub-thread does wait() in between, task_stopped_code(ptrace => T) wrongly looks like another report from tracee. This confuses debugger, and since wait_task_stopped() clears ->exit_code the tracee can miss a signal. Test-case: #include #include #include #include #include #include int pid; void *waiter(void *arg) { int stat; for (;;) { assert(pid == wait(&stat)); assert(WIFSTOPPED(stat)); if (WSTOPSIG(stat) == SIGHUP) continue; assert(WSTOPSIG(stat) == SIGCONT); printf("ERR! extra/wrong report:%x\n", stat); } } int main(void) { pthread_t thread; pid = fork(); if (!pid) { assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0); for (;;) kill(getpid(), SIGHUP); } assert(pthread_create(&thread, NULL, waiter, NULL) == 0); for (;;) ptrace(PTRACE_CONT, pid, 0, SIGCONT); return 0; } Note for stable: the bug is very old, but without 9899d11f6544 "ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL" the fix should use lock_task_sighand(child). Signed-off-by: Oleg Nesterov Reported-by: Pavel Labath Tested-by: Pavel Labath Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit b255044d68f190693d799263eb4dab66813f2de9 Author: Michael Davidson Date: Tue Apr 14 15:47:38 2015 -0700 fs/binfmt_elf.c: fix bug in loading of PIE binaries commit a87938b2e246b81b4fb713edb371a9fa3c5c3c86 upstream. With CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE enabled, and a normal top-down address allocation strategy, load_elf_binary() will attempt to map a PIE binary into an address range immediately below mm->mmap_base. Unfortunately, load_elf_ binary() does not take account of the need to allocate sufficient space for the entire binary which means that, while the first PT_LOAD segment is mapped below mm->mmap_base, the subsequent PT_LOAD segment(s) end up being mapped above mm->mmap_base into the are that is supposed to be the "gap" between the stack and the binary. Since the size of the "gap" on x86_64 is only guaranteed to be 128MB this means that binaries with large data segments > 128MB can end up mapping part of their data segment over their stack resulting in corruption of the stack (and the data segment once the binary starts to run). Any PIE binary with a data segment > 128MB is vulnerable to this although address randomization means that the actual gap between the stack and the end of the binary is normally greater than 128MB. The larger the data segment of the binary the higher the probability of failure. Fix this by calculating the total size of the binary in the same way as load_elf_interp(). Signed-off-by: Michael Davidson Cc: Alexander Viro Cc: Jiri Kosina Cc: Kees Cook Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 40236427a828dd93a0dda9652063fb969a42aabd Author: Ulrik De Bie Date: Mon Apr 6 15:35:38 2015 -0700 Input: elantech - fix absolute mode setting on some ASUS laptops commit bd884149aca61de269fd9bad83fe2a4232ffab21 upstream. On ASUS TP500LN and X750JN, the touchpad absolute mode is reset each time set_rate is done. In order to fix this, we will verify the firmware version, and if it matches the one in those laptops, the set_rate function is overloaded with a function elantech_set_rate_restore_reg_07 that performs the set_rate with the original function, followed by a restore of reg_07 (the register that sets the absolute mode on elantech v4 hardware). Also the ASUS TP500LN and X750JN firmware version, capabilities, and button constellation is added to elantech.c Reported-and-tested-by: George Moutsopoulos Signed-off-by: Ulrik De Bie Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Slaby commit 52decd9be6f9c5401cf2711be0a8bbea71dfa3cd Author: Michael Gernoth Date: Thu Apr 9 23:42:15 2015 +0200 ALSA: emu10k1: don't deadlock in proc-functions commit 91bf0c2dcb935a87e5c0795f5047456b965fd143 upstream. The functions snd_emu10k1_proc_spdif_read and snd_emu1010_fpga_read acquire the emu_lock before accessing the FPGA. The function used to access the FPGA (snd_emu1010_fpga_read) also tries to take the emu_lock which causes a deadlock. Remove the outer locking in the proc-functions (guarding only the already safe fpga read) to prevent this deadlock. [removed superfluous flags variables too -- tiwai] Signed-off-by: Michael Gernoth Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit ac00ee011e26da21fc84b49a87a921098c842f91 Author: Felipe Balbi Date: Fri Feb 13 15:38:33 2015 -0600 usb: core: hub: use new USB_RESUME_TIMEOUT commit bbc78c07a51f6fd29c227b1220a9016e585358ba upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit 058b064116e332c1a94be9123325f608cf34d496 Author: Felipe Balbi Date: Fri Feb 13 15:03:13 2015 -0600 usb: dwc2: hcd: use new USB_RESUME_TIMEOUT commit 74bd7b69801819707713b88e9d0bc074efa2f5e7 upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit 0d1c8d590b7f2b1ec352ff99f9a003df97dded55 Author: Felipe Balbi Date: Fri Feb 13 15:00:38 2015 -0600 usb: host: sl811: use new USB_RESUME_TIMEOUT commit 08debfb13b199716da6153940c31968c556b195d upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit e308e9ae708d3abcab32f0078e0e847ca8e15a8a Author: Felipe Balbi Date: Fri Feb 13 14:39:13 2015 -0600 usb: host: xhci: use new USB_RESUME_TIMEOUT commit b9e451885deb6262dbaf5cd14aa77d192d9ac759 upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Acked-by: Mathias Nyman Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit ad33cca5c2c57f327582d03090beceb2ba5847d2 Author: Felipe Balbi Date: Fri Feb 13 14:50:10 2015 -0600 usb: host: isp116x: use new USB_RESUME_TIMEOUT commit 8c0ae6574ccfd3d619876a65829aad74c9d22ba5 upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit fbc1d545bc3dac3fc966429cb624c858fe66eb90 Author: Felipe Balbi Date: Fri Feb 13 14:58:53 2015 -0600 usb: host: r8a66597: use new USB_RESUME_TIMEOUT commit 7a606ac29752a3e571b83f9b3fceb1eaa1d37781 upstream. While this driver was already using a 50ms resume timeout, let's make sure everybody uses the same macro so it's easy to fix later should anything go wrong. It also gives a more "stable" expectation to Linux users. Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit 011370e24fd37be3f97ae5963d159d0058470946 Author: Felipe Balbi Date: Fri Feb 13 14:54:38 2015 -0600 usb: host: fotg210: use new USB_RESUME_TIMEOUT commit 7e136bb71a08e8b8be3bc492f041d9b0bea3856d upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit dc59ca097c98fb82bccf694060ace62885256e08 Author: Felipe Balbi Date: Fri Feb 13 14:44:17 2015 -0600 usb: host: uhci: use new USB_RESUME_TIMEOUT commit b8fb6f79f76f478acbbffccc966daa878f172a0a upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit 99fbbe284e4f337d198a12398549d2d142d8a42e Author: Felipe Balbi Date: Fri Feb 13 14:55:34 2015 -0600 usb: host: fusbh200: use new USB_RESUME_TIMEOUT commit 595227db1f2d98bfc33f02a55842f268e12b247d upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit ebe4ffa5657be8d4b640466fd0a91d73094ade48 Author: Felipe Balbi Date: Fri Feb 13 14:34:25 2015 -0600 usb: define a generic USB_RESUME_TIMEOUT macro commit 62f0342de1f012f3e90607d39e20fce811391169 upstream. Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus. Currently, almost every single USB controller is using a 20ms timeout for resume signalling. That's problematic for two reasons: a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification b) some (many) devices actually need more than 20ms resume signalling. Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using. At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure. Acked-by: Greg Kroah-Hartman Acked-by: Peter Chen Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit 7967436984383cbcde96a4758fde8ea514090234 Author: Axel Lin Date: Thu Mar 12 09:15:28 2015 +0800 usb: phy: Find the right match in devm_usb_phy_match commit 869aee0f31429fa9d94d5aef539602b73ae0cf4b upstream. The res parameter passed to devm_usb_phy_match() is the location where the pointer to the usb_phy is stored, hence it needs to be dereferenced before comparing to the match data in order to find the correct match. Fixes: 410219dcd2ba ("usb: otg: utils: devres: Add API's to associate a device with the phy") Signed-off-by: Axel Lin Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit 503c87f7e56c64e78c257f2ea50b321d36aaf40f Author: Sebastian Hesselbarth Date: Tue Feb 17 19:52:04 2015 +0100 ARM: dts: dove: Fix uart[23] reg property commit a74cd13b807029397f7232449df929bac11fb228 upstream. Fix Dove's register addresses of uart2 and uart3 nodes that seem to be broken since ages due to a copy-and-paste error. Signed-off-by: Sebastian Hesselbarth Acked-by: Gregory CLEMENT Signed-off-by: Gregory CLEMENT Signed-off-by: Jiri Slaby commit 5d17335bfad0bb10d6c25eb0b1a25ca518acc185 Author: Charles Keepax Date: Fri Mar 27 01:58:08 2015 +0900 ARM: S3C64XX: Use fixed IRQ bases to avoid conflicts on Cragganmore commit 4e330ae4ab2915444f1e6dca1358a910aa259362 upstream. There are two PMICs on Cragganmore, currently one dynamically assign its IRQ base and the other uses a fixed base. It is possible for the statically assigned PMIC to fail if its IRQ is taken by the dynamically assigned one. Fix this by statically assigning both the IRQ bases. Signed-off-by: Charles Keepax Signed-off-by: Kukjin Kim Signed-off-by: Jiri Slaby commit 2eca31203f6253e3afe68f8a30aaf1b70c815adb Author: Andrey Ryabinin Date: Fri Mar 20 15:42:27 2015 +0100 ARM: 8320/1: fix integer overflow in ELF_ET_DYN_BASE commit 8defb3367fcd19d1af64c07792aade0747b54e0f upstream. Usually ELF_ET_DYN_BASE is 2/3 of TASK_SIZE. With 3G/1G user/kernel split this is not so, because 2*TASK_SIZE overflows 32 bits, so the actual value of ELF_ET_DYN_BASE is: (2 * TASK_SIZE / 3) = 0x2a000000 When ASLR is disabled PIE binaries will load at ELF_ET_DYN_BASE address. On 32bit platforms AddressSanitzer uses addresses [0x20000000 - 0x40000000] for shadow memory [1]. So ASan doesn't work for PIE binaries when ASLR disabled as it fails to map shadow memory. Also after Kees's 'split ET_DYN ASLR from mmap ASLR' patchset PIE binaries has a high chance of loading somewhere in between [0x2a000000 - 0x40000000] even if ASLR enabled. This makes ASan with PIE absolutely incompatible. Fix overflow by dividing TASK_SIZE prior to multiplying. After this patch ELF_ET_DYN_BASE equals to (for CONFIG_VMSPLIT_3G=y): (TASK_SIZE / 3 * 2) = 0x7f555554 [1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerAlgorithm#Mapping Signed-off-by: Andrey Ryabinin Reported-by: Maria Guseva Signed-off-by: Russell King Signed-off-by: Jiri Slaby commit 3ac895c7731a6c2fbe097609491451cb97b360d9 Author: Krzysztof Kozlowski Date: Fri Feb 20 14:32:25 2015 +0100 power_supply: lp8788-charger: Fix leaked power supply on probe fail commit a7117f81e8391e035c49b3440792f7e6cea28173 upstream. Driver forgot to unregister charger power supply if registering of battery supply failed in probe(). In such case the memory associated with power supply leaked. Signed-off-by: Krzysztof Kozlowski Fixes: 98a276649358 ("power_supply: Add new lp8788 charger driver") Signed-off-by: Sebastian Reichel Signed-off-by: Jiri Slaby commit 1c36ba3f9ef3d3317693dfcead7c3d989b3801bb Author: Krzysztof Kozlowski Date: Fri Feb 20 14:32:22 2015 +0100 power_supply: twl4030_madc: Check return value of power_supply_register commit 68c3ed6fa7e0d69529ced772d650ab128916a81d upstream. The return value of power_supply_register() call was not checked and even on error probe() function returned 0. If registering failed then during unbind the driver tried to unregister power supply which was not actually registered. This could lead to memory corruption because power_supply_unregister() unconditionally cleans up given power supply. Signed-off-by: Krzysztof Kozlowski Fixes: da0a00ebc239 ("power: Add twl4030_madc battery driver.") Signed-off-by: Sebastian Reichel Signed-off-by: Jiri Slaby commit f29084250e0361de2a572a9d27373980fda59eb2 Author: Steven Rostedt Date: Tue Mar 17 10:40:38 2015 -0400 ring-buffer: Replace this_cpu_*() with __this_cpu_*() commit 80a9b64e2c156b6523e7a01f2ba6e5d86e722814 upstream. It has come to my attention that this_cpu_read/write are horrible on architectures other than x86. Worse yet, they actually disable preemption or interrupts! This caused some unexpected tracing results on ARM. 101.356868: preempt_count_add <-ring_buffer_lock_reserve 101.356870: preempt_count_sub <-ring_buffer_lock_reserve The ring_buffer_lock_reserve has recursion protection that requires accessing a per cpu variable. But since preempt_disable() is traced, it too got traced while accessing the variable that is suppose to prevent recursion like this. The generic version of this_cpu_read() and write() are: #define this_cpu_generic_read(pcp) \ ({ typeof(pcp) ret__; \ preempt_disable(); \ ret__ = *this_cpu_ptr(&(pcp)); \ preempt_enable(); \ ret__; \ }) #define this_cpu_generic_to_op(pcp, val, op) \ do { \ unsigned long flags; \ raw_local_irq_save(flags); \ *__this_cpu_ptr(&(pcp)) op val; \ raw_local_irq_restore(flags); \ } while (0) Which is unacceptable for locations that know they are within preempt disabled or interrupt disabled locations. Paul McKenney stated that __this_cpu_() versions produce much better code on other architectures than this_cpu_() does, if we know that the call is done in a preempt disabled location. I also changed the recursive_unlock() to use two local variables instead of accessing the per_cpu variable twice. Link: http://lkml.kernel.org/r/20150317114411.GE3589@linux.vnet.ibm.com Link: http://lkml.kernel.org/r/20150317104038.312e73d1@gandalf.local.home Acked-by: Christoph Lameter Reported-by: Uwe Kleine-Koenig Tested-by: Uwe Kleine-Koenig Signed-off-by: Steven Rostedt Signed-off-by: Jiri Slaby commit 15b684c9fb5012c63f46bc9a1523c8ad8b786a50 Author: Krzysztof Kozlowski Date: Thu Mar 12 08:44:00 2015 +0100 compal-laptop: Check return value of power_supply_register commit 1915a718b1872edffcb13e5436a9f7302d3d36f0 upstream. The return value of power_supply_register() call was not checked and even on error probe() function returned 0. If registering failed then during unbind the driver tried to unregister power supply which was not actually registered. This could lead to memory corruption because power_supply_unregister() unconditionally cleans up given power supply. Fix this by checking return status of power_supply_register() call. In case of failure, clean up sysfs entries and fail the probe. Signed-off-by: Krzysztof Kozlowski Fixes: 9be0fcb5ed46 ("compal-laptop: add JHL90, battery & hwmon interface") Signed-off-by: Sebastian Reichel Signed-off-by: Jiri Slaby [backport to 3.12] commit 1467541ff04b7e4d6f91bc7fe5b447499a53d840 Author: Ian Abbott Date: Mon Mar 23 17:50:27 2015 +0000 spi: spidev: fix possible arithmetic overflow for multi-transfer message commit f20fbaad7620af2df36a1f9d1c9ecf48ead5b747 upstream. `spidev_message()` sums the lengths of the individual SPI transfers to determine the overall SPI message length. It restricts the total length, returning an error if too long, but it does not check for arithmetic overflow. For example, if the SPI message consisted of two transfers and the first has a length of 10 and the second has a length of (__u32)(-1), the total length would be seen as 9, even though the second transfer is actually very long. If the second transfer specifies a null `rx_buf` and a non-null `tx_buf`, the `copy_from_user()` could overrun the spidev's pre-allocated tx buffer before it reaches an invalid user memory address. Fix it by checking that neither the total nor the individual transfer lengths exceed the maximum allowed value. Thanks to Dan Carpenter for reporting the potential integer overflow. Signed-off-by: Ian Abbott Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit b2f5406a39fcfe3701709032bd7e27a2a859ce4d Author: Oliver Neukum Date: Fri Mar 20 14:29:34 2015 +0100 cdc-wdm: fix endianness bug in debug statements commit 323ece54e0761198946ecd0c2091f1d2bfdfcb64 upstream. Values directly from descriptors given in debug statements must be converted to native endianness. Signed-off-by: Oliver Neukum Signed-off-by: Jiri Slaby commit a8ecee7fe315aa06a3b0a95f613aa58400e9c092 Author: Huacai Chen Date: Sun Mar 29 10:54:05 2015 +0800 MIPS: Hibernate: flush TLB entries earlier commit a843d00d038b11267279e3b5388222320f9ddc1d upstream. We found that TLB mismatch not only happens after kernel resume, but also happens during snapshot restore. So move it to the beginning of swsusp_arch_suspend(). Signed-off-by: Huacai Chen Cc: Steven J. Hill Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang Cc: Zhangjin Wu Patchwork: https://patchwork.linux-mips.org/patch/9621/ Signed-off-by: Ralf Baechle Signed-off-by: Jiri Slaby commit e6e75e2f847b44e75fee58705ebc01d9567eaaf5 Author: Radim Krčmář Date: Wed Apr 8 14:16:48 2015 +0200 KVM: use slowpath for cross page cached accesses commit ca3f0874723fad81d0c701b63ae3a17a408d5f25 upstream. kvm_write_guest_cached() does not mark all written pages as dirty and code comments in kvm_gfn_to_hva_cache_init() talk about NULL memslot with cross page accesses. Fix all the easy way. The check is '<= 1' to have the same result for 'len = 0' cache anywhere in the page. (nr_pages_needed is 0 on page boundary.) Fixes: 8f964525a121 ("KVM: Allow cross page reads and writes from cached translations.") Signed-off-by: Radim Krčmář Message-Id: <20150408121648.GA3519@potion.brq.redhat.com> Reviewed-by: Wanpeng Li Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit 5239870c49b38d03341ea090e288587d5680cd63 Author: Heiko Carstens Date: Wed Mar 25 10:13:33 2015 +0100 s390/hibernate: fix save and restore of kernel text section commit d74419495633493c9cd3f2bbeb7f3529d0edded6 upstream. Sebastian reported a crash caused by a jump label mismatch after resume. This happens because we do not save the kernel text section during suspend and therefore also do not restore it during resume, but use the kernel image that restores the old system. This means that after a suspend/resume cycle we lost all modifications done to the kernel text section. The reason for this is the pfn_is_nosave() function, which incorrectly returns that read-only pages don't need to be saved. This is incorrect since we mark the kernel text section read-only. We still need to make sure to not save and restore pages contained within NSS and DCSS segment. To fix this add an extra case for the kernel text section and only save those pages if they are not contained within an NSS segment. Fixes the following crash (and the above bugs as well): Jump label code mismatch at netif_receive_skb_internal+0x28/0xd0 Found: c0 04 00 00 00 00 Expected: c0 f4 00 00 00 11 New: c0 04 00 00 00 00 Kernel panic - not syncing: Corrupted kernel text CPU: 0 PID: 9 Comm: migration/0 Not tainted 3.19.0-01975-gb1b096e70f23 #4 Call Trace: [<0000000000113972>] show_stack+0x72/0xf0 [<000000000081f15e>] dump_stack+0x6e/0x90 [<000000000081c4e8>] panic+0x108/0x2b0 [<000000000081be64>] jump_label_bug.isra.2+0x104/0x108 [<0000000000112176>] __jump_label_transform+0x9e/0xd0 [<00000000001121e6>] __sm_arch_jump_label_transform+0x3e/0x50 [<00000000001d1136>] multi_cpu_stop+0x12e/0x170 [<00000000001d1472>] cpu_stopper_thread+0xb2/0x168 [<000000000015d2ac>] smpboot_thread_fn+0x134/0x1b0 [<0000000000158baa>] kthread+0x10a/0x110 [<0000000000824a86>] kernel_thread_starter+0x6/0xc Reported-and-tested-by: Sebastian Ott Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Jiri Slaby commit 6d56cb94f4eadd3f336e34a1da7be9e9e987f0b0 Author: Ekaterina Tumanova Date: Tue Mar 3 09:54:41 2015 +0100 KVM: s390: Zero out current VMDB of STSI before including level3 data. commit b75f4c9afac2604feb971441116c07a24ecca1ec upstream. s390 documentation requires words 0 and 10-15 to be reserved and stored as zeros. As we fill out all other fields, we can memset the full structure. Signed-off-by: Ekaterina Tumanova Reviewed-by: David Hildenbrand Signed-off-by: Christian Borntraeger Signed-off-by: Jiri Slaby commit f2efcbce549440344368ee59910b698d039852b5 Author: Geert Uytterhoeven Date: Thu Oct 9 15:30:30 2014 -0700 nosave: consolidate __nosave_{begin,end} in commit 7f8998c7aef3ac9c5f3f2943e083dfa6302e90d0 upstream. The different architectures used their own (and different) declarations: extern __visible const void __nosave_begin, __nosave_end; extern const void __nosave_begin, __nosave_end; extern long __nosave_begin, __nosave_end; Consolidate them using the first variant in . Signed-off-by: Geert Uytterhoeven Cc: Russell King Cc: Ralf Baechle Cc: Benjamin Herrenschmidt Cc: Martin Schwidefsky Cc: "David S. Miller" Cc: Guan Xuetao Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby [js -- port to 3.12: arm does not have hibernation yet] commit a97ae729d53d2ea4f1ef80ea75d0802a637559de Author: Felipe Balbi Date: Tue Sep 30 16:08:03 2014 -0500 usb: gadget: composite: enable BESL support commit a6615937bcd9234e6d6bb817c3701fce44d0a84d upstream. According to USB 2.0 ECN Errata for Link Power Management (USB2-LPM-Errata-final.pdf), BESL must be enabled if LPM is enabled. This helps with USB30CV TD 9.21 LPM L1 Suspend Resume Test. Signed-off-by: Felipe Balbi Signed-off-by: Du, Changbin Signed-off-by: Jiri Slaby commit 647385a0a32db8bf075b1c6d03b01d0c24d55c91 Author: Guenter Roeck Date: Wed Apr 22 22:23:54 2015 -0700 drivers: parport: Kconfig: exclude arm64 for PARPORT_PC Fix build problem seen with arm64:allmodconfig. drivers/parport/parport_pc.c:67:25: fatal error: asm/parport.h: No such file or directory arm64 does not support PARPORT_PC. Signed-off-by: Guenter Roeck Signed-off-by: Jiri Slaby commit 43ee6fcfbe5d2bc68fee874e411acf17e1adc33f Author: Gerald Schaefer Date: Tue Apr 14 15:42:30 2015 -0700 mm/hugetlb: use pmd_page() in follow_huge_pmd() commit 97534127012f0e396eddea4691f4c9b170aed74b upstream. Commit 61f77eda9bbf ("mm/hugetlb: reduce arch dependent code around follow_huge_*") broke follow_huge_pmd() on s390, where pmd and pte layout differ and using pte_page() on a huge pmd will return wrong results. Using pmd_page() instead fixes this. All architectures that were touched by that commit have pmd_page() defined, so this should not break anything on other architectures. Fixes: 61f77eda "mm/hugetlb: reduce arch dependent code around follow_huge_*" Signed-off-by: Gerald Schaefer Acked-by: Naoya Horiguchi Cc: Hugh Dickins Cc: Michal Hocko , Andrea Arcangeli Cc: Martin Schwidefsky Acked-by: David Rientjes Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 257ccf0a22d82dd694bc77d8b8fd151f724d6856 Author: Len Brown Date: Wed Jan 15 00:37:34 2014 -0500 sched/idle/x86: Restore mwait_idle() to fix boot hangs, to improve power savings and to improve performance commit b253149b843f89cd300cbdbea27ce1f847506f99 upstream. In Linux-3.9 we removed the mwait_idle() loop: 69fb3676df33 ("x86 idle: remove mwait_idle() and "idle=mwait" cmdline param") The reasoning was that modern machines should be sufficiently happy during the boot process using the default_idle() HALT loop, until cpuidle loads and either acpi_idle or intel_idle invoke the newer MWAIT-with-hints idle loop. But two machines reported problems: 1. Certain Core2-era machines support MWAIT-C1 and HALT only. MWAIT-C1 is preferred for optimal power and performance. But if they support just C1, cpuidle never loads and so they use the boot-time default idle loop forever. 2. Some laptops will boot-hang if HALT is used, but will boot successfully if MWAIT is used. This appears to be a hidden assumption in BIOS SMI, that is presumably valid on the proprietary OS where the BIOS was validated. https://bugzilla.kernel.org/show_bug.cgi?id=60770 So here we effectively revert the patch above, restoring the mwait_idle() loop. However, we don't bother restoring the idle=mwait cmdline parameter, since it appears to add no value. Maintainer notes: For 3.9, simply revert 69fb3676df for 3.10, patch -F3 applies, fuzz needed due to __cpuinit use in context For 3.11, 3.12, 3.13, this patch applies cleanly Tested-by: Mike Galbraith Signed-off-by: Len Brown Acked-by: Mike Galbraith Cc: # 3.9+ Cc: Borislav Petkov Cc: H. Peter Anvin Cc: Ian Malone Cc: Josh Boyer Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/345254a551eb5a6a866e048d7ab570fd2193aca4.1389763084.git.len.brown@intel.com [ Ported to recent kernels. ] [ Mike: 3.10 backport ] Signed-off-by: Ingo Molnar Signed-off-by: Mike Galbraith Signed-off-by: Jiri Slaby commit 2034243f2206a67bce7aa204043d8d2dae57f5d0 Author: Filipe Manana Date: Mon Mar 30 18:26:47 2015 +0100 Btrfs: fix inode eviction infinite loop after extent_same ioctl commit 113e8283869b9855c8b999796aadd506bbac155f upstream. If we pass a length of 0 to the extent_same ioctl, we end up locking an extent range with a start offset greater then its end offset (if the destination file's offset is greater than zero). This results in a warning from extent_io.c:insert_state through the following call chain: btrfs_extent_same() btrfs_double_lock() lock_extent_range() lock_extent(inode->io_tree, offset, offset + len - 1) lock_extent_bits() __set_extent_bit() insert_state() --> WARN_ON(end < start) This leads to an infinite loop when evicting the inode. This is the same problem that my previous patch titled "Btrfs: fix inode eviction infinite loop after cloning into it" addressed but for the extent_same ioctl instead of the clone ioctl. Signed-off-by: Filipe Manana Reviewed-by: Omar Sandoval Signed-off-by: Chris Mason Signed-off-by: Jiri Slaby commit 4ab0f403b8dad3d804ac5550bcf499bbd318b069 Author: Filipe Manana Date: Mon Mar 30 18:23:59 2015 +0100 Btrfs: fix inode eviction infinite loop after cloning into it commit ccccf3d67294714af2d72a6fd6fd7d73b01c9329 upstream. If we attempt to clone a 0 length region into a file we can end up inserting a range in the inode's extent_io tree with a start offset that is greater then the end offset, which triggers immediately the following warning: [ 3914.619057] WARNING: CPU: 17 PID: 4199 at fs/btrfs/extent_io.c:435 insert_state+0x4b/0x10b [btrfs]() [ 3914.620886] BTRFS: end < start 4095 4096 (...) [ 3914.638093] Call Trace: [ 3914.638636] [] dump_stack+0x4c/0x65 [ 3914.639620] [] warn_slowpath_common+0xa1/0xbb [ 3914.640789] [] ? insert_state+0x4b/0x10b [btrfs] [ 3914.642041] [] warn_slowpath_fmt+0x46/0x48 [ 3914.643236] [] insert_state+0x4b/0x10b [btrfs] [ 3914.644441] [] __set_extent_bit+0x107/0x3f4 [btrfs] [ 3914.645711] [] lock_extent_bits+0x65/0x1bf [btrfs] [ 3914.646914] [] ? _raw_spin_unlock+0x28/0x33 [ 3914.648058] [] ? test_range_bit+0xcc/0xde [btrfs] [ 3914.650105] [] lock_extent+0x13/0x15 [btrfs] [ 3914.651361] [] lock_extent_range+0x3d/0xcd [btrfs] [ 3914.652761] [] btrfs_ioctl_clone+0x278/0x388 [btrfs] [ 3914.654128] [] ? might_fault+0x58/0xb5 [ 3914.655320] [] btrfs_ioctl+0xb51/0x2195 [btrfs] (...) [ 3914.669271] ---[ end trace 14843d3e2e622fc1 ]--- This later makes the inode eviction handler enter an infinite loop that keeps dumping the following warning over and over: [ 3915.117629] WARNING: CPU: 22 PID: 4228 at fs/btrfs/extent_io.c:435 insert_state+0x4b/0x10b [btrfs]() [ 3915.119913] BTRFS: end < start 4095 4096 (...) [ 3915.137394] Call Trace: [ 3915.137913] [] dump_stack+0x4c/0x65 [ 3915.139154] [] warn_slowpath_common+0xa1/0xbb [ 3915.140316] [] ? insert_state+0x4b/0x10b [btrfs] [ 3915.141505] [] warn_slowpath_fmt+0x46/0x48 [ 3915.142709] [] insert_state+0x4b/0x10b [btrfs] [ 3915.143849] [] __set_extent_bit+0x107/0x3f4 [btrfs] [ 3915.145120] [] ? btrfs_kill_super+0x17/0x23 [btrfs] [ 3915.146352] [] ? deactivate_locked_super+0x3b/0x50 [ 3915.147565] [] lock_extent_bits+0x65/0x1bf [btrfs] [ 3915.148785] [] ? _raw_write_unlock+0x28/0x33 [ 3915.149931] [] btrfs_evict_inode+0x196/0x482 [btrfs] [ 3915.151154] [] evict+0xa0/0x148 [ 3915.152094] [] dispose_list+0x39/0x43 [ 3915.153081] [] evict_inodes+0xdc/0xeb [ 3915.154062] [] generic_shutdown_super+0x49/0xef [ 3915.155193] [] kill_anon_super+0x13/0x1e [ 3915.156274] [] btrfs_kill_super+0x17/0x23 [btrfs] (...) [ 3915.167404] ---[ end trace 14843d3e2e622fc2 ]--- So just bail out of the clone ioctl if the length of the region to clone is zero, without locking any extent range, in order to prevent this issue (same behaviour as a pwrite with a 0 length for example). This is trivial to reproduce. For example, the steps for the test I just made for fstests: mkfs.btrfs -f SCRATCH_DEV mount SCRATCH_DEV $SCRATCH_MNT touch $SCRATCH_MNT/foo touch $SCRATCH_MNT/bar $CLONER_PROG -s 0 -d 4096 -l 0 $SCRATCH_MNT/foo $SCRATCH_MNT/bar umount $SCRATCH_MNT A test case for fstests follows soon. Signed-off-by: Filipe Manana Reviewed-by: Omar Sandoval Signed-off-by: Chris Mason Signed-off-by: Jiri Slaby commit a60903bf3633bdfd1254b1766ac51d56439c650e Author: David Sterba Date: Wed Mar 25 19:26:41 2015 +0100 btrfs: don't accept bare namespace as a valid xattr commit 3c3b04d10ff1811a27f86684ccd2f5ba6983211d upstream. Due to insufficient check in btrfs_is_valid_xattr, this unexpectedly works: $ touch file $ setfattr -n user. -v 1 file $ getfattr -d file user.="1" ie. the missing attribute name after the namespace. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94291 Reported-by: William Douglas Signed-off-by: David Sterba Signed-off-by: Chris Mason Signed-off-by: Jiri Slaby commit fb5aac18ca6221679f3e88f680f6992dacd4016c Author: Filipe Manana Date: Mon Mar 23 14:07:40 2015 +0000 Btrfs: fix log tree corruption when fs mounted with -o discard commit dcc82f4783ad91d4ab654f89f37ae9291cdc846a upstream. While committing a transaction we free the log roots before we write the new super block. Freeing the log roots implies marking the disk location of every node/leaf (metadata extent) as pinned before the new super block is written. This is to prevent the disk location of log metadata extents from being reused before the new super block is written, otherwise we would have a corrupted log tree if before the new super block is written a crash/reboot happens and the location of any log tree metadata extent ended up being reused and rewritten. Even though we pinned the log tree's metadata extents, we were issuing a discard against them if the fs was mounted with the -o discard option, resulting in corruption of the log tree if a crash/reboot happened before writing the new super block - the next time the fs was mounted, during the log replay process we would find nodes/leafs of the log btree with a content full of zeroes, causing the process to fail and require the use of the tool btrfs-zero-log to wipeout the log tree (and all data previously fsynced becoming lost forever). Fix this by not doing a discard when pinning an extent. The discard will be done later when it's safe (after the new super block is committed) at extent-tree.c:btrfs_finish_extent_commit(). Fixes: e688b7252f78 (Btrfs: fix extent pinning bugs in the tree log) Signed-off-by: Filipe Manana Signed-off-by: Chris Mason Signed-off-by: Jiri Slaby commit f555cb3a3fc94b6d71685d4e032e0adedaf23239 Author: Eric Dumazet Date: Fri Apr 24 16:05:01 2015 -0700 net: fix crash in build_skb() [ Upstream commit 2ea2f62c8bda242433809c7f4e9eae1c52c40bbe ] When I added pfmemalloc support in build_skb(), I forgot netlink was using build_skb() with a vmalloc() area. In this patch I introduce __build_skb() for netlink use, and build_skb() is a wrapper handling both skb->head_frag and skb->pfmemalloc This means netlink no longer has to hack skb->head_frag [ 1567.700067] kernel BUG at arch/x86/mm/physaddr.c:26! [ 1567.700067] invalid opcode: 0000 [#1] PREEMPT SMP KASAN [ 1567.700067] Dumping ftrace buffer: [ 1567.700067] (ftrace buffer empty) [ 1567.700067] Modules linked in: [ 1567.700067] CPU: 9 PID: 16186 Comm: trinity-c182 Not tainted 4.0.0-next-20150424-sasha-00037-g4796e21 #2167 [ 1567.700067] task: ffff880127efb000 ti: ffff880246770000 task.ti: ffff880246770000 [ 1567.700067] RIP: __phys_addr (arch/x86/mm/physaddr.c:26 (discriminator 3)) [ 1567.700067] RSP: 0018:ffff8802467779d8 EFLAGS: 00010202 [ 1567.700067] RAX: 000041000ed8e000 RBX: ffffc9008ed8e000 RCX: 000000000000002c [ 1567.700067] RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffffffffb3fd6049 [ 1567.700067] RBP: ffff8802467779f8 R08: 0000000000000019 R09: ffff8801d0168000 [ 1567.700067] R10: ffff8801d01680c7 R11: ffffed003a02d019 R12: ffffc9000ed8e000 [ 1567.700067] R13: 0000000000000f40 R14: 0000000000001180 R15: ffffc9000ed8e000 [ 1567.700067] FS: 00007f2a7da3f700(0000) GS:ffff8801d1000000(0000) knlGS:0000000000000000 [ 1567.700067] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1567.700067] CR2: 0000000000738308 CR3: 000000022e329000 CR4: 00000000000007e0 [ 1567.700067] Stack: [ 1567.700067] ffffc9000ed8e000 ffff8801d0168000 ffffc9000ed8e000 ffff8801d0168000 [ 1567.700067] ffff880246777a28 ffffffffad7c0a21 0000000000001080 ffff880246777c08 [ 1567.700067] ffff88060d302e68 ffff880246777b58 ffff880246777b88 ffffffffad9a6821 [ 1567.700067] Call Trace: [ 1567.700067] build_skb (include/linux/mm.h:508 net/core/skbuff.c:316) [ 1567.700067] netlink_sendmsg (net/netlink/af_netlink.c:1633 net/netlink/af_netlink.c:2329) [ 1567.774369] ? sched_clock_cpu (kernel/sched/clock.c:311) [ 1567.774369] ? netlink_unicast (net/netlink/af_netlink.c:2273) [ 1567.774369] ? netlink_unicast (net/netlink/af_netlink.c:2273) [ 1567.774369] sock_sendmsg (net/socket.c:614 net/socket.c:623) [ 1567.774369] sock_write_iter (net/socket.c:823) [ 1567.774369] ? sock_sendmsg (net/socket.c:806) [ 1567.774369] __vfs_write (fs/read_write.c:479 fs/read_write.c:491) [ 1567.774369] ? get_lock_stats (kernel/locking/lockdep.c:249) [ 1567.774369] ? default_llseek (fs/read_write.c:487) [ 1567.774369] ? vtime_account_user (kernel/sched/cputime.c:701) [ 1567.774369] ? rw_verify_area (fs/read_write.c:406 (discriminator 4)) [ 1567.774369] vfs_write (fs/read_write.c:539) [ 1567.774369] SyS_write (fs/read_write.c:586 fs/read_write.c:577) [ 1567.774369] ? SyS_read (fs/read_write.c:577) [ 1567.774369] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63) [ 1567.774369] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2594 kernel/locking/lockdep.c:2636) [ 1567.774369] ? trace_hardirqs_on_thunk (arch/x86/lib/thunk_64.S:42) [ 1567.774369] system_call_fastpath (arch/x86/kernel/entry_64.S:261) Fixes: 79930f5892e ("net: do not deplete pfmemalloc reserve") Signed-off-by: Eric Dumazet Reported-by: Sasha Levin Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit bdcfb6f23733c64c4514ae0820899a7866700659 Author: Eric Dumazet Date: Wed Apr 22 07:33:36 2015 -0700 net: do not deplete pfmemalloc reserve [ Upstream commit 79930f5892e134c6da1254389577fffb8bd72c66 ] build_skb() should look at the page pfmemalloc status. If set, this means page allocator allocated this page in the expectation it would help to free other pages. Networking stack can do that only if skb->pfmemalloc is also set. Also, we must refrain using high order pages from the pfmemalloc reserve, so __page_frag_refill() must also use __GFP_NOMEMALLOC for them. Under memory pressure, using order-0 pages is probably the best strategy. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 90a176dc03dc495e17a34edb12bade9ce481d238 Author: Eric Dumazet Date: Thu Apr 23 10:42:39 2015 -0700 tcp: avoid looping in tcp_send_fin() [ Upstream commit 845704a535e9b3c76448f52af1b70e4422ea03fd ] Presence of an unbound loop in tcp_send_fin() had always been hard to explain when analyzing crash dumps involving gigantic dying processes with millions of sockets. Lets try a different strategy : In case of memory pressure, try to add the FIN flag to last packet in write queue, even if packet was already sent. TCP stack will be able to deliver this FIN after a timeout event. Note that this FIN being delivered by a retransmit, it also carries a Push flag given our current implementation. By checking sk_under_memory_pressure(), we anticipate that cooking many FIN packets might deplete tcp memory. In the case we could not allocate a packet, even with __GFP_WAIT allocation, then not sending a FIN seems quite reasonable if it allows to get rid of this socket, free memory, and not block the process from eventually doing other useful work. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 3644030ff70814406747455e2997cb5d000a8bf7 Author: Eric Dumazet Date: Tue Apr 21 18:32:24 2015 -0700 tcp: fix possible deadlock in tcp_send_fin() [ Upstream commit d83769a580f1132ac26439f50068a29b02be535e ] Using sk_stream_alloc_skb() in tcp_send_fin() is dangerous in case a huge process is killed by OOM, and tcp_mem[2] is hit. To be able to free memory we need to make progress, so this patch allows FIN packets to not care about tcp_mem[2], if skb allocation succeeded. In a follow-up patch, we might abort tcp_send_fin() infinite loop in case TIF_MEMDIE is set on this thread, as memory allocator did its best getting extra memory already. This patch reverts d22e15371811 ("tcp: fix tcp fin memory accounting") Fixes: d22e15371811 ("tcp: fix tcp fin memory accounting") Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 70c3d4ae1322b9e9bd7443ef574af5635234a0fa Author: Sebastian Pöhn Date: Mon Apr 20 09:19:20 2015 +0200 ip_forward: Drop frames with attached skb->sk [ Upstream commit 2ab957492d13bb819400ac29ae55911d50a82a13 ] Initial discussion was: [FYI] xfrm: Don't lookup sk_policy for timewait sockets Forwarded frames should not have a socket attached. Especially tw sockets will lead to panics later-on in the stack. This was observed with TPROXY assigning a tw socket and broken policy routing (misconfigured). As a result frame enters forwarding path instead of input. We cannot solve this in TPROXY as it cannot know that policy routing is broken. v2: Remove useless comment Signed-off-by: Sebastian Poehn Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby