- 20 Mar, 2013 16 commits
-
-
Jiri Slaby authored
commit b81273a1 upstream. Now that login from util-linux is forced to drop all references to a TTY which it wants to hangup (to reach reference count 1) we are seeing issues with telnet. When login closes its last reference to the slave PTY, it also resets packet mode on the *master* side. And we have a race here. What telnet does is fork+exec of `login'. Then there are two scenarios: * `login' closes the slave TTY and resets thus master's packet mode, but even now telnet properly sets the mode, or * `telnetd' sets packet mode on the master, `login' closes the slave TTY and resets master's packet mode. The former case is OK. However the latter happens in much more cases, by the order of magnitude to be precise. So when one tries to login to such a messed telnet setup, they see the following: inux login: ogin incorrect Note the missing first letters -- telnet thinks it is still in the packet mode, so when it receives "linux login" from `login', it considers "l" as the type of the packet and strips it. SuS does not mention how the implementation should behave. Both BSDs I checked (Free and Net) do not reset the flag upon the last close. By this I am resurrecting an old bug, see References. We are hitting it regularly now, i.e. with updated util-linux, ergo login. Here, I am changing a behavior introduced back in 2.1 times. It would better have a long time testing before goes upstream. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Bryan Mason <bmason@redhat.com> References: https://lkml.org/lkml/2009/11/11/223 References: https://bugzilla.redhat.com/show_bug.cgi?id=504703 References: https://bugzilla.novell.com/show_bug.cgi?id=797042Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Paul Bolle authored
commit 827aa0d3 upstream. This could have been either ARCH_S5P64X0 or CPU_S5P6450. Looking at commit 2555e663 ("ARM: S5P64X0: Add UART serial support for S5P6450") - which added this typo - makes clear this should be CPU_S5P6450. Signed-off-by:
Paul Bolle <pebolle@tiscali.nl> Acked-by:
Kukjin Kim <kgene.kim@samsung.com> Signed-off-by:
-
Wang YanQing authored
commit 8d2f8cd4 upstream. 01:08.0 Communication controller: NetMos Technology PCI 9835 Multi-I/O Controller (rev 01) Subsystem: Device [1000:0012] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 20 Region 0: I/O ports at e050 [size=8] Region 1: I/O ports at e040 [size=8] Region 2: I/O ports at e030 [size=8] Region 3: I/O ports at e020 [size=8] Region 4: I/O ports at e010 [size=8] Region 5: I/O ports at e000 [size=16] Signed-off-by:
Wang YanQing <udknight@gmail.com> Signed-off-by:
-
Lars-Peter Clausen authored
commit 8d0c2d10 upstream. ext3_msg() takes the printk prefix as the second parameter and the format string as the third parameter. Two callers of ext3_msg omit the prefix and pass the format string as the second parameter and the first parameter to the format string as the third parameter. In both cases this string comes from an arbitrary source. Which means the string may contain format string characters, which will lead to undefined and potentially harmful behavior. The issue was introduced in commit 4cf46b67("ext3: Unify log messages in ext3") and is fixed by this patch. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Kees Cook authored
commit 2ca39528 upstream. When the new signal handlers are set up, the location of sa_restorer is not cleared, leaking a parent process's address space location to children. This allows for a potential bypass of the parent's ASLR by examining the sa_restorer value returned when calling sigaction(). Based on what should be considered "secret" about addresses, it only matters across the exec not the fork (since the VMAs haven't changed until the exec). But since exec sets SIG_DFL and keeps sa_restorer, this is where it should be fixed. Given the few uses of sa_restorer, a "set" function was not written since this would be the only use. Instead, we use __ARCH_HAS_SA_RESTORER, as already done in other places. Example of the leak before applying this patch: $ cat /proc/$$/maps ... 7fb9f3083000-7fb9f3238000 r-xp 00000000 fd:01 404469 .../libc-2.15.so ... $ ./leak ... 7f278bc74000-7f278be29000 r-xp 00000000 fd:01 404469 .../libc-2.15.so ... 1 0 (nil) 0x7fb9f30b94a0 2 4000000 (nil) 0x7f278bcaa4a0 3 4000000 (nil) 0x7f278bcaa4a0 4 0 (nil) 0x7fb9f30b94a0 ... [akpm@linux-foundation.org: use SA_RESTORER for backportability] Signed-off-by:
Kees Cook <keescook@chromium.org> Reported-by:
Emese Revfy <re.emese@gmail.com> Cc: Emese Revfy <re.emese@gmail.com> Cc: PaX Team <pageexec@freemail.hu> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Oleg Nesterov <oleg@redhat.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Serge Hallyn <serge.hallyn@canonical.com> Cc: Julien Tinnes <jln@google.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Malcolm Priestley authored
commit 6987a6da upstream. Remove usb_put_dev from vt6656_suspend and usb_get_dev from vt6566_resume. These are not normally in suspend/resume functions. Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by:
-
Alan Stern authored
commit feca7746 upstream. This patch (as1661) fixes a rather obscure bug in ehci-hcd. In a couple of places, the driver compares the DMA address stored in a QH's overlay region with the address of a particular qTD, in order to see whether that qTD is the one currently being processed by the hardware. (If it is then the status in the QH's overlay region is more up-to-date than the status in the qTD, and if it isn't then the overlay's value needs to be adjusted when the QH is added back to the active schedule.) However, DMA address in the overlay region isn't always valid. It sometimes will contain a stale value, which may happen by coincidence to be equal to a qTD's DMA address. Instead of checking the DMA address, we should check whether the overlay region is active and valid. The patch tests the ACTIVE bit in the overlay, and clears this bit when the overlay becomes invalid (which happens when the currently-executing URB is unlinked). This is the second part of a fix for the regression reported at: https://bugs.launchpad.net/bugs/1088733Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Reported-and-tested-by:
Stephen Thirlwall <sdt@dr.com> Signed-off-by:
-
Bjørn Mork authored
commit ab4b7164 upstream. This reverts commit 200e0d99 ("USB: storage: optimize to match the Huawei USB storage devices and support new switch command" and the followup bugfix commit cd060956 ("USB: storage: properly handle the endian issues of idProduct"). The commit effectively added a large number of Huawei devices to the deprecated usb-storage mode switching logic. Many of these devices have been in use and supported by the userspace usb_modeswitch utility for years. Forcing the switching inside the kernel causes a number of regressions as a result of ignoring existing onfigurations, and also completely takes away the ability to configure mode switching per device/system/user. Known regressions caused by this: - Some of the devices support multiple modes, using different switching commands. There are existing configurations taking advantage of this. - There is a real use case for disabling mode switching and instead mounting the exposed storage device. This becomes impossible with switching logic inside the usb-storage driver. - At least on device fail as a result of the usb-storage switching command, becoming completely unswitchable. This is possibly a firmware bug, but still a regression because the device work as expected using usb_modeswitch defaults. In-kernel mode switching was deprecated years ago with the development of the more user friendly userspace alternatives. The existing list of devices in usb-storage was only kept to prevent breaking already working systems. The long term plan is to remove the list, not to add to it. Ref: http://permalink.gmane.org/gmane.linux.usb.general/28543Signed-off-by:
Bjørn Mork <bjorn@mork.no> Cc: <fangxiaozhi@huawei.com> Signed-off-by:
-
Steve Conklin authored
commit a57e82a1 upstream. The Rigblaster Advantage is an amateur radio interface sold by West Mountain Radio. It contains a cp210x serial interface but the device ID is not in the driver. Signed-off-by:
Steve Conklin <sconklin@canonical.com> Signed-off-by:
-
Christian Schmiedl authored
commit 1941138e upstream. add support for Cinterion's products AH6 and PLS8 by adding Product IDs and USB_DEVICE tuples. Signed-off-by:
Christian Schmiedl <christian.schmiedl@gemalto.com> Signed-off-by:
-
Matwey V. Kornilov authored
commit be3101c2 upstream. This patch adds support for the Lake Shore Cryotronics devices to the CP210x driver. These lines are ported from cp210x driver distributed by Lake Shore web site: http://www.lakeshore.com/Documents/Lake%20Shore%20cp210x-3.0.0.tar.gz and licensed under the terms of GPLv2. Moreover, I've tested this changes with Lake Shore 335 in my labs. Signed-off-by:
Matwey V. Kornilov <matwey@sai.msu.ru> Signed-off-by:
-
Oliver Neukum authored
commit c0f5ecee upstream. The buffer for responses must not overflow. If this would happen, set a flag, drop the data and return an error after user space has read all remaining data. Signed-off-by:
Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
Bjørn Mork authored
commit daec90e7 upstream. Another device using CDC ACM with vendor specific protocol to mark serial functions. Signed-off-by:
-
Amit Shah authored
commit e84e7a56 upstream. The code currently only supports one virtio-rng device at a time. Invoking guests with multiple devices causes the guest to blow up. Check if we've already registered and initialised the driver. Also cleanup in case of registration errors or hot-unplug so that a new device can be used. Reported-by:
Peter Krempa <pkrempa@redhat.com> Reported-by: <yunzheng@redhat.com> Signed-off-by:
Amit Shah <amit.shah@redhat.com> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Konrad Rzeszutek Wilk authored
commit bdc5c181 upstream. While shuting down a HVM guest with pci devices passed through we get this: pciback 0000:04:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100002) ------------[ cut here ]------------ WARNING: at drivers/pci/pci.c:1397 pci_disable_device+0x88/0xa0() Hardware name: MS-7640 Device pciback disabling already-disabled device Modules linked in: Pid: 53, comm: xenwatch Not tainted 3.9.0-rc1-20130304a+ #1 Call Trace: [<ffffffff8106994a>] warn_slowpath_common+0x7a/0xc0 [<ffffffff81069a31>] warn_slowpath_fmt+0x41/0x50 [<ffffffff813cf288>] pci_disable_device+0x88/0xa0 [<ffffffff814554a7>] xen_pcibk_reset_device+0x37/0xd0 [<ffffffff81454b6f>] ? pcistub_put_pci_dev+0x6f/0x120 [<ffffffff81454b8d>] pcistub_put_pci_dev+0x8d/0x120 [<ffffffff814582a9>] __xen_pcibk_release_devices+0x59/0xa0 This fixes the bug. Reported-and-Tested-by:
Sander Eikelenboom <linux@eikelenboom.it> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Dan Williams authored
commit 2d90e636 upstream. 4 ports; AT/PPP is standard CDC-ACM. The other three (added by this patch) are QCDM/DIAG, possibly GPS, and unknown. Signed-off-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
- 14 Mar, 2013 24 commits
-
-
Greg Kroah-Hartman authored
-
Sarah Sharp authored
[This is upstream commit d3b9d7a9. It needs to be backported to kernels as old as 3.2, because it fixes the buggy commit 9dbcaec8 "USB: Handle warm reset failure on empty port."] A USB 3.0 device can transition to the Inactive state if a U1 or U2 exit transition fails. The current code in hub_events simply issues a warm reset, but does not call any pre-reset or post-reset driver methods (or unbind/rebind drivers without them). Therefore the drivers won't know their device has just been reset. hub_events should instead call usb_reset_device. This means hub_port_reset now needs to figure out whether it should issue a warm reset or a hot reset. Remove the FIXME note about needing disconnect() for a NOTATTACHED device. This patch fixes that. Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by:
-
Greg Kroah-Hartman authored
This reverts commit 30efd8de upstream (dd54ec40 in this tree) as it is not needed for the 3.4-stable tree. Cc: David Henningsson <david.henningsson@canonical.com> Cc: Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Sarah Sharp authored
[This is upstream commit 24a6078754f28528bc91e7e7b3e6ae86bd936d8. It needs to be backported to kernels as old as 3.2, because it fixes the buggy commit 9dbcaec8 "USB: Handle warm reset failure on empty port."] When a hot reset fails on a USB 3.0 port, the current port reset code recursively calls hub_port_reset inside hub_port_wait_reset. This isn't ideal, since we should avoid recursive calls in the kernel, and it also doesn't allow us to issue multiple warm resets on reset failures. Rip out the recursive call. Instead, add code to hub_port_reset to issue a warm reset if the hot reset fails, and try multiple warm resets before giving up on the port. In hub_port_wait_reset, remove the recursive call and re-indent. The code is basically the same, except: 1. It bails out early if the port has transitioned to Inactive or Compliance Mode after the reset completed. 2. It doesn't consider a connect status change to be a failed reset. If multiple warm resets needed to be issued, the connect status may have changed, so we need to ignore that and look at the port link state instead. hub_port_reset will now do that. 3. It unconditionally sets udev->speed on all types of successful resets. The old recursive code would set the port speed when the second hub_port_reset returned. The old code did not handle connected devices needing a warm reset well. There were only two situations that the old code handled correctly: an empty port needing a warm reset, and a hot reset that migrated to a warm reset. When an empty port needed a warm reset, hub_port_reset was called with the warm variable set. The code in hub_port_finish_reset would skip telling the USB core and the xHC host that the device was reset, because otherwise that would result in a NULL pointer dereference. When a USB 3.0 device reset migrated to a warm reset, the recursive call made the call stack look like this: hub_port_reset(warm = false) hub_wait_port_reset(warm = false) hub_port_reset(warm = true) hub_wait_port_reset(warm = true) hub_port_finish_reset(warm = true) (return up the call stack to the first wait) hub_port_finish_reset(warm = false) The old code didn't want to notify the USB core or the xHC host of device reset twice, so it only did it in the second call to hub_port_finish_reset, when warm was set to false. This was necessary because before patch two ("USB: Ignore xHCI Reset Device status."), the USB core would pay attention to the xHC Reset Device command error status, and the second call would always fail. Now that we no longer have the recursive call, and warm can change from false to true in hub_port_reset, we need to have hub_port_finish_reset unconditionally notify the USB core and the xHC of the device reset. In hub_port_finish_reset, unconditionally clear the connect status change (CSC) bit for USB 3.0 hubs when the port reset is done. If we had to issue multiple warm resets for a device, that bit may have been set if the device went into SS.Inactive and then was successfully warm reset. Signed-off-by:
-
Sarah Sharp authored
[This is upstream commit 2d4fa940. It needs to be backported to kernels as old as 3.2, because it fixes the buggy commit 9dbcaec8 "USB: Handle warm reset failure on empty port."] The next patch will refactor the hub port code to rip out the recursive call to hub_port_reset on a failed hot reset. In preparation for that, make sure all code paths can deal with being called with a NULL udev. The usb_device will not be valid if warm reset was issued because a port transitioned to the Inactive or Compliance Mode on a device connect. This patch should have no effect on current behavior. Signed-off-by:
-
Sarah Sharp authored
[This is upstream commit 0fe51aa5. It needs to be backported to kernels as old as 3.2, because it fixes the buggy commit 9dbcaec8 "USB: Handle warm reset failure on empty port."] The EHCI host controller needs to prevent EHCI initialization when the UHCI or OHCI companion controller is in the middle of a port reset. It uses ehci_cf_port_reset_rwsem to do this. USB 3.0 hubs can't be under an EHCI host controller, so it makes no sense to down the semaphore for USB 3.0 hubs. It also makes the warm port reset code more complex. Don't down ehci_cf_port_reset_rwsem for USB 3.0 hubs. Signed-off-by:
-
Ben Hutchings authored
commit a40e7cf8 upstream. Commit 9f9c9cbb ("drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists") hoisted the check for "_DMI_" into dmi_scan_machine(), which means that we don't bother to check for "_DMI_" at offset 16 in an SMBIOS entry. smbios_present() may also call dmi_present() for an address where we found "_SM_", if it failed further validation. Check for "_DMI_" in smbios_present() before calling dmi_present(). [akpm@linux-foundation.org: fix build] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Reported-by:
Tim McGrath <tmhikaru@gmail.com> Tested-by:
-
Steven Rostedt authored
commit db05021d upstream. The prompt to enable DYNAMIC_FTRACE (the ability to nop and enable function tracing at run time) had a confusing statement: "enable/disable ftrace tracepoints dynamically" This was written before tracepoints were added to the kernel, but now that tracepoints have been added, this is very confusing and has confused people enough to give wrong information during presentations. Not only that, I looked at the help text, and it still references that dreaded daemon that use to wake up once a second to update the nop locations and brick NICs, that hasn't been around for over five years. Time to bring the text up to the current decade. Reported-by:
Ezequiel Garcia <elezegarcia@gmail.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Tu, Xiaobing authored
commit e3773677 upstream. When system enters sleep, non-boot CPUs will be disabled. Cpufreq stats sysfs is created when the CPU is up, but it is not freed when the CPU is going down. This will cause memory leak. Signed-off-by:
xiaobing tu <xiaobing.tu@intel.com> Signed-off-by:
guifang tang <guifang.tang@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Colin Cross <ccross@google.com> Signed-off-by:
-
Al Viro authored
commit a930d879 upstream. If you open a pipe for neither read nor write, the pipe code will not add any usage counters to the pipe, causing the 'struct pipe_inode_info" to be potentially released early. That doesn't normally matter, since you cannot actually use the pipe, but the pipe release code - particularly fasync handling - still expects the actual pipe infrastructure to all be there. And rather than adding NULL pointer checks, let's just disallow this case, the same way we already do for the named pipe ("fifo") case. This is ancient going back to pre-2.4 days, and until trinity, nobody naver noticed. Reported-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Mathieu Desnoyers authored
commit 8aec0f5d upstream. Looking at mm/process_vm_access.c:process_vm_rw() and comparing it to compat_process_vm_rw() shows that the compatibility code requires an explicit "access_ok()" check before calling compat_rw_copy_check_uvector(). The same difference seems to appear when we compare fs/read_write.c:do_readv_writev() to fs/compat.c:compat_do_readv_writev(). This subtle difference between the compat and non-compat requirements should probably be debated, as it seems to be error-prone. In fact, there are two others sites that use this function in the Linux kernel, and they both seem to get it wrong: Now shifting our attention to fs/aio.c, we see that aio_setup_iocb() also ends up calling compat_rw_copy_check_uvector() through aio_setup_vectored_rw(). Unfortunately, the access_ok() check appears to be missing. Same situation for security/keys/compat.c:compat_keyctl_instantiate_key_iov(). I propose that we add the access_ok() check directly into compat_rw_copy_check_uvector(), so callers don't have to worry about it, and it therefore makes the compat call code similar to its non-compat counterpart. Place the access_ok() check in the same location where copy_from_user() can trigger a -EFAULT error in the non-compat code, so the ABI behaviors are alike on both compat and non-compat. While we are here, fix compat_do_readv_writev() so it checks for compat_rw_copy_check_uvector() negative return values. And also, fix a memory leak in compat_keyctl_instantiate_key_iov() error handling. Acked-by:
Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by:
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by:
-
David Howells authored
commit 0da9dfdd upstream. This fixes CVE-2013-1792. There is a race in install_user_keyrings() that can cause a NULL pointer dereference when called concurrently for the same user if the uid and uid-session keyrings are not yet created. It might be possible for an unprivileged user to trigger this by calling keyctl() from userspace in parallel immediately after logging in. Assume that we have two threads both executing lookup_user_key(), both looking for KEY_SPEC_USER_SESSION_KEYRING. THREAD A THREAD B =============================== =============================== ==>call install_user_keyrings(); if (!cred->user->session_keyring) ==>call install_user_keyrings() ... user->uid_keyring = uid_keyring; if (user->uid_keyring) return 0; <== key = cred->user->session_keyring [== NULL] user->session_keyring = session_keyring; atomic_inc(&key->usage); [oops] At the point thread A dereferences cred->user->session_keyring, thread B hasn't updated user->session_keyring yet, but thread A assumes it is populated because install_user_keyrings() returned ok. The race window is really small but can be exploited if, for example, thread B is interrupted or preempted after initializing uid_keyring, but before doing setting session_keyring. This couldn't be reproduced on a stock kernel. However, after placing systemtap probe on 'user->session_keyring = session_keyring;' that introduced some delay, the kernel could be crashed reliably. Fix this by checking both pointers before deciding whether to return. Alternatively, the test could be done away with entirely as it is checked inside the mutex - but since the mutex is global, that may not be the best way. Signed-off-by:
David Howells <dhowells@redhat.com> Reported-by:
Mateusz Guzik <mguzik@redhat.com> Signed-off-by:
James Morris <james.l.morris@oracle.com> Signed-off-by:
-
Mathias Krause authored
commit 9a5467bf upstream. Three errors resulting in kernel memory disclosure: 1/ The structures used for the netlink based crypto algorithm report API are located on the stack. As snprintf() does not fill the remainder of the buffer with null bytes, those stack bytes will be disclosed to users of the API. Switch to strncpy() to fix this. 2/ crypto_report_one() does not initialize all field of struct crypto_user_alg. Fix this to fix the heap info leak. 3/ For the module name we should copy only as many bytes as module_name() returns -- not as much as the destination buffer could hold. But the current code does not and therefore copies random data from behind the end of the module name, as the module name is always shorter than CRYPTO_MAX_ALG_NAME. Also switch to use strncpy() to copy the algorithm's name and driver_name. They are strings, after all. Signed-off-by:
Mathias Krause <minipli@googlemail.com> Cc: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Konrad Rzeszutek Wilk authored
commit c79c4982 upstream. The git commit 8eaffa67 (xen/pat: Disable PAT support for now) explains in details why we want to disable PAT for right now. However that change was not enough and we should have also disabled the pat_enabled value. Otherwise we end up with: mmap-example:3481 map pfn expected mapping type write-back for [mem 0x00010000-0x00010fff], got uncached-minus ------------[ cut here ]------------ WARNING: at /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774 untrack_pfn+0xb8/0xd0() mem 0x00010000-0x00010fff], got uncached-minus ------------[ cut here ]------------ WARNING: at /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774 untrack_pfn+0xb8/0xd0() ... Pid: 3481, comm: mmap-example Tainted: GF 3.8.0-6-generic #13-Ubuntu Call Trace: [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc0 [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20 [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0 [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100 [<ffffffff81157459>] unmap_vmas+0x49/0x90 [<ffffffff8115f808>] exit_mmap+0x98/0x170 [<ffffffff810559a4>] mmput+0x64/0x100 [<ffffffff810560f5>] dup_mm+0x445/0x660 [<ffffffff81056d9f>] copy_process.part.22+0xa5f/0x1510 [<ffffffff81057931>] do_fork+0x91/0x350 [<ffffffff81057c76>] sys_clone+0x16/0x20 [<ffffffff816ccbf9>] stub_clone+0x69/0x90 [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f ---[ end trace 4918cdd0a4c9fea4 ]--- (a similar message shows up if you end up launching 'mcelog') The call chain is (as analyzed by Liu, Jinsong): do_fork --> copy_process --> dup_mm --> dup_mmap --> copy_page_range --> track_pfn_copy --> reserve_pfn_range --> line 624: flags != want_flags It comes from different memory types of page table (_PAGE_CACHE_WB) and MTRR (_PAGE_CACHE_UC_MINUS). Stefan Bader dug in this deep and found out that: "That makes it clearer as this will do reserve_memtype(...) --> pat_x_mtrr_type --> mtrr_type_lookup --> __mtrr_type_lookup And that can return -1/0xff in case of MTRR not being enabled/initialized. Which is not the case (given there are no messages for it in dmesg). This is not equal to MTRR_TYPE_WRBACK and thus becomes _PAGE_CACHE_UC_MINUS. It looks like the problem starts early in reserve_memtype: if (!pat_enabled) { /* This is identical to page table setting without PAT */ if (new_type) { if (req_type == _PAGE_CACHE_WC) *new_type = _PAGE_CACHE_UC_MINUS; else *new_type = req_type & _PAGE_CACHE_MASK; } return 0; } This would be what we want, that is clearing the PWT and PCD flags from the supported flags - if pat_enabled is disabled." This patch does that - disabling PAT. Reported-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
-
Benjamin Tissoires authored
commit dcd9006b upstream. hid_output_raw_report() makes a direct call to usb_control_msg(). However, some USB3 boards have shown that the usb device is not ready during the .probe(). This blocks the entire usb device, and the paired mice, keyboards are not functional. The dmesg output is the following: [ 11.912287] logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-2/input2 [ 11.912537] logitech-djreceiver 0003:046D:C52B.0003: logi_dj_probe:logi_dj_recv_query_paired_devices error:-32 [ 11.912636] logitech-djreceiver: probe of 0003:046D:C52B.0003 failed with error -32 Relying on the scheduled call to usbhid_submit_report() fixes the problem. related bugs: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1072082 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1039143 https://bugzilla.redhat.com/show_bug.cgi?id=840391 https://bugzilla.kernel.org/show_bug.cgi?id=49781Reported-and-tested-by:
Bob Bowles <bobjohnbowles@gmail.com> Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Konstantin Khlebnikov authored
commit 4e0855df upstream. This patch removes redundant and unbalanced pci_disable_device() from __e1000_shutdown(). pci_clear_master() is enough, device can go into suspended state with elevated enable_cnt. Bug was introduced in commit 23606cf5 ("e1000e / PCI / PM: Add basic runtime PM support (rev. 4)") in v2.6.35 Signed-off-by:
Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: Bruce Allan <bruce.w.allan@intel.com> Acked-by:
Borislav Petkov <bp@suse.de> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Takashi Iwai authored
commit 2069d483 upstream. When a value of a vmaster slave control is changed, the ctl change notification is sometimes ignored. This happens when the master control overrides, e.g. when the corresponding master control is muted. The reason is that slave_put() returns the value of the actual slave put callback, and it doesn't reflect the virtual slave value change. This patch fixes the function just to return 1 whenever a slave value is changed. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Sean Connor authored
commit 69a4cfdd upstream. Set card->private_data in snd_ice1712_create for fixing NULL dereference in snd_ice1712_remove(). Signed-off-by:
Sean Connor <sconnor004@allyinics.org> Signed-off-by:
-
Will Deacon authored
commit f2fe09b0 upstream. Masked out PMXEVTYPER.NSH means that we can't enable profiling at PL2, regardless of the settings in the HDCR. This patch fixes the broken mask. Reported-by:
Christoffer Dall <cdall@cs.columbia.edu> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Alex Deucher authored
commit e8fc4137 upstream. vbios values are wrong leading to colors that are too bright. Use the default values instead. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Guenter Roeck authored
commit f366fccd upstream. We read the chip ID from the chip, use it to determine if the chip ID provided to the driver is correct, and report it if wrong. We should also use the correct chip ID to select supported functionality. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Acked-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Guenter Roeck authored
commit dbd712c2 upstream. Peak attributes were not initialized and cleared correctly. Also, temp2_max is only supported on page 0 and thus does not need to be an array. Signed-off-by:
-
Mark Brown authored
commit 3e78080f upstream. Not having power is a pretty serious error so check that we are able to enable the supply and error out if we can't. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
NeilBrown authored
commit 58ebb34c upstream. Create_stripe_zones returns an error slightly differently to raid0_run and to raid0_takeover_*. The error returned used by the second was wrong and an error would result in mddev->private being set to NULL and sooner or later a crash. So never return NULL, return ERR_PTR(err), not NULL from create_stripe_zones. This bug has been present since 2.6.35 so the fix is suitable for any kernel since then. Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
