linux-stable.git/include/linux, branch v5.0.17

bpf: only test gso type on gso packets

2019-05-16T17:40:26+00:00

[ Upstream commit 4c3024debf62de4c6ac6d3cb4c0063be21d4f652 ]

BPF can adjust gso only for tcp bytestreams. Fail on other gso types.

But only on gso packets. It does not touch this field if !gso_size.

Fixes: b90efd225874 ("bpf: only adjust gso_size on bytestream protocols")
Signed-off-by: Willem de Bruijn 
Acked-by: Yonghong Song 
Signed-off-by: Daniel Borkmann 
Signed-off-by: Sasha Levin

KVM: fix spectrev1 gadgets

2019-05-16T17:40:20+00:00

[ Upstream commit 1d487e9bf8ba66a7174c56a0029c54b1eca8f99c ]

These were found with smatch, and then generalized when applicable.

Signed-off-by: Paolo Bonzini 
Signed-off-by: Sasha Levin

x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T

2019-05-16T17:40:19+00:00

[ Upstream commit 0082517fa4bce073e7cf542633439f26538a14cc ]

Upon reboot, the Acer TravelMate X514-51T laptop appears to complete the
shutdown process, but then it hangs in BIOS POST with a black screen.

The problem is intermittent - at some points it has appeared related to
Secure Boot settings or different kernel builds, but ultimately we have
not been able to identify the exact conditions that trigger the issue to
come and go.

Besides, the EFI mode cannot be disabled in the BIOS of this model.

However, after extensive testing, we observe that using the EFI reboot
method reliably avoids the issue in all cases.

So add a boot time quirk to use EFI reboot on such systems.

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=203119
Signed-off-by: Jian-Hong Pan 
Signed-off-by: Daniel Drake 
Cc: Ard Biesheuvel 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Cc: linux@endlessm.com
Link: http://lkml.kernel.org/r/20190412080152.3718-1-jian-hong@endlessm.com
[ Fix !CONFIG_EFI build failure, clarify the code and the changelog a bit. ]
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

bfq: update internal depth state when queue depth changes

2019-05-16T17:40:10+00:00

[ Upstream commit 77f1e0a52d26242b6c2dba019f6ebebfb9ff701e ]

A previous commit moved the shallow depth and BFQ depth map calculations
to be done at init time, moving it outside of the hotter IO path. This
potentially causes hangs if the users changes the depth of the scheduler
map, by writing to the 'nr_requests' sysfs file for that device.

Add a blk-mq-sched hook that allows blk-mq to inform the scheduler if
the depth changes, so that the scheduler can update its internal state.

Tested-by: Kai Krakow 
Reported-by: Paolo Valente 
Fixes: f0635b8a416e ("bfq: calculate shallow depths at init time")
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

cpu/speculation: Add 'mitigations=' cmdline option

2019-05-14T17:17:13+00:00

commit 98af8452945c55652de68536afdde3b520fec429 upstream

Keeping track of the number of mitigations for all the CPU speculation
bugs has become overwhelming for many users.  It's getting more and more
complicated to decide which mitigations are needed for a given
architecture.  Complicating matters is the fact that each arch tends to
have its own custom way to mitigate the same vulnerability.

Most users fall into a few basic categories:

a) they want all mitigations off;

b) they want all reasonable mitigations on, with SMT enabled even if
   it's vulnerable; or

c) they want all reasonable mitigations on, with SMT disabled if
   vulnerable.

Define a set of curated, arch-independent options, each of which is an
aggregation of existing options:

- mitigations=off: Disable all mitigations.

- mitigations=auto: [default] Enable all the default mitigations, but
  leave SMT enabled, even if it's vulnerable.

- mitigations=auto,nosmt: Enable all the default mitigations, disabling
  SMT if needed by a mitigation.

Currently, these options are placeholders which don't actually do
anything.  They will be fleshed out in upcoming patches.

Signed-off-by: Josh Poimboeuf 
Signed-off-by: Thomas Gleixner 
Tested-by: Jiri Kosina  (on x86)
Reviewed-by: Jiri Kosina 
Cc: Borislav Petkov 
Cc: "H . Peter Anvin" 
Cc: Andy Lutomirski 
Cc: Peter Zijlstra 
Cc: Jiri Kosina 
Cc: Waiman Long 
Cc: Andrea Arcangeli 
Cc: Jon Masters 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: linux-s390@vger.kernel.org
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-arch@vger.kernel.org
Cc: Greg Kroah-Hartman 
Cc: Tyler Hicks 
Cc: Linus Torvalds 
Cc: Randy Dunlap 
Cc: Steven Price 
Cc: Phil Auld 
Link: https://lkml.kernel.org/r/b07a8ef9b7c5055c3a4637c87d07c296d5016fe0.1555085500.git.jpoimboe@redhat.com
Signed-off-by: Greg Kroah-Hartman

x86/speculation/mds: Add sysfs reporting for MDS

2019-05-14T17:17:11+00:00

commit 8a4b06d391b0a42a373808979b5028f5c84d9c6a upstream

Add the sysfs reporting file for MDS. It exposes the vulnerability and
mitigation state similar to the existing files for the other speculative
hardware vulnerabilities.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Greg Kroah-Hartman 
Reviewed-by: Borislav Petkov 
Reviewed-by: Jon Masters 
Tested-by: Jon Masters 
Signed-off-by: Greg Kroah-Hartman

nvmet: fix discover log page when offsets are used

2019-05-10T16:36:11+00:00

[ Upstream commit d808b7f759b50acf0784ce6230ffa63e12ef465d ]

The nvme target hadn't been taking the Get Log Page offset parameter
into consideration, and so has been returning corrupted log pages when
offsets are used. Since many tools, including nvme-cli, split the log
request to 4k, we've been breaking discovery log responses when more
than 3 subsystems exist.

Fix the returned data by internally generating the entire discovery
log page and copying only the requested bytes into the user buffer. The
command log page offset type has been modified to a native __le64 to
make it easier to extract the value from a command.

Signed-off-by: Keith Busch 
Tested-by: Minwoo Im 
Reviewed-by: Chaitanya Kulkarni 
Reviewed-by: Hannes Reinecke 
Reviewed-by: James Smart 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin

blk-mq: introduce blk_mq_complete_request_sync()

2019-05-10T16:36:11+00:00

[ Upstream commit 1b8f21b74c3c9c82fce5a751d7aefb7cc0b8d33d ]

In NVMe's error handler, follows the typical steps of tearing down
hardware for recovering controller:

1) stop blk_mq hw queues
2) stop the real hw queues
3) cancel in-flight requests via
	blk_mq_tagset_busy_iter(tags, cancel_request, ...)
cancel_request():
	mark the request as abort
	blk_mq_complete_request(req);
4) destroy real hw queues

However, there may be race between #3 and #4, because blk_mq_complete_request()
may run q->mq_ops->complete(rq) remotelly and asynchronously, and
->complete(rq) may be run after #4.

This patch introduces blk_mq_complete_request_sync() for fixing the
above race.

Cc: Sagi Grimberg 
Cc: Bart Van Assche 
Cc: James Smart 
Cc: linux-nvme@lists.infradead.org
Reviewed-by: Keith Busch 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Ming Lei 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

linux/kernel.h: Use parentheses around argument in u64_to_user_ptr()

2019-05-10T16:36:08+00:00

[ Upstream commit a0fe2c6479aab5723239b315ef1b552673f434a3 ]

Use parentheses around uses of the argument in u64_to_user_ptr() to
ensure that the cast doesn't apply to part of the argument.

There are existing uses of the macro of the form

  u64_to_user_ptr(A + B)

which expands to

  (void __user *)(uintptr_t)A + B

(the cast applies to the first operand of the addition, the addition
is a pointer addition). This happens to still work as intended, the
semantic difference doesn't cause a difference in behavior.

But I want to use u64_to_user_ptr() with a ternary operator in the
argument, like so:

  u64_to_user_ptr(A ? B : C)

This currently doesn't work as intended.

Signed-off-by: Jann Horn 
Signed-off-by: Borislav Petkov 
Reviewed-by: Mukesh Ojha 
Cc: Andrei Vagin 
Cc: Andrew Morton 
Cc: Dan Carpenter 
Cc: Greg Kroah-Hartman 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Jani Nikula 
Cc: Kees Cook 
Cc: Masahiro Yamada 
Cc: NeilBrown 
Cc: Peter Zijlstra 
Cc: Qiaowei Ren 
Cc: Thomas Gleixner 
Cc: x86-ml 
Link: https://lkml.kernel.org/r/20190329214652.258477-1-jannh@google.com
Signed-off-by: Sasha Levin

clk: x86: Add system specific quirk to mark clocks as critical

2019-05-08T05:22:59+00:00

commit 7c2e07130090ae001a97a6b65597830d6815e93e upstream.

Since commit 648e921888ad ("clk: x86: Stop marking clocks as
CLK_IS_CRITICAL"), the pmc_plt_clocks of the Bay Trail SoC are
unconditionally gated off. Unfortunately this will break systems where these
clocks are used for external purposes beyond the kernel's knowledge. Fix it
by implementing a system specific quirk to mark the necessary pmc_plt_clks as
critical.

Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
Signed-off-by: David Müller 
Signed-off-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman