- 09 Aug, 2012 40 commits
-
-
Tejun Heo authored
commit ce27e317 upstream. While refactoring cgroup file removal path, 05ef1d7c "cgroup: introduce struct cfent" incorrectly changed the @dir argument of simple_unlink() to the inode of the file being deleted instead of that of the containing directory. The effect of this bug is minor - ctime and mtime of the parent weren't properly updated on file deletion. Fix it by using @cgrp->dentry->d_inode instead. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Al Viro <viro@ZenIV.linux.org.uk> Acked-by:
Li Zefan <lizefan@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Heiko Carstens authored
commit 008c2e8f upstream. Make sure the kernel does not incorrectly create a SIGBUS signal during user space accesses: For user space accesses in the switched addressing mode case the kernel may walk page tables and access user address space via the kernel mapping. If a page table entry is invalid the function __handle_fault() gets called in order to emulate a page fault and trigger all the usual actions like paging in a missing page etc. by calling handle_mm_fault(). If handle_mm_fault() returns with an error fixup handling is necessary. For the switched addressing mode case all errors need to be mapped to -EFAULT, so that the calling uaccess function can return -EFAULT to user space. Unfortunately the __handle_fault() incorrectly calls do_sigbus() if VM_FAULT_SIGBUS is set. This however should only happen if a page fault was triggered by a user space instruction. For kernel mode uaccesses the correct action is to only return -EFAULT. So user space may incorrectly see SIGBUS signals because of this bug. For current machines this would only be possible for the switched addressing mode case in conjunction with futex operations. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Martin Schwidefsky authored
commit 0f6f281b upstream. The downgrade of the 4 level page table created by init_new_context is currently done only in start_thread31. If a 31 bit process forks the new mm uses a 4 level page table, including the task size of 2<<42 that goes along with it. This is incorrect as now a 31 bit process can map memory beyond 2GB. Define arch_dup_mmap to do the downgrade after fork. Signed-off-by:
-
Heiko Carstens authored
commit 0008204f upstream. The s390 idle accounting code uses a sequence counter which gets used when the per cpu idle statistics get updated and read. One assumption on read access is that only when the sequence counter is even and did not change while reading all values the result is valid. On cpu hotplug however the per cpu data structure gets initialized via a cpu hotplug notifier on CPU_ONLINE. CPU_ONLINE however is too late, since the onlined cpu is already running and might access the per cpu data. Worst case is that the data structure gets initialized while an idle thread is updating its idle statistics. This will result in an uneven sequence counter after an update. As a result user space tools like top, which access /proc/stat in order to get idle stats, will busy loop waiting for the sequence counter to become even again, which will never happen until the queried cpu will update its idle statistics again. And even then the sequence counter will only have an even value for a couple of cpu cycles. Fix this by moving the initialization of the per cpu idle statistics to cpu_init(). I prefer that solution in favor of changing the notifier to CPU_UP_PREPARE, which would be a different solution to the problem. Signed-off-by:
-
Amitkumar Karwar authored
commit fe020120 upstream. mwifiex driver supports 2x2 chips as well. Hence valid mcs values are 0 to 15. The check for mcs index is corrected in this patch. For example: if 40MHz is enabled and mcs index is 11, "iw link" command would show "tx bitrate: 108.0 MBit/s" without this patch. Now it shows "tx bitrate: 108.0 MBit/s MCS 11 40Mhz" with the patch. Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Forest Bond authored
commit f1b00f4d upstream. Commit d83579e2 incorporated some changes from the vendor driver that made it newly important that the calculated hardware version correctly include the CHIP_92D bit, as all of the IS_92D_* macros were changed to depend on it. However, this bit was being unset for dual-mac, dual-phy devices. The vendor driver behavior was modified to not do this, but unfortunately this change was not picked up along with the others. This caused scanning in the 2.4GHz band to be broken, and possibly other bugs as well. This patch brings the version calculation logic in parity with the vendor driver in this regard, and in doing so fixes the regression. However, the version calculation code in general continues to be largely incoherent and messy, and needs to be cleaned up. Signed-off-by:
Forest Bond <forest.bond@rapidrollout.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Larry Finger authored
commit 3ce4d85b upstream. In commit a7959c13, the USB part of rtlwifi was switched to convert _usb_read_sync() to using a preallocated buffer rather than one that has been acquired using kmalloc. Although this routine is named as though it were synchronous, there seem to be simultaneous users, and the selection of the index to the data buffer is not multi-user safe. This situation is addressed by adding a new spinlock. The routine cannot sleep, thus a mutex is not allowed. Signed-off-by:
-
Cloud Ren authored
commit fa0afcd1 upstream. When io access mode is enabled by BOOTROM or BIOS for AR8152 v2.1, the register can't be read/write by memory access mode. Clearing Bit 8 of Register 0x21c could fixed the issue. Signed-off-by:
Cloud Ren <cjren@qca.qualcomm.com> Signed-off-by:
xiong <xiong@qca.qualcomm.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Meenakshi Venkataraman authored
commit a35e2708 upstream. We missed passing an argument to the debug print. Fix it. Signed-off-by:
Meenakshi Venkataraman <meenakshi.venkataraman@intel.com> Reviewed-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Ilan Peer authored
commit e19ebcab upstream. It is possible that the BSS context is not active (for example when the current mode is set to GO), or that the vif->type is different than station. In such a case we cannot call mac80211 to report the average rssi for the interface (the function assumes that the vif is valid and that the type is station). Reported-by:
Daniel J Blueman <daniel@quora.org> Reviewed-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
-
Eliad Peller authored
commit dac211ec upstream. ieee80211_rx_mgmt_auth() doesn't handle denied authentication properly - it authenticates the station and waits for association (for 5 seconds) instead of failing the authentication. Fix it by destroying auth_data and bailing out instead. Signed-off-by:
Eliad Peller <eliad@wizery.com> Acked-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Christian Lamparter authored
commit 353d09c6 upstream. ieee802_1d_to_ac is defined as a const int[8], but the tid parameter has a range from 0 to 15. Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Johannes Berg authored
commit 097b0e1b upstream. b43 with open firmware crashes mac80211 because it changes the number of queues at runtime which, while it was never really supported, now crashes mac80211 due to the new hardware queue logic. Fix this by detecting open vs. proprietary fw earlier and registering with mac80211 with the right number of queues. Tested-by:
Stefan Lippers-Hollmann <s.l-h@gmx.de> Signed-off-by:
-
Johannes Berg authored
commit a6f38ac3 upstream. Larry (and some others I think) reported that with single-queue drivers mac80211 crashes when waking the queues. This happens because we allocate just a single queue for each virtual interface in case the driver doesn't have at least 4 queues, but the code stopping/waking the virtual interface queues wasn't taking this into account. Reported-by:
-
Mikulas Patocka authored
commit b09e786b upstream. This patch fixes a crash tun_chr_close -> netdev_run_todo -> tun_free_netdev -> sk_release_kernel -> sock_release -> iput(SOCK_INODE(sock)) introduced by commit 1ab5ecb9 The problem is that this socket is embedded in struct tun_struct, it has no inode, iput is called on invalid inode, which modifies invalid memory and optionally causes a crash. sock_release also decrements sockets_in_use, this causes a bug that "sockets: used" field in /proc/*/net/sockstat keeps on decreasing when creating and closing tun devices. This patch introduces a flag SOCK_EXTERNALLY_ALLOCATED that instructs sock_release to not free the inode and not decrement sockets_in_use, fixing both memory corruption and sockets_in_use underflow. It should be backported to 3.3 an 3.4 stabke. Signed-off-by:
Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz> Signed-off-by:
-
Rajiv Andrade authored
commit 24ebe667 upstream. tpm_do_selftest() attempts to read a PCR in order to decide if one can rely on the TPM being used or not. The function that's used by __tpm_pcr_read() does not expect the TPM to be disabled or deactivated, and if so, reports an error. It's fine if the TPM returns this error when trying to use it for the first time after a power cycle, but it's definitely not if it already returned success for a previous attempt to read one of its PCRs. The tpm_do_selftest() was modified so that the driver only reports this return code as an error when it really is. Reported-and-tested-by:
Paul Bolle <pebolle@tiscali.nl> Signed-off-by:
Rajiv Andrade <srajiv@linux.vnet.ibm.com> Signed-off-by:
-
Colin Cross authored
commit 064b021f upstream. Commit cf579dfb (PM / Sleep: Introduce "late suspend" and "early resume" of devices) introduced a bug where suspend_late handlers would be called, but if dpm_suspend_noirq returned an error the early_resume handlers would never be called. All devices would end up on the dpm_late_early_list, and would never be resumed again. Fix it by calling dpm_resume_early when dpm_suspend_noirq returns an error. Signed-off-by:
Colin Cross <ccross@android.com> Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
-
Rafael J. Wysocki authored
commit 11388c87 upstream. Require processes wanting to use the wake_lock/wake_unlock sysfs files to have the CAP_BLOCK_SUSPEND capability, which also is required for the eventpoll EPOLLWAKEUP flag to be effective, so that all interfaces related to blocking autosleep depend on the same capability. Signed-off-by:
Michael Kerrisk <mtk.man-pages@gmail.com> Signed-off-by:
-
Srivatsa S. Bhat authored
commit 443772d4 upstream. If function tracing is enabled for some of the low-level suspend/resume functions, it leads to triple fault during resume from suspend, ultimately ending up in a reboot instead of a resume (or a total refusal to come out of suspended state, on some machines). This issue was explained in more detail in commit f42ac38c (ftrace: disable tracing for suspend to ram). However, the changes made by that commit got reverted by commit cbe2f5a6 (tracing: allow tracing of suspend/resume & hibernation code again). So, unfortunately since things are not yet robust enough to allow tracing of low-level suspend/resume functions, suspend/resume is still broken when ftrace is enabled. So fix this by disabling function tracing during suspend/resume & hibernation. Signed-off-by:
Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by:
-
J. Bruce Fields authored
commit 0ec4f431 upstream. The only checks of the long argument passed to fcntl(fd,F_SETLEASE,.) are done after converting the long to an int. Thus some illegal values may be let through and cause problems in later code. [ They actually *don't* cause problems in mainline, as of Dave Jones's commit 8d657eb3 "Remove easily user-triggerable BUG from generic_setlease", but we should fix this anyway. And this patch will be necessary to fix real bugs on earlier kernels. ] Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Tony Luck authored
commit 6751ed65 upstream. In commit dad1743e ("x86/mce: Only restart instruction after machine check recovery if it is safe") we fixed mce_notify_process() to force a signal to the current process if it was not restartable (RIPV bit not set in MCG_STATUS). But doing it here means that the process doesn't get told the virtual address of the fault via siginfo_t->si_addr. This would prevent application level recovery from the fault. Make a new MF_MUST_KILL flag bit for memory_failure() et al. to use so that we will provide the right information with the signal. Signed-off-by:
Tony Luck <tony.luck@intel.com> Acked-by:
Borislav Petkov <borislav.petkov@amd.com> Signed-off-by:
-
Borislav Petkov authored
commit c9fc3f77 upstream. Microcode reloading in a per-core manner is a very bad idea for both major x86 vendors. And the thing is, we have such interface with which we can end up with different microcode versions applied on different cores of an otherwise homogeneous wrt (family,model,stepping) system. So turn off the possibility of doing that per core and allow it only system-wide. This is a minimal fix which we'd like to see in stable too thus the more-or-less arbitrary decision to allow system-wide reloading only on the BSP: $ echo 1 > /sys/devices/system/cpu/cpu0/microcode/reload ... and disable the interface on the other cores: $ echo 1 > /sys/devices/system/cpu/cpu23/microcode/reload -bash: echo: write error: Invalid argument Also, allowing the reload only from one CPU (the BSP in that case) doesn't allow the reload procedure to degenerate into an O(n^2) deal when triggering reloads from all /sys/devices/system/cpu/cpuX/microcode/reload sysfs nodes simultaneously. A more generic fix will follow. Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
David Henningsson authored
commit 108cc108 upstream. Also add a model/fixup string "lenovo-dock", so that other Thinkpad users will be able to test this fixup easily, to see if it enables dock I/O for them as well. BugLink: https://bugs.launchpad.net/bugs/1026953Tested-by:
John McCarron <john.mccarron@canonical.com> Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Sarah Sharp authored
commit 24971912 upstream. When a user runs `echo 0 > bConfigurationValue` for a USB 3.0 device, usb_disable_device() is called. This function disables all drivers, deallocates interfaces, and sets the device configuration value to 0 (unconfigured). With the new scheme to ensure that unconfigured devices have LPM disabled, usb_disable_device() must call usb_unlocked_disable_lpm() once it unconfigures the device. This commit should be backported to kernels as old as 3.5, that contain the commit 8306095f "USB: Disable USB 3.0 LPM in critical sections." Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Sarah Sharp authored
commit c5c4bdf0 upstream. hub_initiated_lpm_disable_count is not used by any code, so remove it. This commit should be backported to kernels as old as 3.5, that contain the commit 8306095f "USB: Disable USB 3.0 LPM in critical sections." Signed-off-by:
-
Sarah Sharp authored
commit 6d1d0513 upstream. The USB 3.0 specification says that sending a Set Feature or Clear Feature for U1/U2 Enable is not a valid request when the device is in the Default or Addressed state. It is only valid when the device is in the Configured state. The original LPM patch attempted to disable LPM after the device had been reset by hub_port_init(), before it had the configuration reinstalled. The TI hub I tested with did not fail the Clear Feature U1/U2 Enable request that khubd sent while it was in the addressed state, which is why I didn't catch it. Move the LPM disable before the device reset, so that we can send the Clear Feature U1/U2 Enable successfully, and balance the LPM disable count. Also delete any calls to usb_enable_lpm() on error paths that lead to re-enumeration. The calls will fail because the device isn't configured, and it's not useful to balance the LPM disable count because the usb_device is about to be destroyed before re-enumeration. Fix the early exit path ("done" label) to call usb_enable_lpm() to balance the LPM disable count. Note that calling usb_reset_and_verify_device() with an unconfigured device may fail on the first call to usb_disable_lpm(). That's because the LPM disable count is initialized to 0 (LPM enabled), and usb_disable_lpm() will attempt to send a Clear Feature U1/U2 request to a device in the Addressed state. The next patch will fix that. This commit should be backported to kernels as old as 3.5, that contain the commit 8306095f "USB: Disable USB 3.0 LPM in critical sections." Signed-off-by:
-
Sarah Sharp authored
commit 9cf65991 upstream. The USB 3.0 Set/Clear Feature U1/U2 Enable cannot be sent to a device in the Default or Addressed state. It can only be sent to a configured device. Change the USB core to initialize the LPM disable count to 1 (disabled), which reflects this limitation. Change usb_set_configuration() to ensure that if the device is unconfigured on entry, usb_lpm_disable() is not called. This avoids sending the Clear Feature U1/U2 when the device is in the Addressed state. When usb_set_configuration() exits with a successfully installed configuration, usb_lpm_enable() will be called. Once the new configuration is installed, make sure usb_set_configuration() only calls usb_enable_lpm() if the device moved to the Configured state. If we have unconfigured the device by sending it a Set Configuration for config 0, don't enable LPM. This commit should be backported to kernels as old as 3.5, that contain the commit 8306095f "USB: Disable USB 3.0 LPM in critical sections." Signed-off-by:
-
Gerd Hoffmann authored
commit c621a81e upstream. This reverts commit e4d8318a. This patch makes uas.c call usb_unlink_urb on data urbs. The data urbs get freed in the completion callback. This is illegal according to the usb_unlink_urb documentation. This patch also makes the code expect the data completion callback being called before the status completion callback. This isn't guaranteed to be the case, even though the actual data transfer should be finished by the time the status is received. Background: The ehci irq handler for example only know that there are finished transfers, it then has go check the QHs & TDs to see which transfers did actually finish. It has no way to figure in which order the transfers did complete. The xhci driver can call the callbacks in completion order thanks to the event queue. This does nicely explain why the driver is solid on a (usb2) xhci port whereas it goes crazy on ehci in my testing. Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
Bjørn Mork authored
commit 09110529 upstream. Sold by O2 (telefonica germany) under the name "LTE4G" Tested-by:
Thomas Schäfer <tschaefer@t-online.de> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Kevin Cernekee authored
commit 31bde1ce upstream. A "usb0" interface that has never been connected to a host has an unknown operstate, and therefore the IFF_RUNNING flag is (incorrectly) asserted when queried by ifconfig, ifplugd, etc. This is a result of calling netif_carrier_off() too early in the probe function; it should be called after register_netdev(). Similar problems have been fixed in many other drivers, e.g.: e826eafa (bonding: Call netif_carrier_off after register_netdevice) 0d672e9f (drivers/net: Call netif_carrier_off at the end of the probe) 6a3c869a (cxgb4: fix reported state of interfaces without link) Fix is to move netif_carrier_off() to the end of the function. Signed-off-by:
Kevin Cernekee <cernekee@gmail.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Hans de Goede authored
commit 2102e06a upstream. iso data buffers may have holes in them if some packets were short, so for iso urbs we should always copy the entire buffer, just like the regular processcompl does. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Benjamin Tissoires authored
commit 4aceed37 upstream. Zytronic panels shows a new way of setting the Input Mode feature. This feature is put in the second usage in the HID feature, instead of the first, as the majority of the multitouch devices. This patch adds a detection step when the feature is presented to know where the feature is located in the report. We can then trigger the right command to the device. This removes the magic number "0" in the function mt_set_input_mode. Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@enac.fr> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Cc: Simon Farnsworth <simon.farnsworth@onelan.co.uk> Signed-off-by:
-
Dylan Reid authored
commit b43d2247 upstream. After cancel_delayed_work_sync returns, the power down work either never started (power_on == 1) or finished (power_on == 0). In the former case there is no need to power up again. Signed-off-by:
Dylan Reid <dgreid@chromium.org> Signed-off-by:
-
Dylan Reid authored
commit 9e76e6d0 upstream. Turn on the pin widget's PIN_OUT bit from playback prepare. The pin is enabled in open, but is disabled in hdmi_init_pin which is called during system resume. This causes a system suspend/resume during playback to mute HDMI/DP. Enabling the pin in prepare instead of open allows calling snd_pcm_prepare after a system resume to restore audio. Signed-off-by:
-
David Henningsson authored
commit 4e01ec63 upstream. This codec has a separate dmic path (separate dmic only ADC), and thus it looks mostly like ALC275. BugLink: https://bugs.launchpad.net/bugs/1025377Tested-by:
Ray Chen <ray.chen@canonical.com> Signed-off-by:
-
Mark Brown authored
commit e4dd7678 upstream. Ensure robust startup of the part by going through the reset procedure prior to resyncing the full register cache, avoiding potential intermittent faults in some designs. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Mark Brown authored
commit 0ff97ebf upstream. Ever since the DAPM performance improvements we've been marking all widgets as not dirty after each DAPM run. Since _PRE and _POST events aren't part of the DAPM graph this has rendered them non-functional, they will never be marked dirty again and thus will never be run again. Fix this by skipping them when marking widgets as not dirty. Signed-off-by:
Liam Girdwood <lrg@ti.com> Signed-off-by:
-
Liam Girdwood authored
commit 01005a72 upstream. Codec shutdown performs a DAPM power sequence that might cause conflicts and/or race conditions if another stream power event is running simultaneously. Use card's dapm mutex to protect any potential race condition between them. Signed-off-by:
Misael Lopez Cruz <misael.lopez@ti.com> Signed-off-by:
-
Stephen Warren authored
commit 01ad8063 upstream. On TrimSlice, Tegra's USB1 port may be routed to either an external micro USB port, or an internal USB->SATA bridge for SSD or HDD. This muxing is controlled by a GPIO. Whilst not strictly a VBUS GPIO, the TrimSlice board files caused this GPIO to be set appropriately to enable the SATA bridge by passing it as the VBUS GPIO to the USB driver. Echo this same configuration in device tree to enable the SATA bridge. An alternative might be to implement a full USB bus mux driver. However, that seems over-complex right now. Signed-off-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Nishanth Menon authored
commit b110547e upstream. Commit 9fa2df6b (ARM: OMAP2+: OPP: allow OPP enumeration to continue if device is not present) makes the logic: for (i = 0; i < opp_def_size; i++) { <snip> if (!oh || !oh->od) { <snip> continue; } <snip> opp_def++; } In short, the moment we hit a "Bad OPP", we end up looping the list comparing against the bad opp definition pointer for the rest of the iteration count. Instead, increment opp_def in the for loop itself and allow continue to be used in code without much thought so that we check the next set of OPP definition pointers :) Cc: Steve Sakoman <steve@sakoman.com> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Kevin Hilman <khilman@ti.com> Signed-off-by:
-
