commit 4bb08696fab71294c8f1c134a21be9159f82ba08 Author: Greg Kroah-Hartman Date: Sun May 19 11:39:04 2013 -0700 Linux 3.9.3 commit 8cb3a88522df20a6d77934260040facfc0449f0e Author: Andy Grover Date: Fri Apr 26 11:09:03 2013 -0700 target: Use FD_MAX_SECTORS/FD_BLOCKSIZE for blockdevs using fileio commit e3e84cda321703b123f36488f50700f371bc7230 upstream. We can still see the error reported in https://patchwork.kernel.org/patch/2338981/ when using fileio backed by a block device. I'm assuming this will get us past that error (from sbc_parse_cdb), and also assuming it's OK to have our max_sectors be larger than the block's queue max hw sectors? Reported-by: Eric Harney Signed-off-by: Andy Grover Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 60106c06452e7db66d13ce8286d89b9cce13664d Author: Eric W. Biederman Date: Tue Apr 9 02:22:10 2013 -0700 audit: Make testing for a valid loginuid explicit. commit 780a7654cee8d61819512385e778e4827db4bfbc upstream. audit rule additions containing "-F auid!=4294967295" were failing with EINVAL because of a regression caused by e1760bd. Apparently some userland audit rule sets want to know if loginuid uid has been set and are using a test for auid != 4294967295 to determine that. In practice that is a horrible way to ask if a value has been set, because it relies on subtle implementation details and will break every time the uid implementation in the kernel changes. So add a clean way to test if the audit loginuid has been set, and silently convert the old idiom to the cleaner and more comprehensible new idiom. RGB notes: In upstream, audit_rule_to_entry has been refactored out. This is patch is already upstream in functionally the same form in commit 780a7654cee8d61819512385e778e4827db4bfbc . The decimal constant was cast to unsigned to quiet GCC 4.6 32-bit architecture warnings. Reported-By: Steve Grubb Signed-off-by: "Eric W. Biederman" Tested-by: Richard Guy Briggs Signed-off-by: Eric Paris Backported-by: Richard Guy Briggs Signed-off-by: Greg Kroah-Hartman commit 3e717373db383369e5887708c3cde25f396f648e Author: Helge Deller Date: Sat May 11 19:04:09 2013 +0000 parisc: make default cross compiler search more robust (v3) commit 6880b0150a7c25fd75c5ece80abc49ebf53c38c1 upstream. People/distros vary how they prefix the toolchain name for 64bit builds. Rather than enforce one convention over another, add a for loop which does a search for all the general prefixes. For 64bit builds, we now search for (in order): hppa64-unknown-linux-gnu hppa64-linux-gnu hppa64-linux For 32bit builds, we look for: hppa-unknown-linux-gnu hppa-linux-gnu hppa-linux hppa2.0-unknown-linux-gnu hppa2.0-linux-gnu hppa2.0-linux hppa1.1-unknown-linux-gnu hppa1.1-linux-gnu hppa1.1-linux This patch was initiated by Mike Frysinger, with feedback from Jeroen Roovers, John David Anglin and Helge Deller. Signed-off-by: Mike Frysinger Signed-off-by: Jeroen Roovers Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 94f3c29b1ce931836cdc318a41350fc053c54a3d Author: Mike Frysinger Date: Sat May 4 16:50:58 2013 +0000 parisc: fix NATIVE set up in build commit 93782eba49e23c3f311a6b05a19ba15927ec4e8b upstream. The ifeq operator does not accept globs, so this little bit of code will never match (unless uname literally prints out "parsic*"). Rewrite to use a pattern matching operator so that NATIVE is set to 1 on parisc. Signed-off-by: Mike Frysinger Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 746cb3d3ce315b53263a1f8a97390be84cfd5ee3 Author: John David Anglin Date: Sat May 4 19:16:41 2013 +0000 parisc: use long branch in fork_like macro commit bbbfde782084b4f0d85ddffb88f1cf4650ff40e4 upstream. The "b" branch instruction used in the fork_like macro only can handle 17-bit pc-relative offsets. This fails with an out of range offset with some .config files. Rewrite to use the "be" instruction which can branch to any address in a space. Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 94754ecd526651ef163d1b12562b5d0ea7f96ce0 Author: John David Anglin Date: Fri May 10 23:21:38 2013 +0000 parisc: fix SMP races when updating PTE and TLB entries in entry.S commit f0a18819e261afc5fdbd8c5c6f9943123c5461ba upstream. Currently, race conditions exist in the handling of TLB interruptions in entry.S. In particular, dirty bit updates can be lost if an accessed interruption occurs just after the dirty bit interruption on a different cpu. Lost dirty bit updates result in user pages not being flushed and general system instability. This change adds lock and unlock macros to synchronize all PTE and TLB updates done in entry.S. As a result, userspace stability is significantly improved. Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit cdc9fd4956b3a525f68eae79b0f6b859e944a5ce Author: John David Anglin Date: Tue May 7 00:07:25 2013 +0000 parisc: only re-enable interrupts if we need to schedule or deliver signals when returning to userspace commit c207a76bf155cb5cf24cf849c08f6555e9180594 upstream. Helge and I have found that we have a kernel stack overflow problem which causes a variety of random failures. Currently, we re-enable interrupts when returning from an external interrupt incase we need to schedule or delivery signals. As a result, a potentially unlimited number of interrupts can occur while we are running on the kernel stack. It is very limited in space (currently, 16k). This change defers enabling interrupts until we have actually decided to schedule or delivery signals. This only occurs when we about to return to userspace. This limits the number of interrupts on the kernel stack to one. In other cases, interrupts remain disabled until the final return from interrupt (rfi). Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 98b17e9decaf1b103e4d0dd9ded21188c63dd475 Author: Oleg Nesterov Date: Thu May 16 17:43:55 2013 +0200 usermodehelper: check subprocess_info->path != NULL commit 264b83c07a84223f0efd0d1db9ccc66d6f88288f upstream. argv_split(empty_or_all_spaces) happily succeeds, it simply returns argc == 0 and argv[0] == NULL. Change call_usermodehelper_exec() to check sub_info->path != NULL to avoid the crash. This is the minimal fix, todo: - perhaps we should change argv_split() to return NULL or change the callers. - kill or justify ->path[0] check - narrow the scope of helper_lock() Signed-off-by: Oleg Nesterov Acked-By: Lucas De Marchi Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e48c45d58f425fe3ff5a0e8a7584121682643096 Author: Dave Airlie Date: Wed May 15 01:23:36 2013 +0000 drm/radeon: restore nomodeset operation (v2) commit e9ced8e040ebe40e9953db90acbe7d0b58702ebb upstream. When UMS was deprecated it removed support for nomodeset commandline we really want this in distro land so we can debug stuff, everyone should fallback to vesa correctly. v2: oops -1 isn't used anymore, restore original behaviour -1 is default, so we can boot with nomodeset on the command line, then use radeon.modeset=1 to override it for debugging later. Reviewed-by: Alex Deucher Reviewed-by: Christian König Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 916214e6b5dbfa96790b4a88c3a054093796bb15 Author: Kees Cook Date: Sun May 12 22:00:51 2013 -0700 drm/radeon: check incoming cliprects pointer commit fefaedcfb82d2e57c2320acf60604ab03b750cc0 upstream. The "boxes" parameter points into userspace memory. It should be verified like any other operation against user memory. Signed-off-by: Kees Cook Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit b479773965dec670698dee71667b76453f055df7 Author: Axel Lin Date: Thu May 9 21:14:20 2013 +0800 ASoC: da7213: Fix setting dmic_samplephase and dmic_clk_rate commit 61559af111e41761f5f4f20ce0897345eb59076e upstream. When set dmic_samplephase and dmic_clk_rate bits for dmic_cfg, current code checks pdata->dmic_data_sel which is wrong. Signed-off-by: Axel Lin Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 99099e169513f16ea40a35653d50c333f4c05d45 Author: Benjamin LaHaise Date: Thu May 16 14:04:27 2013 -0500 ipmi: ipmi_devintf: compat_ioctl method fails to take ipmi_mutex commit 6368087e851e697679af059b4247aca33a69cef3 upstream. When a 32 bit version of ipmitool is used on a 64 bit kernel, the ipmi_devintf code fails to correctly acquire ipmi_mutex. This results in incomplete data being retrieved in some cases, or other possible failures. Add a wrapper around compat_ipmi_ioctl() to take ipmi_mutex to fix this. Signed-off-by: Benjamin LaHaise Signed-off-by: Corey Minyard Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 29a5fc4815c1ba9365e68927e0c4a267dbba87ca Author: Chen Gang Date: Thu May 16 14:04:25 2013 -0500 drivers/char/ipmi: memcpy, need additional 2 bytes to avoid memory overflow commit a5f2b3d6a738e7d4180012fe7b541172f8c8dcea upstream. When calling memcpy, read_data and write_data need additional 2 bytes. write_data: for checking: "if (size > IPMI_MAX_MSG_LENGTH)" for operating: "memcpy(bt->write_data + 3, data + 1, size - 1)" read_data: for checking: "if (msg_len < 3 || msg_len > IPMI_MAX_MSG_LENGTH)" for operating: "memcpy(data + 2, bt->read_data + 4, msg_len - 2)" Signed-off-by: Chen Gang Signed-off-by: Corey Minyard Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit dce292e9ad1153354e730824f6d90df2c470784d Author: Lan Tianyu Date: Mon May 6 03:23:40 2013 +0000 ACPI / EC: Restart transaction even when the IBF flag set commit 28fe5c825f8e15744d04c7c1b8df197950923ecd upstream. The EC driver works abnormally with IBF flag always set. IBF means "The host has written a byte of data to the command or data port, but the embedded controller has not yet read it". If IBF is set in the EC status and not cleared, this will cause all subsequent EC requests to fail with a timeout error. Change the EC driver so that it doesn't refuse to restart a transaction if IBF is set in the status. Also increase the number of transaction restarts to 5, as it turns out that 2 is not sufficient in some cases. This bug happens on several different machines (Asus V1S, Dell Latitude E6530, Samsung R719, Acer Aspire 5930G, Sony Vaio SR19VN and others). [rjw: Changelog] References: https://bugzilla.kernel.org/show_bug.cgi?id=14733 References: https://bugzilla.kernel.org/show_bug.cgi?id=15560 References: https://bugzilla.kernel.org/show_bug.cgi?id=15946 References: https://bugzilla.kernel.org/show_bug.cgi?id=42945 References: https://bugzilla.kernel.org/show_bug.cgi?id=48221 Signed-off-by: Lan Tianyu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 1ed59c216723ca3586509ff309fbb987312d922a Author: Nicholas Bellinger Date: Tue May 14 23:41:04 2013 -0700 target/iblock: Fix WCE=1 + DPOFUA=1 backend WRITE regression commit d2bdbee0d91a5d3ba2e439ce889e20bfe6fd4f1b upstream. This patch fixes a regression bug introduced in v3.9-rc1 where if the underlying struct block_device for a IBLOCK backend is configured with WCE=1 + DPOFUA=1 settings, the rw = WRITE assignment no longer occurs in iblock_execute_rw(), and rw = 0 is passed to iblock_submit_bios() in effect causing a READ bio operation to occur. The offending commit is: commit d0c8b259f8970d39354c1966853363345d401330 Author: Nicholas Bellinger Date: Tue Jan 29 22:10:06 2013 -0800 target/iblock: Use backend REQ_FLUSH hint for WriteCacheEnabled status Note the WCE=1 + DPOFUA=0, WCE=0 + DPOFUA=1, and WCE=0 + DPOFUA=0 cases are not affected by this regression bug. Reported-by: Chris Boot Tested-by: Chris Boot Reported-by: Hannes Reinecke Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 114b8afe93aa6bf9ffd97874643e7f8485865012 Author: Joern Engel Date: Mon May 13 16:30:06 2013 -0400 target: close target_put_sess_cmd() vs. core_tmr_abort_task() race commit ccf5ae83a6cf3d9cfe9a7038bfe7cd38ab03d5e1 upstream. It is possible for one thread to to take se_sess->sess_cmd_lock in core_tmr_abort_task() before taking a reference count on se_cmd->cmd_kref, while another thread in target_put_sess_cmd() drops se_cmd->cmd_kref before taking se_sess->sess_cmd_lock. This introduces kref_put_spinlock_irqsave() and uses it in target_put_sess_cmd() to close the race window. Signed-off-by: Joern Engel Acked-by: Greg Kroah-Hartman Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit c597f2a40780026e4574e02e05296e22ad84c58f Author: Shlomo Pongratz Date: Sun May 5 17:36:26 2013 +0300 iscsi-target: Fix processing of OOO commands commit 3eccfdb01da58fbd0f789ae6ca61cee3769e26de upstream. Fix two issues in OOO commands processing done at iscsit_attach_ooo_cmdsn. Handle command serial numbers wrap around by using iscsi_sna_lt and not regular comparisson. The routine iterates until it finds an entry whose serial number is greater than the serial number of the new one, thus the new entry should be inserted before that entry and not after. Signed-off-by: Shlomo Pongratz Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit b540137a810d0267051c538e68d4348e43a1edf3 Author: Dirk Brandewie Date: Tue May 7 08:20:27 2013 -0700 cpufreq / intel_pstate: fix ffmpeg regression commit ca182aee389f8026401510f4c63841cb02c820e8 upstream. The ffmpeg benchmark in the phoronix test suite has threads on multiple cores that rely on the progress on of threads on other cores and ping pong back and forth fast enough to make the core appear less busy than it "should" be. If the core has been at minimum p-state for a while bump the pstate up to kick the core to see if it is in this ping pong state. If the core is truly idle the p-state will be reduced at the next sample time. If the core makes more progress it will send more work to the thread bringing both threads out of the ping pong scenario and the p-state will be selected normally. This fixes a performance regression of approximately 30% Signed-off-by: Dirk Brandewie Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 2aa491f8bdcac932006548b1a2b655b29c942e08 Author: Dirk Brandewie Date: Tue May 7 08:20:26 2013 -0700 cpufreq / intel_pstate: use lowest requested max performance commit d8f469e9cff3bc4a6317d923e9506be046aa7bdc upstream. There are two ways that the maximum p-state can be clamped, via a policy change and via the sysfs file. The acpi-thermal driver adjusts the p-state policy in response to thermal events. These changes override the users settings at the moment. Use the lowest of the two requested values this ensures that we will not exceed the requested pstate from either mechanism. Reported-by: Srinivas Pandruvada Signed-off-by: Dirk Brandewie Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 5aacc8bcf0b23e20cbb205ac6fdc3ce797e1cae2 Author: Dirk Brandewie Date: Tue May 7 08:20:25 2013 -0700 cpufreq / intel_pstate: remove idle time and duration from sample and calculations commit 1abc4b20b85b42e8573957e54b193385cf48b0d6 upstream. Idle time is taken into account in the APERF/MPERF ratio calculation there is no reason for the driver to track it seperately. This reduces the work in the driver and makes the code more readable. Removal of the tracking of sample duration removes the possibility of the divide by zero exception when the duration is sub 1us References: https://bugzilla.kernel.org/show_bug.cgi?id=56691 Reported-by: Mike Lothian Signed-off-by: Dirk Brandewie Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 60b19b611510f4d55787e5143ba085baab106e49 Author: Wei Yongjun Date: Mon Apr 29 16:21:07 2013 -0700 drivers/rtc/rtc-pcf2123.c: fix error return code in pcf2123_probe() commit 35623715818dfa720cccf99cd280dcbb4b78da23 upstream. Fix to return -ENODEV in the chip not found error handling case instead of 0, as done elsewhere in this function. Signed-off-by: Wei Yongjun Cc: Jingoo Han Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit 56b02ed3e6e99fcf97a4eef0fccba2bb70e44975 Author: Inderpal Singh Date: Mon Apr 29 17:01:47 2013 +0530 ARM: EXYNOS5: Fix kernel dump in AFTR idle mode commit 088584618836b159947bc4ab5011a5cf1f081a62 upstream. The kernel crashes while resuming from AFTR idle mode. It happens because L2 cache was not going into retention state. This patch configures the USE_RETENTION bit of ARM_L2_OPTION register so that it does not depend on MANUAL_L2RSTDISABLE_CONTROL of ARM_COMMON_OPTION register for L2RSTDISABLE signal. Signed-off-by: Inderpal Singh Tested-by: Chander Kashyap Signed-off-by: Olof Johansson Signed-off-by: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit a7a715466b67d5c0c1c29f7785838393a45c3700 Author: Geert Uytterhoeven Date: Tue Apr 23 23:40:55 2013 +0000 VSOCK: Drop bogus __init annotation from vsock_init_tables() commit 22ee3b57c3ff71772b0c4178404b04f5df78d501 upstream. If gcc (e.g. 4.1.2) decides not to inline vsock_init_tables(), this will cause a section mismatch: WARNING: net/vmw_vsock/vsock.o(.text+0x1bc): Section mismatch in reference from the function __vsock_core_init() to the function .init.text:vsock_init_tables() The function __vsock_core_init() references the function __init vsock_init_tables(). This is often because __vsock_core_init lacks a __init annotation or the annotation of vsock_init_tables is wrong. This may cause crashes if VSOCKETS=y and VMWARE_VMCI_VSOCKETS=m. Signed-off-by: Geert Uytterhoeven Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f51ff5c17eb64f61d05ef6deae50cf7e8043e3ad Author: Philipp Reisner Date: Wed Mar 27 14:08:47 2013 +0100 drbd: fix for deadlock when using automatic split-brain-recovery commit 7c689e63a847316c1b2500f86891b0a574ce7e69 upstream. With an automatic after split-brain recovery policy of "after-sb-1pri call-pri-lost-after-sb", when trying to drbd_set_role() to R_SECONDARY, we run into a deadlock. This was first recognized and supposedly fixed by 2009-06-10 "Fixed a deadlock when using automatic split brain recovery when both nodes are" replacing drbd_set_role() with drbd_change_state() in that code-path, but the first hunk of that patch forgets to remove the drbd_set_role(). We apparently only ever tested the "two primaries" case. Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg Signed-off-by: Jens Axboe Signed-off-by: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit 0cffc58dc06f51e3f02c59b8db11e25310fb400c Author: Lars Ellenberg Date: Wed Mar 27 14:08:42 2013 +0100 drbd: fix memory leak commit 94ad0a101415978be04945b2787be1e8e8a874db upstream. We forgot to free the disk_conf, so for each attach/detach cycle we leaked 336 bytes. Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg Signed-off-by: Jens Axboe Signed-off-by: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit 1035793b2ad31f2cd0b68a9609429e788b80652e Author: Philipp Reisner Date: Wed Mar 27 14:08:44 2013 +0100 drbd: Fix build error when CONFIG_CRYPTO_HMAC is not set commit ef57f9e6bb9278720c8a5278728f252ab85d7ac6 upstream. Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg Signed-off-by: Jens Axboe Signed-off-by: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit 5901e0b54b6bc78f731924a1f38826ce9e9d6fc6 Author: Guenter Roeck Date: Fri Apr 5 21:22:43 2013 -0700 watchdog: Fix race condition in registration code commit 60403f7a4d9368d187f79cba5e4672d01df37574 upstream. A race condition exists when registering the first watchdog device. Sequence of events: - watchdog_register_device calls watchdog_dev_register - watchdog_dev_register creates the watchdog misc device by calling misc_register. At that time, the matching character device (/dev/watchdog0) does not yet exist, and old_wdd is not set either. - Userspace gets an event and opens /dev/watchdog - watchdog_open is called and sets wdd = old_wdd, which is still NULL, and tries to dereference it. This causes the kernel to panic. Seen with systemd trying to open /dev/watchdog immediately after it was created. Reported-by: Arkadiusz Miskiewicz Signed-off-by: Guenter Roeck Tested-by: Arkadiusz Miskiewicz Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit 59df3520db0cd2d5e35e4d79c03bd32d91812276 Author: Tomoya MORINAGA Date: Tue Feb 12 11:25:33 2013 +0900 pch_dma: Use GFP_ATOMIC because called from interrupt context commit 5c1ef59168c485318e40ba485c1eba57d81d0faa upstream. pdc_desc_get() is called from pd_prep_slave_sg, and the function is called from interrupt context(e.g. Uart driver "pch_uart.c"). In fact, I saw kernel error message. So, GFP_ATOMIC must be used not GFP_NOIO. Signed-off-by: Tomoya MORINAGA Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit e27b7bee743d921f037b1da6f071237345bef7c1 Author: Cong Wang Date: Thu May 9 22:40:00 2013 +0000 xfrm6: release dev before returning error [ Upstream commit 84c4a9dfbf430861e7588d95ae3ff61535dca351 ] We forget to call dev_put() on error path in xfrm6_fill_dst(), its caller doesn't handle this. Signed-off-by: Cong Wang Cc: Herbert Xu Cc: Steffen Klassert Cc: David S. Miller Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 35dc0c576d03f49729e2429c43a96f0f09f9a1e9 Author: Amerigo Wang Date: Thu May 9 21:56:37 2013 +0000 ipv6,gre: do not leak info to user-space [ Upstream commit 5dbd5068430b8bd1c19387d46d6c1a88b261257f ] There is a hole in struct ip6_tnl_parm2, so we have to zero the struct on stack before copying it to user-space. Cc: David S. Miller Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 285665993541f4f9d8bf80db6d7d27b205aa78b9 Author: Eric Dumazet Date: Thu May 9 10:28:16 2013 +0000 ipv6: do not clear pinet6 field [ Upstream commit f77d602124d865c38705df7fa25c03de9c284ad2 ] We have seen multiple NULL dereferences in __inet6_lookup_established() After analysis, I found that inet6_sk() could be NULL while the check for sk_family == AF_INET6 was true. Bug was added in linux-2.6.29 when RCU lookups were introduced in UDP and TCP stacks. Once an IPv6 socket, using SLAB_DESTROY_BY_RCU is inserted in a hash table, we no longer can clear pinet6 field. This patch extends logic used in commit fcbdf09d9652c891 ("net: fix nulls list corruptions in sk_prot_alloc") TCP/UDP/UDPLite IPv6 protocols provide their own .clear_sk() method to make sure we do not clear pinet6 field. At socket clone phase, we do not really care, as cloning the parent (non NULL) pinet6 is not adding a fatal race. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 766af4d9a4f5c36289f744a65898ce5bee643138 Author: Jiri Pirko Date: Thu May 9 04:23:40 2013 +0000 macvlan: fix passthru mode race between dev removal and rx path [ Upstream commit 233c7df0821c4190e2d3f4be0f2ca0ab40a5ed8c ] Currently, if macvlan in passthru mode is created and data are rxed and you remove this device, following panic happens: NULL pointer dereference at 0000000000000198 IP: [] macvlan_handle_frame+0x153/0x1f7 [macvlan] I'm using following script to trigger this: I run this script while "ping -f" is running on another machine to send packets to e1 rx. Reason of the panic is that list_first_entry() is blindly called in macvlan_handle_frame() even if the list was empty. vlan is set to incorrect pointer which leads to the crash. I'm fixing this by protecting port->vlans list by rcu and by preventing from getting incorrect pointer in case the list is empty. Introduced by: commit eb06acdc85585f2 "macvlan: Introduce 'passthru' mode to takeover the underlying device" Signed-off-by: Jiri Pirko Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0f1afe3f24bfff492ddba71af38b75c91b539607 Author: Josh Boyer Date: Wed May 8 09:45:47 2013 +0000 if_cablemodem.h: Add parenthesis around ioctl macros [ Upstream commit 4f924b2aa4d3cb30f07e57d6b608838edcbc0d88 ] Protect the SIOCGCM* ioctl macros with parenthesis. Reported-by: Paul Wouters Signed-off-by: Josh Boyer Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 54403b6fda57669ce7406740019fbb87e9956199 Author: Sergei Shtylyov Date: Thu May 9 11:14:07 2013 +0000 3c59x: fix PCI resource management [ Upstream commit 4b264a1676e70dc656ba53a8cac690f2d4b65f4e ] The driver wrongly claimed I/O ports at an address returned by pci_iomap() -- even if it was passed an MMIO address. Fix this by claiming/releasing all PCI resources in the PCI driver's probe()/remove() methods instead and get rid of 'must_free_region' flag weirdness (why would Cardbus claim anything for us?). Signed-off-by: Sergei Shtylyov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit efefe3bd34cad21689edec56822a570159cadaed Author: Sergei Shtylyov Date: Thu May 2 11:10:22 2013 +0000 3c59x: fix freeing nonexistent resource on driver unload [ Upstream commit c81400be716aa4c76f6ebf339ba94358dbbf6da6 ] When unloading the driver that drives an EISA board, a message similar to the following one is displayed: Trying to free nonexistent resource <0000000000013000-000000000001301f> Then an user is unable to reload the driver because the resource it requested in the previous load hasn't been freed. This happens most probably due to a typo in vortex_eisa_remove() which calls release_region() with 'dev->base_addr' instead of 'edev->base_addr'... Reported-by: Matthew Whitehead Tested-by: Matthew Whitehead Signed-off-by: Sergei Shtylyov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 58484f8c691f3045528f2c488f35eb354e407bb7 Author: Konstantin Khlebnikov Date: Sun May 5 04:56:22 2013 +0000 net: frag, fix race conditions in LRU list maintenance [ Upstream commit b56141ab34e2c3e2d7960cea12c20c99530c0c76 ] This patch fixes race between inet_frag_lru_move() and inet_frag_lru_add() which was introduced in commit 3ef0eb0db4bf92c6d2510fe5c4dc51852746f206 ("net: frag, move LRU list maintenance outside of rwlock") One cpu already added new fragment queue into hash but not into LRU. Other cpu found it in hash and tries to move it to the end of LRU. This leads to NULL pointer dereference inside of list_move_tail(). Another possible race condition is between inet_frag_lru_move() and inet_frag_lru_del(): move can happens after deletion. This patch initializes LRU list head before adding fragment into hash and inet_frag_lru_move() doesn't touches it if it's empty. I saw this kernel oops two times in a couple of days. [119482.128853] BUG: unable to handle kernel NULL pointer dereference at (null) [119482.132693] IP: [] __list_del_entry+0x29/0xd0 [119482.136456] PGD 2148f6067 PUD 215ab9067 PMD 0 [119482.140221] Oops: 0000 [#1] SMP [119482.144008] Modules linked in: vfat msdos fat 8021q fuse nfsd auth_rpcgss nfs_acl nfs lockd sunrpc ppp_async ppp_generic bridge slhc stp llc w83627ehf hwmon_vid snd_hda_codec_hdmi snd_hda_codec_realtek kvm_amd k10temp kvm snd_hda_intel snd_hda_codec edac_core radeon snd_hwdep ath9k snd_pcm ath9k_common snd_page_alloc ath9k_hw snd_timer snd soundcore drm_kms_helper ath ttm r8169 mii [119482.152692] CPU 3 [119482.152721] Pid: 20, comm: ksoftirqd/3 Not tainted 3.9.0-zurg-00001-g9f95269 #132 To Be Filled By O.E.M. To Be Filled By O.E.M./RS880D [119482.161478] RIP: 0010:[] [] __list_del_entry+0x29/0xd0 [119482.166004] RSP: 0018:ffff880216d5db58 EFLAGS: 00010207 [119482.170568] RAX: 0000000000000000 RBX: ffff88020882b9c0 RCX: dead000000200200 [119482.175189] RDX: 0000000000000000 RSI: 0000000000000880 RDI: ffff88020882ba00 [119482.179860] RBP: ffff880216d5db58 R08: ffffffff8155c7f0 R09: 0000000000000014 [119482.184570] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88020882ba00 [119482.189337] R13: ffffffff81c8d780 R14: ffff880204357f00 R15: 00000000000005a0 [119482.194140] FS: 00007f58124dc700(0000) GS:ffff88021fcc0000(0000) knlGS:0000000000000000 [119482.198928] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [119482.203711] CR2: 0000000000000000 CR3: 00000002155f0000 CR4: 00000000000007e0 [119482.208533] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [119482.213371] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [119482.218221] Process ksoftirqd/3 (pid: 20, threadinfo ffff880216d5c000, task ffff880216d3a9a0) [119482.223113] Stack: [119482.228004] ffff880216d5dbd8 ffffffff8155dcda 0000000000000000 ffff000200000001 [119482.233038] ffff8802153c1f00 ffff880000289440 ffff880200000014 ffff88007bc72000 [119482.238083] 00000000000079d5 ffff88007bc72f44 ffffffff00000002 ffff880204357f00 [119482.243090] Call Trace: [119482.248009] [] ip_defrag+0x8fa/0xd10 [119482.252921] [] ipv4_conntrack_defrag+0x83/0xe0 [119482.257803] [] nf_iterate+0x8b/0xa0 [119482.262658] [] ? inet_del_offload+0x40/0x40 [119482.267527] [] nf_hook_slow+0x74/0x130 [119482.272412] [] ? inet_del_offload+0x40/0x40 [119482.277302] [] ip_rcv+0x268/0x320 [119482.282147] [] __netif_receive_skb_core+0x612/0x7e0 [119482.286998] [] __netif_receive_skb+0x18/0x60 [119482.291826] [] process_backlog+0xa0/0x160 [119482.296648] [] net_rx_action+0x139/0x220 [119482.301403] [] __do_softirq+0xe7/0x220 [119482.306103] [] run_ksoftirqd+0x28/0x40 [119482.310809] [] smpboot_thread_fn+0xff/0x1a0 [119482.315515] [] ? lg_local_lock_cpu+0x40/0x40 [119482.320219] [] kthread+0xc0/0xd0 [119482.324858] [] ? insert_kthread_work+0x40/0x40 [119482.329460] [] ret_from_fork+0x7c/0xb0 [119482.334057] [] ? insert_kthread_work+0x40/0x40 [119482.338661] Code: 00 00 55 48 8b 17 48 b9 00 01 10 00 00 00 ad de 48 8b 47 08 48 89 e5 48 39 ca 74 29 48 b9 00 02 20 00 00 00 ad de 48 39 c8 74 7a <4c> 8b 00 4c 39 c7 75 53 4c 8b 42 08 4c 39 c7 75 2b 48 89 42 08 [119482.343787] RIP [] __list_del_entry+0x29/0xd0 [119482.348675] RSP [119482.353493] CR2: 0000000000000000 Oops happened on this path: ip_defrag() -> ip_frag_queue() -> inet_frag_lru_move() -> list_move_tail() -> __list_del_entry() Signed-off-by: Konstantin Khlebnikov Cc: Jesper Dangaard Brouer Cc: Florian Westphal Cc: Eric Dumazet Cc: David S. Miller Acked-by: Florian Westphal Signed-off-by: Jesper Dangaard Brouer Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 125e98585058b2c205a2688e0198e0669d50b13c Author: stephen hemminger Date: Fri May 3 14:49:41 2013 +0000 virtio: don't expose u16 in userspace api [ Upstream commit 77d21f23a1e4db8639e3916547c903a3b3c7a07c ] Programs using virtio headers outside of kernel will no longer build because u16 type does not exist in userspace. All user ABI must use __u16 typedef instead. Bug introduce by: commit 986a4f4d452dec004697f667439d27c3fda9c928 Author: Jason Wang Date: Fri Dec 7 07:04:56 2012 +0000 virtio_net: multiqueue support Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 372ef96689aaff54f9a20603d9d1abafa0fc0a8d Author: Daniel Borkmann Date: Fri May 3 02:57:00 2013 +0000 packet: tpacket_v3: do not trigger bug() on wrong header status [ Upstream commit 8da3056c04bfc5f69f840ab038a38389e2de8189 ] Jakub reported that it is fairly easy to trigger the BUG() macro from user space with TPACKET_V3's RX_RING by just giving a wrong header status flag. We already had a similar situation in commit 7f5c3e3a80e6654 (``af_packet: remove BUG statement in tpacket_destruct_skb'') where this was the case in the TX_RING side that could be triggered from user space. So really, don't use BUG() or BUG_ON() unless there's really no way out, and i.e. don't use it for consistency checking when there's user space involved, no excuses, especially not if you're slapping the user with WARN + dump_stack + BUG all at once. The two functions are of concern: prb_retire_current_block() [when block status != TP_STATUS_KERNEL] prb_open_block() [when block_status != TP_STATUS_KERNEL] Calls to prb_open_block() are guarded by ealier checks if block_status is really TP_STATUS_KERNEL (racy!), but the first one BUG() is easily triggable from user space. System behaves still stable after they are removed. Also remove that yoda condition entirely, since it's already guarded. Reported-by: Jakub Zawadzki Signed-off-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0699987cf38e112c5a8a02452bf7e92c23f6c26a Author: holger@eitzenberger.org Date: Fri May 3 00:02:20 2013 +0000 asix: fix BUG in receive path when lowering MTU [ Upstream commit c5060cec6ba27ad3f0e7facfdf05d2f18e3e3010 ] There is bug in the receive path of the asix driver at the time a packet is received larger than MTU size and DF bit set: BUG: unable to handle kernel paging request at 0000004000000001 IP: [] skb_release_head_state+0x2d/0xd2 ... Call Trace: [] ? skb_release_all+0x9/0x1e [] ? __kfree_skb+0x9/0x6f [] ? asix_rx_fixup_internal+0xff/0x1ae [asix] [] ? usbnet_bh+0x4f/0x226 [usbnet] ... It is easily reproducable by setting an MTU of 512 e. g. and sending something like ping -s 1472 -c 1 -M do $SELF from another box. And this is because the rx->ax_skb is freed on error, but rx->ax_skb is not reset, and the size is not reset to zero in this case. And since the skb is added again to the usbnet->done skb queue it is accessing already freed memory, resulting in the BUG when freeing a 2nd time. I therefore think the value 0x0000004000000001 show in the trace is more or less random data. Signed-off-by: Holger Eitzenberger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4b44cbc7a2395229ab3e7b9165fc5dfee3145208 Author: stephen hemminger Date: Thu May 2 14:23:28 2013 +0000 bridge: fix race with topology change timer [ Upstream commit 83401eb4990ff6af55aeed8f49681558544192e6 ] A bridge should only send topology change notice if it is not the root bridge. It is possible for message age timer to elect itself as a new root bridge, and still have a topology change timer running but waiting for bridge lock on other CPU. Solve the race by checking if we are root bridge before continuing. This was the root cause of the cases where br_send_tcn_bpdu would OOPS. Reported-by: JerryKang Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 572953b3a5809b0a4129605a5b588946e7e27959 Author: Bjørn Mork Date: Wed May 1 23:06:42 2013 +0000 net: vlan,ethtool: netdev_features_t is more than 32 bit [ Upstream commit b29d3145183da4e07d4b570fa8acdd3ac4a5c572 ] Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 41d05db1af2c73d17138389271ea149e13b06939 Author: Patrick McHardy Date: Wed May 1 22:36:49 2013 +0000 net: use netdev_features_t in skb_needs_linearize() [ Upstream commit 6708c9e5cc9bfc7c9a00ce9c0fdd0b1d4952b3d1 ] Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 09a4b7ce88847a65f3c52dac145a604c250dbe12 Author: Jamal Hadi Salim Date: Sun Apr 28 05:06:38 2013 +0000 net_sched: act_ipt forward compat with xtables [ Upstream commit 0dcffd09641f3abb21ac5cabc61542ab289d1a3c ] Deal with changes in newer xtables while maintaining backward compatibility. Thanks to Jan Engelhardt for suggestions. Signed-off-by: Jamal Hadi Salim Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d77900b50da9d090fdba932ce8e34f126549546d Author: Matthew Whitehead Date: Mon Apr 29 17:46:53 2013 -0400 3c509.c: call SET_NETDEV_DEV for all device types (ISA/ISAPnP/EISA) [ Upstream commit 3b54912f9cd167641b91d4a697bd742f70e534fe ] The venerable 3c509 driver only sets its device parent in one case, the ISAPnP one. It does this with the SET_NETDEV_DEV function. It should register with the device hierarchy in two additional cases: standard (non-PnP) ISA and EISA. - Currently they appear here: /sys/devices/virtual/net/eth0 (standard ISA) /sys/devices/virtual/net/eth1 (EISA) - Rather, they should instead be here: /sys/devices/isa/3c509.0/net/eth0 (standard ISA) /sys/devices/pci0000:00/0000:00:07.0/00:04/net/eth1 (EISA) Tested on ISA and EISA boards. Signed-off-by: Matthew Whitehead Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a1d9ddb105801c4ac651314f5963ed2de45fc494 Author: Yuchung Cheng Date: Mon Apr 29 08:44:51 2013 +0000 tcp: reset timer after any SYNACK retransmit [ Upstream commit cd75eff64dae8856afbf6ef0f0ca3c145465d8e0 ] Linux immediately returns SYNACK on (spurious) SYN retransmits, but keeps the SYNACK timer running independently. Thus the timer may fire right after the SYNACK retransmit and causes a SYN-SYNACK cross-fire burst. Adopt the fast retransmit/recovery idea in established state by re-arming the SYNACK timer after the fast (SYNACK) retransmit. The timer may fire late up to 500ms due to the current SYNACK timer wheel, but it's OK to be conservative when network is congested. Eric's new listener design should address this issue. Signed-off-by: Yuchung Cheng Acked-by: Eric Dumazet Acked-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0523cdce095dfa615f9c7308603bb11e99179e3c Author: Chen Gang Date: Thu Apr 25 00:49:55 2013 +0000 net: mac802154: comparision issue of type cast, finding by EXTRA_CFLAGS=-W [ Upstream commit 2c1bbbffa0b644fab4f91878cde0c2e8f52e2dcc ] Change MAC802154_CHAN_NONE from ~(u8)0 to 0xff, or the comparison in mac802154_wpan_xmit() for ``chan == MAC802154_CHAN_NONE'' will not succeed. This bug can be boiled down to ``u8 foo = 0xff; if (foo == ~(u8)0) [...] else [...]'' where the condition will always take the else branch. Signed-off-by: Chen Gang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ce5cd52ae112a367ea9c38b1727d99349802a00d Author: Gao feng Date: Wed Apr 24 21:59:23 2013 +0000 net: tun: release the reference of tun device in tun_recvmsg [ Upstream commit 3811ae76bc84e5dc1a670ae10695f046b310bee1 ] We forget to release the reference of tun device in tun_recvmsg. bug introduced in commit 54f968d6efdbf7dec36faa44fc11f01b0e4d1990 (tuntap: move socket to tun_file) Signed-off-by: Gao feng Acked-by: Jason Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7396524d7b79eb227b66e48893da2c2fd7f77a47 Author: Ben Hutchings Date: Mon Apr 22 22:40:07 2013 +0100 sfc: Fix naming of MTD partitions for FPGA bitfiles [ Upstream commit 89cc80a44b7c320e08599cb86f6aef0ead8986a1 ] efx_mcdi_get_board_cfg() uses a buffer for the firmware response that is only large enough to hold subtypes for the originally defined set of NVRAM partitions. Longer responses are truncated, and we may read off the end of the buffer when copying out subtypes for additional partitions. In particular, this can result in the MTD partition for an FPGA bitfile being named e.g. 'eth5 sfc_fpga:00' when it should be 'eth5 sfc_fpga:01'. This means the firmware update tool (sfupdate) can't tell which bitfile should be written to the partition. Correct the response buffer size. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 756cecd0f066505c506b009235159b30a152d581 Author: Eric Dumazet Date: Wed Apr 24 18:34:55 2013 -0700 tcp: force a dst refcount when prequeue packet [ Upstream commit 093162553c33e9479283e107b4431378271c735d ] Before escaping RCU protected section and adding packet into prequeue, make sure the dst is refcounted. Reported-by: Mike Galbraith Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f28cecc16e43ca84d44e5d5fe7bc050e711d2c80 Author: Jani Nikula Date: Tue May 7 18:54:05 2013 +0300 drm/i915: clear the stolen fb before resuming commit 1ffc5289bfcf7f4c4e4213240bb4be68c48ce603 upstream. Similar to commit 88afe715dd5469bc24ca7a19ac62dd3c241cab48 Author: Chris Wilson Date: Sun Dec 16 12:15:41 2012 +0000 drm/i915: Clear the stolen fb before enabling but on the resume path. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=57191 Reported-and-tested-by: Nikolay Amiantov Signed-off-by: Jani Nikula Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 60724ed5b84824747d0bc5bb2a5b10af96503ca4 Author: Daniel Vetter Date: Thu May 2 09:43:05 2013 +0200 drm: don't check modeset locks in panic handler commit a9b054e8ab06504c2afa0e307ee78d3778993a1d upstream. Since we know that locking is broken in that case and it's more important to not flood the dmesg with random gunk. Reported-and-tested-by: Borislav Petkov References: http://lkml.kernel.org/r/20130502000206.GH15623@pd.tnic Cc: Dave Airlie Cc: Borislav Petkov Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit dfdaa3fc4649040b08ebe10d5b05993adf67645c Author: Daniel Vetter Date: Sat Apr 20 12:08:11 2013 +0200 drm/mm: fix dump table BUG commit 3a359f0b21ab218c1bf7a6a1b638b6fd143d0b99 upstream. In commit 9e8944ab564f2e3dde90a518cd32048c58918608 Author: Chris Wilson Date: Thu Nov 15 11:32:17 2012 +0000 drm: Introduce an iterator over holes in the drm_mm range manager helpers and iterators for hole handling have been introduced with some debug BUG_ONs sprinkled over. Unfortunately this broke the mm dumper which unconditionally tried to compute the size of the very first hole. While at it unify the code a bit with the hole dumping in the loop. v2: Extract a hole dump helper. Reported-by: Christopher Harvey Cc: Christopher Harvey Cc: Dave Airlie Cc: Chris Wilson Acked-by: Dave Airlie Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 70386b7f179aaa0a3db5af2ff5fae0f905e0186b Author: Christopher Harvey Date: Wed May 8 19:10:38 2013 +0000 drm/mgag200: Fix framebuffer base address programming commit 9f1d036648c1c5ed81b0e98d7a06d55df972701e upstream. Higher bits of the base address of framebuffers weren't being programmed properly. This caused framebuffers that didn't happen to be allocated at a low enough address to not be displayed properly. Signed-off-by: Christopher Harvey Signed-off-by: Mathieu Larouche Acked-by: Julia Lemire Tested-by: Julia Lemire Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 6640a6a925014f7fbd38de65a377ee88e208d412 Author: Christopher Harvey Date: Fri Apr 12 22:24:05 2013 +0000 drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register commit fb70a6690875315a3a1454e52fa339441ee7612b upstream. The original line, WREG_DAC(MGA1064_PIX_CLK_CTL_CLK_DIS, tmp); wrote tmp into MGA1064_PIX_CLK_CTL_CLK_DIS, where MGA1064_PIX_CLK_CTL_CLK_DIS is an offset into MGA1064_PIX_CLK_CTL. Change the line to write properly into MGA1064_PIX_CLK_CTL. There were other chunks of code nearby that use the same pattern (but work correctly), so this patch updates them all to use this new (slightly more efficient) write pattern. The WREG_DAC macro was causing the DAC_INDEX register to be set to the same value twice. WREG8(DAC_DATA, foo) takes advantage of the fact that DAC_INDEX is already at the value we want. Signed-off-by: Christopher Harvey Acked-by: Julia Lemire Tested-by: Julia Lemire Acked-by: Mathieu Larouche Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 4aea296fc23c3d9645c09f3ec79ac916ba57787b Author: Stanislaw Gruszka Date: Tue May 7 18:07:06 2013 +0200 iwl4965: workaround connection regression on passive channel commit dd9c46408fdc07098333655ff27edf8cac8d9fcf upstream. Jake reported that since commit 1672c0e31917f49d31d30d79067103432bc20cc7 "mac80211: start auth/assoc timeout on frame status", he is unable to connect to his AP, which is configured to use passive channel. After switch to passive channel 4965 firmware drops any TX packet until it receives beacon. Before commit 1672c0e3 we waited on channel and retransmit packet after 200ms, that makes we receive beacon on the meantime and association process succeed. New mac80211 behaviour cause that any ASSOC frame fail immediately on iwl4965 and we can not associate. This patch restore old mac80211 behaviour for iwl4965, by removing IEEE80211_HW_REPORTS_TX_ACK_STATUS feature. This feature will be added again to iwl4965 driver, when different, more complex workaround for this firmware issue, will be added to the driver. Bisected-by: Jake Edge Reported-and-tested-by: Jake Edge Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 548ebaffd93a8a3d54ddccf89b126e10a3c2a81e Author: Thommy Jakobsson Date: Tue Apr 23 21:45:11 2013 +0200 B43: Handle DMA RX descriptor underrun commit 73b82bf0bfbf58e6ff328d3726934370585f6e78 upstream. Add handling of rx descriptor underflow. This fixes a fault that could happen on slow machines, where data is received faster than the CPU can handle. In such a case the device will use up all rx descriptors and refuse to send any more data before confirming that it is ok. This patch enables necessary interrupt to discover such a situation and will handle them by dropping everything in the ring buffer. Reviewed-by: Michael Buesch Signed-off-by: Thommy Jakobsson Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit ab08ba324788b122edc3e983d7b7083fa20d6bc4 Author: Chris Metcalf Date: Thu May 2 15:29:04 2013 -0400 tile: support new Tilera hypervisor commit c539914dcd9a68c63305e055b14115a6a19578a8 upstream. The Tilera hypervisor shipped in releases up through MDE 4.1 launches the client operating system (i.e. Linux) at privilege level 1 (PL1). Starting with MDE 4.2, as part of the work to enable KVM, the Tilera hypervisor launches Linux at PL2 instead. This commit makes the KERNEL_PL option default to 2 for tilegx, while still saying at 1 for tilepro, which doesn't have an updated hypervisor. It also explains how and when you might want to choose another value. In addition, we change a small buglet in the on-chip Ethernet driver, where we were failing to use the KERNEL_PL constant in an API call. To make the transition cleaner, this change also provides the updated hv_init() API for the new hypervisor that supports announcing Linux's compiled-in PL, so the hypervisor can generate a suitable error in the case of a mismatched hypervisor and Linux binary. Signed-off-by: Chris Metcalf Signed-off-by: Greg Kroah-Hartman commit f4d497e4106c3d8461bec4d8b99e740f8e52f7f6 Author: Daniel Drake Date: Wed May 8 15:37:19 2013 -0400 mwifiex: fix setting of multicast filter commit ccd384b10420ac81ba3fb9b0a7d18272c7173552 upstream. A small bug in this code was causing the ALLMULTI filter to be set when in fact we were just wanting to program a selective multicast list to the hardware. Fix that bug and remove a redundant if condition in the code that follows. This fixes wakeup behaviour when multicast WOL is enabled. Previously, all multicast packets would wake up the system. Now, only those that the host intended to receive trigger wakeups. Signed-off-by: Daniel Drake Acked-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 09ec45665014181f41022f1ca15db2e03a6323a8 Author: Amitkumar Karwar Date: Mon May 6 19:46:54 2013 -0700 mwifiex: fix memory leak issue when driver unload commit f16fdc9d2dc1e5b270e9a08377587e831e0d36ac upstream. After unregister_netdevice() call the request is queued and reg_state is changed to NETREG_UNREGISTERING. As we check for NETREG_UNREGISTERED state, free_netdev() never gets executed causing memory leak. Initialize "dev->destructor" to free_netdev() to free device data after unregistration. Reported-by: Daniel Drake Tested-by: Daniel Drake Signed-off-by: Amitkumar Karwar Signed-off-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 8dd844a870b7f074d8443a30c06556f6631f8021 Author: Bing Zhao Date: Mon May 6 19:46:53 2013 -0700 mwifiex: clear is_suspended flag when interrupt is received early commit 48795424acff7215d5eac0b52793a2c1eb3a6283 upstream. When the XO-4 with 8787 wireless is woken up due to wake-on-WLAN mwifiex is often flooded with "not allowed while suspended" messages and the interface is unusable. [ 202.171609] int: sdio_ireg = 0x1 [ 202.180700] info: mwifiex_process_hs_config: auto cancelling host sleep since there is interrupt from the firmware [ 202.201880] event: wakeup device... [ 202.211452] event: hs_deactivated [ 202.514638] info: --- Rx: Data packet --- [ 202.514753] data: 4294957544 BSS(0-0): Data <= kernel [ 202.514825] PREP_CMD: device in suspended state [ 202.514839] data: dequeuing the packet ec7248c0 ec4869c0 [ 202.514886] mwifiex_write_data_sync: not allowed while suspended [ 202.514886] host_to_card, write iomem (1) failed: -1 [ 202.514917] mwifiex_write_data_sync: not allowed while suspended [ 202.514936] host_to_card, write iomem (2) failed: -1 [ 202.514949] mwifiex_write_data_sync: not allowed while suspended [ 202.514965] host_to_card, write iomem (3) failed: -1 [ 202.514976] mwifiex_write_data_async failed: 0xFFFFFFFF This can be readily reproduced when putting the XO-4 in a loop where it goes to sleep due to inactivity, but then wakes up due to an incoming ping. The error is hit within an hour or two. This issue happens when an interrupt comes in early while host sleep is still activated. Driver handles this case by auto cancelling host sleep. However is_suspended flag is still set which prevents any cmd or data from being sent to firmware. Fix it by clearing is_suspended flag in this path. Reported-by: Daniel Drake Tested-by: Daniel Drake Signed-off-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 003e033dbc793c5c292f36e3256749ef8c9a1d42 Author: Felix Fietkau Date: Sat Apr 27 11:47:01 2013 +0200 ath9k: fix key allocation error handling for powersave keys commit 4ef69d0394cba8caa9f75d3f2e53429bfb8b3045 upstream. If no keycache slots are available, ath_key_config can return -ENOSPC. If the key index is not checked for errors, it can lead to logspam that looks like this: "ath: wiphy0: keyreset: keycache entry 228 out of range" This can cause follow-up errors if the invalid keycache index gets used for tx. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 240814c55293b91616bd50bd03c5d711d79bdd03 Author: Anton Blanchard Date: Sun May 12 15:04:53 2013 +0000 powerpc/kexec: Fix kexec when using VMX optimised memcpy commit 79c66ce8f6448a3295a32efeac88c9debd7f7094 upstream. commit b3f271e86e5a (powerpc: POWER7 optimised memcpy using VMX and enhanced prefetch) uses VMX when it is safe to do so (ie not in interrupt). It also looks at the task struct to decide if we have to save the current tasks' VMX state. kexec calls memcpy() at a point where the task struct may have been overwritten by the new kexec segments. If it has been overwritten then when memcpy -> enable_altivec looks up current->thread.regs->msr we get a cryptic oops or lockup. I also notice we aren't initialising thread_info->cpu, which means smp_processor_id is broken. Fix that too. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit ce2530033619203b6d27ba7d45fae9ce3445db56 Author: Robert Jennings Date: Tue May 7 04:34:11 2013 +0000 powerpc: Bring all threads online prior to migration/hibernation commit 120496ac2d2d60aee68d3123a68169502a85f4b5 upstream. This patch brings online all threads which are present but not online prior to migration/hibernation. After migration/hibernation those threads are taken back offline. During migration/hibernation all online CPUs must call H_JOIN, this is required by the hypervisor. Without this patch, threads that are offline (H_CEDE'd) will not be woken to make the H_JOIN call and the OS will be deadlocked (all threads either JOIN'd or CEDE'd). Signed-off-by: Robert Jennings Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit e374a2ff991dc8b5c10f23849d264373878a9e39 Author: Jaccon Bastiaansen Date: Mon May 13 17:28:27 2013 +0100 ARM: 7720/1: ARM v6/v7 cmpxchg64 shouldn't clear upper 32 bits of the old/new value commit 6eabb3301b1facee669d9938f7c5a0295c21d71d upstream. The implementation of cmpxchg64() for the ARM v6 and v7 architecture casts parameter 2 and 3 (the old and new 64bit values) to an unsigned long before calling the atomic_cmpxchg64() function. This clears the top 32 bits of the old and new values, resulting in the wrong values being compare-exchanged. Luckily, this only appears to be used for 64-bit sched_clock, which we don't (yet) have on ARM. This bug was introduced by commit 3e0f5a15f500 ("ARM: 7404/1: cmpxchg64: use atomic64 and local64 routines for cmpxchg64"). Acked-by: Will Deacon Signed-off-by: Jaccon Bastiaansen Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 903bded00704581799e0bd6f4e0dde06a351f9c2 Author: Konrad Rzeszutek Wilk Date: Wed May 8 12:13:03 2013 -0400 x86/microcode: Add local mutex to fix physical CPU hot-add deadlock commit 074d72ff57f65de779e2f70d5906964c0ba1c123 upstream. This can easily be triggered if a new CPU is added (via ACPI hotplug mechanism) and from user-space you do: echo 1 > /sys/devices/system/cpu/cpu3/online (or wait for UDEV to do it) on a newly appeared physical CPU. The deadlock is that the "store_online" in drivers/base/cpu.c takes the cpu_hotplug_driver_lock() lock, then calls "cpu_up". "cpu_up" eventually ends up calling "save_mc_for_early" which also takes the cpu_hotplug_driver_lock() lock. And here is that lockdep thinks of it: smpboot: Stack at about ffff880075c39f44 smpboot: CPU3: has booted. microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x25 ============================================= [ INFO: possible recursive locking detected ] 3.9.0upstream-10129-g167af0e #1 Not tainted --------------------------------------------- sh/2487 is trying to acquire lock: (x86_cpu_hotplug_driver_mutex){+.+.+.}, at: [] cpu_hotplug_driver_lock+0x12/0x20 but task is already holding lock: (x86_cpu_hotplug_driver_mutex){+.+.+.}, at: [] cpu_hotplug_driver_lock+0x12/0x20 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(x86_cpu_hotplug_driver_mutex); lock(x86_cpu_hotplug_driver_mutex); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by sh/2487: #0: (sb_writers#5){.+.+.+}, at: [] vfs_write+0x17d/0x190 #1: (&buffer->mutex){+.+.+.}, at: [] sysfs_write_file+0x3f/0x160 #2: (s_active#20){.+.+.+}, at: [] sysfs_write_file+0xc8/0x160 #3: (x86_cpu_hotplug_driver_mutex){+.+.+.}, at: [] cpu_hotplug_driver_lock+0x12/0x20 #4: (cpu_add_remove_lock){+.+.+.}, at: [] cpu_maps_update_begin+0x12/0x20 #5: (cpu_hotplug.lock){+.+.+.}, at: [] cpu_hotplug_begin+0x27/0x60 Suggested-and-Acked-by: Borislav Petkov Signed-off-by: Konrad Rzeszutek Wilk Cc: fenghua.yu@intel.com Cc: xen-devel@lists.xensource.com Link: http://lkml.kernel.org/r/1368029583-23337-1-git-send-email-konrad.wilk@oracle.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit ee7122adfa3f0b3c4cfa1547246abf30c74d7fe0 Author: Lachlan McIlroy Date: Sun May 5 23:10:00 2013 -0400 ext4: limit group search loop for non-extent files commit e6155736ad76b2070652745f9e54cdea3f0d8567 upstream. In the case where we are allocating for a non-extent file, we must limit the groups we allocate from to those below 2^32 blocks, and ext4_mb_regular_allocator() attempts to do this initially by putting a cap on ngroups for the subsequent search loop. However, the initial target group comes in from the allocation context (ac), and it may already be beyond the artificially limited ngroups. In this case, the limit if (group == ngroups) group = 0; at the top of the loop is never true, and the loop will run away. Catch this case inside the loop and reset the search to start at group 0. [sandeen@redhat.com: add commit msg & comments] Signed-off-by: Lachlan McIlroy Signed-off-by: Eric Sandeen Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 23b929f9c3313a106ca9481b374fd45e41152a33 Author: Steven Rostedt (Red Hat) Date: Tue May 14 15:40:48 2013 -0400 tracing: Fix leaks of filter preds commit 60705c89460fdc7227f2d153b68b3f34814738a4 upstream. Special preds are created when folding a series of preds that can be done in serial. These are allocated in an ops field of the pred structure. But they were never freed, causing memory leaks. This was discovered using the kmemleak checker: unreferenced object 0xffff8800797fd5e0 (size 32): comm "swapper/0", pid 1, jiffies 4294690605 (age 104.608s) hex dump (first 32 bytes): 00 00 01 00 03 00 05 00 07 00 09 00 0b 00 0d 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmemleak_alloc+0x73/0x98 [] kmemleak_alloc_recursive.constprop.42+0x16/0x18 [] __kmalloc+0xd7/0x125 [] kcalloc.constprop.24+0x2d/0x2f [] fold_pred_tree_cb+0xa9/0xf4 [] walk_pred_tree+0x47/0xcc [] replace_preds.isra.20+0x6f8/0x72f [] create_filter+0x4e/0x8b [] ftrace_test_event_filter+0x5a/0x155 [] do_one_initcall+0xa0/0x137 [] kernel_init_freeable+0x14d/0x1dc [] kernel_init+0xe/0xdb [] ret_from_fork+0x7c/0xb0 [] 0xffffffffffffffff Signed-off-by: Steven Rostedt Cc: Tom Zanussi Signed-off-by: Greg Kroah-Hartman commit c25c0eb5e30cb3666f8d8d75f4994383ac361592 Author: Thomas Gleixner Date: Fri May 3 15:02:50 2013 +0200 tick: Cleanup NOHZ per cpu data on cpu down commit 4b0c0f294f60abcdd20994a8341a95c8ac5eeb96 upstream. Prarit reported a crash on CPU offline/online. The reason is that on CPU down the NOHZ related per cpu data of the dead cpu is not cleaned up. If at cpu online an interrupt happens before the per cpu tick device is registered the irq_enter() check potentially sees stale data and dereferences a NULL pointer. Cleanup the data after the cpu is dead. Reported-by: Prarit Bhargava Cc: Mike Galbraith Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1305031451561.2886@ionos Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 3715b5faca27616b1c488a61a1339480b7d06a76 Author: Tirupathi Reddy Date: Tue May 14 13:59:02 2013 +0530 timer: Don't reinitialize the cpu base lock during CPU_UP_PREPARE commit 42a5cf46cd56f46267d2a9fcf2655f4078cd3042 upstream. An inactive timer's base can refer to a offline cpu's base. In the current code, cpu_base's lock is blindly reinitialized each time a CPU is brought up. If a CPU is brought online during the period that another thread is trying to modify an inactive timer on that CPU with holding its timer base lock, then the lock will be reinitialized under its feet. This leads to following SPIN_BUG(). <0> BUG: spinlock already unlocked on CPU#3, kworker/u:3/1466 <0> lock: 0xe3ebe000, .magic: dead4ead, .owner: kworker/u:3/1466, .owner_cpu: 1 <4> [] (unwind_backtrace+0x0/0x11c) from [] (do_raw_spin_unlock+0x40/0xcc) <4> [] (do_raw_spin_unlock+0x40/0xcc) from [] (_raw_spin_unlock+0x8/0x30) <4> [] (_raw_spin_unlock+0x8/0x30) from [] (mod_timer+0x294/0x310) <4> [] (mod_timer+0x294/0x310) from [] (queue_delayed_work_on+0x104/0x120) <4> [] (queue_delayed_work_on+0x104/0x120) from [] (sdhci_msm_bus_voting+0x88/0x9c) <4> [] (sdhci_msm_bus_voting+0x88/0x9c) from [] (sdhci_disable+0x40/0x48) <4> [] (sdhci_disable+0x40/0x48) from [] (mmc_release_host+0x4c/0xb0) <4> [] (mmc_release_host+0x4c/0xb0) from [] (mmc_sd_detect+0x90/0xfc) <4> [] (mmc_sd_detect+0x90/0xfc) from [] (mmc_rescan+0x7c/0x2c4) <4> [] (mmc_rescan+0x7c/0x2c4) from [] (process_one_work+0x27c/0x484) <4> [] (process_one_work+0x27c/0x484) from [] (worker_thread+0x210/0x3b0) <4> [] (worker_thread+0x210/0x3b0) from [] (kthread+0x80/0x8c) <4> [] (kthread+0x80/0x8c) from [] (kernel_thread_exit+0x0/0x8) As an example, this particular crash occurred when CPU #3 is executing mod_timer() on an inactive timer whose base is refered to offlined CPU #2. The code locked the timer_base corresponding to CPU #2. Before it could proceed, CPU #2 came online and reinitialized the spinlock corresponding to its base. Thus now CPU #3 held a lock which was reinitialized. When CPU #3 finally ended up unlocking the old cpu_base corresponding to CPU #2, we hit the above SPIN_BUG(). CPU #0 CPU #3 CPU #2 ------ ------- ------- ..... ...... mod_timer() lock_timer_base spin_lock_irqsave(&base->lock) cpu_up(2) ..... ...... init_timers_cpu() .... ..... spin_lock_init(&base->lock) ..... spin_unlock_irqrestore(&base->lock) ...... Allocation of per_cpu timer vector bases is done only once under "tvec_base_done[]" check. In the current code, spinlock_initialization of base->lock isn't under this check. When a CPU is up each time the base lock is reinitialized. Move base spinlock initialization under the check. Signed-off-by: Tirupathi Reddy Link: http://lkml.kernel.org/r/1368520142-4136-1-git-send-email-tirupath@codeaurora.org Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit d96ac6f2cda4c2e1c7773c37ce9017d3870be5bc Author: John Stultz Date: Wed Apr 24 11:32:56 2013 -0700 time: Revert ALWAYS_USE_PERSISTENT_CLOCK compile time optimizaitons commit b4f711ee03d28f776fd2324fd0bd999cc428e4d2 upstream. Kay Sievers noted that the ALWAYS_USE_PERSISTENT_CLOCK config, which enables some minor compile time optimization to avoid uncessary code in mostly the suspend/resume path could cause problems for userland. In particular, the dependency for RTC_HCTOSYS on !ALWAYS_USE_PERSISTENT_CLOCK, which avoids setting the time twice and simplifies suspend/resume, has the side effect of causing the /sys/class/rtc/rtcN/hctosys flag to always be zero, and this flag is commonly used by udev to setup the /dev/rtc symlink to /dev/rtcN, which can cause pain for older applications. While the udev rules could use some work to be less fragile, breaking userland should strongly be avoided. Additionally the compile time optimizations are fairly minor, and the code being optimized is likely to be reworked in the future, so lets revert this change. Reported-by: Kay Sievers Signed-off-by: John Stultz Cc: Feng Tang Cc: Jason Gunthorpe Link: http://lkml.kernel.org/r/1366828376-18124-1-git-send-email-john.stultz@linaro.org Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 93d927e2e81b0d0b2aa940c7a1ea62ba840d4924 Author: Jeff Layton Date: Fri Apr 12 15:16:32 2013 -0400 audit: vfs: fix audit_inode call in O_CREAT case of do_last commit 33e2208acfc15ce00d3dd13e839bf6434faa2b04 upstream. Jiri reported a regression in auditing of open(..., O_CREAT) syscalls. In older kernels, creating a file with open(..., O_CREAT) created audit_name records that looked like this: type=PATH msg=audit(1360255720.628:64): item=1 name="/abc/foo" inode=138810 dev=fd:00 mode=0100640 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:default_t:s0 type=PATH msg=audit(1360255720.628:64): item=0 name="/abc/" inode=138635 dev=fd:00 mode=040750 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:default_t:s0 ...in recent kernels though, they look like this: type=PATH msg=audit(1360255402.886:12574): item=2 name=(null) inode=264599 dev=fd:00 mode=0100640 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:default_t:s0 type=PATH msg=audit(1360255402.886:12574): item=1 name=(null) inode=264598 dev=fd:00 mode=040750 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:default_t:s0 type=PATH msg=audit(1360255402.886:12574): item=0 name="/abc/foo" inode=264598 dev=fd:00 mode=040750 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:default_t:s0 Richard bisected to determine that the problems started with commit bfcec708, but the log messages have changed with some later audit-related patches. The problem is that this audit_inode call is passing in the parent of the dentry being opened, but audit_inode is being called with the parent flag false. This causes later audit_inode and audit_inode_child calls to match the wrong entry in the audit_names list. This patch simply sets the flag to properly indicate that this inode represents the parent. With this, the audit_names entries are back to looking like they did before. Reported-by: Jiri Jaburek Signed-off-by: Jeff Layton Test By: Richard Guy Briggs Signed-off-by: Eric Paris Signed-off-by: Greg Kroah-Hartman commit 16f0b63b936e10008e1e40ee2bfa219f8a14645a Author: Anton Blanchard Date: Wed Jan 9 10:46:17 2013 +1100 audit: Syscall rules are not applied to existing processes on non-x86 commit cdee3904b4ce7c03d1013ed6dd704b43ae7fc2e9 upstream. Commit b05d8447e782 (audit: inline audit_syscall_entry to reduce burden on archs) changed audit_syscall_entry to check for a dummy context before calling __audit_syscall_entry. Unfortunately the dummy context state is maintained in __audit_syscall_entry so once set it never gets cleared, even if the audit rules change. As a result, if there are no auditing rules when a process starts then it will never be subject to any rules added later. x86 doesn't see this because it has an assembly fast path that calls directly into __audit_syscall_entry. I noticed this issue when working on audit performance optimisations. I wrote a set of simple test cases available at: http://ozlabs.org/~anton/junkcode/audit_tests.tar.gz 02_new_rule.py fails without the patch and passes with it. The test case clears all rules, starts a process, adds a rule then verifies the process produces a syscall audit record. Signed-off-by: Anton Blanchard Signed-off-by: Eric Paris Signed-off-by: Greg Kroah-Hartman commit ccb2c9da1fc6f9a4eeb72ce4a5991bf16c95bb28 Author: James Bottomley Date: Wed Apr 24 14:02:53 2013 -0700 SCSI: sd: fix array cache flushing bug causing performance problems commit 39c60a0948cc06139e2fbfe084f83cb7e7deae3b upstream. Some arrays synchronize their full non volatile cache when the sd driver sends a SYNCHRONIZE CACHE command. Unfortunately, they can have Terrabytes of this and we send a SYNCHRONIZE CACHE for every barrier if an array reports it has a writeback cache. This leads to massive slowdowns on journalled filesystems. The fix is to allow userspace to turn off the writeback cache setting as a temporary measure (i.e. without doing the MODE SELECT to write it back to the device), so even though the device reported it has a writeback cache, the user, knowing that the cache is non volatile and all they care about is filesystem correctness, can turn that bit off in the kernel and avoid the performance ruinous (and safety irrelevant) SYNCHRONIZE CACHE commands. The way you do this is add a 'temporary' prefix when performing the usual cache setting operations, so echo temporary write through > /sys/class/scsi_disk//cache_type Reported-by: Ric Wheeler Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit db9f69dc2d86546eb31c29be637fb70633672fea Author: Konrad Rzeszutek Wilk Date: Sun May 5 09:30:09 2013 -0400 xen/vcpu/pvhvm: Fix vcpu hotplugging hanging. commit 7f1fc268c47491fd5e63548f6415fc8604e13003 upstream. If a user did: echo 0 > /sys/devices/system/cpu/cpu1/online echo 1 > /sys/devices/system/cpu/cpu1/online we would (this a build with DEBUG enabled) get to: smpboot: ++++++++++++++++++++=_---CPU UP 1 .. snip.. smpboot: Stack at about ffff880074c0ff44 smpboot: CPU1: has booted. and hang. The RCU mechanism would kick in an try to IPI the CPU1 but the IPIs (and all other interrupts) would never arrive at the CPU1. At first glance at least. A bit digging in the hypervisor trace shows that (using xenanalyze): [vla] d4v1 vec 243 injecting 0.043163027 --|x d4v1 intr_window vec 243 src 5(vector) intr f3 ] 0.043163639 --|x d4v1 vmentry cycles 1468 ] 0.043164913 --|x d4v1 vmexit exit_reason PENDING_INTERRUPT eip ffffffff81673254 0.043164913 --|x d4v1 inj_virq vec 243 real [vla] d4v1 vec 243 injecting 0.043164913 --|x d4v1 intr_window vec 243 src 5(vector) intr f3 ] 0.043165526 --|x d4v1 vmentry cycles 1472 ] 0.043166800 --|x d4v1 vmexit exit_reason PENDING_INTERRUPT eip ffffffff81673254 0.043166800 --|x d4v1 inj_virq vec 243 real [vla] d4v1 vec 243 injecting there is a pending event (subsequent debugging shows it is the IPI from the VCPU0 when smpboot.c on VCPU1 has done "set_cpu_online(smp_processor_id(), true)") and the guest VCPU1 is interrupted with the callback IPI (0xf3 aka 243) which ends up calling __xen_evtchn_do_upcall. The __xen_evtchn_do_upcall seems to do *something* but not acknowledge the pending events. And the moment the guest does a 'cli' (that is the ffffffff81673254 in the log above) the hypervisor is invoked again to inject the IPI (0xf3) to tell the guest it has pending interrupts. This repeats itself forever. The culprit was the per_cpu(xen_vcpu, cpu) pointer. At the bootup we set each per_cpu(xen_vcpu, cpu) to point to the shared_info->vcpu_info[vcpu] but later on use the VCPUOP_register_vcpu_info to register per-CPU structures (xen_vcpu_setup). This is used to allow events for more than 32 VCPUs and for performance optimizations reasons. When the user performs the VCPU hotplug we end up calling the the xen_vcpu_setup once more. We make the hypercall which returns -EINVAL as it does not allow multiple registration calls (and already has re-assigned where the events are being set). We pick the fallback case and set per_cpu(xen_vcpu, cpu) to point to the shared_info->vcpu_info[vcpu] (which is a good fallback during bootup). However the hypervisor is still setting events in the register per-cpu structure (per_cpu(xen_vcpu_info, cpu)). As such when the events are set by the hypervisor (such as timer one), and when we iterate in __xen_evtchn_do_upcall we end up reading stale events from the shared_info->vcpu_info[vcpu] instead of the per_cpu(xen_vcpu_info, cpu) structures. Hence we never acknowledge the events that the hypervisor has set and the hypervisor keeps on reminding us to ack the events which we never do. The fix is simple. Don't on the second time when xen_vcpu_setup is called over-write the per_cpu(xen_vcpu, cpu) if it points to per_cpu(xen_vcpu_info). Acked-by: Stefano Stabellini Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 159590f26d8658d627fee5841ffbe8ac0670031d Author: Li Zefan Date: Thu May 9 15:08:15 2013 +0800 shm: fix null pointer deref when userspace specifies invalid hugepage size commit 091d0d55b286c9340201b4ed4470be87fc568228 upstream. Dave reported an oops triggered by trinity: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: newseg+0x10d/0x390 PGD cf8c1067 PUD cf8c2067 PMD 0 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC CPU: 2 PID: 7636 Comm: trinity-child2 Not tainted 3.9.0+#67 ... Call Trace: ipcget+0x182/0x380 SyS_shmget+0x5a/0x60 tracesys+0xdd/0xe2 This bug was introduced by commit af73e4d9506d ("hugetlbfs: fix mmap failure in unaligned size request"). Reported-by: Dave Jones Signed-off-by: Li Zefan Reviewed-by: Naoya Horiguchi Acked-by: Rik van Riel Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7b44587e0383980f76da1569249ec8fa662b9411 Author: Shuah Khan Date: Sat Mar 9 11:39:22 2013 -0700 hp_accel: Ignore the error from lis3lv02d_poweron() at resume commit 7783819920ca52fc582a2782f654fe6ed373f465 upstream. The error in lis3lv02_poweron() is harmless in the resume path, so we should ignore it. It is inline with the other usages of lis3lv02_poweron() and matches the 3.0 code for this routine. This patch is in suse git and might have missed making it into the mainline. opensuse - commit id: 66ccdac87c322cf7af12bddba8c805af640b1cff Signed-off-by: Takashi Iwai Signed-off-by: Shuah Khan Signed-off-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman commit 59d7914fea48887beed1d5dc1522360e9874e4d7 Author: Jeff Layton Date: Thu May 9 08:36:23 2013 -0400 nfsd: fix oops when legacy_recdir_name_error is passed a -ENOENT error commit 7255e716b1757dc10fa5e3a4d2eaab303ff9f7b6 upstream. Toralf reported the following oops to the linux-nfs mailing list: -----------------[snip]------------------ NFSD: unable to generate recoverydir name (-2). NFSD: disabling legacy clientid tracking. Reboot recovery will not function correctly! BUG: unable to handle kernel NULL pointer dereference at 000003c8 IP: [] nfsd4_client_tracking_exit+0x11/0x50 [nfsd] *pdpt = 000000002ba33001 *pde = 0000000000000000 Oops: 0000 [#1] SMP Modules linked in: loop nfsd auth_rpcgss ipt_MASQUERADE xt_owner xt_multiport ipt_REJECT xt_tcpudp xt_recent xt_conntrack nf_conntrack_ftp xt_limit xt_LOG iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_filter ip_tables x_tables af_packet pppoe pppox ppp_generic slhc bridge stp llc tun arc4 iwldvm mac80211 coretemp kvm_intel uvcvideo sdhci_pci sdhci mmc_core videobuf2_vmalloc videobuf2_memops usblp videobuf2_core i915 iwlwifi psmouse videodev cfg80211 kvm fbcon bitblit cfbfillrect acpi_cpufreq mperf evdev softcursor font cfbimgblt i2c_algo_bit cfbcopyarea intel_agp intel_gtt drm_kms_helper snd_hda_codec_conexant drm agpgart fb fbdev tpm_tis thinkpad_acpi tpm nvram e1000e rfkill thermal ptp wmi pps_core tpm_bios 8250_pci processor 8250 ac snd_hda_intel snd_hda_codec snd_pcm battery video i2c_i801 snd_page_alloc snd_timer button serial_core i2c_core snd soundcore thermal_sys hwmon aesni_intel ablk_helper cryp td lrw aes_i586 xts gf128mul cbc fuse nfs lockd sunrpc dm_crypt dm_mod hid_monterey hid_microsoft hid_logitech hid_ezkey hid_cypress hid_chicony hid_cherry hid_belkin hid_apple hid_a4tech hid_generic usbhid hid sr_mod cdrom sg [last unloaded: microcode] Pid: 6374, comm: nfsd Not tainted 3.9.1 #6 LENOVO 4180F65/4180F65 EIP: 0060:[] EFLAGS: 00010202 CPU: 0 EIP is at nfsd4_client_tracking_exit+0x11/0x50 [nfsd] EAX: 00000000 EBX: fffffffe ECX: 00000007 EDX: 00000007 ESI: eb9dcb00 EDI: eb2991c0 EBP: eb2bde38 ESP: eb2bde34 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 CR0: 80050033 CR2: 000003c8 CR3: 2ba80000 CR4: 000407f0 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process nfsd (pid: 6374, ti=eb2bc000 task=eb2711c0 task.ti=eb2bc000) Stack: fffffffe eb2bde4c f90a3e0c f90a7754 fffffffe eb0a9c00 eb2bdea0 f90a41ed eb2991c0 1b270000 eb2991c0 eb2bde7c f9099ce9 eb2bde98 0129a020 eb29a020 eb2bdecc eb2991c0 eb2bdea8 f9099da5 00000000 eb9dcb00 00000001 67822f08 Call Trace: [] legacy_recdir_name_error+0x3c/0x40 [nfsd] [] nfsd4_create_clid_dir+0x15d/0x1c0 [nfsd] [] ? nfsd4_lookup_stateid+0x99/0xd0 [nfsd] [] ? nfs4_preprocess_seqid_op+0x85/0x100 [nfsd] [] nfsd4_client_record_create+0x37/0x50 [nfsd] [] nfsd4_open_confirm+0xfe/0x130 [nfsd] [] ? nfsd4_encode_operation+0x61/0x90 [nfsd] [] ? nfsd4_free_stateid+0xc0/0xc0 [nfsd] [] nfsd4_proc_compound+0x41b/0x530 [nfsd] [] nfsd_dispatch+0x8b/0x1a0 [nfsd] [] svc_process+0x3dd/0x640 [sunrpc] [] nfsd+0xad/0x110 [nfsd] [] ? nfsd_destroy+0x70/0x70 [nfsd] [] kthread+0x94/0xa0 [] ret_from_kernel_thread+0x1b/0x28 [] ? flush_kthread_work+0xd0/0xd0 Code: 86 b0 00 00 00 90 c5 0a f9 c7 04 24 70 76 0a f9 e8 74 a9 3d c8 eb ba 8d 76 00 55 89 e5 53 66 66 66 66 90 8b 15 68 c7 0a f9 85 d2 <8b> 88 c8 03 00 00 74 2c 3b 11 77 28 8b 5c 91 08 85 db 74 22 8b EIP: [] nfsd4_client_tracking_exit+0x11/0x50 [nfsd] SS:ESP 0068:eb2bde34 CR2: 00000000000003c8 ---[ end trace 09e54015d145c9c6 ]--- The problem appears to be a regression that was introduced in commit 9a9c6478 "nfsd: make NFSv4 recovery client tracking options per net". Prior to that commit, it was safe to pass a NULL net pointer to nfsd4_client_tracking_exit in the legacy recdir case, and legacy_recdir_name_error did so. After that comit, the net pointer must be valid. This patch just fixes legacy_recdir_name_error to pass in a valid net pointer to that function. Reported-and-tested-by: Toralf Förster Cc: Stanislav Kinsbursky Signed-off-by: Jeff Layton Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit faad5f5c7478207a175f41d676db58b8fc8449f2 Author: J. Bruce Fields Date: Fri May 3 16:09:09 2013 -0400 nfsd4: don't allow owner override on 4.1 CLAIM_FH opens commit 9f415eb25574db4b73a9a712a4438e41dc284922 upstream. The Linux client is using CLAIM_FH to implement regular opens, not just recovery cases, so it depends on the server to check permissions correctly. Therefore the owner override, which may make sense in the delegation recovery case, isn't right in the CLAIM_FH case. Symptoms: on a client with 49f9a0fafd844c32f2abada047c0b9a5ba0d6255 "NFSv4.1: Enable open-by-filehandle", Bryan noticed this: touch test.txt chmod 000 test.txt echo test > test.txt succeeding. Reported-by: Bryan Schumaker Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 6bc7f6efc8451170ce0b70f3f5e08202109e1702 Author: Stanislaw Gruszka Date: Tue Apr 30 11:35:06 2013 +0200 sched: Avoid prev->stime underflow commit 68aa8efcd1ab961e4684ef5af32f72a6ec1911de upstream. Dave Hansen reported strange utime/stime values on his system: https://lkml.org/lkml/2013/4/4/435 This happens because prev->stime value is bigger than rtime value. Root of the problem are non-monotonic rtime values (i.e. current rtime is smaller than previous rtime) and that should be debugged and fixed. But since problem did not manifest itself before commit 62188451f0d63add7ad0cd2a1ae269d600c1663d "cputime: Avoid multiplication overflow on utime scaling", it should be threated as regression, which we can easily fixed on cputime_adjust() function. For now, let's apply this fix, but further work is needed to fix root of the problem. Reported-and-tested-by: Dave Hansen Signed-off-by: Stanislaw Gruszka Cc: Frederic Weisbecker Cc: rostedt@goodmis.org Cc: Linus Torvalds Cc: Dave Hansen Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1367314507-9728-3-git-send-email-sgruszka@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 859a8c0d7865dad5fa818f311ae984fbe5cd5483 Author: Stanislaw Gruszka Date: Tue Apr 30 11:35:07 2013 +0200 Revert "math64: New div64_u64_rem helper" commit f3002134158092178be81339ec5a22ff80e6c308 upstream. This reverts commit f792685006274a850e6cc0ea9ade275ccdfc90bc. The cputime scaling code was changed/fixed and does not need the div64_u64_rem() primitive anymore. It has no other users, so let's remove them. Signed-off-by: Stanislaw Gruszka Cc: Frederic Weisbecker Cc: rostedt@goodmis.org Cc: Linus Torvalds Cc: Dave Hansen Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1367314507-9728-4-git-send-email-sgruszka@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit f25d7d1c9ba805c3d588ed3bbb336d05cfc1f1de Author: Stanislaw Gruszka Date: Tue Apr 30 11:35:05 2013 +0200 sched: Do not account bogus utime commit 772c808a252594692972773f6ee41c289b8e0b2a upstream. Due to rounding in scale_stime(), for big numbers, scaled stime values will grow in chunks. Since rtime grow in jiffies and we calculate utime like below: prev->stime = max(prev->stime, stime); prev->utime = max(prev->utime, rtime - prev->stime); we could erroneously account stime values as utime. To prevent that only update prev->{u,s}time values when they are smaller than current rtime. Signed-off-by: Stanislaw Gruszka Cc: Frederic Weisbecker Cc: rostedt@goodmis.org Cc: Linus Torvalds Cc: Dave Hansen Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1367314507-9728-2-git-send-email-sgruszka@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 434c491303aff685d0b7246367d83a4833491146 Author: Stanislaw Gruszka Date: Tue Apr 30 17:14:42 2013 +0200 sched: Avoid cputime scaling overflow commit 55eaa7c1f511af5fb6ef808b5328804f4d4e5243 upstream. Here is patch, which adds Linus's cputime scaling algorithm to the kernel. This is a follow up (well, fix) to commit d9a3c9823a2e6a543eb7807fb3d15d8233817ec5 ("sched: Lower chances of cputime scaling overflow") which commit tried to avoid multiplication overflow, but did not guarantee that the overflow would not happen. Linus crated a different algorithm, which completely avoids the multiplication overflow by dropping precision when numbers are big. It was tested by me and it gives good relative error of scaled numbers. Testing method is described here: http://marc.info/?l=linux-kernel&m=136733059505406&w=2 Originally-From: Linus Torvalds Signed-off-by: Stanislaw Gruszka Cc: Frederic Weisbecker Cc: rostedt@goodmis.org Cc: Dave Hansen Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20130430151441.GC10465@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 96fc7a7d42897d38d97e5f79c3f7a54c190f98c0 Author: Frederic Weisbecker Date: Wed Feb 20 18:54:55 2013 +0100 sched: Lower chances of cputime scaling overflow commit d9a3c9823a2e6a543eb7807fb3d15d8233817ec5 upstream. Some users have reported that after running a process with hundreds of threads on intensive CPU-bound loads, the cputime of the group started to freeze after a few days. This is due to how we scale the tick-based cputime against the scheduler precise execution time value. We add the values of all threads in the group and we multiply that against the sum of the scheduler exec runtime of the whole group. This easily overflows after a few days/weeks of execution. A proposed solution to solve this was to compute that multiplication on stime instead of utime: 62188451f0d63add7ad0cd2a1ae269d600c1663d ("cputime: Avoid multiplication overflow on utime scaling") The rationale behind that was that it's easy for a thread to spend most of its time in userspace under intensive CPU-bound workload but it's much harder to do CPU-bound intensive long run in the kernel. This postulate got defeated when a user recently reported he was still seeing cputime freezes after the above patch. The workload that triggers this issue relates to intensive networking workloads where most of the cputime is consumed in the kernel. To reduce much more the opportunities for multiplication overflow, lets reduce the multiplication factors to the remainders of the division between sched exec runtime and cputime. Assuming the difference between these shouldn't ever be that large, it could work on many situations. This gets the same results as in the upstream scaling code except for a small difference: the upstream code always rounds the results to the nearest integer not greater to what would be the precise result. The new code rounds to the nearest integer either greater or not greater. In practice this difference probably shouldn't matter but it's worth mentioning. If this solution appears not to be enough in the end, we'll need to partly revert back to the behaviour prior to commit 0cf55e1ec08bb5a22e068309e2d8ba1180ab4239 ("sched, cputime: Introduce thread_group_times()") Back then, the scaling was done on exit() time before adding the cputime of an exiting thread to the signal struct. And then we'll need to scale one-by-one the live threads cputime in thread_group_cputime(). The drawback may be a slightly slower code on exit time. Signed-off-by: Frederic Weisbecker Cc: Stanislaw Gruszka Cc: Steven Rostedt Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Andrew Morton Signed-off-by: Stanislaw Gruszka Acked-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit c459e23aff09053befa7459a99dc91840a6aec31 Author: Frederic Weisbecker Date: Tue Mar 5 18:05:46 2013 +0100 math64: New div64_u64_rem helper commit f792685006274a850e6cc0ea9ade275ccdfc90bc upstream. Provide an extended version of div64_u64() that also returns the remainder of the division. We are going to need this to refine the cputime scaling code. Signed-off-by: Frederic Weisbecker Cc: Stanislaw Gruszka Cc: Steven Rostedt Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Andrew Morton Acked-by: Ingo Molnar Signed-off-by: Stanislaw Gruszka Signed-off-by: Greg Kroah-Hartman commit 3dc73aa4030321924423ebc662dcf6f382fef5b3 Author: Wei Yongjun Date: Fri May 10 14:37:14 2013 +0100 dm cache: fix error return code in cache_create commit fa4d683af3693863bec761e2761a07e4c1351f86 upstream. Return -ENOMEM if memory allocation fails in cache_create instead of 0 (to avoid NULL pointer dereference). Signed-off-by: Wei Yongjun Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit 62253ab07cbbb924ba69cbb4e050b42b008a6884 Author: Wei Yongjun Date: Fri May 10 14:37:15 2013 +0100 dm snapshot: fix error return code in snapshot_ctr commit 09e8b813897a0f85bb401435d009228644c81214 upstream. Return -ENOMEM instead of success if unable to allocate pending exception mempool in snapshot_ctr. Signed-off-by: Wei Yongjun Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit 8f9341a6a18470c0e91ba23c82612c6237c68562 Author: Mikulas Patocka Date: Fri May 10 14:37:15 2013 +0100 dm bufio: avoid a possible __vmalloc deadlock commit 502624bdad3dba45dfaacaf36b7d83e39e74b2d2 upstream. This patch uses memalloc_noio_save to avoid a possible deadlock in dm-bufio. (it could happen only with large block size, at most PAGE_SIZE << MAX_ORDER (typically 8MiB). __vmalloc doesn't fully respect gfp flags. The specified gfp flags are used for allocation of requested pages, structures vmap_area, vmap_block and vm_struct and the radix tree nodes. However, the kernel pagetables are allocated always with GFP_KERNEL. Thus the allocation of pagetables can recurse back to the I/O layer and cause a deadlock. This patch uses the function memalloc_noio_save to set per-process PF_MEMALLOC_NOIO flag and the function memalloc_noio_restore to restore it. When this flag is set, all allocations in the process are done with implied GFP_NOIO flag, thus the deadlock can't happen. This should be backported to stable kernels, but they don't have the PF_MEMALLOC_NOIO flag and memalloc_noio_save/memalloc_noio_restore functions. So, PF_MEMALLOC should be set and restored instead. Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit ce397c5eb27f56a440a22c594293f2f7a56fa821 Author: Mike Snitzer Date: Fri May 10 14:37:14 2013 +0100 dm stripe: fix regression in stripe_width calculation commit d793e684277124d55c5d2444007e224635821346 upstream. Fix a regression in the calculation of the stripe_width in the dm stripe target which led to incorrect processing of device limits. The stripe_width is the stripe device length divided by the number of stripes. The group of commits in the range f14fa69 ("dm stripe: fix size test") to eb850de ("dm stripe: support for non power of 2 chunksize") interfered with each other (a merging error) and led to the stripe_width being set incorrectly to the stripe device length divided by chunk_size * stripe_count. For example, a stripe device's table with: 0 33553920 striped 3 512 ... should result in a stripe_width of 11184640 (33553920 / 3), but due to the bug it was getting set to 21845 (33553920 / (512 * 3)). The impact of this bug is that device topologies that previously worked fine with the stripe target are no longer considered valid. In particular, there is a higher risk of seeing this issue if one of the stripe devices has a 4K logical block size. Resulting in an error message like this: "device-mapper: table: 253:4: len=21845 not aligned to h/w logical block size 4096 of dm-1" The fix is to swap the order of the divisions and to use a temporary variable for the second one, so that width retains the intended value. Signed-off-by: Mike Snitzer Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit e861593f411a2564a3b376144b3a616f3dd2e8d8 Author: Mike Snitzer Date: Fri May 10 14:37:16 2013 +0100 dm table: fix write same support commit dc019b21fb92d620a3b52ccecc135ac968a7c7ec upstream. If device_not_write_same_capable() returns true then the iterate_devices loop in dm_table_supports_write_same() should return false. Reported-by: Bharata B Rao Signed-off-by: Mike Snitzer Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit 82d72f05272eaf6ea37d63673069ce0f0dd8387a Author: Viresh Kumar Date: Fri Mar 15 14:18:20 2013 +0530 DMA: OF: Check properties value before running be32_to_cpup() on it commit 9a188eb126aa7bf27077ee46fcb914898d6fc281 upstream. In of_dma_controller_register() routine we are calling of_get_property() as an parameter to be32_to_cpup(). In case the property doesn't exist we will get a crash. This patch changes this code to check if we got a valid property first and then runs be32_to_cpup() on it. Signed-off-by: Viresh Kumar Signed-off-by: Vinod Koul Signed-off-by: Robert Richter Signed-off-by: Greg Kroah-Hartman commit 7a6ff79b0370eb1d5036e8a35df2f5adea385c51 Author: Takashi Iwai Date: Sat May 4 10:57:16 2013 +0200 ALSA: hda - Fix 3.9 regression of EAPD init on Conexant codecs commit ff359b14919c379a365233aa2e1dd469efac8ce8 upstream. The older Conexant codecs have up to two EAPDs and these are supposed to be rather statically turned on. The new generic parser code assumes the dynamic on/off per path usage, thus it resulted in the silent output on some machines. This patch fixes the problem by simply assuming the static EAPD on for such old Conexant codecs as we did until 3.8 kernel. Reported-and-tested-by: Christopher K. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9437f0b0729ee7e10df020b51114535e721ecd69 Author: Wang YanQing Date: Tue May 7 11:27:33 2013 +0800 ALSA: HDA: Fix Oops caused by dereference NULL pointer commit 2195b063f6609e4c6268f291683902f25eaf9aa6 upstream. The interrupt handler azx_interrupt will call azx_update_rirb, which may call snd_hda_queue_unsol_event, snd_hda_queue_unsol_event will dereference chip->bus pointer. The problem is we alloc chip->bus in azx_codec_create which will be called after we enable IRQ and enable unsolicited event in azx_probe. This will cause Oops due dereference NULL pointer. I meet it, good luck:) [Rearranged the NULL check before the tracepoint and added another NULL check of bus->workq -- tiwai] Signed-off-by: Wang YanQing Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 06856c2eafeb329352b80556a94c6f84eb6d7017 Author: Takashi Iwai Date: Fri May 10 13:39:50 2013 +0200 Revert "ALSA: hda - Don't set up active streams twice" commit 6c35ae3c327ef4b5f51d3428d2ba47ac2153e882 upstream. This reverts commit affdb62b815b38261f09f9d4ec210a35c7ffb1f3. The commit introduced a regression with AD codecs where the stream is always clean up. Since the patch is just a minor optimization and reverting the commit fixes the issue, let's just revert it. Reported-and-tested-by: Michael Burian Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a58e4edcf73d47ff26456ba162a613db2141b6f7 Author: Bob Moore Date: Wed May 8 04:01:15 2013 +0000 ACPICA: Fix possible buffer overflow during a field unit read operation commit 61388f9e5d93053cf399a356414f31f9b4814c6d upstream. Can only happen under these conditions: 1) The DSDT version is 1, meaning integers are 32-bits. 2) The field is between 33 and 64 bits long. It applies cleanly back to ACPICA 20100806+ (Linux v2.6.37+). Signed-off-by: Bob Moore Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit ccd72f9a3fecf9c882973adf69b8d3a675871e01 Author: Dan Carpenter Date: Tue Apr 30 10:24:41 2013 +0300 ASoC: wm8994: missing break in wm8994_aif3_hw_params() commit 4495e46fe18f198366961bb2b324a694ef8a9b44 upstream. The missing break here means that we always return early and the function is a no-op. Signed-off-by: Dan Carpenter Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2016e20a34b4adbea1ef5f17c5022a20f14810b0 Author: Aaro Koskinen Date: Wed May 8 16:48:00 2013 -0700 ARM: OMAP: RX-51: change probe order of touchscreen and panel SPI devices commit e65f131a14726e5f1b880a528271a52428e5b3a5 upstream. Commit 9fdca9df (spi: omap2-mcspi: convert to module_platform_driver) broke the SPI display/panel driver probe on RX-51/N900. The exact cause is not fully understood, but it seems to be related to the probe order. SPI communication to the panel driver (spi1.2) fails unless the touchscreen (spi1.0) has been probed/initialized before. When the omap2-mcspi driver was converted to a platform driver, it resulted in that the devices are probed immediately after the board registers them in the order they are listed in the board file. Fix the issue by moving the touchscreen before the panel in the SPI device list. The patch fixes the following failure: [ 1.260955] acx565akm spi1.2: invalid display ID [ 1.265899] panel-acx565akm display0: acx_panel_probe panel detect error [ 1.273071] omapdss CORE error: driver probe failed: -19 Tested-by: Sebastian Reichel Signed-off-by: Aaro Koskinen Cc: Pali Rohár Cc: Joni Lapilainen Cc: Tomi Valkeinen Cc: Felipe Balbi Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 6defe2bdc863d4ddc5ea5737f2dc09881f76d7f6 Author: Fernando Luis Vazquez Cao Date: Wed May 1 09:26:23 2013 +0900 HID: reintroduce fix-up for certain Sony RF receivers commit c1e0ac192b48b37f31801c17534ab3d2a9282d84 upstream. It looks like the manual merge 0d69a3c731e120b05b7da9fb976830475a3fbc01 ("Merge branches 'for-3.9/sony' and 'for-3.9/steelseries' into for-linus") accidentally removed Sony RF receiver with USB product id 0x0374 from the "have special driver" list, effectively nullifying a464918419f94a0043d2f549d6defb4c3f69f68a ("HID: add support for Sony RF receiver with USB product id 0x0374"). Add the device back to the list. Signed-off-by: Fernando Luis Vazquez Cao Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit c2b4972016dcc9d883ce5333d97d9454d9ae24e1 Author: Paolo Bonzini Date: Thu May 9 11:32:51 2013 +0200 KVM: emulator: emulate SALC commit 326f578f7e1443bac2333712dd130a261ec15288 upstream. This is an almost-undocumented instruction available in 32-bit mode. I say "almost" undocumented because AMD documents it in their opcode maps just to say that it is unavailable in 64-bit mode (sections "A.2.1 One-Byte Opcodes" and "B.3 Invalid and Reassigned Instructions in 64-Bit Mode"). It is roughly equivalent to "sbb %al, %al" except it does not set the flags. Use fastop to emulate it, but do not use the opcode directly because it would fail if the host is 64-bit! Reported-by: Jun'ichi Nomura Signed-off-by: Paolo Bonzini Signed-off-by: Gleb Natapov Signed-off-by: Greg Kroah-Hartman commit e3ed61f1dcb250148b14c37d62918d6fe9e01070 Author: Paolo Bonzini Date: Thu May 9 11:32:50 2013 +0200 KVM: emulator: emulate XLAT commit 7fa57952d70f5737513d8319395e471d107e4e0d upstream. This is used by SGABIOS, KVM breaks with emulate_invalid_guest_state=1. It is just a MOV in disguise, with a funny source address. Reported-by: Jun'ichi Nomura Signed-off-by: Paolo Bonzini Signed-off-by: Gleb Natapov Signed-off-by: Greg Kroah-Hartman commit a58a4482f3b250cd372182fdbf3d2d34ba79fc17 Author: Paolo Bonzini Date: Thu May 9 11:32:49 2013 +0200 KVM: emulator: emulate AAM commit a035d5c64d08a8ac12d81b596e7fa6d95a73c347 upstream. This is used by SGABIOS, KVM breaks with emulate_invalid_guest_state=1. AAM needs the source operand to be unsigned; do the same in AAD as well for consistency, even though it does not affect the result. Reported-by: Jun'ichi Nomura Signed-off-by: Paolo Bonzini Signed-off-by: Gleb Natapov Signed-off-by: Greg Kroah-Hartman commit f7f76899aa82aae0441f451711f3adff1df580dd Author: Gleb Natapov Date: Wed May 8 18:38:44 2013 +0300 KVM: VMX: fix halt emulation while emulating invalid guest sate commit 8d76c49e9ffeee839bc0b7a3278a23f99101263e upstream. The invalid guest state emulation loop does not check halt_request which causes 100% cpu loop while guest is in halt and in invalid state, but more serious issue is that this leaves halt_request set, so random instruction emulated by vm86 #GP exit can be interpreted as halt which causes guest hang. Fix both problems by handling halt_request in emulation loop. Reported-by: Tomas Papan Tested-by: Tomas Papan Reviewed-by: Paolo Bonzini Signed-off-by: Gleb Natapov Signed-off-by: Greg Kroah-Hartman