Commit Graph

723100 Commits

Author SHA1 Message Date
Eric Dumazet b9b312a7a4 ipv6: mcast: better catch silly mtu values
syzkaller reported crashes in IPv6 stack [1]

Xin Long found that lo MTU was set to silly values.

IPv6 stack reacts to changes to small MTU, by disabling itself under
RTNL.

But there is a window where threads not using RTNL can see a wrong
device mtu. This can lead to surprises, in mld code where it is assumed
the mtu is suitable.

Fix this by reading device mtu once and checking IPv6 minimal MTU.

[1]
 skbuff: skb_over_panic: text:0000000010b86b8d len:196 put:20
 head:000000003b477e60 data:000000000e85441e tail:0xd4 end:0xc0 dev:lo
 ------------[ cut here ]------------
 kernel BUG at net/core/skbuff.c:104!
 invalid opcode: 0000 [#1] SMP KASAN
 Dumping ftrace buffer:
    (ftrace buffer empty)
 Modules linked in:
 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.15.0-rc2-mm1+ #39
 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
 Google 01/01/2011
 RIP: 0010:skb_panic+0x15c/0x1f0 net/core/skbuff.c:100
 RSP: 0018:ffff8801db307508 EFLAGS: 00010286
 RAX: 0000000000000082 RBX: ffff8801c517e840 RCX: 0000000000000000
 RDX: 0000000000000082 RSI: 1ffff1003b660e61 RDI: ffffed003b660e95
 RBP: ffff8801db307570 R08: 1ffff1003b660e23 R09: 0000000000000000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff85bd4020
 R13: ffffffff84754ed2 R14: 0000000000000014 R15: ffff8801c4e26540
 FS:  0000000000000000(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000463610 CR3: 00000001c6698000 CR4: 00000000001406e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 Call Trace:
  <IRQ>
  skb_over_panic net/core/skbuff.c:109 [inline]
  skb_put+0x181/0x1c0 net/core/skbuff.c:1694
  add_grhead.isra.24+0x42/0x3b0 net/ipv6/mcast.c:1695
  add_grec+0xa55/0x1060 net/ipv6/mcast.c:1817
  mld_send_cr net/ipv6/mcast.c:1903 [inline]
  mld_ifc_timer_expire+0x4d2/0x770 net/ipv6/mcast.c:2448
  call_timer_fn+0x23b/0x840 kernel/time/timer.c:1320
  expire_timers kernel/time/timer.c:1357 [inline]
  __run_timers+0x7e1/0xb60 kernel/time/timer.c:1660
  run_timer_softirq+0x4c/0xb0 kernel/time/timer.c:1686
  __do_softirq+0x29d/0xbb2 kernel/softirq.c:285
  invoke_softirq kernel/softirq.c:365 [inline]
  irq_exit+0x1d3/0x210 kernel/softirq.c:405
  exiting_irq arch/x86/include/asm/apic.h:540 [inline]
  smp_apic_timer_interrupt+0x16b/0x700 arch/x86/kernel/apic/apic.c:1052
  apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:920

Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Tested-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-12-13 13:13:15 -05:00
Yuval Shaia 9d98e19ba0 IB/ipoib: Restore MM behavior in case of tx_ring allocation failure
memalloc_noio_save modifies the behavior of MM, we must restore it after
we are done.

Fixes: d83187dda9 ("IB/IPoIB: Convert IPoIB to memalloc_noio_* calls")
Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2017-12-13 10:31:57 -07:00
Geert Uytterhoeven 6b782f43d3 Revert "ravb: add workaround for clock when resuming with WoL enabled"
This reverts commit fbf3d034f2.

As of commit 560869100b ("clk: renesas: cpg-mssr: Restore module
clocks during resume"), the workaround is no longer needed.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-12-13 11:18:40 -05:00
Keith Packard 4b4df570b4 drm: Update edid-derived drm_display_info fields at edid property set [v2]
There are a set of values in the drm_display_info structure for each
connector which hold information derived from EDID. These are computed
in drm_add_display_info. Before this patch, that was only called in
drm_add_edid_modes. This meant that they were only set when EDID was
present and never reset when EDID was not, as happened when the
display was disconnected.

One of these fields, non_desktop, is used from
drm_mode_connector_update_edid_property, the function responsible for
assigning the new edid value to the application-visible property.

Various drivers call these two functions (drm_add_edid_modes and
drm_mode_connector_update_edid_property) in different orders. This
means that even when EDID is present, the drm_display_info fields may
not have been computed at the time that
drm_mode_connector_update_edid_property used the non_desktop value to
set the non_desktop property.

I've added a public function (drm_reset_display_info) that resets the
drm_display_info field values to default values and then made the
drm_add_display_info function public. These two functions are now
called directly from drm_mode_connector_update_edid_property so that
the drm_display_info fields are always computed from the current EDID
information before being used in that function.

This means that the drm_display_info values are often computed twice,
once when the EDID property it set and a second time when EDID is used
to compute modes for the device. The alternative would be to uniformly
ensure that the values were computed once before being used, which
would require that all drivers reliably invoke the two paths in the
same order. The computation is inexpensive enough that it seems more
maintainable in the long term to simply compute them in both paths.

The API to drm_add_display_info has been changed so that it no longer
takes the set of edid-based quirks as a parameter. Rather, it now
computes those quirks itself and returns them for further use by
drm_add_edid_modes.

This patch also includes a number of 'const' additions caused by
drm_mode_connector_update_edid_property taking a 'const struct edid *'
parameter and wanting to pass that along to drm_add_display_info.

v2: after review by Daniel Vetter <daniel.vetter@ffwll.ch>

	Removed EXPORT_SYMBOL_GPL for drm_reset_display_info and
	drm_add_display_info.

	Added FIXME in drm_mode_connector_update_edid_property about
	potentially merging that with drm_add_edid_modes to avoid
	the need for two driver calls.

Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171213084427.31199-1-keithp@keithp.com
(danvet: cherry picked from commit 12a889bf4bca ("drm: rework delayed
connector cleanup in connector_iter") from drm-misc-next since
functional conflict with changes in -next and we need to make sure
both have the right version and nothing gets lost.)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-12-13 14:51:37 +01:00
Alan Stern 48a4ff1c7b USB: core: prevent malicious bNumInterfaces overflow
A malicious USB device with crafted descriptors can cause the kernel
to access unallocated memory by setting the bNumInterfaces value too
high in a configuration descriptor.  Although the value is adjusted
during parsing, this adjustment is skipped in one of the error return
paths.

This patch prevents the problem by setting bNumInterfaces to 0
initially.  The existing code already sets it to the proper value
after parsing is complete.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-13 12:28:43 +01:00
Greg Kroah-Hartman cf4df407e0 Revert "USB: core: only clean up what we allocated"
This reverts commit 32fd87b3bb.

Alan wrote a better fix for this...

Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-13 11:59:39 +01:00
Mengting Zhang 92ccc262e4 tools/lib/lockdep: Add missing declaration of 'pr_cont()'
Commit:

  681fbec881 ("lockdep: Use consistent printing primitives")

has moved lockdep away from using printk() for printing.

The commit added usage of pr_cont() which wasn't wrapped in the
userspace headers, causing the following warning for the
liblockdep build:

	../../../kernel/locking/lockdep.c:3544:2: warning: implicit declaration of function 'pr_cont' [-Wimplicit-function-declaration]

Adding an empty declaration of 'pr_cont' fixes the problem.

Signed-off-by: Mengting Zhang <zhangmengting@huawei.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: a.p.zijlstra@chello.nl
Link: http://lkml.kernel.org/r/20171212181644.11913-2-alexander.levin@verizon.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-12-13 11:17:35 +01:00
Dongjiu Geng faa75e147b arm64: fault: avoid send SIGBUS two times
do_sea() calls arm64_notify_die() which will always signal
user-space. It also returns whether APEI claimed the external
abort as a RAS notification. If it returns failure do_mem_abort()
will signal user-space too.

do_mem_abort() wants to know if we handled the error, we always
call arm64_notify_die() so can always return success.

Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
Reviewed-by: James Morse <james.morse@arm.com>
Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2017-12-13 09:58:13 +00:00
Linus Torvalds d39a01eff9 platform-drivers-x86 for v4.15-3
Correct an error in the evdev protocol in asus-wireless which results in
 dropped key events in recent versions of libinput. Add a quirk for
 keyboard lighting for a specific Dell laptop. Silence a static analysis
 warning regarding unchecked return values of small kmalloc() allocations
 in dell-wmi.
 
 The following is an automated git shortlog grouped by driver:
 
 asus-wireless:
  -  send an EV_SYN/SYN_REPORT between state changes
 
 dell-laptop:
  -  Fix keyboard max lighting for Dell Latitude E6410
 
 dell-wmi:
  -  check for kmalloc() errors
 -----BEGIN PGP SIGNATURE-----
 
 iQEcBAABAgAGBQJaMGsQAAoJEKbMaAwKp364nxYH+wQPoNXh23oNQWG+y9QdldEu
 /bI5tbQVfmMLmSNcI2tjq7NS8QGRbn2sTIMilqsrLJAR7RY78uvISOwV8JeLHrd4
 dMjh2VgcOQb6IuVT9H4oS+mSnDhXxtqDZrMlTp9wDztFcRgoP2RrUuxV/RG3ZiDH
 qtKq3RUfB+j6vOXkXifdK83x+FVIk5PiFrMpEytrlgT0y/FWbMz0aj4dm1mMx9Yl
 tS8uuEl9Gh6a+XPi6sMHJ0pH5cbNxmO9hPyRg3Jq+KZYj+NfyEytw+G0J1CAF0LO
 mM37C8gs9ISEOCnUCopZh5fA+sM7WIUoe7jLFiw6Ocj2yU2adp3p214eP3TGZ4Y=
 =hrbr
 -----END PGP SIGNATURE-----

Merge tag 'platform-drivers-x86-v4.15-3' of git://git.infradead.org/linux-platform-drivers-x86

Pull x86 platform driver fixes from Darren Hart:

 - Correct an error in the evdev protocol in asus-wireless which results
   in dropped key events in recent versions of libinput

 - Add a quirk for keyboard lighting for a specific Dell laptop

 - Silence a static analysis warning regarding unchecked return values
   of small kmalloc() allocations in dell-wmi

* tag 'platform-drivers-x86-v4.15-3' of git://git.infradead.org/linux-platform-drivers-x86:
  platform/x86: dell-wmi: check for kmalloc() errors
  platform/x86: asus-wireless: send an EV_SYN/SYN_REPORT between state changes
  platform/x86: dell-laptop: Fix keyboard max lighting for Dell Latitude E6410
2017-12-12 17:19:58 -08:00
Eric Dumazet 9147efcbe0 bpf: add schedule points to map alloc/free
While using large percpu maps, htab_map_alloc() can hold
cpu for hundreds of ms.

This patch adds cond_resched() calls to percpu alloc/free
call sites, all running in process context.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2017-12-12 15:27:22 -08:00
Jean Delvare 45fd4470ba i2c: piix4: Fix port number check on release
The port number shift is still hard-coded to 1 while it now depends
on the hardware.

Thankfully 0 is always 0 no matter how you shift it, so this was a
bug without consequences.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Fixes: 0fe16195f8 ("i2c: piix4: Fix SMBus port selection for AMD Family 17h chips")
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2017-12-12 23:27:04 +01:00
Benjamin Gaignard 9c41e45218 i2c: stm32: Fix copyrights
Uniformize STMicroelectronics copyrights headers and add SPDX
identifier.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Acked-by: Alexandre TORGUE <alexandre.torgue@st.com>
Acked-by: Pierre-Yves MORDRET <pierre-yves.mordret@st.com>
Acked-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2017-12-12 23:16:04 +01:00
Wolfram Sang a3fe09bc03 AT24 fixes for 4.15-rc3
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAlopTtAACgkQEacuoBRx
 13KotRAAyO8Q5poK+XS/SiDCDUHSW+98kZP6wN2210+6LQ48EBA85cGmApdZn2tG
 918JK3y0sYUzto8EhHTadOnCT9wjOMyhRyxAPx8h2qGNm7ET2xTVWsV5GwNWdvCU
 YB9pD8h9+oSakNriNg5uNuLdNnTfVrhYn07dDp3x13uZQ9KfLV+JQtUYUOefZPpW
 Y/RBemDagFLFggwFR968B1TR+2BPcTc6E1BRiUowbIpNTI5507mo24IDTmaQfd/w
 KGMW0UIVO88aTOCQofFt0b80y0g7m6olt2LZZwVZR/Y8FP39OoTf/W7JeHMiatIw
 oFoEyloj96AcHJuV3g2Suc+/qb07oD3cwx09cKnId5j//x8MX9KnZnlfodcAS9Bz
 mcu0TvOSSwrU1vjkIBlkRuGXcnDVhbdOYzymZJ74cr21CznFRZo/Br9GvLI9VE9n
 zPpVD4Nm8UA6FzSPijFOQK97z1l2CP09XJ4tXu+1udGnebN/JtkD9LeVjO7nnv80
 cuEMBe9rgGIHzvAVCzt+rkBGvzKlkTyNVZoz0mPiRiHPKN73NBaahJrVlYXpd92I
 MJUxkvJlOal242pwLvbfcl9pK8y4Y74Is+z969tuQ6KQGNVGI9wizF9Gjbp+CHy5
 waVVGKVkg02s1ONj/iO5oJICWBfhQ3Slj3VTO8zftRr2Oj+3B+c=
 =E17D
 -----END PGP SIGNATURE-----

Merge tag 'at24-4.15-rc3-fixes-for-wolfram' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into i2c/for-current

Sakari fixed a regression introduced during the 4.15 merge window and
David submitted a fix for an issue that has existed in at24 since
introducing nvmem.
2017-12-12 23:08:33 +01:00
Alexei Starovoitov 9dbd2d948e Merge branch 'bpf-misc-fixes'
Daniel Borkmann says:

====================
Couple of outstanding fixes for BPF tree: 1) fixes a perf RB
corruption, 2) and 3) fixes a few build issues from the recent
bpf_perf_event.h uapi corrections. Thanks!
====================

Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2017-12-12 09:52:09 -08:00
Daniel Borkmann 720f228e8d bpf: fix broken BPF selftest build
At least on x86_64, the kernel's BPF selftests seemed to have stopped
to build due to 618e165b2a ("selftests/bpf: sync kernel headers and
introduce arch support in Makefile"):

  [...]
  In file included from test_verifier.c:29:0:
  ../../../include/uapi/linux/bpf_perf_event.h:11:32:
     fatal error: asm/bpf_perf_event.h: No such file or directory
   #include <asm/bpf_perf_event.h>
                                ^
  compilation terminated.
  [...]

While pulling in tools/arch/*/include/uapi/asm/bpf_perf_event.h seems
to work fine, there's no automated fall-back logic right now that would
do the same out of tools/include/uapi/asm-generic/bpf_perf_event.h. The
usual convention today is to add a include/[uapi/]asm/ equivalent that
would pull in the correct arch header or generic one as fall-back, all
ifdef'ed based on compiler target definition. It's similarly done also
in other cases such as tools/include/asm/barrier.h, thus adapt the same
here.

Fixes: 618e165b2a ("selftests/bpf: sync kernel headers and introduce arch support in Makefile")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2017-12-12 09:51:12 -08:00
Daniel Borkmann a23f06f06d bpf: fix build issues on um due to mising bpf_perf_event.h
Since c895f6f703 ("bpf: correct broken uapi for
BPF_PROG_TYPE_PERF_EVENT program type") um (uml) won't build
on i386 or x86_64:

  [...]
    CC      init/main.o
  In file included from ../include/linux/perf_event.h:18:0,
                   from ../include/linux/trace_events.h:10,
                   from ../include/trace/syscall.h:7,
                   from ../include/linux/syscalls.h:82,
                   from ../init/main.c:20:
  ../include/uapi/linux/bpf_perf_event.h:11:32: fatal error:
  asm/bpf_perf_event.h: No such file or directory #include
  <asm/bpf_perf_event.h>
  [...]

Lets add missing bpf_perf_event.h also to um arch. This seems
to be the only one still missing.

Fixes: c895f6f703 ("bpf: correct broken uapi for BPF_PROG_TYPE_PERF_EVENT program type")
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Suggested-by: Richard Weinberger <richard@sigma-star.at>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Cc: Richard Weinberger <richard@sigma-star.at>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2017-12-12 09:51:12 -08:00
Daniel Borkmann 283ca526a9 bpf: fix corruption on concurrent perf_event_output calls
When tracing and networking programs are both attached in the
system and both use event-output helpers that eventually call
into perf_event_output(), then we could end up in a situation
where the tracing attached program runs in user context while
a cls_bpf program is triggered on that same CPU out of softirq
context.

Since both rely on the same per-cpu perf_sample_data, we could
potentially corrupt it. This can only ever happen in a combination
of the two types; all tracing programs use a bpf_prog_active
counter to bail out in case a program is already running on
that CPU out of a different context. XDP and cls_bpf programs
by themselves don't have this issue as they run in the same
context only. Therefore, split both perf_sample_data so they
cannot be accessed from each other.

Fixes: 20b9d7ac48 ("bpf: avoid excessive stack usage for perf_sample_data")
Reported-by: Alexei Starovoitov <ast@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Song Liu <songliubraving@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2017-12-12 09:51:12 -08:00
Geert Uytterhoeven 0c31f1d7be PCI: rcar: Fix use-after-free in probe error path
If CONFIG_DEBUG_SLAB=y, and no PCIe card is inserted, the kernel crashes
during probe on r8a7791/koelsch:

  rcar-pcie fe000000.pcie: PCIe link down
  Unable to handle kernel paging request at virtual address 6b6b6b6b

(seeing this message requires earlycon and keep_bootcon).

Indeed, pci_free_host_bridge() frees the PCI host bridge, including the
embedded rcar_pcie object, so pci_free_resource_list() must not be called
afterwards.

To fix this, move the call to pci_free_resource_list() up, and update the
label name accordingly.

Fixes: ddd535f1ea ("PCI: rcar: Fix memory leak when no PCIe card is inserted")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2017-12-12 11:01:47 -06:00
Christoph Paasch 30791ac419 tcp md5sig: Use skb's saddr when replying to an incoming segment
The MD5-key that belongs to a connection is identified by the peer's
IP-address. When we are in tcp_v4(6)_reqsk_send_ack(), we are replying
to an incoming segment from tcp_check_req() that failed the seq-number
checks.

Thus, to find the correct key, we need to use the skb's saddr and not
the daddr.

This bug seems to have been there since quite a while, but probably got
unnoticed because the consequences are not catastrophic. We will call
tcp_v4_reqsk_send_ack only to send a challenge-ACK back to the peer,
thus the connection doesn't really fail.

Fixes: 9501f97229 ("tcp md5sig: Let the caller pass appropriate key for tcp_v{4,6}_do_calc_md5_hash().")
Signed-off-by: Christoph Paasch <cpaasch@apple.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-12-12 11:15:42 -05:00
Jan Beulich c4f9d9cb2c xen: XEN_ACPI_PROCESSOR is Dom0-only
Add a respective dependency.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2017-12-12 09:39:43 -05:00
Jan Beulich 0f3922a9b9 x86/Xen: don't report ancient LAPIC version
Unconditionally reporting a value seen on the P4 or older invokes
functionality like io_apic_get_unique_id() on 32-bit builds, resulting
in a panic() with sufficiently many CPUs and/or IO-APICs. Doing what
that function does would be the hypervisor's responsibility anyway, so
makes no sense to be used when running on Xen. Uniformly report a more
modern version; this shouldn't matter much as both LAPIC and IO-APIC are
being managed entirely / mostly by the hypervisor.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2017-12-12 09:39:17 -05:00
Mark Rutland 8cb562b1d5 checkpatch: Remove ACCESS_ONCE() warning
Now that ACCESS_ONCE() has been excised from the kernel, any uses will
result in a build error, and we no longer need to whine about it in
checkpatch.

This patch removes the newly redundant warning.

Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Joe Perches <joe@perches.com>
Cc: Andy Whitcroft <apw@canonical.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: acme@redhat.com
Link: http://lkml.kernel.org/r/20171127103824.36526-5-mark.rutland@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-12-12 13:22:10 +01:00
Mark Rutland b899a85043 compiler.h: Remove ACCESS_ONCE()
There are no longer any kernelspace uses of ACCESS_ONCE(), so we can
remove the definition from <linux/compiler.h>.

This patch removes the ACCESS_ONCE() definition, and updates comments
which referred to it. At the same time, some inconsistent and redundant
whitespace is removed from comments.

Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Joe Perches <joe@perches.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: apw@canonical.com
Link: http://lkml.kernel.org/r/20171127103824.36526-4-mark.rutland@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-12-12 13:22:10 +01:00
Mark Rutland 2a22f692bb tools/include: Remove ACCESS_ONCE()
There are no longer any usersapce uses of ACCESS_ONCE(), so we can
remove the definition from our userspace <linux/compiler.h>, which is
only used by tools in the kernel directory (i.e. it isn't a uapi
header).

This patch removes the ACCESS_ONCE() definition, and updates comments
which referred to it. At the same time, some inconsistent and redundant
whitespace is removed from comments.

Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Joe Perches <joe@perches.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: apw@canonical.com
Link: http://lkml.kernel.org/r/20171127103824.36526-3-mark.rutland@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-12-12 13:22:10 +01:00
Mark Rutland f971e511cb tools/perf: Convert ACCESS_ONCE() to READ_ONCE()
Recently there was a treewide conversion of ACCESS_ONCE() to
{READ,WRITE}_ONCE(), but a new use was introduced concurrently by
commit:

  1695849735 ("perf mmap: Move perf_mmap and methods to separate mmap.[ch] files")

Let's convert this over to READ_ONCE() so that we can remove the
ACCESS_ONCE() definitions in subsequent patches.

Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Joe Perches <joe@perches.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: apw@canonical.com
Link: http://lkml.kernel.org/r/20171127103824.36526-2-mark.rutland@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-12-12 13:22:09 +01:00
Andrey Konovalov 32fd87b3bb USB: core: only clean up what we allocated
When cleaning up the configurations, make sure we only free the number
of configurations and interfaces that we could have allocated.

Reported-by: Andrey Konovalov <andreyknvl@google.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-12 13:04:55 +01:00
Will Deacon 0e17cada2a arm64: hw_breakpoint: Use linux/uaccess.h instead of asm/uaccess.h
The only inclusion of asm/uaccess.h should be by linux/uaccess.h. All
other headers should use the latter.

Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2017-12-12 11:53:26 +00:00
Greg Kroah-Hartman c1ed473554 usb: fixes for v4.15-rc4
We have a few fixes on dwc3:
 
 - one fix which only happens with some implementations where we need to
   wait longer for some commands to finish.
 
 - Another fix for high-bandwidth isochronous endpoint programming making
   sure that we send the correct DATA tokens in the correct sequence
 
 - A couple PM fixes on dwc3-of-simple
 
 The other synopsys controller driver (dwc2) got a fix for FIFO size
 programming.
 
 Other than these, we have a couple Kconfig fixes making sure that
 dependencies are properly setup.
 -----BEGIN PGP SIGNATURE-----
 
 iQJRBAABCgA7FiEElLzh7wn96CXwjh2IzL64meEamQYFAlovtj8dHGZlbGlwZS5i
 YWxiaUBsaW51eC5pbnRlbC5jb20ACgkQzL64meEamQYkhg/+Js7q/csuLfknxIeU
 0FT0exGWBr/XNWDwvckS65yR6zFgG6txRmuuHTq1BcqiOL6jpqV0D8VoAUt/rv1U
 HrUPYMaS8Y5qpYZOe28NyyFgl+5CuoYdLkToAqUrX1MRXClt4Cx+XeJ6yOM6heXb
 codXGef04oCTVYbDuPBbO1S99Pi1nw2T7jOLrhwegAGKEBMCzv+uT/qCR/uG5Fzr
 5GHWWQyHLlo3Av29Rmp4GCFONlyxzGyKTKN+tFAVurGsO9UN8zY2BhfP6mH3kG64
 dyef/hWJ4adhxnbTlrjrnZ52RBePhuUzqXDpKPrCYr9mlsI9NfPk6ablvHkF4W5K
 bXqE8YTuiRdQIRS1+3LbK0BSsuC4svVD3QpN2fghPhkcxPg2FnR4eI3t5IupM6Hz
 tqZvn4BU1UPdrRO3FBmyY/ZMTzsk5u4GB81FUUJRqQlg9cPTcjAWTmwox8fVzf6j
 B2uC59qRn5KDMTKOyCU2CATo3Oi211WCWsUtnO7+mXxknyaWOjWI0MfV0fB3OLIj
 IPm/PVfNcECjiOOpgyhSUY5YbIkQpD3/u9U8cuC+2Q2na7Cftsy/tJLrVlKgLXvQ
 VgHoHGwSPkGdrClRp5mB0c5m2byPAE+BaOleSmeepiq2dDUvgr8hjgBURooKpC9j
 mfNmZrsJgYXQIU9v6E0z92PH/+0=
 =6T1G
 -----END PGP SIGNATURE-----

Merge tag 'fixes-for-v4.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus

Felipe writes:

usb: fixes for v4.15-rc4

We have a few fixes on dwc3:

- one fix which only happens with some implementations where we need to
  wait longer for some commands to finish.

- Another fix for high-bandwidth isochronous endpoint programming making
  sure that we send the correct DATA tokens in the correct sequence

- A couple PM fixes on dwc3-of-simple

The other synopsys controller driver (dwc2) got a fix for FIFO size
programming.

Other than these, we have a couple Kconfig fixes making sure that
dependencies are properly setup.
2017-12-12 12:51:05 +01:00
Shanker Donthineni 932b50c7c1 arm64: Add software workaround for Falkor erratum 1041
The ARM architecture defines the memory locations that are permitted
to be accessed as the result of a speculative instruction fetch from
an exception level for which all stages of translation are disabled.
Specifically, the core is permitted to speculatively fetch from the
4KB region containing the current program counter 4K and next 4K.

When translation is changed from enabled to disabled for the running
exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the
Falkor core may errantly speculatively access memory locations outside
of the 4KB region permitted by the architecture. The errant memory
access may lead to one of the following unexpected behaviors.

1) A System Error Interrupt (SEI) being raised by the Falkor core due
   to the errant memory access attempting to access a region of memory
   that is protected by a slave-side memory protection unit.
2) Unpredictable device behavior due to a speculative read from device
   memory. This behavior may only occur if the instruction cache is
   disabled prior to or coincident with translation being changed from
   enabled to disabled.

The conditions leading to this erratum will not occur when either of the
following occur:
 1) A higher exception level disables translation of a lower exception level
   (e.g. EL2 changing SCTLR_EL1[M] from a value of 1 to 0).
 2) An exception level disabling its stage-1 translation if its stage-2
    translation is enabled (e.g. EL1 changing SCTLR_EL1[M] from a value of 1
    to 0 when HCR_EL2[VM] has a value of 1).

To avoid the errant behavior, software must execute an ISB immediately
prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.

Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2017-12-12 11:45:19 +00:00
Shanker Donthineni c622cc013c arm64: Define cputype macros for Falkor CPU
Add cputype definition macros for Qualcomm Datacenter Technologies
Falkor CPU in cputype.h. It's unfortunate that the first revision
of the Falkor CPU used the wrong part number 0x800, got fixed in v2
chip with part number 0xC00, and would be used the same value for
future revisions.

Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2017-12-12 11:45:19 +00:00
Will Deacon 86c9e8126e arm64: mm: Fix false positives in set_pte_at access/dirty race detection
Jiankang reports that our race detection in set_pte_at is firing when
copying the page tables in dup_mmap as a result of a fork(). In this
situation, the page table isn't actually live and so there is no way
that we can race with a concurrent update from the hardware page table
walker.

This patch reworks the race detection so that we require either the
mm to match the current active_mm (i.e. currently installed in our TTBR0)
or the mm_users count to be greater than 1, implying that the page table
could be live in another CPU. The mm_users check might still be racy,
but we'll avoid false positives and it's not realistic to validate that
all the necessary locks are held as part of this assertion.

Cc: Yisheng Xie <xieyisheng1@huawei.com>
Reported-by: Jiankang Chen <chenjiankang1@huawei.com>
Tested-by: Jiankang Chen <chenjiankang1@huawei.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2017-12-12 11:42:24 +00:00
Ingo Molnar e966eaeeb6 locking/lockdep: Remove the cross-release locking checks
This code (CONFIG_LOCKDEP_CROSSRELEASE=y and CONFIG_LOCKDEP_COMPLETIONS=y),
while it found a number of old bugs initially, was also causing too many
false positives that caused people to disable lockdep - which is arguably
a worse overall outcome.

If we disable cross-release by default but keep the code upstream then
in practice the most likely outcome is that we'll allow the situation
to degrade gradually, by allowing entropy to introduce more and more
false positives, until it overwhelms maintenance capacity.

Another bad side effect was that people were trying to work around
the false positives by uglifying/complicating unrelated code. There's
a marked difference between annotating locking operations and
uglifying good code just due to bad lock debugging code ...

This gradual decrease in quality happened to a number of debugging
facilities in the kernel, and lockdep is pretty complex already,
so we cannot risk this outcome.

Either cross-release checking can be done right with no false positives,
or it should not be included in the upstream kernel.

( Note that it might make sense to maintain it out of tree and go through
  the false positives every now and then and see whether new bugs were
  introduced. )

Cc: Byungchul Park <byungchul.park@lge.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-12-12 12:38:51 +01:00
Felipe Balbi 9dbe416b65 Revert "usb: gadget: allow to enable legacy drivers without USB_ETH"
This reverts commit 7a9618a22a.

Romain Izard recently reported that commit 7a9618a22a ended up
allowing every legacy gadget driver to statically linked to the
kernel, however that doesn't work, since only one legacy gadget can be
bound to a controller. Because of that, let's revert the original commit
and fix the problem.

Reported-by: Romain Izard <romain.izard.pro@gmail.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2017-12-12 12:48:30 +02:00
Arnd Bergmann 54eed78c5c usb: gadget: webcam: fix V4L2 Kconfig dependency
Configuring the USB_G_WEBCAM driver as built-in leads to a link
error when CONFIG_VIDEO_V4L2 is a loadable module:

drivers/usb/gadget/function/f_uvc.o: In function `uvc_function_setup':
f_uvc.c:(.text+0xfe): undefined reference to `v4l2_event_queue'
drivers/usb/gadget/function/f_uvc.o: In function `uvc_function_ep0_complete':
f_uvc.c:(.text+0x188): undefined reference to `v4l2_event_queue'

This changes the Kconfig dependency to disallow that configuration,
and force it to be a module in that case as well.

This is apparently a rather old bug, but very hard to trigger
even in thousands of randconfig builds.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2017-12-12 12:44:11 +02:00
Will Deacon d89c70356a locking/core: Remove break_lock field when CONFIG_GENERIC_LOCKBREAK=y
When CONFIG_GENERIC_LOCKBEAK=y, locking structures grow an extra int ->break_lock
field which is used to implement raw_spin_is_contended() by setting the field
to 1 when waiting on a lock and clearing it to zero when holding a lock.
However, there are a few problems with this approach:

  - There is a write-write race between a CPU successfully taking the lock
    (and subsequently writing break_lock = 0) and a waiter waiting on
    the lock (and subsequently writing break_lock = 1). This could result
    in a contended lock being reported as uncontended and vice-versa.

  - On machines with store buffers, nothing guarantees that the writes
    to break_lock are visible to other CPUs at any particular time.

  - READ_ONCE/WRITE_ONCE are not used, so the field is potentially
    susceptible to harmful compiler optimisations,

Consequently, the usefulness of this field is unclear and we'd be better off
removing it and allowing architectures to implement raw_spin_is_contended() by
providing a definition of arch_spin_is_contended(), as they can when
CONFIG_GENERIC_LOCKBREAK=n.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1511894539-7988-3-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-12-12 11:24:01 +01:00
Will Deacon f87f3a328d locking/core: Fix deadlock during boot on systems with GENERIC_LOCKBREAK
Commit:

  a8a217c221 ("locking/core: Remove {read,spin,write}_can_lock()")

removed the definition of raw_spin_can_lock(), causing the GENERIC_LOCKBREAK
spin_lock() routines to poll the ->break_lock field when waiting on a lock.

This has been reported to cause a deadlock during boot on s390, because
the ->break_lock field is also set by the waiters, and can potentially
remain set indefinitely if no other CPUs come in to take the lock after
it has been released.

This patch removes the explicit spinning on ->break_lock from the waiters,
instead relying on the outer trylock() operation to determine when the
lock is available.

Reported-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Tested-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: a8a217c221 ("locking/core: Remove {read,spin,write}_can_lock()")
Link: http://lkml.kernel.org/r/1511894539-7988-2-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-12-12 11:24:01 +01:00
Bart Van Assche 14e3062fb1 scsi: core: Fix a scsi_show_rq() NULL pointer dereference
Avoid that scsi_show_rq() triggers a NULL pointer dereference if called
after sd_uninit_command(). Swap the NULL pointer assignment and the
mempool_free() call in sd_uninit_command() to make it less likely that
scsi_show_rq() triggers a use-after-free. Note: even with these changes
scsi_show_rq() can trigger a use-after-free but that's a lesser evil
than e.g. suppressing debug information for T10 PI Type 2 commands
completely. This patch fixes the following oops:

BUG: unable to handle kernel NULL pointer dereference at (null)
IP: scsi_format_opcode_name+0x1a/0x1c0
CPU: 1 PID: 1881 Comm: cat Not tainted 4.14.0-rc2.blk_mq_io_hang+ #516
Call Trace:
 __scsi_format_command+0x27/0xc0
 scsi_show_rq+0x5c/0xc0
 __blk_mq_debugfs_rq_show+0x116/0x130
 blk_mq_debugfs_rq_show+0xe/0x10
 seq_read+0xfe/0x3b0
 full_proxy_read+0x54/0x90
 __vfs_read+0x37/0x160
 vfs_read+0x96/0x130
 SyS_read+0x55/0xc0
 entry_SYSCALL_64_fastpath+0x1a/0xa5

[mkp: added Type 2]

Fixes: 0eebd005dd ("scsi: Implement blk_mq_ops.show_rq()")
Reported-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
Cc: James E.J. Bottomley <jejb@linux.vnet.ibm.com>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Cc: Ming Lei <ming.lei@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.com>
Cc: Johannes Thumshirn <jthumshirn@suse.de>
Cc: stable@vger.kernel.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2017-12-11 21:56:48 -05:00
Johannes Thumshirn 3e5c63565a scsi: MAINTAINERS: change FCoE list to linux-scsi
fcoe-devel@open-fcoe.org is defunct and all patches are routed via the
SCSI tree anyways.

So update MAINTAINERS accordingly.

Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Bart Van Assche <bart.vanassche@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2017-12-11 21:47:28 -05:00
Jason Yan 621f6401fd scsi: libsas: fix length error in sas_smp_handler()
The return value of smp_execute_task_sg() is the untransferred residual,
but bsg_job_done() requires the length of payload received. This makes
SMP passthrough commands from userland by sg ioctl to libsas get a wrong
response. The userland tools such as smp_utils failed because of these
wrong responses:

~#smp_discover /dev/bsg/expander-2\:13
response too short, len=0
~#smp_discover /dev/bsg/expander-2\:134
response too short, len=0

Fix this by passing the actual received length to bsg_job_done(). And if
smp_execute_task_sg() returns 0, this means received length is exactly
the buffer length.

[mkp: typo]

Fixes: 651a013649 ("scsi: scsi_transport_sas: switch to bsg-lib for SMP passthrough")
Cc: <stable@vger.kernel.org> # v4.14+
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Reported-by: chenqilin <chenqilin2@huawei.com>
Tested-by: chenqilin <chenqilin2@huawei.com>
CC: Christoph Hellwig <hch@lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2017-12-11 21:45:34 -05:00
Dan Carpenter 532298b950 platform/x86: dell-wmi: check for kmalloc() errors
This allocation won't fail in the current kernel because it's small but
not checking for kmalloc() failures introduces static checker warnings
so let's fix it.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Mario Limonciello <mario.limonciello@dell.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2017-12-11 17:26:03 -08:00
Peter Hutterer bff5bf9db1 platform/x86: asus-wireless: send an EV_SYN/SYN_REPORT between state changes
Sending the switch state change twice within the same frame is invalid
evdev protocol and only works if the client handles keys immediately as
well. Processing events immediately is incorrect, it forces a fake
order of events that does not exist on the device.

Recent versions of libinput changed to only process the device state and
SYN_REPORT time, so now the key event is lost.

https://bugs.freedesktop.org/show_bug.cgi?id=104041

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2017-12-11 17:26:02 -08:00
Pali Rohár 68a213d325 platform/x86: dell-laptop: Fix keyboard max lighting for Dell Latitude E6410
This machine reports number of keyboard backlight led levels, instead of
value of the last led level index. Therefore max_brightness properly needs
to be subtracted by 1 to match led max_brightness API.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Reported-by: Gabriel M. Elder <gabriel@tekgnowsys.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196913
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2017-12-11 17:24:21 -08:00
Linus Torvalds a638349bf6 Merge branch 'for-4.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu
Pull percpu fix from Tejun Heo:
 "Just one patch to work around CRIS boot problem caused by a recent
  change which freed a temporary boot data structure. The root cause is
  on CRIS side but it doesn't seem trivial to fix. For now, work around
  by skipping freeing on CRIS"

* 'for-4.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu:
  percpu: hack to let the CRIS architecture to boot until they clean up
2017-12-11 17:13:03 -08:00
Linus Torvalds 085bec853a Merge branch 'for-4.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup
Pull cgroup fixes from Tejun Heo:

 - Prateek posted a couple patches to fix a deadlock involving cpuset
   and workqueue. It unfortunately caused a different deadlock and the
   recent workqueue hotplug simplification removed the original
   deadlock, so Prateek's two patches are reverted for now.

 - The new stat code was missing u64_stats initialization. Fixed.

 - Doc and other misc changes

* 'for-4.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
  cgroup: add warning about RT not being supported on cgroup2
  Revert "cgroup/cpuset: remove circular dependency deadlock"
  Revert "cpuset: Make cpuset hotplug synchronous"
  cgroup: properly init u64_stats
  debug cgroup: use task_css_set instead of rcu_dereference
  cpuset: Make cpuset hotplug synchronous
  cgroup/cpuset: remove circular dependency deadlock
2017-12-11 17:10:05 -08:00
Linus Torvalds 72dd379e67 Merge branch 'for-4.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq
Pull workqueue fixes from Tejun Heo:

 - Lai's hotplug simplifications inadvertently fix a possible deadlock
   involving cpuset and workqueue

 - CPU isolation fix which was reverted due to the changes in the
   housekeeping code resurrected

 - A trivial unused include removal

* 'for-4.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
  workqueue: remove unneeded kallsyms include
  workqueue/hotplug: remove the workaround in rebind_workers()
  workqueue/hotplug: simplify workqueue_offline_cpu()
  workqueue: respect isolated cpus when queueing an unbound work
  main: kernel_start: move housekeeping_init() before workqueue_init_early()
2017-12-11 17:07:26 -08:00
Linus Torvalds a83cb7e6ad Merge branch 'for-4.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata
Pull libata fixes from Tejun Heo:
 "Nothing too interesting. David Milburn improved a corner case
  misbehavior during hotplug. Other than that, minor driver-specific
  fixes"

* 'for-4.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
  libata: sata_down_spd_limit should return if driver has not recorded sstatus speed
  ahci: mtk: Change driver name to ahci-mtk
  ahci: qoriq: refine port register configuration
  pata_pdc2027x : make pdc2027x_*_timing structures const
  pata_pdc2027x: Remove unnecessary error check
  ata: mediatek: Fix typo in module description
2017-12-11 17:05:33 -08:00
Linus Torvalds bfb529ee79 The big changes for IPMI that just went in had a few problems. These
have been in for-next for a while, each since about their creation
 date.  I forgot the bugzilla reference on the second one (ipmi_si: Fix
 oops with PCI devices) so I rebased to add that.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJaLo1KAAoJEGHzjJCRm/+B0HsP/joYHLSzoAESfihnx9JD1dn6
 JM8ZV8fu7e1ZpnrxyGj/dPLSBS1k8wsVKAEGrL5ETz4UOuwIR6/61wpzfyrQf/L5
 0ZBhpv8dAxpHvFZGGE1NCF4jNlo20K0i8YQk9lUxB3Nml3udUd+GUA/Li5d2vGo4
 e6xZyS15euNmHwnELaCguS9Vz79xusLmFvgicmi5l7+Y3X4Ul/sNL+pGySYUMqxU
 NvsH3fTDXJfRv2FCnJwn1sUGpPPPH0uYhaLKXNpekt0PgNNTlTzFWGnfRJrbD/+q
 OWXrfuqiwoCSRhfOXooI2vGAIZ+jjL/vBS9827EGjf0tWgTVnOx+wuDND15uZkxP
 LizUG0ZPcov0veDh1mExIBIU2sCGkZ+dlQeGLaVBQ4tNgbyJyWi5HiwvFc5r9s/e
 /ak0kkt9J54T4MgtEMBEEHSMatUixM8eXJ7K9ySZANP5vXlLmcpXVKBHEB42QWBN
 I1V5o1PVHxV8IrG/zOiWYBLYraWocEaNat/LzlbqGMfoVyb1gXpAI8Cbjphq1xOU
 49J5oY6L8MHNIu0VkEV9MtIEyLAM/V/nd8WQ3YpD/4UJnVoWcorBQWSC7NssWFm8
 5N4dq7kXSnUM4yA21PMogFCnRToO6nrK/ijxOkzWmPbDnvDDywQY/bnj7dAKFQri
 iQ67umU2z0+U4juY+Lls
 =3M4K
 -----END PGP SIGNATURE-----

Merge tag 'for-linus-4.15-2' of git://github.com/cminyard/linux-ipmi

Pull IPMI fixes from Corey Minyard.

* tag 'for-linus-4.15-2' of git://github.com/cminyard/linux-ipmi:
  ipmi_si: fix crash on parisc
  ipmi_si: Fix oops with PCI devices
  ipmi: Stop timers before cleaning up the module
2017-12-11 17:01:59 -08:00
Linus Torvalds 916b20e02e Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
Pull crypto fixes from Herbert Xu:
 "This push fixes the following issues:

   - buffer overread in RSA

   - potential use after free in algif_aead.

   - error path null pointer dereference in af_alg

   - forbid combinations such as hmac(hmac(sha3)) which may crash

   - crash in salsa20 due to incorrect API usage"

* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  crypto: salsa20 - fix blkcipher_walk API usage
  crypto: hmac - require that the underlying hash algorithm is unkeyed
  crypto: af_alg - fix NULL pointer dereference in
  crypto: algif_aead - fix reference counting of null skcipher
  crypto: rsa - fix buffer overread when stripping leading zeroes
2017-12-11 16:32:45 -08:00
Steve Wise c058ecf6e4 iw_cxgb4: only insert drain cqes if wq is flushed
Only insert our special drain CQEs to support ib_drain_sq/rq() after
the wq is flushed. Otherwise, existing but not yet polled CQEs can be
returned out of order to the user application.  This can happen when the
QP has exited RTS but not yet flushed the QP, which can happen during
a normal close (vs abortive close).

In addition never count the drain CQEs when determining how many CQEs
need to be synthesized during the flush operation.  This latter issue
should never happen if the QP is properly flushed before inserting the
drain CQE, but I wanted to avoid corrupting the CQ state.  So we handle
it and log a warning once.

Fixes: 4fe7c2962e ("iw_cxgb4: refactor sq/rq drain logic")
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2017-12-11 15:33:51 -07:00
Chandan Rajendra 9d5afec6b8 ext4: fix crash when a directory's i_size is too small
On a ppc64 machine, when mounting a fuzzed ext2 image (generated by
fsfuzzer) the following call trace is seen,

VFS: brelse: Trying to free free buffer
WARNING: CPU: 1 PID: 6913 at /root/repos/linux/fs/buffer.c:1165 .__brelse.part.6+0x24/0x40
.__brelse.part.6+0x20/0x40 (unreliable)
.ext4_find_entry+0x384/0x4f0
.ext4_lookup+0x84/0x250
.lookup_slow+0xdc/0x230
.walk_component+0x268/0x400
.path_lookupat+0xec/0x2d0
.filename_lookup+0x9c/0x1d0
.vfs_statx+0x98/0x140
.SyS_newfstatat+0x48/0x80
system_call+0x58/0x6c

This happens because the directory that ext4_find_entry() looks up has
inode->i_size that is less than the block size of the filesystem. This
causes 'nblocks' to have a value of zero. ext4_bread_batch() ends up not
reading any of the directory file's blocks. This renders the entries in
bh_use[] array to continue to have garbage data. buffer_uptodate() on
bh_use[0] can then return a zero value upon which brelse() function is
invoked.

This commit fixes the bug by returning -ENOENT when the directory file
has no associated blocks.

Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org
2017-12-11 15:00:57 -05:00