linux-stable.git, branch v3.18.44 Linux kernel stable tree Linux 3.18.44 2016-10-22T20:45:02+00:00 Sasha Levin alexander.levin@verizon.com 2016-10-22T20:45:02+00:00 a6846cfd266b48af1ee7c3c19d5cb60477ca4469 Signed-off-by: Sasha Levin <alexander.levin@verizon.com> 
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
xhci: fix usb2 resume timing and races. 2016-10-22T20:43:20+00:00 Mathias Nyman mathias.nyman@linux.intel.com 2015-12-11T12:38:06+00:00 c003797af3bc3b267a262b4d28ca06efc80390d4 [ Upstream commit f69115fdbc1ac0718e7d19ad3caa3da2ecfe1c96 ] According to USB 2 specs ports need to signal resume for at least 20ms, in practice even longer, before moving to U0 state. Both host and devices can initiate resume. On device initiated resume, a port status interrupt with the port in resume state in issued. The interrupt handler tags a resume_done[port] timestamp with current time + USB_RESUME_TIMEOUT, and kick roothub timer. Root hub timer requests for port status, finds the port in resume state, checks if resume_done[port] timestamp passed, and set port to U0 state. On host initiated resume, current code sets the port to resume state, sleep 20ms, and finally sets the port to U0 state. This should also be changed to work in a similar way as the device initiated resume, with timestamp tagging, but that is not yet tested and will be a separate fix later. There are a few issues with this approach 1. A host initiated resume will also generate a resume event. The event handler will find the port in resume state, believe it's a device initiated resume, and act accordingly. 2. A port status request might cut the resume signalling short if a get_port_status request is handled during the host resume signalling. The port will be found in resume state. The timestamp is not set leading to time_after_eq(jiffies, timestamp) returning true, as timestamp = 0. get_port_status will proceed with moving the port to U0. 3. If an error, or anything else happens to the port during device initiated resume signalling it will leave all the device resume parameters hanging uncleared, preventing further suspend, returning -EBUSY, and cause the pm thread to busyloop trying to enter suspend. Fix this by using the existing resuming_ports bitfield to indicate that resume signalling timing is taken care of. Check if the resume_done[port] is set before using it for timestamp comparison, and also clear out any resume signalling related variables if port is not in U0 or Resume state This issue was discovered when a PM thread busylooped, trying to runtime suspend the xhci USB 2 roothub on a Dell XPS Cc: stable <stable@vger.kernel.org> Reported-by: Daniel J Blueman <daniel@quora.org> Tested-by: Daniel J Blueman <daniel@quora.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> 
[ Upstream commit f69115fdbc1ac0718e7d19ad3caa3da2ecfe1c96 ]

According to USB 2 specs ports need to signal resume for at least 20ms,
in practice even longer, before moving to U0 state.
Both host and devices can initiate resume.

On device initiated resume, a port status interrupt with the port in resume
state in issued. The interrupt handler tags a resume_done[port]
timestamp with current time + USB_RESUME_TIMEOUT, and kick roothub timer.
Root hub timer requests for port status, finds the port in resume state,
checks if resume_done[port] timestamp passed, and set port to U0 state.

On host initiated resume, current code sets the port to resume state,
sleep 20ms, and finally sets the port to U0 state. This should also
be changed to work in a similar way as the device initiated resume, with
timestamp tagging, but that is not yet tested and will be a separate
fix later.

There are a few issues with this approach

1. A host initiated resume will also generate a resume event. The event
   handler will find the port in resume state, believe it's a device
   initiated resume, and act accordingly.

2. A port status request might cut the resume signalling short if a
   get_port_status request is handled during the host resume signalling.
   The port will be found in resume state. The timestamp is not set leading
   to time_after_eq(jiffies, timestamp) returning true, as timestamp = 0.
   get_port_status will proceed with moving the port to U0.

3. If an error, or anything else happens to the port during device
   initiated resume signalling it will leave all the device resume
   parameters hanging uncleared, preventing further suspend, returning
   -EBUSY, and cause the pm thread to busyloop trying to enter suspend.

Fix this by using the existing resuming_ports bitfield to indicate that
resume signalling timing is taken care of.
Check if the resume_done[port] is set before using it for timestamp
comparison, and also clear out any resume signalling related variables
if port is not in U0 or Resume state

This issue was discovered when a PM thread busylooped, trying to runtime
suspend the xhci USB 2 roothub on a Dell XPS

Cc: stable <stable@vger.kernel.org>
Reported-by: Daniel J Blueman <daniel@quora.org>
Tested-by: Daniel J Blueman <daniel@quora.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
x86/cpu: Fix SMAP check in PVOPS environments 2016-10-22T20:38:10+00:00 Andrew Cooper andrew.cooper3@citrix.com 2015-06-03T09:31:14+00:00 bb2f5ed8935a47f78a70ac48e58e993de46430e0 [ Upstream commit 581b7f158fe0383b492acd1ce3fb4e99d4e57808 ] There appears to be no formal statement of what pv_irq_ops.save_fl() is supposed to return precisely. Native returns the full flags, while lguest and Xen only return the Interrupt Flag, and both have comments by the implementations stating that only the Interrupt Flag is looked at. This may have been true when initially implemented, but no longer is. To make matters worse, the Xen PVOP leaves the upper bits undefined, making the BUG_ON() undefined behaviour. Experimentally, this now trips for 32bit PV guests on Broadwell hardware. The BUG_ON() is consistent for an individual build, but not consistent for all builds. It has also been a sitting timebomb since SMAP support was introduced. Use native_save_fl() instead, which will obtain an accurate view of the AC flag. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: David Vrabel <david.vrabel@citrix.com> Tested-by: Rusty Russell <rusty@rustcorp.com.au> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: <lguest@lists.ozlabs.org> Cc: Xen-devel <xen-devel@lists.xen.org> CC: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1433323874-6927-1-git-send-email-andrew.cooper3@citrix.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> 
[ Upstream commit 581b7f158fe0383b492acd1ce3fb4e99d4e57808 ]

There appears to be no formal statement of what pv_irq_ops.save_fl() is
supposed to return precisely.  Native returns the full flags, while lguest and
Xen only return the Interrupt Flag, and both have comments by the
implementations stating that only the Interrupt Flag is looked at.  This may
have been true when initially implemented, but no longer is.

To make matters worse, the Xen PVOP leaves the upper bits undefined, making
the BUG_ON() undefined behaviour.  Experimentally, this now trips for 32bit PV
guests on Broadwell hardware.  The BUG_ON() is consistent for an individual
build, but not consistent for all builds.  It has also been a sitting timebomb
since SMAP support was introduced.

Use native_save_fl() instead, which will obtain an accurate view of the AC
flag.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Tested-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: <lguest@lists.ozlabs.org>
Cc: Xen-devel <xen-devel@lists.xen.org>
CC: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1433323874-6927-1-git-send-email-andrew.cooper3@citrix.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
mm: remove gup_flags FOLL_WRITE games from __get_user_pages() 2016-10-22T19:48:09+00:00 Linus Torvalds torvalds@linux-foundation.org 2016-10-13T20:07:36+00:00 e45a502bdeae5a075257c4f061d1ff4ff0821354 [ Upstream commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 ] This is an ancient bug that was actually attempted to be fixed once (badly) by me eleven years ago in commit 4ceb5db9757a ("Fix get_user_pages() race for write access") but that was then undone due to problems on s390 by commit f33ea7f404e5 ("fix get_user_pages bug"). In the meantime, the s390 situation has long been fixed, and we can now fix it by checking the pte_dirty() bit properly (and do it better). The s390 dirty bit was implemented in abf09bed3cce ("s390/mm: implement software dirty bits") which made it into v3.9. Earlier kernels will have to look at the page state itself. Also, the VM has become more scalable, and what used a purely theoretical race back then has become easier to trigger. To fix it, we introduce a new internal FOLL_COW flag to mark the "yes, we already did a COW" rather than play racy games with FOLL_WRITE that is very fundamental, and then use the pte dirty flag to validate that the FOLL_COW flag is still valid. Reported-and-tested-by: Phil "not Paul" Oester <kernel@linuxace.com> Acked-by: Hugh Dickins <hughd@google.com> Reviewed-by: Michal Hocko <mhocko@suse.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Willy Tarreau <w@1wt.eu> Cc: Nick Piggin <npiggin@gmail.com> Cc: Greg Thelen <gthelen@google.com> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> 
[ Upstream commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 ]

This is an ancient bug that was actually attempted to be fixed once
(badly) by me eleven years ago in commit 4ceb5db9757a ("Fix
get_user_pages() race for write access") but that was then undone due to
problems on s390 by commit f33ea7f404e5 ("fix get_user_pages bug").

In the meantime, the s390 situation has long been fixed, and we can now
fix it by checking the pte_dirty() bit properly (and do it better).  The
s390 dirty bit was implemented in abf09bed3cce ("s390/mm: implement
software dirty bits") which made it into v3.9.  Earlier kernels will
have to look at the page state itself.

Also, the VM has become more scalable, and what used a purely
theoretical race back then has become easier to trigger.

To fix it, we introduce a new internal FOLL_COW flag to mark the "yes,
we already did a COW" rather than play racy games with FOLL_WRITE that
is very fundamental, and then use the pte dirty flag to validate that
the FOLL_COW flag is still valid.

Reported-and-tested-by: Phil "not Paul" Oester <kernel@linuxace.com>
Acked-by: Hugh Dickins <hughd@google.com>
Reviewed-by: Michal Hocko <mhocko@suse.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Nick Piggin <npiggin@gmail.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Linux 3.18.43 2016-10-10T01:24:47+00:00 Sasha Levin alexander.levin@verizon.com 2016-10-09T14:23:45+00:00 3cab355c2ff3a781b6ebe9d1a25bd4ebc1207430 Signed-off-by: Sasha Levin <alexander.levin@verizon.com> 
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
openrisc: fix the fix of copy_from_user() 2016-10-10T01:24:30+00:00 Guenter Roeck linux@roeck-us.net 2016-09-17T19:57:24+00:00 02ce1fd73386e7420cd9b2dc87abd02a7889eaac [ Upstream commit 8e4b72054f554967827e18be1de0e8122e6efc04 ] Since commit acb2505d0119 ("openrisc: fix copy_from_user()"), copy_from_user() returns the number of bytes requested, not the number of bytes not copied. Cc: Al Viro <viro@zeniv.linux.org.uk> Fixes: acb2505d0119 ("openrisc: fix copy_from_user()") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> 
[ Upstream commit 8e4b72054f554967827e18be1de0e8122e6efc04 ]

Since commit acb2505d0119 ("openrisc: fix copy_from_user()"),
copy_from_user() returns the number of bytes requested, not the
number of bytes not copied.

Cc: Al Viro <viro@zeniv.linux.org.uk>
Fixes: acb2505d0119 ("openrisc: fix copy_from_user()")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
ARM: orion: convert the irq_reg_{readl,writel} calls to the new API 2016-10-10T01:24:19+00:00 Gregory CLEMENT gregory.clement@free-electrons.com 2014-11-25T15:19:12+00:00 fb808fa00a2c784ee1b6b5d38bf557b8a7439f58 [ Upstream commit 2f90bce7ff1f760986d55d9cb3a834e8638b1295 ] The commit "genirq: Generic chip: Change irq_reg_{readl,writel} arguments" modified the API. In the same tome the arch/arm/plat-orion/gpio.c file received a fix with the use of the old API: "ARM: orion: Fix for certain sequence of request_irq can cause irq storm". This commit fixes the use of the API. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: Olof Johansson <olof@lixom.net> Link: https://lkml.kernel.org/r/1416928752-24529-1-git-send-email-gregory.clement@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> 
[ Upstream commit 2f90bce7ff1f760986d55d9cb3a834e8638b1295 ]

The commit "genirq: Generic chip: Change irq_reg_{readl,writel}
arguments" modified the API. In the same tome the
arch/arm/plat-orion/gpio.c file received a fix with the use of the old
API: "ARM: orion: Fix for certain sequence of request_irq can cause
irq storm". This commit fixes the use of the API.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: Olof Johansson <olof@lixom.net>
Link: https://lkml.kernel.org/r/1416928752-24529-1-git-send-email-gregory.clement@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
avr32: fix 'undefined reference to `___copy_from_user' 2016-10-10T01:24:06+00:00 Guenter Roeck linux@roeck-us.net 2016-09-17T14:52:49+00:00 db9b2a3891d52770da56a5c6dca85ab007df2473 [ Upstream commit 65c0044ca8d7c7bbccae37f0ff2972f0210e9f41 ] avr32 builds fail with: arch/avr32/kernel/built-in.o: In function `arch_ptrace': (.text+0x650): undefined reference to `___copy_from_user' arch/avr32/kernel/built-in.o:(___ksymtab+___copy_from_user+0x0): undefined reference to `___copy_from_user' kernel/built-in.o: In function `proc_doulongvec_ms_jiffies_minmax': (.text+0x5dd8): undefined reference to `___copy_from_user' kernel/built-in.o: In function `proc_dointvec_minmax_sysadmin': sysctl.c:(.text+0x6174): undefined reference to `___copy_from_user' kernel/built-in.o: In function `ptrace_has_cap': ptrace.c:(.text+0x69c0): undefined reference to `___copy_from_user' kernel/built-in.o:ptrace.c:(.text+0x6b90): more undefined references to `___copy_from_user' follow Fixes: 8630c32275ba ("avr32: fix copy_from_user()") Cc: Al Viro <viro@zeniv.linux.org.uk> Acked-by: Havard Skinnemoen <hskinnemoen@gmail.com> Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> 
[ Upstream commit 65c0044ca8d7c7bbccae37f0ff2972f0210e9f41 ]

avr32 builds fail with:

arch/avr32/kernel/built-in.o: In function `arch_ptrace':
(.text+0x650): undefined reference to `___copy_from_user'
arch/avr32/kernel/built-in.o:(___ksymtab+___copy_from_user+0x0): undefined
reference to `___copy_from_user'
kernel/built-in.o: In function `proc_doulongvec_ms_jiffies_minmax':
(.text+0x5dd8): undefined reference to `___copy_from_user'
kernel/built-in.o: In function `proc_dointvec_minmax_sysadmin':
sysctl.c:(.text+0x6174): undefined reference to `___copy_from_user'
kernel/built-in.o: In function `ptrace_has_cap':
ptrace.c:(.text+0x69c0): undefined reference to `___copy_from_user'
kernel/built-in.o:ptrace.c:(.text+0x6b90): more undefined references to
`___copy_from_user' follow

Fixes: 8630c32275ba ("avr32: fix copy_from_user()")
Cc: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Havard Skinnemoen <hskinnemoen@gmail.com>
Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
hexagon: Fix build failures in linux-next 2016-10-10T01:23:56+00:00 Guenter Roeck linux@roeck-us.net 2014-12-09T22:21:45+00:00 54e7defb67e15b0b0f8f6505193922cb1af4eaba [ Upstream commit cb84c2b401d9cead5508cfed57b59b6d5feffdac ] hexagon:defconfig fails to build in linux-next since commit 332fd7c4fef5 ("genirq: Generic chip: Change irq_reg_{readl,writel} arguments"). The primary build failure is arch/hexagon/include/asm/cacheflush.h: In function 'copy_to_user_page': arch/hexagon/include/asm/cacheflush.h:89:22: error: 'VM_EXEC' undeclared This is the result of including of <linux/io.h> from <linux/irq.h>, which is now necessary due to the use of readl and writel from irq.h. This causes recursive inclusions in hexagon code; cacheflush.h is included from mm.h prior to the definition of VM_EXEC. Fix the problem by moving copy_to_user_page from the hexagon include file to arch/hexagon/mm/cache.c, similar to other architectures. After this change, several redefinitions of readl and writel are reported. Those are caused by recursive inclusions of io.h and asm/cacheflush.h. Fix those problems by reducing the number of files included from those files. Also, it was necessary to stop including asm-generic/cacheflush.h from asm/cacheflush.h. Instead, functionality originally provided by asm-generic/cacheflush.h is now coded in asm/cacheflush.h directly. Cc: Kevin Cernekee <cernekee@gmail.com> Cc: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Guenter Roeck <linux@roeck-us.net> signed-off-by: Richard Kuo <rkuo@codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> 
[ Upstream commit cb84c2b401d9cead5508cfed57b59b6d5feffdac ]

hexagon:defconfig fails to build in linux-next since commit 332fd7c4fef5
("genirq: Generic chip: Change irq_reg_{readl,writel} arguments").

The primary build failure is

arch/hexagon/include/asm/cacheflush.h: In function 'copy_to_user_page':
arch/hexagon/include/asm/cacheflush.h:89:22: error: 'VM_EXEC' undeclared

This is the result of including of <linux/io.h> from <linux/irq.h>,
which is now necessary due to the use of readl and writel from irq.h.
This causes recursive inclusions in hexagon code; cacheflush.h is included
from mm.h prior to the definition of VM_EXEC.

Fix the problem by moving copy_to_user_page from the hexagon include file to
arch/hexagon/mm/cache.c, similar to other architectures. After this change,
several redefinitions of readl and writel are reported. Those are caused
by recursive inclusions of io.h and asm/cacheflush.h. Fix those problems by
reducing the number of files included from those files. Also, it was necessary
to stop including asm-generic/cacheflush.h from asm/cacheflush.h. Instead,
functionality originally provided by asm-generic/cacheflush.h is now coded
in asm/cacheflush.h directly.

Cc: Kevin Cernekee <cernekee@gmail.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
signed-off-by: Richard Kuo <rkuo@codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
block: Do a full clone when splitting discard bios 2016-10-07T14:37:27+00:00 Martin K. Petersen martin.petersen@oracle.com 2015-07-22T11:57:12+00:00 f6e672ada0c9714c7d1a63054ca98c707fa916d6 This fixes a data corruption bug when using discard on top of MD linear, raid0 and raid10 personalities. Commit 20d0189b1012 "block: Introduce new bio_split()" permits sharing the bio_vec between the two resulting bios. That is fine for read/write requests where the bio_vec is immutable. For discards, however, we need to be able to attach a payload and update the bio_vec so the page can get mapped to a scatterlist entry. Therefore the bio_vec can not be shared when splitting discards and we must do a full clone. Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Reported-by: Seunguk Shin <seunguk.shin@samsung.com> Tested-by: Seunguk Shin <seunguk.shin@samsung.com> Cc: Seunguk Shin <seunguk.shin@samsung.com> Cc: Jens Axboe <axboe@fb.com> Cc: Kent Overstreet <kent.overstreet@gmail.com> Cc: <stable@vger.kernel.org> # v3.14+ Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@fb.com> 
This fixes a data corruption bug when using discard on top of MD linear,
raid0 and raid10 personalities.

Commit 20d0189b1012 "block: Introduce new bio_split()" permits sharing
the bio_vec between the two resulting bios. That is fine for read/write
requests where the bio_vec is immutable. For discards, however, we need
to be able to attach a payload and update the bio_vec so the page can
get mapped to a scatterlist entry. Therefore the bio_vec can not be
shared when splitting discards and we must do a full clone.

Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reported-by: Seunguk Shin <seunguk.shin@samsung.com>
Tested-by: Seunguk Shin <seunguk.shin@samsung.com>
Cc: Seunguk Shin <seunguk.shin@samsung.com>
Cc: Jens Axboe <axboe@fb.com>
Cc: Kent Overstreet <kent.overstreet@gmail.com>
Cc: <stable@vger.kernel.org> # v3.14+
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>