--
Hello Dear
My name is Dr Ava Smith,a medical doctor from United States.
I have Dual citizenship which is English and French.
I will share pictures and more details about me as soon as i get
a response from you
Thanks
Ava
[Test Report]
Result: Test Pass
A total of two rounds of pending testing
a. The first round of hanging test
Number of machines: 200
Hanging test duration: 48h
Hanging test results: no walt crash problem
b. The second round of hanging test
Number of machines: 200
Hanging test duration: 72h
Hanging test results: no walt crash problem
Tested-by: wangfajie <wangfajie(a)longcheer.com>
Tested-by: liurenwang <liurenwang(a)longcheer.com>
Tested-by: zhanghui <zhanghui5(a)longcheer.com>
Tested-by: liangke <liangke1(a)xiaomi.com>
This is the start of the stable review cycle for the 5.10.164 release.
There are 64 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 Thu, 19 Jan 2023 12:45:11 +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/v5.x/stable-review/patch-5.10.164-r…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.10.164-rc2
Ferry Toth <ftoth(a)exalondelft.nl>
Revert "usb: ulpi: defer ulpi_register on ulpi_read_id timeout"
Jens Axboe <axboe(a)kernel.dk>
io_uring/io-wq: only free worker if it was allocated for creation
Jens Axboe <axboe(a)kernel.dk>
io_uring/io-wq: free worker if task_work creation is canceled
Rob Clark <robdclark(a)chromium.org>
drm/virtio: Fix GEM handle creation UAF
Johan Hovold <johan+linaro(a)kernel.org>
efi: fix NULL-deref in init error path
Mark Rutland <mark.rutland(a)arm.com>
arm64: cmpxchg_double*: hazard against entire exchange variable
Mark Rutland <mark.rutland(a)arm.com>
arm64: atomics: remove LL/SC trampolines
Mark Rutland <mark.rutland(a)arm.com>
arm64: atomics: format whitespace consistently
Peter Newman <peternewman(a)google.com>
x86/resctrl: Fix task CLOSID/RMID update race
Reinette Chatre <reinette.chatre(a)intel.com>
x86/resctrl: Use task_curr() instead of task_struct->on_cpu to prevent unnecessary IPI
Paolo Bonzini <pbonzini(a)redhat.com>
KVM: x86: Do not return host topology information from KVM_GET_SUPPORTED_CPUID
Paolo Bonzini <pbonzini(a)redhat.com>
Documentation: KVM: add API issues section
Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
iommu/mediatek-v1: Fix an error handling path in mtk_iommu_v1_probe()
Yong Wu <yong.wu(a)mediatek.com>
iommu/mediatek-v1: Add error handle for mtk_iommu_probe
Aaron Thompson <dev(a)aaront.org>
mm: Always release pages to the buddy allocator in memblock_free_late().
Gavin Li <gavinl(a)nvidia.com>
net/mlx5e: Don't support encap rules with gbp option
Rahul Rameshbabu <rrameshbabu(a)nvidia.com>
net/mlx5: Fix ptp max frequency adjustment range
Ido Schimmel <idosch(a)nvidia.com>
net/sched: act_mpls: Fix warning during failed attribute validation
Minsuk Kang <linuxlovemin(a)yonsei.ac.kr>
nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame()
Roger Pau Monne <roger.pau(a)citrix.com>
hvc/xen: lock console list traversal
Angela Czubak <aczubak(a)marvell.com>
octeontx2-af: Fix LMAC config in cgx_lmac_rx_tx_enable
Subbaraya Sundeep <sbhatta(a)marvell.com>
octeontx2-af: Map NIX block from CGX connection
Subbaraya Sundeep <sbhatta(a)marvell.com>
octeontx2-af: Update get/set resource count functions
Tung Nguyen <tung.q.nguyen(a)dektech.com.au>
tipc: fix unexpected link reset due to discovery messages
Emanuele Ghidoli <emanuele.ghidoli(a)toradex.com>
ASoC: wm8904: fix wrong outputs volume after power reactivation
Ricardo Ribalda <ribalda(a)chromium.org>
regulator: da9211: Use irq handler when ready
Eliav Farber <farbere(a)amazon.com>
EDAC/device: Fix period calculation in edac_device_reset_delay_period()
Peter Zijlstra <peterz(a)infradead.org>
x86/boot: Avoid using Intel mnemonics in AT&T syntax asm
Kajol Jain <kjain(a)linux.ibm.com>
powerpc/imc-pmu: Fix use of mutex in IRQs disabled section
Gavrilov Ilia <Ilia.Gavrilov(a)infotecs.ru>
netfilter: ipset: Fix overflow before widen in the bitmap_ip_create() function.
Nicolas Dichtel <nicolas.dichtel(a)6wind.com>
xfrm: fix rcu lock in xfrm_notify_userpolicy()
Ye Bin <yebin10(a)huawei.com>
ext4: fix uninititialized value in 'ext4_evict_inode'
Ferry Toth <ftoth(a)exalondelft.nl>
usb: ulpi: defer ulpi_register on ulpi_read_id timeout
Mathias Nyman <mathias.nyman(a)linux.intel.com>
xhci: Prevent infinite loop in transaction errors recovery for streams
Mathias Nyman <mathias.nyman(a)linux.intel.com>
xhci: move and rename xhci_cleanup_halted_endpoint()
Mathias Nyman <mathias.nyman(a)linux.intel.com>
xhci: store TD status in the td struct instead of passing it along
Mathias Nyman <mathias.nyman(a)linux.intel.com>
xhci: move xhci_td_cleanup so it can be called by more functions
Mathias Nyman <mathias.nyman(a)linux.intel.com>
xhci: Add xhci_reset_halted_ep() helper function
Mathias Nyman <mathias.nyman(a)linux.intel.com>
xhci: adjust parameters passed to cleanup_halted_endpoint()
Mathias Nyman <mathias.nyman(a)linux.intel.com>
xhci: get isochronous ring directly from endpoint structure
Mathias Nyman <mathias.nyman(a)linux.intel.com>
xhci: Avoid parsing transfer events several times
Li Jun <jun.li(a)nxp.com>
clk: imx: imx8mp: add shared clk gate for usb suspend clk
Li Jun <jun.li(a)nxp.com>
dt-bindings: clocks: imx8mp: Add ID for usb suspend clock
Lucas Stach <l.stach(a)pengutronix.de>
clk: imx8mp: add clkout1/2 support
Marek Vasut <marex(a)denx.de>
clk: imx8mp: Add DISP2 pixel clock
Kim Phillips <kim.phillips(a)amd.com>
iommu/amd: Fix ill-formed ivrs_ioapic, ivrs_hpet and ivrs_acpihid options
Suravee Suthikulpanit <suravee.suthikulpanit(a)amd.com>
iommu/amd: Add PCI segment support for ivrs_[ioapic/hpet/acpihid] commands
Qiang Yu <quic_qianyu(a)quicinc.com>
bus: mhi: host: Fix race between channel preparation and M0 event
Herbert Xu <herbert(a)gondor.apana.org.au>
ipv6: raw: Deduct extension header length in rawv6_push_pending_frames
Yang Yingliang <yangyingliang(a)huawei.com>
ixgbe: fix pci device refcount leak
Hans de Goede <hdegoede(a)redhat.com>
platform/x86: sony-laptop: Don't turn off 0x153 keyboard backlight during probe
Kuogee Hsieh <quic_khsieh(a)quicinc.com>
drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer
Konrad Dybcio <konrad.dybcio(a)linaro.org>
drm/msm/adreno: Make adreno quirks not overwrite each other
Volker Lendecke <vl(a)samba.org>
cifs: Fix uninitialized memory read for smb311 posix symlink create
Heiko Carstens <hca(a)linux.ibm.com>
s390/percpu: add READ_ONCE() to arch_this_cpu_to_op_simple()
Heiko Carstens <hca(a)linux.ibm.com>
s390/cpum_sf: add READ_ONCE() semantics to compare and swap loops
Brian Norris <computersforpeace(a)gmail.com>
ASoC: qcom: lpass-cpu: Fix fallback SD line index handling
Alexander Egorenkov <egorenar(a)linux.ibm.com>
s390/kexec: fix ipl report address for kdump
Adrian Hunter <adrian.hunter(a)intel.com>
perf auxtrace: Fix address filter duplicate symbol selection
Jonathan Corbet <corbet(a)lwn.net>
docs: Fix the docs build with Sphinx 6.0
Ard Biesheuvel <ardb(a)kernel.org>
efi: tpm: Avoid READ_ONCE() for accessing the event log
Marc Zyngier <maz(a)kernel.org>
KVM: arm64: Fix S1PTW handling on RO memslots
Luka Guzenko <l.guzenko(a)web.de>
ALSA: hda/realtek: Enable mute/micmute LEDs on HP Spectre x360 13-aw0xxx
Pablo Neira Ayuso <pablo(a)netfilter.org>
netfilter: nft_payload: incorrect arithmetics when fetching VLAN header bits
-------------
Diffstat:
Documentation/admin-guide/kernel-parameters.txt | 51 +++-
Documentation/sphinx/load_config.py | 6 +-
Documentation/virt/kvm/api.rst | 60 +++++
Makefile | 4 +-
arch/arm64/include/asm/atomic_ll_sc.h | 114 ++++----
arch/arm64/include/asm/atomic_lse.h | 16 +-
arch/arm64/include/asm/kvm_emulate.h | 22 +-
arch/powerpc/include/asm/imc-pmu.h | 2 +-
arch/powerpc/perf/imc-pmu.c | 136 +++++-----
arch/s390/include/asm/cpu_mf.h | 31 ++-
arch/s390/include/asm/percpu.h | 2 +-
arch/s390/kernel/machine_kexec_file.c | 5 +-
arch/s390/kernel/perf_cpum_sf.c | 101 ++++---
arch/x86/boot/bioscall.S | 4 +-
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 26 +-
arch/x86/kvm/cpuid.c | 32 +--
drivers/bus/mhi/core/pm.c | 3 +-
drivers/clk/imx/clk-imx8mp.c | 23 +-
drivers/edac/edac_device.c | 17 +-
drivers/edac/edac_module.h | 2 +-
drivers/firmware/efi/efi.c | 9 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 10 +-
drivers/gpu/drm/msm/dp/dp_aux.c | 4 +
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 10 +-
drivers/iommu/amd/init.c | 89 ++++--
drivers/iommu/mtk_iommu_v1.c | 26 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 14 +-
drivers/net/ethernet/marvell/octeontx2/af/cgx.c | 17 +-
drivers/net/ethernet/marvell/octeontx2/af/cgx.h | 6 +-
drivers/net/ethernet/marvell/octeontx2/af/rvu.c | 134 ++++++++--
drivers/net/ethernet/marvell/octeontx2/af/rvu.h | 4 +
.../net/ethernet/marvell/octeontx2/af/rvu_cgx.c | 15 ++
.../net/ethernet/marvell/octeontx2/af/rvu_nix.c | 21 +-
.../ethernet/mellanox/mlx5/core/en/tc_tun_vxlan.c | 2 +
.../net/ethernet/mellanox/mlx5/core/lib/clock.c | 2 +-
drivers/nfc/pn533/usb.c | 44 ++-
drivers/platform/x86/sony-laptop.c | 21 +-
drivers/regulator/da9211-regulator.c | 11 +-
drivers/tty/hvc/hvc_xen.c | 46 ++--
drivers/usb/host/xhci-mem.c | 4 +
drivers/usb/host/xhci-ring.c | 297 +++++++++++----------
drivers/usb/host/xhci.h | 6 +-
fs/cifs/link.c | 1 +
fs/ext4/super.c | 1 +
include/dt-bindings/clock/imx8mp-clock.h | 10 +-
include/linux/tpm_eventlog.h | 4 +-
io_uring/io-wq.c | 6 +
mm/memblock.c | 8 +-
net/ipv6/raw.c | 4 +
net/netfilter/ipset/ip_set_bitmap_ip.c | 4 +-
net/netfilter/nft_payload.c | 2 +-
net/sched/act_mpls.c | 8 +-
net/tipc/node.c | 12 +-
net/xfrm/xfrm_user.c | 7 +-
sound/pci/hda/patch_realtek.c | 23 ++
sound/soc/codecs/wm8904.c | 7 +
sound/soc/qcom/lpass-cpu.c | 5 +-
tools/perf/util/auxtrace.c | 2 +-
58 files changed, 1015 insertions(+), 538 deletions(-)
Hi
Am 18.01.23 um 20:21 schrieb Rodrigo Vivi:
> On Thu, Jan 12, 2023 at 09:11:55PM +0100, Thomas Zimmermann wrote:
>> Set the framebuffer info for drivers that support VGA switcheroo. Only
>> affects the amdgpu and nouveau drivers, which use VGA switcheroo and
>> generic fbdev emulation. For other drivers, this does nothing.
>>
>> This fixes a potential regression in the console code. Both, amdgpu and
>> nouveau, invoked vga_switcheroo_client_fb_set() from their internal fbdev
>> code. But the call got lost when the drivers switched to the generic
>> emulation.
>>
>> Fixes: 087451f372bf ("drm/amdgpu: use generic fb helpers instead of setting up AMD own's.")
>> Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
>> Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de>
>> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
>> Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
>> Cc: Ben Skeggs <bskeggs(a)redhat.com>
>> Cc: Karol Herbst <kherbst(a)redhat.com>
>> Cc: Lyude Paul <lyude(a)redhat.com>
>> Cc: Thomas Zimmermann <tzimmermann(a)suse.de>
>> Cc: Javier Martinez Canillas <javierm(a)redhat.com>
>> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
>> Cc: Jani Nikula <jani.nikula(a)intel.com>
>> Cc: Dave Airlie <airlied(a)redhat.com>
>> Cc: Evan Quan <evan.quan(a)amd.com>
>> Cc: Christian König <christian.koenig(a)amd.com>
>> Cc: Alex Deucher <alexander.deucher(a)amd.com>
>> Cc: Hawking Zhang <Hawking.Zhang(a)amd.com>
>> Cc: Likun Gao <Likun.Gao(a)amd.com>
>> Cc: "Christian König" <christian.koenig(a)amd.com>
>> Cc: Stanley Yang <Stanley.Yang(a)amd.com>
>> Cc: "Tianci.Yin" <tianci.yin(a)amd.com>
>> Cc: Xiaojian Du <Xiaojian.Du(a)amd.com>
>> Cc: Andrey Grodzovsky <andrey.grodzovsky(a)amd.com>
>> Cc: YiPeng Chai <YiPeng.Chai(a)amd.com>
>> Cc: Somalapuram Amaranath <Amaranath.Somalapuram(a)amd.com>
>> Cc: Bokun Zhang <Bokun.Zhang(a)amd.com>
>> Cc: Guchun Chen <guchun.chen(a)amd.com>
>> Cc: Hamza Mahfooz <hamza.mahfooz(a)amd.com>
>> Cc: Aurabindo Pillai <aurabindo.pillai(a)amd.com>
>> Cc: Mario Limonciello <mario.limonciello(a)amd.com>
>> Cc: Solomon Chiu <solomon.chiu(a)amd.com>
>> Cc: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
>> Cc: Felix Kuehling <Felix.Kuehling(a)amd.com>
>> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
>> Cc: "Marek Olšák" <marek.olsak(a)amd.com>
>> Cc: Sam Ravnborg <sam(a)ravnborg.org>
>> Cc: Hans de Goede <hdegoede(a)redhat.com>
>> Cc: "Ville Syrjälä" <ville.syrjala(a)linux.intel.com>
>> Cc: dri-devel(a)lists.freedesktop.org
>> Cc: nouveau(a)lists.freedesktop.org
>> Cc: <stable(a)vger.kernel.org> # v5.17+
>> ---
>> drivers/gpu/drm/drm_fb_helper.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
>> index 427631706128..5e445c61252d 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -30,7 +30,9 @@
>> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>>
>> #include <linux/console.h>
>> +#include <linux/pci.h>
>> #include <linux/sysrq.h>
>> +#include <linux/vga_switcheroo.h>
>>
>> #include <drm/drm_atomic.h>
>> #include <drm/drm_drv.h>
>> @@ -1940,6 +1942,7 @@ static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper,
>> int preferred_bpp)
>> {
>> struct drm_client_dev *client = &fb_helper->client;
>> + struct drm_device *dev = fb_helper->dev;
>
> On drm-tip, this commit has a silent conflict with
> cff84bac9922 ("drm/fh-helper: Split fbdev single-probe helper")
> that's already in drm-next.
>
> I had created a fix-up patch in drm-tip re-introducing this line.
Thank you. Is it fixed for now?
>
> We probably need a backmerge from drm-next into drm-misc-fixes with
> the resolution applied there. And probably propagated that resolution
> later...
Backmerging from -next into -fixes branches is a problem, as -fixes
should be close to the latest release.
Can we solve this by merging -fixes into upstream and backmerging this
into our -next branches?
Best regards
Thomas
>
>> struct drm_fb_helper_surface_size sizes;
>> int ret;
>>
>> @@ -1961,6 +1964,11 @@ static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper,
>> return ret;
>>
>> strcpy(fb_helper->fb->comm, "[fbcon]");
>> +
>> + /* Set the fb info for vgaswitcheroo clients. Does nothing otherwise. */
>> + if (dev_is_pci(dev->dev))
>> + vga_switcheroo_client_fb_set(to_pci_dev(dev->dev), fb_helper->info);
>> +
>> return 0;
>> }
>>
>> --
>> 2.39.0
>>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
The quilt patch titled
Subject: mm/thp: check and bail out if page in deferred queue already
has been removed from the -mm tree. Its filename was
mm-thp-check-and-bail-out-if-page-in-deferred-queue-already.patch
This patch was dropped because it was merged into the mm-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Yin Fengwei <fengwei.yin(a)intel.com>
Subject: mm/thp: check and bail out if page in deferred queue already
Date: Fri, 23 Dec 2022 21:52:07 +0800
Kernel build regression with LLVM was reported here:
https://lore.kernel.org/all/Y1GCYXGtEVZbcv%2F5@dev-arch.thelio-3990X/ with
commit f35b5d7d676e ("mm: align larger anonymous mappings on THP
boundaries"). And the commit f35b5d7d676e was reverted.
It turned out the regression is related with madvise(MADV_DONTNEED)
was used by ld.lld. But with none PMD_SIZE aligned parameter len.
trace-bpfcc captured:
531607 531732 ld.lld do_madvise.part.0 start: 0x7feca9000000, len: 0x7fb000, behavior: 0x4
531607 531793 ld.lld do_madvise.part.0 start: 0x7fec86a00000, len: 0x7fb000, behavior: 0x4
If the underneath physical page is THP, the madvise(MADV_DONTNEED) can
trigger split_queue_lock contention raised significantly. perf showed
following data:
14.85% 0.00% ld.lld [kernel.kallsyms] [k]
entry_SYSCALL_64_after_hwframe
11.52%
entry_SYSCALL_64_after_hwframe
do_syscall_64
__x64_sys_madvise
do_madvise.part.0
zap_page_range
unmap_single_vma
unmap_page_range
page_remove_rmap
deferred_split_huge_page
__lock_text_start
native_queued_spin_lock_slowpath
If THP can't be removed from rmap as whole THP, partial THP will be
removed from rmap by removing sub-pages from rmap. Even the THP head page
is added to deferred queue already, the split_queue_lock will be acquired
and check whether the THP head page is in the queue already. Thus, the
contention of split_queue_lock is raised.
Before acquire split_queue_lock, check and bail out early if the THP
head page is in the queue already. The checking without holding
split_queue_lock could race with deferred_split_scan, but it doesn't
impact the correctness here.
Test result of building kernel with ld.lld:
commit 7b5a0b664ebe (parent commit of f35b5d7d676e):
time -f "\t%E real,\t%U user,\t%S sys" make LD=ld.lld -skj96 allmodconfig all
6:07.99 real, 26367.77 user, 5063.35 sys
commit f35b5d7d676e:
time -f "\t%E real,\t%U user,\t%S sys" make LD=ld.lld -skj96 allmodconfig all
7:22.15 real, 26235.03 user, 12504.55 sys
commit f35b5d7d676e with the fixing patch:
time -f "\t%E real,\t%U user,\t%S sys" make LD=ld.lld -skj96 allmodconfig all
6:08.49 real, 26520.15 user, 5047.91 sys
Link: https://lkml.kernel.org/r/20221223135207.2275317-1-fengwei.yin@intel.com
Signed-off-by: Yin Fengwei <fengwei.yin(a)intel.com>
Tested-by: Nathan Chancellor <nathan(a)kernel.org>
Acked-by: David Rientjes <rientjes(a)google.com>
Reviewed-by: "Huang, Ying" <ying.huang(a)intel.com>
Cc: Feng Tang <feng.tang(a)intel.com>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Rik van Riel <riel(a)surriel.com>
Cc: Xing Zhengjun <zhengjun.xing(a)linux.intel.com>
Cc: Yang Shi <shy828301(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/huge_memory.c | 3 +++
1 file changed, 3 insertions(+)
--- a/mm/huge_memory.c~mm-thp-check-and-bail-out-if-page-in-deferred-queue-already
+++ a/mm/huge_memory.c
@@ -2835,6 +2835,9 @@ void deferred_split_huge_page(struct pag
if (PageSwapCache(page))
return;
+ if (!list_empty(page_deferred_list(page)))
+ return;
+
spin_lock_irqsave(&ds_queue->split_queue_lock, flags);
if (list_empty(page_deferred_list(page))) {
count_vm_event(THP_DEFERRED_SPLIT_PAGE);
_
Patches currently in -mm which might be from fengwei.yin(a)intel.com are
The quilt patch titled
Subject: mm: memcontrol: deprecate charge moving
has been removed from the -mm tree. Its filename was
mm-memcontrol-deprecate-charge-moving.patch
This patch was dropped because it was merged into the mm-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Johannes Weiner <hannes(a)cmpxchg.org>
Subject: mm: memcontrol: deprecate charge moving
Date: Wed, 7 Dec 2022 14:00:39 +0100
Charge moving mode in cgroup1 allows memory to follow tasks as they
migrate between cgroups. This is, and always has been, a questionable
thing to do - for several reasons.
First, it's expensive. Pages need to be identified, locked and isolated
from various MM operations, and reassigned, one by one.
Second, it's unreliable. Once pages are charged to a cgroup, there isn't
always a clear owner task anymore. Cache isn't moved at all, for example.
Mapped memory is moved - but if trylocking or isolating a page fails,
it's arbitrarily left behind. Frequent moving between domains may leave a
task's memory scattered all over the place.
Third, it isn't really needed. Launcher tasks can kick off workload tasks
directly in their target cgroup. Using dedicated per-workload groups
allows fine-grained policy adjustments - no need to move tasks and their
physical pages between control domains. The feature was never
forward-ported to cgroup2, and it hasn't been missed.
Despite it being a niche usecase, the maintenance overhead of supporting
it is enormous. Because pages are moved while they are live and subject
to various MM operations, the synchronization rules are complicated.
There are lock_page_memcg() in MM and FS code, which non-cgroup people
don't understand. In some cases we've been able to shift code and cgroup
API calls around such that we can rely on native locking as much as
possible. But that's fragile, and sometimes we need to hold MM locks for
longer than we otherwise would (pte lock e.g.).
Mark the feature deprecated. Hopefully we can remove it soon.
And backport into -stable kernels so that people who develop against
earlier kernels are warned about this deprecation as early as possible.
[akpm(a)linux-foundation.org: fix memory.rst underlining]
Link: https://lkml.kernel.org/r/Y5COd+qXwk/S+n8N@cmpxchg.org
Signed-off-by: Johannes Weiner <hannes(a)cmpxchg.org>
Acked-by: Shakeel Butt <shakeelb(a)google.com>
Acked-by: Hugh Dickins <hughd(a)google.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Muchun Song <songmuchun(a)bytedance.com>
Cc: Roman Gushchin <roman.gushchin(a)linux.dev>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
Documentation/admin-guide/cgroup-v1/memory.rst | 13 +++++++++++--
mm/memcontrol.c | 4 ++++
2 files changed, 15 insertions(+), 2 deletions(-)
--- a/Documentation/admin-guide/cgroup-v1/memory.rst~mm-memcontrol-deprecate-charge-moving
+++ a/Documentation/admin-guide/cgroup-v1/memory.rst
@@ -86,6 +86,8 @@ Brief summary of control files.
memory.swappiness set/show swappiness parameter of vmscan
(See sysctl's vm.swappiness)
memory.move_charge_at_immigrate set/show controls of moving charges
+ This knob is deprecated and shouldn't be
+ used.
memory.oom_control set/show oom controls.
memory.numa_stat show the number of memory usage per numa
node
@@ -717,8 +719,15 @@ NOTE2:
It is recommended to set the soft limit always below the hard limit,
otherwise the hard limit will take precedence.
-8. Move charges at task migration
-=================================
+8. Move charges at task migration (DEPRECATED!)
+===============================================
+
+THIS IS DEPRECATED!
+
+It's expensive and unreliable! It's better practice to launch workload
+tasks directly from inside their target cgroup. Use dedicated workload
+cgroups to allow fine-grained policy adjustments without having to
+move physical pages between control domains.
Users can move charges associated with a task along with task migration, that
is, uncharge task's pages from the old cgroup and charge them to the new cgroup.
--- a/mm/memcontrol.c~mm-memcontrol-deprecate-charge-moving
+++ a/mm/memcontrol.c
@@ -3919,6 +3919,10 @@ static int mem_cgroup_move_charge_write(
{
struct mem_cgroup *memcg = mem_cgroup_from_css(css);
+ pr_warn_once("Cgroup memory moving (move_charge_at_immigrate) is deprecated. "
+ "Please report your usecase to linux-mm(a)kvack.org if you "
+ "depend on this functionality.\n");
+
if (val & ~MOVE_MASK)
return -EINVAL;
_
Patches currently in -mm which might be from hannes(a)cmpxchg.org are
The quilt patch titled
Subject: mm/uffd: fix pte marker when fork() without fork event
has been removed from the -mm tree. Its filename was
mm-uffd-fix-pte-marker-when-fork-without-fork-event.patch
This patch was dropped because it was merged into the mm-hotfixes-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Peter Xu <peterx(a)redhat.com>
Subject: mm/uffd: fix pte marker when fork() without fork event
Date: Wed, 14 Dec 2022 15:04:52 -0500
Patch series "mm: Fixes on pte markers".
Patch 1 resolves the syzkiller report from Pengfei.
Patch 2 further harden pte markers when used with the recent swapin error
markers. The major case is we should persist a swapin error marker after
fork(), so child shouldn't read a corrupted page.
This patch (of 2):
When fork(), dst_vma is not guaranteed to have VM_UFFD_WP even if src may
have it and has pte marker installed. The warning is improper along with
the comment. The right thing is to inherit the pte marker when needed, or
keep the dst pte empty.
A vague guess is this happened by an accident when there's the prior patch
to introduce src/dst vma into this helper during the uffd-wp feature got
developed and I probably messed up in the rebase, since if we replace
dst_vma with src_vma the warning & comment it all makes sense too.
Hugetlb did exactly the right here (copy_hugetlb_page_range()). Fix the
general path.
Reproducer:
https://github.com/xupengfe/syzkaller_logs/blob/main/221208_115556_copy_pag…
Bugzilla report: https://bugzilla.kernel.org/show_bug.cgi?id=216808
Link: https://lkml.kernel.org/r/20221214200453.1772655-1-peterx@redhat.com
Link: https://lkml.kernel.org/r/20221214200453.1772655-2-peterx@redhat.com
Fixes: c56d1b62cce8 ("mm/shmem: handle uffd-wp during fork()")
Signed-off-by: Peter Xu <peterx(a)redhat.com>
Reported-by: Pengfei Xu <pengfei.xu(a)intel.com>
Acked-by: David Hildenbrand <david(a)redhat.com>
Reviewed-by: Miaohe Lin <linmiaohe(a)huawei.com>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: "Huang, Ying" <ying.huang(a)intel.com>
Cc: Nadav Amit <nadav.amit(a)gmail.com>
Cc: <stable(a)vger.kernel.org> # 5.19+
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/memory.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
--- a/mm/memory.c~mm-uffd-fix-pte-marker-when-fork-without-fork-event
+++ a/mm/memory.c
@@ -828,12 +828,8 @@ copy_nonpresent_pte(struct mm_struct *ds
return -EBUSY;
return -ENOENT;
} else if (is_pte_marker_entry(entry)) {
- /*
- * We're copying the pgtable should only because dst_vma has
- * uffd-wp enabled, do sanity check.
- */
- WARN_ON_ONCE(!userfaultfd_wp(dst_vma));
- set_pte_at(dst_mm, addr, dst_pte, pte);
+ if (userfaultfd_wp(dst_vma))
+ set_pte_at(dst_mm, addr, dst_pte, pte);
return 0;
}
if (!userfaultfd_wp(dst_vma))
_
Patches currently in -mm which might be from peterx(a)redhat.com are
selftests-vm-remove-__use_gnu-in-hugetlb-madvisec.patch
mm-uffd-always-wr-protect-pte-in-ptepmd_mkuffd_wp.patch
mm-mprotect-use-long-for-page-accountings-and-retval.patch
mm-uffd-detect-pgtable-allocation-failures.patch
mm-hugetlb-let-vma_offset_start-to-return-start.patch
mm-hugetlb-dont-wait-for-migration-entry-during-follow-page.patch
mm-hugetlb-document-huge_pte_offset-usage.patch
mm-hugetlb-move-swap-entry-handling-into-vma-lock-when-faulted.patch
mm-hugetlb-make-userfaultfd_huge_must_wait-safe-to-pmd-unshare.patch
mm-hugetlb-make-hugetlb_follow_page_mask-safe-to-pmd-unshare.patch
mm-hugetlb-make-follow_hugetlb_page-safe-to-pmd-unshare.patch
mm-hugetlb-make-walk_hugetlb_range-safe-to-pmd-unshare.patch
mm-hugetlb-introduce-hugetlb_walk.patch
There is a lock inversion and rwsem read-lock recursion in the devfreq
target callback which can lead to deadlocks.
Specifically, ufshcd_devfreq_scale() already holds a clk_scaling_lock
read lock when toggling the write booster, which involves taking the
dev_cmd mutex before taking another clk_scaling_lock read lock.
This can lead to a deadlock if another thread:
1) tries to acquire the dev_cmd and clk_scaling locks in the correct
order, or
2) takes a clk_scaling write lock before the attempt to take the
clk_scaling read lock a second time.
Fix this by dropping the clk_scaling_lock before toggling the write
booster as was done before commit 0e9d4ca43ba8 ("scsi: ufs: Protect some
contexts from unexpected clock scaling").
While the devfreq callbacks are already serialised, add a second
serialising mutex to handle the unlikely case where a callback triggered
through the devfreq sysfs interface is racing with a request to disable
clock scaling through the UFS controller 'clkscale_enable' sysfs
attribute. This could otherwise lead to the write booster being left
disabled after having disabled clock scaling.
Also take the new mutex in ufshcd_clk_scaling_allow() to make sure that
any pending write booster update has completed on return.
Note that this currently only affects Qualcomm platforms since commit
87bd05016a64 ("scsi: ufs: core: Allow host driver to disable wb toggling
during clock scaling").
The lock inversion (i.e. 1 above) was reported by lockdep as:
======================================================
WARNING: possible circular locking dependency detected
6.1.0-next-20221216 #211 Not tainted
------------------------------------------------------
kworker/u16:2/71 is trying to acquire lock:
ffff076280ba98a0 (&hba->dev_cmd.lock){+.+.}-{3:3}, at: ufshcd_query_flag+0x50/0x1c0
but task is already holding lock:
ffff076280ba9cf0 (&hba->clk_scaling_lock){++++}-{3:3}, at: ufshcd_devfreq_scale+0x2b8/0x380
which lock already depends on the new lock.
[ +0.011606]
the existing dependency chain (in reverse order) is:
-> #1 (&hba->clk_scaling_lock){++++}-{3:3}:
lock_acquire+0x68/0x90
down_read+0x58/0x80
ufshcd_exec_dev_cmd+0x70/0x2c0
ufshcd_verify_dev_init+0x68/0x170
ufshcd_probe_hba+0x398/0x1180
ufshcd_async_scan+0x30/0x320
async_run_entry_fn+0x34/0x150
process_one_work+0x288/0x6c0
worker_thread+0x74/0x450
kthread+0x118/0x120
ret_from_fork+0x10/0x20
-> #0 (&hba->dev_cmd.lock){+.+.}-{3:3}:
__lock_acquire+0x12a0/0x2240
lock_acquire.part.0+0xcc/0x220
lock_acquire+0x68/0x90
__mutex_lock+0x98/0x430
mutex_lock_nested+0x2c/0x40
ufshcd_query_flag+0x50/0x1c0
ufshcd_query_flag_retry+0x64/0x100
ufshcd_wb_toggle+0x5c/0x120
ufshcd_devfreq_scale+0x2c4/0x380
ufshcd_devfreq_target+0xf4/0x230
devfreq_set_target+0x84/0x2f0
devfreq_update_target+0xc4/0xf0
devfreq_monitor+0x38/0x1f0
process_one_work+0x288/0x6c0
worker_thread+0x74/0x450
kthread+0x118/0x120
ret_from_fork+0x10/0x20
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&hba->clk_scaling_lock);
lock(&hba->dev_cmd.lock);
lock(&hba->clk_scaling_lock);
lock(&hba->dev_cmd.lock);
*** DEADLOCK ***
Fixes: 0e9d4ca43ba8 ("scsi: ufs: Protect some contexts from unexpected clock scaling")
Cc: stable(a)vger.kernel.org # 5.12
Cc: Can Guo <quic_cang(a)quicinc.com>
Tested-by: Andrew Halaney <ahalaney(a)redhat.com>
Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org>
---
This issue has apparently been known for over a year [1] without anyone
bothering to fix it. Aside from the potential deadlocks, this also leads
to developers using Qualcomm platforms not being able to use lockdep to
prevent further issues like this from being introduced in other places.
Johan
[1] https://lore.kernel.org/lkml/1631843521-2863-1-git-send-email-cang@codeauro…
Changes in v2
- leave the write booster unchanged on errors (Bart)
drivers/ufs/core/ufshcd.c | 29 +++++++++++++++--------------
include/ufs/ufshcd.h | 2 ++
2 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index bda61be5f035..3a1c4d31e010 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -1234,12 +1234,14 @@ static int ufshcd_clock_scaling_prepare(struct ufs_hba *hba)
* clock scaling is in progress
*/
ufshcd_scsi_block_requests(hba);
+ mutex_lock(&hba->wb_mutex);
down_write(&hba->clk_scaling_lock);
if (!hba->clk_scaling.is_allowed ||
ufshcd_wait_for_doorbell_clr(hba, DOORBELL_CLR_TOUT_US)) {
ret = -EBUSY;
up_write(&hba->clk_scaling_lock);
+ mutex_unlock(&hba->wb_mutex);
ufshcd_scsi_unblock_requests(hba);
goto out;
}
@@ -1251,12 +1253,16 @@ static int ufshcd_clock_scaling_prepare(struct ufs_hba *hba)
return ret;
}
-static void ufshcd_clock_scaling_unprepare(struct ufs_hba *hba, bool writelock)
+static void ufshcd_clock_scaling_unprepare(struct ufs_hba *hba, int err, bool scale_up)
{
- if (writelock)
- up_write(&hba->clk_scaling_lock);
- else
- up_read(&hba->clk_scaling_lock);
+ up_write(&hba->clk_scaling_lock);
+
+ /* Enable Write Booster if we have scaled up else disable it */
+ if (ufshcd_enable_wb_if_scaling_up(hba) && !err)
+ ufshcd_wb_toggle(hba, scale_up);
+
+ mutex_unlock(&hba->wb_mutex);
+
ufshcd_scsi_unblock_requests(hba);
ufshcd_release(hba);
}
@@ -1273,7 +1279,6 @@ static void ufshcd_clock_scaling_unprepare(struct ufs_hba *hba, bool writelock)
static int ufshcd_devfreq_scale(struct ufs_hba *hba, bool scale_up)
{
int ret = 0;
- bool is_writelock = true;
ret = ufshcd_clock_scaling_prepare(hba);
if (ret)
@@ -1302,15 +1307,8 @@ static int ufshcd_devfreq_scale(struct ufs_hba *hba, bool scale_up)
}
}
- /* Enable Write Booster if we have scaled up else disable it */
- if (ufshcd_enable_wb_if_scaling_up(hba)) {
- downgrade_write(&hba->clk_scaling_lock);
- is_writelock = false;
- ufshcd_wb_toggle(hba, scale_up);
- }
-
out_unprepare:
- ufshcd_clock_scaling_unprepare(hba, is_writelock);
+ ufshcd_clock_scaling_unprepare(hba, ret, scale_up);
return ret;
}
@@ -6066,9 +6064,11 @@ static void ufshcd_force_error_recovery(struct ufs_hba *hba)
static void ufshcd_clk_scaling_allow(struct ufs_hba *hba, bool allow)
{
+ mutex_lock(&hba->wb_mutex);
down_write(&hba->clk_scaling_lock);
hba->clk_scaling.is_allowed = allow;
up_write(&hba->clk_scaling_lock);
+ mutex_unlock(&hba->wb_mutex);
}
static void ufshcd_clk_scaling_suspend(struct ufs_hba *hba, bool suspend)
@@ -9793,6 +9793,7 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem *mmio_base, unsigned int irq)
/* Initialize mutex for exception event control */
mutex_init(&hba->ee_ctrl_mutex);
+ mutex_init(&hba->wb_mutex);
init_rwsem(&hba->clk_scaling_lock);
ufshcd_init_clk_gating(hba);
diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
index 5cf81dff60aa..727084cd79be 100644
--- a/include/ufs/ufshcd.h
+++ b/include/ufs/ufshcd.h
@@ -808,6 +808,7 @@ struct ufs_hba_monitor {
* @urgent_bkops_lvl: keeps track of urgent bkops level for device
* @is_urgent_bkops_lvl_checked: keeps track if the urgent bkops level for
* device is known or not.
+ * @wb_mutex: used to serialize devfreq and sysfs write booster toggling
* @clk_scaling_lock: used to serialize device commands and clock scaling
* @desc_size: descriptor sizes reported by device
* @scsi_block_reqs_cnt: reference counting for scsi block requests
@@ -951,6 +952,7 @@ struct ufs_hba {
enum bkops_status urgent_bkops_lvl;
bool is_urgent_bkops_lvl_checked;
+ struct mutex wb_mutex;
struct rw_semaphore clk_scaling_lock;
unsigned char desc_size[QUERY_DESC_IDN_MAX];
atomic_t scsi_block_reqs_cnt;
--
2.38.2
From: Steven Rostedt <rostedt(a)goodmis.org>
There is a disconnect between the run_command function and the
wait_for_input. The wait_for_input has a default timeout of 2 minutes. But
if that happens, the run_command loop will exit out to the waitpid() of
the executing command. This fails in that it no longer monitors the
command, and also, the ssh to the test box can hang when its finished, as
it's waiting for the pipe it's writing to to flush, but the loop that
reads that pipe has already exited, leaving the command stuck, and the
test hangs.
Instead, make the default "wait_for_input" of the run_command infinite,
and allow the user to override it if they want with a default timeout
option "RUN_TIMEOUT".
But this fixes the hang that happens when the pipe is full and the ssh
session never exits.
Cc: stable(a)vger.kernel.org
Fixes: 6e98d1b4415fe ("ktest: Add timeout to ssh command")
Signed-off-by: Steven Rostedt <rostedt(a)goodmis.org>
---
tools/testing/ktest/ktest.pl | 20 ++++++++++++++++----
tools/testing/ktest/sample.conf | 5 +++++
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index 78249c3a03a5..7c91d753a9f2 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -178,6 +178,7 @@ my $store_failures;
my $store_successes;
my $test_name;
my $timeout;
+my $run_timeout;
my $connect_timeout;
my $config_bisect_exec;
my $booted_timeout;
@@ -340,6 +341,7 @@ my %option_map = (
"STORE_SUCCESSES" => \$store_successes,
"TEST_NAME" => \$test_name,
"TIMEOUT" => \$timeout,
+ "RUN_TIMEOUT" => \$run_timeout,
"CONNECT_TIMEOUT" => \$connect_timeout,
"CONFIG_BISECT_EXEC" => \$config_bisect_exec,
"BOOTED_TIMEOUT" => \$booted_timeout,
@@ -1862,6 +1864,14 @@ sub run_command {
$command =~ s/\$SSH_USER/$ssh_user/g;
$command =~ s/\$MACHINE/$machine/g;
+ if (!defined($timeout)) {
+ $timeout = $run_timeout;
+ }
+
+ if (!defined($timeout)) {
+ $timeout = -1; # tell wait_for_input to wait indefinitely
+ }
+
doprint("$command ... ");
$start_time = time;
@@ -1888,13 +1898,10 @@ sub run_command {
while (1) {
my $fp = \*CMD;
- if (defined($timeout)) {
- doprint "timeout = $timeout\n";
- }
my $line = wait_for_input($fp, $timeout);
if (!defined($line)) {
my $now = time;
- if (defined($timeout) && (($now - $start_time) >= $timeout)) {
+ if ($timeout >= 0 && (($now - $start_time) >= $timeout)) {
doprint "Hit timeout of $timeout, killing process\n";
$hit_timeout = 1;
kill 9, $pid;
@@ -2066,6 +2073,11 @@ sub wait_for_input {
$time = $timeout;
}
+ if ($time < 0) {
+ # Negative number means wait indefinitely
+ undef $time;
+ }
+
$rin = '';
vec($rin, fileno($fp), 1) = 1;
vec($rin, fileno(\*STDIN), 1) = 1;
diff --git a/tools/testing/ktest/sample.conf b/tools/testing/ktest/sample.conf
index 2d0fe15a096d..f43477a9b857 100644
--- a/tools/testing/ktest/sample.conf
+++ b/tools/testing/ktest/sample.conf
@@ -817,6 +817,11 @@
# is issued instead of a reboot.
# CONNECT_TIMEOUT = 25
+# The timeout in seconds for how long to wait for any running command
+# to timeout. If not defined, it will let it go indefinitely.
+# (default undefined)
+#RUN_TIMEOUT = 600
+
# In between tests, a reboot of the box may occur, and this
# is the time to wait for the console after it stops producing
# output. Some machines may not produce a large lag on reboot
--
2.39.0
From: Steven Rostedt <rostedt(a)goodmis.org>
When monitoring the console output, the stdout is being redirected to do
so. If Ctrl^C is hit during this mode, the stdout is not back to the
console, the user does not see anything they type (no echo).
Add "end_monitor" to the SIGINT interrupt handler to give back the console
on Ctrl^C.
Cc: stable(a)vger.kernel.org
Fixes: 9f2cdcbbb90e7 ("ktest: Give console process a dedicated tty")
Signed-off-by: Steven Rostedt <rostedt(a)goodmis.org>
---
tools/testing/ktest/ktest.pl | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index f2f48ce6ac4d..78249c3a03a5 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -4205,6 +4205,9 @@ sub send_email {
}
sub cancel_test {
+ if ($monitor_cnt) {
+ end_monitor;
+ }
if ($email_when_canceled) {
my $name = get_test_name;
send_email("KTEST: Your [$name] test was cancelled",
--
2.39.0
From: Steven Rostedt <rostedt(a)goodmis.org>
In the "reboot" command, it does a check of the machine to see if it is
still alive with a simple "ssh echo" command. If it fails, it will assume
that a normal "ssh reboot" is not possible and force a power cycle.
In this case, the "start_monitor" is executed, but the "end_monitor" is
not, and this causes the screen will not be given back to the console. That
is, after the test, a "reset" command needs to be performed, as "echo" is
turned off.
Cc: stable(a)vger.kernel.org
Fixes: 6474ace999edd ("ktest.pl: Powercycle the box on reboot if no connection can be made")
Signed-off-by: Steven Rostedt <rostedt(a)goodmis.org>
---
tools/testing/ktest/ktest.pl | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index 6f9fff88cedf..f2f48ce6ac4d 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -1499,7 +1499,8 @@ sub reboot {
# Still need to wait for the reboot to finish
wait_for_monitor($time, $reboot_success_line);
-
+ }
+ if ($powercycle || $time) {
end_monitor;
}
}
--
2.39.0
The ACPI PRM address space handler calls efi_call_virt_pointer() to
execute PRM firmware code, but doing so is only permitted when the EFI
runtime environment is available. Otherwise, such calls are guaranteed
to result in a crash, and must therefore be avoided.
Given that the EFI runtime services may become unavailable after a crash
occurring in the firmware, we need to check this each time the PRM
address space handler is invoked. If the EFI runtime services were not
available at registration time to being with, don't install the address
space handler at all.
Cc: <stable(a)vger.kernel.org>
Cc: "Rafael J. Wysocki" <rafael(a)kernel.org>
Cc: Len Brown <lenb(a)kernel.org>
Cc: linux-acpi(a)vger.kernel.org
Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org>
---
v2: check both at registration and at invocation time
drivers/acpi/prmt.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/acpi/prmt.c b/drivers/acpi/prmt.c
index 998101cf16e47145..3d4c4620f9f95309 100644
--- a/drivers/acpi/prmt.c
+++ b/drivers/acpi/prmt.c
@@ -236,6 +236,11 @@ static acpi_status acpi_platformrt_space_handler(u32 function,
efi_status_t status;
struct prm_context_buffer context;
+ if (!efi_enabled(EFI_RUNTIME_SERVICES)) {
+ pr_err_ratelimited("PRM: EFI runtime services no longer available\n");
+ return AE_NO_HANDLER;
+ }
+
/*
* The returned acpi_status will always be AE_OK. Error values will be
* saved in the first byte of the PRM message buffer to be used by ASL.
@@ -325,6 +330,11 @@ void __init init_prmt(void)
pr_info("PRM: found %u modules\n", mc);
+ if (!efi_enabled(EFI_RUNTIME_SERVICES)) {
+ pr_err("PRM: EFI runtime services unavailable\n");
+ return;
+ }
+
status = acpi_install_address_space_handler(ACPI_ROOT_OBJECT,
ACPI_ADR_SPACE_PLATFORM_RT,
&acpi_platformrt_space_handler,
--
2.39.0
The platforms based on SDM845 SoC locks the access to EDAC registers in the
bootloader. So probing the EDAC driver will result in a crash. Hence,
disable the creation of EDAC platform device on all SDM845 devices.
The issue has been observed on Lenovo Yoga C630 and DB845c.
Cc: <stable(a)vger.kernel.org> # 5.10
Reported-by: Steev Klimaszewski <steev(a)kali.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org>
---
drivers/soc/qcom/llcc-qcom.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/qcom/llcc-qcom.c b/drivers/soc/qcom/llcc-qcom.c
index 7b7c5a38bac6..8d840702df50 100644
--- a/drivers/soc/qcom/llcc-qcom.c
+++ b/drivers/soc/qcom/llcc-qcom.c
@@ -1012,11 +1012,18 @@ static int qcom_llcc_probe(struct platform_device *pdev)
drv_data->ecc_irq = platform_get_irq_optional(pdev, 0);
- llcc_edac = platform_device_register_data(&pdev->dev,
- "qcom_llcc_edac", -1, drv_data,
- sizeof(*drv_data));
- if (IS_ERR(llcc_edac))
- dev_err(dev, "Failed to register llcc edac driver\n");
+ /*
+ * The platforms based on SDM845 SoC locks the access to EDAC registers
+ * in bootloader. So probing the EDAC driver will result in a crash.
+ * Hence, disable the creation of EDAC platform device on SDM845.
+ */
+ if (!of_device_is_compatible(dev->of_node, "qcom,sdm845-llcc")) {
+ llcc_edac = platform_device_register_data(&pdev->dev,
+ "qcom_llcc_edac", -1, drv_data,
+ sizeof(*drv_data));
+ if (IS_ERR(llcc_edac))
+ dev_err(dev, "Failed to register llcc edac driver\n");
+ }
return 0;
err:
--
2.25.1
Commit 537d9ed2f6c1 ("drm/edid: convert add_cea_modes() to use cea db
iter") inadvertently moved the do_hdmi_vsdb_modes() call within the db
iteration loop, always passing NULL as the CTA VDB to
do_hdmi_vsdb_modes(), skipping a lot of stereo modes.
Move the call back outside of the loop.
This does mean only one CTA VDB and HDMI VSDB combination will be
handled, but it's an unlikely scenario to have more than one of either
block, and it was not accounted for before the regression either.
Fixes: 537d9ed2f6c1 ("drm/edid: convert add_cea_modes() to use cea db iter")
Cc: <stable(a)vger.kernel.org> # v6.0+
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula(a)intel.com>
---
drivers/gpu/drm/drm_edid.c | 22 ++++++++++------------
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 23f7146e6a9b..b94adb9bbefb 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5249,13 +5249,12 @@ static int add_cea_modes(struct drm_connector *connector,
{
const struct cea_db *db;
struct cea_db_iter iter;
+ const u8 *hdmi = NULL, *video = NULL;
+ u8 hdmi_len = 0, video_len = 0;
int modes = 0;
cea_db_iter_edid_begin(drm_edid, &iter);
cea_db_iter_for_each(db, &iter) {
- const u8 *hdmi = NULL, *video = NULL;
- u8 hdmi_len = 0, video_len = 0;
-
if (cea_db_tag(db) == CTA_DB_VIDEO) {
video = cea_db_data(db);
video_len = cea_db_payload_len(db);
@@ -5271,18 +5270,17 @@ static int add_cea_modes(struct drm_connector *connector,
modes += do_y420vdb_modes(connector, vdb420,
cea_db_payload_len(db) - 1);
}
-
- /*
- * We parse the HDMI VSDB after having added the cea modes as we
- * will be patching their flags when the sink supports stereo
- * 3D.
- */
- if (hdmi)
- modes += do_hdmi_vsdb_modes(connector, hdmi, hdmi_len,
- video, video_len);
}
cea_db_iter_end(&iter);
+ /*
+ * We parse the HDMI VSDB after having added the cea modes as we will be
+ * patching their flags when the sink supports stereo 3D.
+ */
+ if (hdmi)
+ modes += do_hdmi_vsdb_modes(connector, hdmi, hdmi_len,
+ video, video_len);
+
return modes;
}
--
2.34.1
We try to avoid sending VICs defined in the later specs in AVI
infoframes to sinks that conform to the earlier specs, to not upset
them, and use 0 for the VIC instead. However, we do this detection and
conversion to 0 too early, as we'll need the actual VIC to figure out
the aspect ratio.
In particular, for a mode with 64:27 aspect ratio, 0 for VIC fails the
AVI infoframe generation altogether with -EINVAL.
Separate the VIC lookup from the "filtering", and postpone the
filtering, to use the proper VIC for aspect ratio handling, and the 0
VIC for the infoframe video code as needed.
Reported-by: William Tseng <william.tseng(a)intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6153
References: https://lore.kernel.org/r/20220920062316.43162-1-william.tseng@intel.com
Cc: <stable(a)vger.kernel.org>
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula(a)intel.com>
---
drivers/gpu/drm/drm_edid.c | 21 ++++++++++++---------
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3841aba17abd..23f7146e6a9b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -6885,8 +6885,6 @@ static u8 drm_mode_hdmi_vic(const struct drm_connector *connector,
static u8 drm_mode_cea_vic(const struct drm_connector *connector,
const struct drm_display_mode *mode)
{
- u8 vic;
-
/*
* HDMI spec says if a mode is found in HDMI 1.4b 4K modes
* we should send its VIC in vendor infoframes, else send the
@@ -6896,13 +6894,18 @@ static u8 drm_mode_cea_vic(const struct drm_connector *connector,
if (drm_mode_hdmi_vic(connector, mode))
return 0;
- vic = drm_match_cea_mode(mode);
+ return drm_match_cea_mode(mode);
+}
- /*
- * HDMI 1.4 VIC range: 1 <= VIC <= 64 (CEA-861-D) but
- * HDMI 2.0 VIC range: 1 <= VIC <= 107 (CEA-861-F). So we
- * have to make sure we dont break HDMI 1.4 sinks.
- */
+/*
+ * Avoid sending VICs defined in HDMI 2.0 in AVI infoframes to sinks that
+ * conform to HDMI 1.4.
+ *
+ * HDMI 1.4 (CTA-861-D) VIC range: [1..64]
+ * HDMI 2.0 (CTA-861-F) VIC range: [1..107]
+ */
+static u8 vic_for_avi_infoframe(const struct drm_connector *connector, u8 vic)
+{
if (!is_hdmi2_sink(connector) && vic > 64)
return 0;
@@ -6978,7 +6981,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame,
picture_aspect = HDMI_PICTURE_ASPECT_NONE;
}
- frame->video_code = vic;
+ frame->video_code = vic_for_avi_infoframe(connector, vic);
frame->picture_aspect = picture_aspect;
frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;
--
2.34.1
This bug is marked as fixed by commit:
ext4: block range must be validated before use in ext4_mb_clear_bb()
But I can't find it in the tested trees[1] for more than 90 days.
Is it a correct commit? Please update it by replying:
#syz fix: exact-commit-title
Until then the bug is still considered open and new crashes with
the same signature are ignored.
Kernel: Android 5.10
Dashboard link: https://syzkaller.appspot.com/bug?extid=15cd994e273307bf5cfa
---
[1] I expect the commit to be present in:
1. android12-5.10-lts branch of
https://android.googlesource.com/kernel/common
This device has a trackstick that is sent through the same HID device
than the touchpad.
Unfortunately there are 2 mice attached to that device descriptor, with
the first one for the touchpad when the second is for the trackstick.
Force all devices to be exported.
Cc: stable(a)vger.kernel.org # 5.8+
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2154204
Signed-off-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com>
---
drivers/hid/hid-multitouch.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 91a4d3fc30e0..91ac72b32d45 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -1860,6 +1860,12 @@ static const struct hid_device_id mt_devices[] = {
USB_VENDOR_ID_ASUSTEK,
USB_DEVICE_ID_ASUSTEK_T304_KEYBOARD) },
+ /* Asus ExpertBook with trackstick */
+ { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT,
+ HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
+ USB_VENDOR_ID_ELAN,
+ 0x3148) },
+
/* Atmel panels */
{ .driver_data = MT_CLS_SERIAL,
MT_USB_DEVICE(USB_VENDOR_ID_ATMEL,
--
2.38.1
The "duty > cycle" trick to force the pin level of a disabled TCU2
channel would only work when the channel had been enabled previously.
Address this issue by enabling the PWM mode in jz4740_pwm_disable
(I know, right) so that the "duty > cycle" trick works before disabling
the PWM channel right after.
This issue went unnoticed, as the PWM pins on the majority of the boards
tested would default to the inactive level once the corresponding TCU
clock was enabled, so the first call to jz4740_pwm_disable() would not
actually change the pin levels.
On the GCW Zero however, the PWM pin for the backlight (PWM1, which is
a TCU2 channel) goes active as soon as the timer1 clock is enabled.
Since the jz4740_pwm_disable() function did not work on channels not
previously enabled, the backlight would shine at full brightness from
the moment the backlight driver would probe, until the backlight driver
tried to *enable* the PWM output.
With this fix, the PWM pins will be forced inactive as soon as
jz4740_pwm_apply() is called (and might be reconfigured to active if
dictated by the pwm_state). This means that there is still a tiny time
frame between the .request() and .apply() callbacks where the PWM pin
might be active. Sadly, there is no way to fix this issue: it is
impossible to write a PWM channel's registers if the corresponding clock
is not enabled, and enabling the clock is what causes the PWM pin to go
active.
There is a workaround, though, which complements this fix: simply
starting the backlight driver (or any PWM client driver) with a "init"
pinctrl state that sets the pin as an inactive GPIO. Once the driver is
probed and the pinctrl state switches to "default", the regular PWM pin
configuration can be used as it will be properly driven.
Fixes: c2693514a0a1 ("pwm: jz4740: Obtain regmap from parent node")
Signed-off-by: Paul Cercueil <paul(a)crapouillou.net>
Cc: stable(a)vger.kernel.org
---
drivers/pwm/pwm-jz4740.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/pwm/pwm-jz4740.c b/drivers/pwm/pwm-jz4740.c
index a5fdf97c0d2e..228eb104bf1e 100644
--- a/drivers/pwm/pwm-jz4740.c
+++ b/drivers/pwm/pwm-jz4740.c
@@ -102,11 +102,14 @@ static void jz4740_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
struct jz4740_pwm_chip *jz = to_jz4740(chip);
/*
- * Set duty > period. This trick allows the TCU channels in TCU2 mode to
- * properly return to their init level.
+ * Set duty > period, then enable PWM mode and start the counter.
+ * This trick allows to force the inactive pin level for the TCU2
+ * channels.
*/
regmap_write(jz->map, TCU_REG_TDHRc(pwm->hwpwm), 0xffff);
regmap_write(jz->map, TCU_REG_TDFRc(pwm->hwpwm), 0x0);
+ regmap_set_bits(jz->map, TCU_REG_TCSRc(pwm->hwpwm), TCU_TCSR_PWM_EN);
+ regmap_write(jz->map, TCU_REG_TESR, BIT(pwm->hwpwm));
/*
* Disable PWM output.
--
2.35.1
On Wed, Jan 18, 2023 at 02:26:37AM +0530, mkv22(a)cantab.net wrote:
> OK. I just read about git bisect. Should I do it on the t2 github page from
> where things are downloaded and compiled and installed or on the mainline
> kernel github pages? Many thanks.
Nit, we don't use github for kernel development, but rather,
git.kernel.org :)
> It works fine till 6.1.5.
I recommend using the "t2 github" repo as odds are there are still
out-of-tree patches in there that you rely on.
Let us know how that goes, and watch out with sending html mail to our
mailing lists, they get automatically rejected.
thanks,
greg k-h
This series backports 6 commits with 'Cc stable' that had failed to be
applied, and 4 related commits that made the backports much easier.
Please apply this series to 5.15-stable.
I verified that this series does not cause any regressions with
'gce-xfstests -c ext4/fast_commit -g auto'. There is one test failure
both before and after (ext4/050).
Eric Biggers (5):
ext4: disable fast-commit of encrypted dir operations
ext4: don't set up encryption key during jbd2 transaction
ext4: add missing validation of fast-commit record lengths
ext4: fix unaligned memory access in ext4_fc_reserve_space()
ext4: fix off-by-one errors in fast-commit block filling
Jan Kara (1):
ext4: use ext4_debug() instead of jbd_debug()
Ritesh Harjani (1):
ext4: remove unused enum EXT4_FC_COMMIT_FAILED
Ye Bin (3):
ext4: introduce EXT4_FC_TAG_BASE_LEN helper
ext4: factor out ext4_fc_get_tl()
ext4: fix potential out of bound read in ext4_fc_replay_scan()
fs/ext4/balloc.c | 2 +-
fs/ext4/ext4.h | 4 +-
fs/ext4/ext4_jbd2.c | 3 +-
fs/ext4/fast_commit.c | 284 +++++++++++++++++++++---------------
fs/ext4/fast_commit.h | 7 +-
fs/ext4/indirect.c | 4 +-
fs/ext4/inode.c | 2 +-
fs/ext4/namei.c | 44 +++---
fs/ext4/orphan.c | 24 +--
fs/ext4/super.c | 2 +-
include/trace/events/ext4.h | 7 +-
11 files changed, 222 insertions(+), 161 deletions(-)
--
2.39.0
The patch titled
Subject: mm, mremap: fix mremap() expanding for vma's with vm_ops->close()
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
mm-mremap-fix-mremap-expanding-for-vmas-with-vm_ops-close.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche…
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Vlastimil Babka <vbabka(a)suse.cz>
Subject: mm, mremap: fix mremap() expanding for vma's with vm_ops->close()
Date: Tue, 17 Jan 2023 11:19:39 +0100
Fabian has reported another regression in 6.1 due to ca3d76b0aa80 ("mm:
add merging after mremap resize"). The problem is that vma_merge() can
fail when vma has a vm_ops->close() method, causing is_mergeable_vma()
test to be negative. This was happening for vma mapping a file from
fuse-overlayfs, which does have the method. But when we are simply
expanding the vma, we never remove it due to the "merge" with the added
area, so the test should not prevent the expansion.
As a quick fix, check for such vmas and expand them using vma_adjust()
directly as was done before commit ca3d76b0aa80. For a more robust long
term solution we should try to limit the check for vma_ops->close only to
cases that actually result in vma removal, so that no merge would be
prevented unnecessarily.
Link: https://lkml.kernel.org/r/20230117101939.9753-1-vbabka@suse.cz
Fixes: ca3d76b0aa80 ("mm: add merging after mremap resize")
Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz>
Reported-by: Fabian Vogt <fvogt(a)suse.com>
Link: https://bugzilla.suse.com/show_bug.cgi?id=1206359#c35
Tested-by: Fabian Vogt <fvogt(a)suse.com>
Cc: Jakub Mat��na <matenajakub(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/mm/mremap.c~mm-mremap-fix-mremap-expanding-for-vmas-with-vm_ops-close
+++ a/mm/mremap.c
@@ -1032,11 +1032,22 @@ SYSCALL_DEFINE5(mremap, unsigned long, a
* the already existing vma (expand operation itself) and possibly also
* with the next vma if it becomes adjacent to the expanded vma and
* otherwise compatible.
+ *
+ * However, vma_merge() can currently fail due to is_mergeable_vma()
+ * check for vm_ops->close (see the comment there). Yet this should not
+ * prevent vma expanding, so perform a simple expand for such vma.
+ * Ideally the check for close op should be only done when a vma would
+ * be actually removed due to a merge.
*/
- vma = vma_merge(mm, vma, extension_start, extension_end,
+ if (!vma->vm_ops || !vma->vm_ops->close) {
+ vma = vma_merge(mm, vma, extension_start, extension_end,
vma->vm_flags, vma->anon_vma, vma->vm_file,
extension_pgoff, vma_policy(vma),
vma->vm_userfaultfd_ctx, anon_vma_name(vma));
+ } else if (vma_adjust(vma, vma->vm_start, addr + new_len,
+ vma->vm_pgoff, NULL)) {
+ vma = NULL;
+ }
if (!vma) {
vm_unacct_memory(pages);
ret = -ENOMEM;
_
Patches currently in -mm which might be from vbabka(a)suse.cz are
revert-mm-compaction-fix-set-skip-in-fast_find_migrateblock.patch
mm-mremap-fix-mremap-expanding-for-vmas-with-vm_ops-close.patch
The patch titled
Subject: ia64: fix build error due to switch case label appearing next to declaration
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
ia64-fix-build-error-due-to-switch-case-label-appearing-next-to-declaration.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche…
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: James Morse <james.morse(a)arm.com>
Subject: ia64: fix build error due to switch case label appearing next to declaration
Date: Tue, 17 Jan 2023 15:16:32 +0000
Since commit aa06a9bd8533 ("ia64: fix clock_getres(CLOCK_MONOTONIC) to
report ITC frequency"), gcc 10.1.0 fails to build ia64 with the gnomic:
| ../arch/ia64/kernel/sys_ia64.c: In function 'ia64_clock_getres':
| ../arch/ia64/kernel/sys_ia64.c:189:3: error: a label can only be part of a statement and a declaration is not a statement
| 189 | s64 tick_ns = DIV_ROUND_UP(NSEC_PER_SEC, local_cpu_data->itc_freq);
This line appears immediately after a case label in a switch.
Move the declarations out of the case, to the top of the function.
Link: https://lkml.kernel.org/r/20230117151632.393836-1-james.morse@arm.com
Fixes: aa06a9bd8533 ("ia64: fix clock_getres(CLOCK_MONOTONIC) to report ITC frequency")
Signed-off-by: James Morse <james.morse(a)arm.com>
Cc: ��meric Maschino <emeric.maschino(a)gmail.com>
Cc: matoro <matoro_mailinglist_kernel(a)matoro.tk>
Cc: Sergei Trofimovich <slyich(a)gmail.com>
Cc: John Paul Adrian Glaubitz <glaubitz(a)physik.fu-berlin.de>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/arch/ia64/kernel/sys_ia64.c~ia64-fix-build-error-due-to-switch-case-label-appearing-next-to-declaration
+++ a/arch/ia64/kernel/sys_ia64.c
@@ -170,6 +170,9 @@ ia64_mremap (unsigned long addr, unsigne
asmlinkage long
ia64_clock_getres(const clockid_t which_clock, struct __kernel_timespec __user *tp)
{
+ struct timespec64 rtn_tp;
+ s64 tick_ns;
+
/*
* ia64's clock_gettime() syscall is implemented as a vdso call
* fsys_clock_gettime(). Currently it handles only
@@ -185,8 +188,8 @@ ia64_clock_getres(const clockid_t which_
switch (which_clock) {
case CLOCK_REALTIME:
case CLOCK_MONOTONIC:
- s64 tick_ns = DIV_ROUND_UP(NSEC_PER_SEC, local_cpu_data->itc_freq);
- struct timespec64 rtn_tp = ns_to_timespec64(tick_ns);
+ tick_ns = DIV_ROUND_UP(NSEC_PER_SEC, local_cpu_data->itc_freq);
+ rtn_tp = ns_to_timespec64(tick_ns);
return put_timespec64(&rtn_tp, tp);
}
_
Patches currently in -mm which might be from james.morse(a)arm.com are
ia64-fix-build-error-due-to-switch-case-label-appearing-next-to-declaration.patch
This is a note to let you know that I've just added the patch titled
usb: chipidea: core: fix possible constant 0 if use
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
From f96c0384047257365371a8ac217107c0371586f1 Mon Sep 17 00:00:00 2001
From: Xu Yang <xu.yang_2(a)nxp.com>
Date: Thu, 15 Dec 2022 13:54:09 +0800
Subject: usb: chipidea: core: fix possible constant 0 if use
IS_ERR(ci->role_switch)
After successfully probed, ci->role_switch would only be NULL or a valid
pointer. IS_ERR(ci->role_switch) will always return 0. So no need to wrap
it with IS_ERR, otherwise the logic is wrong.
Fixes: e1b5d2bed67c ("usb: chipidea: core: handle usb role switch in a common way")
cc: <stable(a)vger.kernel.org>
Signed-off-by: Xu Yang <xu.yang_2(a)nxp.com>
Link: https://lore.kernel.org/r/20221215055409.3760523-1-xu.yang_2@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/chipidea/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 484b1cd23431..27c601296130 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -1294,12 +1294,12 @@ static void ci_extcon_wakeup_int(struct ci_hdrc *ci)
cable_id = &ci->platdata->id_extcon;
cable_vbus = &ci->platdata->vbus_extcon;
- if ((!IS_ERR(cable_id->edev) || !IS_ERR(ci->role_switch))
+ if ((!IS_ERR(cable_id->edev) || ci->role_switch)
&& ci->is_otg &&
(otgsc & OTGSC_IDIE) && (otgsc & OTGSC_IDIS))
ci_irq(ci);
- if ((!IS_ERR(cable_vbus->edev) || !IS_ERR(ci->role_switch))
+ if ((!IS_ERR(cable_vbus->edev) || ci->role_switch)
&& ci->is_otg &&
(otgsc & OTGSC_BSVIE) && (otgsc & OTGSC_BSVIS))
ci_irq(ci);
--
2.39.0
This is a note to let you know that I've just added the patch titled
USB: gadgetfs: Fix race between mounting and unmounting
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
From d18dcfe9860e842f394e37ba01ca9440ab2178f4 Mon Sep 17 00:00:00 2001
From: Alan Stern <stern(a)rowland.harvard.edu>
Date: Fri, 23 Dec 2022 09:59:09 -0500
Subject: USB: gadgetfs: Fix race between mounting and unmounting
The syzbot fuzzer and Gerald Lee have identified a use-after-free bug
in the gadgetfs driver, involving processes concurrently mounting and
unmounting the gadgetfs filesystem. In particular, gadgetfs_fill_super()
can race with gadgetfs_kill_sb(), causing the latter to deallocate
the_device while the former is using it. The output from KASAN says,
in part:
BUG: KASAN: use-after-free in instrument_atomic_read_write include/linux/instrumented.h:102 [inline]
BUG: KASAN: use-after-free in atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]
BUG: KASAN: use-after-free in __refcount_sub_and_test include/linux/refcount.h:272 [inline]
BUG: KASAN: use-after-free in __refcount_dec_and_test include/linux/refcount.h:315 [inline]
BUG: KASAN: use-after-free in refcount_dec_and_test include/linux/refcount.h:333 [inline]
BUG: KASAN: use-after-free in put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]
BUG: KASAN: use-after-free in gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086
Write of size 4 at addr ffff8880276d7840 by task syz-executor126/18689
CPU: 0 PID: 18689 Comm: syz-executor126 Not tainted 6.1.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
<TASK>
...
atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]
__refcount_sub_and_test include/linux/refcount.h:272 [inline]
__refcount_dec_and_test include/linux/refcount.h:315 [inline]
refcount_dec_and_test include/linux/refcount.h:333 [inline]
put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]
gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086
deactivate_locked_super+0xa7/0xf0 fs/super.c:332
vfs_get_super fs/super.c:1190 [inline]
get_tree_single+0xd0/0x160 fs/super.c:1207
vfs_get_tree+0x88/0x270 fs/super.c:1531
vfs_fsconfig_locked fs/fsopen.c:232 [inline]
The simplest solution is to ensure that gadgetfs_fill_super() and
gadgetfs_kill_sb() are serialized by making them both acquire a new
mutex.
Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu>
Reported-and-tested-by: syzbot+33d7ad66d65044b93f16(a)syzkaller.appspotmail.com
Reported-and-tested-by: Gerald Lee <sundaywind2004(a)gmail.com>
Link: https://lore.kernel.org/linux-usb/CAO3qeMVzXDP-JU6v1u5Ags6Q-bb35kg3=C6d04Dj…
Fixes: e5d82a7360d1 ("vfs: Convert gadgetfs to use the new mount API")
CC: <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/Y6XCPXBpn3tmjdCC@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/legacy/inode.c | 28 +++++++++++++++++++++-------
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/gadget/legacy/inode.c b/drivers/usb/gadget/legacy/inode.c
index 01c3ead7d1b4..d605bc2e7e8f 100644
--- a/drivers/usb/gadget/legacy/inode.c
+++ b/drivers/usb/gadget/legacy/inode.c
@@ -229,6 +229,7 @@ static void put_ep (struct ep_data *data)
*/
static const char *CHIP;
+static DEFINE_MUTEX(sb_mutex); /* Serialize superblock operations */
/*----------------------------------------------------------------------*/
@@ -2010,13 +2011,20 @@ gadgetfs_fill_super (struct super_block *sb, struct fs_context *fc)
{
struct inode *inode;
struct dev_data *dev;
+ int rc;
- if (the_device)
- return -ESRCH;
+ mutex_lock(&sb_mutex);
+
+ if (the_device) {
+ rc = -ESRCH;
+ goto Done;
+ }
CHIP = usb_get_gadget_udc_name();
- if (!CHIP)
- return -ENODEV;
+ if (!CHIP) {
+ rc = -ENODEV;
+ goto Done;
+ }
/* superblock */
sb->s_blocksize = PAGE_SIZE;
@@ -2053,13 +2061,17 @@ gadgetfs_fill_super (struct super_block *sb, struct fs_context *fc)
* from binding to a controller.
*/
the_device = dev;
- return 0;
+ rc = 0;
+ goto Done;
-Enomem:
+ Enomem:
kfree(CHIP);
CHIP = NULL;
+ rc = -ENOMEM;
- return -ENOMEM;
+ Done:
+ mutex_unlock(&sb_mutex);
+ return rc;
}
/* "mount -t gadgetfs path /dev/gadget" ends up here */
@@ -2081,6 +2093,7 @@ static int gadgetfs_init_fs_context(struct fs_context *fc)
static void
gadgetfs_kill_sb (struct super_block *sb)
{
+ mutex_lock(&sb_mutex);
kill_litter_super (sb);
if (the_device) {
put_dev (the_device);
@@ -2088,6 +2101,7 @@ gadgetfs_kill_sb (struct super_block *sb)
}
kfree(CHIP);
CHIP = NULL;
+ mutex_unlock(&sb_mutex);
}
/*----------------------------------------------------------------------*/
--
2.39.0
This is a note to let you know that I've just added the patch titled
usb: cdns3: remove fetched trb from cache before dequeuing
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
From 1301c7b9f7efad2f11ef924e317c18ebd714fc9a Mon Sep 17 00:00:00 2001
From: Pawel Laszczak <pawell(a)cadence.com>
Date: Tue, 15 Nov 2022 05:00:39 -0500
Subject: usb: cdns3: remove fetched trb from cache before dequeuing
After doorbell DMA fetches the TRB. If during dequeuing request
driver changes NORMAL TRB to LINK TRB but doesn't delete it from
controller cache then controller will handle cached TRB and packet
can be lost.
The example scenario for this issue looks like:
1. queue request - set doorbell
2. dequeue request
3. send OUT data packet from host
4. Device will accept this packet which is unexpected
5. queue new request - set doorbell
6. Device lost the expected packet.
By setting DFLUSH controller clears DRDY bit and stop DMA transfer.
Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
cc: <stable(a)vger.kernel.org>
Signed-off-by: Pawel Laszczak <pawell(a)cadence.com>
Acked-by: Peter Chen <peter.chen(a)kernel.org>
Link: https://lore.kernel.org/r/20221115100039.441295-1-pawell@cadence.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/cdns3/cdns3-gadget.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/usb/cdns3/cdns3-gadget.c b/drivers/usb/cdns3/cdns3-gadget.c
index 5adcb349718c..ccfaebca6faa 100644
--- a/drivers/usb/cdns3/cdns3-gadget.c
+++ b/drivers/usb/cdns3/cdns3-gadget.c
@@ -2614,6 +2614,7 @@ int cdns3_gadget_ep_dequeue(struct usb_ep *ep,
u8 req_on_hw_ring = 0;
unsigned long flags;
int ret = 0;
+ int val;
if (!ep || !request || !ep->desc)
return -EINVAL;
@@ -2649,6 +2650,13 @@ int cdns3_gadget_ep_dequeue(struct usb_ep *ep,
/* Update ring only if removed request is on pending_req_list list */
if (req_on_hw_ring && link_trb) {
+ /* Stop DMA */
+ writel(EP_CMD_DFLUSH, &priv_dev->regs->ep_cmd);
+
+ /* wait for DFLUSH cleared */
+ readl_poll_timeout_atomic(&priv_dev->regs->ep_cmd, val,
+ !(val & EP_CMD_DFLUSH), 1, 1000);
+
link_trb->buffer = cpu_to_le32(TRB_BUFFER(priv_ep->trb_pool_dma +
((priv_req->end_trb + 1) * TRB_SIZE)));
link_trb->control = cpu_to_le32((le32_to_cpu(link_trb->control) & TRB_CYCLE) |
@@ -2660,6 +2668,10 @@ int cdns3_gadget_ep_dequeue(struct usb_ep *ep,
cdns3_gadget_giveback(priv_ep, priv_req, -ECONNRESET);
+ req = cdns3_next_request(&priv_ep->pending_req_list);
+ if (req)
+ cdns3_rearm_transfer(priv_ep, 1);
+
not_found:
spin_unlock_irqrestore(&priv_dev->lock, flags);
return ret;
--
2.39.0
The commit e00b488e813f ("usb-storage: Add Hiksemi USB3-FW to IGNORE_UAS")
blacklists UAS for all of RTL9210 enclosures.
The RTL9210 controller was advertised with UAS since its release back in
2019 and was shipped with a lot of enclosure products with different
firmware combinations.
Blacklist UAS only for HIKSEMI MD202.
This should hopefully be replaced with more robust method than just
comparing strings. But with limited information [1] provided thus far
(dmesg when the device is plugged in, which includes manufacturer and
product, but no lsusb -v to compare against), this is the best we can do
for now.
[1] https://lore.kernel.org/all/20230109115550.71688-1-qkrwngud825@gmail.com
Fixes: e00b488e813f ("usb-storage: Add Hiksemi USB3-FW to IGNORE_UAS")
Cc: Alan Stern <stern(a)rowland.harvard.edu>
Cc: Hongling Zeng <zenghongling(a)kylinos.cn>
Cc: stable(a)vger.kernel.org
Signed-off-by: Juhyung Park <qkrwngud825(a)gmail.com>
---
drivers/usb/storage/uas-detect.h | 13 +++++++++++++
drivers/usb/storage/unusual_uas.h | 7 -------
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/storage/uas-detect.h b/drivers/usb/storage/uas-detect.h
index 3f720faa6f97..d73282c0ec50 100644
--- a/drivers/usb/storage/uas-detect.h
+++ b/drivers/usb/storage/uas-detect.h
@@ -116,6 +116,19 @@ static int uas_use_uas_driver(struct usb_interface *intf,
if (le16_to_cpu(udev->descriptor.idVendor) == 0x0bc2)
flags |= US_FL_NO_ATA_1X;
+ /*
+ * RTL9210-based enclosure from HIKSEMI, MD202 reportedly have issues
+ * with UAS. This isn't distinguishable with just idVendor and
+ * idProduct, use manufacturer and product too.
+ *
+ * Reported-by: Hongling Zeng <zenghongling(a)kylinos.cn>
+ */
+ if (le16_to_cpu(udev->descriptor.idVendor) == 0x0bda &&
+ le16_to_cpu(udev->descriptor.idProduct) == 0x9210 &&
+ (udev->manufacturer && !strcmp(udev->manufacturer, "HIKSEMI")) &&
+ (udev->product && !strcmp(udev->product, "MD202")))
+ flags |= US_FL_IGNORE_UAS;
+
usb_stor_adjust_quirks(udev, &flags);
if (flags & US_FL_IGNORE_UAS) {
diff --git a/drivers/usb/storage/unusual_uas.h b/drivers/usb/storage/unusual_uas.h
index 251778d14e2d..c7b763d6d102 100644
--- a/drivers/usb/storage/unusual_uas.h
+++ b/drivers/usb/storage/unusual_uas.h
@@ -83,13 +83,6 @@ UNUSUAL_DEV(0x0bc2, 0x331a, 0x0000, 0x9999,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_NO_REPORT_LUNS),
-/* Reported-by: Hongling Zeng <zenghongling(a)kylinos.cn> */
-UNUSUAL_DEV(0x0bda, 0x9210, 0x0000, 0x9999,
- "Hiksemi",
- "External HDD",
- USB_SC_DEVICE, USB_PR_DEVICE, NULL,
- US_FL_IGNORE_UAS),
-
/* Reported-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com> */
UNUSUAL_DEV(0x13fd, 0x3940, 0x0000, 0x9999,
"Initio Corporation",
--
2.39.0
This is the start of the stable review cycle for the 5.10.164 release.
There are 64 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 Wed, 18 Jan 2023 15:47:28 +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/v5.x/stable-review/patch-5.10.164-r…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.10.164-rc1
Ferry Toth <ftoth(a)exalondelft.nl>
Revert "usb: ulpi: defer ulpi_register on ulpi_read_id timeout"
Jens Axboe <axboe(a)kernel.dk>
io_uring/io-wq: only free worker if it was allocated for creation
Jens Axboe <axboe(a)kernel.dk>
io_uring/io-wq: free worker if task_work creation is canceled
Rob Clark <robdclark(a)chromium.org>
drm/virtio: Fix GEM handle creation UAF
Johan Hovold <johan+linaro(a)kernel.org>
efi: fix NULL-deref in init error path
Mark Rutland <mark.rutland(a)arm.com>
arm64: cmpxchg_double*: hazard against entire exchange variable
Mark Rutland <mark.rutland(a)arm.com>
arm64: atomics: remove LL/SC trampolines
Mark Rutland <mark.rutland(a)arm.com>
arm64: atomics: format whitespace consistently
Peter Newman <peternewman(a)google.com>
x86/resctrl: Fix task CLOSID/RMID update race
Reinette Chatre <reinette.chatre(a)intel.com>
x86/resctrl: Use task_curr() instead of task_struct->on_cpu to prevent unnecessary IPI
Paolo Bonzini <pbonzini(a)redhat.com>
KVM: x86: Do not return host topology information from KVM_GET_SUPPORTED_CPUID
Paolo Bonzini <pbonzini(a)redhat.com>
Documentation: KVM: add API issues section
Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
iommu/mediatek-v1: Fix an error handling path in mtk_iommu_v1_probe()
Yong Wu <yong.wu(a)mediatek.com>
iommu/mediatek-v1: Add error handle for mtk_iommu_probe
Aaron Thompson <dev(a)aaront.org>
mm: Always release pages to the buddy allocator in memblock_free_late().
Gavin Li <gavinl(a)nvidia.com>
net/mlx5e: Don't support encap rules with gbp option
Rahul Rameshbabu <rrameshbabu(a)nvidia.com>
net/mlx5: Fix ptp max frequency adjustment range
Ido Schimmel <idosch(a)nvidia.com>
net/sched: act_mpls: Fix warning during failed attribute validation
Minsuk Kang <linuxlovemin(a)yonsei.ac.kr>
nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame()
Roger Pau Monne <roger.pau(a)citrix.com>
hvc/xen: lock console list traversal
Angela Czubak <aczubak(a)marvell.com>
octeontx2-af: Fix LMAC config in cgx_lmac_rx_tx_enable
Subbaraya Sundeep <sbhatta(a)marvell.com>
octeontx2-af: Map NIX block from CGX connection
Subbaraya Sundeep <sbhatta(a)marvell.com>
octeontx2-af: Update get/set resource count functions
Tung Nguyen <tung.q.nguyen(a)dektech.com.au>
tipc: fix unexpected link reset due to discovery messages
Emanuele Ghidoli <emanuele.ghidoli(a)toradex.com>
ASoC: wm8904: fix wrong outputs volume after power reactivation
Ricardo Ribalda <ribalda(a)chromium.org>
regulator: da9211: Use irq handler when ready
Eliav Farber <farbere(a)amazon.com>
EDAC/device: Fix period calculation in edac_device_reset_delay_period()
Peter Zijlstra <peterz(a)infradead.org>
x86/boot: Avoid using Intel mnemonics in AT&T syntax asm
Kajol Jain <kjain(a)linux.ibm.com>
powerpc/imc-pmu: Fix use of mutex in IRQs disabled section
Gavrilov Ilia <Ilia.Gavrilov(a)infotecs.ru>
netfilter: ipset: Fix overflow before widen in the bitmap_ip_create() function.
Nicolas Dichtel <nicolas.dichtel(a)6wind.com>
xfrm: fix rcu lock in xfrm_notify_userpolicy()
Ye Bin <yebin10(a)huawei.com>
ext4: fix uninititialized value in 'ext4_evict_inode'
Ferry Toth <ftoth(a)exalondelft.nl>
usb: ulpi: defer ulpi_register on ulpi_read_id timeout
Mathias Nyman <mathias.nyman(a)linux.intel.com>
xhci: Prevent infinite loop in transaction errors recovery for streams
Mathias Nyman <mathias.nyman(a)linux.intel.com>
xhci: move and rename xhci_cleanup_halted_endpoint()
Mathias Nyman <mathias.nyman(a)linux.intel.com>
xhci: store TD status in the td struct instead of passing it along
Mathias Nyman <mathias.nyman(a)linux.intel.com>
xhci: move xhci_td_cleanup so it can be called by more functions
Mathias Nyman <mathias.nyman(a)linux.intel.com>
xhci: Add xhci_reset_halted_ep() helper function
Mathias Nyman <mathias.nyman(a)linux.intel.com>
xhci: adjust parameters passed to cleanup_halted_endpoint()
Mathias Nyman <mathias.nyman(a)linux.intel.com>
xhci: get isochronous ring directly from endpoint structure
Mathias Nyman <mathias.nyman(a)linux.intel.com>
xhci: Avoid parsing transfer events several times
Li Jun <jun.li(a)nxp.com>
clk: imx: imx8mp: add shared clk gate for usb suspend clk
Li Jun <jun.li(a)nxp.com>
dt-bindings: clocks: imx8mp: Add ID for usb suspend clock
Lucas Stach <l.stach(a)pengutronix.de>
clk: imx8mp: add clkout1/2 support
Marek Vasut <marex(a)denx.de>
clk: imx8mp: Add DISP2 pixel clock
Kim Phillips <kim.phillips(a)amd.com>
iommu/amd: Fix ill-formed ivrs_ioapic, ivrs_hpet and ivrs_acpihid options
Suravee Suthikulpanit <suravee.suthikulpanit(a)amd.com>
iommu/amd: Add PCI segment support for ivrs_[ioapic/hpet/acpihid] commands
Qiang Yu <quic_qianyu(a)quicinc.com>
bus: mhi: host: Fix race between channel preparation and M0 event
Herbert Xu <herbert(a)gondor.apana.org.au>
ipv6: raw: Deduct extension header length in rawv6_push_pending_frames
Yang Yingliang <yangyingliang(a)huawei.com>
ixgbe: fix pci device refcount leak
Hans de Goede <hdegoede(a)redhat.com>
platform/x86: sony-laptop: Don't turn off 0x153 keyboard backlight during probe
Kuogee Hsieh <quic_khsieh(a)quicinc.com>
drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer
Konrad Dybcio <konrad.dybcio(a)linaro.org>
drm/msm/adreno: Make adreno quirks not overwrite each other
Volker Lendecke <vl(a)samba.org>
cifs: Fix uninitialized memory read for smb311 posix symlink create
Heiko Carstens <hca(a)linux.ibm.com>
s390/percpu: add READ_ONCE() to arch_this_cpu_to_op_simple()
Heiko Carstens <hca(a)linux.ibm.com>
s390/cpum_sf: add READ_ONCE() semantics to compare and swap loops
Brian Norris <computersforpeace(a)gmail.com>
ASoC: qcom: lpass-cpu: Fix fallback SD line index handling
Alexander Egorenkov <egorenar(a)linux.ibm.com>
s390/kexec: fix ipl report address for kdump
Adrian Hunter <adrian.hunter(a)intel.com>
perf auxtrace: Fix address filter duplicate symbol selection
Jonathan Corbet <corbet(a)lwn.net>
docs: Fix the docs build with Sphinx 6.0
Ard Biesheuvel <ardb(a)kernel.org>
efi: tpm: Avoid READ_ONCE() for accessing the event log
Marc Zyngier <maz(a)kernel.org>
KVM: arm64: Fix S1PTW handling on RO memslots
Luka Guzenko <l.guzenko(a)web.de>
ALSA: hda/realtek: Enable mute/micmute LEDs on HP Spectre x360 13-aw0xxx
Pablo Neira Ayuso <pablo(a)netfilter.org>
netfilter: nft_payload: incorrect arithmetics when fetching VLAN header bits
-------------
Diffstat:
Documentation/admin-guide/kernel-parameters.txt | 51 +++-
Documentation/sphinx/load_config.py | 6 +-
Documentation/virt/kvm/api.rst | 60 +++++
Makefile | 4 +-
arch/arm64/include/asm/atomic_ll_sc.h | 114 ++++----
arch/arm64/include/asm/atomic_lse.h | 16 +-
arch/arm64/include/asm/kvm_emulate.h | 22 +-
arch/powerpc/include/asm/imc-pmu.h | 2 +-
arch/powerpc/perf/imc-pmu.c | 136 +++++-----
arch/s390/include/asm/cpu_mf.h | 31 ++-
arch/s390/include/asm/percpu.h | 2 +-
arch/s390/kernel/machine_kexec_file.c | 5 +-
arch/s390/kernel/perf_cpum_sf.c | 101 ++++---
arch/x86/boot/bioscall.S | 4 +-
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 26 +-
arch/x86/kvm/cpuid.c | 32 +--
drivers/bus/mhi/core/pm.c | 3 +-
drivers/clk/imx/clk-imx8mp.c | 23 +-
drivers/edac/edac_device.c | 17 +-
drivers/edac/edac_module.h | 2 +-
drivers/firmware/efi/efi.c | 9 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 10 +-
drivers/gpu/drm/msm/dp/dp_aux.c | 4 +
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 10 +-
drivers/iommu/amd/init.c | 89 ++++--
drivers/iommu/mtk_iommu_v1.c | 26 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 14 +-
drivers/net/ethernet/marvell/octeontx2/af/cgx.c | 17 +-
drivers/net/ethernet/marvell/octeontx2/af/cgx.h | 6 +-
drivers/net/ethernet/marvell/octeontx2/af/rvu.c | 134 ++++++++--
drivers/net/ethernet/marvell/octeontx2/af/rvu.h | 4 +
.../net/ethernet/marvell/octeontx2/af/rvu_cgx.c | 15 ++
.../net/ethernet/marvell/octeontx2/af/rvu_nix.c | 21 +-
.../ethernet/mellanox/mlx5/core/en/tc_tun_vxlan.c | 2 +
.../net/ethernet/mellanox/mlx5/core/lib/clock.c | 2 +-
drivers/nfc/pn533/usb.c | 44 ++-
drivers/platform/x86/sony-laptop.c | 21 +-
drivers/regulator/da9211-regulator.c | 11 +-
drivers/tty/hvc/hvc_xen.c | 46 ++--
drivers/usb/host/xhci-mem.c | 4 +
drivers/usb/host/xhci-ring.c | 297 +++++++++++----------
drivers/usb/host/xhci.h | 6 +-
fs/cifs/link.c | 1 +
fs/ext4/super.c | 1 +
include/dt-bindings/clock/imx8mp-clock.h | 10 +-
include/linux/tpm_eventlog.h | 4 +-
io_uring/io-wq.c | 6 +
mm/memblock.c | 8 +-
net/ipv6/raw.c | 4 +
net/netfilter/ipset/ip_set_bitmap_ip.c | 4 +-
net/netfilter/nft_payload.c | 2 +-
net/sched/act_mpls.c | 8 +-
net/tipc/node.c | 12 +-
net/xfrm/xfrm_user.c | 7 +-
sound/pci/hda/patch_realtek.c | 23 ++
sound/soc/codecs/wm8904.c | 7 +
sound/soc/qcom/lpass-cpu.c | 5 +-
tools/perf/util/auxtrace.c | 2 +-
58 files changed, 1015 insertions(+), 538 deletions(-)
Dear Linux folks,
Could you please apply commit 0c25422d34b4 (scsi: mpt3sas: Remove
scsi_dma_map() error messages) to the 5.15.y series?
commit 0c25422d34b4726b2707d5f38560943155a91b80
Author: Sreekanth Reddy <sreekanth.reddy(a)broadcom.com>
Date: Thu Mar 3 19:32:03 2022 +0530
scsi: mpt3sas: Remove scsi_dma_map() error messages
When scsi_dma_map() fails by returning a sges_left value less than
zero,
the amount of logging produced can be extremely high. In a recent
end-user
environment, 1200 messages per second were being sent to the log
buffer.
This eventually overwhelmed the system and it stalled.
These error messages are not needed. Remove them.
Link:
https://lore.kernel.org/r/20220303140203.12642-1-sreekanth.reddy@broadcom.c…
Suggested-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Sreekanth Reddy <sreekanth.reddy(a)broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
We see this regression after upgrading from Linux 5.10 to 5.15 on our
file servers with Broadcom/LSI SAS3008 PCI-Express Fusion-MPT SAS-3
(mpt3sas) – though luckily our systems do not stall/crash.
The commit message does not say anything about, what commit caused these
error to be appearing – the log statements have been there since
v4.20-rc1, if I am not mistaken, so it must be something else –, and
also do not mention, why these log messages are not needed, but the new
error condition is actually expected.
In the Canonical/Ubuntu bug tracker I found the explanation below [2].
> 2. mpt3sas: Remove scsi_dma_map errors messages:
> When driver set the DMA mask to 32bit then we observe that the
> SWIOTLB bounce buffers are getting exhausted quickly. For most of the
> IOs driver observe that scsi_dma_map() API returned with failure
> status and hence driver was printing below error message. Since this
> error message is getting printed per IO and if user issues heavy IOs
> then we observe that kernel overwhelmed with this error message. Also
> we will observe the kernel panic when the serial console is enabled.
> So to limit this issue, we removed this error message though this
> patch.
> "scsi_dma_map failed: request for 1310720 bytes!"
The Launchpad issue was created in March 2022, and the fixed Linux
kernel package 5.15.0-53.59 for Ubuntu 22.04 released on November 15th,
2022.
Sreekanth, looking again, you are the patch author, one of the Broadcom
maintainers (LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)) and created the
Launchpad bug report. I am surprised you didn’t get it backported upstream.
Kind regards,
Paul
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
[2]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1965927
"[Ubuntu 22.04] mpt3sas: Request to include latest bug fix patches"