commit 51af817611f2c0987030d024f24fc7ea95dd33e6 Author: Sasha Levin Date: Wed May 20 11:04:50 2015 -0400 Linux 3.18.14 Signed-off-by: Sasha Levin commit 199637437af24dc075a57dcb05bf8878fdf9d731 Author: K. Y. Srinivasan Date: Thu Mar 19 08:11:34 2015 -0700 Drivers: hv: vmbus: Don't wait after requesting offers [ Upstream commit 73cffdb65e679b98893f484063462c045adcf212 ] 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: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0aea21ec8f303b280dc8d28bdbd729e8cf6a7ebd Author: Thomas Hebb Date: Thu Apr 16 12:47:18 2015 -0700 hfsplus: don't store special "osx" xattr prefix on-disk [ Upstream commit db579e76f06e78de011b2cb7e028740a82f5558c ] On Mac OS X, HFS+ extended attributes are not namespaced. Since we want to be compatible with OS X filesystems and yet still support the Linux namespacing system, the hfsplus driver implements a special "osx" namespace that is reported for any attribute that is not namespaced on-disk. However, the current code for getting and setting these unprefixed attributes is broken. hfsplus_osx_setattr() and hfsplus_osx_getattr() are passed names that have already had their "osx." prefixes stripped by the generic functions. The functions first, quite correctly, check those names to make sure that they aren't prefixed with a known namespace, which would allow namespace access restrictions to be bypassed. However, the functions then prepend "osx." to the name they're given before passing it on to hfsplus_getattr() and hfsplus_setattr(). Not only does this cause the "osx." prefix to be stored on-disk, defeating its purpose, it also breaks the check for the special "com.apple.FinderInfo" attribute, which is reported for all files, and as a consequence makes some userspace applications (e.g. GNU patch) fail even when extended attributes are not otherwise in use. There are five commits which have touched this particular code: 127e5f5ae51e ("hfsplus: rework functionality of getting, setting and deleting of extended attributes") b168fff72109 ("hfsplus: use xattr handlers for removexattr") bf29e886b242 ("hfsplus: correct usage of HFSPLUS_ATTR_MAX_STRLEN for non-English attributes") fcacbd95e121 ("fs/hfsplus: move xattr_name allocation in hfsplus_getxattr()") ec1bbd346f18 ("fs/hfsplus: move xattr_name allocation in hfsplus_setxattr()") The first commit creates the functions to begin with. The namespace is prepended by the original code, which I believe was correct at the time, since hfsplus_?etattr() stripped the prefix if found. The second commit removes this behavior from hfsplus_?etattr() and appears to have been intended to also remove the prefixing from hfsplus_osx_?etattr(). However, what it actually does is remove a necessary strncpy() call completely, breaking the osx namespace entirely. The third commit re-adds the strncpy() call as it was originally, but doesn't mention it in its commit message. The final two commits refactor the code and don't affect its functionality. This commit does what b168fff attempted to do (prevent the prefix from being added), but does it properly, instead of passing in an empty buffer (which is what b168fff actually did). Fixes: b168fff72109 ("hfsplus: use xattr handlers for removexattr") Signed-off-by: Thomas Hebb Cc: Hin-Tak Leung Cc: Sergei Antonov Cc: Anton Altaparmakov Cc: Fabian Frederick Cc: Christian Kujau Cc: Christoph Hellwig Cc: Al Viro Cc: Viacheslav Dubeyko Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit be5288ba7826227d07a67e87d5a1136bce851e84 Author: Christian König Date: Mon Apr 27 17:04:36 2015 +0200 drm/radeon: check new address before removing old one [ Upstream commit c29c0876ec05d51a93508a39b90b92c29ba6423d ] Otherwise the change isn't atomic. Signed-off-by: Christian König CC: stable@vger.kernel.org Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2fb826015925351a899c678d3117014361d9a72b 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 [ Upstream commit cd17e02ff4db58ec32d35cf331c705d295779930 ] Seems to have problems with high mclks. bug: https://bugs.freedesktop.org/show_bug.cgi?id=76490 Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 572a8eae2a3ecef257da83e511528c58271d2031 Author: Alex Deucher Date: Sun Apr 19 12:01:00 2015 -0400 drm/radeon: adjust pll when audio is not enabled [ Upstream commit 7fe04d6fa824ccea704535a597dc417c8687f990 ] Fixes display problems with some monitors when audio is not enabled. Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=89505 https://bugzilla.kernel.org/show_bug.cgi?id=94171 Plus several reports on IRC. Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 742b16a2694dbb9a218306e72579a0174698ce96 Author: Christoph Hellwig Date: Thu Apr 23 09:48:49 2015 +0200 3w-sas: fix command completion race [ Upstream commit 579d69bc1fd56d5af5761969aa529d1d1c188300 ] 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 Cc: stable@vger.kernel.org Acked-by: Adam Radford Signed-off-by: James Bottomley Signed-off-by: Sasha Levin commit d722b89103fe12fb683d52dd394315cd175d7cbd Author: Christoph Hellwig Date: Thu Apr 23 09:48:51 2015 +0200 3w-9xxx: fix command completion race [ Upstream commit 118c855b5623f3e2e6204f02623d88c09e0c34de ] 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 Cc: stable@vger.kernel.org Acked-by: Adam Radford Signed-off-by: James Bottomley Signed-off-by: Sasha Levin commit c0abe5a7b642a140c90211fc68eaa4f84adc9603 Author: Christoph Hellwig Date: Thu Apr 23 09:48:50 2015 +0200 3w-xxxx: fix command completion race [ Upstream commit 9cd9554615cba14f0877cc9972a6537ad2bdde61 ] 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 Cc: stable@vger.kernel.org Acked-by: Adam Radford Signed-off-by: James Bottomley Signed-off-by: Sasha Levin commit e5975e422e51281bcaea4c98f954a70916f58906 Author: Davide Italiano Date: Sat May 2 23:21:15 2015 -0400 ext4: move check under lock scope to close a race. [ Upstream commit 280227a75b56ab5d35854f3a77ef74a7ad56a203 ] fallocate() checks that the file is extent-based and returns EOPNOTSUPP in case is not. Other tasks can convert from and to indirect and extent so it's safe to check only after grabbing the inode mutex. Signed-off-by: Davide Italiano Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 826e9b94ce8cd724866d6fc86d614db97730abcf Author: Lukas Czerner Date: Sat May 2 21:36:55 2015 -0400 ext4: fix data corruption caused by unwritten and delayed extents [ Upstream commit d2dc317d564a46dfc683978a2e5a4f91434e9711 ] 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 Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit d3dc2e86f7f760b15d0cc3207e99c2d8a63e4740 Author: Hans de Goede Date: Tue Apr 21 11:20:32 2015 +0200 uas: Set max_sectors_240 quirk for ASM1053 devices [ Upstream commit 8e779c6c4a398763c21371fe40f649206041dc1e ] Testing has shown that ASM1053 devices do not work properly with transfers larger than 240 sectors, so set max_sectors to 240 on these. Cc: stable@vger.kernel.org # 3.16 Reported-by: Steve Bangert Signed-off-by: Hans de Goede Tested-by: Steve Bangert Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f6283d7d0c92f3b1d8b7eb68ffa3b6deee1798de Author: Hans de Goede Date: Tue Apr 21 11:20:31 2015 +0200 uas: Add US_FL_MAX_SECTORS_240 flag [ Upstream commit ee136af4a064c2f61e2025873584d2c7ec93f4ae ] The usb-storage driver sets max_sectors = 240 in its scsi-host template, for uas we do not want to do that for all devices, but testing has shown that some devices need it. This commit adds a US_FL_MAX_SECTORS_240 flag for such devices, and implements support for it in uas.c, while at it it also adds support for US_FL_MAX_SECTORS_64 to uas.c. Cc: stable@vger.kernel.org # 3.16 Signed-off-by: Hans de Goede Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e5e3b3149308e9b104eb439606075a947041b33b Author: Hans de Goede Date: Tue Apr 21 11:20:30 2015 +0200 uas: Allow uas_use_uas_driver to return usb-storage flags [ Upstream commit a5011d44f0e1117a6db14b19b57c51f8be5673a0 ] uas_use_uas_driver may set some US_FL_foo flags during detection, currently these are stored in a local variable and then throw away, but these may be of interest to the caller, so add an extra parameter to (optionally) return the detected flags, and use this in the uas driver. Cc: stable@vger.kernel.org # 3.16 Signed-off-by: Hans de Goede Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1a5be433a33086e3f229d4293d67bf69053b0569 Author: Ilya Dryomov Date: Sat Apr 25 15:56:15 2015 +0300 rbd: end I/O the entire obj_request on error [ Upstream commit 082a75dad84d79d1c15ea9e50f31cb4bb4fa7fd6 ] 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 Cc: stable@vger.kernel.org # 3.10+ Reported-by: Shawn Edwards Reviewed-by: Sage Weil Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 5286f7e311f2c2f19e18a53953be0be4f54a0ba6 Author: Ludovic Desroches Date: Thu Apr 16 16:58:12 2015 +0200 tty/serial: at91: maxburst was missing for dma transfers [ Upstream commit a8d4e01637902311c5643b69a5c80e2805f04054 ] 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 Cc: # 3.12 and later Acked-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ed92377049c4075434b3e4a489a20f6dfefe548e Author: Chris Bainbridge Date: Wed Apr 22 16:40:21 2015 +0100 ACPI / SBS: Enable battery manager when present [ Upstream commit 61f8ff693923e4b19748b0e8287b99778f2661c7 ] Commit 9faf6136ff46 (ACPI / SBS: Disable smart battery manager on Apple) introduced a regression disabling the SBS battery manager. The battery manager should be marked as present when acpi_manager_get_info() returns 0. Fixes: 9faf6136ff46 (ACPI / SBS: Disable smart battery manager on Apple) Signed-off-by: Chris Bainbridge Cc: 3.18+ # 3.18+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 9f57ba579e97cf5d5efe208b6dddef988c2d9643 Author: Omar Sandoval Date: Fri Apr 10 14:20:40 2015 -0700 btrfs: unlock i_mutex after attempting to delete subvolume during send [ Upstream commit 909e26dce3f7600f5e293ac0522c28790a0c8c9c ] Whenever the check for a send in progress introduced in commit 521e0546c970 (btrfs: protect snapshots from deleting during send) is hit, we return without unlocking inode->i_mutex. This is easy to see with lockdep enabled: [ +0.000059] ================================================ [ +0.000028] [ BUG: lock held when returning to user space! ] [ +0.000029] 4.0.0-rc5-00096-g3c435c1 #93 Not tainted [ +0.000026] ------------------------------------------------ [ +0.000029] btrfs/211 is leaving the kernel with locks still held! [ +0.000029] 1 lock held by btrfs/211: [ +0.000023] #0: (&type->i_mutex_dir_key){+.+.+.}, at: [] btrfs_ioctl_snap_destroy+0x2df/0x7a0 Make sure we unlock it in the error path. Reviewed-by: Filipe Manana Reviewed-by: David Sterba Cc: stable@vger.kernel.org Signed-off-by: Omar Sandoval Signed-off-by: Chris Mason Signed-off-by: Sasha Levin commit 36bcc94a440275cac127cff94e4abeb1658297df Author: Bard Liao Date: Tue Apr 28 11:27:39 2015 +0800 ASoC: rt5677: fixed wrong DMIC ref clock [ Upstream commit 60a8d62b8497c23eb3d48149af7e55dac2dd83a2 ] DMIC clock source is not from codec system clock directly. it is generated from the division of system clock. And it should be 256 * sample rate of AIF1. Signed-off-by: Bard Liao Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 5d767349a158c8fab2bbb0e2bbe4d5a75b4abf9f Author: Charles Keepax Date: Wed Apr 22 13:58:47 2015 +0100 ASoC: dapm: Enable autodisable on SOC_DAPM_SINGLE_TLV_AUTODISABLE [ Upstream commit a2d97723cb3a7741af81868427b36bba274b681b ] 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 Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 9714fe21c6f470c58cc00648d66821207f71b491 Author: Wei Yongjun Date: Thu Apr 16 20:18:02 2015 +0800 ASoC: samsung: s3c24xx-i2s: Fix return value check in s3c24xx_iis_dev_probe() [ Upstream commit c479163a1b6ab424786fbcd9225b4e3c1c58eb0b ] In case of error, the function devm_ioremap_resource() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Signed-off-by: Wei Yongjun Reviewed-by: Krzysztof Kozlowski Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 69e961c2193d21b1e754310c96dbcd8ffd224a3e Author: Li Jun Date: Sun Apr 12 17:51:02 2015 +0800 usb: chipidea: otg: remove mutex unlock and lock while stop and start role [ Upstream commit a5a356cee89f86ff86cc3ce24136ca1f802c1bf1 ] Wrongly release mutex lock during otg_statemachine may result in re-enter otg_statemachine, which is not allowed, we should do next state transtition after previous one completed. Fixes: 826cfe751f3e ("usb: chipidea: add OTG fsm operation functions implementation") Cc: # v3.16+ Signed-off-by: Li Jun Signed-off-by: Peter Chen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a142e9641dcbead2c8845c949ad518acac96ed28 Author: Marek Szyprowski Date: Thu Apr 23 12:46:16 2015 +0100 arm64: dma-mapping: always clear allocated buffers [ Upstream commit 6829e274a623187c24f7cfc0e3d35f25d087fcc5 ] Buffers allocated by dma_alloc_coherent() are always zeroed on Alpha, ARM (32bit), MIPS, PowerPC, x86/x86_64 and probably other architectures. It turned out that some drivers rely on this 'feature'. Allocated buffer might be also exposed to userspace with dma_mmap() call, so clearing it is desired from security point of view to avoid exposing random memory to userspace. This patch unifies dma_alloc_coherent() behavior on ARM64 architecture with other implementations by unconditionally zeroing allocated buffer. Cc: # v3.14+ Signed-off-by: Marek Szyprowski Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 57c6da407a51a0f1bbfa38192456b9dffd4cf794 Author: Michal Simek Date: Mon Apr 13 16:34:21 2015 +0200 serial: xilinx: Use platform_get_irq to get irq description structure [ Upstream commit 5c90c07b98c02198d9777a7c4f3047b0a94bf7ed ] For systems with CONFIG_SERIAL_OF_PLATFORM=y and device_type = "serial"; property in DT of_serial.c driver maps and unmaps IRQ (because driver probe fails). Then a driver is called but irq mapping is not created that's why driver is failing again in again on request_irq(). Based on this use platform_get_irq() instead of platform_get_resource() which is doing irq_desc allocation and driver itself can request IRQ. Fix both xilinx serial drivers in the tree. Signed-off-by: Michal Simek CC: Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4957c4d378d97ef685768c48dcbe8d95be1b4d92 Author: Michal Simek Date: Tue Apr 14 12:03:09 2015 +0200 serial: of-serial: Remove device_type = "serial" registration [ Upstream commit 6befa9d883385c580369a2cc9e53fbf329771f6d ] 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 CC: Acked-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit da797a4ce56d6664c6c9d6cd02c9c3a9e94ffe01 Author: Quentin Casasnovas Date: Tue Apr 14 11:25:43 2015 +0200 cdc-acm: prevent infinite loop when parsing CDC headers. [ Upstream commit 0d3bba0287d4e284c3ec7d3397e81eec920d5e7e ] Phil and I found out a problem with commit: 7e860a6e7aa6 ("cdc-acm: add sanity checks") It added some sanity checks to ignore potential garbage in CDC headers but also introduced a potential infinite loop. This can happen at the first loop iteration (elength = 0 in that case) if the description isn't a DT_CS_INTERFACE or later if 'buffer[0]' is zero. It should also be noted that the wrong length was being added to 'buffer' in case 'buffer[1]' was not a DT_CS_INTERFACE descriptor, since elength was assigned after that check in the loop. A specially crafted USB device could be used to trigger this infinite loop. Fixes: 7e860a6e7aa6 ("cdc-acm: add sanity checks") Signed-off-by: Phil Turnbull Signed-off-by: Quentin Casasnovas CC: Sergei Shtylyov CC: Oliver Neukum CC: Adam Lee CC: Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 57f086bcbcc3104557959e30ddbf94ecb8b028d1 Author: Oliver Neukum Date: Wed Jan 28 11:14:55 2015 +0100 cdc-acm: add sanity checks [ Upstream commit 7e860a6e7aa62b337a61110430cd633db5b0d2dd ] Check the special CDC headers for a plausible minimum length. Another big operating systems ignores such garbage. Signed-off-by: Oliver Neukum CC: stable@vger.kernel.org Reviewed-by: Adam Lee Tested-by: Adam Lee Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a1f3efd406be6db261be2f7c1a31e836d157ae32 Author: Takashi Iwai Date: Mon Apr 27 10:40:45 2015 +0200 ALSA: hda - Add mute-LED mode control to Thinkpad [ Upstream commit 7290006d8c0900c56d8c58428134f02c35109d17 ] This patch adds the missing flag to enable "Mute-LED Mode" mixer enum ctl for Thinkpads that have also the software mute-LED control. Reported-and-tested-by: Pali Rohár Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ea4b18887e1f454aa650952f3033a38e777d0891 Author: Peter Zubaj Date: Tue Apr 28 21:57:29 2015 +0200 ALSA: emu10k1: Emu10k2 32 bit DMA mode [ Upstream commit 7241ea558c6715501e777396b5fc312c372e11d9 ] 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 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 79f0cbcc9a4287d966fd7fb259b3cb4f54f99913 Author: Takashi Iwai Date: Mon Apr 27 13:00:09 2015 +0200 ALSA: emu10k1: Fix card shortname string buffer overflow [ Upstream commit d02260824e2cad626fb2a9d62e27006d34b6dedc ] 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. Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 33b9b8ceb1cb2474c33dce3f366ffc947faf035c Author: Takashi Iwai Date: Tue Apr 28 17:11:44 2015 +0200 ALSA: emux: Fix mutex deadlock in OSS emulation [ Upstream commit 1c94e65c668f44d2c69ae7e7fc268ab3268fba3e ] 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. Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1e568ab9b2d5d97516999e8f3e89fdd330fe2d8c Author: Takashi Iwai Date: Mon Apr 27 14:50:39 2015 +0200 ALSA: emux: Fix mutex deadlock at unloading [ Upstream commit 07b0e5d49d227e3950cb13a3e8caf248ef2a310e ] 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. Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3c021baa28e129fec180856a2f5e12c029826e53 Author: Rafał Miłecki Date: Wed Apr 1 16:01:02 2015 +0200 MIPS: BCM47XX: Fix detecting Microsoft MN-700 & Asus WL500G [ Upstream commit 96f7c21363e0e0d19f3471f54a719ed06d708513 ] Since the day of adding this code it was broken. We were iterating over a wrong array and checking for wrong NVRAM entry. Signed-off-by: Rafał Miłecki Cc: linux-mips@linux-mips.org Cc: Hauke Mehrtens Patchwork: https://patchwork.linux-mips.org/patch/9654/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit e17bb066ab5a4f824f90d830a5b70b84253ad350 Author: Markos Chandras Date: Tue Nov 25 09:15:45 2014 +0000 MIPS: Kconfig: Disable SMP/CPS for 64-bit [ Upstream commit 6ca716f2e5571d25a3899c6c5c91ff72ea6d6f5e ] A 64-bit build for Malta produces far too many build problems when SMP/CPS is selected. Moreover, there is currently no 64-bit product with SMP/CPS so we disable SMP/CPS when building for 64-bit until it is properly supported. Signed-off-by: Markos Chandras Cc: Paul Burton Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/8573/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 8a77ae3ed6c300797d7b93de79434a6fe5f6e42e Author: Niklas Cassel Date: Thu Jan 15 16:41:13 2015 +0100 MIPS: smp-cps: cpu_set FPU mask if FPU present [ Upstream commit 90db024f140d0d6ad960cc5f090e3c8ed890ca55 ] If we have an FPU, enroll ourselves in the FPU-full mask. Matching the MT_SMP and CMP implementations of smp_setup. Signed-off-by: Niklas Cassel Cc: paul.burton@imgtec.com Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/8948/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 718bce368d0981291524c3ec07848121f1aac2fe Author: John Crispin Date: Mon Feb 23 06:17:33 2015 +0100 MIPS: ralink: add missing symbol for RALINK_ILL_ACC [ Upstream commit a7b7aad383c5dd9221a06e378197350dd27c1163 ] A driver was added in commit 5433acd81e87 ("MIPS: ralink: add illegal access driver") without the Kconfig section being added. Fix this by adding the symbol to the Kconfig file. Signed-off-by: John Crispin Reported-by: Paul Bolle Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9299/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit e10f7b80311ec624282d5a9127cadf24b4fb6f76 Author: Adrien Schildknecht Date: Wed Mar 25 16:31:42 2015 +0100 SSB: fix Kconfig dependencies [ Upstream commit 179fa46fb666c8f2aa2bbb1f3114d5d826d59d3d ] The commit 21400f252a97 ("MIPS: BCM47XX: Make ssb init NVRAM instead of bcm47xx polling it") introduces a dependency to SSB_SFLASH but did not add it to the Kconfig. drivers/ssb/driver_mipscore.c:216:36: error: 'struct ssb_mipscore' has no member named 'sflash' struct ssb_sflash *sflash = &mcore->sflash; ^ drivers/ssb/driver_mipscore.c:249:12: error: dereferencing pointer to incomplete type if (sflash->present) { ^ Signed-off-by: Adrien Schildknecht Cc: m@bues.ch Cc: zajec5@gmail.com Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/9598/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 3552e350208a52dcfe043093b7eba7d68473ea3f Author: Ralf Baechle Date: Wed Mar 25 13:21:51 2015 +0100 MIPS: Octeon: Delete override of cpu_has_mips_r2_exec_hazard. [ Upstream commit f05ff43355e6997c18f82ddcee370a6e5f8643ce ] This is no longer needed with the fixed, new and improved definition of cpu_has_mips_r2_exec_hazard in . For a discussion, see http://patchwork.linux-mips.org/patch/9539/. Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 3749ec1e51611c4188c54cf2f4d516660fd857a7 Author: Markos Chandras Date: Tue Mar 3 18:48:49 2015 +0000 MIPS: kernel: entry.S: Set correct ISA level for mips_ihb [ Upstream commit aebac99384f7a6d83a3dcd42bf2481eed2670083 ] Commit 6ebb496ffc7e("MIPS: kernel: entry.S: Add MIPS R6 related definitions") added the MIPSR6 definition but it did not update the ISA level of the actual assembly code so a pre-MIPSR6 jr.hb instruction was generated instead. Fix this by using the MISP_ISA_LEVEL_RAW macro. Signed-off-by: Markos Chandras Fixes: 6ebb496ffc7e("MIPS: kernel: entry.S: Add MIPS R6 related definitions") Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9386/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit a23817cb37984c581bacaf1506153f7410b028eb Author: Ganesan Ramalingam Date: Wed Jan 7 16:58:26 2015 +0530 MIPS: Netlogic: Fix for SATA PHY init [ Upstream commit 872cd4c2c617bb3a203ebe18115fd0c697112b87 ] Update to the SATA PHY initialization. This is needed for SATA detection to succeed in all configurations. Signed-off-by: Ganesan Ramalingam Signed-off-by: Jayachandran C Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/8886/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit b50f1cb13d2e425aed6e544bbaa911aaf21e47c2 Author: Aaro Koskinen Date: Sun Mar 22 17:55:39 2015 +0200 MIPS: OCTEON: fix PCI interrupt mapping for D-Link DSR-1000N [ Upstream commit b083518c52ab75a345d668ca7fa41e530df08d51 ] Fix PCI interrupt mapping for DSR1000N. This will get the PCI slot interrupts working. The mapping is based on D-Link GPL tarball. Signed-off-by: Aaro Koskinen Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9593/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 9ba256194c36f2881d49767373d3185d6cd6bb0b Author: Alexander Sverdlin Date: Wed Mar 18 14:05:21 2015 +0100 MIPS: Octeon: Remove udelay() causing huge IRQ latency [ Upstream commit 73bf3c2a500b2db8ac966469591196bf55afb409 ] udelay() in PCI/PCIe read/write callbacks cause 30ms IRQ latency on Octeon platforms because these operations are called from PCI_OP_READ() and PCI_OP_WRITE() under raw_spin_lock_irqsave(). Signed-off-by: Alexander Sverdlin Cc: linux-mips@linux-mips.org Cc: David Daney Cc: Rob Herring Cc: Jiri Kosina Cc: Randy Dunlap Cc: Masanari Iida Cc: Bjorn Helgaas Cc: Mathias Patchwork: https://patchwork.linux-mips.org/patch/9576/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 76723e7ed589998384a080e29204df4659c67cf2 Author: Boris Brezillon Date: Fri May 15 20:11:36 2015 -0400 clk: at91: usb: fix determine_rate prototype Commit c67881fc890916206e723329e774391c6ed354ce is a backport of 0b67c43ce36a9964f1d5e3f973ee19eefd3f9f8f upstream commit, fixing a bug on clk rate change propagation. But in 4.0 ->determine_rate() prototype has changed, thus introducing a prototype mismatch when applying it on 3.19. Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 51f3eddd039a053a3ae578d85c46662fff625b54 Author: Aaro Koskinen Date: Wed Mar 4 23:08:49 2015 +0200 MIPS: OCTEON: dma-octeon: fix OHCI USB config check [ Upstream commit a8667d706dfa394ef9fe5f9013dee92d40a096e8 ] CONFIG_USB_OCTEON_OHCI is deprecated and no longer needed to use OHCI on OCTEON II. Instead, CONFIG_USB_OHCI_HCD_PLATFORM should be used. Signed-off-by: Aaro Koskinen Cc: Aleksey Makarov Cc: David Daney Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9421/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 7b5991c8635c3211a474e549cd3f42d17ce53053 Author: Nicolas Schichan Date: Thu Mar 12 17:00:58 2015 +0100 MIPS: BCM63xx: Move bcm63xx_gpio_init() to bcm63xx_register_devices(). [ Upstream commit 2ec459f2a77b808c1e5a3616c88b613d3f720c8d ] When called from prom init code, bcm63xx_gpio_init() will fail as it will call gpiochip_add() which relies on a working kmalloc() to alloc the gpio_desc array and kmalloc is not useable yet at prom init time. Move bcm63xx_gpio_init() to bcm63xx_register_devices() (an arch_initcall) where kmalloc works. Fixes: 14e85c0e69d5 ("gpio: remove gpio_descs global array") Signed-off-by: Nicolas Schichan Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: Alexandre Courbot Patchwork: https://patchwork.linux-mips.org/patch/9530/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 2611e2418ca8be78f87cd8f727aa92f04fdcfd21 Author: Alexei Starovoitov Date: Mon Apr 27 14:40:37 2015 -0700 bpf: fix 64-bit divide [ Upstream commit 876a7ae65b86d8cec8efe7d15d050ac61116874e ] ALU64_DIV instruction should be dividing 64-bit by 64-bit, whereas do_div() does 64-bit by 32-bit divide. x64 and arm64 JITs correctly implement 64 by 64 unsigned divide. llvm BPF backend emits code assuming that ALU64_DIV does 64 by 64. Fixes: 89aa075832b0 ("net: sock: allow eBPF programs to be attached to sockets") Reported-by: Michael Holzheu Acked-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7f1a6ae73b5c2d24b21d9a27928ceacef3a9a939 Author: Jann Horn Date: Sun Apr 19 02:48:39 2015 +0200 fs: take i_mutex during prepare_binprm for set[ug]id executables [ Upstream commit 8b01fc86b9f425899f8a3a8fc1c47d73c2c20543 ] 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: Sasha Levin commit c42f3e154ec94d298480397cc82613d26b712449 Author: Troy Tan Date: Tue Feb 3 11:15:17 2015 -0600 rtlwifi: rtl8192ee: Fix handling of new style descriptors [ Upstream commit d0311314d00298f83aa5450a1d4a92889e7cc2ea ] The hardware and firmware for the RTL8192EE utilize a FIFO list of descriptors. There were some problems with the initial implementation. The worst of these failed to detect that the FIFO was becoming full, which led to the device needing to be power cycled. As this condition is not relevant to most of the devices supported by rtlwifi, a callback routine was added to detect this situation. This patch implements the necessary changes in the pci handler, and the linkage into the appropriate rtl8192ee routine. Signed-off-by: Troy Tan Signed-off-by: Larry Finger Cc: Stable [V3.18] Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 35d44e970eb865125c699a77c1d143236488babc Author: Naoya Horiguchi Date: Wed Feb 11 15:25:22 2015 -0800 mm/hugetlb: take page table lock in follow_huge_pmd() [ Upstream commit e66f17ff71772b209eed39de35aaa99ba819c93d ] We have a race condition between move_pages() and freeing hugepages, where move_pages() calls follow_page(FOLL_GET) for hugepages internally and tries to get its refcount without preventing concurrent freeing. This race crashes the kernel, so this patch fixes it by moving FOLL_GET code for hugepages into follow_huge_pmd() with taking the page table lock. This patch intentionally removes page==NULL check after pte_page. This is justified because pte_page() never returns NULL for any architectures or configurations. This patch changes the behavior of follow_huge_pmd() for tail pages and then tail pages can be pinned/returned. So the caller must be changed to properly handle the returned tail pages. We could have a choice to add the similar locking to follow_huge_(addr|pud) for consistency, but it's not necessary because currently these functions don't support FOLL_GET flag, so let's leave it for future development. Here is the reproducer: $ cat movepages.c #include #include #include #define ADDR_INPUT 0x700000000000UL #define HPS 0x200000 #define PS 0x1000 int main(int argc, char *argv[]) { int i; int nr_hp = strtol(argv[1], NULL, 0); int nr_p = nr_hp * HPS / PS; int ret; void **addrs; int *status; int *nodes; pid_t pid; pid = strtol(argv[2], NULL, 0); addrs = malloc(sizeof(char *) * nr_p + 1); status = malloc(sizeof(char *) * nr_p + 1); nodes = malloc(sizeof(char *) * nr_p + 1); while (1) { for (i = 0; i < nr_p; i++) { addrs[i] = (void *)ADDR_INPUT + i * PS; nodes[i] = 1; status[i] = 0; } ret = numa_move_pages(pid, nr_p, addrs, nodes, status, MPOL_MF_MOVE_ALL); if (ret == -1) err("move_pages"); for (i = 0; i < nr_p; i++) { addrs[i] = (void *)ADDR_INPUT + i * PS; nodes[i] = 0; status[i] = 0; } ret = numa_move_pages(pid, nr_p, addrs, nodes, status, MPOL_MF_MOVE_ALL); if (ret == -1) err("move_pages"); } return 0; } $ cat hugepage.c #include #include #include #define ADDR_INPUT 0x700000000000UL #define HPS 0x200000 int main(int argc, char *argv[]) { int nr_hp = strtol(argv[1], NULL, 0); char *p; while (1) { p = mmap((void *)ADDR_INPUT, nr_hp * HPS, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB, -1, 0); if (p != (void *)ADDR_INPUT) { perror("mmap"); break; } memset(p, 0, nr_hp * HPS); munmap(p, nr_hp * HPS); } } $ sysctl vm.nr_hugepages=40 $ ./hugepage 10 & $ ./movepages 10 $(pgrep -f hugepage) Fixes: e632a938d914 ("mm: migrate: add hugepage migration code to move_pages()") Signed-off-by: Naoya Horiguchi Reported-by: Hugh Dickins Cc: James Hogan Cc: David Rientjes Cc: Mel Gorman Cc: Johannes Weiner Cc: Michal Hocko Cc: Rik van Riel Cc: Andrea Arcangeli Cc: Luiz Capitulino Cc: Nishanth Aravamudan Cc: Lee Schermerhorn Cc: Steve Capper Cc: [3.12+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit dd8f776dbe944939dd940b981d160f2fa3191641 Author: Naoya Horiguchi Date: Wed Feb 11 15:25:15 2015 -0800 mm/hugetlb: use pmd_page() in follow_huge_pmd() [ Upstream commit 97534127012f0e396eddea4691f4c9b170aed74b ] 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: Sasha Levin commit ced9df8d7f9957e9b04e8080e0cd847f4e84f12f Author: Ian Abbott Date: Fri Feb 27 16:04:42 2015 +0000 staging: comedi: adv_pci1710: fix AI INSN_READ for non-zero channel [ Upstream commit abe46b8932dd9a6dfc3698e3eb121809b7b9ed28 ] Reading of analog input channels by the `INSN_READ` comedi instruction is broken for all except channel 0. `pci171x_ai_insn_read()` calls `pci171x_ai_read_sample()` with the wrong value for the third parameter. It is supposed to be the current index in a channel list (which is always of length 1 in this case, so the index should be 0), but instead it is passing the actual channel number. `pci171x_ai_read_sample()` checks the channel number encoded in the raw sample value read from the hardware matches the channel number stored in the specified index of the previously set up channel list and returns `-ENODATA` if it doesn't match. Since the index should always be 0 in this case, the match will fail unless the channel number is also 0. Fix it by passing 0 as the channel index. Note that when the bug first appeared, it was `pci171x_ai_dropout()` that was called with the wrong parameter value. `pci171x_ai_dropout()` got replaced with `pci171x_ai_read_sample()` in commit 7fd2dae2500d ("staging: comedi: adv_pci1710: introduce pci171x_ai_read_sample()"). Fixes: 16c7eb6047bb ("staging: comedi: adv_pci1710: always enable PCI171x_PARANOIDCHECK code") Signed-off-by: Ian Abbott Cc: stable # 3.16+ Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 24f2e905a3adb255b00e26688c6155c179747a0d Author: Radim Krčmář Date: Tue Mar 17 14:02:32 2015 +0100 KVM: nVMX: mask unrestricted_guest if disabled on L0 [ Upstream commit 0790ec172de1bd2e23f1dbd4925426b6cc3c1b72 ] If EPT was enabled, unrestricted_guest was allowed in L1 regardless of L0. L1 triple faulted when running L2 guest that required emulation. Another side effect was 'WARN_ON_ONCE(vmx->nested.nested_run_pending)' in L0's dmesg: WARNING: CPU: 0 PID: 0 at arch/x86/kvm/vmx.c:9190 nested_vmx_vmexit+0x96e/0xb00 [kvm_intel] () Prevent this scenario by masking SECONDARY_EXEC_UNRESTRICTED_GUEST when the host doesn't have it enabled. Fixes: 78051e3b7e35 ("KVM: nVMX: Disable unrestricted mode if ept=0") Cc: stable@vger.kernel.org Tested-By: Kashyap Chamarthy Signed-off-by: Radim Krčmář Signed-off-by: Marcelo Tosatti Signed-off-by: Sasha Levin commit d07c59df9ff1f75f5ce0a9af7e9a4b9da8739078 Author: Florian Westphal Date: Wed Apr 1 22:36:27 2015 +0200 netfilter: bridge: really save frag_max_size between PRE and POST_ROUTING [ Upstream commit 0b67c43ce36a9964f1d5e3f973ee19eefd3f9f8f ] We also need to save/store in forward, else br_parse_ip_options call will zero frag_max_size as well. Fixes: 93fdd47e5 ('bridge: Save frag_max_size between PRE_ROUTING and POST_ROUTING') Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit d08282c148c574d5ef8d81f657a6e64d49da1d88 Author: Junjie Mao Date: Wed Jan 28 10:02:44 2015 +0800 driver core: bus: Goto appropriate labels on failure in bus_add_device [ Upstream commit 1c34203a1496d1849ba978021b878b3447d433c8 ] 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: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ce7c6bb45f81d96764f1674bcba70c98c969e6b8 Author: Linus Walleij Date: Wed Feb 18 17:12:18 2015 +0100 drivers: platform: parse IRQ flags from resources [ Upstream commit 7085a7401ba54e92bbb5aa24d6f428071e18e509 ] This fixes a regression from the net subsystem: After commit d52fdbb735c36a209f36a628d40ca9185b349ba7 "smc91x: retrieve IRQ and trigger flags in a modern way" a regression would appear on some legacy platforms such as the ARM PXA Zylonite that specify IRQ resources like this: static struct resource r = { .start = X, .end = X, .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHEDGE, }; The previous code would retrieve the resource and parse the high edge setting in the SMC91x driver, a use pattern that means every driver specifying an IRQ flag from a static resource need to parse resource flags and apply them at runtime. As we switched the code to use IRQ descriptors to retrieve the the trigger type like this: irqd_get_trigger_type(irq_get_irq_data(...)); the code would work for new platforms using e.g. device tree as the backing irq descriptor would have its flags properly set, whereas this kind of oldstyle static resources at no point assign the trigger flags to the corresponding IRQ descriptor. To make the behaviour identical on modern device tree and legacy static platform data platforms, modify platform_get_irq() to assign the trigger flags to the irq descriptor when a client looks up an IRQ from static resources. Fixes: d52fdbb735c3 ("smc91x: retrieve IRQ and trigger flags in a modern way") Tested-by: Robert Jarzmik Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e2276c7e6bfa450d2c96ce6ba279183cc3efa106 Author: Dan Carpenter Date: Thu Apr 16 12:48:35 2015 -0700 memstick: mspro_block: add missing curly braces [ Upstream commit 13f6b191aaa11c7fd718d35a0c565f3c16bc1d99 ] 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: Sasha Levin commit e0407f4aea14008ecf27c71839d2a92463f4a611 Author: Nishanth Menon Date: Sat Mar 7 03:39:05 2015 -0600 C6x: time: Ensure consistency in __init [ Upstream commit f4831605f2dacd12730fe73961c77253cc2ea425 ] 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: Sasha Levin commit da41fc72d2fb3680fcfb1afdb9f04cc7b5aaf422 Author: Vutla, Lokesh Date: Tue Mar 31 09:52:25 2015 +0530 crypto: omap-aes - Fix support for unequal lengths [ Upstream commit 6d7e7e02a044025237b6f62a20521170b794537f ] 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: Sasha Levin commit 9e9150becef712cfc0eebee1222f94416eab2996 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 [ Upstream commit a3fa71c40f1853d0c27e8f5bc01a722a705d9682 ] 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: Sasha Levin commit e4e28fbc306e94b5215b1fb1db5819b132f82faa Author: mancha security Date: Wed Mar 18 18:47:25 2015 +0100 lib: memzero_explicit: use barrier instead of OPTIMIZER_HIDE_VAR [ Upstream commit 0b053c9518292705736329a8fe20ef4686ffc8e9 ] 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: Sasha Levin commit b6c65e367249dd9ddc28b4f49b171f6803d70266 Author: Daniel Borkmann Date: Thu Mar 12 17:21:42 2015 +0100 ebpf: verifier: check that call reg with ARG_ANYTHING is initialized [ Upstream commit 80f1d68ccba70b1060c9c7360ca83da430f66bed ] I noticed that a helper function with argument type ARG_ANYTHING does not need to have an initialized value (register). This can worst case lead to unintented stack memory leakage in future helper functions if they are not carefully designed, or unintended application behaviour in case the application developer was not careful enough to match a correct helper function signature in the API. The underlying issue is that ARG_ANYTHING should actually be split into two different semantics: 1) ARG_DONTCARE for function arguments that the helper function does not care about (in other words: the default for unused function arguments), and 2) ARG_ANYTHING that is an argument actually being used by a helper function and *guaranteed* to be an initialized register. The current risk is low: ARG_ANYTHING is only used for the 'flags' argument (r4) in bpf_map_update_elem() that internally does strict checking. Fixes: 17a5267067f3 ("bpf: verifier (add verifier core)") Signed-off-by: Daniel Borkmann Acked-by: Alexei Starovoitov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fcea4d66b0d0660439f6a2eb5b3894d7ee5fd136 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 [ Upstream commit 08e8331654d1d7b2c58045e549005bc356aa7810 ] 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: Sasha Levin commit 49b6acb62afaf20bee52c95bcb0a3baeeddc5b0c Author: Anna Schumaker Date: Tue Apr 14 10:34:20 2015 -0400 NFS: Add a stub for GETDEVICELIST [ Upstream commit 7c61f0d3897eeeff6f3294adb9f910ddefa8035a ] d4b18c3e (pnfs: remove GETDEVICELIST implementation) removed the GETDEVICELIST operation from the NFS client, but left a "hole" in the nfs4_procedures array. This caused /proc/self/mountstats to report an operation named "51" where GETDEVICELIST used to be. This patch adds a stub to fix mountstats. Signed-off-by: Anna Schumaker Fixes: d4b18c3e (pnfs: remove GETDEVICELIST implementation) Cc: stable@vger.kernel.org # 3.17+ Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 61c8c52ced763e16f2c1482ee5a7f4e162c5c4ca Author: J. Bruce Fields Date: Tue Apr 21 15:25:39 2015 -0400 nfsd4: disallow SEEK with special stateids [ Upstream commit 980608fb50aea34993ba956b71cd4602aa42b14b ] If the client uses a special stateid then we'll pass a NULL file to vfs_llseek. Fixes: 24bab491220f " NFSD: Implement SEEK" Cc: Anna Schumaker Cc: stable@vger.kernel.org Reported-by: Christoph Hellwig Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 5a9fb83ea5da6f96708e88e39d352730a02fc8b0 Author: J. Bruce Fields Date: Fri Apr 3 17:19:41 2015 -0400 nfsd4: fix READ permission checking [ Upstream commit 6e4891dc289cd191d46ab7ba1dcb29646644f9ca ] In the case we already have a struct file (derived from a stateid), we still need to do permission-checking; otherwise an unauthorized user could gain access to a file by sniffing or guessing somebody else's stateid. Cc: stable@vger.kernel.org Fixes: dc97618ddda9 "nfsd4: separate splice and readv cases" Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit c5f77349d6694a2ce04536343fee87a0de74522d Author: Al Viro Date: Fri Apr 24 15:47:07 2015 -0400 RCU pathwalk breakage when running into a symlink overmounting something [ Upstream commit 3cab989afd8d8d1bc3d99fef0e7ed87c31e7b647 ] 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(). Cc: stable@vger.kernel.org # since 2.6.39 Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 3d46720fc10e8270d003fa8e55f2e89c14af9261 Author: Dmitry Torokhov Date: Tue Apr 21 09:49:11 2015 -0700 drm/i915: cope with large i2c transfers [ Upstream commit 9535c4757b881e06fae72a857485ad57c422b8d2 ] 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). Cc: stable@vger.kernel.org Reviewed-by: Chris Wilson Signed-off-by: Dmitry Torokhov Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 712d9cd6d0bbe95375893547310dfd1394fe7a65 Author: Imre Deak Date: Wed Apr 15 16:52:30 2015 -0700 drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT reg [ Upstream commit b5f1c97f944482e98e6e39208af356630389d1ea ] Due this typo we don't save/restore the GFX_MAX_REQ_COUNT register across suspend/resume, so fix this. This was introduced in commit ddeea5b0c36f3665446518c609be91f9336ef674 Author: Imre Deak Date: Mon May 5 15:19:56 2014 +0300 drm/i915: vlv: add runtime PM support I noticed this only by reading the code. To my knowledge it shouldn't cause any real problems at the moment, since the power well backing this register remains on across a runtime s/r. This may change once system-wide s0ix functionality is enabled in the kernel. v2: - resend after a missing git add -u :/ Cc: stable@vger.kernel.org Signed-off-by: Imre Deak Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) Signed-off-by: Rodrigo Vivi Reviewed-by: Mika Kuoppala Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 631590d952839b4261df2bf6cbf0839940aaf96a Author: Daniel Vetter Date: Wed Apr 1 13:43:46 2015 +0200 drm/i915: Dont enable CS_PARSER_ERROR interrupts at all [ Upstream commit 37ef01ab5d24d1d520dc79f6a98099d451c2a901 ] We stopped handling them in commit aaecdf611a05cac26a94713bad25297e60225c29 Author: Daniel Vetter Date: Tue Nov 4 15:52:22 2014 +0100 drm/i915: Stop gathering error states for CS error interrupts but just clearing is apparently not enough: A sufficiently dead gpu left behind by firmware (*cough* coreboot *cough*) can keep the gpu in an endless loop of such interrupts, eventually leading to the nmi firing. And definitely to what looks like a machine hang. Since we don't even enable these interrupts on gen5+ let's do the same on earlier platforms. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93171 Tested-by: Mono Tested-by: info@gluglug.org.uk Cc: stable@vger.kernel.org Reviewed-by: Mika Kuoppala Signed-off-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 9be03c9a98adcb1e66df32873cd980844e9b914d Author: Alex Deucher Date: Tue Feb 24 11:29:21 2015 -0500 drm/radeon: fix doublescan modes (v2) [ Upstream commit fd99a0943ffaa0320ea4f69d09ed188f950c0432 ] Use the correct flags for atom. v2: handle DRM_MODE_FLAG_DBLCLK Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 808601dcd371399fabc26c74fd54396cbfd761b6 Author: Mark Brown Date: Wed Apr 15 19:18:39 2015 +0100 i2c: core: Export bus recovery functions [ Upstream commit c1c21f4e60ed4523292f1a89ff45a208bddd3849 ] 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: Sasha Levin commit 74cd034768fecc289b1ef569f446ff1a54b5081b Author: Dmitry Torokhov Date: Mon Apr 20 15:14:47 2015 -0700 i2c: rk3x: report number of messages transmitted [ Upstream commit c6cbfb91b878224e78408a2e15901c79de77115a ] master_xfer() method should return number of i2c messages transferred, but on Rockchip we were usually returning just 1, which caused trouble with users that actually check number of transferred messages vs. checking for negative error codes. Signed-off-by: Dmitry Torokhov Signed-off-by: Wolfram Sang Cc: stable@kernel.org Signed-off-by: Sasha Levin commit c130887c1434d68ce26c4c3cbdaa82c6b5af06d9 Author: Rabin Vincent Date: Mon Apr 13 22:30:12 2015 +0200 tracing: Handle ftrace_dump() atomic context in graph_trace_open() [ Upstream commit ef99b88b16bee753fa51207abdc58ae660453ec6 ] graph_trace_open() can be called in atomic context from ftrace_dump(). Use GFP_ATOMIC for the memory allocations when that's the case, in order to avoid the following splat. BUG: sleeping function called from invalid context at mm/slab.c:2849 in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0 Backtrace: .. [<8004dc94>] (__might_sleep) from [<801371f4>] (kmem_cache_alloc_trace+0x160/0x238) r7:87800040 r6:000080d0 r5:810d16e8 r4:000080d0 [<80137094>] (kmem_cache_alloc_trace) from [<800cbd60>] (graph_trace_open+0x30/0xd0) r10:00000100 r9:809171a8 r8:00008e28 r7:810d16f0 r6:00000001 r5:810d16e8 r4:810d16f0 [<800cbd30>] (graph_trace_open) from [<800c79c4>] (trace_init_global_iter+0x50/0x9c) r8:00008e28 r7:808c853c r6:00000001 r5:810d16e8 r4:810d16f0 r3:800cbd30 [<800c7974>] (trace_init_global_iter) from [<800c7aa0>] (ftrace_dump+0x90/0x2ec) r4:810d2580 r3:00000000 [<800c7a10>] (ftrace_dump) from [<80414b2c>] (sysrq_ftrace_dump+0x1c/0x20) r10:00000100 r9:809171a8 r8:808f6e7c r7:00000001 r6:00000007 r5:0000007a r4:808d5394 [<80414b10>] (sysrq_ftrace_dump) from [<800169b8>] (return_to_handler+0x0/0x18) [<80415498>] (__handle_sysrq) from [<800169b8>] (return_to_handler+0x0/0x18) r8:808c8100 r7:808c8444 r6:00000101 r5:00000010 r4:84eb3210 [<80415668>] (handle_sysrq) from [<800169b8>] (return_to_handler+0x0/0x18) [<8042a760>] (pl011_int) from [<800169b8>] (return_to_handler+0x0/0x18) r10:809171bc r9:809171a8 r8:00000001 r7:00000026 r6:808c6000 r5:84f01e60 r4:8454fe00 [<8007782c>] (handle_irq_event_percpu) from [<80077b44>] (handle_irq_event+0x4c/0x6c) r10:808c7ef0 r9:87283e00 r8:00000001 r7:00000000 r6:8454fe00 r5:84f01e60 r4:84f01e00 [<80077af8>] (handle_irq_event) from [<8007aa28>] (handle_fasteoi_irq+0xf0/0x1ac) r6:808f52a4 r5:84f01e60 r4:84f01e00 r3:00000000 [<8007a938>] (handle_fasteoi_irq) from [<80076dc0>] (generic_handle_irq+0x3c/0x4c) r6:00000026 r5:00000000 r4:00000026 r3:8007a938 [<80076d84>] (generic_handle_irq) from [<80077128>] (__handle_domain_irq+0x8c/0xfc) r4:808c1e38 r3:0000002e [<8007709c>] (__handle_domain_irq) from [<800087b8>] (gic_handle_irq+0x34/0x6c) r10:80917748 r9:00000001 r8:88802100 r7:808c7ef0 r6:808c8fb0 r5:00000015 r4:8880210c r3:808c7ef0 [<80008784>] (gic_handle_irq) from [<80014044>] (__irq_svc+0x44/0x7c) Link: http://lkml.kernel.org/r/1428953721-31349-1-git-send-email-rabin@rab.in Link: http://lkml.kernel.org/r/1428957012-2319-1-git-send-email-rabin@rab.in Cc: stable@vger.kernel.org # 3.13+ Signed-off-by: Rabin Vincent Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 72f9b0fa0d5f729f482a61a3dcefb9b835a664e6 Author: Sagi Grimberg Date: Tue Apr 14 18:08:13 2015 +0300 IB/iser: Fix wrong calculation of protection buffer length [ Upstream commit a065fe6aa25ba6ba93c02dc13486131bb3c64d5f ] This length miss-calculation may cause a silent data corruption in the DIX case and cause the device to reference unmapped area. Fixes: d77e65350f2d ('libiscsi, iser: Adjust data_length to include protection information') Signed-off-by: Sagi Grimberg Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit 4eb6d476fcf6ac71a0b0528785d2a6807c7f57fd Author: Erez Shitrit Date: Thu Apr 2 13:39:05 2015 +0300 IB/mlx4: Fix WQE LSO segment calculation [ Upstream commit ca9b590caa17bcbbea119594992666e96cde9c2f ] 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: Sasha Levin commit ee4709cebbfc95e30310a6370ace293e6bec1aaa Author: Yann Droneaud Date: Mon Apr 13 14:56:23 2015 +0200 IB/core: don't disallow registering region starting at 0x0 [ Upstream commit 66578b0b2f69659f00b6169e6fe7377c4b100d18 ] 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: # 8494057ab5e4 ("IB/uverbs: Prevent integer overflow in ib_umem_get address arithmetic") 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: Sasha Levin commit 33f0de401642c9d434e84490f5f84fdcbfd32702 Author: Yann Droneaud Date: Mon Apr 13 14:56:22 2015 +0200 IB/core: disallow registering 0-sized memory region [ Upstream commit 8abaae62f3fdead8f4ce0ab46b4ab93dee39bab2 ] 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: Cc: Shachar Raindel Cc: Jack Morgenstein Cc: Or Gerlitz Signed-off-by: Yann Droneaud Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit 071dac7383e693aecb3837a7feb123b71d558ee9 Author: Ezequiel Garcia Date: Tue Mar 10 11:37:14 2015 -0300 [media] stk1160: Make sure current buffer is released [ Upstream commit aeff09276748b66072f2db2e668cec955cf41959 ] 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. Cc: stable@vger.kernel.org Signed-off-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c2c7af9c23fbbb1d74cff6d84530dd48e04104d9 Author: Sifan Naeem Date: Tue Feb 10 07:41:56 2015 -0300 [media] rc: img-ir: fix error in parameters passed to irq_free() [ Upstream commit 80ccf4ad06dc9d2f06a8347b2d309cdc959f72b3 ] img_ir_remove() passes a pointer to the ISR function as the 2nd parameter to irq_free() instead of a pointer to the device data structure. This issue causes unloading img-ir module to fail with the below warning after building and loading img-ir as a module. WARNING: CPU: 2 PID: 155 at ../kernel/irq/manage.c:1278 __free_irq+0xb4/0x214() Trying to free already-free IRQ 58 Modules linked in: img_ir(-) CPU: 2 PID: 155 Comm: rmmod Not tainted 3.14.0 #55 ... Call Trace: ... [<8048d420>] __free_irq+0xb4/0x214 [<8048d6b4>] free_irq+0xac/0xf4 [] img_ir_remove+0x54/0xd4 [img_ir] [<8073ded0>] platform_drv_remove+0x30/0x54 ... Fixes: 160a8f8aec4d ("[media] rc: img-ir: add base driver") Signed-off-by: Sifan Naeem Cc: # 3.15+ Acked-by: James Hogan Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3b2b5bee96e5e2b0948cffd033f327ed69508ba3 Author: James Bottomley Date: Wed Apr 15 22:16:01 2015 -0700 mvsas: fix panic on expander attached SATA devices [ Upstream commit 56cbd0ccc1b508de19561211d7ab9e1c77e6b384 ] 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 Cc: Signed-off-by: James Bottomley Signed-off-by: Sasha Levin commit 49afcd312b7f73495764fc16a8b9f25e9e6a14ae 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() [ Upstream commit 40384e4bbeb9f2651fe9bffc0062d9f31ef625bf ] 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 Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a31989f031f88aa43a92670fbe008706bb4f090f Author: Martin K. Petersen Date: Tue Apr 14 17:11:03 2015 -0400 sd: Fix missing ATO tag check [ Upstream commit e557990e358934fb168d30371c9c0f63e314c6b8 ] 3aec2f41a8bae introduced a merge error where we would end up check for sdkp instead of sdkp->ATO. Fix this so we register app tag capability correctly. Signed-off-by: Martin K. Petersen Cc: # v3.17+ Reviewed-by: Sagi Grimberg Signed-off-by: James Bottomley Signed-off-by: Sasha Levin commit ee7633f06e910c01c59d17a824db0661b56f1610 Author: Martin K. Petersen Date: Tue Apr 14 16:56:23 2015 -0400 sd: Unregister integrity profile [ Upstream commit e727c42bd55794765c460b7ac2b6cc969f2a9698 ] The new integrity code did not correctly unregister the profile for SD disks. Call blk_integrity_unregister() when we release a disk. Signed-off-by: Martin K. Petersen Reported-by: Sagi Grimberg Tested-by: Sagi Grimberg Cc: stable@vger.kernel.org # v3.17+ Signed-off-by: James Bottomley Signed-off-by: Sasha Levin commit 34c26c01be8837ae37030266383b17496a8e5bf6 Author: Ben Collins Date: Fri Apr 3 16:09:46 2015 +0000 Revert "dm crypt: fix deadlock when async crypto algorithm returns -EBUSY" [ Upstream commit c0403ec0bb5a8c5b267fb7e16021bec0b17e4964 ] This reverts Linux 4.1-rc1 commit 0618764cb25f6fa9fb31152995de42a8a0496475. The problem which that commit attempts to fix actually lies in the Freescale CAAM crypto driver not dm-crypt. dm-crypt uses CRYPTO_TFM_REQ_MAY_BACKLOG. This means the the crypto driver should internally backlog requests which arrive when the queue is full and process them later. Until the crypto hw's queue becomes full, the driver returns -EINPROGRESS. When the crypto hw's queue if full, the driver returns -EBUSY, and if CRYPTO_TFM_REQ_MAY_BACKLOG is set, is expected to backlog the request and process it when the hardware has queue space. At the point when the driver takes the request from the backlog and starts processing it, it calls the completion function with a status of -EINPROGRESS. The completion function is called (for a second time, in the case of backlogged requests) with a status/err of 0 when a request is done. Crypto drivers for hardware without hardware queueing use the helpers, crypto_init_queue(), crypto_enqueue_request(), crypto_dequeue_request() and crypto_get_backlog() helpers to implement this behaviour correctly, while others implement this behaviour without these helpers (ccp, for example). dm-crypt (before the patch that needs reverting) uses this API correctly. It queues up as many requests as the hw queues will allow (i.e. as long as it gets back -EINPROGRESS from the request function). Then, when it sees at least one backlogged request (gets -EBUSY), it waits till that backlogged request is handled (completion gets called with -EINPROGRESS), and then continues. The references to af_alg_wait_for_completion() and af_alg_complete() in that commit's commit message are irrelevant because those functions only handle one request at a time, unlink dm-crypt. The problem is that the Freescale CAAM driver, which that commit describes as having being tested with, fails to implement the backlogging behaviour correctly. In cam_jr_enqueue(), if the hardware queue is full, it simply returns -EBUSY without backlogging the request. What the observed deadlock was is not described in the commit message but it is obviously the wait_for_completion() in crypto_convert() where dm-crypto would wait for the completion being called with -EINPROGRESS in the case of backlogged requests. This completion will never be completed due to the bug in the CAAM driver. Commit 0618764cb25 incorrectly made dm-crypt wait for every request, even when the driver/hardware queues are not full, which means that dm-crypt will never see -EBUSY. This means that that commit will cause a performance regression on all crypto drivers which implement the API correctly. Revert it. Correct backlog handling should be implemented in the CAAM driver instead. Cc'ing stable purely because commit 0618764cb25 did. If for some reason a stable@ kernel did pick up commit 0618764cb25 it should get reverted. Signed-off-by: Rabin Vincent Reviewed-by: Horia Geanta Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 5ec6388f8e752c6f63caf859ad2be687668c3389 Author: Archit Taneja Date: Wed Mar 4 15:19:35 2015 +0530 clk: qcom: fix RCG M/N counter configuration [ Upstream commit 0b21503dbbfa669dbd847b33578d4041513cddb2 ] Currently, a RCG's M/N counter (used for fraction division) is set to either 'bypass' (counter disabled) or 'dual edge' (counter enabled) based on whether the corresponding rcg struct has a mnd field specified and a non-zero N. In the case where M and N are the same value, the M/N counter is still enabled by code even though no division takes place. Leaving the RCG in such a state can result in improper behavior. This was observed with the DSI pixel clock RCG when M and N were both set to 1. Add an additional check (M != N) to enable the M/N counter only when it's needed for fraction division. Signed-off-by: Archit Taneja Fixes: bcd61c0f535a (clk: qcom: Add support for root clock generators (RCGs)) Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit d415fc1d430b6f0a5c1011bf9830fcdb756a8718 Author: Stephen Boyd Date: Mon Feb 23 13:30:28 2015 -0800 clk: qcom: Fix i2c frequency table [ Upstream commit 0bf0ff82c34da02ee5795101b328225a2d519594 ] PXO is 25MHz, not 27MHz. Fix the table. Fixes: 24d8fba44af3 "clk: qcom: Add support for IPQ8064's global clock controller (GCC)" Signed-off-by: Stephen Boyd Reviewed-by: Andy Gross Tested-by: Andy Gross Signed-off-by: Michael Turquette Signed-off-by: Sasha Levin commit 06714fcfc019dfb9ff90cf5c1e450c54bf0a4ed3 Author: Thierry Reding Date: Mon Mar 23 10:57:46 2015 +0100 clk: tegra: Register the proper number of resets [ Upstream commit 5e43e259171e1eee8bc074d9c44be434e685087b ] The number of resets controls is 32 times the number of peripheral register banks rather than 32 times the number of clocks. This reduces (drastically) the number of reset controls registered from 10080 (315 clocks * 32) to 224 (6 peripheral register banks * 32). This also fixes a potential crash because trying to use any of the excess reset controls (224-10079) would have caused accesses beyond the array bounds of the peripheral register banks definition array. Cc: Peter De Schrijver Cc: Prashant Gaikwad Fixes: 6d5b988e7dc5 ("clk: tegra: implement a reset driver") Cc: stable@vger.kernel.org # 3.14+ Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 7b5b428d0b6a7ee1c81cf5929b44bd4354809234 Author: Bartlomiej Zolnierkiewicz Date: Fri Mar 27 17:27:10 2015 +0100 clk: samsung: exynos4: Disable ARMCLK down feature on Exynos4210 SoC [ Upstream commit 3a9e9cb65be84d6c64fbe9c69a73c15d59f29454 ] Commit 42773b28e71d ("clk: samsung: exynos4: Enable ARMCLK down feature") enabled ARMCLK down feature on all Exynos4 SoCs. Unfortunately on Exynos4210 SoC ARMCLK down feature causes a lockup when ondemand cpufreq governor is used. Fix it by limiting ARMCLK down feature to Exynos4x12 SoCs. This patch was tested on: - Exynos4210 SoC based Trats board - Exynos4210 SoC based Origen board - Exynos4412 SoC based Trats2 board - Exynos4412 SoC based Odroid-U3 board Cc: Daniel Drake Cc: Tomasz Figa Cc: Kukjin Kim Fixes: 42773b28e71d ("clk: samsung: exynos4: Enable ARMCLK down feature") Cc: # v3.17+ Reviewed-by: Krzysztof Kozlowski Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Michael Turquette Signed-off-by: Sasha Levin commit 30d458c451627b693bf69801d88a398bf6f725c5 Author: Gregory CLEMENT Date: Thu Apr 2 17:11:11 2015 +0200 gpio: mvebu: Fix mask/unmask managment per irq chip type [ Upstream commit 61819549f572edd7fce53f228c0d8420cdc85f71 ] 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 Cc: # v3.7 + Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 2f55b8d36f0cbd77575285389dd7a8fba4e031fb Author: Max Filippov Date: Fri Apr 3 09:56:21 2015 +0300 xtensa: ISS: fix locking in TAP network adapter [ Upstream commit 24e94454c8cb6a13634f5a2f5a01da53a546a58d ] - 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. Cc: Signed-off-by: Max Filippov Signed-off-by: Sasha Levin commit 0333a446432e2604be0d1d3fd34e766fd560011f Author: Max Filippov Date: Fri Feb 27 11:02:38 2015 +0300 xtensa: provide __NR_sync_file_range2 instead of __NR_sync_file_range [ Upstream commit 01e84c70fe40c8111f960987bcf7f931842e6d07 ] 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. Cc: stable@vger.kernel.org Signed-off-by: Max Filippov Signed-off-by: Sasha Levin commit 6a87cc5ee776ca7ba67554401622a8f23832b978 Author: Max Filippov Date: Fri Feb 27 06:28:00 2015 +0300 xtensa: xtfpga: fix hardware lockup caused by LCD driver [ Upstream commit 4949009eb8d40a441dcddcd96e101e77d31cf1b2 ] 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. Cc: stable@vger.kernel.org Signed-off-by: Max Filippov Signed-off-by: Sasha Levin commit fc69ac41da31ca159027b524592ede98c7dfc7e5 Author: Rafael J. Wysocki Date: Sat Apr 18 01:25:46 2015 +0200 ACPI / scan: Annotate physical_node_lock in acpi_scan_is_offline() [ Upstream commit 4c533c801d1c9b5c38458a0e7516e0cf50643782 ] acpi_scan_is_offline() may be called under the physical_node_lock lock of the given device object's parent, so prevent lockdep from complaining about that by annotating that instance with SINGLE_DEPTH_NESTING. Fixes: caa73ea158de (ACPI / hotplug / driver core: Handle containers in a special way) Reported-and-tested-by: Xie XiuQi Reviewed-by: Toshi Kani Cc: 3.14+ # 3.14+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 6fd1b9912fb3d74d928cbc8157800cf93e594724 Author: Octavian Purdila Date: Mon Apr 13 11:49:05 2015 +0800 ACPICA: Tables: Don't release ACPI_MTX_TABLES in acpi_tb_install_standard_table(). [ Upstream commit 77ddc2fe08329e375505bc36a3df3233fe57317b ] ACPICA commit c70434d4da13e65b6163c79a5aa16b40193631c7 ACPI_MTX_TABLES is acquired and released by the callers of acpi_tb_install_standard_table() so releasing it in the function itself is causing the following error in Linux kernel if the table is reloaded: ACPI Error: Mutex [0x2] is not acquired, cannot release (20141107/utmutex-321) Call Trace: [] dump_stack+0x4f/0x7b [] acpi_ut_release_mutex+0x47/0x67 [] acpi_load_table+0x73/0xcb Link: https://github.com/acpica/acpica/commit/c70434d4 Signed-off-by: Octavian Purdila Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Cc: 3.16+ # 3.16+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 9d7f2ea242011e249be852bbba178f9c5267a32e Author: Lv Zheng Date: Mon Apr 13 11:48:58 2015 +0800 ACPICA: Utilities: split IO address types from data type models. [ Upstream commit 2b8760100e1de69b6ff004c986328a82947db4ad ] 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 Cc: All applicable Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 28cafa985105b6ab92d7e158df46dbd1d134dca6 Author: Howard Mitchell Date: Thu Mar 19 12:08:30 2015 +0000 ASoC: pcm512x: Add 'Analogue' prefix to analogue volume controls [ Upstream commit 4d9b13c7cc803fbde59d7e998f7de2b9a2101c7e ] This is to ensure that 'alsactl restore' does not apply default initialisation as the chip reset defaults are preferred. Signed-off-by: Howard Mitchell Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit e31c834e3470ab14800d93a3ffdc5a0d59a95cdc Author: Manish Badarkhe Date: Thu Mar 26 15:38:25 2015 +0200 ASoC: davinci-evm: drop un-necessary remove function [ Upstream commit a57069e33fbc6625f39e1b09c88ea44629a35206 ] As davinci card gets registered using 'devm_' api there is no need to unregister the card in 'remove' function. Hence drop the 'remove' function. Fixes: ee2f615d6e59c (ASoC: davinci-evm: Add device tree binding) Signed-off-by: Manish Badarkhe Signed-off-by: Jyri Sarha Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 26ea595bd51cfc49b2cc4498a8c34008cc08d27b Author: Sergej Sawazki Date: Tue Mar 24 21:13:22 2015 +0100 ASoC: wm8741: Fix rates constraints values [ Upstream commit 8787041d9bb832b9449b1eb878cedcebce42c61a ] The WM8741 DAC supports the following typical audio sampling rates: 44.1kHz, 88.2kHz, 176.4kHz (eg: with a master clock of 22.5792MHz) 32kHz, 48kHz, 96kHz, 192kHz (eg: with a master clock of 24.576MHz) For the rates lists, we should use 82000 instead of 88235, 176400 instead of 1764000 and 192000 instead of 19200 (seems to be a typo). Signed-off-by: Sergej Sawazki Acked-by: Charles Keepax Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 8003c8f02736ffb3625f66c91a5ad1e5b4ead4a2 Author: Pascal Huerst Date: Thu Apr 2 10:17:40 2015 +0200 ASoC: cs4271: Increase delay time after reset [ Upstream commit 74ff960222d90999508b4ba0d3449f796695b6d5 ] The delay time after a reset in the codec probe callback was too short, and did not work on certain hw because the codec needs more time to power on. This increases the delay time from 1us to 1ms. Signed-off-by: Pascal Huerst Acked-by: Brian Austin Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 11a0c1eff6269d98bf31b6bb10a7fe4c3d4244d9 Author: Michael Ellerman Date: Fri Apr 3 14:11:54 2015 +1100 powerpc/cell: Fix cell iommu after it_page_shift changes [ Upstream commit 7261b956b276aa97fbf60d00f1d7717d2ea6ee78 ] The patch to add it_page_shift incorrectly changed the increment of uaddr to use it_page_shift, rather then (1 << it_page_shift). This broke booting on at least some Cell blades, as the iommu was basically non-functional. Fixes: 3a553170d35d ("powerpc/iommu: Add it_page_shift field to determine iommu page size") Signed-off-by: Michael Ellerman Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 74fb2a59b1b38109534ee73be457def9791124a3 Author: Michael Ellerman Date: Fri Apr 3 14:11:53 2015 +1100 powerpc/cell: Fix crash in iic_setup_cpu() after per_cpu changes [ Upstream commit b0dd00addc5035f87ec9c5820dacc1ebc7fcb3e6 ] The conversion from __get_cpu_var() to this_cpu_ptr() in iic_setup_cpu() is wrong. It causes an oops at boot. We need the per-cpu address of struct cpu_iic, not cpu_iic.regs->prio. Sparse noticed this, because we pass a non-iomem pointer to out_be64(), but we obviously don't check the sparse results often enough. Fixes: 69111bac42f5 ("powerpc: Replace __get_cpu_var uses") Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 55b47182b6daf9f9ab6b02de8915524373747ce4 Author: Dave Olson Date: Thu Apr 2 21:28:45 2015 -0700 powerpc: Fix missing L2 cache size in /sys/devices/system/cpu [ Upstream commit f7e9e358362557c3aa2c1ec47490f29fe880a09e ] 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: Sasha Levin commit 945818207f50087eef7909ab56fd316a27c9d349 Author: Gavin Shan Date: Fri Mar 27 11:29:00 2015 +1100 powerpc/powernv: Don't map M64 segments using M32DT [ Upstream commit 027fa02f84e851e21daffdf8900d6117071890f8 ] If M64 has been supported, the prefetchable 64-bits memory resources shouldn't be mapped to the corresponding PE# via M32DT. Unfortunately, we're doing that in pnv_ioda_setup_pe_seg() wrongly. The issue was introduced by commit 262af55 ("powerpc/powernv: Enable M64 aperatus for PHB3"). The patch fixes the issue by simply skipping M64 resources when updating to M32DT. Cc: # v3.17+ Signed-off-by: Gavin Shan Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Sasha Levin commit 132a0d3a3c998e6781b9571afc19d467af28ed2b Author: Alexander Ploumistos Date: Fri Feb 13 21:05:11 2015 +0200 Bluetooth: ath3k: Add support Atheros AR5B195 combo Mini PCIe card [ Upstream commit 2eeff0b4317a02f0e281df891d990194f0737aae ] 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 Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit eb2844f82f2aa0230a9f0dd10ad3617f71e0230c Author: Sagi Grimberg Date: Sun Mar 29 15:52:03 2015 +0300 iser-target: Fix session hang in case of an rdma read DIF error [ Upstream commit 364189f0ada5478e4faf8a552d6071a650d757cd ] This hang was a result of a missing command put when a DIF error occurred during a rdma read (and we sent an CHECK_CONDITION error without passing it to the backend). Signed-off-by: Sagi Grimberg Cc: # v3.14+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 5e64371411f83fdf6626162b28f07aaf29ee48cc Author: Akinobu Mita Date: Mon Apr 13 23:21:57 2015 +0900 target/file: Fix SG table for prot_buf initialization [ Upstream commit c836777830428372074d5129ac513e1472c99791 ] In fd_do_prot_rw(), it allocates prot_buf which is used to copy from se_cmd->t_prot_sg by sbc_dif_copy_prot(). The SG table for prot_buf is also initialized by allocating 'se_cmd->t_prot_nents' entries of scatterlist and setting the data length of each entry to PAGE_SIZE at most. However if se_cmd->t_prot_sg contains a clustered entry (i.e. sg->length > PAGE_SIZE), the SG table for prot_buf can't be initialized correctly and sbc_dif_copy_prot() can't copy to prot_buf. (This actually happened with TCM loopback fabric module) As prot_buf is allocated by kzalloc() and it's physically contiguous, we only need a single scatterlist entry. Signed-off-by: Akinobu Mita Cc: Sagi Grimberg Cc: "Martin K. Petersen" Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Cc: # v3.14+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 606105af942168c1ba9424d0c9378a23ceab52f3 Author: Akinobu Mita Date: Mon Apr 13 23:21:58 2015 +0900 target/file: Fix UNMAP with DIF protection support [ Upstream commit 64d240b721b21e266ffde645ec965c3b6d1c551f ] When UNMAP command is issued with DIF protection support enabled, the protection info for the unmapped region is remain unchanged. So READ command for the region causes data integrity failure. This fixes it by invalidating protection info for the unmapped region by filling with 0xff pattern. This change also adds helper function fd_do_prot_fill() in order to reduce code duplication with existing fd_format_prot(). Signed-off-by: Akinobu Mita Reviewed-by: Sagi Grimberg Reviewed-by: "Martin K. Petersen" Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Cc: # v3.14+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit cc75f2514d4f9f4bac0a59f855d914ac2957a623 Author: Akinobu Mita Date: Mon Apr 13 23:21:56 2015 +0900 target/file: Fix BUG() when CONFIG_DEBUG_SG=y and DIF protection enabled [ Upstream commit 38da0f49e8aa1649af397d53f88e163d0e60c058 ] When CONFIG_DEBUG_SG=y and DIF protection support enabled, kernel BUG()s are triggered due to the following two issues: 1) prot_sg is not initialized by sg_init_table(). When CONFIG_DEBUG_SG=y, scatterlist helpers check sg entry has a correct magic value. 2) vmalloc'ed buffer is passed to sg_set_buf(). sg_set_buf() uses virt_to_page() to convert virtual address to struct page, but it doesn't work with vmalloc address. vmalloc_to_page() should be used instead. As prot_buf isn't usually too large, so fix it by allocating prot_buf by kmalloc instead of vmalloc. Signed-off-by: Akinobu Mita Cc: Sagi Grimberg Cc: "Martin K. Petersen" Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Cc: # v3.14+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit d71c65f44eb154106c2fae897fd58f1197c4a09c Author: Nicholas Bellinger Date: Tue Apr 7 21:53:27 2015 +0000 target: Fix COMPARE_AND_WRITE with SG_TO_MEM_NOALLOC handling [ Upstream commit c8e639852ad720499912acedfd6b072325fd2807 ] 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 Cc: # v3.12+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 867af24da06080ffb12a2d0614e046bce917012e Author: K. Y. Srinivasan Date: Fri Mar 27 00:27:18 2015 -0700 scsi: storvsc: Fix a bug in copy_from_bounce_buffer() [ Upstream commit 8de580742fee8bc34d116f57a20b22b9a5f08403 ] 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 Cc: Signed-off-by: James Bottomley Signed-off-by: Sasha Levin commit 054cf47d81e14bb77da7cc6eb72f317ac70440ed Author: Brian Norris Date: Sat Feb 28 02:23:28 2015 -0800 UBI: fix check for "too many bytes" [ Upstream commit 299d0c5b27346a77a0777c993372bf8777d4f2e5 ] 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 Cc: stable Signed-off-by: Brian Norris [rw: Fixed comparison] Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 256f3466548da7c3761e246dd5e6a0776c01df2a Author: Brian Norris Date: Sat Feb 28 02:23:27 2015 -0800 UBI: initialize LEB number variable [ Upstream commit f16db8071ce18819fbd705ddcc91c6f392fb61f8 ] 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 Cc: stable Signed-off-by: Brian Norris Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit c2ffa098d6f9d427269912e33beecb00c57d9460 Author: Brian Norris Date: Sat Feb 28 02:23:26 2015 -0800 UBI: fix out of bounds write [ Upstream commit d74adbdb9abf0d2506a6c4afa534d894f28b763f ] If aeb->len >= vol->reserved_pebs, we should not be writing aeb into the PEB->LEB mapping. Caught by Coverity, CID #711212. Cc: stable Signed-off-by: Brian Norris Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit cdf5f4433cfdbf2aaf3dabbeaa392326895149fe Author: Brian Norris Date: Sat Feb 28 02:23:25 2015 -0800 UBI: account for bitflips in both the VID header and data [ Upstream commit 8eef7d70f7c6772c3490f410ee2bceab3b543fa1 ] 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 Cc: stable Signed-off-by: Brian Norris Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 1a18b9807e50c4e244df9209b3053ac740a6551d 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 [ Upstream commit f82263c6989c31ae9b94cecddffb29dcbec38710 ] 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: Sasha Levin commit 06676db706e1f507862e1a84ffad394d5e1ec3c7 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 [ Upstream commit c5e691928bf166ac03430e957038b60adba3cf6c ] 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 Cc: stable@vger.kernel.org # 3.12+ Link: http://lkml.kernel.org/r/20150324135923.461431960@goodmis.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit ff342613d0b725883aae0bbde834ba5aad99973c Author: Anton Blanchard Date: Tue Apr 14 07:51:03 2015 +1000 powerpc/perf: Cap 64bit userspace backtraces to PERF_MAX_STACK_DEPTH [ Upstream commit 9a5cbce421a283e6aea3c4007f141735bf9da8c3 ] We cap 32bit userspace backtraces to PERF_MAX_STACK_DEPTH (currently 127), but we forgot to do the same for 64bit backtraces. Cc: stable@vger.kernel.org Signed-off-by: Anton Blanchard Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 877f68ecbdb55e5c1dbae420a2850fd2a0487032 Author: Vinson Lee Date: Mon Mar 23 12:09:16 2015 -0700 perf tools: Work around lack of sched_getcpu in glibc < 2.6. [ Upstream commit e1e455f4f4d35850c30235747620d0d078fe9f64 ] This patch fixes this build error with glibc < 2.6. CC util/cloexec.o cc1: warnings being treated as errors util/cloexec.c: In function ‘perf_flag_probe’: util/cloexec.c:24: error: implicit declaration of function ‘sched_getcpu’ util/cloexec.c:24: error: nested extern declaration of ‘sched_getcpu’ make: *** [util/cloexec.o] Error 1 Signed-off-by: Vinson Lee Acked-by: Jiri Olsa Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Masami Hiramatsu Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Yann Droneaud Cc: stable@vger.kernel.org # 3.18+ Link: http://lkml.kernel.org/r/1427137761-16119-1-git-send-email-vlee@twopensource.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 7b6f0b0a71f6cb837c62763889f28581e55e43f5 Author: Vinson Lee Date: Mon Feb 9 16:29:37 2015 -0800 perf symbols: Define STT_GNU_IFUNC for glibc 2.9 and older. [ Upstream commit 4e31050f482c02c822b150d71cf1ea5be7c9d6e4 ] The token STT_GNU_IFUNC is not available with glibc 2.9 and older. Define this token if it is not already defined. This patch fixes this build errors with older versions of glibc. CC util/symbol-elf.o util/symbol-elf.c: In function ‘elf_sym__is_function’: util/symbol-elf.c:75: error: ‘STT_GNU_IFUNC’ undeclared (first use in this function) util/symbol-elf.c:75: error: (Each undeclared identifier is reported only once util/symbol-elf.c:75: error: for each function it appears in.) make: *** [util/symbol-elf.o] Error 1 Signed-off-by: Vinson Lee Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Anton Blanchard Cc: Avi Kivity Cc: Jiri Olsa Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Waiman Long Cc: stable@vger.kernel.org # 3.17+ Link: http://lkml.kernel.org/r/1423528286-13630-1-git-send-email-vlee@twopensource.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 1c1cf82e193a887f37672b0d7b2657c76613ee16 Author: Eric W. Biederman Date: Wed Dec 24 07:35:10 2014 -0600 mnt: Don't propagate umounts in __detach_mounts [ Upstream commit 8318e667f176f7ea34451a1a530634e293f216ac ] Invoking mount propagation from __detach_mounts is inefficient and wrong. It is inefficient because __detach_mounts already walks the list of mounts that where something needs to be done, and mount propagation walks some subset of those mounts again. It is actively wrong because if the dentry that is passed to __detach_mounts is not part of the path to a mount that mount should not be affected. change_mnt_propagation(p,MS_PRIVATE) modifies the mount propagation tree of a master mount so it's slaves are connected to another master if possible. Which means even removing a mount from the middle of a mount tree with __detach_mounts will not deprive any mount propagated mount events. Cc: stable@vger.kernel.org Signed-off-by: "Eric W. Biederman" Signed-off-by: Sasha Levin commit 6b1353cb2664c93997561fa4f46f055da51f5ee7 Author: Eric W. Biederman Date: Wed Dec 24 07:20:01 2014 -0600 mnt: Improve the umount_tree flags [ Upstream commit e819f152104c9f7c9fe50e1aecce6f5d4bf06d65 ] - Remove the unneeded declaration from pnode.h - Mark umount_tree static as it has no callers outside of namespace.c - Define an enumeration of umount_tree's flags. - Pass umount_tree's flags in by name This removes the magic numbers 0, 1 and 2 making the code a little clearer and makes it possible for there to be lazy unmounts that don't propagate. Which is what __detach_mounts actually wants for example. Cc: stable@vger.kernel.org Signed-off-by: "Eric W. Biederman" Signed-off-by: Sasha Levin commit 01acccfad385b79863b41177bdbf30e3a0ccb033 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 [ Upstream commit e12fb97222fc41e8442896934f76d39ef99b590a ] 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 Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 25a1a0e4bf5b1fb956ef1312aba1c48fabf65f34 Author: Marek Vasut Date: Thu Mar 26 02:16:06 2015 +0100 rtlwifi: rtl8192cu: Add new device ID [ Upstream commit 9374e7d2fdcad3c36dafc8d3effd554bc702c4b6 ] 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: Sasha Levin commit 036452652b0251111b357dfdca4a25dbd148b63c Author: Larry Finger Date: Mon Mar 23 18:14:10 2015 -0500 rtlwifi: rtl8192cu: Add new USB ID [ Upstream commit 2f92b314f4daff2117847ac5343c54d3d041bf78 ] USB ID 2001:330d is used for a D-Link DWA-131. Signed-off-by: Larry Finger Cc: Stable Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit e2914f4a8c259431cdeea617da156d2bd1dbe8ab Author: Christophe Ricard Date: Tue Mar 31 08:02:15 2015 +0200 NFC: st21nfcb: Retry i2c_master_send if it returns a negative value [ Upstream commit d4a41d10b2cb5890aeda6b2912973b2a754b05b1 ] i2c_master_send may return many negative values different than -EREMOTEIO. In case an i2c transaction is NACK'ed, on raspberry pi B+ kernel 3.18, -EIO is generated instead. Cc: stable@vger.kernel.org Signed-off-by: Christophe Ricard Signed-off-by: Samuel Ortiz Signed-off-by: Sasha Levin commit 016177a2f369b1c4fe6db353c7ce8918a5fc462c Author: Oleg Nesterov Date: Thu Apr 16 12:47:29 2015 -0700 ptrace: fix race between ptrace_resume() and wait_task_stopped() [ Upstream commit b72c186999e689cb0b055ab1c7b3cd8fffbeb5ed ] 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 Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 954f17f76c942d6fda33d4945bba66178514538d Author: Michael Davidson Date: Tue Apr 14 15:47:38 2015 -0700 fs/binfmt_elf.c: fix bug in loading of PIE binaries [ Upstream commit a87938b2e246b81b4fb713edb371a9fa3c5c3c86 ] 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 Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit d37d990e811e73b5504f55a11446f28cb940dc3b Author: Ulrik De Bie Date: Mon Apr 6 15:35:38 2015 -0700 Input: elantech - fix absolute mode setting on some ASUS laptops [ Upstream commit bd884149aca61de269fd9bad83fe2a4232ffab21 ] 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 Cc: stable@vger.kernel.org Reported-and-tested-by: George Moutsopoulos Signed-off-by: Ulrik De Bie Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit f42c7734c0a3c2156298adeea5c1cdaa037d6889 Author: Kailang Yang Date: Thu Apr 23 15:10:53 2015 +0800 ALSA: hda/realtek - Fix Headphone Mic doesn't recording for ALC256 [ Upstream commit d32b66668c702aed0e330dc5ca186afbadcdacf8 ] Switch default pcbeep path to Line in path. Signed-off-by: Kailang Yang Tested-by: Hui Wang Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit bf78e00928b70a304d4e752ba62d8c19aa68b5c0 Author: David Henningsson Date: Tue Apr 21 10:48:46 2015 +0200 ALSA: hda - fix "num_steps = 0" error on ALC256 [ Upstream commit 7d1b6e29327428993ba568bdd8c66734070f45e0 ] The ALC256 does not have a mixer nid at 0x0b, and there's no loopback path (the output pins are directly connected to the DACs). This commit fixes an "num_steps = 0 for NID=0xb (ctl = Beep Playback Volume)" error (and as a result, problems with amixer/alsamixer). If there's pcbeep functionality, it certainly isn't controlled by setting an amp on 0x0b, so disable beep functionality (at least for now). Cc: stable@vger.kernel.org BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1446517 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 5f54521eb966f6f36edae9fb9bceb3053f3b624d Author: Jo-Philipp Wich Date: Mon Apr 13 12:47:26 2015 +0200 ALSA: hda/realtek - Enable the ALC292 dock fixup on the Thinkpad T450 [ Upstream commit f2aa111041ce36b94e651d882458dea502e76721 ] The Lenovo Thinkpad T450 requires the ALC292_FIXUP_TPT440_DOCK as well in order to get working sound output on the docking stations headphone jack. Patch tested on a Thinkpad T450 (20BVCTO1WW) using kernel 4.0-rc7 in conjunction with a ThinkPad Ultradock. Signed-off-by: Jo-Philipp Wich Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f44e7673bd8a09d4d6d87bbc85afb964d44602dd Author: Michael Gernoth Date: Thu Apr 9 23:42:15 2015 +0200 ALSA: emu10k1: don't deadlock in proc-functions [ Upstream commit 91bf0c2dcb935a87e5c0795f5047456b965fd143 ] 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 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ef1eaaef22b0b76506aeeb7ae233d376fab8f817 Author: Yves-Alexis Perez Date: Sat Apr 11 09:31:35 2015 +0200 ALSA: hda - Add dock support for ThinkPad X250 (17aa:2226) [ Upstream commit c0278669fb61596cc1a10ab8686d27c37269c37b ] This model uses the same dock port as the previous generation. Signed-off-by: Yves-Alexis Perez Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ae74ea64ccdb8b99ee2618b58020263d5b1d9b22 Author: Boris Brezillon Date: Sun Mar 29 03:45:33 2015 +0200 clk: at91: usb: propagate rate modification to the parent clk [ Upstream commit 4591243102faa8de92da320edea47219901461e9 ] The at91sam9n12 and at91sam9x5 usb clocks do not propagate rate modification requests to their parents. This causes a bug when the PLLB is left uninitialized by the bootloader (PLL multiplier set to 0, or in other words, PLL rate = 0 Hz). Implement the determinate_rate method and propagate the change rate request to the parent clk. Cc: # v3.14+ Signed-off-by: Boris Brezillon Reported-by: Bo Shen Tested-by: Bo Shen Signed-off-by: Michael Turquette Signed-off-by: Sasha Levin commit e04bccabf7fb9c1315bf8932558f58288a5e84d9 Author: Felipe Balbi Date: Fri Feb 13 15:38:33 2015 -0600 usb: core: hub: use new USB_RESUME_TIMEOUT [ Upstream commit bbc78c07a51f6fd29c227b1220a9016e585358ba ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: # v3.10+ Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 47e82783bff1f6666e962e0b709162dfd5395a29 Author: Felipe Balbi Date: Fri Feb 13 15:00:38 2015 -0600 usb: host: sl811: use new USB_RESUME_TIMEOUT [ Upstream commit 08debfb13b199716da6153940c31968c556b195d ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: # v3.10+ Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 4062a4ead143d7234c28ef096ce5613a58c94b2e Author: Felipe Balbi Date: Fri Feb 13 14:42:25 2015 -0600 usb: host: ehci: use new USB_RESUME_TIMEOUT [ Upstream commit ea16328f80ca8d74434352157f37ef60e2f55ce2 ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: # v3.10+ Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 9f3220454efcd036d876dfdbcc14e90c45632b45 Author: Felipe Balbi Date: Fri Feb 13 14:39:13 2015 -0600 usb: host: xhci: use new USB_RESUME_TIMEOUT [ Upstream commit b9e451885deb6262dbaf5cd14aa77d192d9ac759 ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: # v3.10+ Acked-by: Mathias Nyman Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit f1106b21fb9b0331a575f9386b80a7acb5c817c7 Author: Felipe Balbi Date: Fri Feb 13 14:50:10 2015 -0600 usb: host: isp116x: use new USB_RESUME_TIMEOUT [ Upstream commit 8c0ae6574ccfd3d619876a65829aad74c9d22ba5 ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: # v3.10+ Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 9e26387b15dca1329ed5be1c2ad7d478231753b6 Author: Felipe Balbi Date: Fri Feb 13 14:58:53 2015 -0600 usb: host: r8a66597: use new USB_RESUME_TIMEOUT [ Upstream commit 7a606ac29752a3e571b83f9b3fceb1eaa1d37781 ] 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. Cc: # v3.10+ Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 90c918c9936084c405727ec682928073d4cc4e1b Author: Felipe Balbi Date: Fri Feb 13 14:54:38 2015 -0600 usb: host: fotg210: use new USB_RESUME_TIMEOUT [ Upstream commit 7e136bb71a08e8b8be3bc492f041d9b0bea3856d ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: # v3.10+ Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 07431f53341fe6769800b499fa85c3215beb8449 Author: Felipe Balbi Date: Fri Feb 13 14:44:17 2015 -0600 usb: host: uhci: use new USB_RESUME_TIMEOUT [ Upstream commit b8fb6f79f76f478acbbffccc966daa878f172a0a ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: # v3.10+ Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 878b8fafadd0b86a5f4bed41b5bd45767f109c73 Author: Felipe Balbi Date: Fri Feb 13 14:55:34 2015 -0600 usb: host: fusbh200: use new USB_RESUME_TIMEOUT [ Upstream commit 595227db1f2d98bfc33f02a55842f268e12b247d ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: # v3.10+ Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 250e891f8444833fce3078967fbd3270b7dae8ff Author: Felipe Balbi Date: Fri Feb 13 14:57:54 2015 -0600 usb: host: oxu210hp: use new USB_RESUME_TIMEOUT [ Upstream commit 84c0d178eb9f3a3ae4d63dc97a440266cf17f7f5 ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: # v3.10+ Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit be6bc8bf1c537d94bbe95b1cdfa8cc5066e00725 Author: Felipe Balbi Date: Fri Feb 13 14:46:27 2015 -0600 usb: musb: use new USB_RESUME_TIMEOUT [ Upstream commit 309be239369609929d5d3833ee043f7c5afc95d1 ] 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 Cc: # v3.10+ Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit a7d51bcea4a77775f6730ba65a0e725367b6d23b Author: Felipe Balbi Date: Fri Feb 13 14:34:25 2015 -0600 usb: define a generic USB_RESUME_TIMEOUT macro [ Upstream commit 62f0342de1f012f3e90607d39e20fce811391169 ] 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. Cc: # v3.10+ Acked-by: Greg Kroah-Hartman Acked-by: Peter Chen Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 8627988cfc62ec0625042b74ccb2b670ab4c9cc2 Author: Axel Lin Date: Thu Mar 12 09:15:28 2015 +0800 usb: phy: Find the right match in devm_usb_phy_match [ Upstream commit 869aee0f31429fa9d94d5aef539602b73ae0cf4b ] 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 Cc: # v3.6+ Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit a7d37b3c148e374c5117ff4e757b82fac2f7be03 Author: Felipe Balbi Date: Mon Dec 30 12:33:53 2013 -0600 usb: musb: core: fix TX/RX endpoint order [ Upstream commit e3c93e1a3f35be4cf1493d3ccfb0c6d9209e4922 ] As per Mentor Graphics' documentation, we should always handle TX endpoints before RX endpoints. This patch fixes that error while also updating some hard-to-read comments which were scattered around musb_interrupt(). This patch should be backported as far back as possible since this error has been in the driver since it's conception. Cc: Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit e9db32eeb4142185db52c9992989df1fb7342ead Author: Sebastian Hesselbarth Date: Tue Feb 17 19:52:04 2015 +0100 ARM: dts: dove: Fix uart[23] reg property [ Upstream commit a74cd13b807029397f7232449df929bac11fb228 ] Fix Dove's register addresses of uart2 and uart3 nodes that seem to be broken since ages due to a copy-and-paste error. Cc: # 3.7+ Signed-off-by: Sebastian Hesselbarth Acked-by: Gregory CLEMENT Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit ed4210b61a802fd728ffcbacfc77241e6ee7a36a Author: Charles Keepax Date: Fri Mar 27 01:58:08 2015 +0900 ARM: S3C64XX: Use fixed IRQ bases to avoid conflicts on Cragganmore [ Upstream commit 4e330ae4ab2915444f1e6dca1358a910aa259362 ] 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 Cc: Signed-off-by: Kukjin Kim Signed-off-by: Sasha Levin commit 5ec2065d7946354b5a32133a2d4e432bb3d5d315 Author: Gregory CLEMENT Date: Fri Jan 30 12:34:25 2015 +0100 ARM: mvebu: Disable CPU Idle on Armada 38x [ Upstream commit 548ae94c1cc7fc120848757249b9a542b1080ffb ] On Armada 38x SoCs, under heavy I/O load, the system hangs when CPU Idle is enabled. Waiting for a solution to this issue, this patch disables the CPU Idle support for this SoC. As CPU Hot plug support also uses some of the CPU Idle functions it is also affected by the same issue. This patch disables it also for the Armada 38x SoCs. Signed-off-by: Gregory CLEMENT Tested-by: Thomas Petazzoni Cc: # v3.17 + Signed-off-by: Sasha Levin commit 870ee204898df165e8b5d750ae82e07bed1c13f1 Author: Andrey Ryabinin Date: Fri Mar 20 15:42:27 2015 +0100 ARM: 8320/1: fix integer overflow in ELF_ET_DYN_BASE [ Upstream commit 8defb3367fcd19d1af64c07792aade0747b54e0f ] 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 Cc: stable@vger.kernel.org Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 3e98276b95ed5202e7eaffeaa546f77c8eb10ccc Author: Russell King Date: Wed Apr 1 16:20:39 2015 +0100 ARM: fix broken hibernation [ Upstream commit 767bf7e7a1e82a81c59778348d156993d0a6175d ] Normally, when a CPU wants to clear a cache line to zero in the external L2 cache, it would generate bus cycles to write each word as it would do with any other data access. However, a Cortex A9 connected to a L2C-310 has a specific feature where the CPU can detect this operation, and signal that it wants to zero an entire cache line. This feature, known as Full Line of Zeros (FLZ), involves a non-standard AXI signalling mechanism which only the L2C-310 can properly interpret. There are separate enable bits in both the L2C-310 and the Cortex A9 - the L2C-310 needs to be enabled and have the FLZ enable bit set in the auxiliary control register before the Cortex A9 has this feature enabled. Unfortunately, the suspend code was not respecting this - it's not obvious from the code: swsusp_arch_suspend() cpu_suspend() /* saves the Cortex A9 auxiliary control register */ arch_save_image() soft_restart() /* turns off FLZ in Cortex A9, and disables L2C */ cpu_resume() /* restores the Cortex A9 registers, inc auxcr */ At this point, we end up with the L2C disabled, but the Cortex A9 with FLZ enabled - which means any memset() or zeroing of a full cache line will fail to take effect. A similar issue exists in the resume path, but it's slightly more complex: swsusp_arch_suspend() cpu_suspend() /* saves the Cortex A9 auxiliary control register */ arch_save_image() /* image with A9 auxcr saved */ ... swsusp_arch_resume() call_with_stack() arch_restore_image() /* restores image with A9 auxcr saved above */ soft_restart() /* turns off FLZ in Cortex A9, and disables L2C */ cpu_resume() /* restores the Cortex A9 registers, inc auxcr */ Again, here we end up with the L2C disabled, but Cortex A9 FLZ enabled. There's no need to turn off the L2C in either of these two paths; there are benefits from not doing so - for example, the page copies will be faster with the L2C enabled. Hence, fix this by providing a variant of soft_restart() which can be used without turning the L2 cache controller off, and use it in both of these paths to keep the L2C enabled across the respective resume transitions. Fixes: 8ef418c7178f ("ARM: l2c: trial at enabling some Cortex-A9 optimisations") Reported-by: Sean Cross Tested-by: Sean Cross Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 36af79ba9dff8cd9eb0ab7ce9f4b808f2247570e Author: Andrew Elble Date: Mon Feb 23 08:51:24 2015 -0500 NFS: fix BUG() crash in notify_change() with patch to chown_common() [ Upstream commit c1b8940b42bb6487b10f2267a96b486276ce9ff7 ] We have observed a BUG() crash in fs/attr.c:notify_change(). The crash occurs during an rsync into a filesystem that is exported via NFS. 1.) fs/attr.c:notify_change() modifies the caller's version of attr. 2.) 6de0ec00ba8d ("VFS: make notify_change pass ATTR_KILL_S*ID to setattr operations") introduced a BUG() restriction such that "no function will ever call notify_change() with both ATTR_MODE and ATTR_KILL_S*ID set". Under some circumstances though, it will have assisted in setting the caller's version of attr to this very combination. 3.) 27ac0ffeac80 ("locks: break delegations on any attribute modification") introduced code to handle breaking delegations. This can result in notify_change() being re-called. attr _must_ be explicitly reset to avoid triggering the BUG() established in #2. 4.) The path that that triggers this is via fs/open.c:chmod_common(). The combination of attr flags set here and in the first call to notify_change() along with a later failed break_deleg_wait() results in notify_change() being called again via retry_deleg without resetting attr. Solution is to move retry_deleg in chmod_common() a bit further up to ensure attr is completely reset. There are other places where this seemingly could occur, such as fs/utimes.c:utimes_common(), but the attr flags are not initially set in such a way to trigger this. Fixes: 27ac0ffeac80 ("locks: break delegations on any attribute modification") Reported-by: Eric Meddaugh Tested-by: Eric Meddaugh Signed-off-by: Andrew Elble Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 323548013942a80edf7b20ddca5aa3083f964894 Author: Krzysztof Kozlowski Date: Fri Feb 20 14:32:24 2015 +0100 power_supply: ipaq_micro_battery: Check return values in probe [ Upstream commit a2c1d531854c4319610f1d83351213b47a633969 ] The return values of create_singlethread_workqueue() and power_supply_register() calls were not checked and even on error probe() function returned 0. 1. If allocation of workqueue failed (returning NULL) then further accesses could lead to NULL pointer dereference. The queue_delayed_work() expects workqueue to be non-NULL. 2. If registration of power supply 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: 00a588f9d27f ("power: add driver for battery reading on iPaq h3xxx") Cc: Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit d81418c1cb812707533730b05afe30753e2f1922 Author: Krzysztof Kozlowski Date: Fri Feb 20 14:32:23 2015 +0100 power_supply: ipaq_micro_battery: Fix leaking workqueue [ Upstream commit f852ec461e24504690445e7d281cbe806df5ccef ] Driver allocates singlethread workqueue in probe but it is not destroyed during removal. Signed-off-by: Krzysztof Kozlowski Fixes: 00a588f9d27f ("power: add driver for battery reading on iPaq h3xxx") Cc: Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 58aad4043bc63cceb8edd93769b8733f92f02fe6 Author: Krzysztof Kozlowski Date: Fri Feb 20 14:32:25 2015 +0100 power_supply: lp8788-charger: Fix leaked power supply on probe fail [ Upstream commit a7117f81e8391e035c49b3440792f7e6cea28173 ] 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") Cc: Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 6bc373ff486aa65f3620bd9253e0b75d83f26150 Author: Krzysztof Kozlowski Date: Fri Feb 20 14:32:22 2015 +0100 power_supply: twl4030_madc: Check return value of power_supply_register [ Upstream commit 68c3ed6fa7e0d69529ced772d650ab128916a81d ] 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.") Cc: Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 6ec5fc3a8308e298002f81b37f605ff10669a8f9 Author: Steven Rostedt Date: Tue Mar 17 10:40:38 2015 -0400 ring-buffer: Replace this_cpu_*() with __this_cpu_*() [ Upstream commit 80a9b64e2c156b6523e7a01f2ba6e5d86e722814 ] 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 Cc: stable@vger.kernel.org Acked-by: Christoph Lameter Reported-by: Uwe Kleine-Koenig Tested-by: Uwe Kleine-Koenig Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit ebc00a2053b4b92a32deaf7a0221bf510abbe50e Author: Krzysztof Kozlowski Date: Thu Mar 12 08:44:00 2015 +0100 compal-laptop: Check return value of power_supply_register [ Upstream commit 1915a718b1872edffcb13e5436a9f7302d3d36f0 ] 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") Cc: Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 29037bcf2d8bf828d253a2e31339c3c04a172a9c Author: Krzysztof Kozlowski Date: Thu Mar 12 08:43:59 2015 +0100 compal-laptop: Fix leaking hwmon device [ Upstream commit ad774702f1705c04e5fa492b793d8d477a504fa6 ] The commit c2be45f09bb0 ("compal-laptop: Use devm_hwmon_device_register_with_groups") wanted to change the registering of hwmon device to resource-managed version. It mostly did it except the main thing - it forgot to use devm-like function so the hwmon device leaked after device removal or probe failure. Signed-off-by: Krzysztof Kozlowski Fixes: c2be45f09bb0 ("compal-laptop: Use devm_hwmon_device_register_with_groups") Cc: Acked-by: Guenter Roeck Acked-by: Darren Hart Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 502e02465516f6987e89b564051d82a9b6498377 Author: Ian Abbott Date: Mon Mar 23 17:50:27 2015 +0000 spi: spidev: fix possible arithmetic overflow for multi-transfer message [ Upstream commit f20fbaad7620af2df36a1f9d1c9ecf48ead5b747 ] `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: Sasha Levin commit 2ed82e9e1784714dd49b090154f136a393cc7837 Author: Lucas Stach Date: Wed Apr 1 10:46:15 2015 +0200 spi: imx: read back the RX/TX watermark levels earlier [ Upstream commit f511ab09dfb0fe7b2335eccac51ff9f001a32e4a ] They are used to decide if the controller can do DMA on a buffer of a specific length and thus are needed before any transfer is attempted. This fixes a memory leak where the SPI core uses the drivers can_dma() callback to determine if a buffer needs to be mapped. As the watermark levels aren't correct at that point the driver falsely claims to be able to DMA the buffer when it fact it isn't. After the transfer has been done the core uses the same callback to determine if it needs to unmap the buffers. As the driver now correctly claims to not being able to DMA the buffer the core doesn't attempt to unmap the buffer which leaves the SGT leaking. Fixes: f62caccd12c17e4 (spi: spi-imx: add DMA support) Signed-off-by: Lucas Stach Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 7c06756c1d6a373c9dec8123ac34854d0547e468 Author: Chen-Yu Tsai Date: Tue Mar 3 09:44:40 2015 +0800 mmc: sunxi: Use devm_reset_control_get_optional() for reset control [ Upstream commit 9e71c589e44ddf2b86f361c81e360c6b0d0354b1 ] The reset control for the sunxi mmc controller is optional. Some newer platforms (sun6i, sun8i, sun9i) have it, while older ones (sun4i, sun5i, sun7i) don't. Use the properly stubbed _optional version so the driver does not fail to compile when RESET_CONTROLLER=n. This patch also adds a check for deferred probing on the reset control. Signed-off-by: Chen-Yu Tsai Cc: # 3.16+ Acked-by: David Lanzendörfer Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit cdc0cf5f1f6a30d20c2d543f569b8dbefff518e8 Author: Oliver Neukum Date: Fri Mar 20 14:29:34 2015 +0100 cdc-wdm: fix endianness bug in debug statements [ Upstream commit 323ece54e0761198946ecd0c2091f1d2bfdfcb64 ] Values directly from descriptors given in debug statements must be converted to native endianness. Signed-off-by: Oliver Neukum CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d2c861b700b0af90da2d60b1b256173628fa6785 Author: NeilBrown Date: Fri Apr 10 13:19:04 2015 +1000 md/raid0: fix bug with chunksize not a power of 2. [ Upstream commit 47d68979cc968535cb87f3e5f2e6a3533ea48fbd ] Since commit 20d0189b1012a37d2533a87fb451f7852f2418d1 in v3.14-rc1 RAID0 has performed incorrect calculations when the chunksize is not a power of 2. This happens because "sector_div()" modifies its first argument, but this wasn't taken into account in the patch. So restore that first arg before re-using the variable. Reported-by: Joe Landman Reported-by: Dave Chinner Fixes: 20d0189b1012a37d2533a87fb451f7852f2418d1 Cc: stable@vger.kernel.org (3.14 and later). Signed-off-by: NeilBrown Signed-off-by: Sasha Levin commit f364a04fb44955c96c08f99171ba1cf822dcdea1 Author: Alistair Strachan Date: Tue Mar 24 14:51:31 2015 -0700 staging: android: sync: Fix memory corruption in sync_timeline_signal(). [ Upstream commit 8e43c9c75faf2902955bd2ecd7a50a8cc41cb00a ] The android_fence_release() function checks for active sync points by calling list_empty() on the list head embedded on the sync point. However, it is only valid to use list_empty() on nodes that have been initialized with INIT_LIST_HEAD() or list_del_init(). Because the list entry has likely been removed from the active list by sync_timeline_signal(), there is a good chance that this WARN_ON_ONCE() will be hit due to dangling pointers pointing at freed memory (even though the sync drivers did nothing wrong) and memory corruption will ensue as the list entry is removed for a second time, corrupting the active list. This problem can be reproduced quite easily with CONFIG_DEBUG_LIST=y and fences with more than one sync point. Signed-off-by: Alistair Strachan Cc: Maarten Lankhorst Cc: Greg Kroah-Hartman Cc: Colin Cross Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fd431a7ce42c056a0e1783074cfece4058cbbd3b Author: Sudip Mukherjee Date: Tue Mar 24 16:29:32 2015 +0530 staging: panel: fix lcd type [ Upstream commit 2c20d92dad5db6440cfa88d811b69fd605240ce4 ] 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: Sasha Levin commit 886b9d665eefdafd00b37d4bf47fb890b551b672 Author: Huacai Chen Date: Sun Mar 29 10:54:05 2015 +0800 MIPS: Hibernate: flush TLB entries earlier [ Upstream commit a843d00d038b11267279e3b5388222320f9ddc1d ] 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: Cc: Steven J. Hill Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang Cc: Zhangjin Wu Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/9621/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 38d99bff82b98d02c254e00a5865b4bb1203e48c Author: Huacai Chen Date: Thu Mar 12 11:51:06 2015 +0800 MIPS: Loongson-3: Add IRQF_NO_SUSPEND to Cascade irqaction [ Upstream commit 0add9c2f1cff9f3f1f2eb7e9babefa872a9d14b9 ] HPET irq is routed to i8259 and then to MIPS CPU irq (cascade). After commit a3e6c1eff5 (MIPS: IRQ: Fix disable_irq on CPU IRQs), if without IRQF_NO_SUSPEND in cascade_irqaction, HPET interrupts will lost during suspend. The result is machine cannot be waken up. Signed-off-by: Huacai Chen Cc: Cc: Steven J. Hill Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang Cc: Zhangjin Wu Patchwork: https://patchwork.linux-mips.org/patch/9528/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 301080ae27c98e8530f6820b29d38f8c6f027a81 Author: Markos Chandras Date: Mon Mar 9 14:54:49 2015 +0000 MIPS: asm: asm-eva: Introduce kernel load/store variants [ Upstream commit 60cd7e08e453bc6828ac4b539f949e4acd80f143 ] Introduce new macros for kernel load/store variants which will be used to perform regular kernel space load/store operations in EVA mode. Signed-off-by: Markos Chandras Cc: # v3.15+ Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9500/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 312bc67c174d380d28ca95c88c3cd7a795220b4e Author: Markos Chandras Date: Fri Feb 27 07:51:32 2015 +0000 MIPS: Malta: Detect and fix bad memsize values [ Upstream commit f7f8aea4b97c4d48e42f02cb37026bee445f239f ] memsize denotes the amount of RAM we can access from kseg{0,1} and that should be up to 256M. In case the bootloader reports a value higher than that (perhaps reporting all the available RAM) it's best if we fix it ourselves and just warn the user about that. This is usually a problem with the bootloader and/or its environment. [ralf@linux-mips.org: Remove useless parens as suggested bei Sergei. Reformat long pr_warn statement to fit into 80 column limit.] Signed-off-by: Markos Chandras Cc: # v3.15+ Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9362/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 00f1187a9cb84924936a4b6310e36be2ad0e8a15 Author: James Hogan Date: Wed Feb 25 13:08:05 2015 +0000 MIPS: lose_fpu(): Disable FPU when MSA enabled [ Upstream commit f8483988cadd7dd22de928db29ed3bcbe02faf78 ] The lose_fpu() function only disables the FPU in CP0_Status.CU1 if the FPU is in use and MSA isn't enabled. This isn't necessarily a problem because KSTK_STATUS(current), the version of CP0_Status stored on the kernel stack on entry from user mode, does always get updated and gets restored when returning to user mode, but I don't think it was intended, and it is inconsistent with the case of only the FPU being in use. Sometimes leaving the FPU enabled may also mask kernel bugs where FPU operations are executed when the FPU might not be enabled. So lets disable the FPU in the MSA case too. Fixes: 33c771ba5c5d ("MIPS: save/disable MSA in lose_fpu") Signed-off-by: James Hogan Cc: Ralf Baechle Cc: Paul Burton Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9323/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 707ff2258e57b45383f402e010dc3c5115e0a835 Author: James Hogan Date: Fri Feb 6 11:11:56 2015 +0000 MIPS: KVM: Handle MSA Disabled exceptions from guest [ Upstream commit 98119ad53376885819d93dfb8737b6a9a61ca0ba ] Guest user mode can generate a guest MSA Disabled exception on an MSA capable core by simply trying to execute an MSA instruction. Since this exception is unknown to KVM it will be passed on to the guest kernel. However guest Linux kernels prior to v3.15 do not set up an exception handler for the MSA Disabled exception as they don't support any MSA capable cores. This results in a guest OS panic. Since an older processor ID may be being emulated, and MSA support is not advertised to the guest, the correct behaviour is to generate a Reserved Instruction exception in the guest kernel so it can send the guest process an illegal instruction signal (SIGILL), as would happen with a non-MSA-capable core. Fix this as minimally as reasonably possible by preventing kvm_mips_check_privilege() from relaying MSA Disabled exceptions from guest user mode to the guest kernel, and handling the MSA Disabled exception by emulating a Reserved Instruction exception in the guest, via a new handle_msa_disabled() KVM callback. Signed-off-by: James Hogan Cc: Paolo Bonzini Cc: Paul Burton Cc: Ralf Baechle Cc: Gleb Natapov Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Cc: # v3.15+ Signed-off-by: Sasha Levin commit e580744e7711b8ee49651df8fc363bc09fd9e3d1 Author: Andre Przywara Date: Fri Apr 10 16:17:59 2015 +0100 KVM: arm/arm64: check IRQ number on userland injection [ Upstream commit fd1d0ddf2ae92fb3df42ed476939861806c5d785 ] When userland injects a SPI via the KVM_IRQ_LINE ioctl we currently only check it against a fixed limit, which historically is set to 127. With the new dynamic IRQ allocation the effective limit may actually be smaller (64). So when now a malicious or buggy userland injects a SPI in that range, we spill over on our VGIC bitmaps and bytemaps memory. I could trigger a host kernel NULL pointer dereference with current mainline by injecting some bogus IRQ number from a hacked kvmtool: ----------------- .... DEBUG: kvm_vgic_inject_irq(kvm, cpu=0, irq=114, level=1) DEBUG: vgic_update_irq_pending(kvm, cpu=0, irq=114, level=1) DEBUG: IRQ #114 still in the game, writing to bytemap now... Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = ffffffc07652e000 [00000000] *pgd=00000000f658b003, *pud=00000000f658b003, *pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 1053 Comm: lkvm-msi-irqinj Not tainted 4.0.0-rc7+ #3027 Hardware name: FVP Base (DT) task: ffffffc0774e9680 ti: ffffffc0765a8000 task.ti: ffffffc0765a8000 PC is at kvm_vgic_inject_irq+0x234/0x310 LR is at kvm_vgic_inject_irq+0x30c/0x310 pc : [] lr : [] pstate: 80000145 ..... So this patch fixes this by checking the SPI number against the actual limit. Also we remove the former legacy hard limit of 127 in the ioctl code. Signed-off-by: Andre Przywara Reviewed-by: Christoffer Dall CC: # 4.0, 3.19, 3.18 [maz: wrap KVM_ARM_IRQ_GIC_MAX with #ifndef __KERNEL__, as suggested by Christopher Covington] Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 35e1329264c8b2ff71d4c186aabb856710cf9b2f Author: Radim Krčmář Date: Wed Apr 8 14:16:48 2015 +0200 KVM: use slowpath for cross page cached accesses [ Upstream commit ca3f0874723fad81d0c701b63ae3a17a408d5f25 ] 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: Sasha Levin commit 23786453d844ccfc9c4781e88b294d075e233d4b Author: Heiko Carstens Date: Wed Mar 25 10:13:33 2015 +0100 s390/hibernate: fix save and restore of kernel text section [ Upstream commit d74419495633493c9cd3f2bbeb7f3529d0edded6 ] 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 Cc: stable@vger.kernel.org Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 00d83726cc64e9a1e1e2f60471235e9cfaa86d1e Author: Jens Freimann Date: Mon Mar 16 12:17:13 2015 +0100 KVM: s390: fix get_all_floating_irqs [ Upstream commit 94aa033efcac47b09db22cb561e135baf37b7887 ] This fixes a bug introduced with commit c05c4186bbe4 ("KVM: s390: add floating irq controller"). get_all_floating_irqs() does copy_to_user() while holding a spin lock. Let's fix this by filling a temporary buffer first and copy it to userspace after giving up the lock. Cc: # 3.18+: 69a8d4562638 KVM: s390: no need to hold... Reviewed-by: David Hildenbrand Signed-off-by: Jens Freimann Signed-off-by: Christian Borntraeger Acked-by: Cornelia Huck Signed-off-by: Sasha Levin commit 7e15bc0e1c8b239a82005a884b1bce9260024ecb Author: Christian Borntraeger Date: Wed Dec 17 10:36:04 2014 +0100 KVM: s390: no need to hold the kvm->mutex for floating interrupts [ Upstream commit 69a8d456263849152826542c7cb0a164b90e68a8 ] The kvm mutex was (probably) used to protect against cpu hotplug. The current code no longer needs to protect against that, as we only rely on CPU data structures that are guaranteed to be available if we can access the CPU. (e.g. vcpu_create will put the cpu in the array AFTER the cpu is ready). Signed-off-by: Christian Borntraeger Acked-by: Cornelia Huck Reviewed-by: Jens Freimann Signed-off-by: Sasha Levin commit abd80ecb36d1f41f0498e57251d0c9aa2e3deb83 Author: Ekaterina Tumanova Date: Tue Mar 3 09:54:41 2015 +0100 KVM: s390: Zero out current VMDB of STSI before including level3 data. [ Upstream commit b75f4c9afac2604feb971441116c07a24ecca1ec ] 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 Cc: stable@vger.kernel.org Reviewed-by: David Hildenbrand Signed-off-by: Christian Borntraeger Signed-off-by: Sasha Levin commit b7c23d30eeb287801113c66e10c0d79387ee02e1 Author: David Hildenbrand Date: Wed Feb 4 15:59:11 2015 +0100 KVM: s390: reinjection of irqs can fail in the tpi handler [ Upstream commit 15462e37ca848abac7477dece65f8af25febd744 ] The reinjection of an I/O interrupt can fail if the list is at the limit and between the dequeue and the reinjection, another I/O interrupt is injected (e.g. if user space floods kvm with I/O interrupts). This patch avoids this memory leak and returns -EFAULT in this special case. This error is not recoverable, so let's fail hard. This can later be avoided by not dequeuing the interrupt but working directly on the locked list. Signed-off-by: David Hildenbrand Cc: stable@vger.kernel.org # 3.16+ Signed-off-by: Christian Borntraeger Signed-off-by: Sasha Levin commit 19881aff151277b639c6bc5c1965750bdeccadcc Author: David Hildenbrand Date: Wed Feb 4 15:53:42 2015 +0100 KVM: s390: fix handling of write errors in the tpi handler [ Upstream commit 261520dcfcba93ca5dfe671b88ffab038cd940c8 ] If the I/O interrupt could not be written to the guest provided area (e.g. access exception), a program exception was injected into the guest but "inti" wasn't freed, therefore resulting in a memory leak. In addition, the I/O interrupt wasn't reinjected. Therefore the dequeued interrupt is lost. This patch fixes the problem while cleaning up the function and making the cc and rc logic easier to handle. Signed-off-by: David Hildenbrand Cc: stable@vger.kernel.org # 3.16+ Signed-off-by: Christian Borntraeger Signed-off-by: Sasha Levin commit 67c5b95cdb8dea2e60b783c79e63c952e443dfec Author: Andrzej Pietrasiewicz Date: Tue Mar 3 10:52:05 2015 +0100 usb: gadget: printer: enqueue printer's response for setup request [ Upstream commit eb132ccbdec5df46e29c9814adf76075ce83576b ] 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. Cc: # v3.4+ Fixes: 2e87edf49227: "usb: gadget: make g_printer use composite" Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 43e8149d0401067293a8a5a8b85f4c34560e2a9e Author: Filipe Manana Date: Mon Mar 30 18:26:47 2015 +0100 Btrfs: fix inode eviction infinite loop after extent_same ioctl [ Upstream commit HEAD ] 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: Greg Kroah-Hartman (cherry picked from commit 9dc106617d5669a6f8d86e08f620dc2fb0413e21) Signed-off-by: Sasha Levin commit d5454242a1332e0a9a9ff154618c57b7629d41e7 Author: Filipe Manana Date: Mon Mar 30 18:23:59 2015 +0100 Btrfs: fix inode eviction infinite loop after cloning into it [ Upstream commit HEAD ] 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: Greg Kroah-Hartman (cherry picked from commit 449b46275ce58e1d3fc20d1efacd0d0369c6070f) Signed-off-by: Sasha Levin commit 5728a92403a208b5b9f444132320ab7ee3052f31 Author: David Sterba Date: Wed Mar 25 19:26:41 2015 +0100 btrfs: don't accept bare namespace as a valid xattr [ Upstream commit HEAD ] 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: Greg Kroah-Hartman (cherry picked from commit 1bb2835ed4f8ee186d8110817cf5a96ef9e35ab3) Signed-off-by: Sasha Levin commit 372b2ac593f1e587fbaa05e9fbb689c28be5de81 Author: Filipe Manana Date: Mon Mar 23 14:07:40 2015 +0000 Btrfs: fix log tree corruption when fs mounted with -o discard [ Upstream commit HEAD ] 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: Greg Kroah-Hartman (cherry picked from commit 3909e5a93ed64a186a396c1b7fd1db07e065728f) Signed-off-by: Sasha Levin commit 753fd54a07c04b01555a45fe9b124cee6cfed450 Author: Nadav Amit Date: Sun Apr 12 21:47:15 2015 +0300 KVM: x86: Fix MSR_IA32_BNDCFGS in msrs_to_save [ Upstream commit HEAD ] commit 9e9c3fe40bcd28e3f98f0ad8408435f4503f2781 upstream. kvm_init_msr_list is currently called before hardware_setup. As a result, vmx_mpx_supported always returns false when kvm_init_msr_list checks whether to save MSR_IA32_BNDCFGS. Move kvm_init_msr_list after vmx_hardware_setup is called to fix this issue. Signed-off-by: Nadav Amit Signed-off-by: Greg Kroah-Hartman Message-Id: <1428864435-4732-1-git-send-email-namit@cs.technion.ac.il> Signed-off-by: Paolo Bonzini (cherry picked from commit 702a71cf592282298395b3359f49a9a985182934) Signed-off-by: Sasha Levin commit 6cbb41b18694ff9d928aa94e144487ca7b26e6f4 Author: Mike Galbraith Date: Sat Jan 18 17:14:44 2014 +0100 sched/idle/x86: Optimize unnecessary mwait_idle() resched IPIs [ Upstream commit f8e617f4582995f7c25ef25b4167213120ad122b ] To fully take advantage of MWAIT, apparently the CLFLUSH instruction needs another quirk on certain CPUs: proper barriers around it on certain machines. On a Q6600 SMP system, pipe-test scheduling performance, cross core, improves significantly: 3.8.13 487.2 KHz 1.000 3.13.0-master 415.5 KHz .852 3.13.0-master+ 415.2 KHz .852 + restore mwait_idle 3.13.0-master++ 488.5 KHz 1.002 + restore mwait_idle + IPI fix Since X86_BUG_CLFLUSH_MONITOR is already a quirk, don't create a separate quirk for the extra smp_mb()s. Signed-off-by: Mike Galbraith Cc: # 3.10+ Cc: Borislav Petkov Cc: H. Peter Anvin Cc: Ian Malone Cc: Josh Boyer Cc: Len Brown Cc: Len Brown Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1390061684.5566.4.camel@marge.simpson.net [ Ported to recent kernel, added comments about the quirk. ] Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 560e6448bc078d13b0a115833f98576d34023c0f 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 [ Upstream commit b253149b843f89cd300cbdbea27ce1f847506f99 ] 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. ] Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 0ff99ba9ebe7818df4160816229ecc6c4b092cd6 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: Sasha Levin commit cfe7befc7d598ad55d0010af03d0dc82ba808492 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: Sasha Levin commit b5635e4539d82648f109c45d7ac09e4a7b3719a3 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: Sasha Levin commit 2732443ade7bd058a7a1d8000e4c910be7e6af88 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: Sasha Levin commit 93cc442175265745f9675a70512a2100ca421119 Author: Tom Herbert Date: Mon Apr 20 14:10:05 2015 -0700 ppp: call skb_checksum_complete_unset in ppp_receive_frame [ Upstream commit 3dfb05340ec6676e6fc71a9ae87bbbe66d3c2998 ] Call checksum_complete_unset in PPP receive to discard checksum-complete value. PPP does not pull checksum for headers and also modifies packet as in VJ compression. Signed-off-by: Tom Herbert Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit dc7071483edd513abad3751b57a1dd832ca31156 Author: Tom Herbert Date: Mon Apr 20 14:10:04 2015 -0700 net: add skb_checksum_complete_unset [ Upstream commit 4e18b9adf2f910ec4d30b811a74a5b626e6c6125 ] This function changes ip_summed to CHECKSUM_NONE if CHECKSUM_COMPLETE is set. This is called to discard checksum-complete when packet is being modified and checksum is not pulled for headers in a layer. Signed-off-by: Tom Herbert Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7aca2472093e9353793faeede03c94d00ce42fb1 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: Sasha Levin commit e13f6f2b39c4d91371c0ede88b136f364a6ffd6d 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: Sasha Levin commit b64bab57fb15e81f3f159353f18adf3d9c8c11a7 Author: Ido Shamay Date: Thu Apr 30 17:32:46 2015 +0300 net/mlx4_en: Schedule napi when RX buffers allocation fails [ Upstream commit 07841f9d94c11afe00c0498cf242edf4075729f4 ] When system is out of memory, refilling of RX buffers fails while the driver continue to pass the received packets to the kernel stack. At some point, when all RX buffers deplete, driver may fall into a sleep, and not recover when memory for new RX buffers is once again availible. This is because hardware does not have valid descriptors, so no interrupt will be generated for the driver to return to work in napi context. Fix it by schedule the napi poll function from stats_task delayed workqueue, as long as the allocations fail. Signed-off-by: Ido Shamay Signed-off-by: Amir Vadai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 09f2ece83a8589f9e65cf75bf7d6aac9ec32fe67 Author: Benjamin Poirier Date: Tue Apr 28 14:49:29 2015 -0700 mlx4: Fix tx ring affinity_mask creation [ Upstream commit 42eab005a5dd5d7ea2b0328aecc4d6cc0c23c9c2 ] By default, the number of tx queues is limited by the number of online cpus in mlx4_en_get_profile(). However, this limit no longer holds after the ethtool .set_channels method has been called. In that situation, the driver may access invalid bits of certain cpumask variables when queue_index >= nr_cpu_ids. Signed-off-by: Benjamin Poirier Acked-by: Ido Shamay Fixes: d03a68f ("net/mlx4_en: Configure the XPS queue mapping on driver load") Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5c0ac4b58b3a99ff1c624b799f416c2afc31e845 Author: Christoffer Dall Date: Mon May 4 09:25:26 2015 +0800 arm/arm64: KVM: Keep elrsr/aisr in sync with software model commit ae705930fca6322600690df9dc1c7d0516145a93 upstream. There is an interesting bug in the vgic code, which manifests itself when the KVM run loop has a signal pending or needs a vmid generation rollover after having disabled interrupts but before actually switching to the guest. In this case, we flush the vgic as usual, but we sync back the vgic state and exit to userspace before entering the guest. The consequence is that we will be syncing the list registers back to the software model using the GICH_ELRSR and GICH_EISR from the last execution of the guest, potentially overwriting a list register containing an interrupt. This showed up during migration testing where we would capture a state where the VM has masked the arch timer but there were no interrupts, resulting in a hung test. Cc: Marc Zyngier Reported-by: Alex Bennee Signed-off-by: Christoffer Dall Signed-off-by: Alex Bennée Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Sasha Levin commit 74e0fedea4b7dd63f6955835f3e7455fdfc64ea7 Author: Marc Zyngier Date: Mon May 4 09:25:25 2015 +0800 arm64: KVM: Do not use pgd_index to index stage-2 pgd commit 04b8dc85bf4a64517e3cf20e409eeaa503b15cc1 upstream. The kernel's pgd_index macro is designed to index a normal, page sized array. KVM is a bit diffferent, as we can use concatenated pages to have a bigger address space (for example 40bit IPA with 4kB pages gives us an 8kB PGD. In the above case, the use of pgd_index will always return an index inside the first 4kB, which makes a guest that has memory above 0x8000000000 rather unhappy, as it spins forever in a page fault, whist the host happilly corrupts the lower pgd. The obvious fix is to get our own kvm_pgd_index that does the right thing(tm). Tested on X-Gene with a hacked kvmtool that put memory at a stupidly high address. Reviewed-by: Christoffer Dall Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Sasha Levin commit 354883e3e518acfd849a68e844d5748fca7965aa Author: Marc Zyngier Date: Mon May 4 09:25:24 2015 +0800 arm64: KVM: Fix stage-2 PGD allocation to have per-page refcounting commit a987370f8e7a1677ae385042644326d9cd145a20 upstream. We're using __get_free_pages with to allocate the guest's stage-2 PGD. The standard behaviour of this function is to return a set of pages where only the head page has a valid refcount. This behaviour gets us into trouble when we're trying to increment the refcount on a non-head page: page:ffff7c00cfb693c0 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x4000000000000000() page dumped because: VM_BUG_ON_PAGE((*({ __attribute__((unused)) typeof((&page->_count)->counter) __var = ( typeof((&page->_count)->counter)) 0; (volatile typeof((&page->_count)->counter) *)&((&page->_count)->counter); })) <= 0) BUG: failure at include/linux/mm.h:548/get_page()! Kernel panic - not syncing: BUG! CPU: 1 PID: 1695 Comm: kvm-vcpu-0 Not tainted 4.0.0-rc1+ #3825 Hardware name: APM X-Gene Mustang board (DT) Call trace: [] dump_backtrace+0x0/0x13c [] show_stack+0x10/0x1c [] dump_stack+0x74/0x94 [] panic+0x100/0x240 [] stage2_get_pmd+0x17c/0x2bc [] kvm_handle_guest_abort+0x4b4/0x6b0 [] handle_exit+0x58/0x180 [] kvm_arch_vcpu_ioctl_run+0x114/0x45c [] kvm_vcpu_ioctl+0x2e0/0x754 [] do_vfs_ioctl+0x424/0x5c8 [] SyS_ioctl+0x40/0x78 CPU0: stopping A possible approach for this is to split the compound page using split_page() at allocation time, and change the teardown path to free one page at a time. It turns out that alloc_pages_exact() and free_pages_exact() does exactly that. While we're at it, the PGD allocation code is reworked to reduce duplication. This has been tested on an X-Gene platform with a 4kB/48bit-VA host kernel, and kvmtool hacked to place memory in the second page of the hardware PGD (PUD for the host kernel). Also regression-tested on a Cubietruck (Cortex-A7). [ Reworked to use alloc_pages_exact() and free_pages_exact() and to return pointers directly instead of by reference as arguments - Christoffer ] Reported-by: Mark Rutland Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Sasha Levin commit f10b9c8a2ee0382e566f488f5d3d2a481369c593 Author: Jan Kiszka Date: Mon May 4 09:25:23 2015 +0800 ARM: KVM: Fix size check in __coherent_cache_guest_page commit a050dfb21cc22ac0c666d52531040c1bc48184cc upstream. The check is supposed to catch page-unaligned sizes, not the inverse. Signed-off-by: Jan Kiszka Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Sasha Levin commit a49ecf872ec8870c32f5d9d412edae4033e87f12 Author: Marc Zyngier Date: Mon May 4 09:25:22 2015 +0800 arm/arm64: KVM: Use kernel mapping to perform invalidation on page fault commit 0d3e4d4fade6b04e933b11e69e80044f35e9cd60 upstream. When handling a fault in stage-2, we need to resync I$ and D$, just to be sure we don't leave any old cache line behind. That's very good, except that we do so using the *user* address. Under heavy load (swapping like crazy), we may end up in a situation where the page gets mapped in stage-2 while being unmapped from userspace by another CPU. At that point, the DC/IC instructions can generate a fault, which we handle with kvm->mmu_lock held. The box quickly deadlocks, user is unhappy. Instead, perform this invalidation through the kernel mapping, which is guaranteed to be present. The box is much happier, and so am I. Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Sasha Levin commit a412dc06d66e6f32269b3825221dc323dcc2ede0 Author: Marc Zyngier Date: Mon May 4 09:25:21 2015 +0800 arm/arm64: KVM: Invalidate data cache on unmap commit 363ef89f8e9bcedc28b976d0fe2d858fe139c122 upstream. Let's assume a guest has created an uncached mapping, and written to that page. Let's also assume that the host uses a cache-coherent IO subsystem. Let's finally assume that the host is under memory pressure and starts to swap things out. Before this "uncached" page is evicted, we need to make sure we invalidate potential speculated, clean cache lines that are sitting there, or the IO subsystem is going to swap out the cached view, loosing the data that has been written directly into memory. Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Sasha Levin commit cc0c5f43df62402d1c283f047634e4672f7cb1d8 Author: Marc Zyngier Date: Mon May 4 09:25:20 2015 +0800 arm64: KVM: Fix HCR setting for 32bit guests commit 801f6772cecea6cfc7da61aa197716ab64db5f9e upstream. Commit b856a59141b1 (arm/arm64: KVM: Reset the HCR on each vcpu when resetting the vcpu) moved the init of the HCR register to happen later in the init of a vcpu, but left out the fixup done in kvm_reset_vcpu when preparing for a 32bit guest. As a result, the 32bit guest is run as a 64bit guest, but the rest of the kernel still manages it as a 32bit. Fun follows. Moving the fixup to vcpu_reset_hcr solves the problem for good. Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Paolo Bonzini Signed-off-by: Shannon Zhao Signed-off-by: Sasha Levin commit 9a73540524944d8e1deed976caa5437c7ff81bf0 Author: Marc Zyngier Date: Mon May 4 09:25:19 2015 +0800 arm64: KVM: Fix TLB invalidation by IPA/VMID commit 55e858b75808347378e5117c3c2339f46cc03575 upstream. It took about two years for someone to notice that the IPA passed to TLBI IPAS2E1IS must be shifted by 12 bits. Clearly our reviewing is not as good as it should be... Paper bag time for me. Reported-by: Mario Smarduch Tested-by: Mario Smarduch Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Paolo Bonzini Signed-off-by: Shannon Zhao Signed-off-by: Sasha Levin commit 3fca593bd1a16d81b12b4081ee0234c9b92cc06a Author: Eric Auger Date: Mon May 4 09:25:18 2015 +0800 KVM: arm/arm64: vgic: vgic_init returns -ENODEV when no online vcpu commit 66b030e48af68fd4c22d343908bc057207a0a31e upstream. To be more explicit on vgic initialization failure, -ENODEV is returned by vgic_init when no online vcpus can be found at init. Signed-off-by: Eric Auger Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Sasha Levin commit 765420c3359e89d778e683c41edc39f51df84140 Author: Christoffer Dall Date: Mon May 4 09:25:17 2015 +0800 arm/arm64: KVM: Require in-kernel vgic for the arch timers commit 05971120fca43e0357789a14b3386bb56eef2201 upstream. It is curently possible to run a VM with architected timers support without creating an in-kernel VGIC, which will result in interrupts from the virtual timer going nowhere. To address this issue, move the architected timers initialization to the time when we run a VCPU for the first time, and then only initialize (and enable) the architected timers if we have a properly created and initialized in-kernel VGIC. When injecting interrupts from the virtual timer to the vgic, the current setup should ensure that this never calls an on-demand init of the VGIC, which is the only call path that could return an error from kvm_vgic_inject_irq(), so capture the return value and raise a warning if there's an error there. We also change the kvm_timer_init() function from returning an int to be a void function, since the function always succeeds. Reviewed-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Sasha Levin commit 11d483cec89a33c6fc1bdd08901b0da723d6f2b9 Author: Christoffer Dall Date: Mon May 4 09:25:16 2015 +0800 arm/arm64: KVM: Initialize the vgic on-demand when injecting IRQs commit ca7d9c829d419c06e450afa5f785d58198c37caa upstream. Userspace assumes that it can wire up IRQ injections after having created all VCPUs and after having created the VGIC, but potentially before starting the first VCPU. This can currently lead to lost IRQs because the state of that IRQ injection is not stored anywhere and we don't return an error to userspace. We haven't seen this problem manifest itself yet, presumably because guests reset the devices on boot, but this could cause issues with migration and other non-standard startup configurations. Reviewed-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Sasha Levin commit d4d53f72fa6bcb4a92a134bed97b07ea3e154840 Author: Shannon Zhao Date: Mon May 4 09:25:15 2015 +0800 arm/arm64: KVM: vgic: kick the specific vcpu instead of iterating through all commit 016ed39c54b8a3db680e5c6a43419f806133caf2 upstream. When call kvm_vgic_inject_irq to inject interrupt, we can known which vcpu the interrupt for by the irq_num and the cpuid. So we should just kick this vcpu to avoid iterating through all. Reviewed-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Marc Zyngier Signed-off-by: Shannon Zhao Signed-off-by: Sasha Levin commit c0a5bdaba1bc306b9fe5f69813948efc6f6396b4 Author: Christoffer Dall Date: Mon May 4 09:25:14 2015 +0800 arm/arm64: KVM: Don't allow creating VCPUs after vgic_initialized commit 716139df2517fbc3f2306dbe8eba0fa88dca0189 upstream. When the vgic initializes its internal state it does so based on the number of VCPUs available at the time. If we allow KVM to create more VCPUs after the VGIC has been initialized, we are likely to error out in unfortunate ways later, perform buffer overflows etc. Acked-by: Marc Zyngier Reviewed-by: Eric Auger Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Sasha Levin commit 2da33f7dca212a8ae2b1ebaa6f311060119d6ffc Author: Peter Maydell Date: Mon May 4 09:25:13 2015 +0800 arm/arm64: KVM: vgic: move reset initialization into vgic_init_maps() commit 6d3cfbe21bef5b66530b50ad16c88fdc71a04c35 upstream. VGIC initialization currently happens in three phases: (1) kvm_vgic_create() (triggered by userspace GIC creation) (2) vgic_init_maps() (triggered by userspace GIC register read/write requests, or from kvm_vgic_init() if not already run) (3) kvm_vgic_init() (triggered by first VM run) We were doing initialization of some state to correspond with the state of a freshly-reset GIC in kvm_vgic_init(); this is too late, since it will overwrite changes made by userspace using the register access APIs before the VM is run. Move this initialization earlier, into the vgic_init_maps() phase. This fixes a bug where QEMU could successfully restore a saved VM state snapshot into a VM that had already been run, but could not restore it "from cold" using the -loadvm command line option (the symptoms being that the restored VM would run but interrupts were ignored). Finally rename vgic_init_maps to vgic_init and renamed kvm_vgic_init to kvm_vgic_map_resources. [ This patch is originally written by Peter Maydell, but I have modified it somewhat heavily, renaming various bits and moving code around. If something is broken, I am to be blamed. - Christoffer ] Acked-by: Marc Zyngier Reviewed-by: Eric Auger Signed-off-by: Peter Maydell Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Sasha Levin commit 63d4dc9ea3fbf1db85c4781cb30ea8459459ed71 Author: Christoffer Dall Date: Mon May 4 09:25:12 2015 +0800 arm/arm64: KVM: Introduce stage2_unmap_vm commit 957db105c99792ae8ef61ffc9ae77d910f6471da upstream. Introduce a new function to unmap user RAM regions in the stage2 page tables. This is needed on reboot (or when the guest turns off the MMU) to ensure we fault in pages again and make the dcache, RAM, and icache coherent. Using unmap_stage2_range for the whole guest physical range does not work, because that unmaps IO regions (such as the GIC) which will not be recreated or in the best case faulted in on a page-by-page basis. Call this function on secondary and subsequent calls to the KVM_ARM_VCPU_INIT ioctl so that a reset VCPU will detect the guest Stage-1 MMU is off when faulting in pages and make the caches coherent. Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Sasha Levin commit 964cce8df8759c57ca0002eb20cdf7aba138a6e6 Author: Christoffer Dall Date: Mon May 4 09:25:11 2015 +0800 arm/arm64: KVM: Turn off vcpus on PSCI shutdown/reboot commit cf5d318865e25f887d49a0c6083bbc6dcd1905b1 upstream. When a vcpu calls SYSTEM_OFF or SYSTEM_RESET with PSCI v0.2, the vcpus should really be turned off for the VM adhering to the suggestions in the PSCI spec, and it's the sane thing to do. Also, clarify the behavior and expectations for exits to user space with the KVM_EXIT_SYSTEM_EVENT case. Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Sasha Levin commit e8234528bd6cd836672358d6aeaa3ba2b0eae5cf Author: Christoffer Dall Date: Mon May 4 09:25:10 2015 +0800 arm/arm64: KVM: Reset the HCR on each vcpu when resetting the vcpu commit b856a59141b1066d3c896a0d0231f84dabd040af upstream. When userspace resets the vcpu using KVM_ARM_VCPU_INIT, we should also reset the HCR, because we now modify the HCR dynamically to enable/disable trapping of guest accesses to the VM registers. This is crucial for reboot of VMs working since otherwise we will not be doing the necessary cache maintenance operations when faulting in pages with the guest MMU off. Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Sasha Levin commit 2421dbc19ac5dd98cb7c1e8b853339b14440d6cf Author: Christoffer Dall Date: Mon May 4 09:25:09 2015 +0800 arm/arm64: KVM: Correct KVM_ARM_VCPU_INIT power off option commit 3ad8b3de526a76fbe9466b366059e4958957b88f upstream. The implementation of KVM_ARM_VCPU_INIT is currently not doing what userspace expects, namely making sure that a vcpu which may have been turned off using PSCI is returned to its initial state, which would be powered on if userspace does not set the KVM_ARM_VCPU_POWER_OFF flag. Implement the expected functionality and clarify the ABI. Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Sasha Levin commit 04329bd399211582b22bccfb1cefc2c716e93a7c Author: Christoffer Dall Date: Mon May 4 09:25:08 2015 +0800 arm/arm64: KVM: Don't clear the VCPU_POWER_OFF flag commit 03f1d4c17edb31b41b14ca3a749ae38d2dd6639d upstream. If a VCPU was originally started with power off (typically to be brought up by PSCI in SMP configurations), there is no need to clear the POWER_OFF flag in the kernel, as this flag is only tested during the init ioctl itself. Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Sasha Levin commit cd7b8af485eb30fe38322564d2be2570a61d4d2a Author: Ard Biesheuvel Date: Mon May 4 09:25:07 2015 +0800 arm, arm64: KVM: handle potential incoherency of readonly memslots commit 849260c72c6b8bd53850cb00b80027db3a273c2c upstream. Readonly memslots are often used to implement emulation of ROMs and NOR flashes, in which case the guest may legally map these regions as uncached. To deal with the incoherency associated with uncached guest mappings, treat all readonly memslots as incoherent, and ensure that pages that belong to regions tagged as such are flushed to DRAM before being passed to the guest. Signed-off-by: Ard Biesheuvel Signed-off-by: Marc Zyngier Signed-off-by: Shannon Zhao Signed-off-by: Sasha Levin commit 4529fdd323d9614d548811d4d12dc7be02b6d80f Author: Laszlo Ersek Date: Mon May 4 09:25:06 2015 +0800 arm, arm64: KVM: allow forced dcache flush on page faults commit 840f4bfbe03f1ce94ade8fdf84e8cd925ef15a48 upstream. To allow handling of incoherent memslots in a subsequent patch, this patch adds a paramater 'ipa_uncached' to cache_coherent_guest_page() so that we can instruct it to flush the page's contents to DRAM even if the guest has caching globally enabled. Signed-off-by: Laszlo Ersek Signed-off-by: Ard Biesheuvel Signed-off-by: Marc Zyngier Signed-off-by: Shannon Zhao Signed-off-by: Sasha Levin commit 02f88a7f2ae921317c91f629d61c39e107b9af23 Author: Ard Biesheuvel Date: Mon May 4 09:25:05 2015 +0800 kvm: add a memslot flag for incoherent memory regions commit 1050dcda3052912984b26fb6d2695a3f41792000 upstream. Memory regions may be incoherent with the caches, typically when the guest has mapped a host system RAM backed memory region as uncached. Add a flag KVM_MEMSLOT_INCOHERENT so that we can tag these memslots and handle them appropriately when mapping them. Signed-off-by: Ard Biesheuvel Signed-off-by: Marc Zyngier Signed-off-by: Shannon Zhao Signed-off-by: Sasha Levin