Commit Graph

798285 Commits

Author SHA1 Message Date
Nick Desaulniers
ac3e233d29 x86/vdso: Drop implicit common-page-size linker flag
GNU linker's -z common-page-size's default value is based on the target
architecture. arch/x86/entry/vdso/Makefile sets it to the architecture
default, which is implicit and redundant. Drop it.

Fixes: 2aae950b21 ("x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu")
Reported-by: Dmitry Golovin <dima@golovin.in>
Reported-by: Bill Wendling <morbo@google.com>
Suggested-by: Dmitry Golovin <dima@golovin.in>
Suggested-by: Rui Ueyama <ruiu@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Andy Lutomirski <luto@kernel.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Fangrui Song <maskray@google.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20181206191231.192355-1-ndesaulniers@google.com
Link: https://bugs.llvm.org/show_bug.cgi?id=38774
Link: https://github.com/ClangBuiltLinux/linux/issues/31
2018-12-07 18:57:38 +01:00
Will Deacon
b4aecf7808 arm64: hibernate: Avoid sending cross-calling with interrupts disabled
Since commit 3b8c9f1cdf ("arm64: IPI each CPU after invalidating the
I-cache for kernel mappings"), a call to flush_icache_range() will use
an IPI to cross-call other online CPUs so that any stale instructions
are flushed from their pipelines. This triggers a WARN during the
hibernation resume path, where flush_icache_range() is called with
interrupts disabled and is therefore prone to deadlock:

  | Disabling non-boot CPUs ...
  | CPU1: shutdown
  | psci: CPU1 killed.
  | CPU2: shutdown
  | psci: CPU2 killed.
  | CPU3: shutdown
  | psci: CPU3 killed.
  | WARNING: CPU: 0 PID: 1 at ../kernel/smp.c:416 smp_call_function_many+0xd4/0x350
  | Modules linked in:
  | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc4 #1

Since all secondary CPUs have been taken offline prior to invalidating
the I-cache, there's actually no need for an IPI and we can simply call
__flush_icache_range() instead.

Cc: <stable@vger.kernel.org>
Fixes: 3b8c9f1cdf ("arm64: IPI each CPU after invalidating the I-cache for kernel mappings")
Reported-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Tested-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Tested-by: James Morse <james.morse@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2018-12-07 15:52:39 +00:00
Jens Axboe
8b878ee247 Merge branch 'nvme-4.20' of git://git.infradead.org/nvme into for-linus
Pull NVMe fixes from Christoph.

* 'nvme-4.20' of git://git.infradead.org/nvme:
  nvmet-rdma: fix response use after free
  nvme: validate controller state before rescheduling keep alive
2018-12-07 08:40:13 -07:00
Jens Axboe
c616cbee97 blk-mq: punt failed direct issue to dispatch list
After the direct dispatch corruption fix, we permanently disallow direct
dispatch of non read/write requests. This works fine off the normal IO
path, as they will be retried like any other failed direct dispatch
request. But for the blk_insert_cloned_request() that only DM uses to
bypass the bottom level scheduler, we always first attempt direct
dispatch. For some types of requests, that's now a permanent failure,
and no amount of retrying will make that succeed. This results in a
livelock.

Instead of making special cases for what we can direct issue, and now
having to deal with DM solving the livelock while still retaining a BUSY
condition feedback loop, always just add a request that has been through
->queue_rq() to the hardware queue dispatch list. These are safe to use
as no merging can take place there. Additionally, if requests do have
prepped data from drivers, we aren't dependent on them not sharing space
in the request structure to safely add them to the IO scheduler lists.

This basically reverts ffe81d4532 and is based on a patch from Ming,
but with the list insert case covered as well.

Fixes: ffe81d4532 ("blk-mq: fix corruption with direct issue")
Cc: stable@vger.kernel.org
Suggested-by: Ming Lei <ming.lei@redhat.com>
Reported-by: Bart Van Assche <bvanassche@acm.org>
Tested-by: Ming Lei <ming.lei@redhat.com>
Acked-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2018-12-07 08:16:11 -07:00
Israel Rukshin
d7dcdf9d4e nvmet-rdma: fix response use after free
nvmet_rdma_release_rsp() may free the response before using it at error
flow.

Fixes: 8407879 ("nvmet-rdma: fix possible bogus dereference under heavy load")
Signed-off-by: Israel Rukshin <israelr@mellanox.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Max Gurtovoy <maxg@mellanox.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
2018-12-07 07:11:11 -08:00
James Smart
86880d6461 nvme: validate controller state before rescheduling keep alive
Delete operations are seeing NULL pointer references in call_timer_fn.
Tracking these back, the timer appears to be the keep alive timer.

nvme_keep_alive_work() which is tied to the timer that is cancelled
by nvme_stop_keep_alive(), simply starts the keep alive io but doesn't
wait for it's completion. So nvme_stop_keep_alive() only stops a timer
when it's pending. When a keep alive is in flight, there is no timer
running and the nvme_stop_keep_alive() will have no affect on the keep
alive io. Thus, if the io completes successfully, the keep alive timer
will be rescheduled.   In the failure case, delete is called, the
controller state is changed, the nvme_stop_keep_alive() is called while
the io is outstanding, and the delete path continues on. The keep
alive happens to successfully complete before the delete paths mark it
as aborted as part of the queue termination, so the timer is restarted.
The delete paths then tear down the controller, and later on the timer
code fires and the timer entry is now corrupt.

Fix by validating the controller state before rescheduling the keep
alive. Testing with the fix has confirmed the condition above was hit.

Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Christoph Hellwig <hch@lst.de>
2018-12-07 07:11:11 -08:00
Paolo Valente
ba7aeae553 block, bfq: fix decrement of num_active_groups
Since commit '2d29c9f89fcd ("block, bfq: improve asymmetric scenarios
detection")', if there are process groups with I/O requests waiting for
completion, then BFQ tags the scenario as 'asymmetric'. This detection
is needed for preserving service guarantees (for details, see comments
on the computation * of the variable asymmetric_scenario in the
function bfq_better_to_idle).

Unfortunately, commit '2d29c9f89fcd ("block, bfq: improve asymmetric
scenarios detection")' contains an error exactly in the updating of
the number of groups with I/O requests waiting for completion: if a
group has more than one descendant process, then the above number of
groups, which is renamed from num_active_groups to a more appropriate
num_groups_with_pending_reqs by this commit, may happen to be wrongly
decremented multiple times, namely every time one of the descendant
processes gets all its pending I/O requests completed.

A correct, complete solution should work as follows. Consider a group
that is inactive, i.e., that has no descendant process with pending
I/O inside BFQ queues. Then suppose that num_groups_with_pending_reqs
is still accounting for this group, because the group still has some
descendant process with some I/O request still in
flight. num_groups_with_pending_reqs should be decremented when the
in-flight request of the last descendant process is finally completed
(assuming that nothing else has changed for the group in the meantime,
in terms of composition of the group and active/inactive state of
child groups and processes). To accomplish this, an additional
pending-request counter must be added to entities, and must be
updated correctly.

To avoid this additional field and operations, this commit resorts to
the following tradeoff between simplicity and accuracy: for an
inactive group that is still counted in num_groups_with_pending_reqs,
this commit decrements num_groups_with_pending_reqs when the first
descendant process of the group remains with no request waiting for
completion.

This simplified scheme provides a fix to the unbalanced decrements
introduced by 2d29c9f89f. Since this error was also caused by lack
of comments on this non-trivial issue, this commit also adds related
comments.

Fixes: 2d29c9f89f ("block, bfq: improve asymmetric scenarios detection")
Reported-by: Steven Barrett <steven@liquorix.net>
Tested-by: Steven Barrett <steven@liquorix.net>
Tested-by: Lucjan Lucjanov <lucjan.lucjanov@gmail.com>
Reviewed-by: Federico Motta <federico@willer.it>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2018-12-07 07:40:07 -07:00
Greg Kroah-Hartman
dbde117c31 GNSS fixes for 4.20-rc6
Here's a fix for a broken activation retry loop in the sirf driver.
 
 Included are also two MAINTAINERS updates.
 
 All have been in linux-next with no reported issues.
 
 Signed-off-by: Johan Hovold <johan@kernel.org>
 -----BEGIN PGP SIGNATURE-----
 
 iHUEABYIAB0WIQQHbPq+cpGvN/peuzMLxc3C7H1lCAUCXAptswAKCRALxc3C7H1l
 CPSwAQChmb2y7CwP5il1PxqTa98F9hRx4H3DBCyPvS4WT5U1MgEAlrx1fnuAPiS3
 97Q6+ZRCyy5rbyjPpzJ6NwTyt13c4w0=
 =oN0i
 -----END PGP SIGNATURE-----

Merge tag 'gnss-4.20-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/gnss into char-misc-linus

Johan writes:

GNSS fixes for 4.20-rc6

Here's a fix for a broken activation retry loop in the sirf driver.

Included are also two MAINTAINERS updates.

All have been in linux-next with no reported issues.

Signed-off-by: Johan Hovold <johan@kernel.org>

* tag 'gnss-4.20-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/gnss:
  MAINTAINERS: exclude gnss from SIRFPRIMA2 regex matching
  MAINTAINERS: add gnss scm tree
  gnss: sirf: fix activation retry handling
2018-12-07 14:05:28 +01:00
Long Li
6ac79291fb CIFS: Avoid returning EBUSY to upper layer VFS
EBUSY is not handled by VFS, and will be passed to user-mode. This is not
correct as we need to wait for more credits.

This patch also fixes a bug where rsize or wsize is used uninitialized when
the call to server->ops->wait_mtu_credits() fails.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Long Li <longli@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
2018-12-07 00:59:23 -06:00
Herbert Xu
e61efff4ae crypto: user - Disable statistics interface
Since this user-space API is still undergoing significant changes,
this patch disables it for the current merge window.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-12-07 13:56:08 +08:00
Linus Torvalds
d387ac13ad ast, msm display fixes, amdgpu fixes, lease fix, omap fixes
-----BEGIN PGP SIGNATURE-----
 
 iQIcBAABAgAGBQJcCc0fAAoJEAx081l5xIa+6X4P/1pTMY/XJob0UVrmygU+oZu8
 NIRO+axzV5EksEaWHCxVN5VtxaXpA1BMbFQeMpen2Vv2+Bts/YYP36Vm6okPK2Kh
 rBByQDdZvpaTovrypososqJ/BBD2ak6CGqiedbb35RKdetxYpVW+gFjEb9spNeOw
 fQAqSaP605sJg+YxVMIg8bEPP4hENSjx+CsmyjDcw3Q5CzeyYz3kFjZ9QKMtb8UK
 inCDc/A4phY9YiglKbdiMfJzJf8HN3ZYLwIOrXJqsmi4HTElyoWCXMMOZNMp4UVO
 c95+AGart+YIXRJ/mbO+l9fitvvaymHNRfTpyvgF7P/MjCrazul+rzhfpjP+hU8a
 oz/8XFUqVphBdWDLHo4FesqpGPMBuEWSs8143Ohz2lG3F/wZknrXkVWi9ojviZ1u
 ahUmaCi+OwyEMCZQNJVcgNdHZrSu06ZjOLyhfy0oab3mXyr03cS2BX4Gv5FslMjQ
 IQUntn9vPu7Po4nsENKV5uSoBozoLlKw4b+r3w2sQbJFLlUXavrsx5lSlTB9ELDF
 AHZsJ0NkLaXbY5It+atzmLLeHwdepYoM1Ocx3DKy9D2gqdaPXQdDTamvoLeq7dOg
 zmGh9wNJdtX3Y2/I/5YVeClpUhuR6vQtj1x2x7gDHE2rIs+IoGnfUBg2NW67HH4o
 JhF+LXQclvtsAzp3P86L
 =6wgz
 -----END PGP SIGNATURE-----

Merge tag 'drm-fixes-2018-12-07' of git://anongit.freedesktop.org/drm/drm

Pull drm fixes from Dave Airlie:
 "There's a bit more in here than I'd like, and I'm hoping things calm
  down when I'm out.

  msm:
   - a bunch of display fixes for the new DPU
   - a couple of command submission fixes

  omap:
   - some DSI fixes

  ast:
   - driver unload crash fix

  core:
   - fix the lease uevent so userspace can distinguish it

  amd:
   - fix a bpc regression
   - fix lru handling regression
   - fixed firmware support for new GPUs
   - power management fixes for vega20"

* tag 'drm-fixes-2018-12-07' of git://anongit.freedesktop.org/drm/drm: (37 commits)
  drm/ast: Fix connector leak during driver unload
  drm/amdgpu/vcn: Update vcn.cur_state during suspend
  drm/amd/display: Fix overflow/truncation from strncpy.
  drm/amd/powerplay: improve OD code robustness
  drm/amdgpu: enlarge maximum waiting time of KIQ
  drm/fb-helper: Fix typo in parameter description
  drm/amd/powerplay: support SoftMin/Max setting for some specific DPM
  drm/amd/powerplay: issue pre-display settings for display change event
  drm/amd/powerplay: support new pptable upload on Vega20
  drm/amdgpu/gmc8: always load MC firmware in the driver
  drm/amdgpu/gmc8: update MC firmware for polaris
  drm/amdgpu: update mc firmware image for polaris12 variants
  drm/msm: Fix error return checking
  drm/msm/dpu: Ignore alpha for XBGR8888 format
  drm/msm: dpu: Fix "WARNING: invalid free of devm_ allocated data"
  drm/msm/hdmi: Drop pointless static qualifier in msm_hdmi_bind()
  drm/msm: Move fence put to where failure occurs
  drm/msm: dpu: Don't set legacy plane->crtc pointer
  drm/msm/gpu: Don't map command buffers with nr_relocs equal to 0
  drm/msm/hdmi: Enable HPD after HDMI IRQ is set up
  ...
2018-12-06 19:35:50 -08:00
Linus Torvalds
7f80c7325b NFS client bugfixes for Linux 4.20
Highlights include:
 
 Stable fixes:
  - Fix a page leak when using RPCSEC_GSS/krb5p to encrypt data.
 
 Bugfixes:
  - Fix a regression that causes the RPC receive code to hang
  - Fix call_connect_status() so that it handles tasks that got transmitted
    while queued waiting for the socket lock.
  - Fix a memory leak in call_encode()
  - Fix several other connect races.
  - Fix receive code error handling.
  - Use the discard iterator rather than MSG_TRUNC for compatibility with
    AF_UNIX/AF_LOCAL sockets.
  - nfs: don't dirty kernel pages read by direct-io
  - pnfs/Flexfiles fix to enforce per-mirror stateid only for NFSv4 data
    servers
 -----BEGIN PGP SIGNATURE-----
 
 iQIcBAABAgAGBQJcCWIOAAoJEA4mA3inWBJc3BsP/i/VXd0ZSxxL8i/++qCR1KGT
 /p0+t2HbrhPzb3jKmuaBe/6T6bLMbpmkwbesA6cHENkaPiOqxPhxLsJlh4o2BHwg
 NcjAbbov/hkakFAHlp69KqiL7DZe8YEqQE8GlUnn+3C3RM3i2TSRQ3AGXUH22P2a
 MY5fqiub2PmEwe2UZR8BzIEQd5w60AzTNXzQb181/+SCTOPdJTKneh0Tw54lD4d6
 vWKhi64cyQxQxshCvrX6IpcNWu9qwm7qDGQ3rDAg0whunve4YGtTz1suRUk888M4
 VfNxA8skFZuaQS/UU6oek2xaeMlSzEoJQXimKLYTEJKoqf7sWxfNLAfqHwnfyo4T
 Yab3cfVRs5KgEltVZyodb9oVQd6KI13hYeT+vXubz2kq1Ode4NJCnzgEefOP0hNV
 ENDal0hqBrfjfVIkpg/wfgRJln/W4Y/U0oPPm50eJJxa0ZKTfftBWo4me5DwCFF9
 0/XhPdFWTvZsYjmSGRC1RsaSrzUvO+wFo3tKQ2lQqf8QP3ix9ZtGQHN+h8RN9SxK
 ti5OxTMsfM3jYg7+yu4yOAQkcCcoaDA37+JztpuUSlMRfNss8uM7cQKsQ4WQf6Nr
 24At5Wr/ib7hVkAQ5oB98UWh5q1ZLzmmHhzsf8KacTSNcfjgu0H0DmKtm3CfThFK
 xfTHotzM3IqbUXRZQ7++
 =M/mt
 -----END PGP SIGNATURE-----

Merge tag 'nfs-for-4.20-5' of git://git.linux-nfs.org/projects/trondmy/linux-nfs

Pull NFS client bugfixes from Trond Myklebust:
 "This is mainly fallout from the updates to the SUNRPC code that is
  being triggered from less common combinations of NFS mount options.

  Highlights include:

  Stable fixes:
   - Fix a page leak when using RPCSEC_GSS/krb5p to encrypt data.

  Bugfixes:
   - Fix a regression that causes the RPC receive code to hang
   - Fix call_connect_status() so that it handles tasks that got
     transmitted while queued waiting for the socket lock.
   - Fix a memory leak in call_encode()
   - Fix several other connect races.
   - Fix receive code error handling.
   - Use the discard iterator rather than MSG_TRUNC for compatibility
     with AF_UNIX/AF_LOCAL sockets.
   - nfs: don't dirty kernel pages read by direct-io
   - pnfs/Flexfiles fix to enforce per-mirror stateid only for NFSv4
     data servers"

* tag 'nfs-for-4.20-5' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
  SUNRPC: Don't force a redundant disconnection in xs_read_stream()
  SUNRPC: Fix up socket polling
  SUNRPC: Use the discard iterator rather than MSG_TRUNC
  SUNRPC: Treat EFAULT as a truncated message in xs_read_stream_request()
  SUNRPC: Fix up handling of the XDRBUF_SPARSE_PAGES flag
  SUNRPC: Fix RPC receive hangs
  SUNRPC: Fix a potential race in xprt_connect()
  SUNRPC: Fix a memory leak in call_encode()
  SUNRPC: Fix leak of krb5p encode pages
  SUNRPC: call_connect_status() must handle tasks that got transmitted
  nfs: don't dirty kernel pages read by direct-io
  flexfiles: enforce per-mirror stateid only for v4 DSes
2018-12-06 18:57:04 -08:00
Linus Torvalds
b72f711a4e Merge branch 'spectre' of git://git.armlinux.org.uk/~rmk/linux-arm
Pull ARM spectre fix from Russell King:
 "Exynos folk noticed that CPU hotplug wasn't working with their kernel
  configuration, and have tested this as fixing the problem"

* 'spectre' of git://git.armlinux.org.uk/~rmk/linux-arm:
  ARM: ensure that processor vtables is not lost after boot
2018-12-06 16:45:36 -08:00
Linus Torvalds
7e40b56c77 Merge branch 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm
Pull ARM fixes from Russell King:
 "Some small fixes that have been accumulated:

   - Chris Cole noticed that in a SMP environment, the DMA cache
     coherence handling can produce undesirable results in a corner
     case

   - Propagate that fix for ARMv7M as well

   - Fix a false positive with source fortification

   - Fix an uninitialised return that Nathan Jones spotted"

* 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm:
  ARM: 8816/1: dma-mapping: fix potential uninitialized return
  ARM: 8815/1: V7M: align v7m_dma_inv_range() with v7 counterpart
  ARM: 8814/1: mm: improve/fix ARM v7_dma_inv_range() unaligned address handling
  ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE
2018-12-06 16:39:44 -08:00
Masahiro Yamada
ece27a337d i2c: uniphier-f: fix violation of tLOW requirement for Fast-mode
Currently, the clock duty is set as tLOW/tHIGH = 1/1. For Fast-mode,
tLOW is set to 1.25 us while the I2C spec requires tLOW >= 1.3 us.

tLOW/tHIGH = 5/4 would meet both Standard-mode and Fast-mode:
  Standard-mode: tLOW = 5.56 us, tHIGH = 4.44 us
  Fast-mode:     tLOW = 1.39 us, tHIGH = 1.11 us

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2018-12-06 23:14:59 +01:00
Masahiro Yamada
8469636ab5 i2c: uniphier: fix violation of tLOW requirement for Fast-mode
Currently, the clock duty is set as tLOW/tHIGH = 1/1. For Fast-mode,
tLOW is set to 1.25 us while the I2C spec requires tLOW >= 1.3 us.

tLOW/tHIGH = 5/4 would meet both Standard-mode and Fast-mode:
  Standard-mode: tLOW = 5.56 us, tHIGH = 4.44 us
  Fast-mode:     tLOW = 1.39 us, tHIGH = 1.11 us

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2018-12-06 23:14:59 +01:00
Masahiro Yamada
cd8843f541 i2c: uniphier-f: fill TX-FIFO only in IRQ handler for repeated START
- For a repeated START condition, this controller starts data transfer
   immediately after the slave address is written to the TX-FIFO.

 - Once the TX-FIFO empty interrupt is asserted, the controller makes
   a pause even if additional data are written to the TX-FIFO.

Given those circumstances, the data after a repeated START may not be
transferred if the interrupt is asserted while the TX-FIFO is being
filled up. A more reliable way is to append TX data only in the
interrupt handler.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2018-12-06 23:14:59 +01:00
Masahiro Yamada
c2a653deaa i2c: uniphier-f: fix timeout error after reading 8 bytes
I was totally screwed up in commit eaba68785c ("i2c: uniphier-f:
fix race condition when IRQ is cleared"). Since that commit, if the
number of read bytes is multiple of the FIFO size (8, 16, 24... bytes),
the STOP condition could be issued twice, depending on the timing.
If this happens, the controller will go wrong, resulting in the timeout
error.

It was more than 3 years ago when I wrote this driver, so my memory
about this hardware was vague. Please let me correct the description
in the commit log of eaba68785c.

Clearing the IRQ status on exiting the IRQ handler is absolutely
fine. This controller makes a pause while any IRQ status is asserted.
If the IRQ status is cleared first, the hardware may start the next
transaction before the IRQ handler finishes what it supposed to do.

This partially reverts the bad commit with clear comments so that I
will never repeat this mistake.

I also investigated what is happening at the last moment of the read
mode. The UNIPHIER_FI2C_INT_RF interrupt is asserted a bit earlier
(by half a period of the clock cycle) than UNIPHIER_FI2C_INT_RB.

I consulted a hardware engineer, and I got the following information:

UNIPHIER_FI2C_INT_RF
    asserted at the falling edge of SCL at the 8th bit.

UNIPHIER_FI2C_INT_RB
    asserted at the rising edge of SCL at the 9th (ACK) bit.

In order to avoid calling uniphier_fi2c_stop() twice, check the latter
interrupt. I also commented this because it is obscure hardware internal.

Fixes: eaba68785c ("i2c: uniphier-f: fix race condition when IRQ is cleared")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2018-12-06 23:14:59 +01:00
Hans de Goede
0544ee4b1a i2c: scmi: Fix probe error on devices with an empty SMB0001 ACPI device node
Some AMD based HP laptops have a SMB0001 ACPI device node which does not
define any methods.

This leads to the following error in dmesg:

[    5.222731] cmi: probe of SMB0001:00 failed with error -5

This commit makes acpi_smbus_cmi_add() return -ENODEV instead in this case
silencing the error. In case of a failure of the i2c_add_adapter() call
this commit now propagates the error from that call instead of -EIO.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2018-12-06 23:14:59 +01:00
Adamski, Krzysztof (Nokia - PL/Wroclaw)
6c7f25cae5 i2c: axxia: properly handle master timeout
According to Intel (R) Axxia TM Lionfish Communication Processor
Peripheral Subsystem Hardware Reference Manual, the AXXIA I2C module
have a programmable Master Wait Timer, which among others, checks the
time between commands send in manual mode. When a timeout (25ms) passes,
TSS bit is set in Master Interrupt Status register and a Stop command is
issued by the hardware.

The axxia_i2c_xfer(), does not properly handle this situation, however.
For each message a separate axxia_i2c_xfer_msg() is called and this
function incorrectly assumes that any interrupt might happen only when
waiting for completion. This is mostly correct but there is one
exception - a master timeout can trigger if enough time has passed
between individual transfers. It will, by definition, happen between
transfers when the interrupts are disabled by the code. If that happens,
the hardware issues Stop command.

The interrupt indicating timeout will not be triggered as soon as we
enable them since the Master Interrupt Status is cleared when master
mode is entered again (which happens before enabling irqs) meaning this
error is lost and the transfer is continued even though the Stop was
issued on the bus. The subsequent operations completes without error but
a bogus value (0xFF in case of read) is read as the client device is
confused because aborted transfer. No error is returned from
master_xfer() making caller believe that a valid value was read.

To fix the problem, the TSS bit (indicating timeout) in Master Interrupt
Status register is checked before each transfer. If it is set, there was
a timeout before this transfer and (as described above) the hardware
already issued Stop command so the transaction should be aborted thus
-ETIMEOUT is returned from the master_xfer() callback. In order to be
sure no timeout was issued we can't just read the status just before
starting new transaction as there will always be a small window of time
(few CPU cycles at best) where this might still happen. For this reason
we have to temporally disable the timer before checking for TSS bit.
Disabling it will, however, clear the TSS bit so in order to preserve
that information, we have to read it in ISR so we have to ensure that
the TSS interrupt is not masked between transfers of one transaction.
There is no need to call bus recovery or controller reinitialization if
that happens so it's skipped.

Signed-off-by: Krzysztof Adamski <krzysztof.adamski@nokia.com>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2018-12-06 23:14:53 +01:00
David S. Miller
cd9d1a2332 Merge branch 'mlxsw-Various-fixes'
Ido Schimmel says:

====================
mlxsw: Various fixes

Patches #1 and #2 fix two VxLAN related issues. The first patch removes
warnings that can currently be triggered from user space. Second patch
avoids leaking a FID in an error path.

Patch #3 fixes a too strict check that causes certain host routes not to
be promoted to perform GRE decapsulation in hardware.

Last patch avoids a use-after-free when deleting a VLAN device via an
ioctl when it is enslaved to a bridge. I have a patchset for net-next
that reworks this code and makes the driver more robust.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
2018-12-06 13:31:09 -08:00
Ido Schimmel
993107fea5 mlxsw: spectrum_switchdev: Fix VLAN device deletion via ioctl
When deleting a VLAN device using an ioctl the netdev is unregistered
before the VLAN filter is updated via ndo_vlan_rx_kill_vid(). It can
lead to a use-after-free in mlxsw in case the VLAN device is deleted
while being enslaved to a bridge.

The reason for the above is that when mlxsw receives the CHANGEUPPER
event, it wrongly assumes that the VLAN device is no longer its upper
and thus destroys the internal representation of the bridge port despite
the reference count being non-zero.

Fix this by checking if the VLAN device is our upper using its real
device. In net-next I'm going to remove this trick and instead make
mlxsw completely agnostic to the order of the events.

Fixes: c57529e1d5 ("mlxsw: spectrum: Replace vPorts with Port-VLAN")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-12-06 13:31:09 -08:00
Nir Dotan
da93d2913f mlxsw: spectrum_router: Relax GRE decap matching check
GRE decap offload is configured when local routes prefix correspond to the
local address of one of the offloaded GRE tunnels. The matching check was
found to be too strict, such that for a flat GRE configuration, in which
the overlay and underlay traffic share the same non-default VRF, decap flow
was not offloaded.

Relax the check for decap flow offloading. A match occurs if the local
address of the tunnel matches the local route address while both share the
same VRF table.

Fixes: 4607f6d269 ("mlxsw: spectrum_router: Support IPv4 underlay decap")
Signed-off-by: Nir Dotan <nird@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-12-06 13:31:08 -08:00
Ido Schimmel
f58a83c207 mlxsw: spectrum_switchdev: Avoid leaking FID's reference count
It should never be possible for a user to set a VNI on a FID in case one
is already set. The driver therefore returns an error, but fails to drop
the reference count taken earlier when calling
mlxsw_sp_fid_8021d_lookup().

Drop the reference when this unlikely error is hit.

Fixes: 1c30d1836a ("mlxsw: spectrum: Enable VxLAN enslavement to bridges")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-12-06 13:31:08 -08:00
Ido Schimmel
050fc01fb1 mlxsw: spectrum_nve: Remove easily triggerable warnings
It is possible to trigger a warning in mlxsw in case a flood entry which
mlxsw is not aware of is deleted from the VxLAN device. This is because
mlxsw expects to find a singly linked list where the flood entry is
present in.

Fix by removing these warnings for now.

Will re-add them in the next release after we teach mlxsw to ask for a
dump of FDB entries from the VxLAN device, once it is enslaved to a
bridge mlxsw cares about.

Fixes: 6e6030bd54 ("mlxsw: spectrum_nve: Implement common NVE core")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-12-06 13:31:08 -08:00
Stefan Hajnoczi
834e772c8d vhost/vsock: fix use-after-free in network stack callers
If the network stack calls .send_pkt()/.cancel_pkt() during .release(),
a struct vhost_vsock use-after-free is possible.  This occurs because
.release() does not wait for other CPUs to stop using struct
vhost_vsock.

Switch to an RCU-enabled hashtable (indexed by guest CID) so that
.release() can wait for other CPUs by calling synchronize_rcu().  This
also eliminates vhost_vsock_lock acquisition in the data path so it
could have a positive effect on performance.

This is CVE-2018-14625 "kernel: use-after-free Read in vhost_transport_send_pkt".

Cc: stable@vger.kernel.org
Reported-and-tested-by: syzbot+bd391451452fb0b93039@syzkaller.appspotmail.com
Reported-by: syzbot+e3e074963495f92a89ed@syzkaller.appspotmail.com
Reported-by: syzbot+d5a0a170c5069658b141@syzkaller.appspotmail.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
2018-12-06 14:28:38 -05:00
Halil Pasic
78b1a52e05 virtio/s390: fix race in ccw_io_helper()
While ccw_io_helper() seems like intended to be exclusive in a sense that
it is supposed to facilitate I/O for at most one thread at any given
time, there is actually nothing ensuring that threads won't pile up at
vcdev->wait_q. If they do, all threads get woken up and see the status
that belongs to some other request than their own. This can lead to bugs.
For an example see:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1788432

This race normally does not cause any problems. The operations provided
by struct virtio_config_ops are usually invoked in a well defined
sequence, normally don't fail, and are normally used quite infrequent
too.

Yet, if some of the these operations are directly triggered via sysfs
attributes, like in the case described by the referenced bug, userspace
is given an opportunity to force races by increasing the frequency of the
given operations.

Let us fix the problem by ensuring, that for each device, we finish
processing the previous request before starting with a new one.

Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
Reported-by: Colin Ian King <colin.king@canonical.com>
Cc: stable@vger.kernel.org
Message-Id: <20180925121309.58524-3-pasic@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-12-06 14:22:35 -05:00
Halil Pasic
2448a299ec virtio/s390: avoid race on vcdev->config
Currently we have a race on vcdev->config in virtio_ccw_get_config() and
in virtio_ccw_set_config().

This normally does not cause problems, as these are usually infrequent
operations. However, for some devices writing to/reading from the config
space can be triggered through sysfs attributes. For these, userspace can
force the race by increasing the frequency.

Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
Cc: stable@vger.kernel.org
Message-Id: <20180925121309.58524-2-pasic@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-12-06 14:22:34 -05:00
Stefan Hajnoczi
c38f57da42 vhost/vsock: fix reset orphans race with close timeout
If a local process has closed a connected socket and hasn't received a
RST packet yet, then the socket remains in the table until a timeout
expires.

When a vhost_vsock instance is released with the timeout still pending,
the socket is never freed because vhost_vsock has already set the
SOCK_DONE flag.

Check if the close timer is pending and let it close the socket.  This
prevents the race which can leak sockets.

Reported-by: Maximilian Riemensberger <riemensberger@cadami.net>
Cc: Graham Whaley <graham.whaley@gmail.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-12-06 14:22:34 -05:00
Linus Torvalds
abb8d6ecbd This is a single commit that fixes a bug in uprobes SDT code
due to a missing mutex protection.
 -----BEGIN PGP SIGNATURE-----
 
 iIoEABYIADIWIQRRSw7ePDh/lE+zeZMp5XQQmuv6qgUCXAlffRQccm9zdGVkdEBn
 b29kbWlzLm9yZwAKCRAp5XQQmuv6qq0KAP0eIy6/kwoBocygRLgB6N4naX/zFcw4
 m2NiSlYe3NpC6AD/Z1g3wg8bKlm7ar2OzaqE4wQdeKjrvPlUtymUKiwFxA8=
 =8Huu
 -----END PGP SIGNATURE-----

Merge tag 'trace-v4.20-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace

Pull tracing fix from Steven Rostedt:
 "This is a single commit that fixes a bug in uprobes SDT code due to a
  missing mutex protection"

* tag 'trace-v4.20-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  Uprobes: Fix kernel oops with delayed_uprobe_remove()
2018-12-06 10:35:19 -08:00
Linus Torvalds
2acee31cce sound fixes for 4.20-rc6
Still more incoming fixes than wished at this stage, but all look like
 small and reasonable fixes.  In addition to the usual HD-audio and
 USB-audio quirks for various devices, two notable changes are
 included:
 - A fix for USB-audio UAF at probing a malformed descriptor
 - Workarounds for PCM rwsem mutex starvation
 -----BEGIN PGP SIGNATURE-----
 
 iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAlwI8PoOHHRpd2FpQHN1
 c2UuZGUACgkQLtJE4w1nLE8hDQ/9Gsuf0Um+OACXUV3a3sTQvhngNt60cv8LHgQT
 hVQnI0n/oCJ6/MoC32tsrqI8SwCZlHYl1DYlpYPHsIRYPL2bc8P1n0mLpBZyi9Xd
 flVeRZmVIC6mgouwVAsUPxID+iLspIsf+9nZbuq2wD+aCEtk0a3COXlcZ+k4cuiC
 aM/Bhdq+zTe9r6R8I86Q/u4aEdNa81LnLMPGW1u8I15IPKfYvp9ZZoFhmun8onvQ
 ZDvpXMyqRyODX24Nb60ngys1jtbq1WIEmyRqW2rd4fyZt3SIznTLj/ItBMyxWANb
 WcjHS0cNsOtw39Gjp3SGM16ljKPvAAO+DJVggyZbY9IuYoxh6J2mamGPpcVD+88m
 uUNHV1c0YZdj9/zxsb5yUi67UI4w8FM03tNP8jcOxtZBpG9NoFTk0aefr15/R9cZ
 X9Y8iWKWorfzXJ6E5XmOFxWH8MqDRhKBDLqITtSIaH6StwgF77krn8S7Xg/2JhW9
 bxjHQmbmDU/vBBgRjGaOnCdAusbRUey8c8t3znr9uCz2klaGRiYJPZZx20D2Xb5x
 YJWKhE2C0E1D5H7b6HC1xdaFV/nb1m2AYDDPvfv675C7T1I78h2GGhFc6slsBbw6
 Hnd74Eb6Lrqn3ITUKhBTA8wC3go9FR0EtnIVZE+mWhZ7IA69moN7JnYncHoTIWqx
 9A7bP08=
 =/PaM
 -----END PGP SIGNATURE-----

Merge tag 'sound-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "Still more incoming fixes than wished at this stage, but all look like
  small and reasonable fixes.

  In addition to the usual HD-audio and USB-audio quirks for various
  devices, two notable changes are included:

   - a fix for USB-audio UAF at probing a malformed descriptor

   - workarounds for PCM rwsem mutex starvation"

* tag 'sound-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4860G/Z6860G
  ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4660G
  ALSA: hda/realtek - Add support for Acer Aspire C24-860 headset mic
  ALSA: hda/realtek: ALC286 mic and headset-mode fixups for Acer Aspire U27-880
  ALSA: usb-audio: Fix UAF decrement if card has no live interfaces in card.c
  ALSA: hda/realtek - Fix speaker output regression on Thinkpad T570
  ALSA: pcm: Fix interval evaluation with openmin/max
  ALSA: hda: Add support for AMD Stoney Ridge
  ALSA: usb-audio: Add SMSL D1 to quirks for native DSD support
  ALSA: pcm: Fix starvation on down_write_nonblock()
  ALSA: pcm: Call snd_pcm_unlink() conditionally at closing
2018-12-06 09:25:53 -08:00
Linus Torvalds
002f421a84 C-SKY fixes/update for 4.20-rc6
- Bugfix tlb_get_pgd error.
 
  - Update MAINTAINERS file for C-SKY drivers.
 -----BEGIN PGP SIGNATURE-----
 
 iQJGBAABCAAwFiEE2KAv+isbWR/viAKHAXH1GYaIxXsFAlwIkagSHHJlbl9ndW9A
 Yy1za3kuY29tAAoJEAFx9RmGiMV7masP/RSILViW+HYKhl5peYuWr9cajNpLqwQt
 zCGHNkYTl/vObNq9HCKS9EfbB88k81SEEP4FOO/I83nTS0IuCWHvvLXyaPHqqMet
 6W0R7hlXUxllMESu02jiHLFF2UOoWqx6XJ5POh5b2/EyADVSYQ6SYeCjDJsWlxUL
 BUI7Po/H9D8c1/5vgMv3mROswmE/GsuRnea5y3mXSBWBQcxsp70rMcUKPIxge8E2
 uBVJp0naznp3Eupp68DkSgHI+6UbC7KSjLnqV7MOKvP/GR8CQ7MzGK75BAXaXhTD
 OReBz1EWc1RaE6wzCe/TyUx2nyqkpZsPjY9r+7ZbTIvyjCTw0OOlf+wiqoSfkWe+
 GDUMt71g6Fw5l9zqAwyPxew9lklmp/hWxMk3gy24yb22ptmIOojigTJsC7BHg456
 77bD+doV+0dN5VUJ3grKSOJ+b9REdOZVMLWjGw9fy1L+r/8+3GU5iKXZ9CJAop15
 s/EMiqZ9uEZp3ass9Y1okZMjpRL1Px6UVaXJtUs/LKaWxYnBWvA4Jj2N09d87Qmq
 32CItTt6W+PAHgQuNfStruiDoJ3COzxje4jA0LjUy4Km81njEfmyJdlId5BuNYeo
 0ug3a9QLMsSpuZjIC+HVzVUyqaFwDHHoEjpyXwLWOQ65CgeDv7K6m4AEF2nj+sui
 5dilmumX3Zfg
 =tE+D
 -----END PGP SIGNATURE-----

Merge tag 'csky-4.20-rc6' of github.com:c-sky/csky-linux

Pull C-SKY fixes from Guo Ren:

 - bugfix for tlb_get_pgd() error

 - update MAINTAINERS file for C-SKY drivers

* tag 'csky-4.20-rc6' of github.com:c-sky/csky-linux:
  csky: bugfix tlb_get_pgd error.
  MAINTAINERS: add maintainer for C-SKY drivers
2018-12-06 09:23:34 -08:00
Andy Shevchenko
ffe843b182 dmaengine: dw: Fix FIFO size for Intel Merrifield
Intel Merrifield has a reduced size of FIFO used in iDMA 32-bit controller,
i.e. 512 bytes instead of 1024.

Fix this by partitioning it as 64 bytes per channel.

Note, in the future we might switch to 'fifo-size' property instead of
hard coded value.

Fixes: 199244d694 ("dmaengine: dw: add support of iDMA 32-bit hardware")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
2018-12-06 22:53:05 +05:30
Alexander Popov
8fb2dfb228 stackleak: Register the 'stackleak_cleanup' pass before the '*free_cfg' pass
Currently the 'stackleak_cleanup' pass deleting a CALL insn is executed
after the 'reload' pass. That allows gcc to do some weird optimization in
function prologues and epilogues, which are generated later [1].

Let's avoid that by registering the 'stackleak_cleanup' pass before
the '*free_cfg' pass. It's the moment when the stack frame size is
already final, function prologues and epilogues are generated, and the
machine-dependent code transformations are not done.

[1] https://www.openwall.com/lists/kernel-hardening/2018/11/23/2

Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Alexander Popov <alex.popov@linux.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-12-06 09:10:23 -08:00
Greg Kroah-Hartman
3caad34eab USB-serial fix for v4.20-rc6
Here's a fix for a reported USB-console regression in 4.18 which
 revealed a long-standing bug in the console implementation.
 
 The patch has been in linux-next over night with no reported issues.
 
 Signed-off-by: Johan Hovold <johan@kernel.org>
 -----BEGIN PGP SIGNATURE-----
 
 iHUEABYIAB0WIQQHbPq+cpGvN/peuzMLxc3C7H1lCAUCXAlOXAAKCRALxc3C7H1l
 COC9AP4jozobKxNIgbmP6LAwz34Zv19qZyhi2hOzM0Less5o+QD+PLKS4yFPErNq
 L6jm+cb1RE3rW9bjrbphoT7PvQoa3QM=
 =QA9N
 -----END PGP SIGNATURE-----

Merge tag 'usb-serial-4.20-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus

Johan writes:

USB-serial fix for v4.20-rc6

Here's a fix for a reported USB-console regression in 4.18 which
revealed a long-standing bug in the console implementation.

The patch has been in linux-next over night with no reported issues.

Signed-off-by: Johan Hovold <johan@kernel.org>

* tag 'usb-serial-4.20-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial:
  USB: serial: console: fix reported terminal settings
2018-12-06 18:02:58 +01:00
Russell King
3a4d0c2172 ARM: ensure that processor vtables is not lost after boot
Marek Szyprowski reported problems with CPU hotplug in current kernels.
This was tracked down to the processor vtables being located in an
init section, and therefore discarded after kernel boot, despite being
required after boot to properly initialise the non-boot CPUs.

Arrange for these tables to end up in .rodata when required.

Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Krzysztof Kozlowski <krzk@kernel.org>
Fixes: 383fb3ee80 ("ARM: spectre-v2: per-CPU vtables to work around big.Little systems")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2018-12-06 16:42:05 +00:00
Johan Hovold
63cea1f735 MAINTAINERS: exclude gnss from SIRFPRIMA2 regex matching
Exclude the gnss subsystem from SIRMPRIMA2 regex matching, which would
otherwise match the unrelated gnss sirf driver.

Cc: Barry Song <baohua@kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
2018-12-06 17:22:58 +01:00
Johan Hovold
85280de450 MAINTAINERS: add gnss scm tree
Add SCM tree for the gnss subsystem.

Signed-off-by: Johan Hovold <johan@kernel.org>
2018-12-06 17:22:57 +01:00
Johan Hovold
06fd9ab12b gnss: sirf: fix activation retry handling
Fix activation helper which would return -ETIMEDOUT even if the last
retry attempt was successful.

Also change the semantics of the retries variable so that it actually
holds the number of retries (rather than tries).

Fixes: d2efbbd18b ("gnss: add driver for sirfstar-based receivers")
Cc: stable <stable@vger.kernel.org>	# 4.19
Signed-off-by: Johan Hovold <johan@kernel.org>
2018-12-06 17:22:23 +01:00
Guo Ren
b7d624ab43 asm-generic: unistd.h: fixup broken macro include.
The broken macros make the glibc compile error. If there is no
__NR3264_fstat*, we should also removed related definitions.

Reported-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Fixes: bf4b6a7d37 ("y2038: Remove stat64 family from default syscall set")
[arnd: Both Marcin and Guo provided this patch to fix up my clearly
       broken commit, I applied the version with the better changelog.]
Signed-off-by: Guo Ren <ren_guo@c-sky.com>
Signed-off-by: Mao Han <han_mao@c-sky.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-12-06 16:57:47 +01:00
Andrea Righi
a50480cb6d kprobes/x86: Blacklist non-attachable interrupt functions
These interrupt functions are already non-attachable by kprobes.
Blacklist them explicitly so that they can show up in
/sys/kernel/debug/kprobes/blacklist and tools like BCC can use this
additional information.

Signed-off-by: Andrea Righi <righi.andrea@gmail.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: David S. Miller <davem@davemloft.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yonghong Song <yhs@fb.com>
Link: http://lkml.kernel.org/r/20181206095648.GA8249@Dell
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-12-06 16:52:03 +01:00
Macpaul Lin
dada6a43b0 kgdboc: fix KASAN global-out-of-bounds bug in param_set_kgdboc_var()
This patch is trying to fix KE issue due to
"BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198"
reported by Syzkaller scan."

[26364:syz-executor0][name:report8t]BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198
[26364:syz-executor0][name:report&]Read of size 1 at addr ffffff900e44f95f by task syz-executor0/26364
[26364:syz-executor0][name:report&]
[26364:syz-executor0]CPU: 7 PID: 26364 Comm: syz-executor0 Tainted: G W 0
[26364:syz-executor0]Call trace:
[26364:syz-executor0][<ffffff9008095cf8>] dump_bacIctrace+Ox0/0x470
[26364:syz-executor0][<ffffff9008096de0>] show_stack+0x20/0x30
[26364:syz-executor0][<ffffff90089cc9c8>] dump_stack+Oxd8/0x128
[26364:syz-executor0][<ffffff90084edb38>] print_address_description +0x80/0x4a8
[26364:syz-executor0][<ffffff90084ee270>] kasan_report+Ox178/0x390
[26364:syz-executor0][<ffffff90084ee4a0>] _asan_report_loadi_noabort+Ox18/0x20
[26364:syz-executor0][<ffffff9008b092ac>] param_set_kgdboc_var+Ox194/0x198
[26364:syz-executor0][<ffffff900813af64>] param_attr_store+Ox14c/0x270
[26364:syz-executor0][<ffffff90081394c8>] module_attr_store+0x60/0x90
[26364:syz-executor0][<ffffff90086690c0>] sysfs_kl_write+Ox100/0x158
[26364:syz-executor0][<ffffff9008666d84>] kernfs_fop_write+0x27c/0x3a8
[26364:syz-executor0][<ffffff9008508264>] do_loop_readv_writev+0x114/0x1b0
[26364:syz-executor0][<ffffff9008509ac8>] do_readv_writev+0x4f8/0x5e0
[26364:syz-executor0][<ffffff9008509ce4>] vfs_writev+0x7c/Oxb8
[26364:syz-executor0][<ffffff900850ba64>] SyS_writev+Oxcc/0x208
[26364:syz-executor0][<ffffff90080883f0>] elO_svc_naked +0x24/0x28
[26364:syz-executor0][name:report&]
[26364:syz-executor0][name:report&]The buggy address belongs to the variable:
[26364:syz-executor0][name:report&] kgdb_tty_line+Ox3f/0x40
[26364:syz-executor0][name:report&]
[26364:syz-executor0][name:report&]Memory state around the buggy address:
[26364:syz-executor0] ffffff900e44f800: 00 00 00 00 00 04 fa fa fa fa fa fa 00 fa fa fa
[26364:syz-executor0] ffffff900e44f880: fa fa fa fa 00 fa fa fa fa fa fa fa 00 fa fa fa
[26364:syz-executor0]> ffffff900e44f900: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00
[26364:syz-executor0][name:report&]                                       ^
[26364:syz-executor0] ffffff900e44f980: 00 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa
[26364:syz-executor0] ffffff900e44fa00: 04 fa fa fa fa fa fa fa 00 fa fa fa fa fa fa fa
[26364:syz-executor0][name:report&]
[26364:syz-executor0][name:panic&]Disabling lock debugging due to kernel taint
[26364:syz-executor0]------------[cut here]------------

After checking the source code, we've found there might be an out-of-bounds
access to "config[len - 1]" array when the variable "len" is zero.

Signed-off-by: Macpaul Lin <macpaul@gmail.com>
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-06 15:59:07 +01:00
Mathias Nyman
0472bf06c6 xhci: Prevent U1/U2 link pm states if exit latency is too long
Don't allow USB3 U1 or U2 if the latency to wake up from the U-state
reaches the service interval for a periodic endpoint.

This is according to xhci 1.1 specification section 4.23.5.2 extra note:

"Software shall ensure that a device is prevented from entering a U-state
 where its worst case exit latency approaches the ESIT."

Allowing too long exit latencies for periodic endpoint confuses xHC
internal scheduling, and new devices may fail to enumerate with a
"Not enough bandwidth for new device state" error from the host.

Cc: <stable@vger.kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-06 13:00:10 +01:00
Sandeep Singh
a7d57abcc8 xhci: workaround CSS timeout on AMD SNPS 3.0 xHC
Occasionally AMD SNPS 3.0 xHC does not respond to
CSS when set, also it does not flag anything on SRE and HCE
to point the internal xHC errors on USBSTS register. This stalls
the entire system wide suspend and there is no point in stalling
just because of xHC CSS is not responding.

To work around this problem, if the xHC does not flag
anything on SRE and HCE, we can skip the CSS
timeout and allow the system to continue the suspend. Once the
system resume happens we can internally reset the controller
using XHCI_RESET_ON_RESUME quirk

Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Signed-off-by: Sandeep Singh <Sandeep.Singh@amd.com>
cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com>
Cc: <stable@vger.kernel.org>
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-06 13:00:10 +01:00
Paulo Alcantara
c988de29ca cifs: Fix separator when building path from dentry
Make sure to use the CIFS_DIR_SEP(cifs_sb) as path separator for
prefixpath too. Fixes a bug with smb1 UNIX extensions.

Fixes: a6b5058faf ("fs/cifs: make share unaccessible at root level mountable")
Signed-off-by: Paulo Alcantara <palcantara@suse.com>
Reviewed-by: Aurelien Aptel <aaptel@suse.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
CC: Stable <stable@vger.kernel.org>
2018-12-06 02:20:17 -06:00
Steve French
6e785302da cifs: In Kconfig CONFIG_CIFS_POSIX needs depends on legacy (insecure cifs)
Missing a dependency.  Shouldn't show cifs posix extensions
in Kconfig if CONFIG_CIFS_ALLOW_INSECURE_DIALECTS (ie SMB1
protocol) is disabled.

Signed-off-by: Steve French <stfrench@microsoft.com>
Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
2018-12-06 02:20:14 -06:00
Jiri Wiesner
ebaf39e603 ipv4: ipv6: netfilter: Adjust the frag mem limit when truesize changes
The *_frag_reasm() functions are susceptible to miscalculating the byte
count of packet fragments in case the truesize of a head buffer changes.
The truesize member may be changed by the call to skb_unclone(), leaving
the fragment memory limit counter unbalanced even if all fragments are
processed. This miscalculation goes unnoticed as long as the network
namespace which holds the counter is not destroyed.

Should an attempt be made to destroy a network namespace that holds an
unbalanced fragment memory limit counter the cleanup of the namespace
never finishes. The thread handling the cleanup gets stuck in
inet_frags_exit_net() waiting for the percpu counter to reach zero. The
thread is usually in running state with a stacktrace similar to:

 PID: 1073   TASK: ffff880626711440  CPU: 1   COMMAND: "kworker/u48:4"
  #5 [ffff880621563d48] _raw_spin_lock at ffffffff815f5480
  #6 [ffff880621563d48] inet_evict_bucket at ffffffff8158020b
  #7 [ffff880621563d80] inet_frags_exit_net at ffffffff8158051c
  #8 [ffff880621563db0] ops_exit_list at ffffffff814f5856
  #9 [ffff880621563dd8] cleanup_net at ffffffff814f67c0
 #10 [ffff880621563e38] process_one_work at ffffffff81096f14

It is not possible to create new network namespaces, and processes
that call unshare() end up being stuck in uninterruptible sleep state
waiting to acquire the net_mutex.

The bug was observed in the IPv6 netfilter code by Per Sundstrom.
I thank him for his analysis of the problem. The parts of this patch
that apply to IPv4 and IPv6 fragment reassembly are preemptive measures.

Signed-off-by: Jiri Wiesner <jwiesner@suse.com>
Reported-by: Per Sundstrom <per.sundstrom@redqube.se>
Acked-by: Peter Oskolkov <posk@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-12-05 20:44:46 -08:00
Jakub Audykowicz
afd0a8006e sctp: frag_point sanity check
If for some reason an association's fragmentation point is zero,
sctp_datamsg_from_user will try to endlessly try to divide a message
into zero-sized chunks. This eventually causes kernel panic due to
running out of memory.

Although this situation is quite unlikely, it has occurred before as
reported. I propose to add this simple last-ditch sanity check due to
the severity of the potential consequences.

Signed-off-by: Jakub Audykowicz <jakub.audykowicz@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-12-05 20:37:52 -08:00
Sam Bobroff
e594a5e349 drm/ast: Fix connector leak during driver unload
When unloading the ast driver, a warning message is printed by
drm_mode_config_cleanup() because a reference is still held to one of
the drm_connector structs.

Correct this by calling drm_crtc_force_disable_all() in
ast_fbdev_destroy().

Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1e613f3c630c7bbc72e04a44b178259b9164d2f6.1543798395.git.sbobroff@linux.ibm.com
2018-12-06 14:12:02 +10:00
Dave Airlie
6ccd895e41 UAPI:
- Distinguish lease events from hotplug (Daniel)
 
 Other:
 - omap: Restore panel-dpi bus flags (Tomi)
 - omap: Fix a couple of dsi issues (Sebastian)
 
 Cc: Sebastian Reichel <sebastian.reichel@collabora.com>
 Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
 Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
 -----BEGIN PGP SIGNATURE-----
 
 iQEzBAABCgAdFiEEfxcpfMSgdnQMs+QqlvcN/ahKBwoFAlwIMQ4ACgkQlvcN/ahK
 BwphDwf/a4gL0Dfw/QiCt2RndGtFsVVJPeByZXKv2puQAM/2f66PrtxRkmqulSyW
 gUTBuyUSgMjNKXY5bhRDDfxKP2tshKjzGfFvd+j7U4X4reGAK7lksV0m2+S9xp1M
 GP+RiUKCXySbMyjLM4VwvvYWYDU0xRo+YUhwkWuhJqgra223HfoO5BSBLQwQvVss
 4CCMyEL/gN0axasj82hu+9g0pIIrWeP9sAUIkX+jnSJRp3J6ZixH904EKbf1wNqZ
 EEwnQ7t8x0OSYFHY+Q3YIS35f+NskpkDrCjYX0Tq0TVZih1CU4Bx21e6Epk2BZeR
 NDTjFv2ERUYv5n1DF4alMSbFFiuotg==
 =W8Lu
 -----END PGP SIGNATURE-----

Merge tag 'drm-misc-fixes-2018-12-05' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes

UAPI:
- Distinguish lease events from hotplug (Daniel)

Other:
- omap: Restore panel-dpi bus flags (Tomi)
- omap: Fix a couple of dsi issues (Sebastian)

Cc: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20181205201428.GA35447@art_vandelay
2018-12-06 14:09:57 +10:00