commit ef00e58c65808c26f4c9f1c3aa45640d7c99bf56 Author: Ben Hutchings Date: Wed Sep 19 15:05:26 2012 +0100 Linux 3.2.30 commit d228dd20d4c968a688b29cf59d2450c2bdcac018 Author: Linus Torvalds Date: Fri Sep 14 14:48:21 2012 -0700 vfs: make O_PATH file descriptors usable for 'fstat()' commit 55815f70147dcfa3ead5738fd56d3574e2e3c1c2 upstream. We already use them for openat() and friends, but fstat() also wants to be able to use O_PATH file descriptors. This should make it more directly comparable to the O_SEARCH of Solaris. Note that you could already do the same thing with "fstatat()" and an empty path, but just doing "fstat()" directly is simpler and faster, so there is no reason not to just allow it directly. See also commit 332a2e1244bd, which did the same thing for fchdir, for the same reasons. Reported-by: ольга крыжановская Cc: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 7c6430b9b762972e99ff841a4c78d6cc02be8e51 Author: Linus Torvalds Date: Sat Apr 28 14:55:17 2012 -0700 VFS: make vfs_fstat() use f[get|put]_light() commit e994defb7b6813ba6fa7a2a36e86d2455ad1dc35 upstream. Use the *_light() versions that properly avoid doing the file user count updates when they are unnecessary. Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 62ae7bbdbb77a210eb839f34dc0d1923a4842dbd Author: Tyler Hicks Date: Thu Sep 13 12:00:56 2012 -0700 eCryptfs: Copy up attributes of the lower target inode after rename commit 8335eafc2859e1a26282bef7c3d19f3d68868b8a upstream. After calling into the lower filesystem to do a rename, the lower target inode's attributes were not copied up to the eCryptfs target inode. This resulted in the eCryptfs target inode staying around, rather than being evicted, because i_nlink was not updated for the eCryptfs inode. This also meant that eCryptfs didn't do the final iput() on the lower target inode so it stayed around, as well. This would result in a failure to free up space occupied by the target file in the rename() operation. Both target inodes would eventually be evicted when the eCryptfs filesystem was unmounted. This patch calls fsstack_copy_attr_all() after the lower filesystem does its ->rename() so that important inode attributes, such as i_nlink, are updated at the eCryptfs layer. ecryptfs_evict_inode() is now called and eCryptfs can drop its final reference on the lower inode. http://launchpad.net/bugs/561129 Signed-off-by: Tyler Hicks Tested-by: Colin Ian King Signed-off-by: Ben Hutchings commit 705924f5e9051809090eb0b8ec552b41a2718f8b Author: Dave Airlie Date: Fri Sep 14 13:28:23 2012 +1000 drm/nouveau: fix booting with plymouth + dumb support commit 610bd7da160f76f1644ecb4cd7f39511b49a22cc upstream. We noticed a plymouth bug on Fedora 18, and I then noticed this stupid thinko, fixing it fixed the problem with plymouth. Acked-by: Ben Skeggs Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings commit 8654636ef7426f41a713430cb93f57365a6bfcc4 Author: Alex Deucher Date: Fri Aug 31 11:56:50 2012 -0400 drm/radeon: rework pll selection (v3) commit 985f61f7ee647ad570c05eab0b74915da2ac8e19 upstream. For DP we can use the same PPLL for all active DP encoders. Take advantage of that to prevent cases where we may end up sharing a PPLL between DP and non-DP which won't work. Also clean up the code a bit. v2: - fix missing pll_id assignment in crtc init v3: - fix DP PPLL check - document functions - break in main encoder search loop after matching. no need to keep checking additional encoders. fixes: https://bugs.freedesktop.org/show_bug.cgi?id=54471 Signed-off-by: Alex Deucher [bwh: Backported to 3.2: drop the DCE6 case] Signed-off-by: Ben Hutchings commit ca9d5df1dce289bf297c94d6e3fa5afa01885146 Author: Alex Deucher Date: Mon Aug 6 17:06:03 2012 -0400 drm/radeon: fix ordering in pll picking on dce4+ commit ecd67955fd4c8e66e4df312098989d5fa7da624c upstream. No functional change, but re-order the cases so they evaluate properly due to the way the DCE macros work. Noticed by kallisti5 on IRC. Signed-off-by: Alex Deucher [bwh: Backported to 3.2: drop the DCE6 case] Signed-off-by: Ben Hutchings commit 540e00f8662500ff2b6289871b4ca919cd9d6a21 Author: Alex Deucher Date: Tue Jul 17 14:02:43 2012 -0400 drm/radeon: fix up pll selection on DCE5/6 commit 26fe45a0a76f165425f332a5aaa298f149f9db22 upstream. Selecting ATOM_PPLL_INVALID should be equivalent as the DCPLL or PPLL0 are already programmed for the DISPCLK, but the preferred method is to always specify the PLL selected. SetPixelClock will check the parameters and skip the programming if the PLL is already set up. Signed-off-by: Alex Deucher Reviewed-by: Christian König [bwh: Backported to 3.2: drop the DCE6 case] Signed-off-by: Ben Hutchings commit b7e804af32be49d07d2386ae6a977984124ad8f6 Author: Alan Cox Date: Tue Sep 4 16:07:18 2012 +0100 ahci: Add alternate identifier for the 88SE9172 commit 17c60c6b763cb5b83b0185e7d38d01d18e55a05a upstream. This can also appear as 0x9192. Reported in bugzilla and confirmed with the board documentation for these boards. Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=42970 Signed-off-by: Alan Cox Signed-off-by: Jeff Garzik Signed-off-by: Ben Hutchings commit 6cc0cbf6635d7c3547b904d7988ccd974762dae0 Author: Dave Airlie Date: Tue Aug 28 01:53:54 2012 +0000 vmwgfx: add dumb ioctl support commit 5e1782d224c79b26ab7d5c31e3f87657000714fb upstream. Testing and works with the -modesetting driver, Reviewed-by: Jakob Bornecrantz Signed-off-by: Dave Airlie [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 35d0642e293587214472cccbb60dd3f8411f0750 Author: Matteo Frigo Date: Wed Sep 12 10:12:06 2012 -0400 ALSA: ice1724: Use linear scale for AK4396 volume control. commit 3737e2be505d872bf2b3c1cd4151b2d2b413d7b5 upstream. The AK4396 DAC has a linear-scale attentuator, but sound/pci/ice1712/prodigy_hifi.c used a log scale instead, which is not quite right. This patch restores the correct scale, borrowing from the ak4396 code in sound/pci/oxygen/oxygen.c. Signed-off-by: Matteo Frigo Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 0c0f4d2c4e01687b3edacb34ec73d45c4eccbfd5 Author: Guenter Roeck Date: Tue Jun 19 08:00:00 2012 -0700 hwmon: (twl4030-madc-hwmon) Initialize uninitialized structure elements commit 73d7c119255615a26070f9d6cdb722a166a29015 upstream. twl4030_madc_conversion uses do_avg and type structure elements of twl4030_madc_request. Initialize structure to avoid random operation. Fix for: Coverity CID 200794 Uninitialized scalar variable. Cc: Keerthy Signed-off-by: Guenter Roeck Acked-by: Jean Delvare Acked-by: Keerthy Signed-off-by: Ben Hutchings commit 3bef14ff773afb2b26c05b30418a0b891563b0a9 Author: Pavankumar Kondeti Date: Fri Sep 7 11:23:28 2012 +0530 EHCI: Update qTD next pointer in QH overlay region during unlink commit 3d037774b42ed677f699b1dce7d548d55f4e4c2b upstream. There is a possibility of QH overlay region having reference to a stale qTD pointer during unlink. Consider an endpoint having two pending qTD before unlink process begins. The endpoint's QH queue looks like this. qTD1 --> qTD2 --> Dummy To unlink qTD2, QH is removed from asynchronous list and Asynchronous Advance Doorbell is programmed. The qTD1's next qTD pointer is set to qTD2'2 next qTD pointer and qTD2 is retired upon controller's doorbell interrupt. If QH's current qTD pointer points to qTD1, transfer overlay region still have reference to qTD2. But qtD2 is just unlinked and freed. This may cause EHCI system error. Fix this by updating qTD next pointer in QH overlay region with the qTD next pointer of the current qTD. Signed-off-by: Pavankumar Kondeti Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 10b4b8b20803ba45a77fec99a311bed774decc71 Author: Eric Dumazet Date: Mon Sep 10 21:22:11 2012 +0200 staging: r8712u: fix bug in r8712_recv_indicatepkt() commit abf02cfc179bb4bd30d05f582d61b3b8f429b813 upstream. 64bit arches have a buggy r8712u driver, let's fix it. skb->tail must be set properly or network stack behavior is undefined. Addresses https://bugzilla.redhat.com/show_bug.cgi?id=847525 Addresses https://bugzilla.kernel.org/show_bug.cgi?id=45071 Signed-off-by: Eric Dumazet Cc: Dave Jones Acked-by: Larry Finger Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit d3759eaf54695290840a06248512366b4e87a9cc Author: Bjørn Mork Date: Mon Sep 10 12:01:05 2012 +0200 USB: ftdi_sio: do not claim CDC ACM function commit f08dea734844aa42ec57c229b0b73b3d7d21f810 upstream. The Microchip vid:pid 04d8:000a is used for their CDC ACM demo firmware application. This is a device with a single function conforming to the CDC ACM specification and with the intention of demonstrating CDC ACM class firmware and driver interaction. The demo is used on a number of development boards, and may also be used unmodified by vendors using Microchip hardware. Some vendors have re-used this vid:pid for other types of firmware, emulating FTDI chips. Attempting to continue to support such devices without breaking class based applications that by matching on interface class/subclass/proto being ff/ff/00. I have no information about the actual device or interface descriptors, but this will at least make the proper CDC ACM devices work again. Anyone having details of the offending device's descriptors should update this entry with the details. Reported-by: Florian Wöhrl Reported-by: Xiaofan Chen Cc: Alan Cox Cc: Bruno Thomsen Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 177c0a3c211f902056e19427eba0ad55eed7d773 Author: Takashi Iwai Date: Mon Sep 10 09:39:31 2012 +0200 ALSA: hda - Fix Oops at codec reset/reconfig commit 07dc59f0988cb54fd87bd373b3b27eb2401dd811 upstream. snd_hda_codec_reset() calls restore_pincfgs() where the codec is powered up again, which eventually tries to resume and initialize via the callbacks of the codec. However, it's the place just after codec free callback, thus no codec callbacks should be called after that. On a codec like CS4206, it results in Oops due to the access in init callback. This patch fixes the issue by clearing the codec callbacks properly after freeing codec. Reported-by: Daniel J Blueman Signed-off-by: Takashi Iwai [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit ad07e22ea469292fd1416175b81c88ef8646985b Author: Will Deacon Date: Fri Sep 7 18:21:44 2012 +0100 ARM: 7526/1: traps: send SIGILL if get_user fails on undef handling path commit 2b2040af0b64cd93e5d4df2494c4486cf604090d upstream. get_user may fail to load from the provided __user address due to an unhandled fault generated by the access. In the case of the undefined instruction trap, this results in failure to load the faulting instruction, in which case we should send SIGILL to the task rather than continue with potentially uninitialised data. Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Ben Hutchings commit 2a74f74258904ad54228779b4d9319cc3c08d557 Author: David Brown Date: Tue Sep 4 21:36:37 2012 +0100 ARM: 7513/1: Make sure dtc is built before running it commit 70b0476a2394de4f4e32e0b67288d80ff71ca963 upstream. 'make dtbs' in a clean tree will try running the dtc before actually building it. Make these rules depend upon the scripts to build it. Signed-off-by: David Brown Signed-off-by: Russell King Signed-off-by: Ben Hutchings commit 7b8b925af13a058ad6696b117503d6894d65897c Author: Trond Myklebust Date: Fri Sep 7 11:08:50 2012 -0400 SUNRPC: Fix a UDP transport regression commit f39c1bfb5a03e2d255451bff05be0d7255298fa4 upstream. Commit 43cedbf0e8dfb9c5610eb7985d5f21263e313802 (SUNRPC: Ensure that we grab the XPRT_LOCK before calling xprt_alloc_slot) is causing hangs in the case of NFS over UDP mounts. Since neither the UDP or the RDMA transport mechanism use dynamic slot allocation, we can skip grabbing the socket lock for those transports. Add a new rpc_xprt_op to allow switching between the TCP and UDP/RDMA case. Note that the NFSv4.1 back channel assigns the slot directly through rpc_run_bc_task, so we can ignore that case. Reported-by: Dick Streefland Signed-off-by: Trond Myklebust Signed-off-by: Ben Hutchings commit 2971abeb4ad7000b3ca8f5beca598eeea3f03a22 Author: Weston Andros Adamson Date: Thu Sep 6 15:54:27 2012 -0400 NFS: return error from decode_getfh in decode open commit 01913b49cf1dc6409a07dd2a4cc6af2e77f3c410 upstream. If decode_getfh failed, nfs4_xdr_dec_open would return 0 since the last decode_* call must have succeeded. Signed-off-by: Weston Andros Adamson Signed-off-by: Trond Myklebust Signed-off-by: Ben Hutchings commit d9a6b7d813f592d6d8738418bc396eeaea65467c Author: Bjørn Mork Date: Sun Sep 2 15:41:34 2012 +0200 kobject: fix oops with "input0: bad kobj_uevent_env content in show_uevent()" commit 60e233a56609fd963c59e99bd75c663d63fa91b6 upstream. Fengguang Wu writes: > After the __devinit* removal series, I can still get kernel panic in > show_uevent(). So there are more sources of bug.. > > Debug patch: > > @@ -343,8 +343,11 @@ static ssize_t show_uevent(struct device > goto out; > > /* copy keys to file */ > - for (i = 0; i < env->envp_idx; i++) > + dev_err(dev, "uevent %d env[%d]: %s/.../%s\n", env->buflen, env->envp_idx, top_kobj->name, dev->kobj.name); > + for (i = 0; i < env->envp_idx; i++) { > + printk(KERN_ERR "uevent %d env[%d]: %s\n", (int)count, i, env->envp[i]); > count += sprintf(&buf[count], "%s\n", env->envp[i]); > + } > > Oops message, the env[] is again not properly initilized: > > [ 44.068623] input input0: uevent 61 env[805306368]: input0/.../input0 > [ 44.069552] uevent 0 env[0]: (null) This is a completely different CONFIG_HOTPLUG problem, only demonstrating another reason why CONFIG_HOTPLUG should go away. I had a hard time trying to disable it anyway ;-) The problem this time is lots of code assuming that a call to add_uevent_var() will guarantee that env->buflen > 0. This is not true if CONFIG_HOTPLUG is unset. So things like this end up overwriting env->envp_idx because the array index is -1: if (add_uevent_var(env, "MODALIAS=")) return -ENOMEM; len = input_print_modalias(&env->buf[env->buflen - 1], sizeof(env->buf) - env->buflen, dev, 0); Don't know what the best action is, given that there seem to be a *lot* of this around the kernel. This patch "fixes" the problem for me, but I don't know if it can be considered an appropriate fix. [ It is the correct fix for now, for 3.7 forcing CONFIG_HOTPLUG to always be on is the longterm fix, but it's too late for 3.6 and older kernels to resolve this that way - gregkh ] Reported-by: Fengguang Wu Signed-off-by: Bjørn Mork Tested-by: Fengguang Wu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 06c181e04d2fb11e2671789ac7ce354e31621533 Author: Alan Stern Date: Tue Sep 4 10:41:02 2012 -0400 USB: add device quirk for Joss Optical touchboard commit 92fc7a8b0f20bdb243c706daf42658e8e0cd2ef0 upstream. This patch (as1604) adds a CONFIG_INTF_STRINGS quirk for the Joss infrared touchboard device. The device doesn't like to be asked for its interface strings. Signed-off-by: Alan Stern Reported-by: adam ? Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 702066cc9b7651ccd94f02bde59355c659f74b52 Author: Horst Schirmeier Date: Fri Aug 31 00:00:28 2012 +0200 USB: ftdi_sio: PID for NZR SEM 16+ USB commit 26a538b9ea2a3ee10dafc0068f0560dfd7b7ba37 upstream. This adds the USB PID for the NZR SEM 16+ USB energy monitor device . It works perfectly with the GPL software on . Signed-off-by: Horst Schirmeier Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 01ce87e184a949dfd8fab6e508e7ed0ae476bc77 Author: Éric Piel Date: Tue Sep 4 17:25:06 2012 +0200 USB: ftdi-sio: add support for more Physik Instrumente devices commit dafc4f7be1a556ca3868d343c00127728b397068 upstream. Commit b69cc672052540 added support for the E-861. After acquiring a C-867, I realised that every Physik Instrumente's device has a different PID. They are listed in the Windows device driver's .inf file. So here are all PIDs for the current (and probably future) USB devices from Physik Instrumente. Compiled, but only actually tested on the E-861 and C-867. Signed-off-by: Éric Piel Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 1170e5b66595a73f7e8bb0b62e433669939c0eea Author: Santiago Leon Date: Tue Sep 4 14:41:37 2012 +0000 ibmveth: Fix alignment of rx queue bug commit d90c92fee89ccd75ef2646f3bde0b4c0450666c3 upstream. This patch fixes a bug found by Nish Aravamudan (https://lkml.org/lkml/2012/5/15/220) where the driver is not following the spec (it is not aligning the rx buffer on a 16-byte boundary) and the hypervisor aborts the registration, making the device unusable. The fix follows BenH's recommendation (https://lkml.org/lkml/2012/7/20/461) to replace the kmalloc+map for a single call to dma_alloc_coherent() because that function always aligns to a 16-byte boundary. The stable trees will run into this bug whenever the rx buffer kmalloc call returns something not aligned on a 16-byte boundary. Signed-off-by: Santiago Leon Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit da75c41ed3cf1fc577b24dc87559bd32e27ebc8b Author: Dirk Behme Date: Fri Aug 31 10:02:47 2012 +0200 tty: serial: imx: don't reinit clock in imx_setup_ufcr() commit 7be0670f7b9198382938a03ff3db7f47ef6b4780 upstream. Remove the clock configuration from imx_setup_ufcr(). This isn't needed here and will cause garbage output if done. To be be sure that we only touch the bits we want (TXTL and RXTL) we have to mask out all other bits of the UFCR register. Add one non-existing bit macro for this, too (bit 6, DCEDTE on i.MX6). Signed-off-by: Dirk Behme CC: Shawn Guo CC: Sascha Hauer CC: Troy Kisky CC: Xinyu Chen Acked-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: deleted code in imx_setup_ufcr() refers to sport->clk not sport->clk_per] Signed-off-by: Ben Hutchings commit c096552004244868391b29f319ea8889d55abe19 Author: Xinyu Chen Date: Mon Aug 27 09:36:51 2012 +0200 tty: serial: imx: console write routing is unsafe on SMP commit 9ec1882df244c4ee1baa692676fef5e8b0f5487d upstream. The console feature's write routing is unsafe on SMP with the startup/shutdown call. There could be several consumers of the console * the kernel printk * the init process using /dev/kmsg to call printk to show log * shell, which open /dev/console and write with sys_write() The shell goes into the normal uart open/write routing, but the other two go into the console operations. The open routing calls imx serial startup, which will write USR1/2 register without any lock and critical with imx_console_write call. Add a spin_lock for startup/shutdown/console_write routing. This patch is a port from Freescale's Android kernel. Signed-off-by: Xinyu Chen Tested-by: Dirk Behme CC: Sascha Hauer Acked-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 2bcd02db4deea25c9a5c8cca03b2fceba6596574 Author: Moiz Sonasath Date: Wed Sep 5 08:34:26 2012 +0300 usb: host: xhci: fix compilation error for non-PCI based stacks commit 296365781903226a3fb8758901eaeec09d2798e4 upstream. For non PCI-based stacks, this function call usb_disable_xhci_ports(to_pci_dev(hcd->self.controller)); made from xhci_shutdown is not applicable. Ideally, we wouldn't have any PCI-specific code on a generic driver such as the xHCI stack, but it looks like we should just stub usb_disable_xhci_ports() out for non-PCI devices. [ balbi@ti.com: slight improvement to commit log ] This patch should be backported to kernels as old as 3.0, since the commit it fixes (e95829f474f0db3a4d940cae1423783edd966027 "xhci: Switch PPT ports to EHCI on shutdown.") was marked for stable. Signed-off-by: Moiz Sonasath Signed-off-by: Ruchika Kharwar Signed-off-by: Felipe Balbi Signed-off-by: Sarah Sharp Signed-off-by: Ben Hutchings commit 874879c4643c481d50f34d6957207b5e444171b1 Author: Alexis R. Cortes Date: Fri Aug 3 14:00:27 2012 -0500 usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 upstream. This patch is intended to work around a known issue on the SN65LVPE502CP USB3.0 re-driver that can delay the negotiation between a device and the host past the usual handshake timeout. If that happens on the first insertion, the host controller port will enter in Compliance Mode and NO port status event will be generated (as per xHCI Spec) making impossible to detect this event by software. The port will remain in compliance mode until a warm reset is applied to it. As a result of this, the port will seem "dead" to the user and no device connections or disconnections will be detected. For solving this, the patch creates a timer which polls every 2 seconds the link state of each host controller's port (this by reading the PORTSC register) and recovers the port by issuing a Warm reset every time Compliance mode is detected. If a xHC USB3.0 port has previously entered to U0, the compliance mode issue will NOT occur only until system resumes from sleep/hibernate, therefore, the compliance mode timer is stopped when all xHC USB 3.0 ports have entered U0. The timer is initialized again after each system resume. Since the issue is being caused by a piece of hardware, the timer will be enabled ONLY on those systems that have the SN65LVPE502CP installed (this patch uses DMI strings for detecting those systems) therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK has been added to the xhci stack). This patch applies for these systems: Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820. This patch should be backported to kernels as old as 3.2, as that was the first kernel to support warm reset. The kernels will need to contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When hot reset for USB3 fails, try warm reset" and commit 8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub port status CAS". The first patch add warm reset support, and the second patch modifies the USB core to issue a warm reset when the port is in compliance mode. Signed-off-by: Alexis R. Cortes Signed-off-by: Sarah Sharp [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 43e3806177660ebb1fdd4ac8aedb0e62abfbe3e4 Author: Matthew Garrett Date: Tue Aug 14 16:44:49 2012 -0400 xhci: Make handover code more robust commit e955a1cd086de4d165ae0f4c7be7289d84b63bdc upstream. My test platform (Intel DX79SI) boots reliably under BIOS, but frequently crashes when booting via UEFI. I finally tracked this down to the xhci handoff code. It seems that reads from the device occasionally just return 0xff, resulting in xhci_find_next_cap_offset generating a value that's larger than the resource region. We then oops when attempting to read the value. Sanity checking that value lets us avoid the crash. I've no idea what's causing the underlying problem, and xhci still doesn't actually *work* even with this, but the machine at least boots which will probably make further debugging easier. This should be backported to kernels as old as 2.6.31, that contain the commit 66d4eadd8d067269ea8fead1a50fe87c2979a80d "USB: xhci: BIOS handoff and HW initialization." Signed-off-by: Matthew Garrett Signed-off-by: Sarah Sharp Signed-off-by: Ben Hutchings commit 52fa5d9c8c956ee587389bd662106a770de42827 Author: Dan Carpenter Date: Mon Aug 13 19:57:03 2012 +0300 xhci: Fix a logical vs bitwise AND bug commit 052c7f9ffb0e95843e75448d02664459253f9ff8 upstream. The intent was to test whether the flag was set. This patch should be backported to stable kernels as old as 3.0, since it fixes a bug in commit e95829f474f0db3a4d940cae1423783edd966027 "xhci: Switch PPT ports to EHCI on shutdown.", which was marked for stable. Signed-off-by: Dan Carpenter Signed-off-by: Sarah Sharp Signed-off-by: Ben Hutchings commit 201a1b49e0222de2d07c3a107c1bcd58891fbd54 Author: Sarah Sharp Date: Mon Jul 23 18:59:30 2012 +0300 xhci: Switch PPT ports to EHCI on shutdown. commit e95829f474f0db3a4d940cae1423783edd966027 upstream. The Intel desktop boards DH77EB and DH77DF have a hardware issue that can be worked around by BIOS. If the USB ports are switched to xHCI on shutdown, the xHCI host will send a spurious interrupt, which will wake the system. Some BIOS will work around this, but not all. The bug can be avoided if the USB ports are switched back to EHCI on shutdown. The Intel Windows driver switches the ports back to EHCI, so change the Linux xHCI driver to do the same. Unfortunately, we can't tell the two effected boards apart from other working motherboards, because the vendors will change the DMI strings for the DH77EB and DH77DF boards to their own custom names. One example is Compulab's mini-desktop, the Intense-PC. Instead, key off the Panther Point xHCI host PCI vendor and device ID, and switch the ports over for all PPT xHCI hosts. The only impact this will have on non-effected boards is to add a couple hundred milliseconds delay on boot when the BIOS has to switch the ports over from EHCI to xHCI. This patch should be backported to kernels as old as 3.0, that contain the commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by: Sarah Sharp Reported-by: Denis Turischev Tested-by: Denis Turischev [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 62744fbfed6add6d174ce72753cf0157b6e6be99 Author: Seth Jennings Date: Wed Aug 29 16:58:45 2012 -0500 staging: zcache: fix cleancache race condition with shrinker commit 6d7d9798ad5c97ee4e911dd070dc12dc5ae55bd0 upstream. This patch fixes a race condition that results in memory corruption when using cleancache. The race exists between the zcache shrinker handler, shrink_zcache_memory() and cleancache_get_page(). In most cases, the shrinker will both evict a zbpg from its buddy list and flush it from tmem before a cleancache_get_page() occurs on that page. A subsequent cleancache_get_page() will fail in the tmem layer. In the rare case that two occur together and the cleancache_get_page() path gets through the tmem layer before the shrinker path can flush tmem, zbud_decompress() does a check to see if the zbpg is a "zombie", i.e. not on a buddy list, which means the shrinker is in the process of reclaiming it. If the zbpg is a zombie, zbud_decompress() returns -EINVAL. However, this return code is being ignored by the caller, zcache_pampd_get_data_and_free(), which results in the caller of cleancache_get_page() thinking that the page has been properly retrieved when it has not. This patch modifies zcache_pampd_get_data_and_free() to convey the failure up the stack so that the caller of cleancache_get_page() knows the page retrieval failed. This needs to be applied to stable trees as well. zcache-main.c was named zcache.c before v3.1, so I'm not sure how you want to handle trees earlier than that. Signed-off-by: Seth Jennings Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Minchan Kim Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 9cab0e1c7f5872173d40f188b430d1348b118710 Author: Sergei Poselenov Date: Sun Sep 2 13:14:32 2012 +0400 rt2800usb: Added rx packet length validity check commit efd5d6b03bd9c9e0df646c56fb5f4f3e25e5c1ac upstream. On our system (ARM Cortex-M3 SOC running linux-2.6.33) frequent crashes were observed in the rt2800usb module because of the invalid length of the received packet (3392, 46920...). This patch adds the sanity check on the packet legth. Also, changed WARNING to ERROR in rt2x00lib_rxdone() so that the bad packet condition would be noticed. The fix was tested on the latest compat-wireless-3.5.1-1-snpc. Signed-off-by: Sergei Poselenov Acked-by: Ivo van Doorn Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit d1a0322803c21b12abeb9070959d7aeb549634e4 Author: Gertjan van Wingerde Date: Fri Aug 31 19:22:11 2012 +0200 rt2x00: Fix rfkill polling prior to interface start. commit a396e10019eaf3809b0219c966865aaafec12630 upstream. We need to program the rfkill switch GPIO pin direction to input at device initialization time, not only when the interface is brought up. Doing this only when the interface is brought up could lead to rfkill detecting the switch is turned on erroneously and inability to create the interface and bringing it up. Reported-and-tested-by: Andreas Messer Signed-off-by: Gertjan van Wingerde Acked-by: Ivo Van Doorn Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit d9eba20fd64ad0c21b9e66b04d9302b8b1b61284 Author: Gertjan van Wingerde Date: Fri Aug 31 19:22:10 2012 +0200 rt2x00: Fix word size of rt2500usb MAC_CSR19 register. commit 6ced58a5dbb94dbfbea1b33ca3c56d1e929cd548 upstream. The register is 16 bits wide, not 32. Signed-off-by: Gertjan van Wingerde Acked-by: Ivo Van Doorn Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit 9291835bd26cf1505a9ad5e35d40fb55bbda910a Author: Gertjan van Wingerde Date: Fri Aug 31 19:22:09 2012 +0200 rt2x00: Identify ASUS USB-N53 device. commit 177ef8360fabdc49ff08d2598c06e7f7a36b53e3 upstream. This is an RT3572 based device. Signed-off-by: Maximilian Engelhardt Signed-off-by: Gertjan van Wingerde Acked-by: Ivo Van Doorn Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit 9e8777d13f622f259756b53baedee0b2e2a26fb7 Author: Keng-Yu Lin Date: Fri Aug 10 01:39:23 2012 +0800 Intel xhci: Only switch the switchable ports commit a96874a2a92feaef607ddd3137277a788cb927a6 upstream. With a previous patch to enable the EHCI/XHCI port switching, it switches all the available ports. The assumption is not correct because the BIOS may expect some ports not switchable by the OS. There are two more registers that contains the information of the switchable and non-switchable ports. This patch adds the checking code for the two register so that only the switchable ports are altered. This patch should be backported to kernels as old as 3.0, that contain commit ID 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by: Keng-Yu Lin Signed-off-by: Sarah Sharp Signed-off-by: Ben Hutchings commit fbac0dfd9a74a06d306e304149f165962b1af961 Author: Manoj Iyer Date: Wed Aug 22 11:53:18 2012 -0500 xhci: Recognize USB 3.0 devices as superspeed at powerup commit 29d214576f936db627ff62afb9ef438eea18bcd2 upstream. On Intel Panther Point chipset USB 3.0 devices show up as high-speed devices on powerup, but after an s3 cycle they are correctly recognized as SuperSpeed. At powerup switch the port to xHCI so that USB 3.0 devices are correctly recognized. BugLink: http://bugs.launchpad.net/bugs/1000424 This patch should be backported to kernels as old as 3.0, that contain commit ID 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by: Manoj Iyer Signed-off-by: Sarah Sharp Signed-off-by: Ben Hutchings commit 7081f1bf324ad65e421bb83fd3c1cb7c974248ad Author: Malcolm Priestley Date: Wed Aug 29 23:08:21 2012 +0100 staging: vt6656: [BUG] - Failed connection, incorrect endian. commit aa209eef3ce8419ff2926c2fa944dfbfb5afbacb upstream. Hi, This patch fixes a bug with driver failing to negotiate a connection. The bug was traced to commit 203e4615ee9d9fa8d3506b9d0ef30095e4d5bc90 staging: vt6656: removed custom definitions of Ethernet packet types In that patch, definitions in include/linux/if_ether.h replaced ones in tether.h which had both big and little endian definitions. include/linux/if_ether.h only refers to big endian values, cpu_to_be16 should be used for the correct endian architectures. Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit f707d86130d5d292c0f2b19d1bd8f2cad128c929 Author: Ian Abbott Date: Fri Aug 31 20:41:30 2012 +0100 staging: comedi: das08: Correct AO output for das08jr-16-ao commit 61ed59ed09e6ad2b8395178ea5ad5f653bba08e3 upstream. Don't zero out bits 15..12 of the data value in `das08jr_ao_winsn()` as that knobbles the upper three-quarters of the output range for the 'das08jr-16-ao' board. Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 7672832a4ebe555d580a0cdb41a09da0cb8264ba Author: Ian Abbott Date: Fri Aug 31 20:41:29 2012 +0100 staging: comedi: das08: Correct AI encoding for das08jr-16-ao commit e6391a182865efc896cb2a8d79e07b7ac2f45b48 upstream. The element of `das08_boards[]` for the 'das08jr-16-ao' board has the `ai_encoding` member set to `das08_encode12`. It should be set to `das08_encode16` same as the 'das08jr/16' board. After all, this board has 16-bit AI resolution. The description of the A/D LSB register at offset 0 seems incorrect in the user manual "cio-das08jr-16-ao.pdf" as it implies that the AI resolution is only 12 bits. The diagrams of the A/D LSB and MSB registers show 15 data bits and a sign bit, which matches what the software expects for the `das08_encode16` AI encoding method. Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust indentation] Signed-off-by: Ben Hutchings commit 94757f8d13027373fc9e930b8b7258792a3dbe6b Author: Trond Myklebust Date: Tue Sep 4 11:05:07 2012 -0400 NFS: Fix a problem with the legacy binary mount code commit 872ece86ea5c367aa92f44689c2d01a1c767aeb3 upstream. Apparently, am-utils is still using the legacy binary mountdata interface, and is having trouble parsing /proc/mounts due to the 'port=' field being incorrectly set. The following patch should fix up the regression. Reported-by: Marius Tolzmann Signed-off-by: Trond Myklebust Signed-off-by: Ben Hutchings commit ad1a5fb246644fd0300de5adc8b1f4f221e631a8 Author: Trond Myklebust Date: Mon Sep 3 14:56:02 2012 -0400 NFS: Fix the initialisation of the readdir 'cookieverf' array commit c3f52af3e03013db5237e339c817beaae5ec9e3a upstream. When the NFS_COOKIEVERF helper macro was converted into a static inline function in commit 99fadcd764 (nfs: convert NFS_*(inode) helpers to static inline), we broke the initialisation of the readdir cookies, since that depended on doing a memset with an argument of 'sizeof(NFS_COOKIEVERF(inode))' which therefore changed from sizeof(be32 cookieverf[2]) to sizeof(be32 *). At this point, NFS_COOKIEVERF seems to be more of an obfuscation than a helper, so the best thing would be to just get rid of it. Also see: https://bugzilla.kernel.org/show_bug.cgi?id=46881 Reported-by: Andi Kleen Reported-by: David Binderman Signed-off-by: Trond Myklebust Signed-off-by: Ben Hutchings commit f8112ffff6bacaad4fcdf144fee23d1b1be74f9a Author: Al Viro Date: Mon Aug 20 14:59:25 2012 +0100 perf_event: Switch to internal refcount, fix race with close() commit a6fa941d94b411bbd2b6421ffbde6db3c93e65ab upstream. Don't mess with file refcounts (or keep a reference to file, for that matter) in perf_event. Use explicit refcount of its own instead. Deal with the race between the final reference to event going away and new children getting created for it by use of atomic_long_inc_not_zero() in inherit_event(); just have the latter free what it had allocated and return NULL, that works out just fine (children of siblings of something doomed are created as singletons, same as if the child of leader had been created and immediately killed). Signed-off-by: Al Viro Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/r/20120820135925.GG23464@ZenIV.linux.org.uk Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings commit 0112e26a6a0f374041033fb5472f01db2658ac51 Author: Benoît Locher Date: Mon Aug 27 15:02:45 2012 +0200 can: mcp251x: avoid repeated frame bug commit cab32f39dcc5b35db96497dc0a026b5dea76e4e7 upstream. The MCP2515 has a silicon bug causing repeated frame transmission, see section 5 of MCP2515 Rev. B Silicon Errata Revision G (March 2007). Basically, setting TXBnCTRL.TXREQ in either SPI mode (00 or 11) will eventually cause the bug. The workaround proposed by Microchip is to use mode 00 and send a RTS command on the SPI bus to initiate the transmission. Signed-off-by: Benoît Locher Signed-off-by: Marc Kleine-Budde Signed-off-by: Ben Hutchings commit f094377d3dc8bbf4baf9db85f88cd65fb1fccd1a Author: Jani Nikula Date: Wed Aug 29 14:08:42 2012 +0300 drm/i915: only enable sdvo hotplug irq if needed commit fcbc50da7753b210b4442ca9abc4efbd4e481f6e upstream. Avoid constant wakeups caused by noisy irq lines when we don't even care about the irq. This should be particularly useful for i945g/gm where the hotplug has been disabled: commit 768b107e4b3be0acf6f58e914afe4f337c00932b Author: Daniel Vetter Date: Fri May 4 11:29:56 2012 +0200 drm/i915: disable sdvo hotplug on i945g/gm v2: While at it, remove the bogus hotplug_active read, and do not mask hotplug_active[0] before checking whether the irq is needed, per discussion with Daniel on IRC. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=38442 Tested-by: Dominik Köppl Signed-off-by: Jani Nikula Signed-off-by: Daniel Vetter Signed-off-by: Ben Hutchings commit beb073b246b08bec2280a66c970ba5061de9674b Author: Chris Wilson Date: Fri May 11 18:01:33 2012 +0100 drm/i915: SDVO hotplug have different interrupt status bits for i915/i965/g4x commit 084b612ecf8e59973576b2f644e6949609c79375 upstream. Note that gen3 is the only platform where we've got the bit definitions right, hence the workaround of disabling sdvo hotplug support on i945g/gm is not due to misdiagnosis of broken hotplug irq handling ... Signed-off-by: Chris Wilson [danvet: add some blurb about sdvo hotplug fail on i945g/gm I've wondered about while reviewing.] Signed-off-by: Daniel Vetter [bwh: Backported to 3.2: - Adjust context - Handle all three cases in i915_driver_irq_postinstall() as there are not separate functions for gen3 and gen4+ - Carry on using IS_SDVOB() in intel_sdvo_init()] Signed-off-by: Ben Hutchings commit 7a5030928317b47b27ceb66f678424caf45e7ccc Author: Will Deacon Date: Thu Aug 16 18:55:44 2012 +0100 ARM: 7496/1: hw_breakpoint: don't rely on dfsr to show watchpoint access type commit bf8801145c01ab600f8df66e8c879ac642fa5846 upstream. From ARM debug architecture v7.1 onwards, a watchpoint exception causes the DFAR to be updated with the faulting data address. However, DFSR.WnR takes an UNKNOWN value and therefore cannot be used in general to determine the access type that triggered the watchpoint. This patch forbids watchpoints without an overflow handler from specifying a specific access type (load/store). Those with overflow handlers must be able to handle false positives potentially triggered by a watchpoint of a different access type on the same address. For SIGTRAP-based handlers (i.e. ptrace), this should have no impact. Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Ben Hutchings commit b81e4a32ad041cc78fc55c8363453d7636ab4028 Author: Bjørn Mork Date: Tue Sep 11 09:40:31 2012 +0200 USB: option: replace ZTE K5006-Z entry with vendor class rule commit ba9edaa468869a8cea242a411066b0f490751798 upstream. Fix the ZTE K5006-Z entry so that it actually matches anything commit f1b5c997 USB: option: add ZTE K5006-Z added a device specific entry assuming that the device would use class/subclass/proto == ff/ff/ff like other ZTE devices. It turns out that ZTE has started using vendor specific subclass and protocol codes: T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=19d2 ProdID=1018 Rev= 0.00 S: Manufacturer=ZTE,Incorporated S: Product=ZTE LTE Technologies MSM S: SerialNumber=MF821Vxxxxxxx C:* #Ifs= 5 Cfg#= 1 Atr=c0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=86 Prot=10 Driver=(none) E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=02 Prot=05 Driver=(none) E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=(none) E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=00 Driver=qmi_wwan E: Ad=85(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms We do not have any information on how ZTE intend to use these codes, but let us assume for now that the 3 sets matching serial functions in the K5006-Z always will identify a serial function in a ZTE device. Cc: Thomas Schäfer Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit fef1ddd5b4b38c6197bc03fe2cb565e30a677a74 Author: Bjørn Mork Date: Wed Aug 15 15:43:33 2012 +0200 USB: option: add ZTE K5006-Z commit f1b5c997e68533df1f96dcd3068a231bca495603 upstream. The ZTE (Vodafone) K5006-Z use the following interface layout: 00 DIAG 01 secondary 02 modem 03 networkcard 04 storage Ignoring interface #3 which is handled by the qmi_wwan driver. Cc: Thomas Schäfer Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit d5d9014fd924e63d5abb1affec57e83505f73f33 Author: James Ralston Date: Mon Sep 10 10:14:02 2012 +0200 i2c-i801: Add Device IDs for Intel Lynx Point-LP PCH commit 4a8f1ddde942e232387e6129ce4f4c412e43802f upstream. Add the SMBus Device IDs for the Intel Lynx Point-LP PCH. Signed-off-by: James Ralston Signed-off-by: Jean Delvare Signed-off-by: Ben Hutchings commit 79c4d0f5a56d2b0d09bdb9460e33d49320bdd750 Author: Seth Heasley Date: Mon Mar 26 21:47:19 2012 +0200 i2c-i801: Add device IDs for Intel Lynx Point commit 062737fb6d90c632439b1f77ad6a4965cfc84a20 upstream. Add the SMBus controller device IDs for the Intel Lynx Point PCH. Signed-off-by: Seth Heasley Signed-off-by: Jean Delvare Signed-off-by: Ben Hutchings commit ed756add374b0742f00fae8ff74db2e0186c0c70 Author: Will Deacon Date: Fri Aug 10 17:51:18 2012 +0100 ARM: 7487/1: mm: avoid setting nG bit for user mappings that aren't present commit 47f1204329237a0f8655f5a9f14a38ac81946ca1 upstream. Swap entries are encoding in ptes such that !pte_present(pte) and pte_file(pte). The remaining bits of the descriptor are used to identify the swapfile and offset within it to the swap entry. When writing such a pte for a user virtual address, set_pte_at unconditionally sets the nG bit, which (in the case of LPAE) will corrupt the swapfile offset and lead to a BUG: [ 140.494067] swap_free: Unused swap offset entry 000763b4 [ 140.509989] BUG: Bad page map in process rs:main Q:Reg pte:0ec76800 pmd:8f92e003 This patch fixes the problem by only setting the nG bit for user mappings that are actually present. Reviewed-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Ben Hutchings commit 2543c104ef7f41d32e7f985a826f04d0d98e295d Author: Sarah Sharp Date: Thu Jul 26 12:03:59 2012 -0700 xhci: Fix bug after deq ptr set to link TRB. This patch fixes a particularly nasty bug that was revealed by the ring expansion patches. The bug has been present since the very beginning of the xHCI driver history, and could have caused general protection faults from bad memory accesses. The first thing to note is that a Set TR Dequeue Pointer command can move the dequeue pointer to a link TRB, if the canceled or stalled transfer TD ended just before a link TRB. The function to increment the dequeue pointer, inc_deq, was written before cancellation and stall support was added. It assumed that the dequeue pointer could never point to a link TRB. It would unconditionally increment the dequeue pointer at the start of the function, check if the pointer was now on a link TRB, and move it to the top of the next segment if so. This means that if a Set TR Dequeue Point command moved the dequeue pointer to a link TRB, a subsequent call to inc_deq() would move the pointer off the segment and into la-la-land. It would then read from that memory to determine if it was a link TRB. Other functions would often call inc_deq() until the dequeue pointer matched some other pointer, which means this function would quite happily read all of system memory before wrapping around to the right pointer value. Often, there would be another endpoint segment from a different ring allocated from the same DMA pool, which would be contiguous to the segment inc_deq just stepped off of. inc_deq would eventually find the link TRB in that segment, and blindly move the dequeue pointer back to the top of the correct ring segment. The only reason the original code worked at all is because there was only one ring segment. With the ring expansion patches, the dequeue pointer would eventually wrap into place, but the dequeue segment would be out-of-sync. On the second TD after the dequeue pointer was moved to a link TRB, trb_in_td() would fail (because the dequeue pointer and dequeue segment were out-of-sync), and this message would appear: ERROR Transfer event TRB DMA ptr not part of current TD This fixes bugzilla entry 4333 (option-based modem unhappy on USB 3.0 port: "Transfer event TRB DMA ptr not part of current TD", "rejecting I/O to offline device"), https://bugzilla.kernel.org/show_bug.cgi?id=43333 and possibly other general protection fault bugs as well. This patch should be backported to kernels as old as 2.6.31. The original upstream commit is 50d0206fcaea3e736f912fd5b00ec6233fb4ce44, but it does not apply to kernels older than 3.4, because inc_deq was changed in 3.3 and 3.4. This patch should apply to the 3.2 kernel and older. Signed-off-by: Sarah Sharp commit 7da67bc3c1da67f269296edc1d217ada6f1339e3 Author: Chris Wilson Date: Tue Apr 17 10:05:38 2012 +0100 drm/i915: Wait for all pending operations to the fb before disabling the pipe During modeset we have to disable the pipe to reconfigure its timings and maybe its size. Userspace may have queued up command buffers that depend upon the pipe running in a certain configuration and so the commands may become confused across the modeset. At the moment, we use a less than satisfactory kick-scanline-waits should the GPU hang during the modeset. It should be more reliable to wait for the pending operations to complete first, even though we still have a window for userspace to submit a broken command buffer during the modeset. Signed-off-by: Chris Wilson Signed-off-by: Daniel Vetter (cherry picked from commit 0f91128d88bbb8b0a8e7bb93df2c40680871d45a) Signed-off-by: Timo Aaltonen commit 63180c8a56b254148c28762b200139dcaf92a73d Author: John Stultz Date: Fri Aug 31 13:30:06 2012 -0400 time: Move ktime_t overflow checking into timespec_valid_strict This is a -stable backport of cee58483cf56e0ba355fdd97ff5e8925329aa936 Andreas Bombe reported that the added ktime_t overflow checking added to timespec_valid in commit 4e8b14526ca7 ("time: Improve sanity checking of timekeeping inputs") was causing problems with X.org because it caused timeouts larger then KTIME_T to be invalid. Previously, these large timeouts would be clamped to KTIME_MAX and would never expire, which is valid. This patch splits the ktime_t overflow checking into a new timespec_valid_strict function, and converts the timekeeping codes internal checking to use this more strict function. Reported-and-tested-by: Andreas Bombe Cc: Zhouping Liu Cc: Ingo Molnar Cc: Prarit Bhargava Cc: Thomas Gleixner Signed-off-by: John Stultz Signed-off-by: Linus Torvalds Cc: Linux Kernel Signed-off-by: John Stultz commit cfb06dcbc0a63430195cfb70b56bd58311414878 Author: John Stultz Date: Tue Aug 21 20:30:49 2012 -0400 time: Avoid making adjustments if we haven't accumulated anything This is a -stable backport of bf2ac312195155511a0f79325515cbb61929898a If update_wall_time() is called and the current offset isn't large enough to accumulate, avoid re-calling timekeeping_adjust which may change the clock freq and can cause 1ns inconsistencies with CLOCK_REALTIME_COARSE/CLOCK_MONOTONIC_COARSE. Signed-off-by: John Stultz Cc: Prarit Bhargava Cc: Ingo Molnar Link: http://lkml.kernel.org/r/1345595449-34965-5-git-send-email-john.stultz@linaro.org Signed-off-by: Thomas Gleixner Cc: Linux Kernel Signed-off-by: John Stultz commit 8dd006cdafa7c955f6f4c66d25564d90aa29af1d Author: John Stultz Date: Wed Aug 8 15:36:20 2012 -0400 time: Improve sanity checking of timekeeping inputs This is a -stable backport of 4e8b14526ca7fb046a81c94002c1c43b6fdf0e9b Unexpected behavior could occur if the time is set to a value large enough to overflow a 64bit ktime_t (which is something larger then the year 2262). Also unexpected behavior could occur if large negative offsets are injected via adjtimex. So this patch improves the sanity check timekeeping inputs by improving the timespec_valid() check, and then makes better use of timespec_valid() to make sure we don't set the time to an invalid negative value or one that overflows ktime_t. Note: This does not protect from setting the time close to overflowing ktime_t and then letting natural accumulation cause the overflow. Reported-by: CAI Qian Reported-by: Sasha Levin Signed-off-by: John Stultz Cc: Peter Zijlstra Cc: Prarit Bhargava Cc: Zhouping Liu Cc: Ingo Molnar Link: http://lkml.kernel.org/r/1344454580-17031-1-git-send-email-john.stultz@linaro.org Signed-off-by: Thomas Gleixner Cc: Linux Kernel Signed-off-by: John Stultz commit 6293b62174d4bb3594c7d41276a3c35755101aba Author: Marc Gariepy Date: Tue May 1 13:37:57 2012 -0400 fixing dmi match for hp t5745 and hp st5747 thin client commit 62004978df3898649e152751eb6ac264a323ec36 upstream. Match the correct information which is DMI_PRODUCT_NAME instead of DMI_BOARD_NAME See dmidecode information on launchpad for both thin client: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911920 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911916 Signed-off-by: Marc Gariepy Reviewed-by: Adam Jackson Signed-Off-by: Daniel Vetter Signed-off-by: Ben Hutchings commit f152c392a7715862818fb671cbd5e0b2545aedae Author: Lai Jiangshan Date: Sun Sep 2 00:28:19 2012 +0800 workqueue: UNBOUND -> REBIND morphing in rebind_workers() should be atomic commit 96e65306b81351b656835c15931d1d237b252f27 upstream. The compiler may compile the following code into TWO write/modify instructions. worker->flags &= ~WORKER_UNBOUND; worker->flags |= WORKER_REBIND; so the other CPU may temporarily see worker->flags which doesn't have either WORKER_UNBOUND or WORKER_REBIND set and perform local wakeup prematurely. Fix it by using single explicit assignment via ACCESS_ONCE(). Because idle workers have another WORKER_NOT_RUNNING flag, this bug doesn't exist for them; however, update it to use the same pattern for consistency. tj: Applied the change to idle workers too and updated comments and patch description a bit. stable: Idle worker rebinding doesn't apply for -stable and WORKER_UNBOUND used to be WORKER_ROGUE. Updated accordingly. Signed-off-by: Lai Jiangshan Signed-off-by: Tejun Heo commit e8bf333a7a14bd2fa1d091794a168d3ed570457d Author: Yuval Mintz Date: Sun Aug 26 00:35:45 2012 +0000 bnx2x: fix 57840_MF pci id [ Upstream commit 5c879d2094946081af934739850c7260e8b25d3c ] Commit c3def943c7117d42caaed3478731ea7c3c87190e have added support for new pci ids of the 57840 board, while failing to change the obsolete value in 'pci_ids.h'. This patch does so, allowing the probe of such devices. Signed-off-by: Yuval Mintz Signed-off-by: Eilon Greenstein Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 4c5e5e2a49816debff35ac5400b0d56a2d57e495 Author: Francesco Ruggeri Date: Fri Aug 24 07:38:35 2012 +0000 net: ipv4: ipmr_expire_timer causes crash when removing net namespace [ Upstream commit acbb219d5f53821b2d0080d047800410c0420ea1 ] When tearing down a net namespace, ipv4 mr_table structures are freed without first deactivating their timers. This can result in a crash in run_timer_softirq. This patch mimics the corresponding behaviour in ipv6. Locking and synchronization seem to be adequate. We are about to kfree mrt, so existing code should already make sure that no other references to mrt are pending or can be created by incoming traffic. The functions invoked here do not cause new references to mrt or other race conditions to be created. Invoking del_timer_sync guarantees that ipmr_expire_timer is inactive. Both ipmr_expire_process (whose completion we may have to wait in del_timer_sync) and mroute_clean_tables internally use mfc_unres_lock or other synchronizations when needed, and they both only modify mrt. Tested in Linux 3.4.8. Signed-off-by: Francesco Ruggeri Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit db385ea9719a50e852fa7396c4af2213ec342f6c Author: xeb@mail.ru Date: Fri Aug 24 01:07:38 2012 +0000 l2tp: avoid to use synchronize_rcu in tunnel free function [ Upstream commit 99469c32f79a32d8481f87be0d3c66dad286f4ec ] Avoid to use synchronize_rcu in l2tp_tunnel_free because context may be atomic. Signed-off-by: Dmitry Kozlov Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit a0411257ca056288e6ea1618334d2e1d80ac457c Author: Claudiu Manoil Date: Thu Aug 23 21:46:25 2012 +0000 gianfar: fix default tx vlan offload feature flag [ Upstream commit e2c53be223aca36cf93eb6a0f6bafa079e78f52b ] Commit - "b852b72 gianfar: fix bug caused by 87c288c6e9aa31720b72e2bc2d665e24e1653c3e" disables by default (on mac init) the hw vlan tag insertion. The "features" flags were not updated to reflect this, and "ethtool -K" shows tx-vlan-offload to be "on" by default. Cc: Sebastian Poehn Signed-off-by: Claudiu Manoil Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit e6ae7506816cdf4d702c501ceb5202eecf7e4a07 Author: Pablo Neira Ayuso Date: Thu Aug 23 02:09:11 2012 +0000 netlink: fix possible spoofing from non-root processes [ Upstream commit 20e1db19db5d6b9e4e83021595eab0dc8f107bef ] Non-root user-space processes can send Netlink messages to other processes that are well-known for being subscribed to Netlink asynchronous notifications. This allows ilegitimate non-root process to send forged messages to Netlink subscribers. The userspace process usually verifies the legitimate origin in two ways: a) Socket credentials. If UID != 0, then the message comes from some ilegitimate process and the message needs to be dropped. b) Netlink portID. In general, portID == 0 means that the origin of the messages comes from the kernel. Thus, discarding any message not coming from the kernel. However, ctnetlink sets the portID in event messages that has been triggered by some user-space process, eg. conntrack utility. So other processes subscribed to ctnetlink events, eg. conntrackd, know that the event was triggered by some user-space action. Neither of the two ways to discard ilegitimate messages coming from non-root processes can help for ctnetlink. This patch adds capability validation in case that dst_pid is set in netlink_sendmsg(). This approach is aggressive since existing applications using any Netlink bus to deliver messages between two user-space processes will break. Note that the exception is NETLINK_USERSOCK, since it is reserved for netlink-to-netlink userspace communication. Still, if anyone wants that his Netlink bus allows netlink-to-netlink userspace, then they can set NL_NONROOT_SEND. However, by default, I don't think it makes sense to allow to use NETLINK_ROUTE to communicate two processes that are sending no matter what information that is not related to link/neighbouring/routing. They should be using NETLINK_USERSOCK instead for that. Signed-off-by: Pablo Neira Ayuso Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit dc77000f6fa5f7dd5eac1d02fa7812a131a67b89 Author: Eric Dumazet Date: Tue Aug 21 06:21:17 2012 +0000 af_netlink: force credentials passing [CVE-2012-3520] [ Upstream commit e0e3cea46d31d23dc40df0a49a7a2c04fe8edfea ] Pablo Neira Ayuso discovered that avahi and potentially NetworkManager accept spoofed Netlink messages because of a kernel bug. The kernel passes all-zero SCM_CREDENTIALS ancillary data to the receiver if the sender did not provide such data, instead of not including any such data at all or including the correct data from the peer (as it is the case with AF_UNIX). This bug was introduced in commit 16e572626961 (af_unix: dont send SCM_CREDENTIALS by default) This patch forces passing credentials for netlink, as before the regression. Another fix would be to not add SCM_CREDENTIALS in netlink messages if not provided by the sender, but it might break some programs. With help from Florian Weimer & Petr Matousek This issue is designated as CVE-2012-3520 Signed-off-by: Eric Dumazet Cc: Petr Matousek Cc: Florian Weimer Cc: Pablo Neira Ayuso Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 1b048ea7242555f91066228ef136ba299f4ae567 Author: Eric Leblond Date: Thu Aug 16 22:02:58 2012 +0000 af_packet: don't emit packet on orig fanout group [ Upstream commit c0de08d04215031d68fa13af36f347a6cfa252ca ] If a packet is emitted on one socket in one group of fanout sockets, it is transmitted again. It is thus read again on one of the sockets of the fanout group. This result in a loop for software which generate packets when receiving one. This retransmission is not the intended behavior: a fanout group must behave like a single socket. The packet should not be transmitted on a socket if it originates from a socket belonging to the same fanout group. This patch fixes the issue by changing the transmission check to take fanout group info account. Reported-by: Aleksandr Kotov Signed-off-by: Eric Leblond Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit daf8fa93325e55ec605c4e725e6dc07d63d0d5c1 Author: Mathias Krause Date: Wed Aug 15 11:31:57 2012 +0000 net: fix info leak in compat dev_ifconf() [ Upstream commit 43da5f2e0d0c69ded3d51907d9552310a6b545e8 ] The implementation of dev_ifconf() for the compat ioctl interface uses an intermediate ifc structure allocated in userland for the duration of the syscall. Though, it fails to initialize the padding bytes inserted for alignment and that for leaks four bytes of kernel stack. Add an explicit memset(0) before filling the structure to avoid the info leak. Signed-off-by: Mathias Krause Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 9b2a14018c8a62cf910e10efb4b24787549de5c4 Author: Mathias Krause Date: Wed Aug 15 11:31:56 2012 +0000 ipvs: fix info leak in getsockopt(IP_VS_SO_GET_TIMEOUT) [ Upstream commit 2d8a041b7bfe1097af21441cb77d6af95f4f4680 ] If at least one of CONFIG_IP_VS_PROTO_TCP or CONFIG_IP_VS_PROTO_UDP is not set, __ip_vs_get_timeouts() does not fully initialize the structure that gets copied to userland and that for leaks up to 12 bytes of kernel stack. Add an explicit memset(0) before passing the structure to __ip_vs_get_timeouts() to avoid the info leak. Signed-off-by: Mathias Krause Cc: Wensong Zhang Cc: Simon Horman Cc: Julian Anastasov Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 24635bcd494892f4fce7b2504f3f1c65cc2d6ad2 Author: Mathias Krause Date: Wed Aug 15 11:31:55 2012 +0000 dccp: fix info leak via getsockopt(DCCP_SOCKOPT_CCID_TX_INFO) [ Upstream commit 7b07f8eb75aa3097cdfd4f6eac3da49db787381d ] The CCID3 code fails to initialize the trailing padding bytes of struct tfrc_tx_info added for alignment on 64 bit architectures. It that for potentially leaks four bytes kernel stack via the getsockopt() syscall. Add an explicit memset(0) before filling the structure to avoid the info leak. Signed-off-by: Mathias Krause Cc: Gerrit Renker Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 3f497daadeeb2b84dc8e97b32416d98b34485b99 Author: Mathias Krause Date: Wed Aug 15 11:31:53 2012 +0000 llc: fix info leak via getsockname() [ Upstream commit 3592aaeb80290bda0f2cf0b5456c97bfc638b192 ] The LLC code wrongly returns 0, i.e. "success", when the socket is zapped. Together with the uninitialized uaddrlen pointer argument from sys_getsockname this leads to an arbitrary memory leak of up to 128 bytes kernel stack via the getsockname() syscall. Return an error instead when the socket is zapped to prevent the info leak. Also remove the unnecessary memset(0). We don't directly write to the memory pointed by uaddr but memcpy() a local structure at the end of the function that is properly initialized. Signed-off-by: Mathias Krause Cc: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 79690021eba0738861965187af2f75035f846d6f Author: Mathias Krause Date: Wed Aug 15 11:31:51 2012 +0000 Bluetooth: L2CAP - Fix info leak via getsockname() [ Upstream commit 792039c73cf176c8e39a6e8beef2c94ff46522ed ] The L2CAP code fails to initialize the l2_bdaddr_type member of struct sockaddr_l2 and the padding byte added for alignment. It that for leaks two bytes kernel stack via the getsockname() syscall. Add an explicit memset(0) before filling the structure to avoid the info leak. Signed-off-by: Mathias Krause Cc: Marcel Holtmann Cc: Gustavo Padovan Cc: Johan Hedberg Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 18fc748c13b0a15152bd711c3d42560f833af9e5 Author: Mathias Krause Date: Wed Aug 15 11:31:50 2012 +0000 Bluetooth: RFCOMM - Fix info leak via getsockname() [ Upstream commit 9344a972961d1a6d2c04d9008b13617bcb6ec2ef ] The RFCOMM code fails to initialize the trailing padding byte of struct sockaddr_rc added for alignment. It that for leaks one byte kernel stack via the getsockname() syscall. Add an explicit memset(0) before filling the structure to avoid the info leak. Signed-off-by: Mathias Krause Cc: Marcel Holtmann Cc: Gustavo Padovan Cc: Johan Hedberg Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 2ab341d741cb33f5e69893f6871cf4a4d7bfd3f5 Author: Mathias Krause Date: Wed Aug 15 11:31:49 2012 +0000 Bluetooth: RFCOMM - Fix info leak in ioctl(RFCOMMGETDEVLIST) [ Upstream commit f9432c5ec8b1e9a09b9b0e5569e3c73db8de432a ] The RFCOMM code fails to initialize the two padding bytes of struct rfcomm_dev_list_req inserted for alignment before copying it to userland. Additionally there are two padding bytes in each instance of struct rfcomm_dev_info. The ioctl() that for disclosures two bytes plus dev_num times two bytes uninitialized kernel heap memory. Allocate the memory using kzalloc() to fix this issue. Signed-off-by: Mathias Krause Cc: Marcel Holtmann Cc: Gustavo Padovan Cc: Johan Hedberg Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 1621af48f4c2cf3e10438507bea36af7189603b9 Author: Mathias Krause Date: Wed Aug 15 11:31:48 2012 +0000 Bluetooth: RFCOMM - Fix info leak in getsockopt(BT_SECURITY) [ Upstream commit 9ad2de43f1aee7e7274a4e0d41465489299e344b ] The RFCOMM code fails to initialize the key_size member of struct bt_security before copying it to userland -- that for leaking one byte kernel stack. Initialize key_size with 0 to avoid the info leak. Signed-off-by: Mathias Krause Cc: Marcel Holtmann Cc: Gustavo Padovan Cc: Johan Hedberg Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 1ec7005779d27fabc6fb64f0852745aaac4a66d2 Author: Mathias Krause Date: Wed Aug 15 11:31:47 2012 +0000 Bluetooth: HCI - Fix info leak via getsockname() [ Upstream commit 3f68ba07b1da811bf383b4b701b129bfcb2e4988 ] The HCI code fails to initialize the hci_channel member of struct sockaddr_hci and that for leaks two bytes kernel stack via the getsockname() syscall. Initialize hci_channel with 0 to avoid the info leak. Signed-off-by: Mathias Krause Cc: Marcel Holtmann Cc: Gustavo Padovan Cc: Johan Hedberg Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 2c7571e8eccb318337c06e09871ce0bf9868b93a Author: Mathias Krause Date: Wed Aug 15 11:31:46 2012 +0000 Bluetooth: HCI - Fix info leak in getsockopt(HCI_FILTER) [ Upstream commit e15ca9a0ef9a86f0477530b0f44a725d67f889ee ] The HCI code fails to initialize the two padding bytes of struct hci_ufilter before copying it to userland -- that for leaking two bytes kernel stack. Add an explicit memset(0) before filling the structure to avoid the info leak. Signed-off-by: Mathias Krause Cc: Marcel Holtmann Cc: Gustavo Padovan Cc: Johan Hedberg Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 86cbb1ef4f7b1e6ac6cb65bb34b6949cd5b90c6e Author: Mathias Krause Date: Wed Aug 15 11:31:45 2012 +0000 atm: fix info leak via getsockname() [ Upstream commit 3c0c5cfdcd4d69ffc4b9c0907cec99039f30a50a ] The ATM code fails to initialize the two padding bytes of struct sockaddr_atmpvc inserted for alignment. Add an explicit memset(0) before filling the structure to avoid the info leak. Signed-off-by: Mathias Krause Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 3d9e0c7f9adf3b5bbdc257d4c70ead09947cc304 Author: Mathias Krause Date: Wed Aug 15 11:31:44 2012 +0000 atm: fix info leak in getsockopt(SO_ATMPVC) [ Upstream commit e862f1a9b7df4e8196ebec45ac62295138aa3fc2 ] The ATM code fails to initialize the two padding bytes of struct sockaddr_atmpvc inserted for alignment. Add an explicit memset(0) before filling the structure to avoid the info leak. Signed-off-by: Mathias Krause Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 86134afa03b3d154314e81bbc874dfec66ab74c0 Author: Ben Hutchings Date: Tue Aug 14 08:54:51 2012 +0000 ipv6: addrconf: Avoid calling netdevice notifiers with RCU read-side lock [ Upstream commit 4acd4945cd1e1f92b20d14e349c6c6a52acbd42d ] Cong Wang reports that lockdep detected suspicious RCU usage while enabling IPV6 forwarding: [ 1123.310275] =============================== [ 1123.442202] [ INFO: suspicious RCU usage. ] [ 1123.558207] 3.6.0-rc1+ #109 Not tainted [ 1123.665204] ------------------------------- [ 1123.768254] include/linux/rcupdate.h:430 Illegal context switch in RCU read-side critical section! [ 1123.992320] [ 1123.992320] other info that might help us debug this: [ 1123.992320] [ 1124.307382] [ 1124.307382] rcu_scheduler_active = 1, debug_locks = 0 [ 1124.522220] 2 locks held by sysctl/5710: [ 1124.648364] #0: (rtnl_mutex){+.+.+.}, at: [] rtnl_trylock+0x15/0x17 [ 1124.882211] #1: (rcu_read_lock){.+.+.+}, at: [] rcu_lock_acquire+0x0/0x29 [ 1125.085209] [ 1125.085209] stack backtrace: [ 1125.332213] Pid: 5710, comm: sysctl Not tainted 3.6.0-rc1+ #109 [ 1125.441291] Call Trace: [ 1125.545281] [] lockdep_rcu_suspicious+0x109/0x112 [ 1125.667212] [] rcu_preempt_sleep_check+0x45/0x47 [ 1125.781838] [] __might_sleep+0x1e/0x19b [...] [ 1127.445223] [] call_netdevice_notifiers+0x4a/0x4f [...] [ 1127.772188] [] dev_disable_lro+0x32/0x6b [ 1127.885174] [] dev_forward_change+0x30/0xcb [ 1128.013214] [] addrconf_forward_change+0x85/0xc5 [...] addrconf_forward_change() uses RCU iteration over the netdev list, which is unnecessary since it already holds the RTNL lock. We also cannot reasonably require netdevice notifier functions not to sleep. Reported-by: Cong Wang Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 6c8caeb1fd9b7da47e66112ac9b07313a6230b74 Author: danborkmann@iogearbox.net Date: Fri Aug 10 22:48:54 2012 +0000 af_packet: remove BUG statement in tpacket_destruct_skb [ Upstream commit 7f5c3e3a80e6654cf48dfba7cf94f88c6b505467 ] Here's a quote of the comment about the BUG macro from asm-generic/bug.h: Don't use BUG() or BUG_ON() unless there's really no way out; one example might be detecting data structure corruption in the middle of an operation that can't be backed out of. If the (sub)system can somehow continue operating, perhaps with reduced functionality, it's probably not BUG-worthy. If you're tempted to BUG(), think again: is completely giving up really the *only* solution? There are usually better options, where users don't need to reboot ASAP and can mostly shut down cleanly. In our case, the status flag of a ring buffer slot is managed from both sides, the kernel space and the user space. This means that even though the kernel side might work as expected, the user space screws up and changes this flag right between the send(2) is triggered when the flag is changed to TP_STATUS_SENDING and a given skb is destructed after some time. Then, this will hit the BUG macro. As David suggested, the best solution is to simply remove this statement since it cannot be used for kernel side internal consistency checks. I've tested it and the system still behaves /stable/ in this case, so in accordance with the above comment, we should rather remove it. Signed-off-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 47be27f0e491483c16285ed023874929824b5190 Author: Alexey Khoroshilov Date: Wed Aug 8 00:33:25 2012 +0000 net/core: Fix potential memory leak in dev_set_alias() [ Upstream commit 7364e445f62825758fa61195d237a5b8ecdd06ec ] Do not leak memory by updating pointer with potentially NULL realloc return value. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 3f37c3bd4cded42d856f5f9d40a830bfefa57b58 Author: Gao feng Date: Tue Aug 7 00:23:11 2012 +0000 pptp: lookup route with the proper net namespace [ Upstream commit 08252b32311c3fa84219ad794d640af7399b5485 ] pptp always use init_net as the net namespace to lookup route, this will cause route lookup failed in container. because we already set the correct net namespace to struct sock in pptp_create,so fix this by using sock_net(sk) to replace &init_net. Signed-off-by: Gao feng Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 748b6a42291b23c24ed21f93598189c25d7ae513 Author: Wu Fengguang Date: Thu Aug 2 23:10:01 2012 +0000 isdnloop: fix and simplify isdnloop_init() [ Upstream commit 77f00f6324cb97cf1df6f9c4aaeea6ada23abdb2 ] Fix a buffer overflow bug by removing the revision and printk. [ 22.016214] isdnloop-ISDN-driver Rev 1.11.6.7 [ 22.097508] isdnloop: (loop0) virtual card added [ 22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff83244972 [ 22.174400] [ 22.436157] Pid: 1, comm: swapper Not tainted 3.5.0-bisect-00018-gfa8bbb1-dirty #129 [ 22.624071] Call Trace: [ 22.720558] [] ? CallcNew+0x56/0x56 [ 22.815248] [] panic+0x110/0x329 [ 22.914330] [] ? isdnloop_init+0xaf/0xb1 [ 23.014800] [] ? CallcNew+0x56/0x56 [ 23.090763] [] __stack_chk_fail+0x2b/0x30 [ 23.185748] [] isdnloop_init+0xaf/0xb1 Signed-off-by: Fengguang Wu Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit e72c9bd7d87ae9780d8b87f9ab45041fc72f3f48 Author: Hiroaki SHIMODA Date: Fri Aug 3 19:57:52 2012 +0900 net_sched: gact: Fix potential panic in tcf_gact(). [ Upstream commit 696ecdc10622d86541f2e35cc16e15b6b3b1b67e ] gact_rand array is accessed by gact->tcfg_ptype whose value is assumed to less than MAX_RAND, but any range checks are not performed. So add a check in tcf_gact_init(). And in tcf_gact(), we can reduce a branch. Signed-off-by: Hiroaki SHIMODA Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 9f871e883277cc22c6217db806376dce52401a31 Author: Ben Hutchings Date: Mon Jul 30 16:11:42 2012 +0000 tcp: Apply device TSO segment limit earlier [ Upstream commit 1485348d2424e1131ea42efc033cbd9366462b01 ] Cache the device gso_max_segs in sock::sk_gso_max_segs and use it to limit the size of TSO skbs. This avoids the need to fall back to software GSO for local TCP senders. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 68cb695ccecf949d48949e72f8ce591fdaaa325c Author: Ben Hutchings Date: Mon Jul 30 15:57:44 2012 +0000 sfc: Fix maximum number of TSO segments and minimum TX queue size [ Upstream commit 7e6d06f0de3f74ca929441add094518ae332257c ] Currently an skb requiring TSO may not fit within a minimum-size TX queue. The TX queue selected for the skb may stall and trigger the TX watchdog repeatedly (since the problem skb will be retried after the TX reset). This issue is designated as CVE-2012-3412. Set the maximum number of TSO segments for our devices to 100. This should make no difference to behaviour unless the actual MSS is less than about 700. Increase the minimum TX queue size accordingly to allow for 2 worst-case skbs, so that there will definitely be space to add an skb after we wake a queue. To avoid invalidating existing configurations, change efx_ethtool_set_ringparam() to fix up values that are too small rather than returning -EINVAL. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 99ea81edff2135603588fe12bd95cca2dd76a5cb Author: Ben Hutchings Date: Mon Jul 30 15:57:00 2012 +0000 net: Allow driver to limit number of GSO segments per skb [ Upstream commit 30b678d844af3305cda5953467005cebb5d7b687 ] A peer (or local user) may cause TCP to use a nominal MSS of as little as 88 (actual MSS of 76 with timestamps). Given that we have a sufficiently prodigious local sender and the peer ACKs quickly enough, it is nevertheless possible to grow the window for such a connection to the point that we will try to send just under 64K at once. This results in a single skb that expands to 861 segments. In some drivers with TSO support, such an skb will require hundreds of DMA descriptors; a substantial fraction of a TX ring or even more than a full ring. The TX queue selected for the skb may stall and trigger the TX watchdog repeatedly (since the problem skb will be retried after the TX reset). This particularly affects sfc, for which the issue is designated as CVE-2012-3412. Therefore: 1. Add the field net_device::gso_max_segs holding the device-specific limit. 2. In netif_skb_features(), if the number of segments is too high then mask out GSO features to force fall back to software GSO. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit bc63e39c5809523d365ad0e7f9f7aa8b8ba8fd7c Author: Axel Lin Date: Mon Sep 10 10:14:02 2012 +0200 i2c-designware: Fix build error if CONFIG_I2C_DESIGNWARE_PLATFORM=y && CONFIG_I2C_DESIGNWARE_PCI=y commit e68bb91baa0bb9817567bd45d560919e8e26373b upstream. This patch adds config I2C_DESIGNWARE_CORE in Kconfig, and let I2C_DESIGNWARE_PLATFORM and I2C_DESIGNWARE_PCI select I2C_DESIGNWARE_CORE. Because both I2C_DESIGNWARE_PLATFORM and I2C_DESIGNWARE_PCI can be built as built-in or module, we also need to export the functions in i2c-designware-core. This fixes below build error when CONFIG_I2C_DESIGNWARE_PLATFORM=y && CONFIG_I2C_DESIGNWARE_PCI=y: LD drivers/i2c/busses/built-in.o drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_clear_int': i2c-designware-core.c:(.text+0xa10): multiple definition of `i2c_dw_clear_int' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x928): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_init': i2c-designware-core.c:(.text+0x178): multiple definition of `i2c_dw_init' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x90): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `dw_readl': i2c-designware-core.c:(.text+0xe8): multiple definition of `dw_readl' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x0): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_isr': i2c-designware-core.c:(.text+0x724): multiple definition of `i2c_dw_isr' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x63c): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_xfer': i2c-designware-core.c:(.text+0x4b0): multiple definition of `i2c_dw_xfer' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x3c8): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_is_enabled': i2c-designware-core.c:(.text+0x9d4): multiple definition of `i2c_dw_is_enabled' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8ec): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `dw_writel': i2c-designware-core.c:(.text+0x124): multiple definition of `dw_writel' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x3c): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_xfer_msg': i2c-designware-core.c:(.text+0x2e8): multiple definition of `i2c_dw_xfer_msg' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x200): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_enable': i2c-designware-core.c:(.text+0x9c8): multiple definition of `i2c_dw_enable' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8e0): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_read_comp_param': i2c-designware-core.c:(.text+0xa24): multiple definition of `i2c_dw_read_comp_param' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x93c): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_disable': i2c-designware-core.c:(.text+0x9dc): multiple definition of `i2c_dw_disable' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8f4): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_func': i2c-designware-core.c:(.text+0x710): multiple definition of `i2c_dw_func' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x628): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_disable_int': i2c-designware-core.c:(.text+0xa18): multiple definition of `i2c_dw_disable_int' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x930): first defined here make[3]: *** [drivers/i2c/busses/built-in.o] Error 1 make[2]: *** [drivers/i2c/busses] Error 2 make[1]: *** [drivers/i2c] Error 2 make: *** [drivers] Error 2 Signed-off-by: Axel Lin Signed-off-by: Jean Delvare Tested-by: Jiri Slaby Signed-off-by: Ben Hutchings commit beb30ae4adbd66a2d7195fd4f6156b4d93e64a9f Author: Dave Airlie Date: Tue Aug 28 21:40:51 2012 -0400 drm/vmwgfx: add MODULE_DEVICE_TABLE so vmwgfx loads at boot commit c4903429a92be60e6fe59868924a65eca4cd1a38 upstream. This will cause udev to load vmwgfx instead of waiting for X to do it. Reviewed-by: Jakob Bornecrantz Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings commit 06335856d22eeef4862c539920137e348a9e620d Author: Pavel Shilovsky Date: Wed Aug 29 21:13:38 2012 +0400 CIFS: Fix error handling in cifs_push_mandatory_locks commit e2f2886a824ff0a56da1eaa13019fde86aa89fa6 upstream. Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 9600be784136611dcab44490998f8d7420ac7a79 Author: Dave Jones Date: Thu Sep 6 12:01:00 2012 -0400 Remove user-triggerable BUG from mpol_to_str commit 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a upstream. Trivially triggerable, found by trinity: kernel BUG at mm/mempolicy.c:2546! Process trinity-child2 (pid: 23988, threadinfo ffff88010197e000, task ffff88007821a670) Call Trace: show_numa_map+0xd5/0x450 show_pid_numa_map+0x13/0x20 traverse+0xf2/0x230 seq_read+0x34b/0x3e0 vfs_read+0xac/0x180 sys_pread64+0xa2/0xc0 system_call_fastpath+0x1a/0x1f RIP: mpol_to_str+0x156/0x360 Signed-off-by: Dave Jones Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 7c013154e1cb6ffd5f2a0b6b17b4b70df9e16ebd Author: Ronny Hegewald Date: Fri Aug 31 09:57:52 2012 +0000 xen: Use correct masking in xen_swiotlb_alloc_coherent. commit b5031ed1be0aa419250557123633453753181643 upstream. When running 32-bit pvops-dom0 and a driver tries to allocate a coherent DMA-memory the xen swiotlb-implementation returned memory beyond 4GB. The underlaying reason is that if the supplied driver passes in a DMA_BIT_MASK(64) ( hwdev->coherent_dma_mask is set to 0xffffffffffffffff) our dma_mask will be u64 set to 0xffffffffffffffff even if we set it to DMA_BIT_MASK(32) previously. Meaning we do not reset the upper bits. By using the dma_alloc_coherent_mask function - it does the proper casting and we get 0xfffffffff. This caused not working sound on a system with 4 GB and a 64-bit compatible sound-card with sets the DMA-mask to 64bit. On bare-metal and the forward-ported xen-dom0 patches from OpenSuse a coherent DMA-memory is always allocated inside the 32-bit address-range by calling dma_alloc_coherent_mask. This patch adds the same functionality to xen swiotlb and is a rebase of the original patch from Ronny Hegewald which never got upstream b/c the underlaying reason was not understood until now. The original email with the original patch is in: http://old-list-archives.xen.org/archives/html/xen-devel/2010-02/msg00038.html the original thread from where the discussion started is in: http://old-list-archives.xen.org/archives/html/xen-devel/2010-01/msg00928.html Signed-off-by: Ronny Hegewald Signed-off-by: Stefano Panella Acked-By: David Vrabel Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Ben Hutchings commit 0658632e16cba7cd399dd9380ac48531415f46e4 Author: Jan Kara Date: Wed Sep 5 15:48:23 2012 +0200 udf: Fix data corruption for files in ICB commit 9c2fc0de1a6e638fe58c354a463f544f42a90a09 upstream. When a file is stored in ICB (inode), we overwrite part of the file, and the page containing file's data is not in page cache, we end up corrupting file's data by overwriting them with zeros. The problem is we use simple_write_begin() which simply zeroes parts of the page which are not written to. The problem has been introduced by be021ee4 (udf: convert to new aops). Fix the problem by providing a ->write_begin function which makes the page properly uptodate. Reported-by: Ian Abbott Signed-off-by: Jan Kara Signed-off-by: Ben Hutchings commit 241ee90a69ede9cf9255df1a18036210beeb8adf Author: Paul Mackerras Date: Tue Sep 4 18:33:08 2012 +0000 powerpc: Make sure IPI handlers see data written by IPI senders commit 9fb1b36ca1234e64a5d1cc573175303395e3354d upstream. We have been observing hangs, both of KVM guest vcpu tasks and more generally, where a process that is woken doesn't properly wake up and continue to run, but instead sticks in TASK_WAKING state. This happens because the update of rq->wake_list in ttwu_queue_remote() is not ordered with the update of ipi_message in smp_muxed_ipi_message_pass(), and the reading of rq->wake_list in scheduler_ipi() is not ordered with the reading of ipi_message in smp_ipi_demux(). Thus it is possible for the IPI receiver not to see the updated rq->wake_list and therefore conclude that there is nothing for it to do. In order to make sure that anything done before smp_send_reschedule() is ordered before anything done in the resulting call to scheduler_ipi(), this adds barriers in smp_muxed_message_pass() and smp_ipi_demux(). The barrier in smp_muxed_message_pass() is a full barrier to ensure that there is a full ordering between the smp_send_reschedule() caller and scheduler_ipi(). In smp_ipi_demux(), we use xchg() rather than xchg_local() because xchg() includes release and acquire barriers. Using xchg() rather than xchg_local() makes sense given that ipi_message is not just accessed locally. This moves the barrier between setting the message and calling the cause_ipi() function into the individual cause_ipi implementations. Most of them -- those that used outb, out_8 or similar -- already had a full barrier because out_8 etc. include a sync before the MMIO store. This adds an explicit barrier in the two remaining cases. These changes made no measurable difference to the speed of IPIs as measured using a simple ping-pong latency test across two CPUs on different cores of a POWER7 machine. The analysis of the reason why processes were not waking up properly is due to Milton Miller. Reported-by: Milton Miller Signed-off-by: Paul Mackerras Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Ben Hutchings commit 4d676c891354e871351e741eedf6a909ebffd265 Author: Anton Blanchard Date: Thu Nov 24 19:39:36 2011 +0000 powerpc/xics: Harden xics hypervisor backend commit 3ce21cdfe93efffa4ffba9cf3ca2576d3d60d6dc upstream. During kdump stress testing I sometimes see the kdump kernel panic with: Interrupt 0x306 (real) is invalid, disabling it. Kernel panic - not syncing: bad return code EOI - rc = -4, value=ff000306 Instead of panicing print the error message, dump the stack the first time it happens and continue on. Add some more information to the debug messages as well. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Ben Hutchings commit 33b29c62b42b09fae45b78535d315541ad65d321 Author: Anton Blanchard Date: Mon Sep 3 16:51:10 2012 +0000 powerpc: Restore correct DSCR in context switch commit 714332858bfd40dcf8f741498336d93875c23aa7 upstream. During a context switch we always restore the per thread DSCR value. If we aren't doing explicit DSCR management (ie thread.dscr_inherit == 0) and the default DSCR changed while the process has been sleeping we end up with the wrong value. Check thread.dscr_inherit and select the default DSCR or per thread DSCR as required. This was found with the following test case, when running with more threads than CPUs (ie forcing context switching): http://ozlabs.org/~anton/junkcode/dscr_default_test.c With the four patches applied I can run a combination of all test cases successfully at the same time: http://ozlabs.org/~anton/junkcode/dscr_default_test.c http://ozlabs.org/~anton/junkcode/dscr_explicit_test.c http://ozlabs.org/~anton/junkcode/dscr_inherit_test.c Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Ben Hutchings commit ea1862390d3fa57b1b0eca2c445f25a98e02fc7d Author: Anton Blanchard Date: Mon Sep 3 16:49:47 2012 +0000 powerpc: Fix DSCR inheritance in copy_thread() commit 1021cb268b3025573c4811f1dee4a11260c4507b upstream. If the default DSCR is non zero we set thread.dscr_inherit in copy_thread() meaning the new thread and all its children will ignore future updates to the default DSCR. This is not intended and is a change in behaviour that a number of our users have hit. We just need to inherit thread.dscr and thread.dscr_inherit from the parent which ends up being much simpler. This was found with the following test case: http://ozlabs.org/~anton/junkcode/dscr_default_test.c Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Ben Hutchings commit 5f31a641ff0e76081cf4ae1f72799cd59c20baea Author: Anton Blanchard Date: Mon Sep 3 16:48:46 2012 +0000 powerpc: Keep thread.dscr and thread.dscr_inherit in sync commit 00ca0de02f80924dfff6b4f630e1dff3db005e35 upstream. When we update the DSCR either via emulation of mtspr(DSCR) or via a change to dscr_default in sysfs we don't update thread.dscr. We will eventually update it at context switch time but there is a period where thread.dscr is incorrect. If we fork at this point we will copy the old value of thread.dscr into the child. To avoid this, always keep thread.dscr in sync with reality. This issue was found with the following testcase: http://ozlabs.org/~anton/junkcode/dscr_inherit_test.c Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Ben Hutchings commit b32fef3b4df0e254fb4d0fd3122a2668a5f11581 Author: Anton Blanchard Date: Mon Sep 3 16:47:56 2012 +0000 powerpc: Update DSCR on all CPUs when writing sysfs dscr_default commit 1b6ca2a6fe56e7697d57348646e07df08f43b1bb upstream. Writing to dscr_default in sysfs doesn't actually change the DSCR - we rely on a context switch on each CPU to do the work. There is no guarantee we will get a context switch in a reasonable amount of time so fire off an IPI to force an immediate change. This issue was found with the following test case: http://ozlabs.org/~anton/junkcode/dscr_explicit_test.c Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 3b75588b26cc22a16ff812e38ba7720b3e2d9b38 Author: Ian Chen Date: Wed Aug 29 15:05:36 2012 +0900 mmc: card: Skip secure erase on MoviNAND; causes unrecoverable corruption. commit 3550ccdb9d8d350e526b809bf3dd92b550a74fe1 upstream. For several MoviNAND eMMC parts, there are known issues with secure erase and secure trim. For these specific MoviNAND devices, we skip these operations. Specifically, there is a bug in the eMMC firmware that causes unrecoverable corruption when the MMC is erased with MMC_CAP_ERASE enabled. References: http://forum.xda-developers.com/showthread.php?t=1644364 https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB#111398485184813224730/posts/21pTYfTsCkB Signed-off-by: Ian Chen Reviewed-by: Namjae Jeon Acked-by: Jaehoon Chung Reviewed-by: Linus Walleij Signed-off-by: Chris Ball [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit a0d9ef18e6578ebce77372896fa8fb1ba19e1612 Author: Shawn Guo Date: Wed Aug 22 23:10:01 2012 +0800 mmc: sdhci-esdhc: break out early if clock is 0 commit 74f330bceaa7b88d06062e1cac3d519a3dfc041e upstream. Since commit 30832ab56 ("mmc: sdhci: Always pass clock request value zero to set_clock host op") was merged, esdhc_set_clock starts hitting "if (clock == 0)" where ESDHC_SYSTEM_CONTROL has been operated. This causes SDHCI card-detection function being broken. Fix the regression by moving "if (clock == 0)" above ESDHC_SYSTEM_CONTROL operation. Signed-off-by: Shawn Guo Signed-off-by: Chris Ball Signed-off-by: Ben Hutchings commit 3a0ae8e18c188a90c8a54fd26d18d6da5a084892 Author: Lauri Hintsala Date: Tue Jul 17 17:16:10 2012 +0300 mmc: mxs-mmc: fix deadlock caused by recursion loop commit fc108d24d3a6da63576a460e122fa1df0cbdea20 upstream. Release the lock before mmc_signal_sdio_irq is called by mxs_mmc_enable_sdio_irq. Backtrace: [ 65.470000] ============================================= [ 65.470000] [ INFO: possible recursive locking detected ] [ 65.470000] 3.5.0-rc5 #2 Not tainted [ 65.470000] --------------------------------------------- [ 65.470000] ksdioirqd/mmc0/73 is trying to acquire lock: [ 65.470000] (&(&host->lock)->rlock#2){-.-...}, at: [] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc] [ 65.470000] [ 65.470000] but task is already holding lock: [ 65.470000] (&(&host->lock)->rlock#2){-.-...}, at: [] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc] [ 65.470000] [ 65.470000] other info that might help us debug this: [ 65.470000] Possible unsafe locking scenario: [ 65.470000] [ 65.470000] CPU0 [ 65.470000] ---- [ 65.470000] lock(&(&host->lock)->rlock#2); [ 65.470000] lock(&(&host->lock)->rlock#2); [ 65.470000] [ 65.470000] *** DEADLOCK *** [ 65.470000] [ 65.470000] May be due to missing lock nesting notation [ 65.470000] [ 65.470000] 1 lock held by ksdioirqd/mmc0/73: [ 65.470000] #0: (&(&host->lock)->rlock#2){-.-...}, at: [] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc] [ 65.470000] [ 65.470000] stack backtrace: [ 65.470000] [] (unwind_backtrace+0x0/0xf4) from [] (__lock_acquire+0x14f8/0x1b98) [ 65.470000] [] (__lock_acquire+0x14f8/0x1b98) from [] (lock_acquire+0xa0/0x108) [ 65.470000] [] (lock_acquire+0xa0/0x108) from [] (_raw_spin_lock_irqsave+0x48/0x5c) [ 65.470000] [] (_raw_spin_lock_irqsave+0x48/0x5c) from [] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) [ 65.470000] [] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) from [] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) [ 65.470000] [] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) from [] (sdio_irq_thread+0x1bc/0x274) [ 65.470000] [] (sdio_irq_thread+0x1bc/0x274) from [] (kthread+0x8c/0x98) [ 65.470000] [] (kthread+0x8c/0x98) from [] (kernel_thread_exit+0x0/0x8) [ 65.470000] BUG: spinlock lockup suspected on CPU#0, ksdioirqd/mmc0/73 [ 65.470000] lock: 0xc3358724, .magic: dead4ead, .owner: ksdioirqd/mmc0/73, .owner_cpu: 0 [ 65.470000] [] (unwind_backtrace+0x0/0xf4) from [] (do_raw_spin_lock+0x100/0x144) [ 65.470000] [] (do_raw_spin_lock+0x100/0x144) from [] (_raw_spin_lock_irqsave+0x50/0x5c) [ 65.470000] [] (_raw_spin_lock_irqsave+0x50/0x5c) from [] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) [ 65.470000] [] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) from [] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) [ 65.470000] [] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) from [] (sdio_irq_thread+0x1bc/0x274) [ 65.470000] [] (sdio_irq_thread+0x1bc/0x274) from [] (kthread+0x8c/0x98) [ 65.470000] [] (kthread+0x8c/0x98) from [] (kernel_thread_exit+0x0/0x8) Reported-by: Attila Kinali Signed-off-by: Lauri Hintsala Acked-by: Shawn Guo Signed-off-by: Chris Ball [bwh: Backported to 3.2: - Adjust context - HW_SSP_STATUS is a simple rather than function-like macro] Signed-off-by: Ben Hutchings commit 2fa07abbe88fa0452121d13c44c95595b19ed67d Author: Lauri Hintsala Date: Tue Jul 17 17:16:09 2012 +0300 mmc: mxs-mmc: fix deadlock in SDIO IRQ case commit 1af36b2a993dddfa3d6860ec4879c9e8abc9b976 upstream. Release the lock before mmc_signal_sdio_irq is called by mxs_mmc_irq_handler. Backtrace: [ 79.660000] ============================================= [ 79.660000] [ INFO: possible recursive locking detected ] [ 79.660000] 3.4.0-00009-g3e96082-dirty #11 Not tainted [ 79.660000] --------------------------------------------- [ 79.660000] swapper/0 is trying to acquire lock: [ 79.660000] (&(&host->lock)->rlock#2){-.....}, at: [] mxs_mmc_enable_sdio_irq+0x18/0xd4 [ 79.660000] [ 79.660000] but task is already holding lock: [ 79.660000] (&(&host->lock)->rlock#2){-.....}, at: [] mxs_mmc_irq_handler+0x1c/0xe8 [ 79.660000] [ 79.660000] other info that might help us debug this: [ 79.660000] Possible unsafe locking scenario: [ 79.660000] [ 79.660000] CPU0 [ 79.660000] ---- [ 79.660000] lock(&(&host->lock)->rlock#2); [ 79.660000] lock(&(&host->lock)->rlock#2); [ 79.660000] [ 79.660000] *** DEADLOCK *** [ 79.660000] [ 79.660000] May be due to missing lock nesting notation [ 79.660000] [ 79.660000] 1 lock held by swapper/0: [ 79.660000] #0: (&(&host->lock)->rlock#2){-.....}, at: [] mxs_mmc_irq_handler+0x1c/0xe8 [ 79.660000] [ 79.660000] stack backtrace: [ 79.660000] [] (unwind_backtrace+0x0/0xf4) from [] (__lock_acquire+0x1948/0x1d48) [ 79.660000] [] (__lock_acquire+0x1948/0x1d48) from [] (lock_acquire+0xe0/0xf8) [ 79.660000] [] (lock_acquire+0xe0/0xf8) from [] (_raw_spin_lock_irqsave+0x44/0x58) [ 79.660000] [] (_raw_spin_lock_irqsave+0x44/0x58) from [] (mxs_mmc_enable_sdio_irq+0x18/0xd4) [ 79.660000] [] (mxs_mmc_enable_sdio_irq+0x18/0xd4) from [] (mxs_mmc_irq_handler+0xd4/0xe8) [ 79.660000] [] (mxs_mmc_irq_handler+0xd4/0xe8) from [] (handle_irq_event_percpu+0x70/0x254) [ 79.660000] [] (handle_irq_event_percpu+0x70/0x254) from [] (handle_irq_event+0x3c/0x5c) [ 79.660000] [] (handle_irq_event+0x3c/0x5c) from [] (handle_level_irq+0x90/0x110) [ 79.660000] [] (handle_level_irq+0x90/0x110) from [] (generic_handle_irq+0x38/0x50) [ 79.660000] [] (generic_handle_irq+0x38/0x50) from [] (handle_IRQ+0x30/0x84) [ 79.660000] [] (handle_IRQ+0x30/0x84) from [] (__irq_svc+0x38/0x60) [ 79.660000] [] (__irq_svc+0x38/0x60) from [] (default_idle+0x2c/0x40) [ 79.660000] [] (default_idle+0x2c/0x40) from [] (cpu_idle+0x64/0xcc) [ 79.660000] [] (cpu_idle+0x64/0xcc) from [] (start_kernel+0x244/0x2c8) [ 79.660000] BUG: spinlock lockup on CPU#0, swapper/0 [ 79.660000] lock: c398cb2c, .magic: dead4ead, .owner: swapper/0, .owner_cpu: 0 [ 79.660000] [] (unwind_backtrace+0x0/0xf4) from [] (do_raw_spin_lock+0xf0/0x144) [ 79.660000] [] (do_raw_spin_lock+0xf0/0x144) from [] (_raw_spin_lock_irqsave+0x4c/0x58) [ 79.660000] [] (_raw_spin_lock_irqsave+0x4c/0x58) from [] (mxs_mmc_enable_sdio_irq+0x18/0xd4) [ 79.660000] [] (mxs_mmc_enable_sdio_irq+0x18/0xd4) from [] (mxs_mmc_irq_handler+0xd4/0xe8) [ 79.660000] [] (mxs_mmc_irq_handler+0xd4/0xe8) from [] (handle_irq_event_percpu+0x70/0x254) [ 79.660000] [] (handle_irq_event_percpu+0x70/0x254) from [] (handle_irq_event+0x3c/0x5c) [ 79.660000] [] (handle_irq_event+0x3c/0x5c) from [] (handle_level_irq+0x90/0x110) [ 79.660000] [] (handle_level_irq+0x90/0x110) from [] (generic_handle_irq+0x38/0x50) [ 79.660000] [] (generic_handle_irq+0x38/0x50) from [] (handle_IRQ+0x30/0x84) [ 79.660000] [] (handle_IRQ+0x30/0x84) from [] (__irq_svc+0x38/0x60) [ 79.660000] [] (__irq_svc+0x38/0x60) from [] (default_idle+0x2c/0x40) [ 79.660000] [] (default_idle+0x2c/0x40) from [] (cpu_idle+0x64/0xcc) [ 79.660000] [] (cpu_idle+0x64/0xcc) from [] (start_kernel+0x244/0x2c8) Signed-off-by: Lauri Hintsala Acked-by: Shawn Guo Signed-off-by: Chris Ball [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 68b7b07e0d827a581058c5e4adb0a348e9a53a53 Author: Miklos Szeredi Date: Tue Sep 4 18:45:54 2012 +0200 fuse: fix retrieve length commit c9e67d483776d8d2a5f3f70491161b205930ffe1 upstream. In some cases fuse_retrieve() would return a short byte count if offset was non-zero. The data returned was correct, though. Signed-off-by: Miklos Szeredi Signed-off-by: Ben Hutchings commit 7b07c2bc5547b5f4b35eda35b6754faf10b5ccc7 Author: Artem Bityutskiy Date: Mon Sep 3 17:12:29 2012 +0300 UBI: fix a horrible memory deallocation bug commit 78b495c39add820ab66ab897af9bd77a5f2e91f6 upstream. UBI was mistakingly using 'kfree()' instead of 'kmem_cache_free()' when freeing "attach eraseblock" structures in vtbl.c. Thankfully, this happened only when we were doing auto-format, so many systems were unaffected. However, there are still many users affected. It is strange, but the system did not crash and nothing bad happened when the SLUB memory allocator was used. However, in case of SLOB we observed an crash right away. This problem was introduced in 2.6.39 by commit "6c1e875 UBI: add slab cache for ubi_scan_leb objects" A note for stable trees: Because variable were renamed, this won't cleanly apply to older kernels. Changing names like this should help: 1. ai -> si 2. aeb_slab_cache -> seb_slab_cache 3. new_aeb -> new_seb Reported-by: Richard Genoud Tested-by: Richard Genoud Tested-by: Artem Bityutskiy Signed-off-by: Artem Bityutskiy [bwh: Backported to 3.2: aeb_slab_cache was actually named scan_leb_slab] Signed-off-by: Ben Hutchings commit 33c5063fd1deb751e11e240cb88a6795306ce5cc Author: Jan Kara Date: Mon Sep 3 16:50:42 2012 +0200 ext3: Fix fdatasync() for files with only i_size changes commit 156bddd8e505b295540f3ca0e27dda68cb0d49aa upstream. Code tracking when transaction needs to be committed on fdatasync(2) forgets to handle a situation when only inode's i_size is changed. Thus in such situations fdatasync(2) doesn't force transaction with new i_size to disk and that can result in wrong i_size after a crash. Fix the issue by updating inode's i_datasync_tid whenever its size is updated. Reported-by: Kristian Nielsen Signed-off-by: Jan Kara [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 78e96c146124c1ebbd9387bc2d26185b262563b9 Author: Bruce Allan Date: Fri Aug 24 20:38:11 2012 +0000 e1000e: DoS while TSO enabled caused by link partner with small MSS commit d821a4c4d11ad160925dab2bb009b8444beff484 upstream. With a low enough MSS on the link partner and TSO enabled locally, the networking stack can periodically send a very large (e.g. 64KB) TCP message for which the driver will attempt to use more Tx descriptors than are available by default in the Tx ring. This is due to a workaround in the code that imposes a limit of only 4 MSS-sized segments per descriptor which appears to be a carry-over from the older e1000 driver and may be applicable only to some older PCI or PCIx parts which are not supported in e1000e. When the driver gets a message that is too large to fit across the configured number of Tx descriptors, it stops the upper stack from queueing any more and gets stuck in this state. After a timeout, the upper stack assumes the adapter is hung and calls the driver to reset it. Remove the unnecessary limitation of using up to only 4 MSS-sized segments per Tx descriptor, and put in a hard failure test to catch when attempting to check for message sizes larger than would fit in the whole Tx ring. Refactor the remaining logic that limits the size of data per Tx descriptor from a seemingly arbitrary 8KB to a limit based on the dynamic size of the Tx packet buffer as described in the hardware specification. Also, fix the logic in the check for space in the Tx ring for the next largest possible packet after the current one has been successfully queued for transmit, and use the appropriate defines for default ring sizes in e1000_probe instead of magic values. This issue goes back to the introduction of e1000e in 2.6.24 when it was split off from e1000. Reported-by: Ben Hutchings Signed-off-by: Bruce Allan Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller [bwh: Backported to 3.2: - Adjust context - Adjust for use of net_device vs e1000_ring parameter] Signed-off-by: Ben Hutchings commit 307937c6743d8657620ba8d4828afc6b42b384c6 Author: Paul Menzel Date: Wed Aug 8 23:12:19 2012 +0200 drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S commit 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b upstream. Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with vertical stripes in the top half. In commit bc42aabc [2] commit bc42aabc6a01b92b0f961d65671564e0e1cd7592 Author: Adam Jackson Date: Wed May 23 16:26:54 2012 -0400 drm/edid/quirks: ViewSonic VA2026w Adam Jackson added the quirk `EDID_QUIRK_FORCE_REDUCED_BLANKING` which is also needed for this ASUS monitor. All log files and output from `xrandr` is included in the referenced Bugzilla report #17629. Please note that this monitor only has a VGA (D-Sub) connector [1]. [1] http://www.asus.com/Display/LCD_Monitors/VW222S/ [2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bc42aabc6a01b92b0f961d65671564e0e1cd7592 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=17629 Signed-off-by: Paul Menzel Cc: Cc: Adam Jackson Cc: Ian Pilcher Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings commit 84a53fbef86fe96e363ee716b80abbe6d55cfc37 Author: Adam Jackson Date: Wed May 23 16:26:54 2012 -0400 drm/edid/quirks: ViewSonic VA2026w commit bc42aabc6a01b92b0f961d65671564e0e1cd7592 upstream. Entirely new class of fail for this one. The detailed timings are for normal CVT but the monitor really wanted CVT-R. Bugzilla: http://bugzilla.redhat/com/516471 Signed-off-by: Adam Jackson Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings commit 07137a221c2e771605a5f1b106d471c6dd827fa6 Author: Jerome Glisse Date: Tue Aug 28 16:50:22 2012 -0400 drm/radeon: force dma32 to fix regression rs4xx,rs6xx,rs740 commit 4a2b6662c3632176b4fdf012243dd3751367bf1f upstream. It seems some of those IGP dislike non dma32 page despite what documentation says. Fix regression since we allowed non dma32 pages. It seems it only affect some revision of those IGP chips as we don't know which one just force dma32 for all of them. https://bugzilla.redhat.com/show_bug.cgi?id=785375 Signed-off-by: Jerome Glisse Signed-off-by: Alex Deucher Signed-off-by: Ben Hutchings commit fb7094d55edc1fa667d042b8ac5aef3d57b856d4 Author: Alex Deucher Date: Wed Aug 22 09:54:56 2012 -0400 drm/radeon/atom: rework DIG modesetting on DCE3+ commit 8d1af57ae3c4458ed0de93ef97f388dd1b3239c7 upstream. The ordering is important and the current drm code wasn't cutting it for modern DIG encoders. We need to have information about crtc before setting up the encoders so I've shifted the ordering a bit. Probably we'll need a full rework akin to danvet's recent intel patchs. This patch fixes numerous issues with DP bridge chips and makes link training much more reliable. Signed-off-by: Alex Deucher [bwh: Backported to 3.2: drop DCE6 cases] Signed-off-by: Ben Hutchings commit bcee0e636903477fae6070a6f49dfab44813e253 Author: Alex Deucher Date: Tue Aug 21 19:06:21 2012 -0400 drm/radeon: don't disable plls that are in use by other crtcs commit 4e58591c8961b3e31709313f75819f2eec06e322 upstream. Some plls are shared for DP. Signed-off-by: Alex Deucher Reviewed-by: Michel Dänzer [bwh: Backported to 3.2: add the dev and rdev variables, previously added upstream to support DCE6.1 which isn't supported in this version] Signed-off-by: Ben Hutchings commit cedfdedec428b13781cb231fbfb0de23729af2f0 Author: Alan Stern Date: Thu Aug 23 10:51:55 2012 -0400 HID: add NOGET quirk for Eaton Ellipse MAX UPS commit 67ddbb3e6568fb1820b2cc45b00c50702b114801 upstream. This patch (as1603) adds a NOGET quirk for the Eaton Ellipse MAX UPS device. (The USB IDs were already present in hid-ids.h, apparently under a different name.) Signed-off-by: Alan Stern Reported-by: Laurent Bigonville Signed-off-by: Jiri Kosina Signed-off-by: Ben Hutchings commit f41bb2729b2930aa361f0af56d32f941b5e91e37 Author: Aaron Tian Date: Thu Dec 15 11:09:06 2011 +0800 HID: multitouch: support PixArt optical touch screen commit b7ea95ff9baab144dacdc30d752307938c5ab6bf upstream. This patch modifies hid-multitouch driver for supporting PixArt optical touch screen. Because of the device does not have to set initial report, we apply "HID_QUIRK_NO_INIT_REPORTS" quirk and add the device into hid_blacklist[] Signed-off-by: Aaron Tian Signed-off-by: Jiri Kosina [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit cb4c3c5050800e3e7767ccb1d1233baac744ddf3 Author: Jakob Bornecrantz Date: Thu Aug 16 08:29:03 2012 +0000 drm: Check for invalid cursor flags commit 7c4eaca4162d0b5ad4fb39f974d7ffd71b9daa09 upstream. Signed-off-by: Jakob Bornecrantz Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings commit 770ba2389ee98d51fe12d738e0ed4006caefca47 Author: Jesse Barnes Date: Mon Nov 7 12:03:23 2011 -0800 drm: remove some potentially dangerous DRM_ERRORs commit acb4b992d8a13728044f430b47b9199aa45993e9 upstream. Each of these error messages can be caused by a broken or malicious userspace wanting to spam the dmesg with useless info. They're really not worthy of DRM_DEBUG statements either; those are generally only useful during bringup of new hardware or versions, and ought to be removed before going upstream anyway. Signed-off-by: Jesse Barnes Reviewed-by: Alex Deucher Signed-off-by: Dave Airlie [bwh: Backported to 3.2: s/r\./r->/ in drm_mode_addfb()] Signed-off-by: Ben Hutchings commit c09ccfb99f423aa9cdd865c72695c72402f2eb97 Author: Arnd Bergmann Date: Thu Aug 16 10:40:40 2012 +0000 ARM: imx: select CPU_FREQ_TABLE when needed commit f637c4c9405e21f44cf0045eaf77eddd3a79ca5a upstream. The i.MX cpufreq implementation uses the CPU_FREQ_TABLE helpers, so it needs to select that code to be built. This problem has apparently existed since the i.MX cpufreq code was first merged in v2.6.37. Building IMX without CPU_FREQ_TABLE results in: arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_exit': arch/arm/plat-mxc/cpufreq.c:173: undefined reference to `cpufreq_frequency_table_put_attr' arch/arm/plat-mxc/built-in.o: In function `mxc_set_target': arch/arm/plat-mxc/cpufreq.c:84: undefined reference to `cpufreq_frequency_table_target' arch/arm/plat-mxc/built-in.o: In function `mxc_verify_speed': arch/arm/plat-mxc/cpufreq.c:65: undefined reference to `cpufreq_frequency_table_verify' arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_init': arch/arm/plat-mxc/cpufreq.c:154: undefined reference to `cpufreq_frequency_table_cpuinfo' arch/arm/plat-mxc/cpufreq.c:162: undefined reference to `cpufreq_frequency_table_get_attr' Signed-off-by: Arnd Bergmann Acked-by: Shawn Guo Cc: Sascha Hauer Cc: Yong Shen Signed-off-by: Ben Hutchings commit aaee3116bff0cda7d0eb4e2723cc108d5c056988 Author: Konrad Rzeszutek Wilk Date: Fri Aug 17 16:43:28 2012 -0400 xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M. commit c96aae1f7f393387d160211f60398d58463a7e65 upstream. When we are finished with return PFNs to the hypervisor, then populate it back, and also mark the E820 MMIO and E820 gaps as IDENTITY_FRAMEs, we then call P2M to set areas that can be used for ballooning. We were off by one, and ended up over-writting a P2M entry that most likely was an IDENTITY_FRAME. For example: 1-1 mapping on 40000->40200 1-1 mapping on bc558->bc5ac 1-1 mapping on bc5b4->bc8c5 1-1 mapping on bc8c6->bcb7c 1-1 mapping on bcd00->100000 Released 614 pages of unused memory Set 277889 page(s) to 1-1 mapping Populating 40200-40466 pfn range: 614 pages added => here we set from 40466 up to bc559 P2M tree to be INVALID_P2M_ENTRY. We should have done it up to bc558. The end result is that if anybody is trying to construct a PTE for PFN bc558 they end up with ~PAGE_PRESENT. Reported-by-and-Tested-by: Andre Przywara Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Ben Hutchings commit a3aaee9f1070ccec4bf551af5b47b6037a939e1c Author: Shawn Guo Date: Wed Aug 22 21:46:39 2012 +0800 ARM: dts: imx51-babbage: fix esdhc cd/wp properties commit a46d2619d7180bda12bad2bf15bbd0731dfc2dcf upstream. The binding doc and dts use properties "fsl,{cd,wp}-internal" while esdhc driver uses "fsl,{cd,wp}-controller". Fix binding doc and dts to get them match driver code. Reported-by: Chris Ball Signed-off-by: Shawn Guo Acked-by: Chris Ball Signed-off-by: Ben Hutchings commit 63aa21efee43ad4d6ae0504f333e4aaad42183bd Author: Shawn Guo Date: Sat Aug 18 14:27:32 2012 +0800 ARM: imx6: spin the cpu until hardware takes it down commit c944b0b9354ea06ffb0c8a7178949f1185f9f499 upstream. Though commit 602bf40 (ARM: imx6: exit coherency when shutting down a cpu) improves the stability of imx6q cpu hotplug a lot, there are still hangs seen with a more stressful hotplug testing. It's expected that once imx_enable_cpu(cpu, false) is called, the cpu will be taken down by hardware immediately, and the code after that will not get any chance to execute. However, this is not always the case from the testing. The cpu could possibly be alive for a few cycles before hardware actually takes it down. So rather than letting cpu execute some code that could cause a hang in these cycles, let's make the cpu spin there and wait for hardware to take it down. Signed-off-by: Shawn Guo Signed-off-by: Ben Hutchings commit 3fd4e8f0ecd916f761459f0dc7174940ce3a0b99 Author: Grazvydas Ignotas Date: Tue Aug 21 09:09:48 2012 +0300 OMAPFB: fix framebuffer console colors commit c1c52848cef52e157468b8879fc3cae23b6f3a99 upstream. omapfb does not currently set pseudo palette correctly for color depths above 16bpp, making red text invisible, command like echo -e '\e[0;31mRED' > /dev/tty1 will display nothing on framebuffer console in 24bpp mode. This is because temporary variable is declared incorrectly, fix it. Signed-off-by: Grazvydas Ignotas Signed-off-by: Tomi Valkeinen Signed-off-by: Florian Tobias Schandinat Signed-off-by: Ben Hutchings commit 9ec662146036d6ed240721ab175607752e0819d2 Author: Xu, Anhua Date: Mon Aug 13 03:08:33 2012 +0000 drm/i915: fix wrong order of parameters in port checking functions commit b70ad586162609141f0aa9eb34790f31a8954f89 upstream. Wrong order of parameters passed-in when calling hdmi/adpa /lvds_pipe_enabled(), 2nd and 3rd parameters are reversed. This bug was indroduced by commit 1519b9956eb4b4180fa3f47c73341463cdcfaa37 Author: Keith Packard Date: Sat Aug 6 10:35:34 2011 -0700 drm/i915: Fix PCH port pipe select in CPT disable paths The reachable tag for this commit is v3.1-rc1-3-g1519b99 Signed-off-by: Anhua Xu Reviewed-by: Chris Wilson Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44876 Tested-by: Daniel Schroeder Signed-off-by: Daniel Vetter Signed-off-by: Ben Hutchings commit caac26534f1b995a1c985bb316ce9f4cbadfbaf8 Author: Adam Jackson Date: Fri Oct 7 14:38:43 2011 -0400 drm/i915: Fix assert_pch_hdmi_disabled to mention HDMI (not DP) commit 23c99e775d14f01ba45a5affd2fb51af4328359c upstream. Signed-off-by: Adam Jackson Signed-off-by: Daniel Vetter Signed-off-by: Ben Hutchings commit e5748ee03b46dab9048e38b04602eefbf648a0d2 Author: Luca Tettamanti Date: Tue Aug 21 17:36:28 2012 +0200 hwmon: (asus_atk0110) Add quirk for Asus M5A78L commit 43ca6cb28c871f2fbad10117b0648e5ae3b0f638 upstream. The old interface is bugged and reads the wrong sensor when retrieving the reading for the chassis fan (it reads the CPU sensor); the new interface works fine. Reported-by: Göran Uddeborg Tested-by: Göran Uddeborg Signed-off-by: Luca Tettamanti Signed-off-by: Guenter Roeck Signed-off-by: Ben Hutchings commit 31155dabf022ae9e239ca5321287f8128857a52d Author: James Bottomley Date: Wed Jul 25 23:55:55 2012 +0400 Fix 'Device not ready' issue on mpt2sas commit 14216561e164671ce147458653b1fea06a4ada1e upstream. This is a particularly nasty SCSI ATA Translation Layer (SATL) problem. SAT-2 says (section 8.12.2) if the device is in the stopped state as the result of processing a START STOP UNIT command (see 9.11), then the SATL shall terminate the TEST UNIT READY command with CHECK CONDITION status with the sense key set to NOT READY and the additional sense code of LOGICAL UNIT NOT READY, INITIALIZING COMMAND REQUIRED; mpt2sas internal SATL seems to implement this. The result is very confusing standby behaviour (using hdparm -y). If you suspend a drive and then send another command, usually it wakes up. However, if the next command is a TEST UNIT READY, the SATL sees that the drive is suspended and proceeds to follow the SATL rules for this, returning NOT READY to all subsequent commands. This means that the ordering of TEST UNIT READY is crucial: if you send TUR and then a command, you get a NOT READY to both back. If you send a command and then a TUR, you get GOOD status because the preceeding command woke the drive. This bit us badly because commit 85ef06d1d252f6a2e73b678591ab71caad4667bb Author: Tejun Heo Date: Fri Jul 1 16:17:47 2011 +0200 block: flush MEDIA_CHANGE from drivers on close(2) Changed our ordering on TEST UNIT READY commands meaning that SATA drives connected to an mpt2sas now suspend and refuse to wake (because the mpt2sas SATL sees the suspend *before* the drives get awoken by the next ATA command) resulting in lots of failed commands. The standard is completely nuts forcing this inconsistent behaviour, but we have to work around it. The fix for this is twofold: 1. Set the allow_restart flag so we wake the drive when we see it has been suspended 2. Return all TEST UNIT READY status directly to the mid layer without any further error handling which prevents us causing error handling which may offline the device just because of a media check TUR. Reported-by: Matthias Prager Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings commit fb225ce36716c46b10c68ab25c9f8c97563bd895 Author: Kashyap Desai Date: Tue Jul 17 18:20:44 2012 -0700 megaraid_sas: Move poll_aen_lock initializer commit bd8d6dd43a77bfd2b8fef5b094b9d6095e169dee upstream. The following patch moves the poll_aen_lock initializer from megasas_probe_one() to megasas_init(). This prevents a crash when a user loads the driver and tries to issue a poll() system call on the ioctl interface with no adapters present. Signed-off-by: Kashyap Desai Signed-off-by: Adam Radford Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings commit f64c045ad2f37a56f2c9ab9cfe662b2e797bb37e Author: sreekanth.reddy@lsi.com Date: Tue Jul 17 15:57:05 2012 +0530 mpt2sas: Fix for Driver oops, when loading driver with max_queue_depth command line option to a very small value commit 338b131a3269881c7431234855c93c219b0979b6 upstream. If the specified max_queue_depth setting is less than the expected number of internal commands, then driver will calculate the queue depth size to a negitive number. This negitive number is actually a very large number because variable is unsigned 16bit integer. So, the driver will ask for a very large amount of memory for message frames and resulting into oops as memory allocation routines will not able to handle such a large request. So, in order to limit this kind of oops, The driver need to set the max_queue_depth to a scsi mid layer's can_queue value. Then the overall message frames required for IO is minimum of either (max_queue_depth plus internal commands) or the IOC global credits. Signed-off-by: Sreekanth Reddy Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings commit abad539f71b3d3fc390f571f440843731794d91d Author: Dmitry Torokhov Date: Tue Aug 21 21:57:15 2012 -0700 Input: i8042 - add Gigabyte T1005 series netbooks to noloop table commit 7b125b94ca16b7e618c6241cb02c4c8060cea5e3 upstream. They all define their chassis type as "Other" and therefore are not categorized as "laptops" by the driver, which tries to perform AUX IRQ delivery test which fails and causes touchpad not working. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42620 Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit 22d4436ddd8532fe0ef66d0c4f72e93c23831b37 Author: Johannes Berg Date: Tue Aug 21 18:57:11 2012 +0200 iwlwifi: protect SRAM debugfs commit 4fc79db178f0a0ede479b4713e00df2d106028b3 upstream. If the device is not started, we can't read its SRAM and attempting to do so will cause issues. Protect the debugfs read. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville [bwh: Backported to 3.2: - Adjust context - Pass iwl_shared not iwl_priv pointer to iwl_is_ready_rf()] Signed-off-by: Ben Hutchings commit cfc41fe51189b356f4e8dd1982d1b97ee594d5fd Author: Johannes Berg Date: Tue Aug 21 18:57:10 2012 +0200 iwlwifi: fix flow handler debug code commit 94543a8d4fb302817014981489f15cb3b92ec3c2 upstream. iwl_dbgfs_fh_reg_read() can cause crashes and/or BUG_ON in slub because the ifdefs are wrong, the code in iwl_dump_fh() should use DEBUGFS, not DEBUG to protect the buffer writing code. Also, while at it, clean up the arguments to the function, some code and make it generally safer. Reported-by: Benjamin Herrenschmidt Signed-off-by: Johannes Berg Signed-off-by: John W. Linville [bwh: Backported to 3.2: adjust filenames and context] Signed-off-by: Ben Hutchings commit f7532f73105dc8f05f2970d41b1d71d41d59e8a0 Author: Arnaud Patard (Rtp) Date: Thu Jul 26 12:15:46 2012 +0200 ARM: Orion: Set eth packet size csum offload limit commit 58569aee5a1a5dcc25c34a0a2ed9a377874e6b05 upstream. The mv643xx ethernet controller limits the packet size for the TX checksum offloading. This patch sets this limits for Kirkwood and Dove which have smaller limits that the default. As a side note, this patch is an updated version of a patch sent some years ago: http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/017320.html which seems to have been lost. Signed-off-by: Arnaud Patard Signed-off-by: Jason Cooper [bwh: Backported to 3.2: adjust for the extra two parameters of orion_ge0{0,1}_init()] Signed-off-by: Ben Hutchings commit 20ac628bdcdd48828bdca10e91a8ef29a9aae527 Author: Jon Hunter Date: Fri Jul 13 15:12:03 2012 -0500 ARM: OMAP2+: Fix dmtimer set source clock failure commit 54f32a35f4d3a653a18a2c8c239f19ae060bd803 upstream. Calling the dmtimer function omap_dm_timer_set_source() fails if following a call to pm_runtime_put() to disable the timer. For example the following sequence would fail to set the parent clock ... omap_dm_timer_stop(gptimer); omap_dm_timer_set_source(gptimer, OMAP_TIMER_SRC_32_KHZ); The following error message would be seen ... omap_dm_timer_set_source: failed to set timer_32k_ck as parent The problem is that, by design, pm_runtime_put() simply decrements the usage count and returns before the timer has actually been disabled. Therefore, setting the parent clock failed because the timer was still active when the trying to set the parent clock. Setting a parent clock will fail if the clock you are setting the parent of has a non-zero usage count. To ensure that this does not fail use pm_runtime_put_sync() when disabling the timer. Note that this will not be seen on OMAP1 devices, because these devices do not use the clock framework for dmtimers. Signed-off-by: Jon Hunter Acked-by: Kevin Hilman Signed-off-by: Tony Lindgren Signed-off-by: Ben Hutchings commit ccd2951d12243c68b49654b14d54af7821c5eeaa Author: Heiko Stuebner Date: Tue Aug 7 19:12:05 2012 +0900 ARM: S3C24XX: Fix s3c2410_dma_enqueue parameters commit b01858c7806e7e6f6121da2e51c9222fc4d21dc6 upstream. Commit d670ac019f60 (ARM: SAMSUNG: DMA Cleanup as per sparse) changed the prototype of the s3c2410_dma_* functions to use the enum dma_ch instead of an generic unsigned int. In the s3c24xx dma.c s3c2410_dma_enqueue seems to have been forgotten, the other functions there were changed correctly. Signed-off-by: Heiko Stuebner Signed-off-by: Kukjin Kim Signed-off-by: Ben Hutchings commit 3d0292f5e659df73b893e3fa414d180a8ed5e562 Author: Mel Gorman Date: Mon Jul 23 12:16:19 2012 +0100 Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts commit bba3d8c3b3c0f2123be5bc687d1cddc13437c923 upstream. The following build error occured during a parisc build with swap-over-NFS patches applied. net/core/sock.c:274:36: error: initializer element is not constant net/core/sock.c:274:36: error: (near initialization for 'memalloc_socks') net/core/sock.c:274:36: error: initializer element is not constant Dave Anglin says: > Here is the line in sock.i: > > struct static_key memalloc_socks = ((struct static_key) { .enabled = > ((atomic_t) { (0) }) }); The above line contains two compound literals. It also uses a designated initializer to initialize the field enabled. A compound literal is not a constant expression. The location of the above statement isn't fully clear, but if a compound literal occurs outside the body of a function, the initializer list must consist of constant expressions. Reported-by: Fengguang Wu Signed-off-by: Mel Gorman Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings