Linus Torvalds [Sun, 9 Dec 2018 18:18:24 +0000 (10:18 -0800)]
Merge tag 'usb-4.20-rc6' of git://git./linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are some small USB fixes for 4.20-rc6
The "largest" here are some xhci fixes for reported issues. Also here
is a USB core fix, some quirk additions, and a usb-serial fix which
required the export of one of the tty layer's functions to prevent
code duplication. The tty maintainer agreed with this change.
All of these have been in linux-next with no reported issues"
* tag 'usb-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
xhci: Prevent U1/U2 link pm states if exit latency is too long
xhci: workaround CSS timeout on AMD SNPS 3.0 xHC
USB: check usb_get_extra_descriptor for proper size
USB: serial: console: fix reported terminal settings
usb: quirk: add no-LPM quirk on SanDisk Ultra Flair device
USB: Fix invalid-free bug in port_over_current_notify()
usb: appledisplay: Add 27" Apple Cinema Display
Linus Torvalds [Sun, 9 Dec 2018 18:15:13 +0000 (10:15 -0800)]
Merge tag '4.20-rc5-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6
Pull cifs fixes from Steve French:
"Three small fixes: a fix for smb3 direct i/o, a fix for CIFS DFS for
stable and a minor cifs Kconfig fix"
* tag '4.20-rc5-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6:
CIFS: Avoid returning EBUSY to upper layer VFS
cifs: Fix separator when building path from dentry
cifs: In Kconfig CONFIG_CIFS_POSIX needs depends on legacy (insecure cifs)
Linus Torvalds [Sun, 9 Dec 2018 17:54:04 +0000 (09:54 -0800)]
Merge tag 'dax-fixes-4.20-rc6' of git://git./linux/kernel/git/nvdimm/nvdimm
Pull dax fixes from Dan Williams:
"The last of the known regression fixes and fallout from the Xarray
conversion of the filesystem-dax implementation.
On the path to debugging why the dax memory-failure injection test
started failing after the Xarray conversion a couple more fixes for
the dax_lock_mapping_entry(), now called dax_lock_page(), surfaced.
Those plus the bug that started the hunt are now addressed. These
patches have appeared in a -next release with no issues reported.
Note the touches to mm/memory-failure.c are just the conversion to the
new function signature for dax_lock_page().
Summary:
- Fix the Xarray conversion of fsdax to properly handle
dax_lock_mapping_entry() in the presense of pmd entries
- Fix inode destruction racing a new lock request"
* tag 'dax-fixes-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
dax: Fix unlock mismatch with updated API
dax: Don't access a freed inode
dax: Check page->mapping isn't NULL
Linus Torvalds [Sun, 9 Dec 2018 17:46:54 +0000 (09:46 -0800)]
Merge tag 'libnvdimm-fixes-4.20-rc6' of git://git./linux/kernel/git/nvdimm/nvdimm
Pull libnvdimm fixes from Dan Williams:
"A regression fix for the Address Range Scrub implementation, yes
another one, and support for platforms that misalign persistent memory
relative to the Linux memory hotplug section constraint. Longer term,
support for sub-section memory hotplug would alleviate alignment
waste, but until then this hack allows a 'struct page' memmap to be
established for these misaligned memory regions.
These have all appeared in a -next release, and thanks to Patrick for
reporting and testing the alignment padding fix.
Summary:
- Unless and until the core mm handles memory hotplug units smaller
than a section (128M), persistent memory namespaces must be padded
to section alignment.
The libnvdimm core already handled section collision with "System
RAM", but some configurations overlap independent "Persistent
Memory" ranges within a section, so additional padding injection is
added for that case.
- The recent reworks of the ARS (address range scrub) state machine
to reduce the number of state flags inadvertantly missed a
conversion of acpi_nfit_ars_rescan() call sites. Fix the regression
whereby user-requested ARS results in a "short" scrub rather than a
"long" scrub.
- Fixup the unit tests to handle / test the 128M section alignment of
mocked test resources.
* tag 'libnvdimm-fixes-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
acpi/nfit: Fix user-initiated ARS to be "ARS-long" rather than "ARS-short"
libnvdimm, pfn: Pad pfn namespaces relative to other regions
tools/testing/nvdimm: Align test resources to 128M
Linus Torvalds [Sun, 9 Dec 2018 01:45:20 +0000 (17:45 -0800)]
Merge branch 'fixes' of git://git./linux/kernel/git/evalenti/linux-soc-thermal
Pull thermal SoC fixes from Eduardo Valentin:
"Fixes for armada and broadcom thermal drivers"
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal:
thermal: broadcom: constify thermal_zone_of_device_ops structure
thermal: armada: constify thermal_zone_of_device_ops structure
thermal: bcm2835: Switch to SPDX identifier
thermal: armada: fix legacy resource fixup
thermal: armada: fix legacy validity test sense
Linus Torvalds [Sat, 8 Dec 2018 19:44:04 +0000 (11:44 -0800)]
Merge tag 'asm-generic-4.20' of git://git./linux/kernel/git/arnd/asm-generic
Pull asm-generic fix from Arnd Bergmann:
"Multiple people reported a bug I introduced in asm-generic/unistd.h in
4.20, this is the obvious bugfix to get glibc and others to correctly
build again on new architectures that no longer provide the old
fstatat64() family of system calls"
* tag 'asm-generic-4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic:
asm-generic: unistd.h: fixup broken macro include.
Linus Torvalds [Sat, 8 Dec 2018 19:33:26 +0000 (11:33 -0800)]
Merge tag 'clk-fixes-for-linus' of git://git./linux/kernel/git/clk/linux
Pull clk fixes from Stephen Boyd:
"A few clk driver fixes this time:
- Introduce protected-clock DT binding to fix breakage on qcom
sdm845-mtp boards where the qspi clks introduced this merge window
cause the firmware on those boards to take down the system if we
try to read the clk registers
- Fix a couple off-by-one errors found by Dan Carpenter
- Handle failure in zynq fixed factor clk driver to avoid using
uninitialized data"
* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
clk: zynqmp: Off by one in zynqmp_is_valid_clock()
clk: mmp: Off by one in mmp_clk_add()
clk: mvebu: Off by one bugs in cp110_of_clk_get()
arm64: dts: qcom: sdm845-mtp: Mark protected gcc clocks
clk: qcom: Support 'protected-clocks' property
dt-bindings: clk: Introduce 'protected-clocks' property
clk: zynqmp: handle fixed factor param query error
Linus Torvalds [Sat, 8 Dec 2018 19:25:02 +0000 (11:25 -0800)]
Merge tag 'xfs-4.20-fixes-3' of git://git./fs/xfs/xfs-linux
Pull xfs fixes from Darrick Wong:
"Here are hopefully the last set of fixes for 4.20.
There's a fix for a longstanding statfs reporting problem with project
quotas, a correction for page cache invalidation behaviors when
fallocating near EOF, and a fix for a broken metadata verifier return
code.
Finally, the most important fix is to the pipe splicing code (aka the
generic copy_file_range fallback) to avoid pointless short directio
reads by only asking the filesystem for as much data as there are
available pages in the pipe buffer. Our previous fix (simulated short
directio reads because the number of pages didn't match the length of
the read requested) caused subtle problems on overlayfs, so that part
is reverted.
Anyhow, this series passes fstests -g all on xfs and overlay+xfs, and
has passed 17 billion fsx operations problem-free since I started
testing
Summary:
- Fix broken project quota inode counts
- Fix incorrect PAGE_MASK/PAGE_SIZE usage
- Fix incorrect return value in btree verifier
- Fix WARN_ON remap flags false positive
- Fix splice read overflows"
* tag 'xfs-4.20-fixes-3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
iomap: partially revert
4721a601099 (simulated directio short read on EFAULT)
splice: don't read more than available pipe space
vfs: allow some remap flags to be passed to vfs_clone_file_range
xfs: fix inverted return from xfs_btree_sblock_verify_crc
xfs: fix PAGE_MASK usage in xfs_free_file_space
fs/xfs: fix f_ffree value for statfs when project quota is set
David Rientjes [Fri, 7 Dec 2018 22:50:16 +0000 (14:50 -0800)]
Revert "mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmask"
This reverts commit
89c83fb539f95491be80cdd5158e6f0ce329e317.
This should have been done as part of
2f0799a0ffc0 ("mm, thp: restore
node-local hugepage allocations"). The movement of the thp allocation
policy from alloc_pages_vma() to alloc_hugepage_direct_gfpmask() was
intended to only set __GFP_THISNODE for mempolicies that are not
MPOL_BIND whereas the revert could set this regardless of mempolicy.
While the check for MPOL_BIND between alloc_hugepage_direct_gfpmask()
and alloc_pages_vma() was racy, that has since been removed since the
revert. What is left is the possibility to use __GFP_THISNODE in
policy_node() when it is unexpected because the special handling for
hugepages in alloc_pages_vma() was removed as part of the consolidation.
Secondly, prior to
89c83fb539f9, alloc_pages_vma() implemented a somewhat
different policy for hugepage allocations, which were allocated through
alloc_hugepage_vma(). For hugepage allocations, if the allocating
process's node is in the set of allowed nodes, allocate with
__GFP_THISNODE for that node (for MPOL_PREFERRED, use that node with
__GFP_THISNODE instead). This was changed for shmem_alloc_hugepage() to
allow fallback to other nodes in
89c83fb539f9 as it did for new_page() in
mm/mempolicy.c which is functionally different behavior and removes the
requirement to only allocate hugepages locally.
So this commit does a full revert of
89c83fb539f9 instead of the partial
revert that was done in
2f0799a0ffc0. The result is the same thp
allocation policy for 4.20 that was in 4.19.
Fixes:
89c83fb539f9 ("mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmask")
Fixes:
2f0799a0ffc0 ("mm, thp: restore node-local hugepage allocations")
Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Fri, 7 Dec 2018 22:34:10 +0000 (14:34 -0800)]
Merge tag 'for_linus' of git://git./linux/kernel/git/mst/vhost
Pull vhost/virtio fixes from Michael Tsirkin:
"A couple of last-minute fixes"
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
vhost/vsock: fix use-after-free in network stack callers
virtio/s390: fix race in ccw_io_helper()
virtio/s390: avoid race on vcdev->config
vhost/vsock: fix reset orphans race with close timeout
Linus Torvalds [Fri, 7 Dec 2018 22:18:49 +0000 (14:18 -0800)]
Merge tag 'arm64-fixes' of git://git./linux/kernel/git/arm64/linux
Pull arm64 fix from Catalin Marinas:
"Avoid sending IPIs with interrupts disabled"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: hibernate: Avoid sending cross-calling with interrupts disabled
Linus Torvalds [Fri, 7 Dec 2018 21:13:07 +0000 (13:13 -0800)]
Merge tag 'gcc-plugins-v4.20-rc6' of git://git./linux/kernel/git/kees/linux
Pull gcc stackleak plugin fixes from Kees Cook:
- Remove tracing for inserted stack depth marking function (Anders
Roxell)
- Move gcc-plugin pass location to avoid objtool warnings (Alexander
Popov)
* tag 'gcc-plugins-v4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
stackleak: Register the 'stackleak_cleanup' pass before the '*free_cfg' pass
stackleak: Mark stackleak_track_stack() as notrace
Linus Torvalds [Fri, 7 Dec 2018 21:07:10 +0000 (13:07 -0800)]
Merge branch 'linus' of git://git./linux/kernel/git/herbert/crypto-2.6
Pull crypto fixes from Herbert Xu:
- Disable the new crypto stats interface as it's still being changed
- Fix potential uses-after-free in cbc/cfb/pcbc.
* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: user - Disable statistics interface
crypto: do not free algorithm before using
Linus Torvalds [Fri, 7 Dec 2018 20:58:34 +0000 (12:58 -0800)]
Merge tag 'pci-v4.20-fixes-3' of git://git./linux/kernel/git/helgaas/pci
Pull PCI fixes from Bjorn Helgaas:
"Revert ASPM change that caused a regression"
* tag 'pci-v4.20-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
Revert "PCI/ASPM: Do not initialize link state when aspm_disabled is set"
Linus Torvalds [Fri, 7 Dec 2018 18:40:37 +0000 (10:40 -0800)]
Merge tag 'for-linus-
20181207' of git://git.kernel.dk/linux-block
Pull block fixes from Jens Axboe:
"Let's try this again...
We're finally happy with the DM livelock issue, and it's also passed
overnight testing and the corruption regression test. The end result
is much nicer now too, which is great.
Outside of that fix, there's a pull request for NVMe with two small
fixes, and a regression fix for BFQ from this merge window. The BFQ
fix looks bigger than it is, it's 90% comment updates"
* tag 'for-linus-
20181207' of git://git.kernel.dk/linux-block:
blk-mq: punt failed direct issue to dispatch list
nvmet-rdma: fix response use after free
nvme: validate controller state before rescheduling keep alive
block, bfq: fix decrement of num_active_groups
Linus Torvalds [Fri, 7 Dec 2018 18:31:31 +0000 (10:31 -0800)]
Merge branch 'i2c/for-current-fixed' of git://git./linux/kernel/git/wsa/linux
Pull i2c fixes from Wolfram Sang:
"A set of driver bugfixes for the I2C subsystem"
* 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: uniphier-f: fix violation of tLOW requirement for Fast-mode
i2c: uniphier: fix violation of tLOW requirement for Fast-mode
i2c: uniphier-f: fill TX-FIFO only in IRQ handler for repeated START
i2c: uniphier-f: fix timeout error after reading 8 bytes
i2c: scmi: Fix probe error on devices with an empty SMB0001 ACPI device node
i2c: axxia: properly handle master timeout
i2c: rcar: check bus state before reinitializing
i2c: nvidia-gpu: limit reads also for combined messages
i2c: nvidia-gpu: adhere to I2C fault codes
Linus Torvalds [Fri, 7 Dec 2018 17:58:34 +0000 (09:58 -0800)]
Merge tag 'dmaengine-fix-4.20-rc6' of git://git.infradead.org/users/vkoul/slave-dma
Pull dmaengine fixes from Vinod Koul:
"Another pull request for dmaengine. We got bunch of fixes early this
week and all are tagged to stable. Hope this is last fix for this
cycle:
- Fix imx-sdma handling of channel terminations, this involves
reverting two commits and implement async termination
- Fix cppi dma channel deletion from pending list on stop
- Fix FIFO size for dw controller in Intel Merrifield"
* tag 'dmaengine-fix-4.20-rc6' of git://git.infradead.org/users/vkoul/slave-dma:
dmaengine: dw: Fix FIFO size for Intel Merrifield
dmaengine: cppi41: delete channel from pending list when stop channel
dmaengine: imx-sdma: use GFP_NOWAIT for dma descriptor allocations
dmaengine: imx-sdma: implement channel termination via worker
Revert "dmaengine: imx-sdma: alloclate bd memory from dma pool"
Revert "dmaengine: imx-sdma: Use GFP_NOWAIT for dma allocations"
Will Deacon [Fri, 7 Dec 2018 12:47:10 +0000 (12:47 +0000)]
arm64: hibernate: Avoid sending cross-calling with interrupts disabled
Since commit
3b8c9f1cdfc50 ("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:
3b8c9f1cdfc50 ("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>
Jens Axboe [Fri, 7 Dec 2018 15:40:13 +0000 (08:40 -0700)]
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
Jens Axboe [Fri, 7 Dec 2018 05:17:44 +0000 (22:17 -0700)]
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
ffe81d45322c and is based on a patch from Ming,
but with the list insert case covered as well.
Fixes:
ffe81d45322c ("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>
Israel Rukshin [Wed, 5 Dec 2018 16:54:57 +0000 (16:54 +0000)]
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>
James Smart [Wed, 28 Nov 2018 01:04:44 +0000 (17:04 -0800)]
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>
Paolo Valente [Thu, 6 Dec 2018 18:18:18 +0000 (19:18 +0100)]
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
2d29c9f89fcd. Since this error was also caused by lack
of comments on this non-trivial issue, this commit also adds related
comments.
Fixes:
2d29c9f89fcd ("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>
Long Li [Thu, 6 Dec 2018 04:51:06 +0000 (04:51 +0000)]
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>
Herbert Xu [Fri, 7 Dec 2018 05:56:08 +0000 (13:56 +0800)]
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>
Linus Torvalds [Fri, 7 Dec 2018 03:35:50 +0000 (19:35 -0800)]
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
...
Linus Torvalds [Fri, 7 Dec 2018 02:57:04 +0000 (18:57 -0800)]
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
Linus Torvalds [Fri, 7 Dec 2018 00:45:36 +0000 (16:45 -0800)]
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
Linus Torvalds [Fri, 7 Dec 2018 00:39:44 +0000 (16:39 -0800)]
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
Masahiro Yamada [Thu, 6 Dec 2018 03:55:28 +0000 (12:55 +0900)]
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>
Masahiro Yamada [Thu, 6 Dec 2018 03:55:27 +0000 (12:55 +0900)]
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>
Masahiro Yamada [Thu, 6 Dec 2018 03:55:26 +0000 (12:55 +0900)]
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>
Masahiro Yamada [Thu, 6 Dec 2018 03:55:25 +0000 (12:55 +0900)]
i2c: uniphier-f: fix timeout error after reading 8 bytes
I was totally screwed up in commit
eaba68785c2d ("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
eaba68785c2d.
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:
eaba68785c2d ("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>
Hans de Goede [Wed, 21 Nov 2018 09:19:55 +0000 (10:19 +0100)]
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>
Adamski, Krzysztof (Nokia - PL/Wroclaw) [Fri, 16 Nov 2018 13:24:41 +0000 (13:24 +0000)]
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>
Stefan Hajnoczi [Mon, 5 Nov 2018 10:35:47 +0000 (10:35 +0000)]
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>
Halil Pasic [Wed, 26 Sep 2018 16:48:30 +0000 (18:48 +0200)]
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>
Halil Pasic [Wed, 26 Sep 2018 16:48:29 +0000 (18:48 +0200)]
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>
Stefan Hajnoczi [Thu, 6 Dec 2018 19:14:34 +0000 (19:14 +0000)]
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>
Linus Torvalds [Thu, 6 Dec 2018 18:35:19 +0000 (10:35 -0800)]
Merge tag 'trace-v4.20-rc5' of git://git./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()
Linus Torvalds [Thu, 6 Dec 2018 17:25:53 +0000 (09:25 -0800)]
Merge tag 'sound-4.20-rc6' of git://git./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
Linus Torvalds [Thu, 6 Dec 2018 17:23:34 +0000 (09:23 -0800)]
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
Andy Shevchenko [Wed, 5 Dec 2018 16:33:59 +0000 (18:33 +0200)]
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:
199244d69458 ("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>
Alexander Popov [Thu, 6 Dec 2018 15:13:07 +0000 (18:13 +0300)]
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>
Greg Kroah-Hartman [Thu, 6 Dec 2018 17:02:58 +0000 (18:02 +0100)]
Merge tag 'usb-serial-4.20-rc6' of https://git./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
Russell King [Thu, 6 Dec 2018 16:36:38 +0000 (16:36 +0000)]
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:
383fb3ee8024 ("ARM: spectre-v2: per-CPU vtables to work around big.Little systems")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Guo Ren [Thu, 6 Dec 2018 02:07:40 +0000 (10:07 +0800)]
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:
bf4b6a7d371e ("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>
Mathias Nyman [Wed, 5 Dec 2018 12:22:39 +0000 (14:22 +0200)]
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>
Sandeep Singh [Wed, 5 Dec 2018 12:22:38 +0000 (14:22 +0200)]
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>
Paulo Alcantara [Thu, 15 Nov 2018 14:20:52 +0000 (15:20 +0100)]
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:
a6b5058fafdf ("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>
Steve French [Sat, 3 Nov 2018 20:02:44 +0000 (15:02 -0500)]
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>
Sam Bobroff [Mon, 3 Dec 2018 00:53:21 +0000 (11:53 +1100)]
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
Dave Airlie [Thu, 6 Dec 2018 04:09:53 +0000 (14:09 +1000)]
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
Dave Airlie [Thu, 6 Dec 2018 04:08:43 +0000 (14:08 +1000)]
Merge branch 'drm-fixes-4.20' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
Fixes for 4.20:
- Fix banding regression on 6 bpc panels
- Vega20 fix for six 4k displays
- Fix LRU handling in ttm_buffer_object_transfer
- Use proper MC firmware for newer polaris variants
- Vega20 powerplay fixes
- VCN suspend/resume fix for PCO
- Misc other fixes
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181205192934.2857-1-alexander.deucher@amd.com
Dave Airlie [Thu, 6 Dec 2018 04:07:26 +0000 (14:07 +1000)]
Merge tag 'msm-fixes-2018-12-04' of https://gitlab.freedesktop.org/seanpaul/dpu-staging into drm-fixes
- Several related to incorrect error checking/handling (Various)
- Prevent IRQ storm on MDP5 HDMI hotplug (Todor)
- Don't capture crash state if unsupported (Sharat)
- Properly grab vblank reference in atomic wait for commit done (Sean)
Cc: Sharat Masetty <smasetty@codeaurora.org>
Cc: Todor Tomov <todor.tomov@linaro.org>
Cc: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20181205194207.GY154160@art_vandelay
Ravi Bangoria [Wed, 5 Dec 2018 03:34:23 +0000 (09:04 +0530)]
Uprobes: Fix kernel oops with delayed_uprobe_remove()
There could be a race between task exit and probe unregister:
exit_mm()
mmput()
__mmput() uprobe_unregister()
uprobe_clear_state() put_uprobe()
delayed_uprobe_remove() delayed_uprobe_remove()
put_uprobe() is calling delayed_uprobe_remove() without taking
delayed_uprobe_lock and thus the race sometimes results in a
kernel crash. Fix this by taking delayed_uprobe_lock before
calling delayed_uprobe_remove() from put_uprobe().
Detailed crash log can be found at:
Link: http://lkml.kernel.org/r/000000000000140c370577db5ece@google.com
Link: http://lkml.kernel.org/r/20181205033423.26242-1-ravi.bangoria@linux.ibm.com
Acked-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Reported-by: syzbot+cb1fb754b771caca0a88@syzkaller.appspotmail.com
Fixes:
1cc33161a83d ("uprobes: Support SDT markers having reference count (semaphore)")
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Anders Roxell [Fri, 30 Nov 2018 15:08:59 +0000 (16:08 +0100)]
stackleak: Mark stackleak_track_stack() as notrace
Function graph tracing recurses into itself when stackleak is enabled,
causing the ftrace graph selftest to run for up to 90 seconds and
trigger the softlockup watchdog.
Breakpoint 2, ftrace_graph_caller () at ../arch/arm64/kernel/entry-ftrace.S:200
200 mcount_get_lr_addr x0 // pointer to function's saved lr
(gdb) bt
\#0 ftrace_graph_caller () at ../arch/arm64/kernel/entry-ftrace.S:200
\#1 0xffffff80081d5280 in ftrace_caller () at ../arch/arm64/kernel/entry-ftrace.S:153
\#2 0xffffff8008555484 in stackleak_track_stack () at ../kernel/stackleak.c:106
\#3 0xffffff8008421ff8 in ftrace_ops_test (ops=0xffffff8009eaa840 <graph_ops>, ip=
18446743524091297036, regs=<optimized out>) at ../kernel/trace/ftrace.c:1507
\#4 0xffffff8008428770 in __ftrace_ops_list_func (regs=<optimized out>, ignored=<optimized out>, parent_ip=<optimized out>, ip=<optimized out>) at ../kernel/trace/ftrace.c:6286
\#5 ftrace_ops_no_ops (ip=
18446743524091297036, parent_ip=
18446743524091242824) at ../kernel/trace/ftrace.c:6321
\#6 0xffffff80081d5280 in ftrace_caller () at ../arch/arm64/kernel/entry-ftrace.S:153
\#7 0xffffff800832fd10 in irq_find_mapping (domain=0xffffffc03fc4bc80, hwirq=27) at ../kernel/irq/irqdomain.c:876
\#8 0xffffff800832294c in __handle_domain_irq (domain=0xffffffc03fc4bc80, hwirq=27, lookup=true, regs=0xffffff800814b840) at ../kernel/irq/irqdesc.c:650
\#9 0xffffff80081d52b4 in ftrace_graph_caller () at ../arch/arm64/kernel/entry-ftrace.S:205
Rework so we mark stackleak_track_stack as notrace
Co-developed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Linus Torvalds [Thu, 6 Dec 2018 01:06:31 +0000 (17:06 -0800)]
Merge tag 'scsi-fixes' of git://git./linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Four obvious bug fixes. The vmw_pscsi is so old that it's amazing
no-one noticed before now"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: storvsc: Fix a race in sub-channel creation that can cause panic
scsi: vmw_pscsi: Rearrange code to avoid multiple calls to free_irq during unload
scsi: libiscsi: Fix NULL pointer dereference in iscsi_eh_session_reset
scsi: lpfc: fix block guard enablement on SLI3 adapters
Linus Torvalds [Wed, 5 Dec 2018 23:51:41 +0000 (15:51 -0800)]
Merge tag 'arc-4.20-rc6' of git://git./linux/kernel/git/vgupta/arc
Pull ARC fixes/updates from Vineet Gupta
- Missing reads{x}()/writes{x}() getting in the way of some drivers [Jose Abreu]
- Builds defaulting to ARCv2 ISA based configsa [Kevin Hilman]
- Misc fixes
* tag 'arc-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
ARC: io.h: Implement reads{x}()/writes{x}()
ARC: change defconfig defaults to ARCv2
arc: [devboards] Add support of NFSv3 ACL
ARC: mm: fix uninitialised signal code in do_page_fault
ARC: [plat-hsdk] Enable DW APB GPIO support
ARCv2: boot log unaligned access in use
ARC: IOC: panic if kernel was started with previously enabled IOC
ARC: remove redundant 'default n' from Kconfig
David Rientjes [Wed, 5 Dec 2018 23:45:54 +0000 (15:45 -0800)]
mm, thp: restore node-local hugepage allocations
This is a full revert of
ac5b2c18911f ("mm: thp: relax __GFP_THISNODE for
MADV_HUGEPAGE mappings") and a partial revert of
89c83fb539f9 ("mm, thp:
consolidate THP gfp handling into alloc_hugepage_direct_gfpmask").
By not setting __GFP_THISNODE, applications can allocate remote hugepages
when the local node is fragmented or low on memory when either the thp
defrag setting is "always" or the vma has been madvised with
MADV_HUGEPAGE.
Remote access to hugepages often has much higher latency than local pages
of the native page size. On Haswell,
ac5b2c18911f was shown to have a
13.9% access regression after this commit for binaries that remap their
text segment to be backed by transparent hugepages.
The intent of
ac5b2c18911f is to address an issue where a local node is
low on memory or fragmented such that a hugepage cannot be allocated. In
every scenario where this was described as a fix, there is abundant and
unfragmented remote memory available to allocate from, even with a greater
access latency.
If remote memory is also low or fragmented, not setting __GFP_THISNODE was
also measured on Haswell to have a 40% regression in allocation latency.
Restore __GFP_THISNODE for thp allocations.
Fixes:
ac5b2c18911f ("mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings")
Fixes:
89c83fb539f9 ("mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmask")
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Dan Williams [Mon, 3 Dec 2018 18:30:25 +0000 (10:30 -0800)]
acpi/nfit: Fix user-initiated ARS to be "ARS-long" rather than "ARS-short"
A "short" ARS (address range scrub) instructs the platform firmware to
return known errors. In contrast, a "long" ARS instructs platform
firmware to arrange every data address on the DIMM to be read / checked
for poisoned data.
The conversion of the flags in commit
d3abaf43bab8 "acpi, nfit: Fix
Address Range Scrub completion tracking", changed the meaning of passing
'0' to acpi_nfit_ars_rescan(). Previously '0' meant "not short", now '0'
is ARS_REQ_SHORT. Pass ARS_REQ_LONG to restore the expected scrub-type
behavior of user-initiated ARS sessions.
Fixes:
d3abaf43bab8 ("acpi, nfit: Fix Address Range Scrub completion tracking")
Reported-by: Jacek Zloch <jacek.zloch@intel.com>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Dan Williams [Sat, 24 Nov 2018 18:47:04 +0000 (10:47 -0800)]
libnvdimm, pfn: Pad pfn namespaces relative to other regions
Commit
cfe30b872058 "libnvdimm, pmem: adjust for section collisions with
'System RAM'" enabled Linux to workaround occasions where platform
firmware arranges for "System RAM" and "Persistent Memory" to collide
within a single section boundary. Unfortunately, as reported in this
issue [1], platform firmware can inflict the same collision between
persistent memory regions.
The approach of interrogating iomem_resource does not work in this
case because platform firmware may merge multiple regions into a single
iomem_resource range. Instead provide a method to interrogate regions
that share the same parent bus.
This is a stop-gap until the core-MM can grow support for hotplug on
sub-section boundaries.
[1]: https://github.com/pmem/ndctl/issues/76
Fixes:
cfe30b872058 ("libnvdimm, pmem: adjust for section collisions with...")
Cc: <stable@vger.kernel.org>
Reported-by: Patrick Geary <patrickg@supermicro.com>
Tested-by: Patrick Geary <patrickg@supermicro.com>
Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Dan Williams [Wed, 5 Dec 2018 22:11:48 +0000 (14:11 -0800)]
tools/testing/nvdimm: Align test resources to 128M
In preparation for libnvdimm growing new restrictions to detect section
conflicts between persistent memory regions, enable nfit_test to
allocate aligned resources. Use a gen_pool to allocate nfit_test's fake
resources in a separate address space from the virtual translation of
the same.
Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
Tested-by: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Linus Torvalds [Wed, 5 Dec 2018 21:28:01 +0000 (13:28 -0800)]
Merge tag 'for-linus-
20181205' of git://git.kernel.dk/linux-block
Pull block fixes from Jens Axboe:
"A bit earlier in the week as usual, but there's a fix here that should
go in sooner rather than later.
Under a combination of circumstance, the direct issue path in blk-mq
could corrupt data. This wasn't easy to hit, but the ones that are
affected by it, seem to hit it pretty easily. Full explanation in the
patch. None of the regular filesystem and storage testing has
triggered it, even though it's been around since 4.19-rc1.
Outside of that, whitelist trim tweak for certain Samsung devices for
libata"
* tag 'for-linus-
20181205' of git://git.kernel.dk/linux-block:
blk-mq: fix corruption with direct issue
libata: whitelist all SAMSUNG MZ7KM* solid-state disks
Mathias Payer [Wed, 5 Dec 2018 20:19:59 +0000 (21:19 +0100)]
USB: check usb_get_extra_descriptor for proper size
When reading an extra descriptor, we need to properly check the minimum
and maximum size allowed, to prevent from invalid data being sent by a
device.
Reported-by: Hui Peng <benquike@gmail.com>
Reported-by: Mathias Payer <mathias.payer@nebelwelt.net>
Co-developed-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Hui Peng <benquike@gmail.com>
Signed-off-by: Mathias Payer <mathias.payer@nebelwelt.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Zhu [Tue, 4 Dec 2018 03:04:28 +0000 (22:04 -0500)]
drm/amdgpu/vcn: Update vcn.cur_state during suspend
Replace vcn_v1_0_stop with vcn_v1_0_set_powergating_state during suspend,
to keep adev->vcn.cur_state update. It will fix VCN S3 hung issue.
Signed-off-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Linus Torvalds [Wed, 5 Dec 2018 17:58:17 +0000 (09:58 -0800)]
Merge tag 'for-4.20-rc5-tag' of git://git./linux/kernel/git/kdave/linux
Pull btrfs fix from David Sterba:
"A patch in 4.19 introduced a sanity check that was too strict and a
filesystem cannot be mounted.
This happens for filesystems with more than 10 devices and has been
reported by a few users so we need the fix to propagate to stable"
* tag 'for-4.20-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
btrfs: tree-checker: Don't check max block group size as current max chunk size limit is unreliable
Linus Torvalds [Wed, 5 Dec 2018 17:51:10 +0000 (09:51 -0800)]
Merge tag 'pm-4.20-rc6' of git://git./linux/kernel/git/rafael/linux-pm
Pull power management fix from Rafael Wysocki:
"Revert a problematic recent commit that attempted to fix a system-wide
suspend issue related to the freezer"
* tag 'pm-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
Revert "exec: make de_thread() freezable"
Linus Torvalds [Wed, 5 Dec 2018 17:45:34 +0000 (09:45 -0800)]
Merge tag 'mfd-fixes-4.20' of git://git./linux/kernel/git/lee/mfd
Pull mfd bugfix from Lee Jones:
"Replace release function in cros_ec_dev"
* tag 'mfd-fixes-4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd:
Revert "mfd: cros_ec: Use devm_kzalloc for private data"
Chris Chiu [Wed, 5 Dec 2018 06:48:56 +0000 (14:48 +0800)]
ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4860G/Z6860G
Acer AIO Veriton Z4860G/Z6860G with the same ALC286 codec has issues
with the input from external microphone. The issue can be fixed by
the fixup ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE for Veriton Z4660G.
Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Chris Chiu <chiu@endlessm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Chris Chiu [Wed, 5 Dec 2018 06:48:55 +0000 (14:48 +0800)]
ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4660G
Acer AIO Veriton Z4660G with ALC286 codec has issue with the input
from external microphones connecting via 'Front Mic' jack. The fixup
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE enables the jack sensing of
the headset and fix the audio input issue of external microphone.
Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Chris Chiu <chiu@endlessm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Chris Chiu [Wed, 5 Dec 2018 06:48:54 +0000 (14:48 +0800)]
ALSA: hda/realtek - Add support for Acer Aspire C24-860 headset mic
The Acer AIO Aspire C24-860 with ALC286 can't detect the headset
microphone. Just like another Acer AIO U27-880, it needs a different
pin value for 0x18 and the headset fixup to make headset mic work.
Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Chris Chiu <chiu@endlessm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Chris Chiu [Wed, 5 Dec 2018 06:48:53 +0000 (14:48 +0800)]
ALSA: hda/realtek: ALC286 mic and headset-mode fixups for Acer Aspire U27-880
Acer Aspire U27-880(AIO) with ALC286 codec can not detect headset mic
and internal mic not working either. It needs the similar quirk like
Sony laptops to fix headphone jack sensing and enables use of the
internal microphone.
Unfortunately jack sensing for the headset mic is still not working.
Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Chris Chiu <chiu@endlessm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Julia Lawall [Tue, 30 Oct 2018 15:15:00 +0000 (16:15 +0100)]
thermal: broadcom: constify thermal_zone_of_device_ops structure
The thermal_zone_of_device_ops structure can be const as it is only
passed as the last argument of thermal_zone_of_sensor_register
and the corresponding parameter is declared as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Julia Lawall [Tue, 30 Oct 2018 15:14:59 +0000 (16:14 +0100)]
thermal: armada: constify thermal_zone_of_device_ops structure
The thermal_zone_of_device_ops structure can be const as it is only
passed as the last argument of devm_thermal_zone_of_sensor_register
and the corresponding parameter is declared as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Trond Myklebust [Mon, 3 Dec 2018 23:49:00 +0000 (18:49 -0500)]
SUNRPC: Don't force a redundant disconnection in xs_read_stream()
If the connection is broken, then xs_tcp_state_change() will take care
of scheduling the socket close as soon as appropriate. xs_read_stream()
just needs to report the error.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Trond Myklebust [Tue, 4 Dec 2018 12:50:06 +0000 (07:50 -0500)]
SUNRPC: Fix up socket polling
Ensure that we do not exit the socket read callback without clearing
XPRT_SOCK_DATA_READY.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Trond Myklebust [Mon, 3 Dec 2018 20:58:58 +0000 (15:58 -0500)]
SUNRPC: Use the discard iterator rather than MSG_TRUNC
When discarding message data from the stream, we're better off using
the discard iterator, since that will work with non-TCP streams.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Trond Myklebust [Mon, 3 Dec 2018 20:41:38 +0000 (15:41 -0500)]
SUNRPC: Treat EFAULT as a truncated message in xs_read_stream_request()
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Trond Myklebust [Sun, 2 Dec 2018 20:22:48 +0000 (15:22 -0500)]
SUNRPC: Fix up handling of the XDRBUF_SPARSE_PAGES flag
If the allocator fails before it has reached the target number of pages,
then we need to recheck that we're not seeking past the page buffer.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Trond Myklebust [Tue, 4 Dec 2018 12:52:11 +0000 (07:52 -0500)]
SUNRPC: Fix RPC receive hangs
The RPC code is occasionally hanging when the receive code fails to
empty the socket buffer due to a partial read of the data. When we
convert that to an EAGAIN, it appears we occasionally leave data in the
socket. The fix is to just keep reading until the socket returns
EAGAIN/EWOULDBLOCK.
Reported-by: Catalin Marinas <catalin.marinas@arm.com>
Reported-by: Cristian Marussi <cristian.marussi@arm.com>
Reported-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Tested-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Cristian Marussi <cristian.marussi@arm.com>
Johan Hovold [Tue, 4 Dec 2018 16:00:36 +0000 (17:00 +0100)]
USB: serial: console: fix reported terminal settings
The USB-serial console implementation has never reported the actual
terminal settings used. Despite storing the corresponding cflags in its
struct console, these were never honoured on later tty open() where the
tty termios would be left initialised to the driver defaults.
Unlike the serial console implementation, the USB-serial code calls
subdriver open() already at console setup. While calling set_termios()
and write() before open() looks like it could work for some USB-serial
drivers, others definitely do not expect this, so modelling this after
serial core is going to be intrusive, if at all possible.
Instead, use a (renamed) tty helper to save the termios data used at
console setup so that the tty termios reflects the actual terminal
settings after a subsequent tty open().
Note that the calls to tty_init_termios() (tty_driver_install()) and
tty_save_termios() are serialised using the disconnect mutex.
This specifically fixes a regression that was triggered by a recent
change adding software flow control to the pl2303 driver: a getty trying
to disable flow control while leaving the baud rate unchanged would now
also set the baud rate to the driver default (prior to the flow-control
change this had been a noop).
Fixes:
7041d9c3f01b ("USB: serial: pl2303: add support for tx xon/xoff flow control")
Cc: stable <stable@vger.kernel.org> # 4.18
Cc: Florian Zumbiehl <florz@florz.de>
Reported-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Enric Balletbo i Serra [Tue, 4 Dec 2018 15:58:43 +0000 (16:58 +0100)]
Revert "mfd: cros_ec: Use devm_kzalloc for private data"
This reverts commit
3aa2177e47878f7e7616da8a2050c44f22301b6e.
That commit triggered a new WARN when unloading the module (see at the
end of the commit message). When a class_dev is embedded in a structure
then that class_dev is the thing that controls the lifetime of that
structure, for that reason device managed allocations can't be used here.
See Documentation/kobject.txt.
Revert the above patch, so the struct is allocated using kzalloc and we
have a release function for it that frees the allocated memory, otherwise
it is broken.
------------[ cut here ]------------
Device 'cros_ec' does not have a release() function, it is broken and must be fixed.
WARNING: CPU: 3 PID: 3675 at drivers/base/core.c:895 device_release+0x80/0x90
Modules linked in: btusb btrtl btintel btbcm bluetooth ...
CPU: 3 PID: 3675 Comm: rmmod Not tainted 4.20.0-rc4 #76
Hardware name: Google Kevin (DT)
pstate:
40000005 (nZcv daif -PAN -UAO)
pc : device_release+0x80/0x90
lr : device_release+0x80/0x90
sp :
ffff00000c47bc70
x29:
ffff00000c47bc70 x28:
ffff8000e86b0d40
x27:
0000000000000000 x26:
0000000000000000
x25:
0000000056000000 x24:
0000000000000015
x23:
ffff8000f0bbf860 x22:
ffff000000d320a0
x21:
ffff8000ee93e100 x20:
ffff8000ed931428
x19:
ffff8000ed931418 x18:
0000000000000020
x17:
0000000000000000 x16:
0000000000000000
x15:
0000000000000400 x14:
0000000000000143
x13:
0000000000000000 x12:
0000000000000400
x11:
0000000000000157 x10:
0000000000000960
x9 :
ffff00000c47b9b0 x8 :
ffff8000e86b1700
x7 :
0000000000000000 x6 :
ffff8000f7d520b8
x5 :
ffff8000f7d520b8 x4 :
0000000000000000
x3 :
ffff8000f7d58e68 x2 :
ffff8000e86b0d40
x1 :
37d859939c964800 x0 :
0000000000000000
Call trace:
device_release+0x80/0x90
kobject_put+0x74/0xe8
device_unregister+0x20/0x30
ec_device_remove+0x34/0x48 [cros_ec_dev]
platform_drv_remove+0x28/0x48
device_release_driver_internal+0x1a8/0x240
driver_detach+0x40/0x80
bus_remove_driver+0x54/0xa8
driver_unregister+0x2c/0x58
platform_driver_unregister+0x10/0x18
cros_ec_dev_exit+0x1c/0x2d8 [cros_ec_dev]
__arm64_sys_delete_module+0x16c/0x1f8
el0_svc_common+0x84/0xd8
el0_svc_handler+0x2c/0x80
el0_svc+0x8/0xc
---[ end trace
a57c4625f3c60ae8 ]---
Cc: stable@vger.kernel.org
Fixes:
3aa2177e4787 ("mfd: cros_ec: Use devm_kzalloc for private data")
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Harry Pan [Wed, 28 Nov 2018 16:40:41 +0000 (00:40 +0800)]
usb: quirk: add no-LPM quirk on SanDisk Ultra Flair device
Some lower volume SanDisk Ultra Flair in 16GB, which the VID:PID is
in 0781:5591, will aggressively request LPM of U1/U2 during runtime,
when using this thumb drive as the OS installation key we found the
device will generate failure during U1 exit path making it dropped
from the USB bus, this causes a corrupted installation in system at
the end.
i.e.,
[ 166.918296] hub 2-0:1.0: state 7 ports 7 chg 0000 evt 0004
[ 166.918327] usb usb2-port2: link state change
[ 166.918337] usb usb2-port2: do warm reset
[ 166.970039] usb usb2-port2: not warm reset yet, waiting 50ms
[ 167.022040] usb usb2-port2: not warm reset yet, waiting 200ms
[ 167.276043] usb usb2-port2: status 02c0, change 0041, 5.0 Gb/s
[ 167.276050] usb 2-2: USB disconnect, device number 2
[ 167.276058] usb 2-2: unregistering device
[ 167.276060] usb 2-2: unregistering interface 2-2:1.0
[ 167.276170] xhci_hcd 0000:00:15.0: shutdown urb
ffffa3c7cc695cc0 ep1in-bulk
[ 167.284055] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[ 167.284064] sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 33 04 90 00 01 00 00
...
Analyzed the USB trace in the link layer we realized it is because
of the 6-ms timer of tRecoveryConfigurationTimeout which documented
on the USB 3.2 Revision 1.0, the section 7.5.10.4.2 of "Exit from
Recovery.Configuration"; device initiates U1 exit -> Recovery.Active
-> Recovery.Configuration, then the host timer timeout makes the link
transits to eSS.Inactive -> Rx.Detect follows by a Warm Reset.
Interestingly, the other higher volume of SanDisk Ultra Flair sharing
the same VID:PID, such as 64GB, would not request LPM during runtime,
it sticks at U0 always, thus disabling LPM does not affect those thumb
drives at all.
The same odd occures in SanDisk Ultra Fit 16GB, VID:PID in 0781:5583.
Signed-off-by: Harry Pan <harry.pan@intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Wed, 28 Nov 2018 16:25:58 +0000 (11:25 -0500)]
USB: Fix invalid-free bug in port_over_current_notify()
Syzbot and KASAN found the following invalid-free bug in
port_over_current_notify():
--------------------------------------------------------------------------
BUG: KASAN: double-free or invalid-free in port_over_current_notify
drivers/usb/core/hub.c:5192 [inline]
BUG: KASAN: double-free or invalid-free in port_event
drivers/usb/core/hub.c:5241 [inline]
BUG: KASAN: double-free or invalid-free in hub_event+0xd97/0x4140
drivers/usb/core/hub.c:5384
CPU: 1 PID: 32710 Comm: kworker/1:3 Not tainted 4.20.0-rc3+ #129
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x244/0x39d lib/dump_stack.c:113
print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
kasan_report_invalid_free+0x64/0xa0 mm/kasan/report.c:336
__kasan_slab_free+0x13a/0x150 mm/kasan/kasan.c:501
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xcf/0x230 mm/slab.c:3817
port_over_current_notify drivers/usb/core/hub.c:5192 [inline]
port_event drivers/usb/core/hub.c:5241 [inline]
hub_event+0xd97/0x4140 drivers/usb/core/hub.c:5384
process_one_work+0xc90/0x1c40 kernel/workqueue.c:2153
worker_thread+0x17f/0x1390 kernel/workqueue.c:2296
kthread+0x35a/0x440 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
--------------------------------------------------------------------------
The problem is caused by use of a static array to store
environment-string pointers. When the routine is called by multiple
threads concurrently, the pointers from one thread can overwrite those
from another.
The solution is to use an ordinary automatic array instead of a static
array.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: syzbot+98881958e1410ec7e53c@syzkaller.appspotmail.com
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Theissen [Tue, 4 Dec 2018 22:43:35 +0000 (23:43 +0100)]
usb: appledisplay: Add 27" Apple Cinema Display
Add another Apple Cinema Display to the list of supported displays.
Signed-off-by: Alexander Theissen <alex.theissen@me.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bin Liu [Mon, 12 Nov 2018 15:43:22 +0000 (09:43 -0600)]
dmaengine: cppi41: delete channel from pending list when stop channel
The driver defines three states for a cppi channel.
- idle: .chan_busy == 0 && not in .pending list
- pending: .chan_busy == 0 && in .pending list
- busy: .chan_busy == 1 && not in .pending list
There are cases in which the cppi channel could be in the pending state
when cppi41_dma_issue_pending() is called after cppi41_runtime_suspend()
is called.
cppi41_stop_chan() has a bug for these cases to set channels to idle state.
It only checks the .chan_busy flag, but not the .pending list, then later
when cppi41_runtime_resume() is called the channels in .pending list will
be transitioned to busy state.
Removing channels from the .pending list solves the problem.
Fixes:
975faaeb9985 ("dma: cppi41: start tear down only if channel is busy")
Cc: stable@vger.kernel.org # v3.15+
Signed-off-by: Bin Liu <b-liu@ti.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Lucas Stach [Tue, 6 Nov 2018 03:40:37 +0000 (03:40 +0000)]
dmaengine: imx-sdma: use GFP_NOWAIT for dma descriptor allocations
DMA buffer descriptors aren't allocated from atomic context, so they
can use the less heavyweigth GFP_NOWAIT.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Lucas Stach [Tue, 6 Nov 2018 03:40:33 +0000 (03:40 +0000)]
dmaengine: imx-sdma: implement channel termination via worker
The dmaengine documentation states that device_terminate_all may be
asynchronous and need not wait for the active transfers to stop.
This allows us to move most of the functionality currently implemented
in the sdma channel termination function to run in a worker, outside
of any atomic context. Moving this out of atomic context has two
benefits: we can now sleep while waiting for the channel to terminate,
instead of busy waiting and the freeing of the dma descriptors happens
with IRQs enabled, getting rid of a warning in the dma mapping code.
As the termination is now async, we need to implement the
device_synchronize dma engine function which simply waits for the
worker to finish its execution.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Lucas Stach [Tue, 6 Nov 2018 03:40:28 +0000 (03:40 +0000)]
Revert "dmaengine: imx-sdma: alloclate bd memory from dma pool"
This reverts commit
fe5b85c656bc. The SDMA engine needs the descriptors to
be contiguous in memory. As the dma pool API is only able to provide a
single descriptor per alloc invocation there is no guarantee that multiple
descriptors satisfy this requirement. Also the code in question is broken
as it only allocates memory for a single descriptor, without looking at the
number of descriptors required for the transfer, leading to out-of-bounds
accesses when the descriptors are written.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Lucas Stach [Tue, 6 Nov 2018 03:40:25 +0000 (03:40 +0000)]
Revert "dmaengine: imx-sdma: Use GFP_NOWAIT for dma allocations"
This reverts commit
c1199875d327, as this depends on another commit
that is going to be reverted.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Stefan Wahren [Sat, 10 Nov 2018 16:55:27 +0000 (17:55 +0100)]
thermal: bcm2835: Switch to SPDX identifier
Adopt the SPDX license identifier headers to ease license compliance
management.
Cc: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Matthew Wilcox [Fri, 30 Nov 2018 16:05:06 +0000 (11:05 -0500)]
dax: Fix unlock mismatch with updated API
Internal to dax_unlock_mapping_entry(), dax_unlock_entry() is used to
store a replacement entry in the Xarray at the given xas-index with the
DAX_LOCKED bit clear. When called, dax_unlock_entry() expects the unlocked
value of the entry relative to the current Xarray state to be specified.
In most contexts dax_unlock_entry() is operating in the same scope as
the matched dax_lock_entry(). However, in the dax_unlock_mapping_entry()
case the implementation needs to recall the original entry. In the case
where the original entry is a 'pmd' entry it is possible that the pfn
performed to do the lookup is misaligned to the value retrieved in the
Xarray.
Change the api to return the unlock cookie from dax_lock_page() and pass
it to dax_unlock_page(). This fixes a bug where dax_unlock_page() was
assuming that the page was PMD-aligned if the entry was a PMD entry with
signatures like:
WARNING: CPU: 38 PID: 1396 at fs/dax.c:340 dax_insert_entry+0x2b2/0x2d0
RIP: 0010:dax_insert_entry+0x2b2/0x2d0
[..]
Call Trace:
dax_iomap_pte_fault.isra.41+0x791/0xde0
ext4_dax_huge_fault+0x16f/0x1f0
? up_read+0x1c/0xa0
__do_fault+0x1f/0x160
__handle_mm_fault+0x1033/0x1490
handle_mm_fault+0x18b/0x3d0
Link: https://lkml.kernel.org/r/20181130154902.GL10377@bombadil.infradead.org
Fixes:
9f32d221301c ("dax: Convert dax_lock_mapping_entry to XArray")
Reported-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Matthew Wilcox <willy@infradead.org>
Tested-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Russell King [Fri, 9 Nov 2018 17:01:05 +0000 (17:01 +0000)]
thermal: armada: fix legacy resource fixup
When the armada thermal module is inserted, removed and then reinserted,
the system panics as per the messages below. The reason is that "edit"
a live resource in the resource tree twice, and end up with it pointing
to some other hardware.
Editing live resources (resources that are part of the registered
resource tree) is not permissible - the resource tree is an ordered
set of resources, sorted by start address, and when a new resource is
inserted, it is validated that it (a) fits within its parent resource
and (b) does not overlap a neighbouring resource.
Get rid of this resource editing. We can instead adjust the return
value from ioremap() as ioremap() deals with the creation of page-
based mappings - provided the adjustment does not cross a page
boundary.
SError Interrupt on CPU1, code 0xbf000000 -- SError
CPU: 1 PID: 2749 Comm: modprobe Not tainted 4.19.0+ #175
Hardware name: Marvell 8040 MACCHIATOBin Double shot (DT)
pstate:
20400085 (nzCv daIf +PAN -UAO)
pc : regmap_mmio_read+0x3c/0x60
lr : regmap_mmio_read+0x3c/0x60
sp :
ffffff800d453900
x29:
ffffff800d453900 x28:
ffffff800096a1d0
x27:
0000000000000100 x26:
ffffff80009696d8
x25:
ffffff8000969000 x24:
ffffffc13a588918
x23:
ffffffc13a9a28a8 x22:
ffffff800d4539dc
x21:
0000000000000084 x20:
ffffff800d4539dc
x19:
ffffffc13a5d5480 x18:
0000000000000000
x17:
0000000000000000 x16:
0000000000000000
x15:
0000000000000000 x14:
0000000000000000
x13:
0000000000000000 x12:
0000000000000030
x11:
0101010101010101 x10:
7f7f7f7f7f7f7f7f
x9 :
0000000000000000 x8 :
ffffffc13a5d5a80
x7 :
0000000000000000 x6 :
000000000000003f
x5 :
0000000000000000 x4 :
0000000000000000
x3 :
ffffff800851be70 x2 :
ffffff800851bd60
x1 :
ffffff800d492ff8 x0 :
0000000000000000
Kernel panic - not syncing: Asynchronous SError Interrupt
CPU: 1 PID: 2749 Comm: modprobe Not tainted 4.19.0+ #175
Hardware name: Marvell 8040 MACCHIATOBin Double shot (DT)
Call trace:
dump_backtrace+0x0/0x158
show_stack+0x14/0x1c
dump_stack+0x90/0xb0
panic+0x128/0x298
print_tainted+0x0/0xa8
arm64_serror_panic+0x74/0x80
do_serror+0x5c/0xb8
el1_error+0xb4/0x144
regmap_mmio_read+0x3c/0x60
_regmap_bus_reg_read+0x18/0x20
_regmap_read+0x64/0x180
regmap_read+0x44/0x6c
armada_ap806_init+0x24/0x5c [armada_thermal]
armada_thermal_probe+0x2c8/0x37c [armada_thermal]
platform_drv_probe+0x4c/0xb0
really_probe+0x21c/0x2b4
driver_probe_device+0x58/0xfc
__driver_attach+0xd4/0xd8
bus_for_each_dev+0x50/0xa0
driver_attach+0x20/0x28
bus_add_driver+0x1c4/0x228
driver_register+0x6c/0x124
__platform_driver_register+0x4c/0x54
armada_thermal_driver_init+0x20/0x1000 [armada_thermal]
do_one_initcall+0x30/0x204
do_init_module+0x5c/0x1d4
load_module+0x1a88/0x212c
__se_sys_finit_module+0xa0/0xac
__arm64_sys_finit_module+0x1c/0x24
el0_svc_common+0x94/0xf0
el0_svc_handler+0x24/0x80
el0_svc+0x8/0x3c0
SMP: stopping secondary CPUs
Kernel Offset: disabled
CPU features: 0x0,
21806000
Memory Limit: none
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Tested-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Russell King [Fri, 9 Nov 2018 16:44:14 +0000 (16:44 +0000)]
thermal: armada: fix legacy validity test sense
Commit
8c0e64ac4075 ("thermal: armada: get rid of the ->is_valid()
pointer") removed the unnecessary indirection through a function
pointer, but in doing so, also removed the negation operator too:
- if (priv->data->is_valid && !priv->data->is_valid(priv)) {
+ if (armada_is_valid(priv)) {
which results in:
armada_thermal
f06f808c.thermal: Temperature sensor reading not valid
armada_thermal
f2400078.thermal: Temperature sensor reading not valid
armada_thermal
f4400078.thermal: Temperature sensor reading not valid
at boot, or whenever the "temp" sysfs file is read. Replace the
negation operator.
Fixes:
8c0e64ac4075 ("thermal: armada: get rid of the ->is_valid() pointer")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Jens Axboe [Wed, 5 Dec 2018 03:06:48 +0000 (20:06 -0700)]
blk-mq: fix corruption with direct issue
If we attempt a direct issue to a SCSI device, and it returns BUSY, then
we queue the request up normally. However, the SCSI layer may have
already setup SG tables etc for this particular command. If we later
merge with this request, then the old tables are no longer valid. Once
we issue the IO, we only read/write the original part of the request,
not the new state of it.
This causes data corruption, and is most often noticed with the file
system complaining about the just read data being invalid:
[ 235.934465] EXT4-fs error (device sda1): ext4_iget:4831: inode #7142: comm dpkg-query: bad extra_isize 24937 (inode size 256)
because most of it is garbage...
This doesn't happen from the normal issue path, as we will simply defer
the request to the hardware queue dispatch list if we fail. Once it's on
the dispatch list, we never merge with it.
Fix this from the direct issue path by flagging the request as
REQ_NOMERGE so we don't change the size of it before issue.
See also:
https://bugzilla.kernel.org/show_bug.cgi?id=201685
Tested-by: Guenter Roeck <linux@roeck-us.net>
Fixes:
6ce3dd6eec1 ("blk-mq: issue directly if hw queue isn't busy in case of 'none'")
Cc: stable@vger.kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Nathan Jones [Tue, 4 Dec 2018 09:05:32 +0000 (10:05 +0100)]
ARM: 8816/1: dma-mapping: fix potential uninitialized return
While trying to use the dma_mmap_*() interface, it was noticed that this
interface returns strange values when passed an incorrect length.
If neither of the if() statements fire then the return value is
uninitialized. In the worst case it returns 0 which means the caller
will think the function succeeded.
Fixes:
1655cf8829d8 ("ARM: dma-mapping: Remove traces of NOMMU code")
Signed-off-by: Nathan Jones <nathanj439@gmail.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Vladimir Murzin [Fri, 23 Nov 2018 11:25:21 +0000 (12:25 +0100)]
ARM: 8815/1: V7M: align v7m_dma_inv_range() with v7 counterpart
Chris has discovered and reported that v7_dma_inv_range() may corrupt
memory if address range is not aligned to cache line size.
Since the whole cache-v7m.S was lifted form cache-v7.S the same
observation applies to v7m_dma_inv_range(). So the fix just mirrors
what has been done for v7 with a little specific of M-class.
Cc: Chris Cole <chris@sageembedded.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Chris Cole [Fri, 23 Nov 2018 11:20:45 +0000 (12:20 +0100)]
ARM: 8814/1: mm: improve/fix ARM v7_dma_inv_range() unaligned address handling
This patch addresses possible memory corruption when
v7_dma_inv_range(start_address, end_address) address parameters are not
aligned to whole cache lines. This function issues "invalidate" cache
management operations to all cache lines from start_address (inclusive)
to end_address (exclusive). When start_address and/or end_address are
not aligned, the start and/or end cache lines are first issued "clean &
invalidate" operation. The assumption is this is done to ensure that any
dirty data addresses outside the address range (but part of the first or
last cache lines) are cleaned/flushed so that data is not lost, which
could happen if just an invalidate is issued.
The problem is that these first/last partial cache lines are issued
"clean & invalidate" and then "invalidate". This second "invalidate" is
not required and worse can cause "lost" writes to addresses outside the
address range but part of the cache line. If another component writes to
its part of the cache line between the "clean & invalidate" and
"invalidate" operations, the write can get lost. This fix is to remove
the extra "invalidate" operation when unaligned addressed are used.
A kernel module is available that has a stress test to reproduce the
issue and a unit test of the updated v7_dma_inv_range(). It can be
downloaded from
http://ftp.sageembedded.com/outgoing/linux/cache-test-
20181107.tgz.
v7_dma_inv_range() is call by dmac_[un]map_area(addr, len, direction)
when the direction is DMA_FROM_DEVICE. One can (I believe) successfully
argue that DMA from a device to main memory should use buffers aligned
to cache line size, because the "clean & invalidate" might overwrite
data that the device just wrote using DMA. But if a driver does use
unaligned buffers, at least this fix will prevent memory corruption
outside the buffer.
Signed-off-by: Chris Cole <chris@sageembedded.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Nicholas Kazlauskas [Fri, 20 Jul 2018 14:17:29 +0000 (10:17 -0400)]
drm/amd/display: Fix overflow/truncation from strncpy.
[Why]
New GCC warnings for stringop-truncation and stringop-overflow help
catch common misuse of strncpy. This patch suppresses these warnings
by fixing bugs identified by them.
[How]
Since the parameter passed for name in amdpgu_dm_create_common_mode has
no fixed length, if the string is >= DRM_DISPLAY_MODE_LEN then
mode->name will not be null-terminated.
The truncation in fill_audio_info won't actually occur (and the string
will be null-terminated since the buffer is initialized to zero), but
the warning can be suppressed by using the proper buffer size.
This patch fixes both issues by using the real size for the buffer and
making use of strscpy (which always terminates).
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
projects / platform / kernel / linux-starfive.git / log