Linus Torvalds [Sat, 29 Aug 2020 20:50:56 +0000 (13:50 -0700)]
fsldma: fix very broken 32-bit ppc ioread64 functionality
Commit ef91bb196b0d ("kernel.h: Silence sparse warning in
lower_32_bits") caused new warnings to show in the fsldma driver, but
that commit was not to blame: it only exposed some very incorrect code
that tried to take the low 32 bits of an address.
That made no sense for multiple reasons, the most notable one being that
that code was intentionally limited to only 32-bit ppc builds, so "only
low 32 bits of an address" was completely nonsensical. There were no
high bits to mask off to begin with.
But even more importantly fropm a correctness standpoint, turning the
address into an integer then caused the subsequent address arithmetic to
be completely wrong too, and the "+1" actually incremented the address
by one, rather than by four.
Which again was incorrect, since the code was reading two 32-bit values
and trying to make a 64-bit end result of it all. Surprisingly, the
iowrite64() did not suffer from the same odd and incorrect model.
This code has never worked, but it's questionable whether anybody cared:
of the two users that actually read the 64-bit value (by way of some C
preprocessor hackery and eventually the 'get_cdar()' inline function),
one of them explicitly ignored the value, and the other one might just
happen to work despite the incorrect value being read.
This patch at least makes it not fail the build any more, and makes the
logic superficially sane. Whether it makes any difference to the code
_working_ or not shall remain a mystery.
Linus Torvalds [Sat, 29 Aug 2020 19:51:58 +0000 (12:51 -0700)]
Merge tag 's390-5.9-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 fixes from Vasily Gorbik:
- Disable preemption trace in percpu macros since the lockdep code
itself uses percpu variables now and it causes recursions.
- Fix kernel space 4-level paging broken by recent vmem rework.
* tag 's390-5.9-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/vmem: fix vmem_add_range for 4-level paging
s390: don't trace preemption in percpu macros
Linus Torvalds [Sat, 29 Aug 2020 19:44:30 +0000 (12:44 -0700)]
Merge tag 'for-linus-5.9-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull xen fixes from Juergen Gross:
"Two fixes for Xen: one needed for ongoing work to support virtio with
Xen, and one for a corner case in IRQ handling with Xen"
* tag 'for-linus-5.9-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
arm/xen: Add misuse warning to virt_to_gfn
xen/xenbus: Fix granting of vmalloc'd memory
XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt XEN data pointer which contains XEN specific information.
Linus Torvalds [Sat, 29 Aug 2020 19:37:00 +0000 (12:37 -0700)]
Merge tag 'hwmon-for-v5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
Pull hwmon fixes from Guenter Roeck:
- Fix tempeerature scale in gsc-hwmon driver
- Fix divide by 0 error in nct7904 driver
- Drop non-existing attribute from pmbus/isl68137 driver
- Fix status check in applesmc driver
* tag 'hwmon-for-v5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
hwmon: (gsc-hwmon) Scale temperature to millidegrees
hwmon: (applesmc) check status earlier.
hwmon: (nct7904) Correct divide by 0
hwmon: (pmbus/isl68137) remove READ_TEMPERATURE_1 telemetry for RAA228228
Linus Torvalds [Fri, 28 Aug 2020 23:38:29 +0000 (16:38 -0700)]
Merge tag 'block-5.9-2020-08-28' of git://git.kernel.dk/linux-block
Pull block fixes from Jens Axboe:
- nbd timeout fix (Hou)
- device size fix for loop LOOP_CONFIGURE (Martijn)
- MD pull from Song with raid5 stripe size fix (Yufen)
* tag 'block-5.9-2020-08-28' of git://git.kernel.dk/linux-block:
md/raid5: make sure stripe_size as power of two
loop: Set correct device size when using LOOP_CONFIGURE
nbd: restore default timeout when setting it to zero
Linus Torvalds [Fri, 28 Aug 2020 23:23:16 +0000 (16:23 -0700)]
Merge tag 'io_uring-5.9-2020-08-28' of git://git.kernel.dk/linux-block
Pull io_uring fixes from Jens Axboe:
"A few fixes in here, all based on reports and test cases from folks
using it. Most of it is stable material as well:
- Hashed work cancelation fix (Pavel)
- poll wakeup signalfd fix
- memlock accounting fix
- nonblocking poll retry fix
- ensure we never return -ERESTARTSYS for reads
- ensure offset == -1 is consistent with preadv2() as documented
- IOPOLL -EAGAIN handling fixes
- remove useless task_work bounce for block based -EAGAIN retry"
* tag 'io_uring-5.9-2020-08-28' of git://git.kernel.dk/linux-block:
io_uring: don't bounce block based -EAGAIN retry off task_work
io_uring: fix IOPOLL -EAGAIN retries
io_uring: clear req->result on IOPOLL re-issue
io_uring: make offset == -1 consistent with preadv2/pwritev2
io_uring: ensure read requests go through -ERESTART* transformation
io_uring: don't use poll handler if file can't be nonblocking read/written
io_uring: fix imbalanced sqo_mm accounting
io_uring: revert consumed iov_iter bytes on error
io-wq: fix hang after cancelling pending hashed work
io_uring: don't recurse on tsk->sighand->siglock with signalfd
Linus Torvalds [Fri, 28 Aug 2020 20:23:31 +0000 (13:23 -0700)]
Merge tag 'devprop-5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull device properties framework fix from Rafael Wysocki:
"Prevent the promotion of the secondary firmware node of a device to
the primary one from leaking a pointer (Heikki Krogerus)"
* tag 'devprop-5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
device property: Fix the secondary firmware node handling in set_primary_fwnode()
Linus Torvalds [Fri, 28 Aug 2020 20:17:14 +0000 (13:17 -0700)]
Merge tag 'acpi-5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fixes from Rafael Wysocki:
"These fix two recent issues in the ACPI memory mappings management
code and tighten up error handling in the ACPI driver for AMD SoCs
(APD).
Specifics:
- Avoid redundant rounding to the page size in acpi_os_map_iomem() to
address a recently introduced issue with the EFI memory map
permission check on ARM64 (Ard Biesheuvel).
- Fix acpi_release_memory() to wait until the memory mappings
released by it have been really unmapped (Rafael Wysocki).
- Make the ACPI driver for AMD SoCs (APD) check the return value of
acpi_dev_get_property() to avoid failures in the cases when the
device property under inspection is missing (Furquan Shaikh)"
* tag 'acpi-5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: OSL: Prevent acpi_release_memory() from returning too early
ACPI: ioremap: avoid redundant rounding to OS page size
ACPI: SoC: APD: Check return value of acpi_dev_get_property()
Linus Torvalds [Fri, 28 Aug 2020 20:12:09 +0000 (13:12 -0700)]
Merge tag 'pm-5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fixes from Rafael Wysocki:
"These fix the recently added Tegra194 cpufreq driver and the handling
of devices using runtime PM during system-wide suspend, improve the
intel_pstate driver documentation and clean up the cpufreq core.
Specifics:
- Make the recently added Tegra194 cpufreq driver use
read_cpuid_mpir() instead of cpu_logical_map() to avoid exporting
logical_cpu_map (Sumit Gupta).
- Drop the automatic system wakeup event reporting for devices with
pending runtime-resume requests during system-wide suspend to avoid
spurious aborts of the suspend flow (Rafael Wysocki).
- Fix build warning in the intel_pstate driver documentation and
improve the wording in there (Randy Dunlap).
- Clean up two pieces of code in the cpufreq core (Viresh Kumar)"
* tag 'pm-5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpufreq: Use WARN_ON_ONCE() for invalid relation
cpufreq: No need to verify cpufreq_driver in show_scaling_cur_freq()
PM: sleep: core: Fix the handling of pending runtime resume requests
Documentation: fix pm/intel_pstate build warning and wording
cpufreq: replace cpu_logical_map() with read_cpuid_mpir()
* pm-cpufreq:
cpufreq: Use WARN_ON_ONCE() for invalid relation
cpufreq: No need to verify cpufreq_driver in show_scaling_cur_freq()
Documentation: fix pm/intel_pstate build warning and wording
cpufreq: replace cpu_logical_map() with read_cpuid_mpir()
Linus Torvalds [Fri, 28 Aug 2020 18:37:33 +0000 (11:37 -0700)]
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Catalin Marinas:
- Fix kernel build with the integrated LLVM assembler which doesn't see
the -Wa,-march option.
- Fix "make vdso_install" when COMPAT_VDSO is disabled.
- Make KVM more robust if the AT S1E1R instruction triggers an
exception (architecture corner cases).
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
KVM: arm64: Set HCR_EL2.PTW to prevent AT taking synchronous exception
KVM: arm64: Survive synchronous exceptions caused by AT instructions
KVM: arm64: Add kvm_extable for vaxorcism code
arm64: vdso32: make vdso32 install conditional
arm64: use a common .arch preamble for inline assembly
Herbert Xu [Fri, 28 Aug 2020 07:11:25 +0000 (17:11 +1000)]
kernel.h: Silence sparse warning in lower_32_bits
I keep getting sparse warnings in crypto such as:
CHECK drivers/crypto/ccree/cc_hash.c
drivers/crypto/ccree/cc_hash.c:49:9: warning: cast truncates bits from constant value (47b5481dbefa4fa4 becomes befa4fa4)
drivers/crypto/ccree/cc_hash.c:49:26: warning: cast truncates bits from constant value (db0c2e0d64f98fa7 becomes 64f98fa7)
[.. many more ..]
This patch removes the warning by adding a mask to keep sparse
happy.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Fri, 28 Aug 2020 17:57:14 +0000 (10:57 -0700)]
Merge tag 'writeback_for_v5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs
Pull writeback fixes from Jan Kara:
"Fixes for writeback code occasionally skipping writeback of some
inodes or livelocking sync(2)"
* tag 'writeback_for_v5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
writeback: Drop I_DIRTY_TIME_EXPIRE
writeback: Fix sync livelock due to b_dirty_time processing
writeback: Avoid skipping inode writeback
writeback: Protect inode->i_io_list with inode->i_lock
Linus Torvalds [Fri, 28 Aug 2020 17:41:00 +0000 (10:41 -0700)]
Merge tag 'gfs2-v5.9-rc2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2
Pull gfs2 fix from Andreas Gruenbacher:
"Fix a memory leak on filesystem withdraw.
We didn't detect this bug because we have slab merging on by default
(CONFIG_SLAB_MERGE_DEFAULT). Adding 'slub_nomerge' to the kernel
command line exposed the problem"
* tag 'gfs2-v5.9-rc2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2:
gfs2: add some much needed cleanup for log flushes that fail
Linus Torvalds [Fri, 28 Aug 2020 17:33:04 +0000 (10:33 -0700)]
Merge tag 'ceph-for-5.9-rc3' of git://github.com/ceph/ceph-client
Pull ceph fixes from Ilya Dryomov:
"We have an inode number handling change, prompted by s390x which is a
64-bit architecture with a 32-bit ino_t, a patch to disallow leases to
avoid potential data integrity issues when CephFS is re-exported via
NFS or CIFS and a fix for the bulk of W=1 compilation warnings"
* tag 'ceph-for-5.9-rc3' of git://github.com/ceph/ceph-client:
ceph: don't allow setlease on cephfs
ceph: fix inode number handling on arches with 32-bit ino_t
libceph: add __maybe_unused to DEFINE_CEPH_FEATURE
Linus Torvalds [Fri, 28 Aug 2020 17:15:33 +0000 (10:15 -0700)]
Merge tag 'mfd-fixes-5.9' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
Pull MFD fixes from Lee Jones:
- fix double free
- handle devicetree disabled devices gracefully
* tag 'mfd-fixes-5.9' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd:
mfd: mfd-core: Ensure disabled devices are ignored without error
mfd: core: Fix double-free in mfd_remove_devices_fn()
Linus Torvalds [Fri, 28 Aug 2020 16:46:48 +0000 (09:46 -0700)]
Merge tag 'drm-fixes-2020-08-28' of git://anongit.freedesktop.org/drm/drm
Pull drm fixes from Dave Airlie:
"As expected a bit of an rc3 uptick, amdgpu and msm are the main ones,
one msm patch was from the merge window, but had dependencies and we
dropped it until the other tree had landed. Otherwise it's a couple of
fixes for core, and etnaviv, and single i915, exynos, omap fixes.
I'm still tracking the Sandybridge gpu relocations issue, if we don't
see much movement I might just queue up the reverts. I'll talk to
Daniel next week once he's back from holidays.
core:
- Take modeset bkl for legacy drivers
dp_mst:
- Allow null crtc in dp_mst
i915:
- Fix command parser desc matching with masks
amdgpu:
- Misc display fixes
- Backlight fixes
- MPO fix for DCN1
- Fixes for Sienna Cichlid
- Fixes for Navy Flounder
- Vega SW CTF fixes
- SMU fix for Raven
- Fix a possible overflow in INFO ioctl
- Gfx10 clockgating fix
exynos:
- Just drop __iommu annotation to fix sparse warning
omap:
- locking state fix"
* tag 'drm-fixes-2020-08-28' of git://anongit.freedesktop.org/drm/drm: (41 commits)
drm/amd/display: Fix memleak in amdgpu_dm_mode_config_init
drm/amdgpu: disable runtime pm for navy_flounder
drm/amd/display: Retry AUX write when fail occurs
drm/amdgpu: Fix buffer overflow in INFO ioctl
drm/amd/powerplay: Fix hardmins not being sent to SMU for RV
drm/amdgpu: use MODE1 reset for navy_flounder by default
drm/amd/pm: correct the thermal alert temperature limit settings
drm/amdgpu: add asd fw check before loading asd
drm/amd/display: Keep current gain when ABM disable immediately
drm/amd/display: Fix passive dongle mistaken as active dongle in EDID emulation
drm/amd/display: Revert HDCP disable sequence change
drm/amd/display: Send DISPLAY_OFF after power down on boot
drm/amdgpu/gfx10: refine mgcg setting
drm/amd/pm: correct Vega20 swctf limit setting
drm/amd/pm: correct Vega12 swctf limit setting
drm/amd/pm: correct Vega10 swctf limit setting
drm/amd/pm: set VCN pg per instances
drm/amd/pm: enable run_btc callback for sienna_cichlid
drivers: gpu: amd: Initialize amdgpu_dm_backlight_caps object to 0 in amdgpu_dm_update_backlight_caps
drm/amd/display: Reject overlay plane configurations in multi-display scenarios
...
James Morse [Fri, 21 Aug 2020 14:07:07 +0000 (15:07 +0100)]
KVM: arm64: Set HCR_EL2.PTW to prevent AT taking synchronous exception
AT instructions do a translation table walk and return the result, or
the fault in PAR_EL1. KVM uses these to find the IPA when the value is
not provided by the CPU in HPFAR_EL1.
If a translation table walk causes an external abort it is taken as an
exception, even if it was due to an AT instruction. (DDI0487F.a's D5.2.11
"Synchronous faults generated by address translation instructions")
While we previously made KVM resilient to exceptions taken due to AT
instructions, the device access causes mismatched attributes, and may
occur speculatively. Prevent this, by forbidding a walk through memory
described as device at stage2. Now such AT instructions will report a
stage2 fault.
Such a fault will cause KVM to restart the guest. If the AT instructions
always walk the page tables, but guest execution uses the translation cached
in the TLB, the guest can't make forward progress until the TLB entry is
evicted. This isn't a problem, as since commit 5dcd0fdbb492 ("KVM: arm64:
Defer guest entry when an asynchronous exception is pending"), KVM will
return to the host to process IRQs allowing the rest of the system to keep
running.
Cc: stable@vger.kernel.org # <v5.3: 5dcd0fdbb492 ("KVM: arm64: Defer guest entry when an asynchronous exception is pending") Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
James Morse [Fri, 21 Aug 2020 14:07:06 +0000 (15:07 +0100)]
KVM: arm64: Survive synchronous exceptions caused by AT instructions
KVM doesn't expect any synchronous exceptions when executing, any such
exception leads to a panic(). AT instructions access the guest page
tables, and can cause a synchronous external abort to be taken.
The arm-arm is unclear on what should happen if the guest has configured
the hardware update of the access-flag, and a memory type in TCR_EL1 that
does not support atomic operations. B2.2.6 "Possible implementation
restrictions on using atomic instructions" from DDI0487F.a lists
synchronous external abort as a possible behaviour of atomic instructions
that target memory that isn't writeback cacheable, but the page table
walker may behave differently.
Make KVM robust to synchronous exceptions caused by AT instructions.
Add a get_user() style helper for AT instructions that returns -EFAULT
if an exception was generated.
While KVM's version of the exception table mixes synchronous and
asynchronous exceptions, only one of these can occur at each location.
Re-enter the guest when the AT instructions take an exception on the
assumption the guest will take the same exception. This isn't guaranteed
to make forward progress, as the AT instructions may always walk the page
tables, but guest execution may use the translation cached in the TLB.
This isn't a problem, as since commit 5dcd0fdbb492 ("KVM: arm64: Defer guest
entry when an asynchronous exception is pending"), KVM will return to the
host to process IRQs allowing the rest of the system to keep running.
Cc: stable@vger.kernel.org # <v5.3: 5dcd0fdbb492 ("KVM: arm64: Defer guest entry when an asynchronous exception is pending") Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
James Morse [Fri, 21 Aug 2020 14:07:05 +0000 (15:07 +0100)]
KVM: arm64: Add kvm_extable for vaxorcism code
KVM has a one instruction window where it will allow an SError exception
to be consumed by the hypervisor without treating it as a hypervisor bug.
This is used to consume asynchronous external abort that were caused by
the guest.
As we are about to add another location that survives unexpected exceptions,
generalise this code to make it behave like the host's extable.
KVM's version has to be mapped to EL2 to be accessible on nVHE systems.
The SError vaxorcism code is a one instruction window, so has two entries
in the extable. Because the KVM code is copied for VHE and nVHE, we end up
with four entries, half of which correspond with code that isn't mapped.
Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
vdso32 should only be installed if CONFIG_COMPAT_VDSO is enabled,
since it's not even supposed to be compiled otherwise, and arm64
builds without a 32bit crosscompiler will fail.
Fixes: 8d75785a8142 ("ARM64: vdso32: Install vdso32 from vdso_install") Signed-off-by: Frank van der Linden <fllinden@amazon.com> Cc: stable@vger.kernel.org [5.4+] Link: https://lore.kernel.org/r/20200827234012.19757-1-fllinden@amazon.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Sami Tolvanen [Thu, 27 Aug 2020 20:36:08 +0000 (13:36 -0700)]
arm64: use a common .arch preamble for inline assembly
Commit 7c78f67e9bd9 ("arm64: enable tlbi range instructions") breaks
LLVM's integrated assembler, because -Wa,-march is only passed to
external assemblers and therefore, the new instructions are not enabled
when IAS is used.
This change adds a common architecture version preamble, which can be
used in inline assembly blocks that contain instructions that require
a newer architecture version, and uses it to fix __TLBI_0 and __TLBI_1
with ARM64_TLB_RANGE.
Lee Jones [Wed, 19 Aug 2020 08:16:50 +0000 (09:16 +0100)]
mfd: mfd-core: Ensure disabled devices are ignored without error
Commit e49aa9a9bd22 ("mfd: core: Make a best effort attempt to match
devices with the correct of_nodes") changed the semantics for disabled
devices in mfd_add_device(). Instead of silently ignoring a disabled
child device, an error was returned. On receipt of the error
mfd_add_devices() the precedes to remove *all* child devices and
returns an all-failed error to the caller, which will inevitably fail
the parent device as well.
This patch reverts back to the old semantics and ignores child devices
which are disabled in Device Tree.
Fixes: e49aa9a9bd22 ("mfd: core: Make a best effort attempt to match devices with the correct of_nodes") Reported-by: Icenowy Zheng <icenowy@aosc.io> Tested-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Yufen Yu [Thu, 20 Aug 2020 13:22:05 +0000 (09:22 -0400)]
md/raid5: make sure stripe_size as power of two
Commit 3b5408b98e4d ("md/raid5: support config stripe_size by sysfs
entry") make stripe_size as a configurable value. It just requires
stripe_size as multiple of 4KB.
In fact, we should make sure stripe_size as power of two. Otherwise,
stripe_shift which is the result of ilog2 can not represent the real
stripe_size. Then, stripe_hash() and stripe_hash_locks_hash() may
get unexpected value.
Fixes: 3b5408b98e4d ("md/raid5: support config stripe_size by sysfs entry") Signed-off-by: Yufen Yu <yuyufen@huawei.com> Signed-off-by: Song Liu <songliubraving@fb.com>
Jens Axboe [Thu, 27 Aug 2020 22:46:24 +0000 (16:46 -0600)]
io_uring: don't bounce block based -EAGAIN retry off task_work
These events happen inline from submission, so there's no need to
bounce them through the original task. Just set them up for retry
and issue retry directly instead of going over task_work.
Jens Axboe [Thu, 27 Aug 2020 22:40:19 +0000 (16:40 -0600)]
io_uring: fix IOPOLL -EAGAIN retries
This normally isn't hit, as polling is mostly done on NVMe with deep
queue depths. But if we do run into request starvation, we need to
ensure that retries are properly serialized.
Reported-by: Andres Freund <andres@anarazel.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
Dan Carpenter [Wed, 26 Aug 2020 11:33:30 +0000 (14:33 +0300)]
dma-pool: Fix an uninitialized variable bug in atomic_pool_expand()
The "page" pointer can be used with out being initialized.
Fixes: d7e673ec2c8e ("dma-pool: Only allocate from CMA when in same memory zone") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Simon Leiner [Tue, 25 Aug 2020 09:31:53 +0000 (11:31 +0200)]
arm/xen: Add misuse warning to virt_to_gfn
As virt_to_gfn uses virt_to_phys, it will return invalid addresses when
used with vmalloc'd addresses. This patch introduces a warning, when
virt_to_gfn is used in this way.
Simon Leiner [Tue, 25 Aug 2020 09:31:52 +0000 (11:31 +0200)]
xen/xenbus: Fix granting of vmalloc'd memory
On some architectures (like ARM), virt_to_gfn cannot be used for
vmalloc'd memory because of its reliance on virt_to_phys. This patch
introduces a check for vmalloc'd addresses and obtains the PFN using
vmalloc_to_pfn in that case.
Thomas Gleixner [Tue, 25 Aug 2020 15:22:58 +0000 (17:22 +0200)]
XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt
XEN data pointer which contains XEN specific information.
handler data is meant for interrupt handlers and not for storing irq chip
specific information as some devices require handler data to store internal
per interrupt information, e.g. pinctrl/GPIO chained interrupt handlers.
This obviously creates a conflict of interests and crashes the machine
because the XEN pointer is overwritten by the driver pointer.
As the XEN data is not handler specific it should be stored in
irqdesc::irq_data::chip_data instead.
A simple sed s/irq_[sg]et_handler_data/irq_[sg]et_chip_data/ cures that.
Cc: stable@vger.kernel.org Reported-by: Roman Shaposhnik <roman@zededa.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Roman Shaposhnik <roman@zededa.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/87lfi2yckt.fsf@nanos.tec.linutronix.de Signed-off-by: Juergen Gross <jgross@suse.com>
Dave Airlie [Thu, 27 Aug 2020 02:44:04 +0000 (12:44 +1000)]
Merge tag 'amd-drm-fixes-5.9-2020-08-26' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
amd-drm-fixes-5.9-2020-08-26:
amdgpu:
- Misc display fixes
- Backlight fixes
- MPO fix for DCN1
- Fixes for Sienna Cichlid
- Fixes for Navy Flounder
- Vega SW CTF fixes
- SMU fix for Raven
- Fix a possible overflow in INFO ioctl
- Gfx10 clockgating fix
Dave Airlie [Thu, 27 Aug 2020 02:36:32 +0000 (12:36 +1000)]
Merge tag 'drm-msm-fixes-2020-08-24' of https://gitlab.freedesktop.org/drm/msm into drm-fixes
Some fixes for v5.9 plus the one opp/bandwidth scaling patch ("drm:
msm: a6xx: use dev_pm_opp_set_bw to scale DDR") which was not included
in the initial pull due to dependency on patch landing thru OPP tree
Dave Airlie [Thu, 27 Aug 2020 02:34:06 +0000 (12:34 +1000)]
Merge branch 'etnaviv/fixes' of https://git.pengutronix.de/git/lst/linux into drm-fixes
Two fixes:
One fixes a bad interaction with the DRM scheduler, leading to some dma
fences not getting signalled after hitting the job timeout. The other
one fixes a GPU init regression, as apparently one old core doesn't
likes us reading some of the identification registers.
Jens Axboe [Thu, 27 Aug 2020 00:58:26 +0000 (18:58 -0600)]
io_uring: clear req->result on IOPOLL re-issue
Make sure we clear req->result, which was set to -EAGAIN for retry
purposes, when moving it to the reissue list. Otherwise we can end up
retrying a request more than once, which leads to weird results in
the io-wq handling (and other spots).
Cc: stable@vger.kernel.org Reported-by: Andres Freund <andres@anarazel.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
Dinghao Liu [Wed, 26 Aug 2020 13:24:58 +0000 (21:24 +0800)]
drm/amd/display: Fix memleak in amdgpu_dm_mode_config_init
When amdgpu_display_modeset_create_props() fails, state and
state->context should be freed to prevent memleak. It's the
same when amdgpu_dm_audio_init() fails.
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Wayne Lin [Tue, 18 Aug 2020 03:19:42 +0000 (11:19 +0800)]
drm/amd/display: Retry AUX write when fail occurs
[Why]
In dm_dp_aux_transfer() now, we forget to handle AUX_WR fail cases. We
suppose every write wil get done successfully and hence some AUX
commands might not sent out indeed.
[How]
Check if AUX_WR success. If not, retry it.
Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Tue, 25 Aug 2020 15:43:45 +0000 (11:43 -0400)]
drm/amdgpu: Fix buffer overflow in INFO ioctl
The values for "se_num" and "sh_num" come from the user in the ioctl.
They can be in the 0-255 range but if they're more than
AMDGPU_GFX_MAX_SE (4) or AMDGPU_GFX_MAX_SH_PER_SE (2) then it results in
an out of bounds read.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
drm/amd/powerplay: Fix hardmins not being sent to SMU for RV
[Why]
DC uses these to raise the voltage as needed for higher dispclk/dppclk
and to ensure that we have enough bandwidth to drive the displays.
There's a bug preventing these from actuially sending messages since
it's checking the actual clock (which is 0) instead of the incoming
clock (which shouldn't be 0) when deciding to send the hardmin.
[How]
Check the clocks != 0 instead of the actual clocks.
Fixes: 9ed9203c3ee7 ("drm/amd/powerplay: rv dal-pplib interface refactor powerplay part") Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
Samson Tam [Thu, 13 Aug 2020 14:50:21 +0000 (10:50 -0400)]
drm/amd/display: Fix passive dongle mistaken as active dongle in EDID emulation
[Why]
dongle_type is set during dongle connection but for passive dongles,
dongle_type is not set. If user starts with an active dongle and
then switches to a passive dongle, it will still report as an active
dongle. Trying to emulate the wrong connecter type results in display
not lighting up.
[How]
Set dpcd_caps.dongle_type for passive dongles in detect_dp().
Signed-off-by: Samson Tam <Samson.Tam@amd.com> Reviewed-by: Joshua Aberback <Joshua.Aberback@amd.com> Acked-by: Eryk Brol <eryk.brol@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Revert HDCP disable sequence change that blanks stream before
disabling HDCP. PSP and HW teams are currently investigating the
root cause of why HDCP cannot be disabled before stream blank,
which is expected to work without issues.
Signed-off-by: Jaehyun Chung <jaehyun.chung@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Acked-by: Eryk Brol <eryk.brol@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Evan Quan [Fri, 21 Aug 2020 04:21:30 +0000 (12:21 +0800)]
drm/amd/pm: correct Vega20 swctf limit setting
Correct the Vega20 thermal swctf limit.
Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
Evan Quan [Fri, 21 Aug 2020 04:18:58 +0000 (12:18 +0800)]
drm/amd/pm: correct Vega12 swctf limit setting
Correct the Vega12 thermal swctf limit.
Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
Furquan Shaikh [Thu, 20 Aug 2020 07:52:41 +0000 (00:52 -0700)]
drivers: gpu: amd: Initialize amdgpu_dm_backlight_caps object to 0 in amdgpu_dm_update_backlight_caps
In `amdgpu_dm_update_backlight_caps()`, there is a local
`amdgpu_dm_backlight_caps` object that is filled in by
`amdgpu_acpi_get_backlight_caps()`. However, this object is
uninitialized before the call and hence the subsequent check for
aux_support can fail since it is not initialized by
`amdgpu_acpi_get_backlight_caps()` as well. This change initializes
this local `amdgpu_dm_backlight_caps` object to 0.
Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Furquan Shaikh <furquan@google.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Reject overlay plane configurations in multi-display scenarios
[Why]
These aren't stable on some platform configurations when driving
multiple displays, especially on higher resolution.
In particular the delay in asserting p-state and validating from
x86 outweights any power or performance benefit from the hardware
composition.
Under some configurations this will manifest itself as extreme stutter
or unresponsiveness especially when combined with cursor movement.
[How]
Disable these for now. Exposing overlays to userspace doesn't guarantee
that they'll be able to use them in any and all configurations and it's
part of the DRM contract to have userspace gracefully handle validation
failures when they occur.
Valdiation occurs as part of DC and this in particular affects RV, so
disable this in dcn10_global_validation.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: use correct scale for actual_brightness
Documentation for sysfs backlight level interface requires that
values in both 'brightness' and 'actual_brightness' files are
interpreted to be in range from 0 to the value given in the
'max_brightness' file.
With amdgpu, max_brightness gives 255, and values written by the user
into 'brightness' are internally rescaled to a wider range. However,
reading from 'actual_brightness' gives the raw register value without
inverse rescaling. This causes issues for various userspace tools such
as PowerTop and systemd that expect the value to be in the correct
range.
Introduce a helper to retrieve internal backlight range. Use it to
reimplement 'convert_brightness' as 'convert_brightness_from_user' and
introduce 'convert_brightness_to_user'.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=203905
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1242 Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alexander Monakov <amonakov@ispras.ru> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
Linus Torvalds [Wed, 26 Aug 2020 17:58:20 +0000 (10:58 -0700)]
Merge tag 'tty-5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty/serial fixes from Greg KH:
"Here are a few small TTY/Serial/vt fixes for 5.9-rc3
Included in here are:
- qcom serial fixes
- vt ioctl and core bugfixes
- pl011 serial driver fixes
- 8250 serial driver fixes
- other misc serial driver fixes
and for good measure:
- fbcon fix for syzbot found problem.
All of these have been in linux-next for a while with no reported
issues"
* tag 'tty-5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
tty: serial: imx: add dependence and build for earlycon
serial: samsung: Removes the IRQ not found warning
serial: 8250: change lock order in serial8250_do_startup()
serial: stm32: avoid kernel warning on absence of optional IRQ
serial: pl011: Fix oops on -EPROBE_DEFER
serial: pl011: Don't leak amba_ports entry on driver register error
serial: 8250_exar: Fix number of ports for Commtech PCIe cards
tty: serial: qcom_geni_serial: Drop __init from qcom_geni_console_setup
serial: qcom_geni_serial: Fix recent kdb hang
vt_ioctl: change VT_RESIZEX ioctl to check for error return from vc_resize()
fbcon: prevent user font height or width change from causing potential out-of-bounds access
vt: defer kfree() of vc_screenbuf in vc_do_resize()
Linus Torvalds [Wed, 26 Aug 2020 17:50:50 +0000 (10:50 -0700)]
Merge tag 'char-misc-5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver fixes from Greg KH:
"Here are some small char and misc and other driver subsystem fixes for
5.9-rc3.
The majority of these are tiny habanalabs driver fixes, but also in
here are:
- speakup build fixes now that it is out of staging and got exposed
to more build systems all of a sudden
- mei driver fix
All of these have been in linux-next for a while with no reported
issues"
* tag 'char-misc-5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
habanalabs: correctly report inbound pci region cfg error
habanalabs: check correct vmalloc return code
habanalabs: validate FW file size
habanalabs: fix incorrect check on failed workqueue create
habanalabs: set max power according to card type
habanalabs: proper handling of alloc size in coresight
habanalabs: set clock gating according to mask
habanalabs: verify user input in cs_ioctl_signal_wait
habanalabs: Fix a loop in gaudi_extract_ecc_info()
habanalabs: Fix memory corruption in debugfs
habanalabs: validate packet id during CB parse
habanalabs: Validate user address before mapping
habanalabs: unmap PCI bars upon iATU failure
mei: hdcp: fix mei_hdcp_verify_mprime() input parameter
speakup: only build serialio when ISA is enabled
speakup: Fix wait_for_xmitr for ttyio case
Linus Torvalds [Wed, 26 Aug 2020 17:44:15 +0000 (10:44 -0700)]
Merge tag 'hyperv-fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux
Pull hyperv fixes from Wei Liu:
"Two patches from Vineeth to improve Hyper-V timesync facility"
* tag 'hyperv-fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux:
hv_utils: drain the timesync packets on onchannelcallback
hv_utils: return error if host timesysnc update is stale
Linus Torvalds [Wed, 26 Aug 2020 17:40:09 +0000 (10:40 -0700)]
Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
Pull virtio bugfixes from Michael Tsirkin:
"A couple vdpa and vhost bugfixes"
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
vdpa/mlx5: Avoid warnings about shifts on 32-bit platforms
vhost-iotlb: fix vhost_iotlb_itree_next() documentation
vdpa: ifcvf: free config irq in ifcvf_free_irq()
vdpa: ifcvf: return err when fail to request config irq
Jens Axboe [Wed, 26 Aug 2020 16:36:20 +0000 (10:36 -0600)]
io_uring: make offset == -1 consistent with preadv2/pwritev2
The man page for io_uring generally claims were consistent with what
preadv2 and pwritev2 accept, but turns out there's a slight discrepancy
in how offset == -1 is handled for pipes/streams. preadv doesn't allow
it, but preadv2 does. This currently causes io_uring to return -EINVAL
if that is attempted, but we should allow that as documented.
This change makes us consistent with preadv2/pwritev2 for just passing
in a NULL ppos for streams if the offset is -1.
Sven Schnelle [Thu, 20 Aug 2020 07:48:23 +0000 (09:48 +0200)]
s390: don't trace preemption in percpu macros
Since commit a21ee6055c30 ("lockdep: Change hardirq{s_enabled,_context}
to per-cpu variables") the lockdep code itself uses percpu variables. This
leads to recursions because the percpu macros are calling preempt_enable()
which might call trace_preempt_on().
Martijn Coenen [Tue, 25 Aug 2020 07:18:29 +0000 (09:18 +0200)]
loop: Set correct device size when using LOOP_CONFIGURE
The device size calculation was done before processing the loop
configuration, which meant that the we set the size on the underlying
block device incorrectly in case lo_offset/lo_sizelimit were set in the
configuration. Delay computing the size until we've setup the device
parameters correctly.
Hou Pu [Mon, 10 Aug 2020 12:00:44 +0000 (08:00 -0400)]
nbd: restore default timeout when setting it to zero
If we configured io timeout of nbd0 to 100s. Later after we
finished using it, we configured nbd0 again and set the io
timeout to 0. We expect it would timeout after 30 seconds
and keep retry. But in fact we could not change the timeout
when we set it to 0. the timeout is still the original 100s.
So change the timeout to default 30s when we set it to zero.
It also behaves same as commit 2da22da57348 ("nbd: fix zero
cmd timeout handling v2").
It becomes more important if we were reconfigure a nbd device
and the io timeout it set to zero. Because it could take 30s
to detect the new socket and thus io could be completed more
quickly compared to 100s.
Signed-off-by: Hou Pu <houpu@bytedance.com> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
vdpa/mlx5: Avoid warnings about shifts on 32-bit platforms
Clang warns several times when building for 32-bit ARM along the lines
of:
drivers/vdpa/mlx5/net/mlx5_vnet.c:1462:31: warning: shift count >= width
of type [-Wshift-count-overflow]
ndev->mvdev.mlx_features |= BIT(VIRTIO_F_VERSION_1);
^~~~~~~~~~~~~~~~~~~~~~~
This is related to the BIT macro, which uses an unsigned long literal,
which is 32-bit on ARM so having a shift equal to or larger than 32 will
cause this warning, such as the above, where VIRTIO_F_VERSION_1 is 32.
To avoid this, use BIT_ULL, which will be an unsigned long long. This
matches the size of the features field throughout this driver, which is
u64 so there should be no functional change.
This patch contains trivial changes for the vhost_iotlb_itree_next()
documentation, fixing the function name and the description of
first argument (@map).
Jason Wang [Thu, 23 Jul 2020 09:12:54 +0000 (17:12 +0800)]
vdpa: ifcvf: free config irq in ifcvf_free_irq()
We don't free config irq in ifcvf_free_irq() which will trigger a
BUG() in pci core since we try to free the vectors that has an
action. Fixing this by recording the config irq in ifcvf_hw structure
and free it in ifcvf_free_irq().
Fixes: e7991f376a4d ("ifcvf: implement config interrupt in IFCVF") Cc: Zhu Lingshan <lingshan.zhu@intel.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Link: https://lore.kernel.org/r/20200723091254.20617-2-jasowang@redhat.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Zhu Lingshan <lingshan.zhu@intel.com> Fixes: e7991f376a4d ("ifcvf: implement config interrupt in IFCVF") Cc: Zhu Lingshan <a class="moz-txt-link-rfc2396E" href="mailto:lingshan.zhu@intel.com"><lingshan.zhu@intel.com></a> Signed-off-by: Jason Wang <a class="moz-txt-link-rfc2396E" href="mailto:jasowang@redhat.com"><jasowang@redhat.com></a>
Marek Szyprowski [Mon, 13 Jul 2020 07:07:08 +0000 (09:07 +0200)]
drm/exynos: gem: Fix sparse warning
kvaddr element of the exynos_gem object points to a memory buffer, thus
it should not have a __iomem annotation. Then, to avoid a warning or
casting on assignment to fbi structure, the screen_buffer element of the
union should be used instead of the screen_base.
Reported-by: kernel test robot <lkp@intel.com> Suggested-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
Linus Torvalds [Tue, 25 Aug 2020 18:59:23 +0000 (11:59 -0700)]
Merge tag 'm68knommu-for-v5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu
Pull m68knommu fix from Greg Ungerer:
"Only a single fix for the binfmt_flat loader (reverting a recent
change)"
* tag 'm68knommu-for-v5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu:
binfmt_flat: revert "binfmt_flat: don't offset the data start"
Jens Axboe [Tue, 25 Aug 2020 18:59:22 +0000 (12:59 -0600)]
io_uring: ensure read requests go through -ERESTART* transformation
We need to call kiocb_done() for any ret < 0 to ensure that we always
get the proper -ERESTARTSYS (and friends) transformation done.
At some point this should be tied into general error handling, so we
can get rid of the various (mostly network) related commands that check
and perform this substitution.
Linus Torvalds [Tue, 25 Aug 2020 18:42:43 +0000 (11:42 -0700)]
Merge tag 'libnvdimm-fix-v5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
Pull libnvdimm fixes from Vishal Verma:
"A couple of minor fixes for things merged in 5.9-rc1.
One is an out-of-bounds access caught by KASAN, and the second is a
tweak to some overzealous logging about dax support even for
traditional block devices which was unnecessary"
* tag 'libnvdimm-fix-v5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
dax: do not print error message for non-persistent memory block device
libnvdimm: KASAN: global-out-of-bounds Read in internal_create_group
Jens Axboe [Tue, 25 Aug 2020 18:27:50 +0000 (12:27 -0600)]
io_uring: don't use poll handler if file can't be nonblocking read/written
There's no point in using the poll handler if we can't do a nonblocking
IO attempt of the operation, since we'll need to go async anyway. In
fact this is actively harmful, as reading from eg pipes won't return 0
to indicate EOF.
Linus Torvalds [Tue, 25 Aug 2020 18:13:29 +0000 (11:13 -0700)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid
Pull HID fixes from Jiri Kosina:
- regression fix / revert of a commit that intended to reduce probing
delay by ~50ms, but introduced a race that causes quite a few devices
not to enumerate, or get stuck on first IRQ
- buffer overflow fix in hiddev, from Peilin Ye
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
Revert "HID: usbhid: do not sleep when opening device"
HID: hiddev: Fix slab-out-of-bounds write in hiddev_ioctl_usage()
HID: quirks: Always poll three more Lenovo PixArt mice
HID: i2c-hid: Always sleep 60ms after I2C_HID_PWR_ON commands
HID: macally: Constify macally_id_table
HID: cougar: Constify cougar_id_table
Jens Axboe [Tue, 25 Aug 2020 13:58:00 +0000 (07:58 -0600)]
io_uring: fix imbalanced sqo_mm accounting
We do the initial accounting of locked_vm and pinned_vm before we have
setup ctx->sqo_mm, which means we can end up having not accounted the
memory at setup time, but still decrement it when we exit. This causes
an imbalance in the accounting.
Setup ctx->sqo_mm earlier in io_uring_create(), before we do the first
accounting of mm->{locked,pinned}_vm. This also unifies the state
grabbing for the ctx, and eliminates a failure case in
io_sq_offload_start().
Fixes: f74441e6311a ("io_uring: account locked memory before potential error case") Reported-by: Robert M. Muncrief <rmuncrief@humanavance.com> Reported-by: Niklas Schnelle <schnelle@linux.ibm.com> Tested-by: Niklas Schnelle <schnelle@linux.ibm.com> Tested-by: Robert M. Muncrief <rmuncrief@humanavance.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
PM: sleep: core: Fix the handling of pending runtime resume requests
It has been reported that system-wide suspend may be aborted in the
absence of any wakeup events due to unforseen interactions of it with
the runtume PM framework.
One failing scenario is when there are multiple devices sharing an
ACPI power resource and runtime-resume needs to be carried out for
one of them during system-wide suspend (for example, because it needs
to be reconfigured before the whole system goes to sleep). In that
case, the runtime-resume of that device involves turning the ACPI
power resource "on" which in turn causes runtime-resume requests
to be queued up for all of the other devices sharing it. Those
requests go to the runtime PM workqueue which is frozen during
system-wide suspend, so they are not actually taken care of until
the resume of the whole system, but the pm_runtime_barrier()
call in __device_suspend() sees them and triggers system wakeup
events for them which then cause the system-wide suspend to be
aborted if wakeup source objects are in active use.
Of course, the logic that leads to triggering those wakeup events is
questionable in the first place, because clearly there are cases in
which a pending runtime resume request for a device is not connected
to any real wakeup events in any way (like the one above). Moreover,
it is racy, because the device may be resuming already by the time
the pm_runtime_barrier() runs and so if the driver doesn't take care
of signaling the wakeup event as appropriate, it will be lost.
However, if the driver does take care of that, the extra
pm_wakeup_event() call in the core is redundant.
Accordingly, drop the conditional pm_wakeup_event() call fron
__device_suspend() and make the latter call pm_runtime_barrier()
alone. Also modify the comment next to that call to reflect the new
code and extend it to mention the need to avoid unwanted interactions
between runtime PM and system-wide device suspend callbacks.
Fixes: 1e2ef05bb8cf8 ("PM: Limit race conditions between runtime PM and system sleep (v2)") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Utkarsh H Patel <utkarsh.h.patel@intel.com> Tested-by: Utkarsh H Patel <utkarsh.h.patel@intel.com> Tested-by: Pengfei Xu <pengfei.xu@intel.com> Cc: All applicable <stable@vger.kernel.org>
ACPI: OSL: Prevent acpi_release_memory() from returning too early
After commit 1757659d022b ("ACPI: OSL: Implement deferred unmapping
of ACPI memory") in some cases acpi_release_memory() may return
before the target memory mappings actually go away, because they
are released asynchronously now.
Prevent it from returning prematurely by making it wait for the next
RCU grace period to elapse, for all of the RCU callbacks to complete
and for all of the scheduled work items to be flushed before
returning.
Fixes: 1757659d022b ("ACPI: OSL: Implement deferred unmapping of ACPI memory") Reported-by: Kenneth R. Crudup <kenny@panix.com> Tested-by: Kenneth R. Crudup <kenny@panix.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Jens Axboe [Mon, 24 Aug 2020 17:45:26 +0000 (11:45 -0600)]
io_uring: revert consumed iov_iter bytes on error
Some consumers of the iov_iter will return an error, but still have
bytes consumed in the iterator. This is an issue for -EAGAIN, since we
rely on a sane iov_iter state across retries.
Fix this by ensuring that we revert consumed bytes, if any, if the file
operations have consumed any bytes from iterator. This is similar to what
generic_file_read_iter() does, and is always safe as we have the previous
bytes count handy already.
The reason for this is that omapdrm calls drm_crtc_vblank_on() while
holding event_lock taken with spin_lock_irq().
It is not clear why drm_crtc_vblank_on() and drm_crtc_vblank_get() are
called while holding event_lock. I don't see any problem with moving
those calls outside the lock, which is what this patch does.
Ray Jui [Fri, 14 Aug 2020 22:40:08 +0000 (15:40 -0700)]
i2c: iproc: Fix shifting 31 bits
Fix undefined behaviour in the iProc I2C driver by using 'BIT' marcro.
Reported-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Ray Jui <ray.jui@broadcom.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
[wsa: in commit msg, don't say 'checkpatch' but name the issue] Signed-off-by: Wolfram Sang <wsa@kernel.org>
Wolfram Sang [Mon, 17 Aug 2020 12:19:30 +0000 (14:19 +0200)]
i2c: rcar: in slave mode, clear NACK earlier
Currently, a NACK in slave mode is set/cleared when SCL is held low by
the IP core right before the bit is about to be pushed out. This is too
late for clearing and then a NACK from the previous byte is still used
for the current one. Now, let's clear the NACK right after we detected
the STOP condition following the NACK.
Fixes: de20d1857dd6 ("i2c: rcar: add slave support") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
projects / mirror_ubuntu-kernels.git / log