- 03 Jan, 2013 40 commits
-
-
Kevin McKinney authored
commit 4f29ef05 upstream. This patch adds two new products and modifies the device id table to include them. In addition, product of 0xbccd - BCM_USB_PRODUCT_ID_SM250 is removed because Beceem, ZTE, Sprint use this id for block devices. Reported-by:
Muhammad Minhazul Haque <mdminhazulhaque@gmail.com> Signed-off-by:
Kevin McKinney <klmckinney1@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: adjust context] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Kevin McKinney authored
commit e66fc1fb upstream. This patch create and initalizes a new device id of 0x172 as reported by Rinat Camalov <richman1000000d@gmail.com>. In addition, a comment is added to the potential invalid existing device id. Reported-by:
Rinat Camalov <richman1000000d@gmail.com> Signed-off-by:
-
Alexis R. Cortes authored
commit b0e4e606 upstream. This minor patch creates a more stricter conditional for the Z1 sytems for applying the Compliance Mode Patch, this to avoid the quirk to be applied to models that contain a "Z1" in their dmi product string but are different from Z1 systems. This patch should be backported to stable kernels as old as 3.2, that contain the commit 71c731a2 "usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware" Signed-off-by:
Alexis R. Cortes <alexis.cortes@ti.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Sarah Sharp authored
commit bba18e33 upstream. Ali reports that plugging a device into the Fresco Logic xHCI host with PCI device ID 1400 produces an IRQ error: do_IRQ: 3.176 No irq handler for vector (irq -1) Other early Fresco Logic host revisions don't support MSI, even though their PCI config space claims they do. Extend the quirk to disabling MSI to this chipset revision. Also enable the short transfer quirk, since it's likely this revision also has that quirk, and it should be harmless to enable. 04:00.0 0c03: 1b73:1400 (rev 01) (prog-if 30 [XHCI]) Subsystem: 1d5c:1000 Physical Slot: 3 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 51 Region 0: Memory at d4600000 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000feeff00c Data: 41b1 Capabilities: [80] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <2us, L1 <32us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 unlimited ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Kernel driver in use: xhci_hcd This patch should be backported to stable kernels as old as 2.6.36, that contain the commit f5182b41 "xhci: Disable MSI for some Fresco Logic hosts." Signed-off-by:
A Sh <smr.ash1991@gmail.com> Tested-by:
-
Julius Werner authored
commit 68e5254a upstream. xhci_alloc_segments_for_ring() builds a list of xhci_segments and links the tail to head at the end (forming a ring). When it bails out for OOM reasons half-way through, it tries to destroy its half-built list with xhci_free_segments_for_ring(), even though it is not a ring yet. This causes a null-pointer dereference upon hitting the last element. Furthermore, one of its callers (xhci_ring_alloc()) mistakenly believes the output parameters to be valid upon this kind of OOM failure, and calls xhci_ring_free() on them. Since the (incomplete) list/ring should already be destroyed in that case, this would lead to a use after free. This patch fixes those issues by having xhci_alloc_segments_for_ring() destroy its half-built, non-circular list manually and destroying the invalid struct xhci_ring in xhci_ring_alloc() with a plain kfree(). This patch should be backported to kernels as old as 2.6.31, that contains the commit 0ebbab37 "USB: xhci: Ring allocation and initialization." A separate patch will need to be developed for kernels older than 3.4, since the ring allocation code was refactored in that kernel. Signed-off-by:
Julius Werner <jwerner@chromium.org> Signed-off-by:
-
Sarah Sharp authored
commit 4525c0a1 upstream. The xHCI 1.0 specification made a change to the TD Size field in TRBs. The value is now the number of packets that remain to be sent in the TD, not including this TRB. The TD Size value for the last TRB in a TD must always be zero. The xHCI function xhci_v1_0_td_remainder() attempts to calculate this, but it gets it wrong. First, it erroneously reuses the old xhci_td_remainder function, which will right shift the value by 10. The xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10. Second, it does not set the TD size for the last TRB in a TD to zero. Third, it uses roundup instead of DIV_ROUND_UP. The total packet count is supposed to be the total number of bytes in this TD, divided by the max packet size, rounded up. DIV_ROUND_UP is the right function to use in that case. With the old code, a TD on an endpoint with max packet size 1024 would be set up like so: TRB 1, TRB length = 600 bytes, TD size = 0 TRB 1, TRB length = 200 bytes, TD size = 0 TRB 1, TRB length = 100 bytes, TD size = 0 With the new code, the TD would be set up like this: TRB 1, TRB length = 600 bytes, TD size = 1 TRB 1, TRB length = 200 bytes, TD size = 1 TRB 1, TRB length = 100 bytes, TD size = 0 This commit should be backported to kernels as old as 3.0, that contain the commit 4da6e6f2 "xhci 1.0: Update TD size field format." Signed-off-by:
Chintan Mehta <chintan.mehta@sibridgetech.com> Reported-by:
Shimmer Huang <shimmering.h@gmail.com> Tested-by:
Bhavik Kothari <bhavik.kothari@sibridgetech.com> Tested-by:
-
Sarah Sharp authored
commit 392a07ae upstream. David reports that at drivers/usb/host/xhci.c:2257: static bool xhci_is_sync_in_ep(unsigned int ep_type) { return (ep_type == ISOC_IN_EP || ep_type != INT_IN_EP); } The static analyser cppcheck says [linux-3.7-rc2/drivers/usb/host/xhci.c:2257]: (style) Redundant condition: If ep_type == 5, the comparison ep_type != 7 is always true. Maybe the original programmer intention was something like static bool xhci_is_sync_in_ep(unsigned int ep_type) { return (ep_type == ISOC_IN_EP || ep_type == INT_IN_EP); } Fix this. This patch should be backported to stable kernels as old as 3.2, that contain the commit 2b698999 "xhci: USB 3.0 BW checking." Signed-off-by:
David Binderman <dcb314@hotmail.com> Signed-off-by:
-
Thomas Gleixner authored
commit 04aa530e upstream. Sankara reported that the genirq core code fails to adjust the affinity of an interrupt thread in several cases: 1) On request/setup_irq() the call to setup_affinity() happens before the new action is registered, so the new thread is not notified. 2) For secondary shared interrupts nothing notifies the new thread to change its affinity. 3) Interrupts which have the IRQ_NO_BALANCE flag set are not moving the thread either. Fix this by setting the thread affinity flag right on thread creation time. This ensures that under all circumstances the thread moves to the right place. Requires a check in irq_thread_check_affinity for an existing affinity mask (CONFIG_CPU_MASK_OFFSTACK=y) Reported-and-tested-by:
Sankara Muthukrishnan <sankara.m@gmail.com> Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1209041738200.2754@ionosSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Alan Stern authored
commit 2656a9ab upstream. This patch (as1632b) fixes a bug in ehci-hcd. The USB core uses urb->hcpriv to determine whether or not an URB is active; host controller drivers are supposed to set this pointer to a non-NULL value when an URB is queued. However ehci-hcd sets it to NULL for isochronous URBs, which defeats the check in usbcore. In itself this isn't a big deal. But people have recently found that certain sequences of actions will cause the snd-usb-audio driver to reuse URBs without waiting for them to complete. In the absence of proper checking by usbcore, the URBs get added to their endpoint list twice. This leads to list corruption and a system freeze. The patch makes ehci-hcd assign a meaningful value to urb->hcpriv for isochronous URBs. Improving robustness always helps. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
Artem S. Tashkinov <t.artem@lycos.com> Reported-by:
Christof Meerwald <cmeerw@cmeerw.org> Signed-off-by:
-
Alan Stern authored
commit 36caff5d upstream. This patch (as1631) fixes a bug that shows up when a config change fails for a device under an xHCI controller. The controller needs to be told to disable the endpoints that have been enabled for the new config. The existing code does this, but before storing the information about which endpoints were enabled! As a result, any second attempt to install the new config is doomed to fail because xhci-hcd will refuse to enable an endpoint that is already enabled. The patch optimistically initializes the new endpoints' device structures before asking the device to switch to the new config. If the request fails then the endpoint information is already stored, so we can use usb_hcd_alloc_bandwidth() to disable the endpoints with no trouble. The rest of the error path is slightly more complex now; we have to disable the new interfaces and call put_device() rather than simply deallocating them. Signed-off-by:
Matthias Schniedermeyer <ms@citd.de> CC: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Will Deacon authored
commit 864aa04c upstream. When updating the page protection map after calculating the user_pgprot value, the base protection map is temporarily stored in an unsigned long type, causing truncation of the protection bits when LPAE is enabled. This effectively means that calls to mprotect() will corrupt the upper page attributes, clearing the XN bit unconditionally. This patch uses pteval_t to store the intermediate protection values, preserving the upper bits for 64-bit descriptors. Acked-by:
Nicolas Pitre <nico@linaro.org> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Eugene Shatokhin authored
commit 24ec19b0 upstream. In ext4_xattr_set_acl(), if ext4_journal_start() returns an error, posix_acl_release() will not be called for 'acl' which may result in a memory leak. This patch fixes that. Reviewed-by:
Lukas Czerner <lczerner@redhat.com> Signed-off-by:
Eugene Shatokhin <eugene.shatokhin@rosalab.ru> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
Roland Dreier authored
commit 1c5c12c6 upstream. There are some cases, for example when the initiator sends an out-of-bounds ErrorRecoveryLevel value, where the iSCSI target terminates the connection without sending back any error. Audit the login path and add appropriate iscsit_tx_login_rsp() calls to make sure this doesn't happen. Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Yanchuan Nian authored
commit 3c40794b upstream. The object type in the cache of lockowner_slab is wrong, and it is better to fix it. Signed-off-by:
Yanchuan Nian <ycnian@gmail.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Sergei Shtylyov authored
commit 8b416b0b upstream. Now that DaVinci glue layer can be modular, we must export cppi_interrupt() that it may call... Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Jan Beulich authored
commit 6acf5a8c upstream. HPET_TN_FSB is not a proper mask bit; it merely toggles between MSI and legacy interrupt delivery. The proper mask bit is HPET_TN_ENABLE, so use both bits when (un)masking the interrupt. Signed-off-by:
Jan Beulich <jbeulich@suse.com> Link: http://lkml.kernel.org/r/5093E09002000078000A60E6@nat28.tlf.novell.comSigned-off-by:
-
Sebastian Andrzej Siewior authored
commit 0f9df939 upstream. The "video->minor = -1" assigment is done in V4L2 by video_register_device() so it is removed here. Now. uvc_function_bind() calls in error case uvc_function_unbind() for cleanup. The problem is that uvc_function_unbind() frees the uvc struct and uvc_bind_config() does as well in error case of usb_add_function(). Removing kfree() in usb_add_function() would make the patch smaller but it would look odd because the new allocated memory is not cleaned up. However it is not guaranteed that if we call usb_add_function() we also get to the bind function. Therefore the patch extracts the conditional cleanup from uvc_function_unbind() applies to uvc_function_bind(). uvc_function_unbind() now contains only the complete cleanup which is required once everything has been registrated. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Bhupesh Sharma <bhupesh.sharma@st.com> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Sebastian Andrzej Siewior authored
commit d0eca719 upstream. Signed-off-by:
-
Sebastian Andrzej Siewior authored
commit d185039f upstream. The HS descriptors are only created if HS is supported by the UDC but we never free them. Signed-off-by:
-
Sebastian Andrzej Siewior authored
commit e79cc615 upstream. I think this is wrong since 72c973dd ("usb: gadget: add usb_endpoint_descriptor to struct usb_ep"). If we fail to allocate an ep or bail out early we shouldn't check for the descriptor which is assigned at ep_enable() time. Cc: Tatyana Brokhman <tlinder@codeaurora.org> Signed-off-by:
-
Alexander Graf authored
commit e43a0287 upstream. When remembering the direction of a DCR transaction, we should write to the same variable that we interpret on later when doing vcpu_run again. Signed-off-by:
Alexander Graf <agraf@suse.de> [bwh: Backported to 3.2: adjust context, indentation] Signed-off-by:
-
Rajkumar Manoharan authored
commit 16802602 upstream. This reduced the power consumption to half in full and network sleep. Cc: Paul Stewart <pstew@chromium.org> Signed-off-by:
Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.2: - INIT_INI_ARRAY macro requires an explicit size argument - Remove the now-redundant macro PCIE_PLL_ON_CREQ_DIS_L1_2P0] Signed-off-by:
-
Will Deacon authored
commit b92b1b89 upstream. Virtio devices may attempt to add descriptors to a virtqueue from atomic context using GFP_ATOMIC allocation. This is problematic because such allocations can fall outside of the lowmem mapping, causing virt_to_phys to report bogus physical addresses which are subsequently passed to userspace via the buffers for the virtual device. This patch masks out __GFP_HIGH and __GFP_HIGHMEM from the requested flags when allocating descriptors for a virtqueue. If an atomic allocation is requested and later fails, we will return -ENOSPC which will be handled by the driver. Cc: Sasha Levin <levinsasha928@gmail.com> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Will Deacon authored
commit b9cdc88d upstream. When using a virtio transport, the 9p net device may pass the physical address of a kernel buffer to userspace via a scatterlist inside a virtqueue. If the kernel buffer is mapped outside of the linear mapping (e.g. highmem), then virt_to_page will return a bogus value and we will populate the scatterlist with junk. This patch uses kmap_to_page when populating the page array for a kernel buffer. Cc: Sasha Levin <levinsasha928@gmail.com> Signed-off-by:
-
Will Deacon authored
commit f0263d2d upstream. Some virtio device drivers (9p) need to translate high virtual addresses to physical addresses, which are inserted into the virtqueue for processing by userspace. This patch exports the kmap_to_page symbol, so that the affected drivers can be compiled as modules. Signed-off-by:
-
Ben Hutchings authored
This is extracted from Mel Gorman's commit 5a178119 ('mm: add support for direct_IO to highmem pages') upstream. Required to backport commit b9cdc88d ('virtio: 9p: correctly pass physical address to userspace for high pages'). Cc: Mel Gorman <mgorman@suse.de> Cc: Rik van Riel <riel@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Tejun Heo authored
commit dd67d32d upstream. A task is considered frozen enough between freezer_do_not_count() and freezer_count() and freezers use freezer_should_skip() to test this condition. This supposedly works because freezer_count() always calls try_to_freezer() after clearing %PF_FREEZER_SKIP. However, there currently is nothing which guarantees that freezer_count() sees %true freezing() after clearing %PF_FREEZER_SKIP when freezing is in progress, and vice-versa. A task can escape the freezing condition in effect by freezer_count() seeing !freezing() and freezer_should_skip() seeing %PF_FREEZER_SKIP. This patch adds smp_mb()'s to freezer_count() and freezer_should_skip() such that either %true freezing() is visible to freezer_count() or !PF_FREEZER_SKIP is visible to freezer_should_skip(). Signed-off-by:
Tejun Heo <tj@kernel.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Rafael J. Wysocki <rjw@sisk.pl> [bwh: Backported to 3.2: - Adjust context and indentation - freezer_do_not_count() and freezer_count() are no-ops for kernel tasks] Signed-off-by:
-
Tejun Heo authored
commit 5edee61e upstream. cgroup core has a bug which violates a basic rule about event notifications - when a new entity needs to be added, you add that to the notification list first and then make the new entity conform to the current state. If done in the reverse order, an event happening inbetween will be lost. cgroup_subsys->fork() is invoked way before the new task is added to the css_set. Currently, cgroup_freezer is the only user of ->fork() and uses it to make new tasks conform to the current state of the freezer. If FROZEN state is requested while fork is in progress between cgroup_fork_callbacks() and cgroup_post_fork(), the child could escape freezing - the cgroup isn't frozen when ->fork() is called and the freezer couldn't see the new task on the css_set. This patch moves cgroup_subsys->fork() invocation to cgroup_post_fork() after the new task is added to the css_set. cgroup_fork_callbacks() is removed. Because now a task may be migrated during cgroup_subsys->fork(), freezer_fork() is updated so that it adheres to the usual RCU locking and the rather pointless comment on why locking can be different there is removed (if it doesn't make anything simpler, why even bother?). Signed-off-by:
-
Christian Borntraeger authored
commit 87cac8f8 upstream. Newer kernels (linux-next with the transparent huge page patches) use rrbm if the feature is announced via feature bit 66. RRBM will cause intercepts, so KVM does not handle it right now, causing an illegal instruction in the guest. The easy solution is to disable the feature bit for the guest. This fixes bugs like: Kernel BUG at 0000000000124c2a [verbose debug info unavailable] illegal operation: 0001 [#1] SMP Modules linked in: virtio_balloon virtio_net ipv6 autofs4 CPU: 0 Not tainted 3.5.4 #1 Process fmempig (pid: 659, task: 000000007b712fd0, ksp: 000000007bed3670) Krnl PSW : 0704d00180000000 0000000000124c2a (pmdp_clear_flush_young+0x5e/0x80) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3 00000000003cc000 0000000000000004 0000000000000000 0000000079800000 0000000000040000 0000000000000000 000000007bed3918 000000007cf40000 0000000000000001 000003fff7f00000 000003d281a94000 000000007bed383c 000000007bed3918 00000000005ecbf8 00000000002314a6 000000007bed36e0 Krnl Code:>0000000000124c2a: b9810025 ogr %r2,%r5 0000000000124c2e: 41343000 la %r3,0(%r4,%r3) 0000000000124c32: a716fffa brct %r1,124c26 0000000000124c36: b9010022 lngr %r2,%r2 0000000000124c3a: e3d0f0800004 lg %r13,128(%r15) 0000000000124c40: eb22003f000c srlg %r2,%r2,63 [ 2150.713198] Call Trace: [ 2150.713223] ([<00000000002312c4>] page_referenced_one+0x6c/0x27c) [ 2150.713749] [<0000000000233812>] page_referenced+0x32a/0x410 [...] CC: Alex Graf <agraf@suse.de> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
-
Shuah Khan authored
Fix wii_memory_fixups() the following compile error on 3.0.y tree with wii_defconfig on 3.0.y tree. CC arch/powerpc/platforms/embedded6xx/wii.o arch/powerpc/platforms/embedded6xx/wii.c: In function ‘wii_memory_fixups’: arch/powerpc/platforms/embedded6xx/wii.c:88:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘phys_addr_t’ [-Werror=format] arch/powerpc/platforms/embedded6xx/wii.c:88:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘phys_addr_t’ [-Werror=format] arch/powerpc/platforms/embedded6xx/wii.c:90:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘phys_addr_t’ [-Werror=format] arch/powerpc/platforms/embedded6xx/wii.c:90:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘phys_addr_t’ [-Werror=format] cc1: all warnings being treated as errors make[2]: *** [arch/powerpc/platforms/embedded6xx/wii.o] Error 1 make[1]: *** [arch/powerpc/platforms/embedded6xx] Error 2 make: *** [arch/powerpc/platforms] Error 2 Signed-off-by:
Shuah Khan <shuah.khan@hp.com> Signed-off-by:
-
Mel Gorman authored
commit 18a2f371 upstream. This fixes a regression in 3.7-rc, which has since gone into stable. Commit 00442ad0 ("mempolicy: fix a memory corruption by refcount imbalance in alloc_pages_vma()") changed get_vma_policy() to raise the refcount on a shmem shared mempolicy; whereas shmem_alloc_page() went on expecting alloc_page_vma() to drop the refcount it had acquired. This deserves a rework: but for now fix the leak in shmem_alloc_page(). Hugh: shmem_swapin() did not need a fix, but surely it's clearer to use the same refcounting there as in shmem_alloc_page(), delete its onstack mempolicy, and the strange mpol_cond_copy() and __mpol_cond_copy() - those were invented to let swapin_readahead() make an unknown number of calls to alloc_pages_vma() with one mempolicy; but since 00442ad0, alloc_pages_vma() has kept refcount in balance, so now no problem. Reported-and-tested-by:
Tommi Rantala <tt.rantala@gmail.com> Signed-off-by:
Mel Gorman <mgorman@suse.de> Signed-off-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Chris Ball authored
commit 6984f3c3 upstream. This reverts commit 8464dd52, which was a misapplied debugging version of the patch, not the final patch itself. Signed-off-by:
Chris Ball <cjb@laptop.org> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Mike Galbraith authored
commit fd8ef117 upstream. This reverts commit 800d4d30. Between commits 8323f26c ("sched: Fix race in task_group()") and 800d4d30 ("sched, autogroup: Stop going ahead if autogroup is disabled"), autogroup is a wreck. With both applied, all you have to do to crash a box is disable autogroup during boot up, then reboot.. boom, NULL pointer dereference due to commit 800d4d30 not allowing autogroup to move things, and commit 8323f26c making that the only way to switch runqueues: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff81063ac0>] effective_load.isra.43+0x50/0x90 Pid: 7047, comm: systemd-user-se Not tainted 3.6.8-smp #7 MEDIONPC MS-7502/MS-7502 RIP: effective_load.isra.43+0x50/0x90 Process systemd-user-se (pid: 7047, threadinfo ffff880221dde000, task ffff88022618b3a0) Call Trace: select_task_rq_fair+0x255/0x780 try_to_wake_up+0x156/0x2c0 wake_up_state+0xb/0x10 signal_wake_up+0x28/0x40 complete_signal+0x1d6/0x250 __send_signal+0x170/0x310 send_signal+0x40/0x80 do_send_sig_info+0x47/0x90 group_send_sig_info+0x4a/0x70 kill_pid_info+0x3a/0x60 sys_kill+0x97/0x1a0 ? vfs_read+0x120/0x160 ? sys_read+0x45/0x90 system_call_fastpath+0x16/0x1b Code: 49 0f af 41 50 31 d2 49 f7 f0 48 83 f8 01 48 0f 46 c6 48 2b 07 48 8b bf 40 01 00 00 48 85 ff 74 3a 45 31 c0 48 8b 8f 50 01 00 00 <48> 8b 11 4c 8b 89 80 00 00 00 49 89 d2 48 01 d0 45 8b 59 58 4c RIP [<ffffffff81063ac0>] effective_load.isra.43+0x50/0x90 RSP <ffff880221ddfbd8> CR2: 0000000000000000 Signed-off-by:
Mike Galbraith <efault@gmx.de> Acked-by:
Ingo Molnar <mingo@kernel.org> Cc: Yong Zhang <yong.zhang0@gmail.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Jean Delvare authored
commit 7e06b7a3 upstream. * Right-shift the values in GET_FBD_FAT_IDX and GET_FBD_NF_IDX, so that the callers get the result they expect. * Fix definition of FERR_FAT_FBD_ERR_MASK. * Call GET_FBD_NF_IDX, not GET_FBD_FAT_IDX, when operating on register FERR_NF_FBD. We were lucky they have the same definition. This fixes kernel bug #44131: https://bugzilla.kernel.org/show_bug.cgi?id=44131Signed-off-by:
Jean Delvare <jdelvare@suse.de> Cc: Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Doug Thompson <dougthompson@xmission.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
Dmitry Rogozhkin authored
commit e79e0fe3 upstream. Subsequent threads returning EBUSY from vm_insert_pfn() was not handled correctly. As a result concurrent access from new threads to mmapped data caused SIGBUS. Note that this fixes i-g-t/tests/gem_threaded_tiled_access. Tested-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Eugeni Dodonov authored
commit cc22a938 upstream. This adds PCI ID for IVB GT2 server variant which we were missing. Signed-off-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> [danvet: fix up conflict because the patch has been diffed against next. tsk.] Signed-Off-by:
-
Duncan Roe authored
commit 7110005e upstream. Signed-off-by:
Duncan Roe <duncan_roe@acslink.net.au> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Krzysztof Wilczynski authored
commit b631cf1f upstream. This is to change use of "0x%08x" in favour of "%p" as per ../Documentation/printk-formats.txt, which also takes care about the following warning during compilation time: drivers/scsi/aha152x.c: In function ‘get_command’: drivers/scsi/aha152x.c:2987: warning: cast from pointer to integer of different size Signed-off-by:
Krzysztof Wilczynski <krzysztof.wilczynski@linux.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Dan Carpenter authored
commit 5bc9ad77 upstream. Gcc 4.6.2 complains that: drivers/leds/leds-lp5521.c: In function `lp5521_load_program': drivers/leds/leds-lp5521.c:214:21: warning: `mode' may be used uninitialized in this function [-Wuninitialized] drivers/leds/leds-lp5521.c: In function `lp5521_probe': drivers/leds/leds-lp5521.c:788:5: warning: `buf' may be used uninitialized in this function [-Wuninitialized] drivers/leds/leds-lp5521.c:740:6: warning: `ret' may be used uninitialized in this function [-Wuninitialized] These are real problems if lp5521_read() returns an error. When that happens we should handle it, instead of ignoring it or doing a bitwise OR with all the other error codes and continuing. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Milo <Milo.Kim@ti.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Bryan Wu <bryan.wu@canonical.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Srinidhi KASAGAR authored
commit 42960b76 upstream. Fix it by assigning the lp5521_read return value. Signed-off-by:
srinidhi kasagar <srinidhi.kasagar@stericsson.com> Cc: Milo(Woogyom) Kim <milo.kim@ti.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Arun MURTHY <arun.murthy@stericsson.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
