From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
This is the start of the stable review cycle for the 4.14.225 release.
There are 20 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Fri, 12 Mar 2021 13:23:09 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.225-r…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.14.225-rc1
AngeloGioacchino Del Regno <angelogioacchino.delregno(a)somainline.org>
drm/msm/a5xx: Remove overwriting A5XX_PC_DBG_ECO_CNTL register
Aswath Govindraju <a-govindraju(a)ti.com>
misc: eeprom_93xx46: Add quirk to support Microchip 93LC46B eeprom
Bjorn Helgaas <bhelgaas(a)google.com>
PCI: Add function 1 DMA alias quirk for Marvell 9215 SATA controller
Hans de Goede <hdegoede(a)redhat.com>
platform/x86: acer-wmi: Add ACER_CAP_KBD_DOCK quirk for the Aspire Switch 10E SW3-016
Hans de Goede <hdegoede(a)redhat.com>
platform/x86: acer-wmi: Add support for SW_TABLET_MODE on Switch devices
Hans de Goede <hdegoede(a)redhat.com>
platform/x86: acer-wmi: Add ACER_CAP_SET_FUNCTION_MODE capability flag
Hans de Goede <hdegoede(a)redhat.com>
platform/x86: acer-wmi: Add new force_caps module parameter
Hans de Goede <hdegoede(a)redhat.com>
platform/x86: acer-wmi: Cleanup accelerometer device handling
Hans de Goede <hdegoede(a)redhat.com>
platform/x86: acer-wmi: Cleanup ACER_CAP_FOO defines
Tsuchiya Yuto <kitakar(a)gmail.com>
mwifiex: pcie: skip cancel_work_sync() on reset failure path
Andrey Ryabinin <arbn(a)yandex-team.com>
iommu/amd: Fix sleeping in atomic in increase_address_space()
Jeffle Xu <jefflexu(a)linux.alibaba.com>
dm table: fix zoned iterate_devices based device capability checks
Jeffle Xu <jefflexu(a)linux.alibaba.com>
dm table: fix DAX iterate_devices based device capability checks
Jeffle Xu <jefflexu(a)linux.alibaba.com>
dm table: fix iterate_devices based device capability checks
Dan Carpenter <dan.carpenter(a)oracle.com>
rsxx: Return -EFAULT if copy_to_user() fails
Colin Ian King <colin.king(a)canonical.com>
ALSA: ctxfi: cthw20k2: fix mask on conf to allow 4 bits
Antonio Borneo <borneo.antonio(a)gmail.com>
usbip: tools: fix build error for multiple definition
Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
PM: runtime: Update device status before letting suppliers suspend
Ira Weiny <ira.weiny(a)intel.com>
btrfs: fix raid6 qstripe kmap
David Sterba <dsterba(a)suse.com>
btrfs: raid56: simplify tracking of Q stripe presence
-------------
Diffstat:
Makefile | 4 +-
drivers/base/power/runtime.c | 62 ++++++----
drivers/block/rsxx/core.c | 8 +-
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 -
drivers/iommu/amd_iommu.c | 10 +-
drivers/md/dm-table.c | 168 ++++++++++++---------------
drivers/misc/eeprom/eeprom_93xx46.c | 15 +++
drivers/net/wireless/marvell/mwifiex/pcie.c | 18 ++-
drivers/net/wireless/marvell/mwifiex/pcie.h | 2 +
drivers/pci/quirks.c | 3 +
drivers/platform/x86/acer-wmi.c | 169 +++++++++++++++++++++++-----
fs/btrfs/raid56.c | 58 ++++------
include/linux/eeprom_93xx46.h | 2 +
sound/pci/ctxfi/cthw20k2.c | 2 +-
tools/usb/usbip/libsrc/usbip_host_common.c | 2 +-
15 files changed, 326 insertions(+), 199 deletions(-)
Hello stable maintainers,
While working on some backports I'm about to send hopefully today or
tomorrow, I was curious why the convention seems to be for folks to
use "commit <sha> upstream." in commit messages? I know that's what's
in https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#opt…,
but I was curious whether the format from `git cherry-pick -xs <sha>`
is not acceptable? I assume there's context as to why not? It is nice
to have that info uniformly near the top, but I find myself having to
cherry-pick then amend a lot. Or is there an option in git to
automate the stable kernel's preferred style?
--
Thanks,
~Nick Desaulniers
The patch titled
Subject: mm/oom_kill: ensure MMU notifier range_end() is paired with range_start()
has been removed from the -mm tree. Its filename was
mm-oom_kill-ensure-mmu-notifier-range_end-is-paired-with-range_start.patch
This patch was dropped because an updated version will be merged
------------------------------------------------------
From: Sean Christopherson <seanjc(a)google.com>
Subject: mm/oom_kill: ensure MMU notifier range_end() is paired with range_start()
Invoke the MMU notifier's .invalidate_range_end() callbacks even if one of
the .invalidate_range_start() callbacks failed. If there are multiple
notifiers, the notifier that did not fail may have performed actions in
its ...start() that it expects to unwind via ...end(). Per the
mmu_notifier_ops documentation, ...start() and ...end() must be paired.
The only in-kernel usage that is fatally broken is the SGI UV GRU driver,
which effectively blocks and sleeps fault handlers during ...start(), and
unblocks/wakes the handlers during ...end(). But, the only users that can
fail ...start() are the i915 and Nouveau drivers, which are unlikely to
collide with the SGI driver.
KVM is the only other user of ...end(), and while KVM also blocks fault
handlers in ...start(), the fault handlers do not sleep and originate in
killable ioctl() calls. So while it's possible for the i915 and Nouveau
drivers to collide with KVM, the bug is benign for KVM since the process
is dying and KVM's guest is about to be terminated.
So, as of today, the bug is likely benign. But, that may not always be
true, e.g. there is a potential use case for blocking memslot updates in
KVM while an invalidation is in-progress, and failure to unblock would
result in said updates being blocked indefinitely and hanging.
Found by inspection. Verified by adding a second notifier in KVM that
periodically returns -EAGAIN on non-blockable ranges, triggering OOM, and
observing that KVM exits with an elevated notifier count.
Link: https://lkml.kernel.org/r/20210310213117.1444147-1-seanjc@google.com
Fixes: 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu notifiers")
Signed-off-by: Sean Christopherson <seanjc(a)google.com>
Reviewed-by: Ben Gardon <bgardon(a)google.com>
Cc: David Rientjes <rientjes(a)google.com>
Cc: Jason Gunthorpe <jgg(a)ziepe.ca>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: "Jérôme Glisse" <jglisse(a)redhat.com>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: Johannes Weiner <hannes(a)cmpxchg.org>
Cc: Dimitri Sivanich <dimitri.sivanich(a)hpe.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/oom_kill.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
--- a/mm/oom_kill.c~mm-oom_kill-ensure-mmu-notifier-range_end-is-paired-with-range_start
+++ a/mm/oom_kill.c
@@ -546,12 +546,10 @@ bool __oom_reap_task_mm(struct mm_struct
vma, mm, vma->vm_start,
vma->vm_end);
tlb_gather_mmu(&tlb, mm);
- if (mmu_notifier_invalidate_range_start_nonblock(&range)) {
- tlb_finish_mmu(&tlb);
+ if (!mmu_notifier_invalidate_range_start_nonblock(&range))
+ unmap_page_range(&tlb, vma, range.start, range.end, NULL);
+ else
ret = false;
- continue;
- }
- unmap_page_range(&tlb, vma, range.start, range.end, NULL);
mmu_notifier_invalidate_range_end(&range);
tlb_finish_mmu(&tlb);
}
_
Patches currently in -mm which might be from seanjc(a)google.com are
Lee sent a patchset to update Futex for 4.9, see https://www.spinics.net/lists/stable/msg443081.html,
Then Xiaoming sent a follow-up patch for it, see https://lore.kernel.org/lkml/20210225093120.GD641347@dell/.
These patchsets may also resolve following issues in 4.4.260 which have been reported in 4.9,
see https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/?h=li…
> /*
> * The task is on the way out. When the futex state is
> * FUTEX_STATE_DEAD, we know that the task has finished
> * the cleanup:
> */
> int ret = (p->futex_state = FUTEX_STATE_DEAD) ? -ESRCH : -EAGAIN;
Here may be:
int ret = (p->futex_state == FUTEX_STATE_DEAD) ? -ESRCH : -EAGAIN;
> raw_spin_unlock_irq(&p->pi_lock);
> /*
> * If the owner task is between FUTEX_STATE_EXITING and
> * FUTEX_STATE_DEAD then store the task pointer and keep
> * the reference on the task struct. The calling code will
> * drop all locks, wait for the task to reach
> * FUTEX_STATE_DEAD and then drop the refcount. This is
> * required to prevent a live lock when the current task
> * preempted the exiting task between the two states.
> */
> if (ret == -EBUSY)
And here, the variable "ret" may only be "-ESRCH" or "-EAGAIN", but not "-EBUSY".
> *exiting = p;
> else
> put_task_struct(p);
Since 074e7d515783 ("futex: Ensure the correct return value from futex_lock_pi()") has
been merged in 4.4.260, I send the remain 3 patches.
Peter Zijlstra (1):
futex: Change locking rules
Thomas Gleixner (2):
futex: Cure exit race
futex: fix dead code in attach_to_pi_owner()
kernel/futex.c | 209 +++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 177 insertions(+), 32 deletions(-)
--
2.25.4