* [PATCH 6.15 000/480] 6.15.10-rc1 review
@ 2025-08-12 17:43 Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 001/480] drm/radeon: Do not hold console lock while suspending clients Greg Kroah-Hartman
` (491 more replies)
0 siblings, 492 replies; 1767+ messages in thread
From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, linux-kernel, torvalds, akpm, linux,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie, achill
This is the start of the stable review cycle for the 6.15.10 release.
There are 480 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, 14 Aug 2025 17:42:20 +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/v6.x/stable-review/patch-6.15.10-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.15.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 6.15.10-rc1
Suren Baghdasaryan <surenb@google.com>
mm: fix a UAF when vma->mm is freed after vma->vm_refcnt got dropped
Tao Xue <xuetao09@huawei.com>
usb: gadget : fix use-after-free in composite_dev_cleanup()
Aditya Garg <gargaditya08@live.com>
HID: apple: avoid setting up battery timer for devices without battery
Alan Stern <stern@rowland.harvard.edu>
HID: core: Harden s32ton() against conversion to 0 bits
Yuhao Jiang <danisjiang@gmail.com>
USB: gadget: f_hid: Fix memory leak in hidg_bind error path
Qasim Ijaz <qasdev00@gmail.com>
HID: apple: validate feature-report field count to prevent NULL pointer dereference
Julien Massot <julien.massot@collabora.com>
media: ti: j721e-csi2rx: fix list_del corruption
Robin Murphy <robin.murphy@arm.com>
perf/arm-ni: Set initial IRQ affinity
Akash Kumar <quic_akakum@quicinc.com>
usb: gadget: uvc: Initialize frame-based format color matching descriptor
Baolin Wang <baolin.wang@linux.alibaba.com>
mm: shmem: fix the shmem large folio allocation for the i915 driver
Kemeng Shi <shikemeng@huaweicloud.com>
mm: swap: move nr_swap_pages counter decrement from folio_alloc_swap() to swap_range_alloc()
Kemeng Shi <shikemeng@huaweicloud.com>
mm: swap: fix potential buffer overflow in setup_clusters()
Kemeng Shi <shikemeng@huaweicloud.com>
mm: swap: correctly use maxpages in swapon syscall to avoid potential deadloop
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
mm/hmm: move pmd_to_hmm_pfn_flags() to the respective #ifdeffery
Jiaxun Yang <jiaxun.yang@flygoat.com>
MIPS: mm: tlb-r4k: Uniquify TLB entries on init
Gerald Schaefer <gerald.schaefer@linux.ibm.com>
s390/mm: Remove possible false-positive warning in pte_free_defer()
Sean Christopherson <seanjc@google.com>
KVM: VMX: Allow guest to set DEBUGCTL.RTM_DEBUG if RTM is supported
Dave Hansen <dave.hansen@linux.intel.com>
x86/fpu: Delay instruction pointer fixup until after warning
Michael J. Ruhl <michael.j.ruhl@intel.com>
platform/x86/intel/pmt: fix a crashlog NULL pointer access
Edip Hazuri <edip@medip.dev>
ALSA: hda/realtek - Fix mute LED for HP Victus 16-d1xxx (MB 8A26)
Edip Hazuri <edip@medip.dev>
ALSA: hda/realtek - Fix mute LED for HP Victus 16-s0xxx
Edip Hazuri <edip@medip.dev>
ALSA: hda/realtek - Fix mute LED for HP Victus 16-r1xxx
Geoffrey D. Bennett <g@b4.vu>
ALSA: scarlett2: Add retry on -EPROTO from scarlett2_usb_tx()
Thorsten Blum <thorsten.blum@linux.dev>
ALSA: intel_hdmi: Fix off-by-one error in __hdmi_lpe_audio_probe()
Tom Lendacky <thomas.lendacky@amd.com>
x86/sev: Evict cache lines during SNP memory validation
Ammar Faizi <ammarfaizi2@gnuweeb.org>
net: usbnet: Fix the wrong netif_carrier_on() call
John Ernberg <john.ernberg@actia.se>
net: usbnet: Avoid potential RCU stall on LINK_CHANGE event
Zenm Chen <zenmchen@gmail.com>
Bluetooth: btusb: Add USB ID 3625:010b for TP-LINK Archer TX10UB Nano
Slark Xiao <slark_xiao@163.com>
USB: serial: option: add Foxconn T99W709
Thorsten Blum <thorsten.blum@linux.dev>
smb: server: Fix extension string in ksmbd_extract_shortname()
Namjae Jeon <linkinjeon@kernel.org>
ksmbd: limit repeated connections from clients with the same IP
Paulo Alcantara <pc@manguebit.org>
smb: client: default to nonativesocket under POSIX mounts
Paulo Alcantara <pc@manguebit.org>
smb: client: set symlink type as native for POSIX mounts
Wang Zhaolong <wangzhaolong@huaweicloud.com>
smb: client: fix netns refcount leak after net_passive changes
Namjae Jeon <linkinjeon@kernel.org>
ksmbd: fix corrupted mtime and ctime in smb2_open
Namjae Jeon <linkinjeon@kernel.org>
ksmbd: fix Preauh_HashValue race condition
Namjae Jeon <linkinjeon@kernel.org>
ksmbd: fix null pointer dereference error in generate_encryptionkey
Budimir Markovic <markovicbudimir@gmail.com>
vsock: Do not allow binding to VMADDR_PORT_ANY
Quang Le <quanglex97@gmail.com>
net/packet: fix a race in packet_set_ring() and packet_notifier()
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
selftests/perf_events: Add a mmap() correctness test
Thomas Gleixner <tglx@linutronix.de>
perf/core: Prevent VMA split of buffer mappings
Thomas Gleixner <tglx@linutronix.de>
perf/core: Handle buffer mapping fail correctly in perf_mmap()
Thomas Gleixner <tglx@linutronix.de>
perf/core: Exit early on perf_mmap() fail
Thomas Gleixner <tglx@linutronix.de>
perf/core: Don't leak AUX buffer refcount on allocation failure
Thomas Gleixner <tglx@linutronix.de>
perf/core: Preserve AUX buffer allocation failure result
Olga Kornievskaia <okorniev@redhat.com>
sunrpc: fix handling of server side tls alerts
NeilBrown <neil@brown.name>
nfsd: avoid ref leak in nfsd_open_local_fh()
Jeff Layton <jlayton@kernel.org>
nfsd: don't set the ctime on delegated atime updates
Zhang Rui <rui.zhang@intel.com>
tools/power turbostat: Fix bogus SysWatt for forked program
Stefan Metzmacher <metze@samba.org>
smb: client: return an error if rdma_connect does not return within 5 seconds
Eric Dumazet <edumazet@google.com>
pptp: fix pptp_xmit() error path
Mohamed Khalfella <mkhalfella@purestorage.com>
nvmet: exit debugfs after discovery subsystem exits
Stefan Metzmacher <metze@samba.org>
smb: client: let recv_done() avoid touching data_transfer after cleanup/move
Stefan Metzmacher <metze@samba.org>
smb: client: let recv_done() cleanup before notifying the callers.
Stefan Metzmacher <metze@samba.org>
smb: client: make sure we call ib_dma_unmap_single() only if we called ib_dma_map_single already
Stefan Metzmacher <metze@samba.org>
smb: client: remove separate empty_packet_queue
Stefan Metzmacher <metze@samba.org>
smb: client: let send_done() cleanup before calling smbd_disconnect_rdma_connection()
Stefan Metzmacher <metze@samba.org>
smb: server: let recv_done() avoid touching data_transfer after cleanup/move
Stefan Metzmacher <metze@samba.org>
smb: server: let recv_done() consistently call put_recvmsg/smb_direct_disconnect_rdma_connection
Stefan Metzmacher <metze@samba.org>
smb: server: make sure we call ib_dma_unmap_single() only if we called ib_dma_map_single already
Stefan Metzmacher <metze@samba.org>
smb: server: remove separate empty_recvmsg_queue
Mikhail Zaslonko <zaslonko@linux.ibm.com>
s390/boot: Fix startup debugging log
Takashi Iwai <tiwai@suse.de>
ALSA: hda/ca0132: Fix missing error handling in ca0132_alt_select_out()
Arnd Bergmann <arnd@arndb.de>
ASoC: SOF: Intel: hda-sdw-bpt: fix SND_SOF_SOF_HDA_SDW_BPT dependencies
Arnd Bergmann <arnd@arndb.de>
irqchip: Build IMX_MU_MSI only on ARM
Meghana Malladi <m-malladi@ti.com>
net: ti: icssg-prueth: Fix skb handling for XDP_PASS
Trond Myklebust <trond.myklebust@hammerspace.com>
NFS/localio: nfs_uuid_put() fix the wake up after unlinking the file
Trond Myklebust <trond.myklebust@hammerspace.com>
NFS/localio: nfs_uuid_put() fix races with nfs_open/close_local_fh()
Trond Myklebust <trond.myklebust@hammerspace.com>
NFS/localio: nfs_close_local_fh() fix check for file closed
Jakub Kicinski <kuba@kernel.org>
eth: fbnic: remove the debugging trick of super high page bias
Sumanth Korikkar <sumanthk@linux.ibm.com>
s390/mm: Allocate page table with PAGE_SIZE granularity
Maher Azzouzi <maherazz04@gmail.com>
net/sched: mqprio: fix stack out-of-bounds write in tc entry parsing
Michal Schmidt <mschmidt@redhat.com>
benet: fix BUG when creating VFs
Lorenzo Bianconi <lorenzo@kernel.org>
net: airoha: npu: Add missing MODULE_FIRMWARE macros
Jakub Kicinski <kuba@kernel.org>
eth: fbnic: unlink NAPIs from queues on error to open
Thomas Gleixner <tglx@linutronix.de>
x86/irq: Plug vector setup race
Michal Wajdeczko <michal.wajdeczko@intel.com>
drm/xe/pf: Disable PF restart worker on device removal
Olga Kornievskaia <okorniev@redhat.com>
sunrpc: fix client side handling of tls alerts
Takamitsu Iwai <takamitz@amazon.co.jp>
net/sched: taprio: enforce minimum value for picos_per_byte
Wang Liang <wangliang74@huawei.com>
net: drop UFO packets in udp_rcv_segment()
Florian Fainelli <florian.fainelli@broadcom.com>
net: mdio: mdio-bcm-unimac: Correct rate fallback logic
Eric Dumazet <edumazet@google.com>
ipv6: reject malicious packets in ipv6_gso_segment()
Christoph Paasch <cpaasch@openai.com>
net/mlx5: Correctly set gso_segs when LRO is used
Simon Trimmer <simont@opensource.cirrus.com>
spi: cs42l43: Property entry should be a null-terminated array
Baojun Xu <baojun.xu@ti.com>
ASoC: tas2781: Fix the wrong step for TLV on tas2781
Christoph Hellwig <hch@lst.de>
block: ensure discard_granularity is zero when discard is not supported
Guenter Roeck <linux@roeck-us.net>
block: Fix default IO priority if there is no IO context
Jakub Kicinski <kuba@kernel.org>
netlink: specs: ethtool: fix module EEPROM input/output arguments
Alexander Gordeev <agordeev@linux.ibm.com>
s390/mm: Set high_memory at the end of the identity mapping
Harald Freudenberger <freude@linux.ibm.com>
s390/ap: Unmask SLCF bit in card and queue ap functions sysfs
Mohamed Khalfella <mkhalfella@purestorage.com>
nvmet: initialize discovery subsys after debugfs is initialized
Eric Dumazet <edumazet@google.com>
pptp: ensure minimal skb length in pptp_xmit()
Luca Weiss <luca.weiss@fairphone.com>
net: ipa: add IPA v5.1 and v5.5 to ipa_version_string()
Horatiu Vultur <horatiu.vultur@microchip.com>
phy: mscc: Fix parsing of unicast frames
Jakub Kicinski <kuba@kernel.org>
netpoll: prevent hanging NAPI when netcons gets enabled
Heming Zhao <heming.zhao@suse.com>
md/md-cluster: handle REMOVE message earlier
Benjamin Coddington <bcodding@redhat.com>
NFS: Fixup allocation flags for nfsiod's __GFP_NORETRY
Olga Kornievskaia <okorniev@redhat.com>
NFSv4.2: another fix for listxattr
Trond Myklebust <trond.myklebust@hammerspace.com>
NFS: Fix filehandle bounds checking in nfs_fh_to_dentry()
Trond Myklebust <trond.myklebust@hammerspace.com>
NFS: Fix wakeup of __nfs_lookup_revalidate() in unblock_revalidate()
Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
pNFS/flexfiles: don't attempt pnfs on fatal DS errors
Len Brown <len.brown@intel.com>
tools/power turbostat: regression fix: --show C1E%
Timothy Pearson <tpearson@raptorengineering.com>
PCI: pnv_php: Fix surprise plug detection and recovery
Timothy Pearson <tpearson@raptorengineering.com>
powerpc/eeh: Make EEH driver device hotplug safe
Timothy Pearson <tpearson@raptorengineering.com>
powerpc/eeh: Export eeh_unfreeze_pe()
Timothy Pearson <tpearson@raptorengineering.com>
PCI: pnv_php: Work around switches with broken presence detection
Timothy Pearson <tpearson@raptorengineering.com>
PCI: pnv_php: Clean up allocated IRQs on unplug
Herbert Xu <herbert@gondor.apana.org.au>
padata: Remove comment for reorder_work
Peter Zijlstra <peterz@infradead.org>
sched/psi: Fix psi_seq initialization
Jason Gunthorpe <jgg@ziepe.ca>
vfio/pci: Do vf_token checks for VFIO_DEVICE_BIND_IOMMUFD
Masahiro Yamada <masahiroy@kernel.org>
kconfig: qconf: fix ConfigList::updateListAllforAll()
Salomon Dushimirimana <salomondush@google.com>
scsi: sd: Make sd shutdown issue START STOP UNIT appropriately
Seunghui Lee <sh043.lee@samsung.com>
scsi: ufs: core: Use link recovery when h8 exit fails during runtime resume
Li Lingfeng <lilingfeng3@huawei.com>
scsi: Revert "scsi: iscsi: Fix HW conn removal use after free"
Tomas Henzl <thenzl@redhat.com>
scsi: mpt3sas: Fix a fw_event memory leak
Alex Williamson <alex.williamson@redhat.com>
vfio/pci: Separate SR-IOV VF dev_set
Brett Creeley <brett.creeley@amd.com>
vfio/pds: Fix missing detach_ioas op
Jacob Pan <jacob.pan@linux.microsoft.com>
vfio: Prevent open_count decrement to negative
Jacob Pan <jacob.pan@linux.microsoft.com>
vfio: Fix unbalanced vfio_df_close call in no-iommu mode
Christophe JAILLET <christophe.jaillet@wanadoo.fr>
i2c: muxes: mule: Fix an error handling path in mule_i2c_mux_probe()
Zhengxu Zhang <zhengxu.zhang@unisoc.com>
exfat: fdatasync flag should be same like generic_write_sync()
Chao Yu <chao@kernel.org>
f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode
Chao Yu <chao@kernel.org>
f2fs: fix to calculate dirty data during has_not_enough_free_secs()
Chao Yu <chao@kernel.org>
f2fs: fix to update upper_p in __get_secs_required() correctly
Jan Prusakowski <jprusakowski@google.com>
f2fs: vm_unmap_ram() may be called from an invalid context
Chao Yu <chao@kernel.org>
f2fs: fix to avoid out-of-boundary access in devs.path
Chao Yu <chao@kernel.org>
f2fs: fix to avoid panic in f2fs_evict_inode
Chao Yu <chao@kernel.org>
f2fs: fix to avoid UAF in f2fs_sync_inode_meta()
Chao Yu <chao@kernel.org>
f2fs: doc: fix wrong quota mount option description
Chao Yu <chao@kernel.org>
f2fs: fix to check upper boundary for gc_no_zoned_gc_percent
Chao Yu <chao@kernel.org>
f2fs: fix to check upper boundary for gc_valid_thresh_ratio
yohan.joung <yohan.joung@sk.com>
f2fs: fix to check upper boundary for value of gc_boost_zoned_gc_percent
Abinash Singh <abinashlalotra@gmail.com>
f2fs: fix KMSAN uninit-value in extent_info usage
Chao Yu <chao@kernel.org>
f2fs: fix to avoid invalid wait context issue
Sheng Yong <shengyong1@xiaomi.com>
f2fs: fix bio memleak when committing super block
Daeho Jeong <daehojeong@google.com>
f2fs: turn off one_time when forcibly set to foreground GC
Brian Masney <bmasney@redhat.com>
rtc: rv3028: fix incorrect maximum clock rate handling
Brian Masney <bmasney@redhat.com>
rtc: pcf8563: fix incorrect maximum clock rate handling
Brian Masney <bmasney@redhat.com>
rtc: pcf85063: fix incorrect maximum clock rate handling
Brian Masney <bmasney@redhat.com>
rtc: nct3018y: fix incorrect maximum clock rate handling
Brian Masney <bmasney@redhat.com>
rtc: hym8563: fix incorrect maximum clock rate handling
Brian Masney <bmasney@redhat.com>
rtc: ds1307: fix incorrect maximum clock rate handling
Uros Bizjak <ubizjak@gmail.com>
ucount: fix atomic_long_inc_below() argument type
Petr Pavlu <petr.pavlu@suse.com>
module: Restore the moduleparam prefix length check
Stanley Chu <yschu@nuvoton.com>
i3c: master: svc: Fix npcm845 FIFO_EMPTY quirk
Helge Deller <deller@gmx.de>
apparmor: Fix unaligned memory accesses in KUnit test
Johannes Berg <johannes.berg@intel.com>
scripts: gdb: move MNT_* constants to gdb-parsed
Ryan Lee <ryan.lee@canonical.com>
apparmor: fix loop detection used in conflicting attachment resolution
Ryan Lee <ryan.lee@canonical.com>
apparmor: ensure WB_HISTORY_SIZE value is a power of 2
Paul Chaignon <paul.chaignon@gmail.com>
bpf: Check netfilter ctx accesses are aligned
Paul Chaignon <paul.chaignon@gmail.com>
bpf: Check flow_dissector ctx accesses are aligned
Cindy Lu <lulu@redhat.com>
vhost: Reintroduce kthread API and add mode selection
Anders Roxell <anders.roxell@linaro.org>
vdpa: Fix IDR memory leak in VDUSE module exit
Dragos Tatulea <dtatulea@nvidia.com>
vdpa/mlx5: Fix release of uninitialized resources on error path
Alok Tiwari <alok.a.tiwari@oracle.com>
vhost-scsi: Fix check for inline_sg_cnt exceeding preallocated limit
Mike Christie <michael.christie@oracle.com>
vhost-scsi: Fix log flooding with target does not exist errors
Dragos Tatulea <dtatulea@nvidia.com>
vdpa/mlx5: Fix needs_teardown flag calculation
Namhyung Kim <namhyung@kernel.org>
perf record: Cache build-ID of hit DSOs only
Takashi Iwai <tiwai@suse.de>
ALSA: usb: scarlett2: Fix missing NULL check
WangYuli <wangyuli@uniontech.com>
selftests: ALSA: fix memory leak in utimer test
Lukasz Laguna <lukasz.laguna@intel.com>
drm/xe/vf: Disable CSC support on VF
Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>
mtd: rawnand: atmel: set pmecc data setup time
Thomas Fourier <fourier.thomas@gmail.com>
mtd: rawnand: rockchip: Add missing check after DMA map
Thomas Fourier <fourier.thomas@gmail.com>
mtd: rawnand: atmel: Fix dma_mapping_error() address
Zheng Yu <zheng.yu@northwestern.edu>
jfs: fix metapage reference count leak in dbAllocCtl
Paulo Alcantara <pc@manguebit.org>
smb: client: allow parsing zero-length AV pairs
Chenyuan Yang <chenyuan0y@gmail.com>
fbdev: imxfb: Check fb_add_videomode to prevent null-ptr-deref
Giovanni Cabiddu <giovanni.cabiddu@intel.com>
crypto: qat - fix seq_file position update in adf_ring_next()
Giovanni Cabiddu <giovanni.cabiddu@intel.com>
crypto: qat - fix DMA direction for compression on GEN2 devices
Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
clk: clocking-wizard: Fix the round rate handling for versal
Chen Pei <cp0613@linux.alibaba.com>
perf tools: Remove libtraceevent in .gitignore
Ben Hutchings <benh@debian.org>
sh: Do not use hyphen in exported variable name
Shengjiu Wang <shengjiu.wang@nxp.com>
ASoC: fsl_xcvr: get channel status data with firmware exists
Shengjiu Wang <shengjiu.wang@nxp.com>
ASoC: fsl_xcvr: get channel status data when PHY is not exists
Charles Keepax <ckeepax@opensource.cirrus.com>
ASoC: SDCA: Fix some holes in the regmap readable/writeable helpers
Shree Ramamoorthy <s-ramamoorthy@ti.com>
mfd: tps65219: Update TPS65214 MFD cell's GPIO compatible string
Thomas Fourier <fourier.thomas@gmail.com>
dmaengine: nbpfaxi: Add missing check after DMA map
Thomas Fourier <fourier.thomas@gmail.com>
dmaengine: mv_xor: Fix missing check after DMA map and missing unmap
Ian Rogers <irogers@google.com>
tools subcmd: Tighten the filename size in check_if_command_finished
Dan Carpenter <dan.carpenter@linaro.org>
fs/orangefs: Allow 2 more characters in do_c_string()
Tanmay Shah <tanmay.shah@amd.com>
remoteproc: xlnx: Disable unsupported features
Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
clk: imx95-blk-ctl: Fix synchronous abort
Manivannan Sadhasivam <mani@kernel.org>
PCI: endpoint: pci-epf-vntb: Fix the incorrect usage of __iomem attribute
Bard Liao <yung-chuan.liao@linux.intel.com>
soundwire: stream: restore params when prepare ports fail
Eric Biggers <ebiggers@kernel.org>
crypto: krb5 - Fix memory leak in krb5_test_one_prf()
Bairavi Alagappan <bairavix.alagappan@intel.com>
crypto: qat - disable ZUC-256 capability for QAT GEN5
Thomas Fourier <fourier.thomas@gmail.com>
crypto: img-hash - Fix dma_unmap_sg() nents value
Thomas Fourier <fourier.thomas@gmail.com>
crypto: keembay - Fix dma_unmap_sg() nents value
Ovidiu Panait <ovidiu.panait.oss@gmail.com>
hwrng: mtk - handle devm_pm_runtime_enable errors
Varshini Rajendran <varshini.rajendran@microchip.com>
clk: at91: sam9x7: update pll clk ranges
Jan Kara <jack@suse.cz>
ext4: Make sure BH_New bit is cleared in ->write_end handler
Baokun Li <libaokun1@huawei.com>
ext4: fix inode use after free in ext4_end_io_rsv_work()
Dan Carpenter <dan.carpenter@linaro.org>
watchdog: ziirave_wdt: check record length in ziirave_firm_verify()
Robin Murphy <robin.murphy@arm.com>
PCI: Fix driver_managed_dma check
Thomas Fourier <fourier.thomas@gmail.com>
scsi: isci: Fix dma_unmap_sg() nents value
Thomas Fourier <fourier.thomas@gmail.com>
scsi: mvsas: Fix dma_unmap_sg() nents value
Thomas Fourier <fourier.thomas@gmail.com>
scsi: elx: efct: Fix dma_unmap_sg() nents value
Thomas Fourier <fourier.thomas@gmail.com>
scsi: ibmvscsi_tgt: Fix dma_unmap_sg() nents value
Paul Kocialkowski <paulk@sys-base.io>
clk: sunxi-ng: v3s: Fix de clock definition
Yao Zi <ziyao@disroot.org>
clk: thead: th1520-ap: Correctly refer the parent of osc_12m
Shiraz Saleem <shirazsaleem@microsoft.com>
RDMA/mana_ib: Fix DSCP value in modify QP
Ian Rogers <irogers@google.com>
perf hwmon_pmu: Avoid shortening hwmon PMU name
Leo Yan <leo.yan@arm.com>
perf tests bp_account: Fix leaked file descriptor
Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
pinmux: fix race causing mux_owner NULL with active mux_usecount
wangzijie <wangzijie1@honor.com>
proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al
Arnd Bergmann <arnd@arndb.de>
kernel: trace: preemptirq_delay_test: use offstack cpu mask
Steven Rostedt <rostedt@goodmis.org>
tracing: Use queue_rcu_work() to free filters
Junxian Huang <huangjunxian6@hisilicon.com>
RDMA/hns: Fix -Wframe-larger-than issue
Junxian Huang <huangjunxian6@hisilicon.com>
RDMA/hns: Drop GFP_NOWARN
Junxian Huang <huangjunxian6@hisilicon.com>
RDMA/hns: Fix accessing uninitialized resources
Junxian Huang <huangjunxian6@hisilicon.com>
RDMA/hns: Get message length of ack_req from FW
Mengbiao Xiong <xisme1998@gmail.com>
crypto: ccp - Fix crash when rebind ccp device for ccp.ko
Thomas Fourier <fourier.thomas@gmail.com>
crypto: inside-secure - Fix `dma_unmap_sg()` nents value
Alexey Kardashevskiy <aik@amd.com>
crypto: ccp - Fix locking on alloc failure handling
wenglianfa <wenglianfa@huawei.com>
RDMA/hns: Fix HW configurations not cleared in error flow
wenglianfa <wenglianfa@huawei.com>
RDMA/hns: Fix double destruction of rsv_qp
Namhyung Kim <namhyung@kernel.org>
perf sched: Fix memory leaks in 'perf sched latency'
Namhyung Kim <namhyung@kernel.org>
perf sched: Use RC_CHK_EQUAL() to compare pointers
Namhyung Kim <namhyung@kernel.org>
perf sched: Fix memory leaks for evsel->priv in timehist
Namhyung Kim <namhyung@kernel.org>
perf sched: Fix thread leaks in 'perf sched timehist'
Namhyung Kim <namhyung@kernel.org>
perf sched: Fix memory leaks in 'perf sched map'
Namhyung Kim <namhyung@kernel.org>
perf sched: Free thread->priv using priv_destructor
Namhyung Kim <namhyung@kernel.org>
perf sched: Make sure it frees the usage string
Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
mtd: spi-nor: spansion: Fixup params->set_4byte_addr_mode for SEMPER
Ian Rogers <irogers@google.com>
perf dso: Add missed dso__put to dso__load_kcore
Namhyung Kim <namhyung@kernel.org>
perf tools: Fix use-after-free in help_unknown_cmd()
Thomas Fourier <fourier.thomas@gmail.com>
Fix dma_unmap_sg() nents value
Nuno Sá <nuno.sa@analog.com>
clk: clk-axi-clkgen: fix fpfd_max frequency for zynq
Amir Goldstein <amir73il@gmail.com>
fanotify: sanitize handle_type values when reporting fid
Luca Weiss <luca.weiss@fairphone.com>
phy: qualcomm: phy-qcom-eusb2-repeater: Don't zero-out registers
Rodrigo Gobbi <rodrigo.gobbi.7@gmail.com>
soundwire: debugfs: move debug statement outside of error handling
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
dmaengine: mmp: Fix again Wvoid-pointer-to-enum-cast warning
Charles Keepax <ckeepax@opensource.cirrus.com>
soundwire: Correct some property names
Jiwei Sun <sunjw10@lenovo.com>
PCI: Adjust the position of reading the Link Control 2 register
Ze Huang <huangze@whut.edu.cn>
pinctrl: canaan: k230: Fix order of DT parse and pinctrl register
Ze Huang <huangze@whut.edu.cn>
pinctrl: canaan: k230: add NULL check in DT parse
Yuan Chen <chenyuan@kylinos.cn>
pinctrl: berlin: fix memory leak in berlin_pinctrl_build_state()
Yuan Chen <chenyuan@kylinos.cn>
pinctrl: sunxi: Fix memory leak on krealloc failure
Jerome Brunet <jbrunet@baylibre.com>
PCI: endpoint: pci-epf-vntb: Return -ENOENT if pci_epc_get_next_free_bar() fails
Arnd Bergmann <arnd@arndb.de>
crypto: arm/aes-neonbs - work around gcc-15 warning
Thomas Antoine <t.antoine@uclouvain.be>
power: supply: max1720x correct capacity computation
Casey Connolly <casey.connolly@linaro.org>
power: supply: qcom_pmi8998_charger: fix wakeirq
Charles Han <hanchunchao@inspur.com>
power: supply: max14577: Handle NULL pdata when CONFIG_OF is not set
Charles Han <hanchunchao@inspur.com>
power: supply: cpcap-charger: Fix null check for power_supply_get_by_name
Rohit Visavalia <rohit.visavalia@amd.com>
clk: xilinx: vcu: unregister pll_post only if registered correctly
Namhyung Kim <namhyung@kernel.org>
perf parse-events: Set default GH modifier properly
James Cowgill <james.cowgill@blaize.com>
media: v4l2-ctrls: Fix H264 SEPARATE_COLOUR_PLANE check
Henry Martin <bsdhenrymartin@gmail.com>
clk: davinci: Add NULL check in davinci_lpsc_clk_register()
Ivan Stepchenko <sid@itb.spb.ru>
mtd: fix possible integer overflow in erase_xfer()
Svyatoslav Pankratov <svyatoslav.pankratov@intel.com>
crypto: qat - fix state restore for banks with exceptions
Ahsan Atta <ahsan.atta@intel.com>
crypto: qat - allow enabling VFs in the absence of IOMMU
Herbert Xu <herbert@gondor.apana.org.au>
padata: Fix pd UAF once and for all
Herbert Xu <herbert@gondor.apana.org.au>
crypto: marvell/cesa - Fix engine load inaccuracy
Suman Kumar Chakraborty <suman.kumar.chakraborty@intel.com>
crypto: qat - use unmanaged allocation for dc_data
Ovidiu Panait <ovidiu.panait.oss@gmail.com>
crypto: sun8i-ce - fix nents passed to dma_unmap_sg()
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
clk: renesas: rzv2h: Fix missing CLK_SET_RATE_PARENT flag for ddiv clocks
Hans Zhang <18255117159@163.com>
PCI: rockchip-host: Fix "Unexpected Completion" log message
Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
remoteproc: qcom: pas: Conclude the rename from adsp
Kees Cook <kees@kernel.org>
fortify: Fix incorrect reporting of read buffer size
Kees Cook <kees@kernel.org>
staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int()
Gabriele Monaco <gmonaco@redhat.com>
rv: Adjust monitor dependencies
Samuel Holland <samuel.holland@sifive.com>
RISC-V: KVM: Fix inclusion of Smnpm in the guest ISA bitmap
Puranjay Mohan <puranjay@kernel.org>
bpf, arm64: Fix fp initialization for exception boundary
Thomas Weißschuh <thomas.weissschuh@linutronix.de>
bpf/preload: Don't select USERMODE_DRIVER
Eric Dumazet <edumazet@google.com>
ipv6: annotate data-races around rt->fib6_nsiblings
Eric Dumazet <edumazet@google.com>
ipv6: fix possible infinite loop in fib6_info_uses_dev()
Eric Dumazet <edumazet@google.com>
ipv6: prevent infinite loop in rt6_nlmsg_size()
Stanislav Fomichev <sdf@fomichev.me>
vrf: Drop existing dst reference in vrf_ip6_input_dst
Xiumei Mu <xmu@redhat.com>
selftests: rtnetlink.sh: remove esp4_offload after test
Jason Xing <kernelxing@tencent.com>
igb: xsk: solve negative overflow of nb_pkts in zerocopy mode
Jason Xing <kernelxing@tencent.com>
stmmac: xsk: fix negative overflow of budget in zerocopy mode
Kuniyuki Iwashima <kuniyu@google.com>
neighbour: Fix null-ptr-deref in neigh_flush_dev().
Tristram Ha <tristram.ha@microchip.com>
net: dsa: microchip: Fix wrong rx drop MIB counter for KSZ8863
Stanislav Fomichev <sdf@fomichev.me>
macsec: set IFF_UNICAST_FLT priv flag
Jianbo Liu <jianbol@nvidia.com>
net/mlx5e: Remove skb secpath if xfrm state is not found
Alexei Lazar <alazar@nvidia.com>
net/mlx5e: Clear Read-Only port buffer size in PBMC before update
Florian Westphal <fw@strlen.de>
netfilter: xt_nfacct: don't assume acct name is null-terminated
Jimmy Assarsson <extja@kvaser.com>
can: kvaser_usb: Assign netdev.dev_port based on device channel index
Jimmy Assarsson <extja@kvaser.com>
can: kvaser_pciefd: Store device channel index
Stephane Grosjean <stephane.grosjean@hms-networks.com>
can: peak_usb: fix USB FD devices potential malfunction
Daniel Zahka <daniel.zahka@gmail.com>
selftests: drv-net: tso: fix non-tunneled tso6 test case name
Daniel Zahka <daniel.zahka@gmail.com>
selftests: drv-net: tso: fix vxlan tunnel flags to get correct gso_type
Daniel Zahka <daniel.zahka@gmail.com>
selftests: drv-net: tso: enable test cases based on hw_features
Gal Pressman <gal@nvidia.com>
selftests: drv-net: Fix remote command checking in require_cmd()
Gabriele Monaco <gmonaco@redhat.com>
tools/rv: Do not skip idle in trace
Kuniyuki Iwashima <kuniyu@google.com>
bpf: Disable migration in nf_hook_run_bpf().
Chris Down <chris@chrisdown.name>
Bluetooth: hci_event: Mask data status from LE ext adv reports
Ivan Pravdin <ipravdin.official@gmail.com>
Bluetooth: hci_devcd_dump: fix out-of-bounds via dev_coredumpv
Arseniy Krasnov <avkrasnov@salutedevices.com>
Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()'
Benjamin Berg <benjamin.berg@intel.com>
wifi: iwlwifi: mld: decode EOF bit for AMPDUs
Jeremy Linton <jeremy.linton@arm.com>
arm64/gcs: task_gcs_el0_enable() should use passed task
Johannes Berg <johannes.berg@intel.com>
wifi: mac80211: fix WARN_ON for monitor mode on some devices
Matthew Wilcox (Oracle) <willy@infradead.org>
memcg_slabinfo: Fix use of PG_slab
Marco Elver <elver@google.com>
kcsan: test: Initialize dummy variable
Steven Rostedt <rostedt@goodmis.org>
ring-buffer: Remove ring_buffer_read_prepare_sync()
Kees Cook <kees@kernel.org>
wifi: nl80211: Set num_sub_specs before looping through sub_specs
Kees Cook <kees@kernel.org>
wifi: mac80211: Write cnt before copying in ieee80211_copy_rnr_beacon()
Steven Rostedt <rostedt@goodmis.org>
PM: cpufreq: powernv/tracing: Move powernv_throttle trace event
Gokul Sivakumar <gokulkumar.sivakumar@infineon.com>
wifi: brcmfmac: fix P2P discovery failure in P2P peer due to missing P2P IE
Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com>
wifi: ath12k: fix endianness handling while accessing wmi service bit
Remi Pommarel <repk@triplefau.lt>
Reapply "wifi: mac80211: Update skb's control block key in ieee80211_tx_dequeue()"
Remi Pommarel <repk@triplefau.lt>
wifi: mac80211: Check 802.11 encaps offloading in ieee80211_tx_h_select_key()
Alexander Wetzel <Alexander@wetzel-home.de>
wifi: mac80211: Don't call fq_flow_idx() for management frames
Alexander Wetzel <Alexander@wetzel-home.de>
wifi: mac80211: Do not schedule stopped TXQs
Alexander Wetzel <Alexander@wetzel-home.de>
wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac()
Murad Masimov <m.masimov@mt-integration.ru>
wifi: plfxlc: Fix error handling in usb driver probe
Moon Hee Lee <moonhee.lee.ca@gmail.com>
wifi: mac80211: reject TDLS operations when station is not associated
Tze-nan Wu <Tze-nan.Wu@mediatek.com>
rcu: Fix delayed execution of hurry callbacks
Jason Gunthorpe <jgg@ziepe.ca>
iommu/amd: Fix geometry.aperture_end for V2 tables
Puranjay Mohan <puranjay@kernel.org>
selftests/bpf: fix implementation of smp_mb()
Alex Deucher <alexander.deucher@amd.com>
drm/amdgpu/gfx10: fix kiq locking in KCQ reset
Alex Deucher <alexander.deucher@amd.com>
drm/amdgpu/gfx9.4.3: fix kiq locking in KCQ reset
Alex Deucher <alexander.deucher@amd.com>
drm/amdgpu/gfx9: fix kiq locking in KCQ reset
Baochen Qiang <quic_bqiang@quicinc.com>
wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask()
Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
wifi: ath12k: Use HTT_TCL_METADATA_VER_V1 in FTM mode
Thomas Fourier <fourier.thomas@gmail.com>
mwl8k: Add missing check after DMA map
Bitterblue Smith <rtl8821cerfe2@gmail.com>
wifi: rtw88: Fix macid assigned to TDLS station
Martin Kaistra <martin.kaistra@linutronix.de>
wifi: rtl8xxxu: Fix RX skb size for aggregation disabled
Eric Dumazet <edumazet@google.com>
tcp: call tcp_measure_rcv_mss() for ooo packets
Juergen Gross <jgross@suse.com>
xen/gntdev: remove struct gntdev_copy_batch from stack
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
iommu/arm-smmu: disable PRR on SM8250
Jason Gunthorpe <jgg@ziepe.ca>
iommu/vt-d: Do not wipe out the page table NID when devices detach
Juri Lelli <juri.lelli@redhat.com>
sched/deadline: Reset extra_bw to max_bw when clearing root domains
Juri Lelli <juri.lelli@redhat.com>
sched/deadline: Initialize dl_servers after SMP
Al Viro <viro@zeniv.linux.org.uk>
xen: fix UAF in dmabuf_exp_from_pages()
Edward Srouji <edwards@nvidia.com>
RDMA/mlx5: Fix UMR modifying of mkey page size
Eric Dumazet <edumazet@google.com>
net_sched: act_ctinfo: use atomic64_t for three counters
William Liu <will@willsroot.io>
net/sched: Restrict conditions for adding duplicating netems to qdisc tree
Easwar Hariharan <eahariha@linux.microsoft.com>
iommu/amd: Enable PASID and ATS capabilities in the correct order
Tiwei Bie <tiwei.btw@antgroup.com>
um: rtc: Avoid shadowing err in uml_rtc_start()
Johan Korsnes <johan.korsnes@gmail.com>
arch: powerpc: defconfig: Drop obsolete CONFIG_NET_CLS_TCINDEX
Fedor Pchelkin <pchelkin@ispras.ru>
netfilter: nf_tables: adjust lockdep assertions handling
Phil Sutter <phil@nwl.cc>
netfilter: nf_tables: Drop dead code from fill_*_info routines
Shixiong Ou <oushixiong@kylinos.cn>
fbcon: Fix outdated registered_fb reference in comment
Peter Zijlstra <peterz@infradead.org>
sched/deadline: Less agressive dl_server handling
Peter Zijlstra <peterz@infradead.org>
sched/psi: Optimize psi_group_change() cpu_clock() usage
Andy Yan <andy.yan@rock-chips.com>
drm/rockchip: vop2: Fix the update of LAYER/PORT select registers when there are multi display output on rk3588/rk3568
Heiko Stuebner <heiko@sntech.de>
drm/rockchip: vop2: fail cleanly if missing a primary plane for a video-port
Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
wifi: ath12k: Block radio bring-up in FTM mode
Fedor Pchelkin <pchelkin@ispras.ru>
drm/amd/pm/powerplay/hwmgr/smu_helper: fix order of mask and value
Lorenzo Bianconi <lorenzo@kernel.org>
wifi: mt76: mt7996: Fix valid_links bitmask in mt7996_mac_sta_{add,remove}
Lorenzo Bianconi <lorenzo@kernel.org>
wifi: mt76: mt7996: Fix possible OOB access in mt7996_tx()
Lorenzo Bianconi <lorenzo@kernel.org>
wifi: mt76: mt7996: Fix secondary link lookup in mt7996_mcu_sta_mld_setup_tlv()
Artem Sadovnikov <a.sadovnikov@ispras.ru>
refscale: Check that nreaders and loops multiplication doesn't overflow
Finn Thain <fthain@linux-m68k.org>
m68k: Don't unregister boot console needlessly
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
drm/msm/dpu: Fill in min_prefill_lines for SC8180X
Kumar Kartikeya Dwivedi <memxor@gmail.com>
bpf: Ensure RCU lock is held around bpf_prog_ksym_find
Mark Brown <broonie@kernel.org>
kselftest/arm64: Fix check for setting new VLs in sve-ptrace
Dan Carpenter <dan.carpenter@linaro.org>
wifi: iwlwifi: Fix error code in iwl_op_mode_dvm_start()
Eric Dumazet <edumazet@google.com>
net: dst: add four helpers to annotate data-races around dst->dev
Eric Dumazet <edumazet@google.com>
net: dst: annotate data-races around dst->output
Eric Dumazet <edumazet@google.com>
net: dst: annotate data-races around dst->input
Stav Aviram <saviram@nvidia.com>
net/mlx5: Check device memory pointer before usage
xin.guo <guoxin0309@gmail.com>
tcp: fix tcp_ofo_queue() to avoid including too much DUP SACK range
Thiraviyam Mariyappan <thiraviyam.mariyappan@oss.qualcomm.com>
wifi: ath12k: Clear auth flag only for actual association in security mode
Sergey Senozhatsky <senozhatsky@chromium.org>
wifi: ath11k: clear initialized flag for deinit-ed srng lists
Stanislav Fomichev <sdf@fomichev.me>
team: replace team lock with rtnl lock
Jiasheng Jiang <jiasheng@iscas.ac.cn>
iwlwifi: Add missing check for alloc_ordered_workqueue
Xiu Jianfeng <xiujianfeng@huawei.com>
wifi: iwlwifi: Fix memory leak in iwl_mvm_init()
Daniil Dulov <d.dulov@aladdin.ru>
wifi: rtl818x: Kill URBs before clearing tx status queue
Zong-Zhe Yang <kevin_yang@realtek.com>
wifi: rtw89: avoid NULL dereference when RX problematic packet on unsupported 6 GHz band
Arnd Bergmann <arnd@arndb.de>
caif: reduce stack size, again
Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com>
wifi: ath12k: Pass ab pointer directly to ath12k_dp_tx_get_encap_type()
P Praneesh <praneesh.p@oss.qualcomm.com>
wifi: ath12k: Fix double budget decrement while reaping monitor ring
Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
wifi: ath12k: Avoid accessing uninitialized arvif->ar during beacon miss
Haren Myneni <haren@linux.ibm.com>
powerpc/pseries/dlpar: Search DRC index from ibm,drc-indexes for IO add
Yuan Chen <chenyuan@kylinos.cn>
bpftool: Fix memory leak in dump_xx_nlmsg on realloc failure
Lijo Lazar <lijo.lazar@amd.com>
drm/amdgpu: Remove nbiov7.9 replay count reporting
Jonathan Corbet <corbet@lwn.net>
slub: Fix a documentation build error for krealloc()
Ian Forbes <ian.forbes@broadcom.com>
drm/vmwgfx: Fix Host-Backed userspace on Guest-Backed kernel
Petr Machata <petrm@nvidia.com>
net: ipv6: ip6mr: Fix in/out netdev to pass to the FORWARD chain
Mykyta Yatsenko <yatsenko@meta.com>
selftests/bpf: Fix unintentional switch case fall through
Eduard Zingerman <eddyz87@gmail.com>
bpf: handle jset (if a & b ...) as a jump in CFG computation
Fushuai Wang <wangfushuai@baidu.com>
selftests/bpf: fix signedness bug in redir_partial()
Jiayuan Chen <jiayuan.chen@linux.dev>
bpf, ktls: Fix data corruption when using bpf_msg_pop_data() in ktls
Breno Leitao <leitao@debian.org>
netconsole: Only register console drivers when targets are configured
Jiayuan Chen <jiayuan.chen@linux.dev>
bpf, sockmap: Fix psock incorrectly pointing to sk
Kuan-Chung Chen <damon.chen@realtek.com>
wifi: rtw89: fix EHT 20MHz TX rate for non-AP STA
Boris Brezillon <boris.brezillon@collabora.com>
drm/panthor: Add missing explicit padding in drm_panthor_gpu_info
Adrián Larumbe <adrian.larumbe@collabora.com>
drm/panfrost: Fix panfrost device variable name in devfreq
Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
drm/connector: hdmi: Evaluate limited range after computing format
Andy Yan <andy.yan@rock-chips.com>
drm/rockchip: cleanup fb when drm_gem_fb_afbc_init failed
Steven Rostedt <rostedt@goodmis.org>
selftests/tracing: Fix false failure of subsystem event test
Alok Tiwari <alok.a.tiwari@oracle.com>
staging: nvec: Fix incorrect null termination of battery manufacturer
Michael J. Ruhl <michael.j.ruhl@intel.com>
drm/xe: Correct BMG VSEC header sizing
Michael J. Ruhl <michael.j.ruhl@intel.com>
drm/xe: Correct the rev value for the DVSEC entries
Slark Xiao <slark_xiao@163.com>
bus: mhi: host: pci_generic: Fix the modem name of Foxconn T99W640
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
interconnect: qcom: qcs615: Drop IP0 interconnects
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
interconnect: qcom: sc8180x: specify num_nodes
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
interconnect: qcom: sc8280xp: specify num_links for qnm_a1noc_cfg
Johan Hovold <johan@kernel.org>
soc: qcom: pmic_glink: fix OF node leak
Brahmajit Das <listout@listout.xyz>
samples: mei: Fix building on musl libc
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: greybus: gbphy: fix up const issue with the match callback
Charles Keepax <ckeepax@opensource.cirrus.com>
ASoC: SDCA: Allow read-only controls to be deferrable
Lifeng Zheng <zhenglifeng1@huawei.com>
cpufreq: Init policy->rwsem before it may be possibly used
Lifeng Zheng <zhenglifeng1@huawei.com>
cpufreq: Initialize cpufreq-based frequency-invariance later
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
cpufreq: intel_pstate: Always use HWP_DESIRED_PERF in passive mode
Chanwoo Choi <cw00.choi@samsung.com>
PM / devfreq: Fix a index typo in trans_stat
Lifeng Zheng <zhenglifeng1@huawei.com>
PM / devfreq: Check governor before using governor->name
Jonas Karlman <jonas@kwiboo.se>
arm64: dts: rockchip: Fix pinctrl node names for RK3528
Adam Ford <aford173@gmail.com>
arm64: dts: imx8mn-beacon: Fix HS400 USDHC clock speed
Adam Ford <aford173@gmail.com>
arm64: dts: imx8mm-beacon: Fix HS400 USDHC clock speed
Annette Kobou <annette.kobou@kontron.de>
ARM: dts: imx6ul-kontron-bl-common: Fix RTS polarity for RS485 interface
Moon Hee Lee <moonhee.lee.ca@gmail.com>
selftests: breakpoints: use suspend_stats to reliably check suspend success
Patrick Delaunay <patrick.delaunay@foss.st.com>
arm64: dts: st: fix timer used for ticks
Sebastian Reichel <sebastian.reichel@collabora.com>
arm64: dts: rockchip: fix PHY handling for ROCK 4D
Sumit Gupta <sumitg@nvidia.com>
soc/tegra: cbb: Clear ERR_FORCE register with ERR_STATUS
Christophe JAILLET <christophe.jaillet@wanadoo.fr>
staging: gpib: Fix error handling paths in cb_gpib_probe()
Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
staging: gpib: Fix error code in board_type_ioctl()
Albin Törnqvist <albin.tornqvist@codiax.se>
arm: dts: ti: omap: Fixup pinheader typo
Lucas De Marchi <lucas.demarchi@intel.com>
usb: early: xhci-dbc: Fix early_ioremap leak
Sivan Zohar-Kotzer <sivany32@gmail.com>
powercap: dtpm_cpu: Fix NULL pointer dereference in get_pd_power_uw()
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert "vmci: Prevent the dispatching of uninitialized payloads"
Thomas Weißschuh <thomas.weissschuh@linutronix.de>
selftests: vDSO: chacha: Correctly skip test if necessary
Tim Harvey <tharvey@gateworks.com>
arm64: dts: imx8mp-venice-gw74xx: update name of M2SKT_WDIS2# gpio
Denis OSTERLAND-HEIM <denis.osterland@diehl.com>
pps: fix poll support
Lizhi Xu <lizhi.xu@windriver.com>
vmci: Prevent the dispatching of uninitialized payloads
Shankari Anand <shankari.ak0208@gmail.com>
rust: miscdevice: clarify invariant for `MiscDeviceRegistration`
Abdun Nihaal <abdun.nihaal@gmail.com>
staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc()
Jonas Karlman <jonas@kwiboo.se>
arm64: dts: rockchip: Enable eMMC HS200 mode on Radxa E20C
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
power: sequencing: qcom-wcn: fix bluetooth-wifi copypasta for WCN6855
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers: misc: sram: fix up some const issues with recent attribute changes
Clément Le Goffic <clement.legoffic@foss.st.com>
spi: stm32: Check for cfg availability in stm32_spi_probe
Hans de Goede <hansg@kernel.org>
mei: vsc: Unset the event callback on remove and probe errors
Hans de Goede <hansg@kernel.org>
mei: vsc: Event notifier fixes
Hans de Goede <hansg@kernel.org>
mei: vsc: Destroy mutex after freeing the IRQ
Hans de Goede <hansg@kernel.org>
mei: vsc: Don't re-init VSC from mei_vsc_hw_reset() on stop
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
usb: typec: ucsi: yoga-c630: fix error and remove paths
Sibi Sankar <quic_sibis@quicinc.com>
firmware: arm_scmi: Fix up turbo frequencies selection
Arnd Bergmann <arnd@arndb.de>
cpufreq: armada-8k: make both cpu masks static
Ryan Wanner <Ryan.Wanner@microchip.com>
ARM: dts: microchip: sam9x7: Add clock name property
Ryan Wanner <Ryan.Wanner@microchip.com>
ARM: dts: microchip: sama7d65: Add clock name property
Michael Walle <mwalle@kernel.org>
arm64: dts: ti: k3-am62p-j722s: fix pinctrl-single size
Wadim Egorov <w.egorov@phytec.de>
arm64: dts: ti: k3-am642-phyboard-electra: Fix PRU-ICSSG Ethernet ports
Charalampos Mitrodimas <charmitro@posteo.net>
usb: misc: apple-mfi-fastcharge: Make power supply names unique
Seungjin Bae <eeodqql09@gmail.com>
usb: host: xhci-plat: fix incorrect type for of_match variable in xhci_plat_probe()
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
ARM: dts: vfxxx: Correctly use two tuples for timer address
Gautham R. Shenoy <gautham.shenoy@amd.com>
pm: cpupower: Fix printing of CORE, CPU fields in cpupower-monitor
André Apitzsch <git@apitzsch.eu>
arm64: dts: qcom: msm8976: Make blsp_dma controlled-remotely
Lijuan Gao <lijuan.gao@oss.qualcomm.com>
arm64: dts: qcom: sa8775p: Correct the interrupt for remoteproc
Will Deacon <willdeacon@google.com>
arm64: dts: exynos: gs101: Add 'local-timer-stop' to cpuidle nodes
Jie Gan <jie.gan@oss.qualcomm.com>
arm64: dts: qcom: qcs615: disable the CTI device of the camera block
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
arm64: dts: qcom: sc7180: Expand IMEM region
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
arm64: dts: qcom: sdm845: Expand IMEM region
Jie Gan <jie.gan@oss.qualcomm.com>
arm64: dts: qcom: qcs615: fix a crash issue caused by infinite loop for Coresight
Alexander Wilhelm <alexander.wilhelm@westermo.com>
soc: qcom: QMI encoding/decoding for big endian
Dmitry Vyukov <dvyukov@google.com>
selftests: Fix errno checking in syscall_user_dispatch test
Alexander Stein <alexander.stein@ew.tq-group.com>
arm64: dts: freescale: imx93-tqma9352: Limit BUCK2 to 600mV
Chen-Yu Tsai <wenst@chromium.org>
ASoC: mediatek: use reserved memory or enable buffer pre-allocation
Arnd Bergmann <arnd@arndb.de>
ASoC: ops: dynamically allocate struct snd_ctl_elem_value
Venkata Prasad Potturu <venkataprasad.potturu@amd.com>
ASoC: amd: acp: Fix pointer assignments for snd_soc_acpi_mach structures
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
ASoC: soc-dai: tidyup return value of snd_soc_xlate_tdm_slot_mask()
Sun YangKai <sunk67188@gmail.com>
btrfs: remove partial support for lowest level from btrfs_search_forward()
Randy Dunlap <rdunlap@infradead.org>
io_uring: fix breakage in EXPERT menu
John Garry <john.g.garry@oracle.com>
block: sanitize chunk_sectors for atomic write limits
Andreas Gruenbacher <agruenba@redhat.com>
gfs2: No more self recovery
Kees Cook <kees@kernel.org>
kunit/fortify: Add back "volatile" for sizeof() constants
Zheng Qixing <zhengqixing@huawei.com>
md: allow removing faulty rdev during resync
Andreas Gruenbacher <agruenba@redhat.com>
gfs2: Minor do_xmote cancelation fix
Thomas Fourier <fourier.thomas@gmail.com>
block: mtip32xx: Fix usage of dma_map_sg()
Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Revert "fs/ntfs3: Replace inode_trylock with inode_lock"
Yangtao Li <frank.li@vivo.com>
hfsplus: remove mutex_lock check in hfsplus_free_extents
Yangtao Li <frank.li@vivo.com>
hfs: make splice write available again
Yangtao Li <frank.li@vivo.com>
hfsplus: make splice write available again
Caleb Sander Mateos <csander@purestorage.com>
ublk: use vmalloc for ublk_device's __queues
Tingmao Wang <m@maowtm.org>
landlock: Fix warning from KUnit tests
Edward Adam Davis <eadavis@qq.com>
fs/ntfs3: cancle set bad inode after removing name fails
Song Liu <song@kernel.org>
selftests/landlock: Fix build of audit_test
Mickaël Salaün <mic@digikod.net>
selftests/landlock: Fix readlink check
RubenKelevra <rubenkelevra@gmail.com>
fs_context: fix parameter name in infofc() macro
Al Viro <viro@zeniv.linux.org.uk>
parse_longname(): strrchr() expects NUL-terminated string
Richard Guy Briggs <rgb@redhat.com>
audit,module: restore audit logging in load failure case
Alexandru Andries <alex.andries.aa@gmail.com>
ASoC: amd: yc: add DMI quirk for ASUS M6501RM
Arnd Bergmann <arnd@arndb.de>
ASoC: Intel: fix SND_SOC_SOF dependencies
Jackie Dong <xy-jackie@139.com>
ALSA: hda/realtek: Support mute LED for Yoga with ALC287
Richard Fitzgerald <rf@opensource.cirrus.com>
ALSA: hda/cs35l56: Workaround bad dev-index on Lenovo Yoga Book 9i GenX
Adam Queler <queler@gmail.com>
ASoC: amd: yc: Add DMI entries to support HP 15-fb1xxx
Arnd Bergmann <arnd@arndb.de>
ethernet: intel: fix building with large NR_CPUS
Lane Odenbach <laodenbach@gmail.com>
ASoC: amd: yc: Add DMI quirk for HP Laptop 17 cp-2033dx
Thomas Zimmermann <tzimmermann@suse.de>
drm/radeon: Do not hold console lock while suspending clients
-------------
Diffstat:
Documentation/filesystems/f2fs.rst | 6 +-
Documentation/netlink/specs/ethtool.yaml | 6 +-
Makefile | 4 +-
arch/arm/boot/dts/microchip/sam9x7.dtsi | 2 +
arch/arm/boot/dts/microchip/sama7d65.dtsi | 2 +
.../boot/dts/nxp/imx/imx6ul-kontron-bl-common.dtsi | 1 -
arch/arm/boot/dts/nxp/vf/vfxxx.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/am335x-boneblack.dts | 2 +-
arch/arm/crypto/aes-neonbs-glue.c | 2 +-
arch/arm64/boot/dts/exynos/google/gs101.dtsi | 3 +
.../boot/dts/freescale/imx8mm-beacon-som.dtsi | 2 +
.../boot/dts/freescale/imx8mn-beacon-som.dtsi | 2 +
.../boot/dts/freescale/imx8mp-venice-gw74xx.dts | 8 +-
arch/arm64/boot/dts/freescale/imx93-tqma9352.dtsi | 6 +-
arch/arm64/boot/dts/qcom/msm8976.dtsi | 2 +
arch/arm64/boot/dts/qcom/qcs615.dtsi | 4 +
arch/arm64/boot/dts/qcom/sa8775p.dtsi | 10 +-
arch/arm64/boot/dts/qcom/sc7180.dtsi | 10 +-
arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 +-
arch/arm64/boot/dts/rockchip/rk3528-pinctrl.dtsi | 20 +-
arch/arm64/boot/dts/rockchip/rk3528-radxa-e20c.dts | 1 +
arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts | 6 +-
arch/arm64/boot/dts/st/stm32mp251.dtsi | 2 +-
.../boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 2 +-
.../boot/dts/ti/k3-am642-phyboard-electra-rdk.dts | 2 +
arch/arm64/include/asm/gcs.h | 2 +-
arch/arm64/kernel/process.c | 6 +-
arch/arm64/net/bpf_jit_comp.c | 1 +
arch/m68k/Kconfig.debug | 2 +-
arch/m68k/kernel/early_printk.c | 42 +-
arch/m68k/kernel/head.S | 8 +-
arch/mips/mm/tlb-r4k.c | 56 +-
arch/powerpc/configs/ppc6xx_defconfig | 1 -
arch/powerpc/kernel/eeh.c | 1 +
arch/powerpc/kernel/eeh_driver.c | 48 +-
arch/powerpc/kernel/eeh_pe.c | 10 +-
arch/powerpc/kernel/pci-hotplug.c | 3 +
arch/powerpc/platforms/pseries/dlpar.c | 52 +-
arch/riscv/kvm/vcpu_onereg.c | 83 ++-
arch/s390/boot/startup.c | 2 +-
arch/s390/include/asm/ap.h | 2 +-
arch/s390/kernel/setup.c | 6 +
arch/s390/mm/pgalloc.c | 5 -
arch/s390/mm/vmem.c | 5 +-
arch/sh/Makefile | 10 +-
arch/sh/boot/compressed/Makefile | 4 +-
arch/sh/boot/romimage/Makefile | 4 +-
arch/um/drivers/rtc_user.c | 2 +-
arch/x86/boot/cpuflags.c | 13 +
arch/x86/coco/sev/shared.c | 46 ++
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/hw_irq.h | 12 +-
arch/x86/include/asm/msr-index.h | 1 +
arch/x86/kernel/cpu/scattered.c | 1 +
arch/x86/kernel/irq.c | 63 ++-
arch/x86/kvm/vmx/vmx.c | 4 +
arch/x86/mm/extable.c | 5 +-
block/blk-settings.c | 19 +-
crypto/krb5/selftest.c | 1 +
drivers/block/mtip32xx/mtip32xx.c | 27 +-
drivers/block/ublk_drv.c | 4 +-
drivers/bluetooth/btusb.c | 4 +
drivers/bus/mhi/host/pci_generic.c | 8 +-
drivers/char/hw_random/mtk-rng.c | 4 +-
drivers/clk/at91/sam9x7.c | 20 +-
drivers/clk/clk-axi-clkgen.c | 2 +-
drivers/clk/davinci/psc.c | 5 +
drivers/clk/imx/clk-imx95-blk-ctl.c | 13 +-
drivers/clk/renesas/rzv2h-cpg.c | 1 +
drivers/clk/sunxi-ng/ccu-sun8i-v3s.c | 3 +-
drivers/clk/thead/clk-th1520-ap.c | 9 +-
drivers/clk/xilinx/clk-xlnx-clock-wizard.c | 2 +-
drivers/clk/xilinx/xlnx_vcu.c | 4 +-
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/armada-8k-cpufreq.c | 3 +-
drivers/cpufreq/cpufreq.c | 21 +-
drivers/cpufreq/intel_pstate.c | 4 +-
drivers/cpufreq/powernv-cpufreq.c | 4 +-
drivers/cpufreq/powernv-trace.h | 44 ++
.../crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c | 4 +-
drivers/crypto/ccp/ccp-debugfs.c | 3 +
drivers/crypto/ccp/sev-dev.c | 8 +-
drivers/crypto/img-hash.c | 2 +-
drivers/crypto/inside-secure/safexcel_hash.c | 8 +-
.../crypto/intel/keembay/keembay-ocs-hcu-core.c | 8 +-
.../crypto/intel/qat/qat_420xx/adf_420xx_hw_data.c | 9 +-
.../crypto/intel/qat/qat_common/adf_gen4_hw_data.c | 29 +-
drivers/crypto/intel/qat/qat_common/adf_sriov.c | 1 -
.../intel/qat/qat_common/adf_transport_debug.c | 4 +-
drivers/crypto/intel/qat/qat_common/qat_bl.c | 6 +-
.../crypto/intel/qat/qat_common/qat_compression.c | 8 +-
drivers/crypto/marvell/cesa/cipher.c | 4 +-
drivers/crypto/marvell/cesa/hash.c | 5 +-
drivers/devfreq/devfreq.c | 12 +-
drivers/dma/mmp_tdma.c | 2 +-
drivers/dma/mv_xor.c | 21 +-
drivers/dma/nbpfaxi.c | 13 +
drivers/firmware/arm_scmi/perf.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 6 +-
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c | 3 +-
drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c | 20 -
.../gpu/drm/amd/pm/powerplay/hwmgr/smu_helper.c | 2 +-
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 4 +-
.../drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 1 +
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 4 +-
drivers/gpu/drm/radeon/radeon_device.c | 8 +-
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 9 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 29 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 33 ++
drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 89 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c | 2 +-
drivers/gpu/drm/xe/xe_device.c | 1 +
drivers/gpu/drm/xe/xe_gt_sriov_pf.c | 32 +-
drivers/gpu/drm/xe/xe_vsec.c | 20 +-
drivers/hid/hid-apple.c | 20 +-
drivers/hid/hid-core.c | 6 +-
drivers/i2c/muxes/i2c-mux-mule.c | 3 +-
drivers/i3c/master/svc-i3c-master.c | 20 +-
drivers/infiniband/hw/erdma/erdma_verbs.c | 3 +-
drivers/infiniband/hw/hns/hns_roce_device.h | 1 +
drivers/infiniband/hw/hns/hns_roce_hem.c | 18 +-
drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 87 ++-
drivers/infiniband/hw/hns/hns_roce_hw_v2.h | 8 +-
drivers/infiniband/hw/hns/hns_roce_main.c | 22 +-
drivers/infiniband/hw/mana/qp.c | 2 +-
drivers/infiniband/hw/mlx5/dm.c | 2 +-
drivers/infiniband/hw/mlx5/umr.c | 6 +-
drivers/interconnect/qcom/qcs615.c | 42 --
drivers/interconnect/qcom/sc8180x.c | 6 +
drivers/interconnect/qcom/sc8280xp.c | 1 +
drivers/iommu/amd/iommu.c | 19 +-
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 3 +-
drivers/iommu/intel/iommu.c | 1 -
drivers/irqchip/Kconfig | 1 +
drivers/md/md.c | 33 +-
.../media/platform/ti/j721e-csi2rx/j721e-csi2rx.c | 1 +
drivers/media/v4l2-core/v4l2-ctrls-core.c | 8 +-
drivers/mfd/tps65219.c | 2 +-
drivers/misc/mei/platform-vsc.c | 8 +
drivers/misc/mei/vsc-tp.c | 20 +-
drivers/misc/sram.c | 10 +-
drivers/mtd/ftl.c | 2 +-
drivers/mtd/nand/raw/atmel/nand-controller.c | 2 +-
drivers/mtd/nand/raw/atmel/pmecc.c | 6 +
drivers/mtd/nand/raw/rockchip-nand-controller.c | 15 +
drivers/mtd/spi-nor/spansion.c | 31 ++
drivers/net/can/kvaser_pciefd.c | 1 +
drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c | 1 +
drivers/net/can/usb/peak_usb/pcan_usb_fd.c | 17 +-
drivers/net/dsa/microchip/ksz8.c | 3 +
drivers/net/dsa/microchip/ksz8_reg.h | 4 +-
drivers/net/ethernet/airoha/airoha_npu.c | 2 +
drivers/net/ethernet/emulex/benet/be_cmds.c | 2 +-
drivers/net/ethernet/intel/fm10k/fm10k.h | 3 +-
drivers/net/ethernet/intel/i40e/i40e.h | 2 +-
drivers/net/ethernet/intel/igb/igb_xsk.c | 3 +-
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 3 +-
.../ethernet/mellanox/mlx5/core/en/port_buffer.c | 3 +
.../mellanox/mlx5/core/en_accel/ipsec_rxtx.c | 4 +
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 1 +
drivers/net/ethernet/mellanox/mlx5/core/lib/dm.c | 4 +-
drivers/net/ethernet/mellanox/mlx5/core/main.c | 3 -
drivers/net/ethernet/meta/fbnic/fbnic_netdev.c | 4 +-
drivers/net/ethernet/meta/fbnic/fbnic_txrx.c | 4 +-
drivers/net/ethernet/meta/fbnic/fbnic_txrx.h | 6 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
drivers/net/ethernet/ti/icssg/icssg_common.c | 15 +-
drivers/net/ipa/ipa_sysfs.c | 6 +-
drivers/net/macsec.c | 2 +-
drivers/net/mdio/mdio-bcm-unimac.c | 5 +-
drivers/net/netconsole.c | 30 +-
drivers/net/phy/mscc/mscc_ptp.c | 1 +
drivers/net/phy/mscc/mscc_ptp.h | 1 +
drivers/net/ppp/pptp.c | 18 +-
drivers/net/team/team_core.c | 96 ++--
drivers/net/team/team_mode_activebackup.c | 3 +-
drivers/net/team/team_mode_loadbalance.c | 13 +-
drivers/net/usb/usbnet.c | 11 +-
drivers/net/vrf.c | 2 +
drivers/net/wireless/ath/ath11k/hal.c | 4 +
drivers/net/wireless/ath/ath11k/mac.c | 12 +-
drivers/net/wireless/ath/ath12k/dp.h | 1 +
drivers/net/wireless/ath/ath12k/dp_mon.c | 1 -
drivers/net/wireless/ath/ath12k/dp_tx.c | 10 +-
drivers/net/wireless/ath/ath12k/mac.c | 29 +-
drivers/net/wireless/ath/ath12k/p2p.c | 3 +-
drivers/net/wireless/ath/ath12k/wmi.c | 14 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 8 +-
drivers/net/wireless/intel/iwlwifi/dvm/main.c | 12 +-
drivers/net/wireless/intel/iwlwifi/mld/rx.c | 9 +
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 4 +-
drivers/net/wireless/marvell/mwl8k.c | 4 +
drivers/net/wireless/mediatek/mt76/mt7996/main.c | 21 +-
drivers/net/wireless/mediatek/mt76/mt7996/mcu.c | 3 +-
drivers/net/wireless/purelifi/plfxlc/mac.c | 11 +-
drivers/net/wireless/purelifi/plfxlc/mac.h | 2 +-
drivers/net/wireless/purelifi/plfxlc/usb.c | 29 +-
drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c | 3 +-
drivers/net/wireless/realtek/rtl8xxxu/core.c | 2 +-
drivers/net/wireless/realtek/rtw88/main.c | 4 +-
drivers/net/wireless/realtek/rtw89/core.c | 5 +
drivers/net/wireless/realtek/rtw89/phy.c | 12 +-
drivers/nvme/target/core.c | 18 +-
drivers/pci/controller/pcie-rockchip-host.c | 2 +-
drivers/pci/endpoint/functions/pci-epf-vntb.c | 4 +-
drivers/pci/hotplug/pnv_php.c | 235 +++++++-
drivers/pci/pci-driver.c | 6 +-
drivers/pci/quirks.c | 6 +-
drivers/perf/arm-ni.c | 2 +
drivers/phy/qualcomm/phy-qcom-eusb2-repeater.c | 83 +--
drivers/pinctrl/berlin/berlin.c | 8 +-
drivers/pinctrl/pinctrl-k230.c | 13 +-
drivers/pinctrl/pinmux.c | 20 +-
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 11 +-
drivers/platform/x86/intel/pmt/class.c | 3 +-
drivers/platform/x86/intel/pmt/class.h | 1 +
drivers/power/sequencing/pwrseq-qcom-wcn.c | 2 +-
drivers/power/supply/cpcap-charger.c | 5 +-
drivers/power/supply/max14577_charger.c | 4 +-
drivers/power/supply/max1720x_battery.c | 11 +-
drivers/power/supply/qcom_pmi8998_charger.c | 4 +-
drivers/powercap/dtpm_cpu.c | 2 +
drivers/pps/pps.c | 11 +-
drivers/remoteproc/Kconfig | 11 +-
drivers/remoteproc/qcom_q6v5_pas.c | 615 ++++++++++-----------
drivers/remoteproc/xlnx_r5_remoteproc.c | 2 +
drivers/rtc/rtc-ds1307.c | 2 +-
drivers/rtc/rtc-hym8563.c | 2 +-
drivers/rtc/rtc-nct3018y.c | 2 +-
drivers/rtc/rtc-pcf85063.c | 2 +-
drivers/rtc/rtc-pcf8563.c | 2 +-
drivers/rtc/rtc-rv3028.c | 2 +-
drivers/s390/crypto/ap_bus.h | 2 +-
drivers/scsi/elx/efct/efct_lio.c | 2 +-
drivers/scsi/ibmvscsi_tgt/libsrp.c | 6 +-
drivers/scsi/isci/request.c | 2 +-
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 3 +-
drivers/scsi/mvsas/mv_sas.c | 4 +-
drivers/scsi/scsi_transport_iscsi.c | 2 +
drivers/scsi/sd.c | 4 +-
drivers/soc/qcom/pmic_glink.c | 9 +-
drivers/soc/qcom/qmi_encdec.c | 46 +-
drivers/soc/tegra/cbb/tegra234-cbb.c | 2 +
drivers/soundwire/debugfs.c | 6 +-
drivers/soundwire/mipi_disco.c | 4 +-
drivers/soundwire/stream.c | 2 +-
drivers/spi/spi-cs42l43.c | 2 +-
drivers/spi/spi-stm32.c | 8 +-
drivers/staging/fbtft/fbtft-core.c | 1 +
drivers/staging/gpib/cb7210/cb7210.c | 15 +-
drivers/staging/gpib/common/gpib_os.c | 2 +-
drivers/staging/greybus/gbphy.c | 6 +-
.../media/atomisp/pci/atomisp_gmin_platform.c | 9 +-
drivers/staging/nvec/nvec_power.c | 2 +-
drivers/ufs/core/ufshcd.c | 10 +-
drivers/usb/early/xhci-dbc.c | 4 +
drivers/usb/gadget/composite.c | 5 +
drivers/usb/gadget/function/f_hid.c | 7 +-
drivers/usb/gadget/function/uvc_configfs.c | 10 +
drivers/usb/host/xhci-plat.c | 2 +-
drivers/usb/misc/apple-mfi-fastcharge.c | 24 +-
drivers/usb/serial/option.c | 2 +
drivers/usb/typec/ucsi/ucsi_yoga_c630.c | 19 +-
drivers/vdpa/mlx5/core/mr.c | 3 +
drivers/vdpa/mlx5/net/mlx5_vnet.c | 12 +-
drivers/vdpa/vdpa_user/vduse_dev.c | 1 +
drivers/vfio/device_cdev.c | 38 +-
drivers/vfio/group.c | 7 +-
drivers/vfio/iommufd.c | 4 +
drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c | 1 +
drivers/vfio/pci/mlx5/main.c | 1 +
drivers/vfio/pci/nvgrace-gpu/main.c | 2 +
drivers/vfio/pci/pds/vfio_dev.c | 2 +
drivers/vfio/pci/qat/main.c | 1 +
drivers/vfio/pci/vfio_pci.c | 1 +
drivers/vfio/pci/vfio_pci_core.c | 24 +-
drivers/vfio/pci/virtio/main.c | 3 +
drivers/vfio/vfio_main.c | 3 +-
drivers/vhost/Kconfig | 18 +
drivers/vhost/scsi.c | 6 +-
drivers/vhost/vhost.c | 244 +++++++-
drivers/vhost/vhost.h | 22 +
drivers/video/fbdev/core/fbcon.c | 4 +-
drivers/video/fbdev/imxfb.c | 9 +-
drivers/watchdog/ziirave_wdt.c | 3 +
drivers/xen/gntdev-common.h | 4 +
drivers/xen/gntdev-dmabuf.c | 28 +-
drivers/xen/gntdev.c | 71 ++-
fs/btrfs/ctree.c | 18 +-
fs/ceph/crypto.c | 31 +-
fs/exfat/file.c | 5 +-
fs/ext4/inline.c | 2 +
fs/ext4/inode.c | 3 +-
fs/ext4/page-io.c | 16 +-
fs/f2fs/data.c | 7 +-
fs/f2fs/debug.c | 17 +-
fs/f2fs/extent_cache.c | 2 +-
fs/f2fs/f2fs.h | 2 +-
fs/f2fs/gc.c | 1 +
fs/f2fs/inode.c | 21 +-
fs/f2fs/segment.h | 5 +-
fs/f2fs/super.c | 1 +
fs/f2fs/sysfs.c | 21 +
fs/gfs2/glock.c | 3 +-
fs/gfs2/util.c | 37 +-
fs/hfs/inode.c | 1 +
fs/hfsplus/extents.c | 3 -
fs/hfsplus/inode.c | 1 +
fs/jfs/jfs_dmap.c | 4 +-
fs/nfs/dir.c | 4 +-
fs/nfs/export.c | 11 +-
fs/nfs/flexfilelayout/flexfilelayout.c | 26 +-
fs/nfs/flexfilelayout/flexfilelayoutdev.c | 6 +-
fs/nfs/internal.h | 9 +-
fs/nfs/nfs4proc.c | 10 +-
fs/nfs_common/nfslocalio.c | 28 +-
fs/nfsd/localio.c | 5 +-
fs/nfsd/vfs.c | 10 +-
fs/notify/fanotify/fanotify.c | 8 +-
fs/ntfs3/file.c | 5 +-
fs/ntfs3/frecord.c | 7 +-
fs/ntfs3/namei.c | 10 +-
fs/ntfs3/ntfs_fs.h | 3 +-
fs/orangefs/orangefs-debugfs.c | 6 +-
fs/proc/generic.c | 2 +
fs/proc/inode.c | 2 +-
fs/proc/internal.h | 5 +
fs/smb/client/cifs_debug.c | 6 +-
fs/smb/client/cifsencrypt.c | 4 +-
fs/smb/client/cifsfs.c | 2 +-
fs/smb/client/connect.c | 9 +-
fs/smb/client/fs_context.c | 19 +-
fs/smb/client/fs_context.h | 18 +-
fs/smb/client/link.c | 11 +-
fs/smb/client/reparse.c | 2 +-
fs/smb/client/smbdirect.c | 130 ++---
fs/smb/client/smbdirect.h | 4 -
fs/smb/server/connection.h | 1 +
fs/smb/server/smb2pdu.c | 22 +-
fs/smb/server/smb_common.c | 2 +-
fs/smb/server/transport_rdma.c | 97 ++--
fs/smb/server/transport_tcp.c | 17 +
fs/smb/server/vfs.c | 3 +-
include/linux/audit.h | 9 +-
include/linux/fortify-string.h | 2 +-
include/linux/fs_context.h | 2 +-
include/linux/if_team.h | 3 -
include/linux/ioprio.h | 3 +-
include/linux/mlx5/device.h | 1 +
include/linux/mm.h | 30 +
include/linux/moduleparam.h | 5 +-
include/linux/padata.h | 4 -
include/linux/pps_kernel.h | 1 +
include/linux/proc_fs.h | 1 +
include/linux/psi_types.h | 6 +-
include/linux/ring_buffer.h | 4 +-
include/linux/sched.h | 1 +
include/linux/skbuff.h | 23 +
include/linux/usb/usbnet.h | 1 +
include/linux/vfio.h | 4 +
include/linux/vfio_pci_core.h | 2 +
include/net/bluetooth/hci.h | 1 +
include/net/bluetooth/hci_core.h | 6 +
include/net/dst.h | 24 +-
include/net/lwtunnel.h | 8 +-
include/net/tc_act/tc_ctinfo.h | 6 +-
include/net/udp.h | 24 +-
include/sound/tas2781-tlv.h | 2 +-
include/trace/events/power.h | 22 -
include/uapi/drm/panthor_drm.h | 3 +
include/uapi/linux/vfio.h | 12 +-
include/uapi/linux/vhost.h | 29 +
init/Kconfig | 2 +-
kernel/audit.h | 2 +-
kernel/auditsc.c | 2 +-
kernel/bpf/core.c | 5 +-
kernel/bpf/helpers.c | 11 +-
kernel/bpf/preload/Kconfig | 1 -
kernel/bpf/verifier.c | 1 +
kernel/events/core.c | 38 +-
kernel/kcsan/kcsan_test.c | 2 +-
kernel/module/main.c | 6 +-
kernel/padata.c | 132 ++---
kernel/rcu/refscale.c | 10 +-
kernel/rcu/tree_nocb.h | 2 +-
kernel/sched/core.c | 2 +
kernel/sched/deadline.c | 78 ++-
kernel/sched/fair.c | 9 -
kernel/sched/psi.c | 123 +++--
kernel/sched/sched.h | 1 +
kernel/trace/power-traces.c | 1 -
kernel/trace/preemptirq_delay_test.c | 13 +-
kernel/trace/ring_buffer.c | 63 +--
kernel/trace/rv/monitors/scpd/Kconfig | 2 +-
kernel/trace/rv/monitors/sncid/Kconfig | 2 +-
kernel/trace/rv/monitors/snep/Kconfig | 2 +-
kernel/trace/rv/monitors/wip/Kconfig | 2 +-
kernel/trace/trace.c | 14 +-
kernel/trace/trace_events_filter.c | 28 +-
kernel/trace/trace_kdb.c | 8 +-
kernel/ucount.c | 2 +-
lib/tests/fortify_kunit.c | 4 +-
mm/hmm.c | 2 +-
mm/memory.c | 3 +-
mm/shmem.c | 4 +-
mm/slub.c | 10 +-
mm/swapfile.c | 65 +--
net/bluetooth/coredump.c | 6 +-
net/bluetooth/hci_event.c | 8 +-
net/caif/cfctrl.c | 294 +++++-----
net/core/dst.c | 8 +-
net/core/filter.c | 3 +
net/core/neighbour.c | 88 ++-
net/core/netpoll.c | 7 +
net/core/skmsg.c | 7 +
net/core/sock.c | 8 +-
net/ipv4/route.c | 4 +-
net/ipv4/tcp_input.c | 4 +-
net/ipv6/ip6_fib.c | 24 +-
net/ipv6/ip6_offload.c | 4 +-
net/ipv6/ip6mr.c | 3 +-
net/ipv6/route.c | 60 +-
net/mac80211/cfg.c | 2 +-
net/mac80211/main.c | 13 +-
net/mac80211/tdls.c | 2 +-
net/mac80211/tx.c | 14 +-
net/netfilter/nf_bpf_link.c | 5 +-
net/netfilter/nf_tables_api.c | 29 +-
net/netfilter/xt_nfacct.c | 4 +-
net/packet/af_packet.c | 12 +-
net/sched/act_ctinfo.c | 19 +-
net/sched/sch_mqprio.c | 2 +-
net/sched/sch_netem.c | 40 ++
net/sched/sch_taprio.c | 21 +-
net/sunrpc/svcsock.c | 43 +-
net/sunrpc/xprtsock.c | 40 +-
net/tls/tls_sw.c | 13 +
net/vmw_vsock/af_vsock.c | 3 +-
net/wireless/nl80211.c | 1 +
net/wireless/reg.c | 2 +
rust/kernel/miscdevice.rs | 8 +-
samples/mei/mei-amt-version.c | 2 +-
scripts/gdb/linux/constants.py.in | 12 +-
scripts/kconfig/qconf.cc | 2 +-
security/apparmor/include/match.h | 8 +-
security/apparmor/match.c | 23 +-
security/apparmor/policy_unpack_test.c | 6 +-
security/landlock/id.c | 69 ++-
sound/pci/hda/cs35l56_hda.c | 114 +++-
sound/pci/hda/patch_ca0132.c | 5 +-
sound/pci/hda/patch_realtek.c | 6 +
sound/soc/amd/acp/acp-pci.c | 8 +-
sound/soc/amd/acp/amd-acpi-mach.c | 4 +-
sound/soc/amd/acp/amd.h | 8 +-
sound/soc/amd/yc/acp6x-mach.c | 21 +
sound/soc/fsl/fsl_xcvr.c | 25 +-
sound/soc/intel/boards/Kconfig | 2 +-
.../soc/mediatek/common/mtk-afe-platform-driver.c | 4 +-
sound/soc/mediatek/common/mtk-base-afe.h | 1 +
sound/soc/mediatek/mt8173/mt8173-afe-pcm.c | 7 +
sound/soc/mediatek/mt8183/mt8183-afe-pcm.c | 7 +
sound/soc/mediatek/mt8186/mt8186-afe-pcm.c | 7 +
sound/soc/mediatek/mt8192/mt8192-afe-pcm.c | 7 +
sound/soc/sdca/sdca_functions.c | 3 +-
sound/soc/sdca/sdca_regmap.c | 16 +-
sound/soc/soc-dai.c | 16 +-
sound/soc/soc-ops.c | 28 +-
sound/soc/sof/intel/Kconfig | 3 +-
sound/usb/mixer_scarlett2.c | 14 +-
sound/x86/intel_hdmi_audio.c | 2 +-
tools/bpf/bpftool/net.c | 15 +-
tools/cgroup/memcg_slabinfo.py | 4 +-
tools/lib/subcmd/help.c | 12 +-
tools/lib/subcmd/run-command.c | 15 +-
tools/perf/.gitignore | 2 -
tools/perf/builtin-sched.c | 147 +++--
tools/perf/tests/bp_account.c | 1 +
tools/perf/util/build-id.c | 2 +-
tools/perf/util/evsel.c | 11 +
tools/perf/util/evsel.h | 2 +
tools/perf/util/hwmon_pmu.c | 2 +-
tools/perf/util/parse-events.c | 11 +-
tools/perf/util/symbol.c | 1 +
.../cpupower/utils/idle_monitor/cpupower-monitor.c | 4 -
tools/power/x86/turbostat/turbostat.c | 5 +-
tools/testing/selftests/alsa/utimer-test.c | 1 +
tools/testing/selftests/arm64/fp/sve-ptrace.c | 2 +-
tools/testing/selftests/bpf/bpf_atomic.h | 2 +-
.../selftests/bpf/prog_tests/sockmap_listen.c | 2 +
tools/testing/selftests/bpf/veristat.c | 1 +
.../breakpoints/step_after_suspend_test.c | 41 +-
tools/testing/selftests/drivers/net/hw/tso.py | 99 ++--
tools/testing/selftests/drivers/net/lib/py/env.py | 2 +-
.../ftrace/test.d/event/subsystem-enable.tc | 28 +-
tools/testing/selftests/landlock/audit.h | 7 +-
tools/testing/selftests/landlock/audit_test.c | 1 +
tools/testing/selftests/net/rtnetlink.sh | 6 +
tools/testing/selftests/perf_events/.gitignore | 1 +
tools/testing/selftests/perf_events/Makefile | 2 +-
tools/testing/selftests/perf_events/mmap.c | 236 ++++++++
.../selftests/syscall_user_dispatch/sud_test.c | 50 +-
tools/testing/selftests/vDSO/vdso_test_chacha.c | 3 +-
tools/verification/rv/src/in_kernel.c | 4 +-
504 files changed, 4855 insertions(+), 2641 deletions(-)
^ permalink raw reply [flat|nested] 1767+ messages in thread* [PATCH 6.15 001/480] drm/radeon: Do not hold console lock while suspending clients 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 002/480] ASoC: amd: yc: Add DMI quirk for HP Laptop 17 cp-2033dx Greg Kroah-Hartman ` (490 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Thomas Zimmermann, Jeff Johnson, Ville Syrjälä, Alex Deucher, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Zimmermann <tzimmermann@suse.de> [ Upstream commit 5dd0b96118e09a3725e3f83543e133b1fd02c18c ] The radeon driver holds the console lock while suspending in-kernel DRM clients. This creates a circular dependency with the client-list mutex, which is supposed to be acquired first. Reported when combining radeon with another DRM driver. Therefore, do not take the console lock in radeon, but let the fbdev DRM client acquire the lock when needed. This is what all other DRM drivers so. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reported-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Closes: https://lore.kernel.org/dri-devel/0a087cfd-bd4c-48f1-aa2f-4a3b12593935@oss.qualcomm.com/ Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 612ec7c69d04cb58beb1332c2806da9f2f47a3ae) Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/gpu/drm/radeon/radeon_device.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index bbd39348a7ab..6f50cfdfe5a2 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -1635,11 +1635,9 @@ int radeon_suspend_kms(struct drm_device *dev, bool suspend, pci_set_power_state(pdev, PCI_D3hot); } - if (notify_clients) { - console_lock(); - drm_client_dev_suspend(dev, true); - console_unlock(); - } + if (notify_clients) + drm_client_dev_suspend(dev, false); + return 0; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 002/480] ASoC: amd: yc: Add DMI quirk for HP Laptop 17 cp-2033dx 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 001/480] drm/radeon: Do not hold console lock while suspending clients Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 003/480] ethernet: intel: fix building with large NR_CPUS Greg Kroah-Hartman ` (489 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Lane Odenbach, Mark Brown, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Lane Odenbach <laodenbach@gmail.com> [ Upstream commit 7bab1bd9fdf15b9fa7e6a4b0151deab93df3c80d ] This fixes the internal microphone in the stated device Signed-off-by: Lane Odenbach <laodenbach@gmail.com> Link: https://patch.msgid.link/20250715182038.10048-1-laodenbach@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- sound/soc/amd/yc/acp6x-mach.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c index 1689b6b22598..42d123cb8b4c 100644 --- a/sound/soc/amd/yc/acp6x-mach.c +++ b/sound/soc/amd/yc/acp6x-mach.c @@ -577,6 +577,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = { DMI_MATCH(DMI_BOARD_NAME, "8A7F"), } }, + { + .driver_data = &acp6x_card, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "HP"), + DMI_MATCH(DMI_BOARD_NAME, "8A81"), + } + }, { .driver_data = &acp6x_card, .matches = { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 003/480] ethernet: intel: fix building with large NR_CPUS 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 001/480] drm/radeon: Do not hold console lock while suspending clients Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 002/480] ASoC: amd: yc: Add DMI quirk for HP Laptop 17 cp-2033dx Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 004/480] ASoC: amd: yc: Add DMI entries to support HP 15-fb1xxx Greg Kroah-Hartman ` (488 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Arnd Bergmann, David S. Miller, Aleksandr Loktionov, Alexander Lobakin, Tony Nguyen, Sasha Levin, Sunitha Mekala 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Arnd Bergmann <arnd@arndb.de> [ Upstream commit 24171a5a4a952c26568ff0d2a0bc8c4708a95e1d ] With large values of CONFIG_NR_CPUS, three Intel ethernet drivers fail to compile like: In function ‘i40e_free_q_vector’, inlined from ‘i40e_vsi_alloc_q_vectors’ at drivers/net/ethernet/intel/i40e/i40e_main.c:12112:3: 571 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) include/linux/rcupdate.h:1084:17: note: in expansion of macro ‘BUILD_BUG_ON’ 1084 | BUILD_BUG_ON(offsetof(typeof(*(ptr)), rhf) >= 4096); \ drivers/net/ethernet/intel/i40e/i40e_main.c:5113:9: note: in expansion of macro ‘kfree_rcu’ 5113 | kfree_rcu(q_vector, rcu); | ^~~~~~~~~ The problem is that the 'rcu' member in 'q_vector' is too far from the start of the structure. Move this member before the CPU mask instead, in all three drivers. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: David S. Miller <davem@davemloft.net> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Tested-by: Sunitha Mekala <sunithax.d.mekala@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/ethernet/intel/fm10k/fm10k.h | 3 ++- drivers/net/ethernet/intel/i40e/i40e.h | 2 +- drivers/net/ethernet/intel/ixgbe/ixgbe.h | 3 ++- 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/intel/fm10k/fm10k.h b/drivers/net/ethernet/intel/fm10k/fm10k.h index 6119a4108838..65a2816142d9 100644 --- a/drivers/net/ethernet/intel/fm10k/fm10k.h +++ b/drivers/net/ethernet/intel/fm10k/fm10k.h @@ -189,13 +189,14 @@ struct fm10k_q_vector { struct fm10k_ring_container rx, tx; struct napi_struct napi; + struct rcu_head rcu; /* to avoid race with update stats on free */ + cpumask_t affinity_mask; char name[IFNAMSIZ + 9]; #ifdef CONFIG_DEBUG_FS struct dentry *dbg_q_vector; #endif /* CONFIG_DEBUG_FS */ - struct rcu_head rcu; /* to avoid race with update stats on free */ /* for dynamic allocation of rings associated with this q_vector */ struct fm10k_ring ring[] ____cacheline_internodealigned_in_smp; diff --git a/drivers/net/ethernet/intel/i40e/i40e.h b/drivers/net/ethernet/intel/i40e/i40e.h index c67963bfe14e..7c600d6e66ba 100644 --- a/drivers/net/ethernet/intel/i40e/i40e.h +++ b/drivers/net/ethernet/intel/i40e/i40e.h @@ -945,6 +945,7 @@ struct i40e_q_vector { u16 reg_idx; /* register index of the interrupt */ struct napi_struct napi; + struct rcu_head rcu; /* to avoid race with update stats on free */ struct i40e_ring_container rx; struct i40e_ring_container tx; @@ -955,7 +956,6 @@ struct i40e_q_vector { cpumask_t affinity_mask; struct irq_affinity_notify affinity_notify; - struct rcu_head rcu; /* to avoid race with update stats on free */ char name[I40E_INT_NAME_STR_LEN]; bool arm_wb_state; bool in_busy_poll; diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h index e6a380d4929b..fb43fba5daa1 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h @@ -505,9 +505,10 @@ struct ixgbe_q_vector { struct ixgbe_ring_container rx, tx; struct napi_struct napi; + struct rcu_head rcu; /* to avoid race with update stats on free */ + cpumask_t affinity_mask; int numa_node; - struct rcu_head rcu; /* to avoid race with update stats on free */ char name[IFNAMSIZ + 9]; /* for dynamic allocation of rings associated with this q_vector */ -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 004/480] ASoC: amd: yc: Add DMI entries to support HP 15-fb1xxx 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (2 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 003/480] ethernet: intel: fix building with large NR_CPUS Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 005/480] ALSA: hda/cs35l56: Workaround bad dev-index on Lenovo Yoga Book 9i GenX Greg Kroah-Hartman ` (487 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Adam Queler, Mark Brown, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Adam Queler <queler@gmail.com> [ Upstream commit 949ddec3728f3a793a13c1c9003028b9b159aefc ] This model requires an additional detection quirk to enable the internal microphone. Signed-off-by: Adam Queler <queler+k@gmail.com> Link: https://patch.msgid.link/20250715031434.222062-1-queler+k@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- sound/soc/amd/yc/acp6x-mach.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c index 42d123cb8b4c..4bde41663f42 100644 --- a/sound/soc/amd/yc/acp6x-mach.c +++ b/sound/soc/amd/yc/acp6x-mach.c @@ -528,6 +528,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "OMEN by HP Gaming Laptop 16z-n000"), } }, + { + .driver_data = &acp6x_card, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "HP"), + DMI_MATCH(DMI_PRODUCT_NAME, "Victus by HP Gaming Laptop 15-fb1xxx"), + } + }, { .driver_data = &acp6x_card, .matches = { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 005/480] ALSA: hda/cs35l56: Workaround bad dev-index on Lenovo Yoga Book 9i GenX 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (3 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 004/480] ASoC: amd: yc: Add DMI entries to support HP 15-fb1xxx Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 006/480] ALSA: hda/realtek: Support mute LED for Yoga with ALC287 Greg Kroah-Hartman ` (486 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Richard Fitzgerald, Brian Howard, Takashi Iwai, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Richard Fitzgerald <rf@opensource.cirrus.com> [ Upstream commit 40b1c2f9b299295ed0482e1fee6f46521e6e79e5 ] The Lenovo Yoga Book 9i GenX has the wrong values in the cirrus,dev-index _DSD property. Add a fixup for this model to ignore the property and hardcode the index from the I2C bus address. The error in the cirrus,dev-index property would prevent the second amp instance from probing. The component binding would never see all the required instances and so there would not be a binding between patch_realtek.c and the cs35l56 driver. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Reported-by: Brian Howard <blhoward2@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220228 Link: https://patch.msgid.link/20250714110154.204740-1-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org> --- sound/pci/hda/cs35l56_hda.c | 110 +++++++++++++++++++++++++++--------- 1 file changed, 82 insertions(+), 28 deletions(-) diff --git a/sound/pci/hda/cs35l56_hda.c b/sound/pci/hda/cs35l56_hda.c index 235d22049aa9..c9c8ec8d2474 100644 --- a/sound/pci/hda/cs35l56_hda.c +++ b/sound/pci/hda/cs35l56_hda.c @@ -874,6 +874,52 @@ static int cs35l56_hda_system_resume(struct device *dev) return 0; } +static int cs35l56_hda_fixup_yoga9(struct cs35l56_hda *cs35l56, int *bus_addr) +{ + /* The cirrus,dev-index property has the wrong values */ + switch (*bus_addr) { + case 0x30: + cs35l56->index = 1; + return 0; + case 0x31: + cs35l56->index = 0; + return 0; + default: + /* There is a pseudo-address for broadcast to both amps - ignore it */ + dev_dbg(cs35l56->base.dev, "Ignoring I2C address %#x\n", *bus_addr); + return 0; + } +} + +static const struct { + const char *sub; + int (*fixup_fn)(struct cs35l56_hda *cs35l56, int *bus_addr); +} cs35l56_hda_fixups[] = { + { + .sub = "17AA390B", /* Lenovo Yoga Book 9i GenX */ + .fixup_fn = cs35l56_hda_fixup_yoga9, + }, +}; + +static int cs35l56_hda_apply_platform_fixups(struct cs35l56_hda *cs35l56, const char *sub, + int *bus_addr) +{ + int i; + + if (IS_ERR(sub)) + return 0; + + for (i = 0; i < ARRAY_SIZE(cs35l56_hda_fixups); i++) { + if (strcasecmp(cs35l56_hda_fixups[i].sub, sub) == 0) { + dev_dbg(cs35l56->base.dev, "Applying fixup for %s\n", + cs35l56_hda_fixups[i].sub); + return (cs35l56_hda_fixups[i].fixup_fn)(cs35l56, bus_addr); + } + } + + return 0; +} + static int cs35l56_hda_read_acpi(struct cs35l56_hda *cs35l56, int hid, int id) { u32 values[HDA_MAX_COMPONENTS]; @@ -898,39 +944,47 @@ static int cs35l56_hda_read_acpi(struct cs35l56_hda *cs35l56, int hid, int id) ACPI_COMPANION_SET(cs35l56->base.dev, adev); } - property = "cirrus,dev-index"; - ret = device_property_count_u32(cs35l56->base.dev, property); - if (ret <= 0) - goto err; - - if (ret > ARRAY_SIZE(values)) { - ret = -EINVAL; - goto err; - } - nval = ret; + /* Initialize things that could be overwritten by a fixup */ + cs35l56->index = -1; - ret = device_property_read_u32_array(cs35l56->base.dev, property, values, nval); + sub = acpi_get_subsystem_id(ACPI_HANDLE(cs35l56->base.dev)); + ret = cs35l56_hda_apply_platform_fixups(cs35l56, sub, &id); if (ret) - goto err; + return ret; - cs35l56->index = -1; - for (i = 0; i < nval; i++) { - if (values[i] == id) { - cs35l56->index = i; - break; - } - } - /* - * It's not an error for the ID to be missing: for I2C there can be - * an alias address that is not a real device. So reject silently. - */ if (cs35l56->index == -1) { - dev_dbg(cs35l56->base.dev, "No index found in %s\n", property); - ret = -ENODEV; - goto err; - } + property = "cirrus,dev-index"; + ret = device_property_count_u32(cs35l56->base.dev, property); + if (ret <= 0) + goto err; - sub = acpi_get_subsystem_id(ACPI_HANDLE(cs35l56->base.dev)); + if (ret > ARRAY_SIZE(values)) { + ret = -EINVAL; + goto err; + } + nval = ret; + + ret = device_property_read_u32_array(cs35l56->base.dev, property, values, nval); + if (ret) + goto err; + + for (i = 0; i < nval; i++) { + if (values[i] == id) { + cs35l56->index = i; + break; + } + } + + /* + * It's not an error for the ID to be missing: for I2C there can be + * an alias address that is not a real device. So reject silently. + */ + if (cs35l56->index == -1) { + dev_dbg(cs35l56->base.dev, "No index found in %s\n", property); + ret = -ENODEV; + goto err; + } + } if (IS_ERR(sub)) { dev_info(cs35l56->base.dev, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 006/480] ALSA: hda/realtek: Support mute LED for Yoga with ALC287 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (4 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 005/480] ALSA: hda/cs35l56: Workaround bad dev-index on Lenovo Yoga Book 9i GenX Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 007/480] ASoC: Intel: fix SND_SOC_SOF dependencies Greg Kroah-Hartman ` (485 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Jackie Dong, Takashi Iwai, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jackie Dong <xy-jackie@139.com> [ Upstream commit 4722727373533b53489b66d3436b50ac156f23bf ] Support mute LED on keyboard for Lenovo Yoga series products with Realtek ALC287 chipset. Tested on Lenovo Slim Pro 7 14APH8. [ slight comment cleanup by tiwai ] Signed-off-by: Jackie Dong <xy-jackie@139.com> Link: https://patch.msgid.link/20250714094655.4657-1-xy-jackie@139.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org> --- sound/pci/hda/patch_realtek.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 3c93d2135717..bf36e84d260b 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -7497,6 +7497,9 @@ static void alc287_fixup_yoga9_14iap7_bass_spk_pin(struct hda_codec *codec, }; struct alc_spec *spec = codec->spec; + /* Support Audio mute LED and Mic mute LED on keyboard */ + hda_fixup_ideapad_acpi(codec, fix, action); + switch (action) { case HDA_FIXUP_ACT_PRE_PROBE: snd_hda_apply_pincfgs(codec, pincfgs); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 007/480] ASoC: Intel: fix SND_SOC_SOF dependencies 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (5 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 006/480] ALSA: hda/realtek: Support mute LED for Yoga with ALC287 Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 008/480] ASoC: amd: yc: add DMI quirk for ASUS M6501RM Greg Kroah-Hartman ` (484 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Arnd Bergmann, Mark Brown, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Arnd Bergmann <arnd@arndb.de> [ Upstream commit e837b59f8b411b5baf5e3de7a5aea10b1c545a63 ] It is currently possible to configure a kernel with all Intel SoC configs as loadable modules, but the board config as built-in. This causes a link failure in the reference to the snd_soc_sof.ko module: x86_64-linux-ld: sound/soc/intel/boards/sof_rt5682.o: in function `sof_rt5682_hw_params': sof_rt5682.c:(.text+0x1f9): undefined reference to `sof_dai_get_mclk' x86_64-linux-ld: sof_rt5682.c:(.text+0x234): undefined reference to `sof_dai_get_bclk' x86_64-linux-ld: sound/soc/intel/boards/sof_rt5682.o: in function `sof_rt5682_codec_init': sof_rt5682.c:(.text+0x3e0): undefined reference to `sof_dai_get_mclk' x86_64-linux-ld: sound/soc/intel/boards/sof_cs42l42.o: in function `sof_cs42l42_hw_params': sof_cs42l42.c:(.text+0x2a): undefined reference to `sof_dai_get_bclk' x86_64-linux-ld: sound/soc/intel/boards/sof_nau8825.o: in function `sof_nau8825_hw_params': sof_nau8825.c:(.text+0x7f): undefined reference to `sof_dai_get_bclk' x86_64-linux-ld: sound/soc/intel/boards/sof_da7219.o: in function `da7219_codec_init': sof_da7219.c:(.text+0xbf): undefined reference to `sof_dai_get_mclk' x86_64-linux-ld: sound/soc/intel/boards/sof_maxim_common.o: in function `max_98373_hw_params': sof_maxim_common.c:(.text+0x6f9): undefined reference to `sof_dai_get_tdm_slots' x86_64-linux-ld: sound/soc/intel/boards/sof_realtek_common.o: in function `rt1015_hw_params': sof_realtek_common.c:(.text+0x54c): undefined reference to `sof_dai_get_bclk' x86_64-linux-ld: sound/soc/intel/boards/sof_realtek_common.o: in function `rt1308_hw_params': sof_realtek_common.c:(.text+0x702): undefined reference to `sof_dai_get_mclk' x86_64-linux-ld: sound/soc/intel/boards/sof_cirrus_common.o: in function `cs35l41_hw_params': sof_cirrus_common.c:(.text+0x2f): undefined reference to `sof_dai_get_bclk' Add an optional dependency on SND_SOC_SOF_INTEL_COMMON, to ensure that whenever the SOF support is in a loadable module, none of the board code can be built-in. This may be be a little heavy-handed, but I also don't see a reason why one would want the boards to be built-in but not the SoC, so it shouldn't actually cause any usability problems. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20250709145626.64125-1-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- sound/soc/intel/boards/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/intel/boards/Kconfig b/sound/soc/intel/boards/Kconfig index 4db7931ba561..4a9324232936 100644 --- a/sound/soc/intel/boards/Kconfig +++ b/sound/soc/intel/boards/Kconfig @@ -11,7 +11,7 @@ menuconfig SND_SOC_INTEL_MACH kernel: saying N will just cause the configurator to skip all the questions about Intel ASoC machine drivers. -if SND_SOC_INTEL_MACH +if SND_SOC_INTEL_MACH && (SND_SOC_SOF_INTEL_COMMON || !SND_SOC_SOF_INTEL_COMMON) config SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES bool "Use more user friendly long card names" -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 008/480] ASoC: amd: yc: add DMI quirk for ASUS M6501RM 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (6 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 007/480] ASoC: Intel: fix SND_SOC_SOF dependencies Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 009/480] audit,module: restore audit logging in load failure case Greg Kroah-Hartman ` (483 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Alexandru Andries, Mark Brown, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Alexandru Andries <alex.andries.aa@gmail.com> [ Upstream commit 6f80be548588429100eb1f5e25dc2a714d583ffe ] add DMI entry for ASUS Vivobook PRO 15X (M6501RM) to make the internal microphone function Signed-off-by: Alexandru Andries <alex.andries.aa@gmail.com> Link: https://patch.msgid.link/20250707220730.361290-1-alex.andries.aa@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- sound/soc/amd/yc/acp6x-mach.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c index 4bde41663f42..e362c2865ec1 100644 --- a/sound/soc/amd/yc/acp6x-mach.c +++ b/sound/soc/amd/yc/acp6x-mach.c @@ -409,6 +409,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "M6500RC"), } }, + { + .driver_data = &acp6x_card, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC."), + DMI_MATCH(DMI_PRODUCT_NAME, "M6501RM"), + } + }, { .driver_data = &acp6x_card, .matches = { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 009/480] audit,module: restore audit logging in load failure case 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (7 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 008/480] ASoC: amd: yc: add DMI quirk for ASUS M6501RM Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 010/480] [ceph] parse_longname(): strrchr() expects NUL-terminated string Greg Kroah-Hartman ` (482 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Richard Guy Briggs, Petr Pavlu, Paul Moore, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Richard Guy Briggs <rgb@redhat.com> [ Upstream commit ae1ae11fb277f1335d6bcd4935ba0ea985af3c32 ] The move of the module sanity check to earlier skipped the audit logging call in the case of failure and to a place where the previously used context is unavailable. Add an audit logging call for the module loading failure case and get the module name when possible. Link: https://issues.redhat.com/browse/RHEL-52839 Fixes: 02da2cbab452 ("module: move check_modinfo() early to early_mod_check()") Signed-off-by: Richard Guy Briggs <rgb@redhat.com> Reviewed-by: Petr Pavlu <petr.pavlu@suse.com> Signed-off-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- include/linux/audit.h | 9 ++++----- kernel/audit.h | 2 +- kernel/auditsc.c | 2 +- kernel/module/main.c | 6 ++++-- 4 files changed, 10 insertions(+), 9 deletions(-) diff --git a/include/linux/audit.h b/include/linux/audit.h index 0050ef288ab3..a394614ccd0b 100644 --- a/include/linux/audit.h +++ b/include/linux/audit.h @@ -417,7 +417,7 @@ extern int __audit_log_bprm_fcaps(struct linux_binprm *bprm, extern void __audit_log_capset(const struct cred *new, const struct cred *old); extern void __audit_mmap_fd(int fd, int flags); extern void __audit_openat2_how(struct open_how *how); -extern void __audit_log_kern_module(char *name); +extern void __audit_log_kern_module(const char *name); extern void __audit_fanotify(u32 response, struct fanotify_response_info_audit_rule *friar); extern void __audit_tk_injoffset(struct timespec64 offset); extern void __audit_ntp_log(const struct audit_ntp_data *ad); @@ -519,7 +519,7 @@ static inline void audit_openat2_how(struct open_how *how) __audit_openat2_how(how); } -static inline void audit_log_kern_module(char *name) +static inline void audit_log_kern_module(const char *name) { if (!audit_dummy_context()) __audit_log_kern_module(name); @@ -677,9 +677,8 @@ static inline void audit_mmap_fd(int fd, int flags) static inline void audit_openat2_how(struct open_how *how) { } -static inline void audit_log_kern_module(char *name) -{ -} +static inline void audit_log_kern_module(const char *name) +{ } static inline void audit_fanotify(u32 response, struct fanotify_response_info_audit_rule *friar) { } diff --git a/kernel/audit.h b/kernel/audit.h index 0211cb307d30..2a24d01c5fb0 100644 --- a/kernel/audit.h +++ b/kernel/audit.h @@ -200,7 +200,7 @@ struct audit_context { int argc; } execve; struct { - char *name; + const char *name; } module; struct { struct audit_ntp_data ntp_data; diff --git a/kernel/auditsc.c b/kernel/auditsc.c index 78fd876a5473..eb98cd6fe91f 100644 --- a/kernel/auditsc.c +++ b/kernel/auditsc.c @@ -2864,7 +2864,7 @@ void __audit_openat2_how(struct open_how *how) context->type = AUDIT_OPENAT2; } -void __audit_log_kern_module(char *name) +void __audit_log_kern_module(const char *name) { struct audit_context *context = audit_context(); diff --git a/kernel/module/main.c b/kernel/module/main.c index 9d8a845d9466..05da78b6a6c1 100644 --- a/kernel/module/main.c +++ b/kernel/module/main.c @@ -3298,7 +3298,7 @@ static int load_module(struct load_info *info, const char __user *uargs, module_allocated = true; - audit_log_kern_module(mod->name); + audit_log_kern_module(info->name); /* Reserve our place in the list. */ err = add_unformed_module(mod); @@ -3460,8 +3460,10 @@ static int load_module(struct load_info *info, const char __user *uargs, * failures once the proper module was allocated and * before that. */ - if (!module_allocated) + if (!module_allocated) { + audit_log_kern_module(info->name ? info->name : "?"); mod_stat_bump_becoming(info, flags); + } free_copy(info, flags); return err; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 010/480] [ceph] parse_longname(): strrchr() expects NUL-terminated string 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (8 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 009/480] audit,module: restore audit logging in load failure case Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 011/480] fs_context: fix parameter name in infofc() macro Greg Kroah-Hartman ` (481 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Viacheslav Dubeyko, Al Viro, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Al Viro <viro@zeniv.linux.org.uk> [ Upstream commit 101841c38346f4ca41dc1802c867da990ffb32eb ] ... and parse_longname() is not guaranteed that. That's the reason why it uses kmemdup_nul() to build the argument for kstrtou64(); the problem is, kstrtou64() is not the only thing that need it. Just get a NUL-terminated copy of the entire thing and be done with that... Fixes: dd66df0053ef "ceph: add support for encrypted snapshot names" Tested-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com> Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/ceph/crypto.c | 31 ++++++++++++------------------- 1 file changed, 12 insertions(+), 19 deletions(-) diff --git a/fs/ceph/crypto.c b/fs/ceph/crypto.c index 3b3c4d8d401e..9c7062245880 100644 --- a/fs/ceph/crypto.c +++ b/fs/ceph/crypto.c @@ -215,35 +215,31 @@ static struct inode *parse_longname(const struct inode *parent, struct ceph_client *cl = ceph_inode_to_client(parent); struct inode *dir = NULL; struct ceph_vino vino = { .snap = CEPH_NOSNAP }; - char *inode_number; - char *name_end; - int orig_len = *name_len; + char *name_end, *inode_number; int ret = -EIO; - + /* NUL-terminate */ + char *str __free(kfree) = kmemdup_nul(name, *name_len, GFP_KERNEL); + if (!str) + return ERR_PTR(-ENOMEM); /* Skip initial '_' */ - name++; - name_end = strrchr(name, '_'); + str++; + name_end = strrchr(str, '_'); if (!name_end) { - doutc(cl, "failed to parse long snapshot name: %s\n", name); + doutc(cl, "failed to parse long snapshot name: %s\n", str); return ERR_PTR(-EIO); } - *name_len = (name_end - name); + *name_len = (name_end - str); if (*name_len <= 0) { pr_err_client(cl, "failed to parse long snapshot name\n"); return ERR_PTR(-EIO); } /* Get the inode number */ - inode_number = kmemdup_nul(name_end + 1, - orig_len - *name_len - 2, - GFP_KERNEL); - if (!inode_number) - return ERR_PTR(-ENOMEM); + inode_number = name_end + 1; ret = kstrtou64(inode_number, 10, &vino.ino); if (ret) { - doutc(cl, "failed to parse inode number: %s\n", name); - dir = ERR_PTR(ret); - goto out; + doutc(cl, "failed to parse inode number: %s\n", str); + return ERR_PTR(ret); } /* And finally the inode */ @@ -254,9 +250,6 @@ static struct inode *parse_longname(const struct inode *parent, if (IS_ERR(dir)) doutc(cl, "can't find inode %s (%s)\n", inode_number, name); } - -out: - kfree(inode_number); return dir; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 011/480] fs_context: fix parameter name in infofc() macro 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (9 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 010/480] [ceph] parse_longname(): strrchr() expects NUL-terminated string Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 012/480] selftests/landlock: Fix readlink check Greg Kroah-Hartman ` (480 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, RubenKelevra, Christian Brauner, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: RubenKelevra <rubenkelevra@gmail.com> [ Upstream commit ffaf1bf3737f706e4e9be876de4bc3c8fc578091 ] The macro takes a parameter called "p" but references "fc" internally. This happens to compile as long as callers pass a variable named fc, but breaks otherwise. Rename the first parameter to “fc” to match the usage and to be consistent with warnfc() / errorfc(). Fixes: a3ff937b33d9 ("prefix-handling analogues of errorf() and friends") Signed-off-by: RubenKelevra <rubenkelevra@gmail.com> Link: https://lore.kernel.org/20250617230927.1790401-1-rubenkelevra@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- include/linux/fs_context.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/fs_context.h b/include/linux/fs_context.h index a19e4bd32e4d..7773eb870039 100644 --- a/include/linux/fs_context.h +++ b/include/linux/fs_context.h @@ -200,7 +200,7 @@ void logfc(struct fc_log *log, const char *prefix, char level, const char *fmt, */ #define infof(fc, fmt, ...) __logfc(fc, 'i', fmt, ## __VA_ARGS__) #define info_plog(p, fmt, ...) __plog(p, 'i', fmt, ## __VA_ARGS__) -#define infofc(p, fmt, ...) __plog((&(fc)->log), 'i', fmt, ## __VA_ARGS__) +#define infofc(fc, fmt, ...) __plog((&(fc)->log), 'i', fmt, ## __VA_ARGS__) /** * warnf - Store supplementary warning message -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 012/480] selftests/landlock: Fix readlink check 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (10 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 011/480] fs_context: fix parameter name in infofc() macro Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 013/480] selftests/landlock: Fix build of audit_test Greg Kroah-Hartman ` (479 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Dan Carpenter, Günther Noack, Mickaël Salaün, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Mickaël Salaün <mic@digikod.net> [ Upstream commit 94a7ce26428d3a7ceb46c503ed726160578b9fcc ] The audit_init_filter_exe() helper incorrectly checks the readlink(2) error because an unsigned integer is used to store the result. Use a signed integer for this check. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/aDbFwyZ_fM-IO7sC@stanley.mountain Fixes: 6a500b22971c ("selftests/landlock: Add tests for audit flags and domain IDs") Reviewed-by: Günther Noack <gnoack@google.com> Link: https://lore.kernel.org/r/20250528144426.1709063-1-mic@digikod.net Signed-off-by: Mickaël Salaün <mic@digikod.net> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/testing/selftests/landlock/audit.h | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/tools/testing/selftests/landlock/audit.h b/tools/testing/selftests/landlock/audit.h index 18a6014920b5..b16986aa6442 100644 --- a/tools/testing/selftests/landlock/audit.h +++ b/tools/testing/selftests/landlock/audit.h @@ -403,11 +403,12 @@ static int audit_init_filter_exe(struct audit_filter *filter, const char *path) /* It is assume that there is not already filtering rules. */ filter->record_type = AUDIT_EXE; if (!path) { - filter->exe_len = readlink("/proc/self/exe", filter->exe, - sizeof(filter->exe) - 1); - if (filter->exe_len < 0) + int ret = readlink("/proc/self/exe", filter->exe, + sizeof(filter->exe) - 1); + if (ret < 0) return -errno; + filter->exe_len = ret; return 0; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 013/480] selftests/landlock: Fix build of audit_test 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (11 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 012/480] selftests/landlock: Fix readlink check Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 014/480] fs/ntfs3: cancle set bad inode after removing name fails Greg Kroah-Hartman ` (478 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Song Liu, Mickaël Salaün, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Song Liu <song@kernel.org> [ Upstream commit dc58130bc38f09b162aa3b216f8b8f1e0a56127b ] We are hitting build error on CentOS 9: audit_test.c:232:40: error: ‘O_CLOEXEC’ undeclared (...) Fix this by including fcntl.h. Signed-off-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/r/20250605214416.1885878-1-song@kernel.org Fixes: 6b4566400a29 ("selftests/landlock: Add PID tests for audit records") Signed-off-by: Mickaël Salaün <mic@digikod.net> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/testing/selftests/landlock/audit_test.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/landlock/audit_test.c b/tools/testing/selftests/landlock/audit_test.c index cfc571afd0eb..46d02d49835a 100644 --- a/tools/testing/selftests/landlock/audit_test.c +++ b/tools/testing/selftests/landlock/audit_test.c @@ -7,6 +7,7 @@ #define _GNU_SOURCE #include <errno.h> +#include <fcntl.h> #include <limits.h> #include <linux/landlock.h> #include <pthread.h> -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 014/480] fs/ntfs3: cancle set bad inode after removing name fails 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (12 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 013/480] selftests/landlock: Fix build of audit_test Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 015/480] landlock: Fix warning from KUnit tests Greg Kroah-Hartman ` (477 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, syzbot+1aa90f0eb1fc3e77d969, Edward Adam Davis, Konstantin Komarov, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Edward Adam Davis <eadavis@qq.com> [ Upstream commit d99208b91933fd2a58ed9ed321af07dacd06ddc3 ] The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link. When renaming, the file0's inode is marked as a bad inode because the file name cannot be deleted. The underlying bug is that make_bad_inode() is called on a live inode. In some cases it's "icache lookup finds a normal inode, d_splice_alias() is called to attach it to dentry, while another thread decides to call make_bad_inode() on it - that would evict it from icache, but we'd already found it there earlier". In some it's outright "we have an inode attached to dentry - that's how we got it in the first place; let's call make_bad_inode() on it just for shits and giggles". Fixes: 78ab59fee07f ("fs/ntfs3: Rework file operations") Reported-by: syzbot+1aa90f0eb1fc3e77d969@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1aa90f0eb1fc3e77d969 Signed-off-by: Edward Adam Davis <eadavis@qq.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/ntfs3/frecord.c | 7 +++---- fs/ntfs3/namei.c | 10 +++------- fs/ntfs3/ntfs_fs.h | 3 +-- 3 files changed, 7 insertions(+), 13 deletions(-) diff --git a/fs/ntfs3/frecord.c b/fs/ntfs3/frecord.c index b7a83200f2cc..83593ecbe57e 100644 --- a/fs/ntfs3/frecord.c +++ b/fs/ntfs3/frecord.c @@ -3003,8 +3003,7 @@ int ni_add_name(struct ntfs_inode *dir_ni, struct ntfs_inode *ni, * ni_rename - Remove one name and insert new name. */ int ni_rename(struct ntfs_inode *dir_ni, struct ntfs_inode *new_dir_ni, - struct ntfs_inode *ni, struct NTFS_DE *de, struct NTFS_DE *new_de, - bool *is_bad) + struct ntfs_inode *ni, struct NTFS_DE *de, struct NTFS_DE *new_de) { int err; struct NTFS_DE *de2 = NULL; @@ -3027,8 +3026,8 @@ int ni_rename(struct ntfs_inode *dir_ni, struct ntfs_inode *new_dir_ni, err = ni_add_name(new_dir_ni, ni, new_de); if (!err) { err = ni_remove_name(dir_ni, ni, de, &de2, &undo); - if (err && ni_remove_name(new_dir_ni, ni, new_de, &de2, &undo)) - *is_bad = true; + WARN_ON(err && ni_remove_name(new_dir_ni, ni, new_de, &de2, + &undo)); } /* diff --git a/fs/ntfs3/namei.c b/fs/ntfs3/namei.c index 652735a0b0c4..fec451381a88 100644 --- a/fs/ntfs3/namei.c +++ b/fs/ntfs3/namei.c @@ -244,7 +244,7 @@ static int ntfs_rename(struct mnt_idmap *idmap, struct inode *dir, struct ntfs_inode *ni = ntfs_i(inode); struct inode *new_inode = d_inode(new_dentry); struct NTFS_DE *de, *new_de; - bool is_same, is_bad; + bool is_same; /* * de - memory of PATH_MAX bytes: * [0-1024) - original name (dentry->d_name) @@ -313,12 +313,8 @@ static int ntfs_rename(struct mnt_idmap *idmap, struct inode *dir, if (dir_ni != new_dir_ni) ni_lock_dir2(new_dir_ni); - is_bad = false; - err = ni_rename(dir_ni, new_dir_ni, ni, de, new_de, &is_bad); - if (is_bad) { - /* Restore after failed rename failed too. */ - _ntfs_bad_inode(inode); - } else if (!err) { + err = ni_rename(dir_ni, new_dir_ni, ni, de, new_de); + if (!err) { simple_rename_timestamp(dir, dentry, new_dir, new_dentry); mark_inode_dirty(inode); mark_inode_dirty(dir); diff --git a/fs/ntfs3/ntfs_fs.h b/fs/ntfs3/ntfs_fs.h index d628977e2556..a79cf4a63b25 100644 --- a/fs/ntfs3/ntfs_fs.h +++ b/fs/ntfs3/ntfs_fs.h @@ -581,8 +581,7 @@ int ni_add_name(struct ntfs_inode *dir_ni, struct ntfs_inode *ni, struct NTFS_DE *de); int ni_rename(struct ntfs_inode *dir_ni, struct ntfs_inode *new_dir_ni, - struct ntfs_inode *ni, struct NTFS_DE *de, struct NTFS_DE *new_de, - bool *is_bad); + struct ntfs_inode *ni, struct NTFS_DE *de, struct NTFS_DE *new_de); bool ni_is_dirty(struct inode *inode); int ni_set_compress(struct inode *inode, bool compr); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 015/480] landlock: Fix warning from KUnit tests 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (13 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 014/480] fs/ntfs3: cancle set bad inode after removing name fails Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 016/480] ublk: use vmalloc for ublk_devices __queues Greg Kroah-Hartman ` (476 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Tingmao Wang, Mickaël Salaün, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Tingmao Wang <m@maowtm.org> [ Upstream commit e0a69cf2c03e61bd8069becb97f66c173d0d1fa1 ] get_id_range() expects a positive value as first argument but get_random_u8() can return 0. Fix this by clamping it. Validated by running the test in a for loop for 1000 times. Note that MAX() is wrong as it is only supposed to be used for constants, but max() is good here. [..] ok 9 test_range2_rand1 [..] ok 10 test_range2_rand2 [..] ok 11 test_range2_rand15 [..] ------------[ cut here ]------------ [..] WARNING: CPU: 6 PID: 104 at security/landlock/id.c:99 test_range2_rand16 (security/landlock/id.c:99 (discriminator 1) security/landlock/id.c:234 (discriminator 1)) [..] Modules linked in: [..] CPU: 6 UID: 0 PID: 104 Comm: kunit_try_catch Tainted: G N 6.16.0-rc1-dev-00001-g314a2f98b65f #1 PREEMPT(undef) [..] Tainted: [N]=TEST [..] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [..] RIP: 0010:test_range2_rand16 (security/landlock/id.c:99 (discriminator 1) security/landlock/id.c:234 (discriminator 1)) [..] Code: 49 c7 c0 10 70 30 82 4c 89 ff 48 c7 c6 a0 63 1e 83 49 c7 45 a0 e0 63 1e 83 e8 3f 95 17 00 e9 1f ff ff ff 0f 0b e9 df fd ff ff <0f> 0b ba 01 00 00 00 e9 68 fe ff ff 49 89 45 a8 49 8d 4d a0 45 31 [..] RSP: 0000:ffff888104eb7c78 EFLAGS: 00010246 [..] RAX: 0000000000000000 RBX: 000000000870822c RCX: 0000000000000000 ^^^^^^^^^^^^^^^^ [..] [..] Call Trace: [..] [..] ---[ end trace 0000000000000000 ]--- [..] ok 12 test_range2_rand16 [..] # landlock_id: pass:12 fail:0 skip:0 total:12 [..] # Totals: pass:12 fail:0 skip:0 total:12 [..] ok 1 landlock_id Fixes: d9d2a68ed44b ("landlock: Add unique ID generator") Signed-off-by: Tingmao Wang <m@maowtm.org> Link: https://lore.kernel.org/r/73e28efc5b8cc394608b99d5bc2596ca917d7c4a.1750003733.git.m@maowtm.org [mic: Minor cosmetic improvements] Signed-off-by: Mickaël Salaün <mic@digikod.net> Signed-off-by: Sasha Levin <sashal@kernel.org> --- security/landlock/id.c | 69 +++++++++++++++++++++++++----------------- 1 file changed, 42 insertions(+), 27 deletions(-) diff --git a/security/landlock/id.c b/security/landlock/id.c index 56f7cc0fc744..838c3ed7bb82 100644 --- a/security/landlock/id.c +++ b/security/landlock/id.c @@ -119,6 +119,12 @@ static u64 get_id_range(size_t number_of_ids, atomic64_t *const counter, #ifdef CONFIG_SECURITY_LANDLOCK_KUNIT_TEST +static u8 get_random_u8_positive(void) +{ + /* max() evaluates its arguments once. */ + return max(1, get_random_u8()); +} + static void test_range1_rand0(struct kunit *const test) { atomic64_t counter; @@ -127,9 +133,10 @@ static void test_range1_rand0(struct kunit *const test) init = get_random_u32(); atomic64_set(&counter, init); KUNIT_EXPECT_EQ(test, get_id_range(1, &counter, 0), init); - KUNIT_EXPECT_EQ( - test, get_id_range(get_random_u8(), &counter, get_random_u8()), - init + 1); + KUNIT_EXPECT_EQ(test, + get_id_range(get_random_u8_positive(), &counter, + get_random_u8()), + init + 1); } static void test_range1_rand1(struct kunit *const test) @@ -140,9 +147,10 @@ static void test_range1_rand1(struct kunit *const test) init = get_random_u32(); atomic64_set(&counter, init); KUNIT_EXPECT_EQ(test, get_id_range(1, &counter, 1), init); - KUNIT_EXPECT_EQ( - test, get_id_range(get_random_u8(), &counter, get_random_u8()), - init + 2); + KUNIT_EXPECT_EQ(test, + get_id_range(get_random_u8_positive(), &counter, + get_random_u8()), + init + 2); } static void test_range1_rand15(struct kunit *const test) @@ -153,9 +161,10 @@ static void test_range1_rand15(struct kunit *const test) init = get_random_u32(); atomic64_set(&counter, init); KUNIT_EXPECT_EQ(test, get_id_range(1, &counter, 15), init); - KUNIT_EXPECT_EQ( - test, get_id_range(get_random_u8(), &counter, get_random_u8()), - init + 16); + KUNIT_EXPECT_EQ(test, + get_id_range(get_random_u8_positive(), &counter, + get_random_u8()), + init + 16); } static void test_range1_rand16(struct kunit *const test) @@ -166,9 +175,10 @@ static void test_range1_rand16(struct kunit *const test) init = get_random_u32(); atomic64_set(&counter, init); KUNIT_EXPECT_EQ(test, get_id_range(1, &counter, 16), init); - KUNIT_EXPECT_EQ( - test, get_id_range(get_random_u8(), &counter, get_random_u8()), - init + 1); + KUNIT_EXPECT_EQ(test, + get_id_range(get_random_u8_positive(), &counter, + get_random_u8()), + init + 1); } static void test_range2_rand0(struct kunit *const test) @@ -179,9 +189,10 @@ static void test_range2_rand0(struct kunit *const test) init = get_random_u32(); atomic64_set(&counter, init); KUNIT_EXPECT_EQ(test, get_id_range(2, &counter, 0), init); - KUNIT_EXPECT_EQ( - test, get_id_range(get_random_u8(), &counter, get_random_u8()), - init + 2); + KUNIT_EXPECT_EQ(test, + get_id_range(get_random_u8_positive(), &counter, + get_random_u8()), + init + 2); } static void test_range2_rand1(struct kunit *const test) @@ -192,9 +203,10 @@ static void test_range2_rand1(struct kunit *const test) init = get_random_u32(); atomic64_set(&counter, init); KUNIT_EXPECT_EQ(test, get_id_range(2, &counter, 1), init); - KUNIT_EXPECT_EQ( - test, get_id_range(get_random_u8(), &counter, get_random_u8()), - init + 3); + KUNIT_EXPECT_EQ(test, + get_id_range(get_random_u8_positive(), &counter, + get_random_u8()), + init + 3); } static void test_range2_rand2(struct kunit *const test) @@ -205,9 +217,10 @@ static void test_range2_rand2(struct kunit *const test) init = get_random_u32(); atomic64_set(&counter, init); KUNIT_EXPECT_EQ(test, get_id_range(2, &counter, 2), init); - KUNIT_EXPECT_EQ( - test, get_id_range(get_random_u8(), &counter, get_random_u8()), - init + 4); + KUNIT_EXPECT_EQ(test, + get_id_range(get_random_u8_positive(), &counter, + get_random_u8()), + init + 4); } static void test_range2_rand15(struct kunit *const test) @@ -218,9 +231,10 @@ static void test_range2_rand15(struct kunit *const test) init = get_random_u32(); atomic64_set(&counter, init); KUNIT_EXPECT_EQ(test, get_id_range(2, &counter, 15), init); - KUNIT_EXPECT_EQ( - test, get_id_range(get_random_u8(), &counter, get_random_u8()), - init + 17); + KUNIT_EXPECT_EQ(test, + get_id_range(get_random_u8_positive(), &counter, + get_random_u8()), + init + 17); } static void test_range2_rand16(struct kunit *const test) @@ -231,9 +245,10 @@ static void test_range2_rand16(struct kunit *const test) init = get_random_u32(); atomic64_set(&counter, init); KUNIT_EXPECT_EQ(test, get_id_range(2, &counter, 16), init); - KUNIT_EXPECT_EQ( - test, get_id_range(get_random_u8(), &counter, get_random_u8()), - init + 2); + KUNIT_EXPECT_EQ(test, + get_id_range(get_random_u8_positive(), &counter, + get_random_u8()), + init + 2); } #endif /* CONFIG_SECURITY_LANDLOCK_KUNIT_TEST */ -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 016/480] ublk: use vmalloc for ublk_devices __queues 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (14 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 015/480] landlock: Fix warning from KUnit tests Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 017/480] hfsplus: make splice write available again Greg Kroah-Hartman ` (475 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Caleb Sander Mateos, Ming Lei, Jens Axboe, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Caleb Sander Mateos <csander@purestorage.com> [ Upstream commit c2f48453b7806d41f5a3270f206a5cd5640ed207 ] struct ublk_device's __queues points to an allocation with up to UBLK_MAX_NR_QUEUES (4096) queues, each of which have: - struct ublk_queue (48 bytes) - Tail array of up to UBLK_MAX_QUEUE_DEPTH (4096) struct ublk_io's, 32 bytes each This means the full allocation can exceed 512 MB, which may well be impossible to service with contiguous physical pages. Switch to kvcalloc() and kvfree(), since there is no need for physically contiguous memory. Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Fixes: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver") Reviewed-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20250620151008.3976463-2-csander@purestorage.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/block/ublk_drv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c index 0e017eae97fb..066231e66f03 100644 --- a/drivers/block/ublk_drv.c +++ b/drivers/block/ublk_drv.c @@ -2373,7 +2373,7 @@ static void ublk_deinit_queues(struct ublk_device *ub) for (i = 0; i < nr_queues; i++) ublk_deinit_queue(ub, i); - kfree(ub->__queues); + kvfree(ub->__queues); } static int ublk_init_queues(struct ublk_device *ub) @@ -2384,7 +2384,7 @@ static int ublk_init_queues(struct ublk_device *ub) int i, ret = -ENOMEM; ub->queue_size = ubq_size; - ub->__queues = kcalloc(nr_queues, ubq_size, GFP_KERNEL); + ub->__queues = kvcalloc(nr_queues, ubq_size, GFP_KERNEL); if (!ub->__queues) return ret; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 017/480] hfsplus: make splice write available again 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (15 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 016/480] ublk: use vmalloc for ublk_devices __queues Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 018/480] hfs: " Greg Kroah-Hartman ` (474 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Yangtao Li, Viacheslav Dubeyko, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Yangtao Li <frank.li@vivo.com> [ Upstream commit 2eafb669da0bf71fac0838bff13594970674e2b4 ] Since 5.10, splice() or sendfile() return EINVAL. This was caused by commit 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops"). This patch initializes the splice_write field in file_operations, like most file systems do, to restore the functionality. Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops") Signed-off-by: Yangtao Li <frank.li@vivo.com> Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com> Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20250529140033.2296791-1-frank.li@vivo.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/hfsplus/inode.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/hfsplus/inode.c b/fs/hfsplus/inode.c index f331e9574217..c85b5802ec0f 100644 --- a/fs/hfsplus/inode.c +++ b/fs/hfsplus/inode.c @@ -368,6 +368,7 @@ static const struct file_operations hfsplus_file_operations = { .write_iter = generic_file_write_iter, .mmap = generic_file_mmap, .splice_read = filemap_splice_read, + .splice_write = iter_file_splice_write, .fsync = hfsplus_file_fsync, .open = hfsplus_file_open, .release = hfsplus_file_release, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 018/480] hfs: make splice write available again 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (16 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 017/480] hfsplus: make splice write available again Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 019/480] hfsplus: remove mutex_lock check in hfsplus_free_extents Greg Kroah-Hartman ` (473 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Yangtao Li, Viacheslav Dubeyko, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Yangtao Li <frank.li@vivo.com> [ Upstream commit 4c831f30475a222046ded25560c3810117a6cff6 ] Since 5.10, splice() or sendfile() return EINVAL. This was caused by commit 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops"). This patch initializes the splice_write field in file_operations, like most file systems do, to restore the functionality. Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops") Signed-off-by: Yangtao Li <frank.li@vivo.com> Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com> Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20250529140033.2296791-2-frank.li@vivo.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/hfs/inode.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/hfs/inode.c b/fs/hfs/inode.c index a81ce7a740b9..451115360f73 100644 --- a/fs/hfs/inode.c +++ b/fs/hfs/inode.c @@ -692,6 +692,7 @@ static const struct file_operations hfs_file_operations = { .write_iter = generic_file_write_iter, .mmap = generic_file_mmap, .splice_read = filemap_splice_read, + .splice_write = iter_file_splice_write, .fsync = hfs_file_fsync, .open = hfs_file_open, .release = hfs_file_release, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 019/480] hfsplus: remove mutex_lock check in hfsplus_free_extents 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (17 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 018/480] hfs: " Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 020/480] Revert "fs/ntfs3: Replace inode_trylock with inode_lock" Greg Kroah-Hartman ` (472 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, syzbot+8c0bc9f818702ff75b76, Yangtao Li, Viacheslav Dubeyko, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Yangtao Li <frank.li@vivo.com> [ Upstream commit fcb96956c921f1aae7e7b477f2435c56f77a31b4 ] Syzbot reported an issue in hfsplus filesystem: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346 hfsplus_free_extents+0x700/0xad0 Call Trace: <TASK> hfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606 hfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56 cont_expand_zero fs/buffer.c:2383 [inline] cont_write_begin+0x2cf/0x860 fs/buffer.c:2446 hfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52 generic_cont_expand_simple+0x151/0x250 fs/buffer.c:2347 hfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263 notify_change+0xe38/0x10f0 fs/attr.c:420 do_truncate+0x1fb/0x2e0 fs/open.c:65 do_sys_ftruncate+0x2eb/0x380 fs/open.c:193 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd To avoid deadlock, Commit 31651c607151 ("hfsplus: avoid deadlock on file truncation") unlock extree before hfsplus_free_extents(), and add check wheather extree is locked in hfsplus_free_extents(). However, when operations such as hfsplus_file_release, hfsplus_setattr, hfsplus_unlink, and hfsplus_get_block are executed concurrently in different files, it is very likely to trigger the WARN_ON, which will lead syzbot and xfstest to consider it as an abnormality. The comment above this warning also describes one of the easy triggering situations, which can easily trigger and cause xfstest&syzbot to report errors. [task A] [task B] ->hfsplus_file_release ->hfsplus_file_truncate ->hfs_find_init ->mutex_lock ->mutex_unlock ->hfsplus_write_begin ->hfsplus_get_block ->hfsplus_file_extend ->hfsplus_ext_read_extent ->hfs_find_init ->mutex_lock ->hfsplus_free_extents WARN_ON(mutex_is_locked) !!! Several threads could try to lock the shared extents tree. And warning can be triggered in one thread when another thread has locked the tree. This is the wrong behavior of the code and we need to remove the warning. Fixes: 31651c607151f ("hfsplus: avoid deadlock on file truncation") Reported-by: syzbot+8c0bc9f818702ff75b76@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/00000000000057fa4605ef101c4c@google.com/ Signed-off-by: Yangtao Li <frank.li@vivo.com> Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com> Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20250529061807.2213498-1-frank.li@vivo.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/hfsplus/extents.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/fs/hfsplus/extents.c b/fs/hfsplus/extents.c index a6d61685ae79..b1699b3c246a 100644 --- a/fs/hfsplus/extents.c +++ b/fs/hfsplus/extents.c @@ -342,9 +342,6 @@ static int hfsplus_free_extents(struct super_block *sb, int i; int err = 0; - /* Mapping the allocation file may lock the extent tree */ - WARN_ON(mutex_is_locked(&HFSPLUS_SB(sb)->ext_tree->tree_lock)); - hfsplus_dump_extent(extent); for (i = 0; i < 8; extent++, i++) { count = be32_to_cpu(extent->block_count); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 020/480] Revert "fs/ntfs3: Replace inode_trylock with inode_lock" 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (18 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 019/480] hfsplus: remove mutex_lock check in hfsplus_free_extents Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 021/480] block: mtip32xx: Fix usage of dma_map_sg() Greg Kroah-Hartman ` (471 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, syzbot+a91fcdbd2698f99db8f4, Lorenzo Stoakes, Konstantin Komarov, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> [ Upstream commit a49f0abd8959048af18c6c690b065eb0d65b2d21 ] This reverts commit 69505fe98f198ee813898cbcaf6770949636430b. Initially, conditional lock acquisition was removed to fix an xfstest bug that was observed during internal testing. The deadlock reported by syzbot is resolved by reintroducing conditional acquisition. The xfstest bug no longer occurs on kernel version 6.16-rc1 during internal testing. I assume that changes in other modules may have contributed to this. Fixes: 69505fe98f19 ("fs/ntfs3: Replace inode_trylock with inode_lock") Reported-by: syzbot+a91fcdbd2698f99db8f4@syzkaller.appspotmail.com Suggested-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/ntfs3/file.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/ntfs3/file.c b/fs/ntfs3/file.c index 9b6a3f8d2e7c..fbecda79fa84 100644 --- a/fs/ntfs3/file.c +++ b/fs/ntfs3/file.c @@ -394,7 +394,10 @@ static int ntfs_file_mmap(struct file *file, struct vm_area_struct *vma) } if (ni->i_valid < to) { - inode_lock(inode); + if (!inode_trylock(inode)) { + err = -EAGAIN; + goto out; + } err = ntfs_extend_initialized_size(file, ni, ni->i_valid, to); inode_unlock(inode); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 021/480] block: mtip32xx: Fix usage of dma_map_sg() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (19 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 020/480] Revert "fs/ntfs3: Replace inode_trylock with inode_lock" Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 022/480] gfs2: Minor do_xmote cancelation fix Greg Kroah-Hartman ` (470 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Thomas Fourier, Andy Shevchenko, Jens Axboe, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Fourier <fourier.thomas@gmail.com> [ Upstream commit 8e1fab9cccc7b806b0cffdceabb09b310b83b553 ] The dma_map_sg() can fail and, in case of failure, returns 0. If it fails, mtip_hw_submit_io() returns an error. The dma_unmap_sg() requires the nents parameter to be the same as the one passed to dma_map_sg(). This patch saves the nents in command->scatter_ents. Fixes: 88523a61558a ("block: Add driver for Micron RealSSD pcie flash cards") Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20250627121123.203731-2-fourier.thomas@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/block/mtip32xx/mtip32xx.c | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-) diff --git a/drivers/block/mtip32xx/mtip32xx.c b/drivers/block/mtip32xx/mtip32xx.c index 0d619df03fa9..fe3a0b8377db 100644 --- a/drivers/block/mtip32xx/mtip32xx.c +++ b/drivers/block/mtip32xx/mtip32xx.c @@ -2040,11 +2040,12 @@ static int mtip_hw_ioctl(struct driver_data *dd, unsigned int cmd, * @dir Direction (read or write) * * return value - * None + * 0 The IO completed successfully. + * -ENOMEM The DMA mapping failed. */ -static void mtip_hw_submit_io(struct driver_data *dd, struct request *rq, - struct mtip_cmd *command, - struct blk_mq_hw_ctx *hctx) +static int mtip_hw_submit_io(struct driver_data *dd, struct request *rq, + struct mtip_cmd *command, + struct blk_mq_hw_ctx *hctx) { struct mtip_cmd_hdr *hdr = dd->port->command_list + sizeof(struct mtip_cmd_hdr) * rq->tag; @@ -2056,12 +2057,14 @@ static void mtip_hw_submit_io(struct driver_data *dd, struct request *rq, unsigned int nents; /* Map the scatter list for DMA access */ - nents = blk_rq_map_sg(rq, command->sg); - nents = dma_map_sg(&dd->pdev->dev, command->sg, nents, dma_dir); + command->scatter_ents = blk_rq_map_sg(rq, command->sg); + nents = dma_map_sg(&dd->pdev->dev, command->sg, + command->scatter_ents, dma_dir); + if (!nents) + return -ENOMEM; - prefetch(&port->flags); - command->scatter_ents = nents; + prefetch(&port->flags); /* * The number of retries for this command before it is @@ -2112,11 +2115,13 @@ static void mtip_hw_submit_io(struct driver_data *dd, struct request *rq, if (unlikely(port->flags & MTIP_PF_PAUSE_IO)) { set_bit(rq->tag, port->cmds_to_issue); set_bit(MTIP_PF_ISSUE_CMDS_BIT, &port->flags); - return; + return 0; } /* Issue the command to the hardware */ mtip_issue_ncq_command(port, rq->tag); + + return 0; } /* @@ -3315,7 +3320,9 @@ static blk_status_t mtip_queue_rq(struct blk_mq_hw_ctx *hctx, blk_mq_start_request(rq); - mtip_hw_submit_io(dd, rq, cmd, hctx); + if (mtip_hw_submit_io(dd, rq, cmd, hctx)) + return BLK_STS_IOERR; + return BLK_STS_OK; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 022/480] gfs2: Minor do_xmote cancelation fix 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (20 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 021/480] block: mtip32xx: Fix usage of dma_map_sg() Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 023/480] md: allow removing faulty rdev during resync Greg Kroah-Hartman ` (469 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Andreas Gruenbacher, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Andreas Gruenbacher <agruenba@redhat.com> [ Upstream commit 75bb2ddea9640b663e4b2eaa06e15196f6f11a95 ] Commit 6cb3b1c2df87 changed how finish_xmote() clears the GLF_LOCK flag, but it failed to adjust the equivalent code in do_xmote(). Fix that. Fixes: 6cb3b1c2df87 ("gfs2: Fix additional unlikely request cancelation race") Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/gfs2/glock.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c index ba25b884169e..ea96113edbe3 100644 --- a/fs/gfs2/glock.c +++ b/fs/gfs2/glock.c @@ -802,7 +802,8 @@ __acquires(&gl->gl_lockref.lock) * We skip telling dlm to do the locking, so we won't get a * reply that would otherwise clear GLF_LOCK. So we clear it here. */ - clear_bit(GLF_LOCK, &gl->gl_flags); + if (!test_bit(GLF_CANCELING, &gl->gl_flags)) + clear_bit(GLF_LOCK, &gl->gl_flags); clear_bit(GLF_DEMOTE_IN_PROGRESS, &gl->gl_flags); gfs2_glock_queue_work(gl, GL_GLOCK_DFT_HOLD); return; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 023/480] md: allow removing faulty rdev during resync 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (21 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 022/480] gfs2: Minor do_xmote cancelation fix Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 024/480] kunit/fortify: Add back "volatile" for sizeof() constants Greg Kroah-Hartman ` (468 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Zheng Qixing, Li Nan, Yu Kuai, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Zheng Qixing <zhengqixing@huawei.com> [ Upstream commit c0ffeb648000acdc932da7a9d33fd65e9263c54c ] During RAID resync, faulty rdev cannot be removed and will result in "Device or resource busy" error when attempting hot removal. Reproduction steps: mdadm -Cv /dev/md0 -l1 -n3 -e1.2 /dev/sd{b..d} mdadm /dev/md0 -f /dev/sdb mdadm /dev/md0 -r /dev/sdb -> mdadm: hot remove failed for /dev/sdb: Device or resource busy After commit 4b10a3bc67c1 ("md: ensure resync is prioritized over recovery"), when a device becomes faulty during resync, the md_choose_sync_action() function returns early without calling remove_and_add_spares(), preventing faulty device removal. This patch extracts a helper function remove_spares() to support removing faulty devices during RAID resync operations. Fixes: 4b10a3bc67c1 ("md: ensure resync is prioritized over recovery") Signed-off-by: Zheng Qixing <zhengqixing@huawei.com> Reviewed-by: Li Nan <linan122@huawei.com> Link: https://lore.kernel.org/linux-raid/20250707075412.150301-1-zhengqixing@huaweicloud.com Signed-off-by: Yu Kuai <yukuai3@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/md/md.c | 24 +++++++++++++++++------- 1 file changed, 17 insertions(+), 7 deletions(-) diff --git a/drivers/md/md.c b/drivers/md/md.c index 9daa78c5fe33..0de87d451a47 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -9380,17 +9380,11 @@ static bool md_spares_need_change(struct mddev *mddev) return false; } -static int remove_and_add_spares(struct mddev *mddev, - struct md_rdev *this) +static int remove_spares(struct mddev *mddev, struct md_rdev *this) { struct md_rdev *rdev; - int spares = 0; int removed = 0; - if (this && test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) - /* Mustn't remove devices when resync thread is running */ - return 0; - rdev_for_each(rdev, mddev) { if ((this == NULL || rdev == this) && rdev_removeable(rdev) && !mddev->pers->hot_remove_disk(mddev, rdev)) { @@ -9404,6 +9398,21 @@ static int remove_and_add_spares(struct mddev *mddev, if (removed && mddev->kobj.sd) sysfs_notify_dirent_safe(mddev->sysfs_degraded); + return removed; +} + +static int remove_and_add_spares(struct mddev *mddev, + struct md_rdev *this) +{ + struct md_rdev *rdev; + int spares = 0; + int removed = 0; + + if (this && test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) + /* Mustn't remove devices when resync thread is running */ + return 0; + + removed = remove_spares(mddev, this); if (this && removed) goto no_add; @@ -9446,6 +9455,7 @@ static bool md_choose_sync_action(struct mddev *mddev, int *spares) /* Check if resync is in progress. */ if (mddev->recovery_cp < MaxSector) { + remove_spares(mddev, NULL); set_bit(MD_RECOVERY_SYNC, &mddev->recovery); clear_bit(MD_RECOVERY_RECOVER, &mddev->recovery); return true; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 024/480] kunit/fortify: Add back "volatile" for sizeof() constants 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (22 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 023/480] md: allow removing faulty rdev during resync Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 025/480] gfs2: No more self recovery Greg Kroah-Hartman ` (467 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Nathan Chancellor, Jannik Glückert, Kees Cook, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Kees Cook <kees@kernel.org> [ Upstream commit 10299c07c94aa0997fa43523b53301e713a6415d ] It seems the Clang can see through OPTIMIZER_HIDE_VAR when the constant is coming from sizeof. Adding "volatile" back to these variables solves this false positive without reintroducing the issues that originally led to switching to OPTIMIZER_HIDE_VAR in the first place[1]. Reported-by: Nathan Chancellor <nathan@kernel.org> Closes: https://github.com/ClangBuiltLinux/linux/issues/2075 [1] Cc: Jannik Glückert <jannik.glueckert@gmail.com> Suggested-by: Nathan Chancellor <nathan@kernel.org> Fixes: 6ee149f61bcc ("kunit/fortify: Replace "volatile" with OPTIMIZER_HIDE_VAR()") Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20250628234034.work.800-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- lib/tests/fortify_kunit.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/tests/fortify_kunit.c b/lib/tests/fortify_kunit.c index 29ffc62a71e3..fc9c76f026d6 100644 --- a/lib/tests/fortify_kunit.c +++ b/lib/tests/fortify_kunit.c @@ -1003,8 +1003,8 @@ static void fortify_test_memcmp(struct kunit *test) { char one[] = "My mind is going ..."; char two[] = "My mind is going ... I can feel it."; - size_t one_len = sizeof(one) - 1; - size_t two_len = sizeof(two) - 1; + volatile size_t one_len = sizeof(one) - 1; + volatile size_t two_len = sizeof(two) - 1; OPTIMIZER_HIDE_VAR(one_len); OPTIMIZER_HIDE_VAR(two_len); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 025/480] gfs2: No more self recovery 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (23 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 024/480] kunit/fortify: Add back "volatile" for sizeof() constants Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 026/480] block: sanitize chunk_sectors for atomic write limits Greg Kroah-Hartman ` (466 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Chunjie Zhu, Andreas Gruenbacher, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Andreas Gruenbacher <agruenba@redhat.com> [ Upstream commit deb016c1669002e48c431d6fd32ea1c20ef41756 ] When a node withdraws and it turns out that it is the only node that has the filesystem mounted, gfs2 currently tries to replay the local journal to bring the filesystem back into a consistent state. Not only is that a very bad idea, it has also never worked because gfs2_recover_func() will refuse to do anything during a withdraw. However, before even getting to this point, gfs2_recover_func() dereferences sdp->sd_jdesc->jd_inode. This was a use-after-free before commit 04133b607a78 ("gfs2: Prevent double iput for journal on error") and is a NULL pointer dereference since then. Simply get rid of self recovery to fix that. Fixes: 601ef0d52e96 ("gfs2: Force withdraw to replay journals and wait for it to finish") Reported-by: Chunjie Zhu <chunjie.zhu@cloud.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/gfs2/util.c | 31 +++++++++++-------------------- 1 file changed, 11 insertions(+), 20 deletions(-) diff --git a/fs/gfs2/util.c b/fs/gfs2/util.c index 13be8d1d228b..ee198a261d4f 100644 --- a/fs/gfs2/util.c +++ b/fs/gfs2/util.c @@ -232,32 +232,23 @@ static void signal_our_withdraw(struct gfs2_sbd *sdp) */ ret = gfs2_glock_nq(&sdp->sd_live_gh); + gfs2_glock_put(live_gl); /* drop extra reference we acquired */ + clear_bit(SDF_WITHDRAW_RECOVERY, &sdp->sd_flags); + /* * If we actually got the "live" lock in EX mode, there are no other - * nodes available to replay our journal. So we try to replay it - * ourselves. We hold the "live" glock to prevent other mounters - * during recovery, then just dequeue it and reacquire it in our - * normal SH mode. Just in case the problem that caused us to - * withdraw prevents us from recovering our journal (e.g. io errors - * and such) we still check if the journal is clean before proceeding - * but we may wait forever until another mounter does the recovery. + * nodes available to replay our journal. */ if (ret == 0) { - fs_warn(sdp, "No other mounters found. Trying to recover our " - "own journal jid %d.\n", sdp->sd_lockstruct.ls_jid); - if (gfs2_recover_journal(sdp->sd_jdesc, 1)) - fs_warn(sdp, "Unable to recover our journal jid %d.\n", - sdp->sd_lockstruct.ls_jid); - gfs2_glock_dq_wait(&sdp->sd_live_gh); - gfs2_holder_reinit(LM_ST_SHARED, - LM_FLAG_NOEXP | GL_EXACT | GL_NOPID, - &sdp->sd_live_gh); - gfs2_glock_nq(&sdp->sd_live_gh); + fs_warn(sdp, "No other mounters found.\n"); + /* + * We are about to release the lockspace. By keeping live_gl + * locked here, we ensure that the next mounter coming along + * will be a "first" mounter which will perform recovery. + */ + goto skip_recovery; } - gfs2_glock_put(live_gl); /* drop extra reference we acquired */ - clear_bit(SDF_WITHDRAW_RECOVERY, &sdp->sd_flags); - /* * At this point our journal is evicted, so we need to get a new inode * for it. Once done, we need to call gfs2_find_jhead which -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 026/480] block: sanitize chunk_sectors for atomic write limits 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (24 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 025/480] gfs2: No more self recovery Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 027/480] io_uring: fix breakage in EXPERT menu Greg Kroah-Hartman ` (465 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Nilay Shroff, John Garry, Martin K. Petersen, Jens Axboe, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: John Garry <john.g.garry@oracle.com> [ Upstream commit 1de67e8e28fc47d71ee06ffa0185da549b378ffb ] Currently we just ensure that a non-zero value in chunk_sectors aligns with any atomic write boundary, as the blk boundary functionality uses both these values. However it is also improper to have atomic write unit max > chunk_sectors (for non-zero chunk_sectors), as this would lead to splitting of atomic write bios (which is disallowed). Sanitize atomic write unit max against chunk_sectors to avoid any potential problems. Fixes: d00eea91deaf3 ("block: Add extra checks in blk_validate_atomic_write_limits()") Reviewed-by: Nilay Shroff <nilay@linux.ibm.com> Signed-off-by: John Garry <john.g.garry@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Link: https://lore.kernel.org/r/20250711105258.3135198-3-john.g.garry@oracle.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org> --- block/blk-settings.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/block/blk-settings.c b/block/blk-settings.c index 4817e7ca03f8..d8c79e5112b4 100644 --- a/block/blk-settings.c +++ b/block/blk-settings.c @@ -186,6 +186,8 @@ static void blk_atomic_writes_update_limits(struct queue_limits *lim) static void blk_validate_atomic_write_limits(struct queue_limits *lim) { unsigned int boundary_sectors; + unsigned int atomic_write_hw_max_sectors = + lim->atomic_write_hw_max >> SECTOR_SHIFT; if (!(lim->features & BLK_FEAT_ATOMIC_WRITES)) goto unsupported; @@ -207,6 +209,10 @@ static void blk_validate_atomic_write_limits(struct queue_limits *lim) lim->atomic_write_hw_max)) goto unsupported; + if (WARN_ON_ONCE(lim->chunk_sectors && + atomic_write_hw_max_sectors > lim->chunk_sectors)) + goto unsupported; + boundary_sectors = lim->atomic_write_hw_boundary >> SECTOR_SHIFT; if (boundary_sectors) { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 027/480] io_uring: fix breakage in EXPERT menu 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (25 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 026/480] block: sanitize chunk_sectors for atomic write limits Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 028/480] btrfs: remove partial support for lowest level from btrfs_search_forward() Greg Kroah-Hartman ` (464 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Randy Dunlap, Jens Axboe, Andrew Morton, Masahiro Yamada, io-uring, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Randy Dunlap <rdunlap@infradead.org> [ Upstream commit d1fbe1ebf4a12cabd7945335d5e47718cb2bef99 ] Add a dependency for IO_URING for the GCOV_PROFILE_URING symbol. Without this patch the EXPERT config menu ends with "Enable IO uring support" and the menu prompts for GCOV_PROFILE_URING and IO_URING_MOCK_FILE are not subordinate to it. This causes all of the EXPERT Kconfig options that follow GCOV_PROFILE_URING to be display in the "upper" menu (General setup), just following the EXPERT menu. Fixes: 1802656ef890 ("io_uring: add GCOV_PROFILE_URING Kconfig option") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Jens Axboe <axboe@kernel.dk> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: io-uring@vger.kernel.org Link: https://lore.kernel.org/r/20250720010456.2945344-1-rdunlap@infradead.org Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org> --- init/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/init/Kconfig b/init/Kconfig index bf3a920064be..b2367239ac9d 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1761,7 +1761,7 @@ config IO_URING config GCOV_PROFILE_URING bool "Enable GCOV profiling on the io_uring subsystem" - depends on GCOV_KERNEL + depends on IO_URING && GCOV_KERNEL help Enable GCOV profiling on the io_uring subsystem, to facilitate code coverage testing. -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 028/480] btrfs: remove partial support for lowest level from btrfs_search_forward() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (26 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 027/480] io_uring: fix breakage in EXPERT menu Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 029/480] ASoC: soc-dai: tidyup return value of snd_soc_xlate_tdm_slot_mask() Greg Kroah-Hartman ` (463 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Qu Wenruo, Filipe Manana, Sun YangKai, David Sterba, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Sun YangKai <sunk67188@gmail.com> [ Upstream commit 27260dd1904bb409cf84709928ba9bc5506fbe8e ] Commit 323ac95bce44 ("Btrfs: don't read leaf blocks containing only checksums during truncate") changed the condition from `level == 0` to `level == path->lowest_level`, while its original purpose was just to do some leaf node handling (calling btrfs_item_key_to_cpu()) and skip some code that doesn't fit leaf nodes. After changing the condition, the code path: 1. Also handles the non-leaf nodes when path->lowest_level is nonzero, which is wrong. However btrfs_search_forward() is never called with a nonzero path->lowest_level, which makes this bug not found before. 2. Makes the later if block with the same condition, which was originally used to handle non-leaf node (calling btrfs_node_key_to_cpu()) when lowest_level is not zero, dead code. Since btrfs_search_forward() is never called for a path with a lowest_level different from zero, just completely remove the partial support for a non-zero lowest_level, simplifying a bit the code, and assert that lowest_level is zero at the start of the function. Suggested-by: Qu Wenruo <wqu@suse.com> Fixes: 323ac95bce44 ("Btrfs: don't read leaf blocks containing only checksums during truncate") Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Sun YangKai <sunk67188@gmail.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/btrfs/ctree.c | 18 +++++------------- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c index a2e7979372cc..648531fe0900 100644 --- a/fs/btrfs/ctree.c +++ b/fs/btrfs/ctree.c @@ -4585,16 +4585,13 @@ int btrfs_del_items(struct btrfs_trans_handle *trans, struct btrfs_root *root, /* * A helper function to walk down the tree starting at min_key, and looking - * for nodes or leaves that are have a minimum transaction id. + * for leaves that have a minimum transaction id. * This is used by the btree defrag code, and tree logging * * This does not cow, but it does stuff the starting key it finds back * into min_key, so you can call btrfs_search_slot with cow=1 on the * key and get a writable path. * - * This honors path->lowest_level to prevent descent past a given level - * of the tree. - * * min_trans indicates the oldest transaction that you are interested * in walking through. Any nodes or leaves older than min_trans are * skipped over (without reading them). @@ -4615,6 +4612,7 @@ int btrfs_search_forward(struct btrfs_root *root, struct btrfs_key *min_key, int keep_locks = path->keep_locks; ASSERT(!path->nowait); + ASSERT(path->lowest_level == 0); path->keep_locks = 1; again: cur = btrfs_read_lock_root_node(root); @@ -4636,8 +4634,8 @@ int btrfs_search_forward(struct btrfs_root *root, struct btrfs_key *min_key, goto out; } - /* at the lowest level, we're done, setup the path and exit */ - if (level == path->lowest_level) { + /* At level 0 we're done, setup the path and exit. */ + if (level == 0) { if (slot >= nritems) goto find_next_key; ret = 0; @@ -4678,12 +4676,6 @@ int btrfs_search_forward(struct btrfs_root *root, struct btrfs_key *min_key, goto out; } } - if (level == path->lowest_level) { - ret = 0; - /* Save our key for returning back. */ - btrfs_node_key_to_cpu(cur, min_key, slot); - goto out; - } cur = btrfs_read_node_slot(cur, slot); if (IS_ERR(cur)) { ret = PTR_ERR(cur); @@ -4699,7 +4691,7 @@ int btrfs_search_forward(struct btrfs_root *root, struct btrfs_key *min_key, out: path->keep_locks = keep_locks; if (ret == 0) - btrfs_unlock_up_safe(path, path->lowest_level + 1); + btrfs_unlock_up_safe(path, 1); return ret; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 029/480] ASoC: soc-dai: tidyup return value of snd_soc_xlate_tdm_slot_mask() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (27 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 028/480] btrfs: remove partial support for lowest level from btrfs_search_forward() Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 030/480] ASoC: amd: acp: Fix pointer assignments for snd_soc_acpi_mach structures Greg Kroah-Hartman ` (462 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Giedrius Trainavičius, Kuninori Morimoto, Mark Brown, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> [ Upstream commit f4c77d5af0a9cd0ee22617baa8b49d0e151fbda7 ] commit 7f1186a8d738661 ("ASoC: soc-dai: check return value at snd_soc_dai_set_tdm_slot()") checks return value of xlate_tdm_slot_mask() (A1)(A2). /* * ... (Y) * TDM mode can be disabled by passing 0 for @slots. In this case @tx_mask, * @rx_mask and @slot_width will be ignored. * ... */ int snd_soc_dai_set_tdm_slot(...) { ... if (...) (A1) ret = dai->driver->ops->xlate_tdm_slot_mask(...); else (A2) ret = snd_soc_xlate_tdm_slot_mask(...); if (ret) goto err; ... } snd_soc_xlate_tdm_slot_mask() (A2) will return -EINVAL if slots was 0 (X), but snd_soc_dai_set_tdm_slot() allow to use it (Y). (A) static int snd_soc_xlate_tdm_slot_mask(...) { ... if (!slots) (X) return -EINVAL; ... } Call xlate_tdm_slot_mask() only if slots was non zero. Reported-by: Giedrius Trainavičius <giedrius@blokas.io> Closes: https://lore.kernel.org/r/CAMONXLtSL7iKyvH6w=CzPTxQdBECf++hn8RKL6Y4=M_ou2YHow@mail.gmail.com Fixes: 7f1186a8d738661 ("ASoC: soc-dai: check return value at snd_soc_dai_set_tdm_slot()") Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/8734cdfx59.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- sound/soc/soc-dai.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/sound/soc/soc-dai.c b/sound/soc/soc-dai.c index a210089747d0..32f46a38682b 100644 --- a/sound/soc/soc-dai.c +++ b/sound/soc/soc-dai.c @@ -259,13 +259,15 @@ int snd_soc_dai_set_tdm_slot(struct snd_soc_dai *dai, &rx_mask, }; - if (dai->driver->ops && - dai->driver->ops->xlate_tdm_slot_mask) - ret = dai->driver->ops->xlate_tdm_slot_mask(slots, &tx_mask, &rx_mask); - else - ret = snd_soc_xlate_tdm_slot_mask(slots, &tx_mask, &rx_mask); - if (ret) - goto err; + if (slots) { + if (dai->driver->ops && + dai->driver->ops->xlate_tdm_slot_mask) + ret = dai->driver->ops->xlate_tdm_slot_mask(slots, &tx_mask, &rx_mask); + else + ret = snd_soc_xlate_tdm_slot_mask(slots, &tx_mask, &rx_mask); + if (ret) + goto err; + } for_each_pcm_streams(stream) snd_soc_dai_tdm_mask_set(dai, stream, *tdm_mask[stream]); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 030/480] ASoC: amd: acp: Fix pointer assignments for snd_soc_acpi_mach structures 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (28 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 029/480] ASoC: soc-dai: tidyup return value of snd_soc_xlate_tdm_slot_mask() Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:43 ` [PATCH 6.15 031/480] ASoC: ops: dynamically allocate struct snd_ctl_elem_value Greg Kroah-Hartman ` (461 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Venkata Prasad Potturu, Mark Brown, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Venkata Prasad Potturu <venkataprasad.potturu@amd.com> [ Upstream commit 0779c0ad2a7cc0ae1865860c9bc8732613cc56b1 ] This patch modifies the assignment of machine structure pointers in the acp_pci_probe function. Previously, the machine pointers were assigned using the address-of operator (&), which caused incompatibility issues in type assignments. Additionally, the declarations of the machine arrays in amd.h have been updated to reflect that they are indeed arrays (`[]`). The code is further cleaned up by declaring the codec structures in amd-acpi-mach.c as static, reflecting their intended usage. error: symbol 'amp_rt1019' was not declared. Should it be static? error: symbol 'amp_max' was not declared. Should it be static? error: symbol 'snd_soc_acpi_amd_acp_machines' was not declared. Should it be static? error: symbol 'snd_soc_acpi_amd_rmb_acp_machines' was not declared. Should it be static? error: symbol 'snd_soc_acpi_amd_acp63_acp_machines' was not declared. Should it be static? error: symbol 'snd_soc_acpi_amd_acp70_acp_machines' was not declared. Should it be static? Fixes: 9c2c0ef64009 ("ASoC: amd: acp: Fix snd_soc_acpi_mach id's duplicate symbol error") Link: https://github.com/thesofproject/linux/issues/5438 Signed-off-by: Venkata Prasad Potturu <venkataprasad.potturu@amd.com> Link: https://patch.msgid.link/20250609121251.639080-1-venkataprasad.potturu@amd.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- sound/soc/amd/acp/acp-pci.c | 8 ++++---- sound/soc/amd/acp/amd-acpi-mach.c | 4 ++-- sound/soc/amd/acp/amd.h | 8 ++++---- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/sound/soc/amd/acp/acp-pci.c b/sound/soc/amd/acp/acp-pci.c index 0b2aa33cc426..2591b1a1c5e0 100644 --- a/sound/soc/amd/acp/acp-pci.c +++ b/sound/soc/amd/acp/acp-pci.c @@ -137,26 +137,26 @@ static int acp_pci_probe(struct pci_dev *pci, const struct pci_device_id *pci_id chip->name = "acp_asoc_renoir"; chip->rsrc = &rn_rsrc; chip->acp_hw_ops_init = acp31_hw_ops_init; - chip->machines = &snd_soc_acpi_amd_acp_machines; + chip->machines = snd_soc_acpi_amd_acp_machines; break; case 0x6f: chip->name = "acp_asoc_rembrandt"; chip->rsrc = &rmb_rsrc; chip->acp_hw_ops_init = acp6x_hw_ops_init; - chip->machines = &snd_soc_acpi_amd_rmb_acp_machines; + chip->machines = snd_soc_acpi_amd_rmb_acp_machines; break; case 0x63: chip->name = "acp_asoc_acp63"; chip->rsrc = &acp63_rsrc; chip->acp_hw_ops_init = acp63_hw_ops_init; - chip->machines = &snd_soc_acpi_amd_acp63_acp_machines; + chip->machines = snd_soc_acpi_amd_acp63_acp_machines; break; case 0x70: case 0x71: chip->name = "acp_asoc_acp70"; chip->rsrc = &acp70_rsrc; chip->acp_hw_ops_init = acp70_hw_ops_init; - chip->machines = &snd_soc_acpi_amd_acp70_acp_machines; + chip->machines = snd_soc_acpi_amd_acp70_acp_machines; break; default: dev_err(dev, "Unsupported device revision:0x%x\n", pci->revision); diff --git a/sound/soc/amd/acp/amd-acpi-mach.c b/sound/soc/amd/acp/amd-acpi-mach.c index d95047d2ee94..27da2a862f1c 100644 --- a/sound/soc/amd/acp/amd-acpi-mach.c +++ b/sound/soc/amd/acp/amd-acpi-mach.c @@ -8,12 +8,12 @@ #include <sound/soc-acpi.h> -struct snd_soc_acpi_codecs amp_rt1019 = { +static struct snd_soc_acpi_codecs amp_rt1019 = { .num_codecs = 1, .codecs = {"10EC1019"} }; -struct snd_soc_acpi_codecs amp_max = { +static struct snd_soc_acpi_codecs amp_max = { .num_codecs = 1, .codecs = {"MX98360A"} }; diff --git a/sound/soc/amd/acp/amd.h b/sound/soc/amd/acp/amd.h index 863e74fcee43..cb8d97122f95 100644 --- a/sound/soc/amd/acp/amd.h +++ b/sound/soc/amd/acp/amd.h @@ -243,10 +243,10 @@ extern struct acp_resource rmb_rsrc; extern struct acp_resource acp63_rsrc; extern struct acp_resource acp70_rsrc; -extern struct snd_soc_acpi_mach snd_soc_acpi_amd_acp_machines; -extern struct snd_soc_acpi_mach snd_soc_acpi_amd_rmb_acp_machines; -extern struct snd_soc_acpi_mach snd_soc_acpi_amd_acp63_acp_machines; -extern struct snd_soc_acpi_mach snd_soc_acpi_amd_acp70_acp_machines; +extern struct snd_soc_acpi_mach snd_soc_acpi_amd_acp_machines[]; +extern struct snd_soc_acpi_mach snd_soc_acpi_amd_rmb_acp_machines[]; +extern struct snd_soc_acpi_mach snd_soc_acpi_amd_acp63_acp_machines[]; +extern struct snd_soc_acpi_mach snd_soc_acpi_amd_acp70_acp_machines[]; extern const struct snd_soc_dai_ops asoc_acp_cpu_dai_ops; extern const struct snd_soc_dai_ops acp_dmic_dai_ops; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 031/480] ASoC: ops: dynamically allocate struct snd_ctl_elem_value 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (29 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 030/480] ASoC: amd: acp: Fix pointer assignments for snd_soc_acpi_mach structures Greg Kroah-Hartman @ 2025-08-12 17:43 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 032/480] ASoC: mediatek: use reserved memory or enable buffer pre-allocation Greg Kroah-Hartman ` (460 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:43 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Arnd Bergmann, Mark Brown, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Arnd Bergmann <arnd@arndb.de> [ Upstream commit 7e10d7242ea8a5947878880b912ffa5806520705 ] This structure is really too larget to be allocated on the stack: sound/soc/soc-ops.c:435:5: error: stack frame size (1296) exceeds limit (1280) in 'snd_soc_limit_volume' [-Werror,-Wframe-larger-than] Change the function to dynamically allocate it instead. There is probably a better way to do it since only two integer fields inside of that structure are actually used, but this is the simplest rework for the moment. Fixes: 783db6851c18 ("ASoC: ops: Enforce platform maximum on initial value") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20250610093057.2643233-1-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- sound/soc/soc-ops.c | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/sound/soc/soc-ops.c b/sound/soc/soc-ops.c index 8d4dd11c9aef..a629e0eacb20 100644 --- a/sound/soc/soc-ops.c +++ b/sound/soc/soc-ops.c @@ -399,28 +399,32 @@ EXPORT_SYMBOL_GPL(snd_soc_put_volsw_sx); static int snd_soc_clip_to_platform_max(struct snd_kcontrol *kctl) { struct soc_mixer_control *mc = (struct soc_mixer_control *)kctl->private_value; - struct snd_ctl_elem_value uctl; + struct snd_ctl_elem_value *uctl; int ret; if (!mc->platform_max) return 0; - ret = kctl->get(kctl, &uctl); + uctl = kzalloc(sizeof(*uctl), GFP_KERNEL); + if (!uctl) + return -ENOMEM; + + ret = kctl->get(kctl, uctl); if (ret < 0) - return ret; + goto out; - if (uctl.value.integer.value[0] > mc->platform_max) - uctl.value.integer.value[0] = mc->platform_max; + if (uctl->value.integer.value[0] > mc->platform_max) + uctl->value.integer.value[0] = mc->platform_max; if (snd_soc_volsw_is_stereo(mc) && - uctl.value.integer.value[1] > mc->platform_max) - uctl.value.integer.value[1] = mc->platform_max; + uctl->value.integer.value[1] > mc->platform_max) + uctl->value.integer.value[1] = mc->platform_max; - ret = kctl->put(kctl, &uctl); - if (ret < 0) - return ret; + ret = kctl->put(kctl, uctl); - return 0; +out: + kfree(uctl); + return ret; } /** -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 032/480] ASoC: mediatek: use reserved memory or enable buffer pre-allocation 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (30 preceding siblings ...) 2025-08-12 17:43 ` [PATCH 6.15 031/480] ASoC: ops: dynamically allocate struct snd_ctl_elem_value Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 033/480] arm64: dts: freescale: imx93-tqma9352: Limit BUCK2 to 600mV Greg Kroah-Hartman ` (459 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, AngeloGioacchino Del Regno, Chen-Yu Tsai, Mark Brown, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Chen-Yu Tsai <wenst@chromium.org> [ Upstream commit ec4a10ca4a68ec97f12f4d17d7abb74db34987db ] In commit 32c9c06adb5b ("ASoC: mediatek: disable buffer pre-allocation") buffer pre-allocation was disabled to accommodate newer platforms that have a limited reserved memory region for the audio frontend. Turns out disabling pre-allocation across the board impacts platforms that don't have this reserved memory region. Buffer allocation failures have been observed on MT8173 and MT8183 based Chromebooks under low memory conditions, which results in no audio playback for the user. Since some MediaTek platforms already have dedicated reserved memory pools for the audio frontend, the plan is to enable this for all of them. This requires device tree changes. As a fallback, reinstate the original policy of pre-allocating audio buffers at probe time of the reserved memory pool cannot be found or used. This patch covers the MT8173, MT8183, MT8186 and MT8192 platforms for now, the reason being that existing MediaTek platform drivers that supported reserved memory were all platforms that mainly supported ChromeOS, and is also the set of devices that I can verify. Fixes: 32c9c06adb5b ("ASoC: mediatek: disable buffer pre-allocation") Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://patch.msgid.link/20250612074901.4023253-7-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- sound/soc/mediatek/common/mtk-afe-platform-driver.c | 4 +++- sound/soc/mediatek/common/mtk-base-afe.h | 1 + sound/soc/mediatek/mt8173/mt8173-afe-pcm.c | 7 +++++++ sound/soc/mediatek/mt8183/mt8183-afe-pcm.c | 7 +++++++ sound/soc/mediatek/mt8186/mt8186-afe-pcm.c | 7 +++++++ sound/soc/mediatek/mt8192/mt8192-afe-pcm.c | 7 +++++++ 6 files changed, 32 insertions(+), 1 deletion(-) diff --git a/sound/soc/mediatek/common/mtk-afe-platform-driver.c b/sound/soc/mediatek/common/mtk-afe-platform-driver.c index 6b6330583941..70fd05d5ff48 100644 --- a/sound/soc/mediatek/common/mtk-afe-platform-driver.c +++ b/sound/soc/mediatek/common/mtk-afe-platform-driver.c @@ -120,7 +120,9 @@ int mtk_afe_pcm_new(struct snd_soc_component *component, struct mtk_base_afe *afe = snd_soc_component_get_drvdata(component); size = afe->mtk_afe_hardware->buffer_bytes_max; - snd_pcm_set_managed_buffer_all(pcm, SNDRV_DMA_TYPE_DEV, afe->dev, 0, size); + snd_pcm_set_managed_buffer_all(pcm, SNDRV_DMA_TYPE_DEV, afe->dev, + afe->preallocate_buffers ? size : 0, + size); return 0; } diff --git a/sound/soc/mediatek/common/mtk-base-afe.h b/sound/soc/mediatek/common/mtk-base-afe.h index f51578b6c50a..a406f2e3e7a8 100644 --- a/sound/soc/mediatek/common/mtk-base-afe.h +++ b/sound/soc/mediatek/common/mtk-base-afe.h @@ -117,6 +117,7 @@ struct mtk_base_afe { struct mtk_base_afe_irq *irqs; int irqs_size; int memif_32bit_supported; + bool preallocate_buffers; struct list_head sub_dais; struct snd_soc_dai_driver *dai_drivers; diff --git a/sound/soc/mediatek/mt8173/mt8173-afe-pcm.c b/sound/soc/mediatek/mt8173/mt8173-afe-pcm.c index 04ed0cfec174..f93d6348fdf8 100644 --- a/sound/soc/mediatek/mt8173/mt8173-afe-pcm.c +++ b/sound/soc/mediatek/mt8173/mt8173-afe-pcm.c @@ -13,6 +13,7 @@ #include <linux/module.h> #include <linux/of.h> #include <linux/of_address.h> +#include <linux/of_reserved_mem.h> #include <linux/dma-mapping.h> #include <linux/pm_runtime.h> #include <sound/soc.h> @@ -1070,6 +1071,12 @@ static int mt8173_afe_pcm_dev_probe(struct platform_device *pdev) afe->dev = &pdev->dev; + ret = of_reserved_mem_device_init(&pdev->dev); + if (ret) { + dev_info(&pdev->dev, "no reserved memory found, pre-allocating buffers instead\n"); + afe->preallocate_buffers = true; + } + irq_id = platform_get_irq(pdev, 0); if (irq_id <= 0) return irq_id < 0 ? irq_id : -ENXIO; diff --git a/sound/soc/mediatek/mt8183/mt8183-afe-pcm.c b/sound/soc/mediatek/mt8183/mt8183-afe-pcm.c index d083b4bf0f95..e7378bee8e50 100644 --- a/sound/soc/mediatek/mt8183/mt8183-afe-pcm.c +++ b/sound/soc/mediatek/mt8183/mt8183-afe-pcm.c @@ -10,6 +10,7 @@ #include <linux/mfd/syscon.h> #include <linux/of.h> #include <linux/of_address.h> +#include <linux/of_reserved_mem.h> #include <linux/pm_runtime.h> #include <linux/reset.h> @@ -1094,6 +1095,12 @@ static int mt8183_afe_pcm_dev_probe(struct platform_device *pdev) afe->dev = &pdev->dev; dev = afe->dev; + ret = of_reserved_mem_device_init(dev); + if (ret) { + dev_info(dev, "no reserved memory found, pre-allocating buffers instead\n"); + afe->preallocate_buffers = true; + } + /* initial audio related clock */ ret = mt8183_init_clock(afe); if (ret) { diff --git a/sound/soc/mediatek/mt8186/mt8186-afe-pcm.c b/sound/soc/mediatek/mt8186/mt8186-afe-pcm.c index db7c93401bee..c73b4664e53e 100644 --- a/sound/soc/mediatek/mt8186/mt8186-afe-pcm.c +++ b/sound/soc/mediatek/mt8186/mt8186-afe-pcm.c @@ -10,6 +10,7 @@ #include <linux/module.h> #include <linux/of.h> #include <linux/of_address.h> +#include <linux/of_reserved_mem.h> #include <linux/pm_runtime.h> #include <linux/reset.h> #include <sound/soc.h> @@ -2835,6 +2836,12 @@ static int mt8186_afe_pcm_dev_probe(struct platform_device *pdev) afe_priv = afe->platform_priv; afe->dev = &pdev->dev; + ret = of_reserved_mem_device_init(dev); + if (ret) { + dev_info(dev, "no reserved memory found, pre-allocating buffers instead\n"); + afe->preallocate_buffers = true; + } + afe->base_addr = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(afe->base_addr)) return PTR_ERR(afe->base_addr); diff --git a/sound/soc/mediatek/mt8192/mt8192-afe-pcm.c b/sound/soc/mediatek/mt8192/mt8192-afe-pcm.c index fd6af74d7995..3d32fe46118e 100644 --- a/sound/soc/mediatek/mt8192/mt8192-afe-pcm.c +++ b/sound/soc/mediatek/mt8192/mt8192-afe-pcm.c @@ -12,6 +12,7 @@ #include <linux/mfd/syscon.h> #include <linux/of.h> #include <linux/of_address.h> +#include <linux/of_reserved_mem.h> #include <linux/pm_runtime.h> #include <linux/reset.h> #include <sound/soc.h> @@ -2179,6 +2180,12 @@ static int mt8192_afe_pcm_dev_probe(struct platform_device *pdev) afe->dev = dev; + ret = of_reserved_mem_device_init(dev); + if (ret) { + dev_info(dev, "no reserved memory found, pre-allocating buffers instead\n"); + afe->preallocate_buffers = true; + } + /* init audio related clock */ ret = mt8192_init_clock(afe); if (ret) { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 033/480] arm64: dts: freescale: imx93-tqma9352: Limit BUCK2 to 600mV 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (31 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 032/480] ASoC: mediatek: use reserved memory or enable buffer pre-allocation Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 034/480] selftests: Fix errno checking in syscall_user_dispatch test Greg Kroah-Hartman ` (458 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Alexander Stein, Peng Fan, Shawn Guo, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Alexander Stein <alexander.stein@ew.tq-group.com> [ Upstream commit 696a4c325fad8af95da6a9d797766d1613831622 ] TQMa9352 is only using LPDDR4X, so the BUCK2 regulator should be fixed at 600MV. Fixes: d2858e6bd36c ("arm64: dts: freescale: imx93-tqma9352: Add PMIC node") Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Acked-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm64/boot/dts/freescale/imx93-tqma9352.dtsi | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx93-tqma9352.dtsi b/arch/arm64/boot/dts/freescale/imx93-tqma9352.dtsi index 2cabdae24227..09385b058664 100644 --- a/arch/arm64/boot/dts/freescale/imx93-tqma9352.dtsi +++ b/arch/arm64/boot/dts/freescale/imx93-tqma9352.dtsi @@ -1,6 +1,6 @@ // SPDX-License-Identifier: (GPL-2.0-or-later OR MIT) /* - * Copyright (c) 2022 TQ-Systems GmbH <linux@ew.tq-group.com>, + * Copyright (c) 2022-2025 TQ-Systems GmbH <linux@ew.tq-group.com>, * D-82229 Seefeld, Germany. * Author: Markus Niebel */ @@ -110,11 +110,11 @@ buck1: BUCK1 { regulator-ramp-delay = <3125>; }; - /* V_DDRQ - 1.1 LPDDR4 or 0.6 LPDDR4X */ + /* V_DDRQ - 0.6 V for LPDDR4X */ buck2: BUCK2 { regulator-name = "BUCK2"; regulator-min-microvolt = <600000>; - regulator-max-microvolt = <1100000>; + regulator-max-microvolt = <600000>; regulator-boot-on; regulator-always-on; regulator-ramp-delay = <3125>; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 034/480] selftests: Fix errno checking in syscall_user_dispatch test 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (32 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 033/480] arm64: dts: freescale: imx93-tqma9352: Limit BUCK2 to 600mV Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 035/480] soc: qcom: QMI encoding/decoding for big endian Greg Kroah-Hartman ` (457 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Dmitry Vyukov, Thomas Gleixner, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Dmitry Vyukov <dvyukov@google.com> [ Upstream commit b89732c8c8357487185f260a723a060b3476144e ] Successful syscalls don't change errno, so checking errno is wrong to ensure that a syscall has failed. For example for the following sequence: prctl(PR_SET_SYSCALL_USER_DISPATCH, op, 0x0, 0xff, 0); EXPECT_EQ(EINVAL, errno); prctl(PR_SET_SYSCALL_USER_DISPATCH, op, 0x0, 0x0, &sel); EXPECT_EQ(EINVAL, errno); only the first syscall may fail and set errno, but the second may succeed and keep errno intact, and the check will falsely pass. Or if errno happened to be EINVAL before, even the first check may falsely pass. Also use EXPECT/ASSERT consistently. Currently there is an inconsistent mix without obvious reasons for usage of one or another. Fixes: 179ef035992e ("selftests: Add kselftest for syscall user dispatch") Signed-off-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/af6a04dbfef9af8570f5bab43e3ef1416b62699a.1747839857.git.dvyukov@google.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- .../syscall_user_dispatch/sud_test.c | 50 +++++++++---------- 1 file changed, 25 insertions(+), 25 deletions(-) diff --git a/tools/testing/selftests/syscall_user_dispatch/sud_test.c b/tools/testing/selftests/syscall_user_dispatch/sud_test.c index d975a6767329..48cf01aeec3e 100644 --- a/tools/testing/selftests/syscall_user_dispatch/sud_test.c +++ b/tools/testing/selftests/syscall_user_dispatch/sud_test.c @@ -79,6 +79,21 @@ TEST_SIGNAL(dispatch_trigger_sigsys, SIGSYS) } } +static void prctl_valid(struct __test_metadata *_metadata, + unsigned long op, unsigned long off, + unsigned long size, void *sel) +{ + EXPECT_EQ(0, prctl(PR_SET_SYSCALL_USER_DISPATCH, op, off, size, sel)); +} + +static void prctl_invalid(struct __test_metadata *_metadata, + unsigned long op, unsigned long off, + unsigned long size, void *sel, int err) +{ + EXPECT_EQ(-1, prctl(PR_SET_SYSCALL_USER_DISPATCH, op, off, size, sel)); + EXPECT_EQ(err, errno); +} + TEST(bad_prctl_param) { char sel = SYSCALL_DISPATCH_FILTER_ALLOW; @@ -86,57 +101,42 @@ TEST(bad_prctl_param) /* Invalid op */ op = -1; - prctl(PR_SET_SYSCALL_USER_DISPATCH, op, 0, 0, &sel); - ASSERT_EQ(EINVAL, errno); + prctl_invalid(_metadata, op, 0, 0, &sel, EINVAL); /* PR_SYS_DISPATCH_OFF */ op = PR_SYS_DISPATCH_OFF; /* offset != 0 */ - prctl(PR_SET_SYSCALL_USER_DISPATCH, op, 0x1, 0x0, 0); - EXPECT_EQ(EINVAL, errno); + prctl_invalid(_metadata, op, 0x1, 0x0, 0, EINVAL); /* len != 0 */ - prctl(PR_SET_SYSCALL_USER_DISPATCH, op, 0x0, 0xff, 0); - EXPECT_EQ(EINVAL, errno); + prctl_invalid(_metadata, op, 0x0, 0xff, 0, EINVAL); /* sel != NULL */ - prctl(PR_SET_SYSCALL_USER_DISPATCH, op, 0x0, 0x0, &sel); - EXPECT_EQ(EINVAL, errno); + prctl_invalid(_metadata, op, 0x0, 0x0, &sel, EINVAL); /* Valid parameter */ - errno = 0; - prctl(PR_SET_SYSCALL_USER_DISPATCH, op, 0x0, 0x0, 0x0); - EXPECT_EQ(0, errno); + prctl_valid(_metadata, op, 0x0, 0x0, 0x0); /* PR_SYS_DISPATCH_ON */ op = PR_SYS_DISPATCH_ON; /* Dispatcher region is bad (offset > 0 && len == 0) */ - prctl(PR_SET_SYSCALL_USER_DISPATCH, op, 0x1, 0x0, &sel); - EXPECT_EQ(EINVAL, errno); - prctl(PR_SET_SYSCALL_USER_DISPATCH, op, -1L, 0x0, &sel); - EXPECT_EQ(EINVAL, errno); + prctl_invalid(_metadata, op, 0x1, 0x0, &sel, EINVAL); + prctl_invalid(_metadata, op, -1L, 0x0, &sel, EINVAL); /* Invalid selector */ - prctl(PR_SET_SYSCALL_USER_DISPATCH, op, 0x0, 0x1, (void *) -1); - ASSERT_EQ(EFAULT, errno); + prctl_invalid(_metadata, op, 0x0, 0x1, (void *) -1, EFAULT); /* * Dispatcher range overflows unsigned long */ - prctl(PR_SET_SYSCALL_USER_DISPATCH, PR_SYS_DISPATCH_ON, 1, -1L, &sel); - ASSERT_EQ(EINVAL, errno) { - TH_LOG("Should reject bad syscall range"); - } + prctl_invalid(_metadata, PR_SYS_DISPATCH_ON, 1, -1L, &sel, EINVAL); /* * Allowed range overflows usigned long */ - prctl(PR_SET_SYSCALL_USER_DISPATCH, PR_SYS_DISPATCH_ON, -1L, 0x1, &sel); - ASSERT_EQ(EINVAL, errno) { - TH_LOG("Should reject bad syscall range"); - } + prctl_invalid(_metadata, PR_SYS_DISPATCH_ON, -1L, 0x1, &sel, EINVAL); } /* -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 035/480] soc: qcom: QMI encoding/decoding for big endian 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (33 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 034/480] selftests: Fix errno checking in syscall_user_dispatch test Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 036/480] arm64: dts: qcom: qcs615: fix a crash issue caused by infinite loop for Coresight Greg Kroah-Hartman ` (456 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Alexander Wilhelm, Dmitry Baryshkov, Bjorn Andersson, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Alexander Wilhelm <alexander.wilhelm@westermo.com> [ Upstream commit 3ced38da5f7de4c260f9eaa86fc805827953243a ] The QMI_DATA_LEN type may have different sizes. Taking the element's address of that type and interpret it as a smaller sized ones works fine for little endian platforms but not for big endian ones. Instead use temporary variables of smaller sized types and cast them correctly to support big endian platforms. Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com> Fixes: 9b8a11e82615 ("soc: qcom: Introduce QMI encoder/decoder") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250522143530.3623809-2-alexander.wilhelm@westermo.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/soc/qcom/qmi_encdec.c | 46 +++++++++++++++++++++++++++++------ 1 file changed, 38 insertions(+), 8 deletions(-) diff --git a/drivers/soc/qcom/qmi_encdec.c b/drivers/soc/qcom/qmi_encdec.c index bb09eff85cff..dafe0a4c202e 100644 --- a/drivers/soc/qcom/qmi_encdec.c +++ b/drivers/soc/qcom/qmi_encdec.c @@ -304,6 +304,8 @@ static int qmi_encode(const struct qmi_elem_info *ei_array, void *out_buf, const void *buf_src; int encode_tlv = 0; int rc; + u8 val8; + u16 val16; if (!ei_array) return 0; @@ -338,7 +340,6 @@ static int qmi_encode(const struct qmi_elem_info *ei_array, void *out_buf, break; case QMI_DATA_LEN: - memcpy(&data_len_value, buf_src, temp_ei->elem_size); data_len_sz = temp_ei->elem_size == sizeof(u8) ? sizeof(u8) : sizeof(u16); /* Check to avoid out of range buffer access */ @@ -348,8 +349,17 @@ static int qmi_encode(const struct qmi_elem_info *ei_array, void *out_buf, __func__); return -ETOOSMALL; } - rc = qmi_encode_basic_elem(buf_dst, &data_len_value, - 1, data_len_sz); + if (data_len_sz == sizeof(u8)) { + val8 = *(u8 *)buf_src; + data_len_value = (u32)val8; + rc = qmi_encode_basic_elem(buf_dst, &val8, + 1, data_len_sz); + } else { + val16 = *(u16 *)buf_src; + data_len_value = (u32)le16_to_cpu(val16); + rc = qmi_encode_basic_elem(buf_dst, &val16, + 1, data_len_sz); + } UPDATE_ENCODE_VARIABLES(temp_ei, buf_dst, encoded_bytes, tlv_len, encode_tlv, rc); @@ -523,14 +533,23 @@ static int qmi_decode_string_elem(const struct qmi_elem_info *ei_array, u32 string_len = 0; u32 string_len_sz = 0; const struct qmi_elem_info *temp_ei = ei_array; + u8 val8; + u16 val16; if (dec_level == 1) { string_len = tlv_len; } else { string_len_sz = temp_ei->elem_len <= U8_MAX ? sizeof(u8) : sizeof(u16); - rc = qmi_decode_basic_elem(&string_len, buf_src, - 1, string_len_sz); + if (string_len_sz == sizeof(u8)) { + rc = qmi_decode_basic_elem(&val8, buf_src, + 1, string_len_sz); + string_len = (u32)val8; + } else { + rc = qmi_decode_basic_elem(&val16, buf_src, + 1, string_len_sz); + string_len = (u32)val16; + } decoded_bytes += rc; } @@ -604,6 +623,9 @@ static int qmi_decode(const struct qmi_elem_info *ei_array, void *out_c_struct, u32 decoded_bytes = 0; const void *buf_src = in_buf; int rc; + u8 val8; + u16 val16; + u32 val32; while (decoded_bytes < in_buf_len) { if (dec_level >= 2 && temp_ei->data_type == QMI_EOTI) @@ -642,9 +664,17 @@ static int qmi_decode(const struct qmi_elem_info *ei_array, void *out_c_struct, if (temp_ei->data_type == QMI_DATA_LEN) { data_len_sz = temp_ei->elem_size == sizeof(u8) ? sizeof(u8) : sizeof(u16); - rc = qmi_decode_basic_elem(&data_len_value, buf_src, - 1, data_len_sz); - memcpy(buf_dst, &data_len_value, sizeof(u32)); + if (data_len_sz == sizeof(u8)) { + rc = qmi_decode_basic_elem(&val8, buf_src, + 1, data_len_sz); + data_len_value = (u32)val8; + } else { + rc = qmi_decode_basic_elem(&val16, buf_src, + 1, data_len_sz); + data_len_value = (u32)val16; + } + val32 = cpu_to_le32(data_len_value); + memcpy(buf_dst, &val32, sizeof(u32)); temp_ei = temp_ei + 1; buf_dst = out_c_struct + temp_ei->offset; tlv_len -= data_len_sz; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 036/480] arm64: dts: qcom: qcs615: fix a crash issue caused by infinite loop for Coresight 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (34 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 035/480] soc: qcom: QMI encoding/decoding for big endian Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 037/480] arm64: dts: qcom: sdm845: Expand IMEM region Greg Kroah-Hartman ` (455 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Jie Gan, Suzuki K Poulose, Bjorn Andersson, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jie Gan <jie.gan@oss.qualcomm.com> [ Upstream commit bd4f35786d5f0798cc1f8c187a81a7c998e6c58f ] An infinite loop has been created by the Coresight devices. When only a source device is enabled, the coresight_find_activated_sysfs_sink function is recursively invoked in an attempt to locate an active sink device, ultimately leading to a stack overflow and system crash. Therefore, disable the replicator1 to break the infinite loop and prevent a potential stack overflow. replicator1_out -> funnel_swao_in6 -> tmc_etf_swao_in -> tmc_etf_swao_out | | replicator1_in replicator_swao_in | | replicator0_out1 replicator_swao_out0 | | replicator0_in funnel_in1_in3 | | tmc_etf_out <- tmc_etf_in <- funnel_merg_out <- funnel_merg_in1 <- funnel_in1_out [call trace] dump_backtrace+0x9c/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x48/0x60 dump_stack+0x18/0x28 panic+0x340/0x3b0 nmi_panic+0x94/0xa0 panic_bad_stack+0x114/0x138 handle_bad_stack+0x34/0xb8 __bad_stack+0x78/0x80 coresight_find_activated_sysfs_sink+0x28/0xa0 [coresight] coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight] coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight] coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight] coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight] ... coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight] coresight_enable_sysfs+0x80/0x2a0 [coresight] side effect after the change: Only trace data originating from AOSS can reach the ETF_SWAO and EUD sinks. Fixes: bf469630552a ("arm64: dts: qcom: qcs615: Add coresight nodes") Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com> Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20250522005016.2148-1-jie.gan@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm64/boot/dts/qcom/qcs615.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/qcom/qcs615.dtsi b/arch/arm64/boot/dts/qcom/qcs615.dtsi index 120654849043..e1f510e5485c 100644 --- a/arch/arm64/boot/dts/qcom/qcs615.dtsi +++ b/arch/arm64/boot/dts/qcom/qcs615.dtsi @@ -1868,6 +1868,7 @@ replicator@604a000 { clocks = <&aoss_qmp>; clock-names = "apb_pclk"; + status = "disabled"; in-ports { port { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 037/480] arm64: dts: qcom: sdm845: Expand IMEM region 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (35 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 036/480] arm64: dts: qcom: qcs615: fix a crash issue caused by infinite loop for Coresight Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 038/480] arm64: dts: qcom: sc7180: " Greg Kroah-Hartman ` (454 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Konrad Dybcio, Dmitry Baryshkov, Bjorn Andersson, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> [ Upstream commit 81a4a7de3d4031e77b5796479ef21aefb0862807 ] We need more than what is currently described, expand the region to its actual boundaries. Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Fixes: 948f6161c6ab ("arm64: dts: qcom: sdm845: Add IMEM and PIL info region") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250523-topic-ipa_mem_dts-v1-2-f7aa94fac1ab@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi index d0314cdf0b92..0e6ec2c54c24 100644 --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi @@ -5078,18 +5078,18 @@ spmi_bus: spmi@c440000 { #interrupt-cells = <4>; }; - sram@146bf000 { + sram@14680000 { compatible = "qcom,sdm845-imem", "syscon", "simple-mfd"; - reg = <0 0x146bf000 0 0x1000>; + reg = <0 0x14680000 0 0x40000>; #address-cells = <1>; #size-cells = <1>; - ranges = <0 0 0x146bf000 0x1000>; + ranges = <0 0 0x14680000 0x40000>; - pil-reloc@94c { + pil-reloc@3f94c { compatible = "qcom,pil-reloc-info"; - reg = <0x94c 0xc8>; + reg = <0x3f94c 0xc8>; }; }; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 038/480] arm64: dts: qcom: sc7180: Expand IMEM region 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (36 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 037/480] arm64: dts: qcom: sdm845: Expand IMEM region Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 039/480] arm64: dts: qcom: qcs615: disable the CTI device of the camera block Greg Kroah-Hartman ` (453 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Konrad Dybcio, Dmitry Baryshkov, Bjorn Andersson, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> [ Upstream commit 965e28cad4739b11f1bc58c0a9935e025938bb1f ] We need more than what is currently described, expand the region to its actual boundaries. Fixes: ede638c42c82 ("arm64: dts: qcom: sc7180: Add IMEM and pil info regions") Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250523-topic-ipa_mem_dts-v1-3-f7aa94fac1ab@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm64/boot/dts/qcom/sc7180.dtsi | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi index 87c432c12a24..7dddafa901d8 100644 --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi @@ -3523,18 +3523,18 @@ spmi_bus: spmi@c440000 { #interrupt-cells = <4>; }; - sram@146aa000 { + sram@14680000 { compatible = "qcom,sc7180-imem", "syscon", "simple-mfd"; - reg = <0 0x146aa000 0 0x2000>; + reg = <0 0x14680000 0 0x2e000>; #address-cells = <1>; #size-cells = <1>; - ranges = <0 0 0x146aa000 0x2000>; + ranges = <0 0 0x14680000 0x2e000>; - pil-reloc@94c { + pil-reloc@2a94c { compatible = "qcom,pil-reloc-info"; - reg = <0x94c 0xc8>; + reg = <0x2a94c 0xc8>; }; }; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 039/480] arm64: dts: qcom: qcs615: disable the CTI device of the camera block 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (37 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 038/480] arm64: dts: qcom: sc7180: " Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 040/480] arm64: dts: exynos: gs101: Add local-timer-stop to cpuidle nodes Greg Kroah-Hartman ` (452 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Jie Gan, Konrad Dybcio, Bjorn Andersson, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jie Gan <jie.gan@oss.qualcomm.com> [ Upstream commit 1b7fc8a281cae9e3176584558a4ac551ce0f777d ] Disable the CTI device of the camera block to prevent potential NoC errors during AMBA bus device matching. The clocks for the Qualcomm Debug Subsystem (QDSS) are managed by aoss_qmp through a mailbox. However, the camera block resides outside the AP domain, meaning its QDSS clock cannot be controlled via aoss_qmp. Fixes: bf469630552a ("arm64: dts: qcom: qcs615: Add coresight nodes") Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250611030003.3801-1-jie.gan@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm64/boot/dts/qcom/qcs615.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/qcs615.dtsi b/arch/arm64/boot/dts/qcom/qcs615.dtsi index e1f510e5485c..3fda88b32a71 100644 --- a/arch/arm64/boot/dts/qcom/qcs615.dtsi +++ b/arch/arm64/boot/dts/qcom/qcs615.dtsi @@ -2428,6 +2428,9 @@ cti@6c13000 { clocks = <&aoss_qmp>; clock-names = "apb_pclk"; + + /* Not all required clocks can be enabled from the OS */ + status = "fail"; }; cti@6c20000 { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 040/480] arm64: dts: exynos: gs101: Add local-timer-stop to cpuidle nodes 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (38 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 039/480] arm64: dts: qcom: qcs615: disable the CTI device of the camera block Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 041/480] arm64: dts: qcom: sa8775p: Correct the interrupt for remoteproc Greg Kroah-Hartman ` (451 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Will Deacon, Will McVicker, Youngmin Nam, Peter Griffin, Krzysztof Kozlowski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Will Deacon <willdeacon@google.com> [ Upstream commit b649082312dd1a4c3989bbdb7c25eb711e9b1d94 ] In preparation for switching to the architected timer as the primary clockevents device, mark the cpuidle nodes with the 'local-timer-stop' property to indicate that an alternative clockevents device must be used for waking up from the "c2" idle state. Signed-off-by: Will Deacon <willdeacon@google.com> [Original commit from https://android.googlesource.com/kernel/gs/+/a896fd98638047989513d05556faebd28a62b27c] Signed-off-by: Will McVicker <willmcvicker@google.com> Reviewed-by: Youngmin Nam <youngmin.nam@samsung.com> Tested-by: Youngmin Nam <youngmin.nam@samsung.com> Fixes: ea89fdf24fd9 ("arm64: dts: exynos: google: Add initial Google gs101 SoC support") Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Tested-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20250611-gs101-cpuidle-v2-1-4fa811ec404d@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm64/boot/dts/exynos/google/gs101.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi index 3de3a758f113..fd0badf24e6f 100644 --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi @@ -155,6 +155,7 @@ ananke_cpu_sleep: cpu-ananke-sleep { idle-state-name = "c2"; compatible = "arm,idle-state"; arm,psci-suspend-param = <0x0010000>; + local-timer-stop; entry-latency-us = <70>; exit-latency-us = <160>; min-residency-us = <2000>; @@ -164,6 +165,7 @@ enyo_cpu_sleep: cpu-enyo-sleep { idle-state-name = "c2"; compatible = "arm,idle-state"; arm,psci-suspend-param = <0x0010000>; + local-timer-stop; entry-latency-us = <150>; exit-latency-us = <190>; min-residency-us = <2500>; @@ -173,6 +175,7 @@ hera_cpu_sleep: cpu-hera-sleep { idle-state-name = "c2"; compatible = "arm,idle-state"; arm,psci-suspend-param = <0x0010000>; + local-timer-stop; entry-latency-us = <235>; exit-latency-us = <220>; min-residency-us = <3500>; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 041/480] arm64: dts: qcom: sa8775p: Correct the interrupt for remoteproc 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (39 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 040/480] arm64: dts: exynos: gs101: Add local-timer-stop to cpuidle nodes Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 042/480] arm64: dts: qcom: msm8976: Make blsp_dma controlled-remotely Greg Kroah-Hartman ` (450 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Lijuan Gao, Konrad Dybcio, Bjorn Andersson, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Lijuan Gao <lijuan.gao@oss.qualcomm.com> [ Upstream commit 7bd7209e9cb11c8864e601d915008da088476f0c ] Fix the incorrect IRQ numbers for ready and handover on sa8775p. The correct values are as follows: Fatal interrupt - 0 Ready interrupt - 1 Handover interrupt - 2 Stop acknowledge interrupt - 3 Fixes: df54dcb34ff2e ("arm64: dts: qcom: sa8775p: add ADSP, CDSP and GPDSP nodes") Signed-off-by: Lijuan Gao <lijuan.gao@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250612-correct_interrupt_for_remoteproc-v1-2-490ee6d92a1b@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm64/boot/dts/qcom/sa8775p.dtsi | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/sa8775p.dtsi b/arch/arm64/boot/dts/qcom/sa8775p.dtsi index 2010b7988b6c..958e4be164d8 100644 --- a/arch/arm64/boot/dts/qcom/sa8775p.dtsi +++ b/arch/arm64/boot/dts/qcom/sa8775p.dtsi @@ -4663,8 +4663,8 @@ remoteproc_gpdsp0: remoteproc@20c00000 { interrupts-extended = <&intc GIC_SPI 768 IRQ_TYPE_EDGE_RISING>, <&smp2p_gpdsp0_in 0 0>, - <&smp2p_gpdsp0_in 2 0>, <&smp2p_gpdsp0_in 1 0>, + <&smp2p_gpdsp0_in 2 0>, <&smp2p_gpdsp0_in 3 0>; interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack"; @@ -4706,8 +4706,8 @@ remoteproc_gpdsp1: remoteproc@21c00000 { interrupts-extended = <&intc GIC_SPI 624 IRQ_TYPE_EDGE_RISING>, <&smp2p_gpdsp1_in 0 0>, - <&smp2p_gpdsp1_in 2 0>, <&smp2p_gpdsp1_in 1 0>, + <&smp2p_gpdsp1_in 2 0>, <&smp2p_gpdsp1_in 3 0>; interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack"; @@ -4847,8 +4847,8 @@ remoteproc_cdsp0: remoteproc@26300000 { interrupts-extended = <&intc GIC_SPI 578 IRQ_TYPE_EDGE_RISING>, <&smp2p_cdsp0_in 0 IRQ_TYPE_EDGE_RISING>, - <&smp2p_cdsp0_in 2 IRQ_TYPE_EDGE_RISING>, <&smp2p_cdsp0_in 1 IRQ_TYPE_EDGE_RISING>, + <&smp2p_cdsp0_in 2 IRQ_TYPE_EDGE_RISING>, <&smp2p_cdsp0_in 3 IRQ_TYPE_EDGE_RISING>; interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack"; @@ -4979,8 +4979,8 @@ remoteproc_cdsp1: remoteproc@2a300000 { interrupts-extended = <&intc GIC_SPI 798 IRQ_TYPE_EDGE_RISING>, <&smp2p_cdsp1_in 0 IRQ_TYPE_EDGE_RISING>, - <&smp2p_cdsp1_in 2 IRQ_TYPE_EDGE_RISING>, <&smp2p_cdsp1_in 1 IRQ_TYPE_EDGE_RISING>, + <&smp2p_cdsp1_in 2 IRQ_TYPE_EDGE_RISING>, <&smp2p_cdsp1_in 3 IRQ_TYPE_EDGE_RISING>; interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack"; @@ -5135,8 +5135,8 @@ remoteproc_adsp: remoteproc@30000000 { interrupts-extended = <&pdc 6 IRQ_TYPE_EDGE_RISING>, <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>, - <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>, <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>, + <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>, <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>; interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack"; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 042/480] arm64: dts: qcom: msm8976: Make blsp_dma controlled-remotely 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (40 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 041/480] arm64: dts: qcom: sa8775p: Correct the interrupt for remoteproc Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 043/480] pm: cpupower: Fix printing of CORE, CPU fields in cpupower-monitor Greg Kroah-Hartman ` (449 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Konrad Dybcio, André Apitzsch, Bjorn Andersson, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: André Apitzsch <git@apitzsch.eu> [ Upstream commit 76270a18dbdf0bb50615f1b29d2cae8d683da01e ] The blsp_dma controller is shared between the different subsystems, which is why it is already initialized by the firmware. We should not reinitialize it from Linux to avoid potential other users of the DMA engine to misbehave. In mainline this can be described using the "qcom,controlled-remotely" property. In the downstream/vendor kernel from Qualcomm there is an opposite "qcom,managed-locally" property. This property is *not* set for the qcom,sps-dma@7884000 and qcom,sps-dma@7ac4000 [1] so adding "qcom,controlled-remotely" upstream matches the behavior of the downstream/vendor kernel. Adding this fixes booting Longcheer L9360. [1]: https://git.codelinaro.org/clo/la/kernel/msm-3.10/-/blob/LA.BR.1.3.7.c26/arch/arm/boot/dts/qcom/msm8976.dtsi#L1149-1163 Fixes: 0484d3ce0902 ("arm64: dts: qcom: Add DTS for MSM8976 and MSM8956 SoCs") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: André Apitzsch <git@apitzsch.eu> Link: https://lore.kernel.org/r/20250615-bqx5plus-v2-1-72b45c84237d@apitzsch.eu Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm64/boot/dts/qcom/msm8976.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi b/arch/arm64/boot/dts/qcom/msm8976.dtsi index d036f31dfdca..963996f7c927 100644 --- a/arch/arm64/boot/dts/qcom/msm8976.dtsi +++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi @@ -1330,6 +1330,7 @@ blsp1_dma: dma-controller@7884000 { clock-names = "bam_clk"; #dma-cells = <1>; qcom,ee = <0>; + qcom,controlled-remotely; }; blsp1_uart1: serial@78af000 { @@ -1450,6 +1451,7 @@ blsp2_dma: dma-controller@7ac4000 { clock-names = "bam_clk"; #dma-cells = <1>; qcom,ee = <0>; + qcom,controlled-remotely; }; blsp2_uart2: serial@7af0000 { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 043/480] pm: cpupower: Fix printing of CORE, CPU fields in cpupower-monitor 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (41 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 042/480] arm64: dts: qcom: msm8976: Make blsp_dma controlled-remotely Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 044/480] ARM: dts: vfxxx: Correctly use two tuples for timer address Greg Kroah-Hartman ` (448 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Gautham R. Shenoy, Shuah Khan, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Gautham R. Shenoy <gautham.shenoy@amd.com> [ Upstream commit 14a3318b4ac8ae0ca2e1132a89de167e1030fbdb ] After the commit 0014f65e3df0 ("pm: cpupower: remove hard-coded topology depth values"), "cpupower monitor" output ceased to print the CORE and the CPU fields on a multi-socket platform. The reason for this is that the patch changed the behaviour to break out of the switch-case after printing the PKG details, while prior to the patch, the CORE and the CPU details would also get printed since the "if" condition check would pass for any level whose topology depth was lesser than that of a package. Fix this ensuring all the details below a desired topology depth are printed in the cpupower monitor output. Link: https://lore.kernel.org/r/20250612122355.19629-3-gautham.shenoy@amd.com Fixes: 0014f65e3df0 ("pm: cpupower: remove hard-coded topology depth values") Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/power/cpupower/utils/idle_monitor/cpupower-monitor.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/tools/power/cpupower/utils/idle_monitor/cpupower-monitor.c b/tools/power/cpupower/utils/idle_monitor/cpupower-monitor.c index ad493157f826..e8b3841d5c0f 100644 --- a/tools/power/cpupower/utils/idle_monitor/cpupower-monitor.c +++ b/tools/power/cpupower/utils/idle_monitor/cpupower-monitor.c @@ -121,10 +121,8 @@ void print_header(int topology_depth) switch (topology_depth) { case TOPOLOGY_DEPTH_PKG: printf(" PKG|"); - break; case TOPOLOGY_DEPTH_CORE: printf("CORE|"); - break; case TOPOLOGY_DEPTH_CPU: printf(" CPU|"); break; @@ -167,10 +165,8 @@ void print_results(int topology_depth, int cpu) switch (topology_depth) { case TOPOLOGY_DEPTH_PKG: printf("%4d|", cpu_top.core_info[cpu].pkg); - break; case TOPOLOGY_DEPTH_CORE: printf("%4d|", cpu_top.core_info[cpu].core); - break; case TOPOLOGY_DEPTH_CPU: printf("%4d|", cpu_top.core_info[cpu].cpu); break; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 044/480] ARM: dts: vfxxx: Correctly use two tuples for timer address 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (42 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 043/480] pm: cpupower: Fix printing of CORE, CPU fields in cpupower-monitor Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 045/480] usb: host: xhci-plat: fix incorrect type for of_match variable in xhci_plat_probe() Greg Kroah-Hartman ` (447 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Krzysztof Kozlowski, Shawn Guo, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> [ Upstream commit f3440dcf8b994197c968fbafe047ce27eed226e8 ] Address and size-cells are 1 and the ftm timer node takes two address spaces in "reg" property, so this should be in two <> tuples. Change has no functional impact, but original code is confusing/less readable. Fixes: 07513e1330a9 ("ARM: dts: vf610: Add Freescale FlexTimer Module timer node.") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm/boot/dts/nxp/vf/vfxxx.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/nxp/vf/vfxxx.dtsi b/arch/arm/boot/dts/nxp/vf/vfxxx.dtsi index 597f20be82f1..62e555bf6a71 100644 --- a/arch/arm/boot/dts/nxp/vf/vfxxx.dtsi +++ b/arch/arm/boot/dts/nxp/vf/vfxxx.dtsi @@ -603,7 +603,7 @@ usbmisc1: usb@400b4800 { ftm: ftm@400b8000 { compatible = "fsl,ftm-timer"; - reg = <0x400b8000 0x1000 0x400b9000 0x1000>; + reg = <0x400b8000 0x1000>, <0x400b9000 0x1000>; interrupts = <44 IRQ_TYPE_LEVEL_HIGH>; clock-names = "ftm-evt", "ftm-src", "ftm-evt-counter-en", "ftm-src-counter-en"; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 045/480] usb: host: xhci-plat: fix incorrect type for of_match variable in xhci_plat_probe() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (43 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 044/480] ARM: dts: vfxxx: Correctly use two tuples for timer address Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 046/480] usb: misc: apple-mfi-fastcharge: Make power supply names unique Greg Kroah-Hartman ` (446 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Seungjin Bae, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Seungjin Bae <eeodqql09@gmail.com> [ Upstream commit d9e496a9fb4021a9e6b11e7ba221a41a2597ac27 ] The variable `of_match` was incorrectly declared as a `bool`. It is assigned the return value of of_match_device(), which is a pointer of type `const struct of_device_id *`. Fixes: 16b7e0cccb243 ("USB: xhci-plat: fix legacy PHY double init") Signed-off-by: Seungjin Bae <eeodqql09@gmail.com> Link: https://lore.kernel.org/r/20250619055746.176112-2-eeodqql09@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/usb/host/xhci-plat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c index 619481dec8e8..87f173392a01 100644 --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -152,7 +152,7 @@ int xhci_plat_probe(struct platform_device *pdev, struct device *sysdev, const s int ret; int irq; struct xhci_plat_priv *priv = NULL; - bool of_match; + const struct of_device_id *of_match; if (usb_disabled()) return -ENODEV; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 046/480] usb: misc: apple-mfi-fastcharge: Make power supply names unique 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (44 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 045/480] usb: host: xhci-plat: fix incorrect type for of_match variable in xhci_plat_probe() Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 047/480] arm64: dts: ti: k3-am642-phyboard-electra: Fix PRU-ICSSG Ethernet ports Greg Kroah-Hartman ` (445 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Charalampos Mitrodimas, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Charalampos Mitrodimas <charmitro@posteo.net> [ Upstream commit 43007b89fb2de746443fbbb84aedd1089afdf582 ] When multiple Apple devices are connected concurrently, the apple-mfi-fastcharge driver fails to probe the subsequent devices with the following error: sysfs: cannot create duplicate filename '/class/power_supply/apple_mfi_fastcharge' apple-mfi-fastcharge 5-2.4.3.3: probe of 5-2.4.3.3 failed with error -17 This happens because the driver uses a fixed power supply name ("apple_mfi_fastcharge") for all devices, causing a sysfs name conflict when a second device is connected. Fix this by generating unique names using the USB bus and device number (e.g., "apple_mfi_fastcharge_5-12"). This ensures each connected device gets a unique power supply entry in sysfs. The change requires storing a copy of the power_supply_desc structure in the per-device mfi_device struct, since the name pointer needs to remain valid for the lifetime of the power supply registration. Fixes: 249fa8217b84 ("USB: Add driver to control USB fast charge for iOS devices") Signed-off-by: Charalampos Mitrodimas <charmitro@posteo.net> Link: https://lore.kernel.org/r/20250602-apple-mfi-fastcharge-duplicate-sysfs-v1-1-5d84de34fac6@posteo.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/usb/misc/apple-mfi-fastcharge.c | 24 +++++++++++++++++++++--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/drivers/usb/misc/apple-mfi-fastcharge.c b/drivers/usb/misc/apple-mfi-fastcharge.c index ac8695195c13..8e852f4b8262 100644 --- a/drivers/usb/misc/apple-mfi-fastcharge.c +++ b/drivers/usb/misc/apple-mfi-fastcharge.c @@ -44,6 +44,7 @@ MODULE_DEVICE_TABLE(usb, mfi_fc_id_table); struct mfi_device { struct usb_device *udev; struct power_supply *battery; + struct power_supply_desc battery_desc; int charge_type; }; @@ -178,6 +179,7 @@ static int mfi_fc_probe(struct usb_device *udev) { struct power_supply_config battery_cfg = {}; struct mfi_device *mfi = NULL; + char *battery_name; int err; if (!mfi_fc_match(udev)) @@ -187,23 +189,38 @@ static int mfi_fc_probe(struct usb_device *udev) if (!mfi) return -ENOMEM; + battery_name = kasprintf(GFP_KERNEL, "apple_mfi_fastcharge_%d-%d", + udev->bus->busnum, udev->devnum); + if (!battery_name) { + err = -ENOMEM; + goto err_free_mfi; + } + + mfi->battery_desc = apple_mfi_fc_desc; + mfi->battery_desc.name = battery_name; + battery_cfg.drv_data = mfi; mfi->charge_type = POWER_SUPPLY_CHARGE_TYPE_TRICKLE; mfi->battery = power_supply_register(&udev->dev, - &apple_mfi_fc_desc, + &mfi->battery_desc, &battery_cfg); if (IS_ERR(mfi->battery)) { dev_err(&udev->dev, "Can't register battery\n"); err = PTR_ERR(mfi->battery); - kfree(mfi); - return err; + goto err_free_name; } mfi->udev = usb_get_dev(udev); dev_set_drvdata(&udev->dev, mfi); return 0; + +err_free_name: + kfree(battery_name); +err_free_mfi: + kfree(mfi); + return err; } static void mfi_fc_disconnect(struct usb_device *udev) @@ -213,6 +230,7 @@ static void mfi_fc_disconnect(struct usb_device *udev) mfi = dev_get_drvdata(&udev->dev); if (mfi->battery) power_supply_unregister(mfi->battery); + kfree(mfi->battery_desc.name); dev_set_drvdata(&udev->dev, NULL); usb_put_dev(mfi->udev); kfree(mfi); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 047/480] arm64: dts: ti: k3-am642-phyboard-electra: Fix PRU-ICSSG Ethernet ports 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (45 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 046/480] usb: misc: apple-mfi-fastcharge: Make power supply names unique Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 048/480] arm64: dts: ti: k3-am62p-j722s: fix pinctrl-single size Greg Kroah-Hartman ` (444 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Wadim Egorov, Vignesh Raghavendra, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Wadim Egorov <w.egorov@phytec.de> [ Upstream commit 945e48a39c957924bc84d1a6c137da039e13855b ] For the ICSSG PHYs to operate correctly, a 25 MHz reference clock must be supplied on CLKOUT0. Previously, our bootloader configured this clock, which is why the PRU Ethernet ports appeared to work, but the change never made it into the device tree. Add clock properties to make EXT_REFCLK1.CLKOUT0 output a 25MHz clock. Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Fixes: 87adfd1ab03a ("arm64: dts: ti: am642-phyboard-electra: Add PRU-ICSSG nodes") Link: https://lore.kernel.org/r/20250521053339.1751844-1-w.egorov@phytec.de Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm64/boot/dts/ti/k3-am642-phyboard-electra-rdk.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/ti/k3-am642-phyboard-electra-rdk.dts b/arch/arm64/boot/dts/ti/k3-am642-phyboard-electra-rdk.dts index f63c101b7d61..129524eb5b91 100644 --- a/arch/arm64/boot/dts/ti/k3-am642-phyboard-electra-rdk.dts +++ b/arch/arm64/boot/dts/ti/k3-am642-phyboard-electra-rdk.dts @@ -322,6 +322,8 @@ AM64X_IOPAD(0x0040, PIN_OUTPUT, 7) /* (U21) GPMC0_AD1.GPIO0_16 */ &icssg0_mdio { pinctrl-names = "default"; pinctrl-0 = <&icssg0_mdio_pins_default &clkout0_pins_default>; + assigned-clocks = <&k3_clks 157 123>; + assigned-clock-parents = <&k3_clks 157 125>; status = "okay"; icssg0_phy1: ethernet-phy@1 { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 048/480] arm64: dts: ti: k3-am62p-j722s: fix pinctrl-single size 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (46 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 047/480] arm64: dts: ti: k3-am642-phyboard-electra: Fix PRU-ICSSG Ethernet ports Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 049/480] ARM: dts: microchip: sama7d65: Add clock name property Greg Kroah-Hartman ` (443 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Michael Walle, Vignesh Raghavendra, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Michael Walle <mwalle@kernel.org> [ Upstream commit fdc8ad019ab9a2308b8cef54fbc366f482fb746f ] Pinmux registers ends at 0x000f42ac (including). Thus, the size argument of the pinctrl-single node has to be 0x2b0. Fix it. This will fix the following error: pinctrl-single f4000.pinctrl: mux offset out of range: 0x2ac (0x2ac) Fixes: 29075cc09f43 ("arm64: dts: ti: Introduce AM62P5 family of SoCs") Signed-off-by: Michael Walle <mwalle@kernel.org> Link: https://lore.kernel.org/r/20250618065239.1904953-1-mwalle@kernel.org Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi index f9b5c97518d6..8bacb04b3773 100644 --- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi @@ -250,7 +250,7 @@ secure_proxy_sa3: mailbox@43600000 { main_pmx0: pinctrl@f4000 { compatible = "pinctrl-single"; - reg = <0x00 0xf4000 0x00 0x2ac>; + reg = <0x00 0xf4000 0x00 0x2b0>; #pinctrl-cells = <1>; pinctrl-single,register-width = <32>; pinctrl-single,function-mask = <0xffffffff>; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 049/480] ARM: dts: microchip: sama7d65: Add clock name property 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (47 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 048/480] arm64: dts: ti: k3-am62p-j722s: fix pinctrl-single size Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 050/480] ARM: dts: microchip: sam9x7: " Greg Kroah-Hartman ` (442 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Ryan Wanner, Claudiu Beznea, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ryan Wanner <Ryan.Wanner@microchip.com> [ Upstream commit 0029468132ba2e00a3010865038783d9b2e6cc07 ] Add clock-output-names to the xtal nodes, so the driver can correctly register the main and slow xtal. This fixes the issue of the SoC clock driver not being able to find the main xtal and slow xtal correctly causing a bad clock tree. Fixes: 261dcfad1b59 ("ARM: dts: microchip: add sama7d65 SoC DT") Signed-off-by: Ryan Wanner <Ryan.Wanner@microchip.com> Link: https://lore.kernel.org/r/3878ae6d0016d46f0c91bd379146d575d5d336aa.1750175453.git.Ryan.Wanner@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm/boot/dts/microchip/sama7d65.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/microchip/sama7d65.dtsi b/arch/arm/boot/dts/microchip/sama7d65.dtsi index b6710ccd4c36..7b1dd28a2cfa 100644 --- a/arch/arm/boot/dts/microchip/sama7d65.dtsi +++ b/arch/arm/boot/dts/microchip/sama7d65.dtsi @@ -38,11 +38,13 @@ cpu0: cpu@0 { clocks { main_xtal: clock-mainxtal { compatible = "fixed-clock"; + clock-output-names = "main_xtal"; #clock-cells = <0>; }; slow_xtal: clock-slowxtal { compatible = "fixed-clock"; + clock-output-names = "slow_xtal"; #clock-cells = <0>; }; }; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 050/480] ARM: dts: microchip: sam9x7: Add clock name property 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (48 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 049/480] ARM: dts: microchip: sama7d65: Add clock name property Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 051/480] cpufreq: armada-8k: make both cpu masks static Greg Kroah-Hartman ` (441 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Ryan Wanner, Claudiu Beznea, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ryan Wanner <Ryan.Wanner@microchip.com> [ Upstream commit 2e24723492b28ffdccb0e3e68725673e299e3823 ] Add clock-output-names to the xtal nodes, so the driver can correctly register the main and slow xtal. This fixes the issue of the SoC clock driver not being able to find the main xtal and slow xtal correctly causing a bad clock tree. Fixes: 41af45af8bc3 ("ARM: dts: at91: sam9x7: add device tree for SoC") Signed-off-by: Ryan Wanner <Ryan.Wanner@microchip.com> Link: https://lore.kernel.org/r/036518968ac657b93e315bb550b822b59ae6f17c.1750175453.git.Ryan.Wanner@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm/boot/dts/microchip/sam9x7.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/microchip/sam9x7.dtsi b/arch/arm/boot/dts/microchip/sam9x7.dtsi index b217a908f525..114449e90720 100644 --- a/arch/arm/boot/dts/microchip/sam9x7.dtsi +++ b/arch/arm/boot/dts/microchip/sam9x7.dtsi @@ -45,11 +45,13 @@ cpu@0 { clocks { slow_xtal: clock-slowxtal { compatible = "fixed-clock"; + clock-output-names = "slow_xtal"; #clock-cells = <0>; }; main_xtal: clock-mainxtal { compatible = "fixed-clock"; + clock-output-names = "main_xtal"; #clock-cells = <0>; }; }; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 051/480] cpufreq: armada-8k: make both cpu masks static 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (49 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 050/480] ARM: dts: microchip: sam9x7: " Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 052/480] firmware: arm_scmi: Fix up turbo frequencies selection Greg Kroah-Hartman ` (440 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Arnd Bergmann, Viresh Kumar, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Arnd Bergmann <arnd@arndb.de> [ Upstream commit b1b41bc072baf7301b1ae95fe417de09a5ad47e2 ] An earlier patch marked one of the two CPU masks as 'static' to reduce stack usage, but if CONFIG_NR_CPUS is large enough, the function still produces a warning for compile testing: drivers/cpufreq/armada-8k-cpufreq.c: In function 'armada_8k_cpufreq_init': drivers/cpufreq/armada-8k-cpufreq.c:203:1: error: the frame size of 1416 bytes is larger than 1408 bytes [-Werror=frame-larger-than=] Normally this should be done using alloc_cpumask_var(), but since the driver already has a static mask and the probe function is not called concurrently, use the same trick for both. Fixes: 1ffec650d07f ("cpufreq: armada-8k: Avoid excessive stack usage") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/cpufreq/armada-8k-cpufreq.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/cpufreq/armada-8k-cpufreq.c b/drivers/cpufreq/armada-8k-cpufreq.c index 5a3545bd0d8d..006f4c554dd7 100644 --- a/drivers/cpufreq/armada-8k-cpufreq.c +++ b/drivers/cpufreq/armada-8k-cpufreq.c @@ -132,7 +132,7 @@ static int __init armada_8k_cpufreq_init(void) int ret = 0, opps_index = 0, cpu, nb_cpus; struct freq_table *freq_tables; struct device_node *node; - static struct cpumask cpus; + static struct cpumask cpus, shared_cpus; node = of_find_matching_node_and_match(NULL, armada_8k_cpufreq_of_match, NULL); @@ -154,7 +154,6 @@ static int __init armada_8k_cpufreq_init(void) * divisions of it). */ for_each_cpu(cpu, &cpus) { - struct cpumask shared_cpus; struct device *cpu_dev; struct clk *clk; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 052/480] firmware: arm_scmi: Fix up turbo frequencies selection 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (50 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 051/480] cpufreq: armada-8k: make both cpu masks static Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 053/480] usb: typec: ucsi: yoga-c630: fix error and remove paths Greg Kroah-Hartman ` (439 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Sibi Sankar, Sudeep Holla, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Sibi Sankar <quic_sibis@quicinc.com> [ Upstream commit ad28fc31dd702871764e9294d4f2314ad78d24a9 ] Sustained frequency when greater than or equal to 4Ghz on 64-bit devices currently result in marking all frequencies as turbo. Address the turbo frequency selection bug by fixing the truncation. Fixes: a897575e79d7 ("firmware: arm_scmi: Add support for marking certain frequencies as turbo") Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Message-Id: <20250514214719.203607-1-quic_sibis@quicinc.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/firmware/arm_scmi/perf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c index c7e5a34b254b..683fd9b85c5c 100644 --- a/drivers/firmware/arm_scmi/perf.c +++ b/drivers/firmware/arm_scmi/perf.c @@ -892,7 +892,7 @@ static int scmi_dvfs_device_opps_add(const struct scmi_protocol_handle *ph, freq = dom->opp[idx].indicative_freq * dom->mult_factor; /* All OPPs above the sustained frequency are treated as turbo */ - data.turbo = freq > dom->sustained_freq_khz * 1000; + data.turbo = freq > dom->sustained_freq_khz * 1000UL; data.level = dom->opp[idx].perf; data.freq = freq; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 053/480] usb: typec: ucsi: yoga-c630: fix error and remove paths 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (51 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 052/480] firmware: arm_scmi: Fix up turbo frequencies selection Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 054/480] mei: vsc: Dont re-init VSC from mei_vsc_hw_reset() on stop Greg Kroah-Hartman ` (438 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Dmitry Baryshkov, Heikki Krogerus, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> [ Upstream commit 168c3896f32e78e7b87f6aa9e85af36e47a9f96c ] Fix memory leak and call ucsi_destroy() from the driver's remove function and probe's error path in order to remove debugfs files and free the memory. Also call yoga_c630_ec_unregister_notify() in the probe's error path. Fixes: 2ea6d07efe53 ("usb: typec: ucsi: add Lenovo Yoga C630 glue driver") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250621-c630-ucsi-v1-1-a86de5e11361@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/usb/typec/ucsi/ucsi_yoga_c630.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/drivers/usb/typec/ucsi/ucsi_yoga_c630.c b/drivers/usb/typec/ucsi/ucsi_yoga_c630.c index d33e3f2dd1d8..47e8dd5b255b 100644 --- a/drivers/usb/typec/ucsi/ucsi_yoga_c630.c +++ b/drivers/usb/typec/ucsi/ucsi_yoga_c630.c @@ -133,17 +133,30 @@ static int yoga_c630_ucsi_probe(struct auxiliary_device *adev, ret = yoga_c630_ec_register_notify(ec, &uec->nb); if (ret) - return ret; + goto err_destroy; + + ret = ucsi_register(uec->ucsi); + if (ret) + goto err_unregister; + + return 0; - return ucsi_register(uec->ucsi); +err_unregister: + yoga_c630_ec_unregister_notify(uec->ec, &uec->nb); + +err_destroy: + ucsi_destroy(uec->ucsi); + + return ret; } static void yoga_c630_ucsi_remove(struct auxiliary_device *adev) { struct yoga_c630_ucsi *uec = auxiliary_get_drvdata(adev); - yoga_c630_ec_unregister_notify(uec->ec, &uec->nb); ucsi_unregister(uec->ucsi); + yoga_c630_ec_unregister_notify(uec->ec, &uec->nb); + ucsi_destroy(uec->ucsi); } static const struct auxiliary_device_id yoga_c630_ucsi_id_table[] = { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 054/480] mei: vsc: Dont re-init VSC from mei_vsc_hw_reset() on stop 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (52 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 053/480] usb: typec: ucsi: yoga-c630: fix error and remove paths Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 055/480] mei: vsc: Destroy mutex after freeing the IRQ Greg Kroah-Hartman ` (437 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Hans de Goede, Alexander Usyskin, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Hans de Goede <hansg@kernel.org> [ Upstream commit 880af854d6343b796f05b9a8b52b68a88535625b ] mei_vsc_hw_reset() gets called from mei_start() and mei_stop() in the latter case we do not need to re-init the VSC by calling vsc_tp_init(). mei_stop() only happens on shutdown and driver unbind. On shutdown we don't need to load + boot the firmware and if the driver later is bound to the device again then mei_start() will do another reset. The intr_enable flag is true when called from mei_start() and false on mei_stop(). Skip vsc_tp_init() when intr_enable is false. This avoids unnecessarily uploading the firmware, which takes 11 seconds. This change reduces the poweroff/reboot time by 11 seconds. Fixes: 386a766c4169 ("mei: Add MEI hardware support for IVSC device") Signed-off-by: Hans de Goede <hansg@kernel.org> Reviewed-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://lore.kernel.org/r/20250623085052.12347-3-hansg@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/misc/mei/platform-vsc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/misc/mei/platform-vsc.c b/drivers/misc/mei/platform-vsc.c index 435760b1e86f..1ac85f0251c5 100644 --- a/drivers/misc/mei/platform-vsc.c +++ b/drivers/misc/mei/platform-vsc.c @@ -256,6 +256,9 @@ static int mei_vsc_hw_reset(struct mei_device *mei_dev, bool intr_enable) vsc_tp_reset(hw->tp); + if (!intr_enable) + return 0; + return vsc_tp_init(hw->tp, mei_dev->dev); } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 055/480] mei: vsc: Destroy mutex after freeing the IRQ 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (53 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 054/480] mei: vsc: Dont re-init VSC from mei_vsc_hw_reset() on stop Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 056/480] mei: vsc: Event notifier fixes Greg Kroah-Hartman ` (436 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Hans de Goede, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Hans de Goede <hansg@kernel.org> [ Upstream commit 35b7f3525fe0a7283de7116e3c75ee3ccb3b14c9 ] The event_notify callback which runs from vsc_tp_thread_isr may call vsc_tp_xfer() which locks the mutex. So the ISR depends on the mutex. Move the mutex_destroy() call to after free_irq() to ensure that the ISR is not running while the mutex is destroyed. Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device") Signed-off-by: Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/r/20250623085052.12347-6-hansg@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/misc/mei/vsc-tp.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/misc/mei/vsc-tp.c b/drivers/misc/mei/vsc-tp.c index 267d0de5fade..66b41b86ea7d 100644 --- a/drivers/misc/mei/vsc-tp.c +++ b/drivers/misc/mei/vsc-tp.c @@ -552,10 +552,10 @@ static int vsc_tp_probe(struct spi_device *spi) return 0; err_destroy_lock: - mutex_destroy(&tp->mutex); - free_irq(spi->irq, tp); + mutex_destroy(&tp->mutex); + return ret; } @@ -565,9 +565,9 @@ static void vsc_tp_remove(struct spi_device *spi) platform_device_unregister(tp->pdev); - mutex_destroy(&tp->mutex); - free_irq(spi->irq, tp); + + mutex_destroy(&tp->mutex); } static void vsc_tp_shutdown(struct spi_device *spi) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 056/480] mei: vsc: Event notifier fixes 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (54 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 055/480] mei: vsc: Destroy mutex after freeing the IRQ Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 057/480] mei: vsc: Unset the event callback on remove and probe errors Greg Kroah-Hartman ` (435 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Hans de Goede, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Hans de Goede <hansg@kernel.org> [ Upstream commit 18f14b2e7f73c7ec272d833d570b632286467c7d ] vsc_tp_register_event_cb() can race with vsc_tp_thread_isr(), add a mutex to protect against this. Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device") Signed-off-by: Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/r/20250623085052.12347-7-hansg@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/misc/mei/vsc-tp.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/misc/mei/vsc-tp.c b/drivers/misc/mei/vsc-tp.c index 66b41b86ea7d..97df3077175d 100644 --- a/drivers/misc/mei/vsc-tp.c +++ b/drivers/misc/mei/vsc-tp.c @@ -79,9 +79,8 @@ struct vsc_tp { vsc_tp_event_cb_t event_notify; void *event_notify_context; - - /* used to protect command download */ - struct mutex mutex; + struct mutex event_notify_mutex; /* protects event_notify + context */ + struct mutex mutex; /* protects command download */ }; /* GPIO resources */ @@ -113,6 +112,8 @@ static irqreturn_t vsc_tp_thread_isr(int irq, void *data) { struct vsc_tp *tp = data; + guard(mutex)(&tp->event_notify_mutex); + if (tp->event_notify) tp->event_notify(tp->event_notify_context); @@ -399,6 +400,8 @@ EXPORT_SYMBOL_NS_GPL(vsc_tp_need_read, "VSC_TP"); int vsc_tp_register_event_cb(struct vsc_tp *tp, vsc_tp_event_cb_t event_cb, void *context) { + guard(mutex)(&tp->event_notify_mutex); + tp->event_notify = event_cb; tp->event_notify_context = context; @@ -530,6 +533,7 @@ static int vsc_tp_probe(struct spi_device *spi) return ret; mutex_init(&tp->mutex); + mutex_init(&tp->event_notify_mutex); /* only one child acpi device */ ret = acpi_dev_for_each_child(ACPI_COMPANION(dev), @@ -554,6 +558,7 @@ static int vsc_tp_probe(struct spi_device *spi) err_destroy_lock: free_irq(spi->irq, tp); + mutex_destroy(&tp->event_notify_mutex); mutex_destroy(&tp->mutex); return ret; @@ -567,6 +572,7 @@ static void vsc_tp_remove(struct spi_device *spi) free_irq(spi->irq, tp); + mutex_destroy(&tp->event_notify_mutex); mutex_destroy(&tp->mutex); } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 057/480] mei: vsc: Unset the event callback on remove and probe errors 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (55 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 056/480] mei: vsc: Event notifier fixes Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 058/480] spi: stm32: Check for cfg availability in stm32_spi_probe Greg Kroah-Hartman ` (434 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Hans de Goede, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Hans de Goede <hansg@kernel.org> [ Upstream commit 6175c6974095f8ca7e5f8d593171512f3e5bd453 ] Make mei_vsc_remove() properly unset the callback to avoid a dead callback sticking around after probe errors or unbinding of the platform driver. Fixes: 386a766c4169 ("mei: Add MEI hardware support for IVSC device") Signed-off-by: Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/r/20250623085052.12347-8-hansg@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/misc/mei/platform-vsc.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/misc/mei/platform-vsc.c b/drivers/misc/mei/platform-vsc.c index 1ac85f0251c5..b2b5a20ae3fa 100644 --- a/drivers/misc/mei/platform-vsc.c +++ b/drivers/misc/mei/platform-vsc.c @@ -380,6 +380,8 @@ static int mei_vsc_probe(struct platform_device *pdev) err_cancel: mei_cancel_work(mei_dev); + vsc_tp_register_event_cb(tp, NULL, NULL); + mei_disable_interrupts(mei_dev); return ret; @@ -388,11 +390,14 @@ static int mei_vsc_probe(struct platform_device *pdev) static void mei_vsc_remove(struct platform_device *pdev) { struct mei_device *mei_dev = platform_get_drvdata(pdev); + struct mei_vsc_hw *hw = mei_dev_to_vsc_hw(mei_dev); pm_runtime_disable(mei_dev->dev); mei_stop(mei_dev); + vsc_tp_register_event_cb(hw->tp, NULL, NULL); + mei_disable_interrupts(mei_dev); mei_deregister(mei_dev); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 058/480] spi: stm32: Check for cfg availability in stm32_spi_probe 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (56 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 057/480] mei: vsc: Unset the event callback on remove and probe errors Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 059/480] drivers: misc: sram: fix up some const issues with recent attribute changes Greg Kroah-Hartman ` (433 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Clément Le Goffic, kernel test robot, Mark Brown, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Clément Le Goffic <clement.legoffic@foss.st.com> [ Upstream commit 21f1c800f6620e43f31dfd76709dbac8ebaa5a16 ] The stm32_spi_probe function now includes a check to ensure that the pointer returned by of_device_get_match_data is not NULL before accessing its members. This resolves a warning where a potential NULL pointer dereference could occur when accessing cfg->has_device_mode. Before accessing the 'has_device_mode' member, we verify that 'cfg' is not NULL. If 'cfg' is NULL, an error message is logged. This change ensures that the driver does not attempt to access configuration data if it is not available, thus preventing a potential system crash due to a NULL pointer dereference. Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202310191831.MLwx1c6x-lkp@intel.com/ Fixes: fee681646fc8 ("spi: stm32: disable device mode with st,stm32f4-spi compatible") Link: https://patch.msgid.link/20250616-spi-upstream-v1-2-7e8593f3f75d@foss.st.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/spi/spi-stm32.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/spi/spi-stm32.c b/drivers/spi/spi-stm32.c index da3517d7102d..dc22b98bdbcc 100644 --- a/drivers/spi/spi-stm32.c +++ b/drivers/spi/spi-stm32.c @@ -2069,9 +2069,15 @@ static int stm32_spi_probe(struct platform_device *pdev) struct resource *res; struct reset_control *rst; struct device_node *np = pdev->dev.of_node; + const struct stm32_spi_cfg *cfg; bool device_mode; int ret; - const struct stm32_spi_cfg *cfg = of_device_get_match_data(&pdev->dev); + + cfg = of_device_get_match_data(&pdev->dev); + if (!cfg) { + dev_err(&pdev->dev, "Failed to get match data for platform\n"); + return -ENODEV; + } device_mode = of_property_read_bool(np, "spi-slave"); if (!cfg->has_device_mode && device_mode) { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 059/480] drivers: misc: sram: fix up some const issues with recent attribute changes 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (57 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 058/480] spi: stm32: Check for cfg availability in stm32_spi_probe Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 060/480] power: sequencing: qcom-wcn: fix bluetooth-wifi copypasta for WCN6855 Greg Kroah-Hartman ` (432 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Arnd Bergmann, Thomas Weißschuh, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [ Upstream commit bf7b4a0e25569ce39c6749afe363aefe5723d326 ] The binary attribute const changes recently for the sram driver were made in a way that hid the fact that we would be casting a const pointer to a non-const one. So explicitly make the cast so that it is obvious and preserve the const pointer in the sram_reserve_cmp() function. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Thomas Weißschuh <linux@weissschuh.net> Fixes: c3b8c358c4f3 ("misc: sram: constify 'struct bin_attribute'") Link: https://lore.kernel.org/r/2025052125-squid-sandstorm-a418@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/misc/sram.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c index e5069882457e..c69644be4176 100644 --- a/drivers/misc/sram.c +++ b/drivers/misc/sram.c @@ -28,7 +28,8 @@ static ssize_t sram_read(struct file *filp, struct kobject *kobj, { struct sram_partition *part; - part = container_of(attr, struct sram_partition, battr); + /* Cast away the const as the attribute is part of a larger structure */ + part = (struct sram_partition *)container_of(attr, struct sram_partition, battr); mutex_lock(&part->lock); memcpy_fromio(buf, part->base + pos, count); @@ -43,7 +44,8 @@ static ssize_t sram_write(struct file *filp, struct kobject *kobj, { struct sram_partition *part; - part = container_of(attr, struct sram_partition, battr); + /* Cast away the const as the attribute is part of a larger structure */ + part = (struct sram_partition *)container_of(attr, struct sram_partition, battr); mutex_lock(&part->lock); memcpy_toio(part->base + pos, buf, count); @@ -164,8 +166,8 @@ static void sram_free_partitions(struct sram_dev *sram) static int sram_reserve_cmp(void *priv, const struct list_head *a, const struct list_head *b) { - struct sram_reserve *ra = list_entry(a, struct sram_reserve, list); - struct sram_reserve *rb = list_entry(b, struct sram_reserve, list); + const struct sram_reserve *ra = list_entry(a, struct sram_reserve, list); + const struct sram_reserve *rb = list_entry(b, struct sram_reserve, list); return ra->start - rb->start; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 060/480] power: sequencing: qcom-wcn: fix bluetooth-wifi copypasta for WCN6855 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (58 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 059/480] drivers: misc: sram: fix up some const issues with recent attribute changes Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 061/480] arm64: dts: rockchip: Enable eMMC HS200 mode on Radxa E20C Greg Kroah-Hartman ` (431 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Konrad Dybcio, Bartosz Golaszewski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> [ Upstream commit 07d59dec6795428983a840de85aa02febaf7e01b ] Prevent a name conflict (which is surprisingly not caught by the framework). Fixes: bd4c8bafcf50 ("power: sequencing: qcom-wcn: improve support for wcn6855") Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250625-topic-wcn6855_pwrseq-v1-1-cfb96d599ff8@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/power/sequencing/pwrseq-qcom-wcn.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/power/sequencing/pwrseq-qcom-wcn.c b/drivers/power/sequencing/pwrseq-qcom-wcn.c index e8f5030f2639..7d8d6b340749 100644 --- a/drivers/power/sequencing/pwrseq-qcom-wcn.c +++ b/drivers/power/sequencing/pwrseq-qcom-wcn.c @@ -155,7 +155,7 @@ static const struct pwrseq_unit_data pwrseq_qcom_wcn_bt_unit_data = { }; static const struct pwrseq_unit_data pwrseq_qcom_wcn6855_bt_unit_data = { - .name = "wlan-enable", + .name = "bluetooth-enable", .deps = pwrseq_qcom_wcn6855_unit_deps, .enable = pwrseq_qcom_wcn_bt_enable, .disable = pwrseq_qcom_wcn_bt_disable, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 061/480] arm64: dts: rockchip: Enable eMMC HS200 mode on Radxa E20C 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (59 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 060/480] power: sequencing: qcom-wcn: fix bluetooth-wifi copypasta for WCN6855 Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 062/480] staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc() Greg Kroah-Hartman ` (430 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Jonas Karlman, Heiko Stuebner, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jonas Karlman <jonas@kwiboo.se> [ Upstream commit 6e3071f4e03997ca0e4388ca61aa06df2802dcd1 ] eMMC HS200 mode (1.8V I/O) is supported by the MMC host controller on RK3528 and works with the optional on-board eMMC module on Radxa E20C. Be explicit about HS200 support in the device tree for Radxa E20C. Fixes: 3a01b5f14a8a ("arm64: dts: rockchip: Enable onboard eMMC on Radxa E20C") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20250621165832.2226160-1-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm64/boot/dts/rockchip/rk3528-radxa-e20c.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3528-radxa-e20c.dts b/arch/arm64/boot/dts/rockchip/rk3528-radxa-e20c.dts index 57a446b5cbd6..92bdb66169f2 100644 --- a/arch/arm64/boot/dts/rockchip/rk3528-radxa-e20c.dts +++ b/arch/arm64/boot/dts/rockchip/rk3528-radxa-e20c.dts @@ -140,6 +140,7 @@ &saradc { &sdhci { bus-width = <8>; cap-mmc-highspeed; + mmc-hs200-1_8v; no-sd; no-sdio; non-removable; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 062/480] staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (60 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 061/480] arm64: dts: rockchip: Enable eMMC HS200 mode on Radxa E20C Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 063/480] rust: miscdevice: clarify invariant for `MiscDeviceRegistration` Greg Kroah-Hartman ` (429 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Abdun Nihaal, Dan Carpenter, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Abdun Nihaal <abdun.nihaal@gmail.com> [ Upstream commit eb2cb7dab60f9be0b435ac4a674255429a36d72c ] In the error paths after fb_info structure is successfully allocated, the memory allocated in fb_deferred_io_init() for info->pagerefs is not freed. Fix that by adding the cleanup function on the error path. Fixes: c296d5f9957c ("staging: fbtft: core support") Signed-off-by: Abdun Nihaal <abdun.nihaal@gmail.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/20250626172412.18355-1-abdun.nihaal@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/staging/fbtft/fbtft-core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c index da9c64152a60..39bced400065 100644 --- a/drivers/staging/fbtft/fbtft-core.c +++ b/drivers/staging/fbtft/fbtft-core.c @@ -692,6 +692,7 @@ struct fb_info *fbtft_framebuffer_alloc(struct fbtft_display *display, return info; release_framebuf: + fb_deferred_io_cleanup(info); framebuffer_release(info); alloc_fail: -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 063/480] rust: miscdevice: clarify invariant for `MiscDeviceRegistration` 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (61 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 062/480] staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc() Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 064/480] vmci: Prevent the dispatching of uninitialized payloads Greg Kroah-Hartman ` (428 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Benno Lossin, Shankari Anand, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Shankari Anand <shankari.ak0208@gmail.com> [ Upstream commit b9ff1c2a26fa31216be18e9b14c419ff8fe39e72 ] Reword and expand the invariant documentation for `MiscDeviceRegistration` to clarify what it means for the inner device to be "registered". It expands to explain: - `inner` points to a `miscdevice` registered via `misc_register`. - This registration stays valid for the entire lifetime of the object. - Deregistration is guaranteed on `Drop`, via `misc_deregister`. Reported-by: Benno Lossin <lossin@kernel.org> Closes: https://github.com/Rust-for-Linux/linux/issues/1168 Fixes: f893691e7426 ("rust: miscdevice: add base miscdevice abstraction") Signed-off-by: Shankari Anand <shankari.ak0208@gmail.com> Link: https://lore.kernel.org/r/20250626104520.563036-1-shankari.ak0208@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- rust/kernel/miscdevice.rs | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/rust/kernel/miscdevice.rs b/rust/kernel/miscdevice.rs index 15d10e5c1db7..188ae10d3319 100644 --- a/rust/kernel/miscdevice.rs +++ b/rust/kernel/miscdevice.rs @@ -44,7 +44,13 @@ pub const fn into_raw<T: MiscDevice>(self) -> bindings::miscdevice { /// /// # Invariants /// -/// `inner` is a registered misc device. +/// - `inner` contains a `struct miscdevice` that is registered using +/// `misc_register()`. +/// - This registration remains valid for the entire lifetime of the +/// [`MiscDeviceRegistration`] instance. +/// - Deregistration occurs exactly once in [`Drop`] via `misc_deregister()`. +/// - `inner` wraps a valid, pinned `miscdevice` created using +/// [`MiscDeviceOptions::into_raw`]. #[repr(transparent)] #[pin_data(PinnedDrop)] pub struct MiscDeviceRegistration<T> { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 064/480] vmci: Prevent the dispatching of uninitialized payloads 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (62 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 063/480] rust: miscdevice: clarify invariant for `MiscDeviceRegistration` Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 065/480] pps: fix poll support Greg Kroah-Hartman ` (427 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, syzbot+9b9124ae9b12d5af5d95, Lizhi Xu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Lizhi Xu <lizhi.xu@windriver.com> [ Upstream commit bfb4cf9fb97e4063f0aa62e9e398025fb6625031 ] The reproducer executes the host's unlocked_ioctl call in two different tasks. When init_context fails, the struct vmci_event_ctx is not fully initialized when executing vmci_datagram_dispatch() to send events to all vm contexts. This affects the datagram taken from the datagram queue of its context by another task, because the datagram payload is not initialized according to the size payload_size, which causes the kernel data to leak to the user space. Before dispatching the datagram, and before setting the payload content, explicitly set the payload content to 0 to avoid data leakage caused by incomplete payload initialization. Fixes: 28d6692cd8fb ("VMCI: context implementation.") Reported-by: syzbot+9b9124ae9b12d5af5d95@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9b9124ae9b12d5af5d95 Tested-by: syzbot+9b9124ae9b12d5af5d95@syzkaller.appspotmail.com Signed-off-by: Lizhi Xu <lizhi.xu@windriver.com> Link: https://lore.kernel.org/r/20250627055214.2967129-1-lizhi.xu@windriver.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/misc/vmw_vmci/vmci_context.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/misc/vmw_vmci/vmci_context.c b/drivers/misc/vmw_vmci/vmci_context.c index f22b44827e92..d566103caa27 100644 --- a/drivers/misc/vmw_vmci/vmci_context.c +++ b/drivers/misc/vmw_vmci/vmci_context.c @@ -251,6 +251,8 @@ static int ctx_fire_notification(u32 context_id, u32 priv_flags) ev.msg.hdr.src = vmci_make_handle(VMCI_HYPERVISOR_CONTEXT_ID, VMCI_CONTEXT_RESOURCE_ID); ev.msg.hdr.payload_size = sizeof(ev) - sizeof(ev.msg.hdr); + memset((char*)&ev.msg.hdr + sizeof(ev.msg.hdr), 0, + ev.msg.hdr.payload_size); ev.msg.event_data.event = VMCI_EVENT_CTX_REMOVED; ev.payload.context_id = context_id; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 065/480] pps: fix poll support 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (63 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 064/480] vmci: Prevent the dispatching of uninitialized payloads Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 066/480] arm64: dts: imx8mp-venice-gw74xx: update name of M2SKT_WDIS2# gpio Greg Kroah-Hartman ` (426 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Denis OSTERLAND-HEIM, Rodolfo Giometti, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Denis OSTERLAND-HEIM <denis.osterland@diehl.com> [ Upstream commit 12c409aa1ec2592280a2ddcc66ff8f3c7f7bb171 ] Because pps_cdev_poll() returns unconditionally EPOLLIN, a user space program that calls select/poll get always an immediate data ready-to-read response. As a result the intended use to wait until next data becomes ready does not work. User space snippet: struct pollfd pollfd = { .fd = open("/dev/pps0", O_RDONLY), .events = POLLIN|POLLERR, .revents = 0 }; while(1) { poll(&pollfd, 1, 2000/*ms*/); // returns immediate, but should wait if(revents & EPOLLIN) { // always true struct pps_fdata fdata; memset(&fdata, 0, sizeof(memdata)); ioctl(PPS_FETCH, &fdata); // currently fetches data at max speed } } Lets remember the last fetch event counter and compare this value in pps_cdev_poll() with most recent event counter and return 0 if they are equal. Signed-off-by: Denis OSTERLAND-HEIM <denis.osterland@diehl.com> Co-developed-by: Rodolfo Giometti <giometti@enneenne.com> Signed-off-by: Rodolfo Giometti <giometti@enneenne.com> Fixes: eae9d2ba0cfc ("LinuxPPS: core support") Link: https://lore.kernel.org/all/f6bed779-6d59-4f0f-8a59-b6312bd83b4e@enneenne.com/ Acked-by: Rodolfo Giometti <giometti@enneenne.com> Link: https://lore.kernel.org/r/c3c50ad1eb19ef553eca8a57c17f4c006413ab70.camel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/pps/pps.c | 11 +++++++++-- include/linux/pps_kernel.h | 1 + 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/pps/pps.c b/drivers/pps/pps.c index 6a02245ea35f..9463232af8d2 100644 --- a/drivers/pps/pps.c +++ b/drivers/pps/pps.c @@ -41,6 +41,9 @@ static __poll_t pps_cdev_poll(struct file *file, poll_table *wait) poll_wait(file, &pps->queue, wait); + if (pps->last_fetched_ev == pps->last_ev) + return 0; + return EPOLLIN | EPOLLRDNORM; } @@ -186,9 +189,11 @@ static long pps_cdev_ioctl(struct file *file, if (err) return err; - /* Return the fetched timestamp */ + /* Return the fetched timestamp and save last fetched event */ spin_lock_irq(&pps->lock); + pps->last_fetched_ev = pps->last_ev; + fdata.info.assert_sequence = pps->assert_sequence; fdata.info.clear_sequence = pps->clear_sequence; fdata.info.assert_tu = pps->assert_tu; @@ -272,9 +277,11 @@ static long pps_cdev_compat_ioctl(struct file *file, if (err) return err; - /* Return the fetched timestamp */ + /* Return the fetched timestamp and save last fetched event */ spin_lock_irq(&pps->lock); + pps->last_fetched_ev = pps->last_ev; + compat.info.assert_sequence = pps->assert_sequence; compat.info.clear_sequence = pps->clear_sequence; compat.info.current_mode = pps->current_mode; diff --git a/include/linux/pps_kernel.h b/include/linux/pps_kernel.h index c7abce28ed29..aab0aebb529e 100644 --- a/include/linux/pps_kernel.h +++ b/include/linux/pps_kernel.h @@ -52,6 +52,7 @@ struct pps_device { int current_mode; /* PPS mode at event time */ unsigned int last_ev; /* last PPS event id */ + unsigned int last_fetched_ev; /* last fetched PPS event id */ wait_queue_head_t queue; /* PPS event queue */ unsigned int id; /* PPS source unique ID */ -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 066/480] arm64: dts: imx8mp-venice-gw74xx: update name of M2SKT_WDIS2# gpio 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (64 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 065/480] pps: fix poll support Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 067/480] selftests: vDSO: chacha: Correctly skip test if necessary Greg Kroah-Hartman ` (425 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Tim Harvey, Shawn Guo, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Tim Harvey <tharvey@gateworks.com> [ Upstream commit 26a6a9cde64a890997708007d9de25809970eac9 ] The GW74xx D revision has added a M2SKT_WDIS2# GPIO which routes to the W_DISABLE2# pin of the M.2 socket. Update the gpio name for consistency. Fixes: 6a5d95b06d93 ("arm64: dts: imx8mp-venice-gw74xx: add M2SKT_GPIO10 gpio configuration") Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm64/boot/dts/freescale/imx8mp-venice-gw74xx.dts | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw74xx.dts b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw74xx.dts index 568d24265ddf..12de7cf1e853 100644 --- a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw74xx.dts +++ b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw74xx.dts @@ -301,7 +301,7 @@ &gpio2 { &gpio3 { gpio-line-names = "", "", "", "", "", "", "m2_rst", "", - "", "", "", "", "", "", "m2_gpio10", "", + "", "", "", "", "", "", "m2_wdis2#", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", ""; }; @@ -310,7 +310,7 @@ &gpio4 { gpio-line-names = "", "", "m2_off#", "", "", "", "", "", "", "", "", "", "", "", "", "", - "", "", "m2_wdis#", "", "", "", "", "", + "", "", "m2_wdis1#", "", "", "", "", "", "", "", "", "", "", "", "", "rs485_en"; }; @@ -811,14 +811,14 @@ pinctrl_hog: hoggrp { MX8MP_IOMUXC_GPIO1_IO09__GPIO1_IO09 0x40000040 /* DIO0 */ MX8MP_IOMUXC_GPIO1_IO11__GPIO1_IO11 0x40000040 /* DIO1 */ MX8MP_IOMUXC_SAI1_RXD0__GPIO4_IO02 0x40000040 /* M2SKT_OFF# */ - MX8MP_IOMUXC_SAI1_TXD6__GPIO4_IO18 0x40000150 /* M2SKT_WDIS# */ + MX8MP_IOMUXC_SAI1_TXD6__GPIO4_IO18 0x40000150 /* M2SKT_WDIS1# */ MX8MP_IOMUXC_SD1_DATA4__GPIO2_IO06 0x40000040 /* M2SKT_PIN20 */ MX8MP_IOMUXC_SD1_STROBE__GPIO2_IO11 0x40000040 /* M2SKT_PIN22 */ MX8MP_IOMUXC_SD2_CLK__GPIO2_IO13 0x40000150 /* PCIE1_WDIS# */ MX8MP_IOMUXC_SD2_CMD__GPIO2_IO14 0x40000150 /* PCIE3_WDIS# */ MX8MP_IOMUXC_SD2_DATA3__GPIO2_IO18 0x40000150 /* PCIE2_WDIS# */ MX8MP_IOMUXC_NAND_DATA00__GPIO3_IO06 0x40000040 /* M2SKT_RST# */ - MX8MP_IOMUXC_NAND_DQS__GPIO3_IO14 0x40000040 /* M2SKT_GPIO10 */ + MX8MP_IOMUXC_NAND_DQS__GPIO3_IO14 0x40000150 /* M2KST_WDIS2# */ MX8MP_IOMUXC_SAI3_TXD__GPIO5_IO01 0x40000104 /* UART_TERM */ MX8MP_IOMUXC_SAI3_TXFS__GPIO4_IO31 0x40000104 /* UART_RS485 */ MX8MP_IOMUXC_SAI3_TXC__GPIO5_IO00 0x40000104 /* UART_HALF */ -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 067/480] selftests: vDSO: chacha: Correctly skip test if necessary 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (65 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 066/480] arm64: dts: imx8mp-venice-gw74xx: update name of M2SKT_WDIS2# gpio Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 068/480] Revert "vmci: Prevent the dispatching of uninitialized payloads" Greg Kroah-Hartman ` (424 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Thomas Weißschuh, Thomas Gleixner, Muhammad Usama Anjum, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Weißschuh <thomas.weissschuh@linutronix.de> [ Upstream commit 2c0a4428f5d6005ff0db12057cc35273593fc040 ] According to kselftest.h ksft_exit_skip() is not meant to be called when a plan has already been printed. Use the recommended function ksft_test_result_skip(). This fixes a bug, where the TAP output would be invalid when skipping: TAP version 13 1..1 ok 2 # SKIP Not implemented on architecture The SKIP line should start with "ok 1" as the plan only contains one test. Fixes: 3b5992eaf730 ("selftests: vDSO: unconditionally build chacha test") Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Link: https://lore.kernel.org/all/20250611-selftests-vdso-fixes-v3-1-e62e37a6bcf5@linutronix.de Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/testing/selftests/vDSO/vdso_test_chacha.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/vDSO/vdso_test_chacha.c b/tools/testing/selftests/vDSO/vdso_test_chacha.c index 8757f738b0b1..0aad682b12c8 100644 --- a/tools/testing/selftests/vDSO/vdso_test_chacha.c +++ b/tools/testing/selftests/vDSO/vdso_test_chacha.c @@ -76,7 +76,8 @@ static void reference_chacha20_blocks(uint8_t *dst_bytes, const uint32_t *key, u void __weak __arch_chacha20_blocks_nostack(uint8_t *dst_bytes, const uint32_t *key, uint32_t *counter, size_t nblocks) { - ksft_exit_skip("Not implemented on architecture\n"); + ksft_test_result_skip("Not implemented on architecture\n"); + ksft_finished(); } int main(int argc, char *argv[]) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 068/480] Revert "vmci: Prevent the dispatching of uninitialized payloads" 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (66 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 067/480] selftests: vDSO: chacha: Correctly skip test if necessary Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 069/480] powercap: dtpm_cpu: Fix NULL pointer dereference in get_pd_power_uw() Greg Kroah-Hartman ` (423 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Stephen Rothwell, Lizhi Xu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [ Upstream commit 8f5d9bed6122b8d96508436e5ad2498bb797eb6b ] This reverts commit bfb4cf9fb97e4063f0aa62e9e398025fb6625031. While the code "looks" correct, the compiler has no way to know that doing "fun" pointer math like this really isn't a write off the end of the structure as there is no hint anywhere that the structure has data at the end of it. This causes the following build warning: In function 'fortify_memset_chk', inlined from 'ctx_fire_notification.isra' at drivers/misc/vmw_vmci/vmci_context.c:254:3: include/linux/fortify-string.h:480:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 480 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ So revert it for now and it can come back in the future in a "sane" way that either correctly makes the structure know that there is trailing data, OR just the payload structure is properly referenced and zeroed out. Fixes: bfb4cf9fb97e ("vmci: Prevent the dispatching of uninitialized payloads") Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Lizhi Xu <lizhi.xu@windriver.com> Link: https://lore.kernel.org/r/20250703171021.0aee1482@canb.auug.org.au Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/misc/vmw_vmci/vmci_context.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/misc/vmw_vmci/vmci_context.c b/drivers/misc/vmw_vmci/vmci_context.c index d566103caa27..f22b44827e92 100644 --- a/drivers/misc/vmw_vmci/vmci_context.c +++ b/drivers/misc/vmw_vmci/vmci_context.c @@ -251,8 +251,6 @@ static int ctx_fire_notification(u32 context_id, u32 priv_flags) ev.msg.hdr.src = vmci_make_handle(VMCI_HYPERVISOR_CONTEXT_ID, VMCI_CONTEXT_RESOURCE_ID); ev.msg.hdr.payload_size = sizeof(ev) - sizeof(ev.msg.hdr); - memset((char*)&ev.msg.hdr + sizeof(ev.msg.hdr), 0, - ev.msg.hdr.payload_size); ev.msg.event_data.event = VMCI_EVENT_CTX_REMOVED; ev.payload.context_id = context_id; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 069/480] powercap: dtpm_cpu: Fix NULL pointer dereference in get_pd_power_uw() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (67 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 068/480] Revert "vmci: Prevent the dispatching of uninitialized payloads" Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 070/480] usb: early: xhci-dbc: Fix early_ioremap leak Greg Kroah-Hartman ` (422 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Sivan Zohar-Kotzer, Rafael J. Wysocki, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Sivan Zohar-Kotzer <sivany32@gmail.com> [ Upstream commit 46dc57406887dd02565cb264224194a6776d882b ] The get_pd_power_uw() function can crash with a NULL pointer dereference when em_cpu_get() returns NULL. This occurs when a CPU becomes impossible during runtime, causing get_cpu_device() to return NULL, which propagates through em_cpu_get() and leads to a crash when em_span_cpus() dereferences the NULL pointer. Add a NULL check after em_cpu_get() and return 0 if unavailable, matching the existing fallback behavior in __dtpm_cpu_setup(). Fixes: eb82bace8931 ("powercap/drivers/dtpm: Scale the power with the load") Signed-off-by: Sivan Zohar-Kotzer <sivany32@gmail.com> Link: https://patch.msgid.link/20250701221355.96916-1-sivany32@gmail.com [ rjw: Drop an excess empty code line ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/powercap/dtpm_cpu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/powercap/dtpm_cpu.c b/drivers/powercap/dtpm_cpu.c index 6b6f51b21550..99390ec1481f 100644 --- a/drivers/powercap/dtpm_cpu.c +++ b/drivers/powercap/dtpm_cpu.c @@ -96,6 +96,8 @@ static u64 get_pd_power_uw(struct dtpm *dtpm) int i; pd = em_cpu_get(dtpm_cpu->cpu); + if (!pd) + return 0; pd_mask = em_span_cpus(pd); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 070/480] usb: early: xhci-dbc: Fix early_ioremap leak 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (68 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 069/480] powercap: dtpm_cpu: Fix NULL pointer dereference in get_pd_power_uw() Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 071/480] arm: dts: ti: omap: Fixup pinheader typo Greg Kroah-Hartman ` (421 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Lucas De Marchi, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Lucas De Marchi <lucas.demarchi@intel.com> [ Upstream commit 2b7eec2ec3015f52fc74cf45d0408925e984ecd1 ] Using the kernel param earlyprintk=xdbc,keep without proper hardware setup leads to this: [ ] xhci_dbc:early_xdbc_parse_parameter: dbgp_num: 0 ... [ ] xhci_dbc:early_xdbc_setup_hardware: failed to setup the connection to host ... [ ] calling kmemleak_late_init+0x0/0xa0 @ 1 [ ] kmemleak: Kernel memory leak detector initialized (mem pool available: 14919) [ ] kmemleak: Automatic memory scanning thread started [ ] initcall kmemleak_late_init+0x0/0xa0 returned 0 after 417 usecs [ ] calling check_early_ioremap_leak+0x0/0x70 @ 1 [ ] ------------[ cut here ]------------ [ ] Debug warning: early ioremap leak of 1 areas detected. please boot with early_ioremap_debug and report the dmesg. [ ] WARNING: CPU: 11 PID: 1 at mm/early_ioremap.c:90 check_early_ioremap_leak+0x4e/0x70 When early_xdbc_setup_hardware() fails, make sure to call early_iounmap() since xdbc_init() won't handle it. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Fixes: aeb9dd1de98c ("usb/early: Add driver for xhci debug capability") Link: https://lore.kernel.org/r/20250627-xdbc-v1-1-43cc8c317b1b@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/usb/early/xhci-dbc.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c index 341408410ed9..41118bba9197 100644 --- a/drivers/usb/early/xhci-dbc.c +++ b/drivers/usb/early/xhci-dbc.c @@ -681,6 +681,10 @@ int __init early_xdbc_setup_hardware(void) xdbc.table_base = NULL; xdbc.out_buf = NULL; + + early_iounmap(xdbc.xhci_base, xdbc.xhci_length); + xdbc.xhci_base = NULL; + xdbc.xhci_length = 0; } return ret; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 071/480] arm: dts: ti: omap: Fixup pinheader typo 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (69 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 070/480] usb: early: xhci-dbc: Fix early_ioremap leak Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 072/480] staging: gpib: Fix error code in board_type_ioctl() Greg Kroah-Hartman ` (420 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Albin Törnqvist, Kevin Hilman, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Albin Törnqvist <albin.tornqvist@codiax.se> [ Upstream commit a3a4be32b69c99fc20a66e0de83b91f8c882bf4c ] This commit fixes a typo introduced in commit ee368a10d0df ("ARM: dts: am335x-boneblack.dts: unique gpio-line-names"). gpio0_7 is located on the P9 header on the BBB. This was verified with a BeagleBone Black by toggling the pin and checking with a multimeter that it corresponds to pin 42 on the P9 header. Signed-off-by: Albin Törnqvist <albin.tornqvist@codiax.se> Link: https://lore.kernel.org/r/20250624114839.1465115-2-albin.tornqvist@codiax.se Fixes: ee368a10d0df ("ARM: dts: am335x-boneblack.dts: unique gpio-line-names") Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm/boot/dts/ti/omap/am335x-boneblack.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/ti/omap/am335x-boneblack.dts b/arch/arm/boot/dts/ti/omap/am335x-boneblack.dts index 16b567e3cb47..b4fdcf9c02b5 100644 --- a/arch/arm/boot/dts/ti/omap/am335x-boneblack.dts +++ b/arch/arm/boot/dts/ti/omap/am335x-boneblack.dts @@ -35,7 +35,7 @@ &gpio0 { "P9_18 [spi0_d1]", "P9_17 [spi0_cs0]", "[mmc0_cd]", - "P8_42A [ecappwm0]", + "P9_42A [ecappwm0]", "P8_35 [lcd d12]", "P8_33 [lcd d13]", "P8_31 [lcd d14]", -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 072/480] staging: gpib: Fix error code in board_type_ioctl() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (70 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 071/480] arm: dts: ti: omap: Fixup pinheader typo Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 073/480] staging: gpib: Fix error handling paths in cb_gpib_probe() Greg Kroah-Hartman ` (419 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Harshit Mogalapalli, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> [ Upstream commit aa07b790d79226f9bd0731d2c065db2823867cc5 ] When copy_from_user() fails it return number of bytes it wasn't able to copy. So the correct return value when copy_from_user() fails is -EFAULT. Fixes: 9dde4559e939 ("staging: gpib: Add GPIB common core driver") Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Link: https://lore.kernel.org/r/20250703064633.1955893-1-harshit.m.mogalapalli@oracle.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/staging/gpib/common/gpib_os.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/gpib/common/gpib_os.c b/drivers/staging/gpib/common/gpib_os.c index 8456b97290b8..01a9099a6c16 100644 --- a/drivers/staging/gpib/common/gpib_os.c +++ b/drivers/staging/gpib/common/gpib_os.c @@ -819,7 +819,7 @@ static int board_type_ioctl(gpib_file_private_t *file_priv, struct gpib_board *b retval = copy_from_user(&cmd, (void __user *)arg, sizeof(board_type_ioctl_t)); if (retval) - return retval; + return -EFAULT; for (list_ptr = registered_drivers.next; list_ptr != ®istered_drivers; list_ptr = list_ptr->next) { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 073/480] staging: gpib: Fix error handling paths in cb_gpib_probe() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (71 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 072/480] staging: gpib: Fix error code in board_type_ioctl() Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 074/480] soc/tegra: cbb: Clear ERR_FORCE register with ERR_STATUS Greg Kroah-Hartman ` (418 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Christophe JAILLET, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Christophe JAILLET <christophe.jaillet@wanadoo.fr> [ Upstream commit 1b0ee85ee7967a4d7a68080c3f6a66af69e4e0b4 ] If cb_gpib_config() fails, 'info' needs to be freed, as already done in the remove function. While at it, remove a pointless comment related to gpib_attach(). Fixes: e9dc69956d4d ("staging: gpib: Add Computer Boards GPIB driver") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/bf89d6f2f8b8c680720d02061fc4ebdd805deca8.1751709098.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/staging/gpib/cb7210/cb7210.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/staging/gpib/cb7210/cb7210.c b/drivers/staging/gpib/cb7210/cb7210.c index 6b22a33a8c4f..e6465331ffd0 100644 --- a/drivers/staging/gpib/cb7210/cb7210.c +++ b/drivers/staging/gpib/cb7210/cb7210.c @@ -1183,8 +1183,7 @@ struct local_info { static int cb_gpib_probe(struct pcmcia_device *link) { struct local_info *info; - -// int ret, i; + int ret; /* Allocate space for private device-specific data */ info = kzalloc(sizeof(*info), GFP_KERNEL); @@ -1210,8 +1209,16 @@ static int cb_gpib_probe(struct pcmcia_device *link) /* Register with Card Services */ curr_dev = link; - return cb_gpib_config(link); -} /* gpib_attach */ + ret = cb_gpib_config(link); + if (ret) + goto free_info; + + return 0; + +free_info: + kfree(info); + return ret; +} /* * This deletes a driver "instance". The device is de-registered -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 074/480] soc/tegra: cbb: Clear ERR_FORCE register with ERR_STATUS 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (72 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 073/480] staging: gpib: Fix error handling paths in cb_gpib_probe() Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 075/480] arm64: dts: rockchip: fix PHY handling for ROCK 4D Greg Kroah-Hartman ` (417 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Sumit Gupta, Thierry Reding, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Sumit Gupta <sumitg@nvidia.com> [ Upstream commit a0647bca8966db04b79af72851ebd04224a4da40 ] When error is injected with the ERR_FORCE register, then this register is not auto cleared on clearing the ERR_STATUS register. This causes repeated interrupts on error injection. To fix, set the ERR_FORCE to zero along with clearing the ERR_STATUS register after handling error. Fixes: fc2f151d2314 ("soc/tegra: cbb: Add driver for Tegra234 CBB 2.0") Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/soc/tegra/cbb/tegra234-cbb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/soc/tegra/cbb/tegra234-cbb.c b/drivers/soc/tegra/cbb/tegra234-cbb.c index c74629af9bb5..1da31ead2b5e 100644 --- a/drivers/soc/tegra/cbb/tegra234-cbb.c +++ b/drivers/soc/tegra/cbb/tegra234-cbb.c @@ -185,6 +185,8 @@ static void tegra234_cbb_error_clear(struct tegra_cbb *cbb) { struct tegra234_cbb *priv = to_tegra234_cbb(cbb); + writel(0, priv->mon + FABRIC_MN_MASTER_ERR_FORCE_0); + writel(0x3f, priv->mon + FABRIC_MN_MASTER_ERR_STATUS_0); dsb(sy); } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 075/480] arm64: dts: rockchip: fix PHY handling for ROCK 4D 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (73 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 074/480] soc/tegra: cbb: Clear ERR_FORCE register with ERR_STATUS Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 076/480] arm64: dts: st: fix timer used for ticks Greg Kroah-Hartman ` (416 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Sebastian Reichel, Heiko Stuebner, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Sebastian Reichel <sebastian.reichel@collabora.com> [ Upstream commit cd803da7c033e376a66793a43ee98e136bc6cc25 ] Old revisions of the ROCK 4D board have a dedicated crystal to supply the RTL8211F PHY's 25MHz clock input. At least some newer revisions instead use REFCLKO25M_GMAC0_OUT. The DT already has this half-prepared, but there are some issues: 1. The DT relies on auto-selecting the right PHY driver, which requires that it works good enough to read the ID registers. This does not work without the clock, which is handled by the PHY driver. By updating the compatible to contain the RTL8211F IDs, so that the operating system can choose the right PHY driver without relying on a pre-powered PHY. 2. Despite the name REFCLKO25M_GMAC0_OUT could also provide a different frequency, so ensure it is explicitly set to 25 MHz as expected by the PHY. 3. While at it switch from deprecated "enable-gpio" to standard "enable-gpios". Fixes: a0fb7eca9c09 ("arm64: dts: rockchip: Add Radxa ROCK 4D device tree") Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20250704-rk3576-rock4d-phy-handling-fixes-v1-1-1d64130c4139@kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts b/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts index 6756403111e7..0a93853cdf43 100644 --- a/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts +++ b/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts @@ -641,14 +641,16 @@ hym8563: rtc@51 { &mdio0 { rgmii_phy0: ethernet-phy@1 { - compatible = "ethernet-phy-ieee802.3-c22"; + compatible = "ethernet-phy-id001c.c916"; reg = <0x1>; clocks = <&cru REFCLKO25M_GMAC0_OUT>; + assigned-clocks = <&cru REFCLKO25M_GMAC0_OUT>; + assigned-clock-rates = <25000000>; pinctrl-names = "default"; pinctrl-0 = <&rtl8211f_rst>; reset-assert-us = <20000>; reset-deassert-us = <100000>; - reset-gpio = <&gpio2 RK_PB5 GPIO_ACTIVE_LOW>; + reset-gpios = <&gpio2 RK_PB5 GPIO_ACTIVE_LOW>; }; }; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 076/480] arm64: dts: st: fix timer used for ticks 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (74 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 075/480] arm64: dts: rockchip: fix PHY handling for ROCK 4D Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 077/480] selftests: breakpoints: use suspend_stats to reliably check suspend success Greg Kroah-Hartman ` (415 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Patrick Delaunay, Alexandre Torgue, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Patrick Delaunay <patrick.delaunay@foss.st.com> [ Upstream commit 9ec406ac4b7de3e8040a503429d1a5d389bfdaf6 ] Remove always-on on generic ARM timer as the clock source provided by STGEN is deactivated in low power mode, STOP1 by example. Fixes: 5d30d03aaf78 ("arm64: dts: st: introduce stm32mp25 SoCs family") Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20250515151238.1.I85271ddb811a7cf73532fec90de7281cb24ce260@changeid Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm64/boot/dts/st/stm32mp251.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi index 87110f91e489..afe88e04875a 100644 --- a/arch/arm64/boot/dts/st/stm32mp251.dtsi +++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi @@ -150,7 +150,7 @@ timer { <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>, <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>, <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>; - always-on; + arm,no-tick-in-suspend; }; soc@0 { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 077/480] selftests: breakpoints: use suspend_stats to reliably check suspend success 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (75 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 076/480] arm64: dts: st: fix timer used for ticks Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 078/480] ARM: dts: imx6ul-kontron-bl-common: Fix RTS polarity for RS485 interface Greg Kroah-Hartman ` (414 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Moon Hee Lee, Shuah Khan, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Moon Hee Lee <moonhee.lee.ca@gmail.com> [ Upstream commit 07b7c2b4eca3f83ce9cd5ee3fa1c7c001d721c69 ] The step_after_suspend_test verifies that the system successfully suspended and resumed by setting a timerfd and checking whether the timer fully expired. However, this method is unreliable due to timing races. In practice, the system may take time to enter suspend, during which the timer may expire just before or during the transition. As a result, the remaining time after resume may show non-zero nanoseconds, even if suspend/resume completed successfully. This leads to false test failures. Replace the timer-based check with a read from /sys/power/suspend_stats/success. This counter is incremented only after a full suspend/resume cycle, providing a reliable and race-free indicator. Also remove the unused file descriptor for /sys/power/state, which remained after switching to a system() call to trigger suspend [1]. [1] https://lore.kernel.org/all/20240930224025.2858767-1-yifei.l.liu@oracle.com/ Link: https://lore.kernel.org/r/20250626191626.36794-1-moonhee.lee.ca@gmail.com Fixes: c66be905cda2 ("selftests: breakpoints: use remaining time to check if suspend succeed") Signed-off-by: Moon Hee Lee <moonhee.lee.ca@gmail.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- .../breakpoints/step_after_suspend_test.c | 41 ++++++++++++++----- 1 file changed, 31 insertions(+), 10 deletions(-) diff --git a/tools/testing/selftests/breakpoints/step_after_suspend_test.c b/tools/testing/selftests/breakpoints/step_after_suspend_test.c index 8d275f03e977..8d233ac95696 100644 --- a/tools/testing/selftests/breakpoints/step_after_suspend_test.c +++ b/tools/testing/selftests/breakpoints/step_after_suspend_test.c @@ -127,22 +127,42 @@ int run_test(int cpu) return KSFT_PASS; } +/* + * Reads the suspend success count from sysfs. + * Returns the count on success or exits on failure. + */ +static int get_suspend_success_count_or_fail(void) +{ + FILE *fp; + int val; + + fp = fopen("/sys/power/suspend_stats/success", "r"); + if (!fp) + ksft_exit_fail_msg( + "Failed to open suspend_stats/success: %s\n", + strerror(errno)); + + if (fscanf(fp, "%d", &val) != 1) { + fclose(fp); + ksft_exit_fail_msg( + "Failed to read suspend success count\n"); + } + + fclose(fp); + return val; +} + void suspend(void) { - int power_state_fd; int timerfd; int err; + int count_before; + int count_after; struct itimerspec spec = {}; if (getuid() != 0) ksft_exit_skip("Please run the test as root - Exiting.\n"); - power_state_fd = open("/sys/power/state", O_RDWR); - if (power_state_fd < 0) - ksft_exit_fail_msg( - "open(\"/sys/power/state\") failed %s)\n", - strerror(errno)); - timerfd = timerfd_create(CLOCK_BOOTTIME_ALARM, 0); if (timerfd < 0) ksft_exit_fail_msg("timerfd_create() failed\n"); @@ -152,14 +172,15 @@ void suspend(void) if (err < 0) ksft_exit_fail_msg("timerfd_settime() failed\n"); + count_before = get_suspend_success_count_or_fail(); + system("(echo mem > /sys/power/state) 2> /dev/null"); - timerfd_gettime(timerfd, &spec); - if (spec.it_value.tv_sec != 0 || spec.it_value.tv_nsec != 0) + count_after = get_suspend_success_count_or_fail(); + if (count_after <= count_before) ksft_exit_fail_msg("Failed to enter Suspend state\n"); close(timerfd); - close(power_state_fd); } int main(int argc, char **argv) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 078/480] ARM: dts: imx6ul-kontron-bl-common: Fix RTS polarity for RS485 interface 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (76 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 077/480] selftests: breakpoints: use suspend_stats to reliably check suspend success Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 079/480] arm64: dts: imx8mm-beacon: Fix HS400 USDHC clock speed Greg Kroah-Hartman ` (413 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Annette Kobou, Frieder Schrempf, Shawn Guo, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Annette Kobou <annette.kobou@kontron.de> [ Upstream commit 47ef5256124fb939d8157b13ca048c902435cf23 ] The polarity of the DE signal of the transceiver is active-high for sending. Therefore rs485-rts-active-low is wrong and needs to be removed to make RS485 transmissions work. Signed-off-by: Annette Kobou <annette.kobou@kontron.de> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Fixes: 1ea4b76cdfde ("ARM: dts: imx6ul-kontron-n6310: Add Kontron i.MX6UL N6310 SoM and boards") Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm/boot/dts/nxp/imx/imx6ul-kontron-bl-common.dtsi | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/boot/dts/nxp/imx/imx6ul-kontron-bl-common.dtsi b/arch/arm/boot/dts/nxp/imx/imx6ul-kontron-bl-common.dtsi index 29d2f86d5e34..f4c45e964daf 100644 --- a/arch/arm/boot/dts/nxp/imx/imx6ul-kontron-bl-common.dtsi +++ b/arch/arm/boot/dts/nxp/imx/imx6ul-kontron-bl-common.dtsi @@ -168,7 +168,6 @@ &uart2 { pinctrl-0 = <&pinctrl_uart2>; linux,rs485-enabled-at-boot-time; rs485-rx-during-tx; - rs485-rts-active-low; uart-has-rtscts; status = "okay"; }; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 079/480] arm64: dts: imx8mm-beacon: Fix HS400 USDHC clock speed 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (77 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 078/480] ARM: dts: imx6ul-kontron-bl-common: Fix RTS polarity for RS485 interface Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 080/480] arm64: dts: imx8mn-beacon: " Greg Kroah-Hartman ` (412 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Adam Ford, Fabio Estevam, Shawn Guo, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Adam Ford <aford173@gmail.com> [ Upstream commit f83f69097a302ed2a2775975ddcf12e6a5ac6ec3 ] The reference manual for the i.MX8MM states the clock rate in MMC mode is 1/2 of the input clock, therefore to properly run at HS400 rates, the input clock must be 400MHz to operate at 200MHz. Currently the clock is set to 200MHz which is half the rate it should be, so the throughput is half of what it should be for HS400 operation. Fixes: 593816fa2f35 ("arm64: dts: imx: Add Beacon i.MX8m-Mini development kit") Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi index 9ba0cb89fa24..c0f00835e47d 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi @@ -286,6 +286,8 @@ &usdhc3 { pinctrl-0 = <&pinctrl_usdhc3>; pinctrl-1 = <&pinctrl_usdhc3_100mhz>; pinctrl-2 = <&pinctrl_usdhc3_200mhz>; + assigned-clocks = <&clk IMX8MM_CLK_USDHC3>; + assigned-clock-rates = <400000000>; bus-width = <8>; non-removable; status = "okay"; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 080/480] arm64: dts: imx8mn-beacon: Fix HS400 USDHC clock speed 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (78 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 079/480] arm64: dts: imx8mm-beacon: Fix HS400 USDHC clock speed Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 081/480] arm64: dts: rockchip: Fix pinctrl node names for RK3528 Greg Kroah-Hartman ` (411 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Adam Ford, Fabio Estevam, Shawn Guo, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Adam Ford <aford173@gmail.com> [ Upstream commit e16ad6c79906bba5e2ac499492b6a5b29ab19d6c ] The reference manual for the i.MX8MN states the clock rate in MMC mode is 1/2 of the input clock, therefore to properly run at HS400 rates, the input clock must be 400MHz to operate at 200MHz. Currently the clock is set to 200MHz which is half the rate it should be, so the throughput is half of what it should be for HS400 operation. Fixes: 36ca3c8ccb53 ("arm64: dts: imx: Add Beacon i.MX8M Nano development kit") Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi index bb11590473a4..353d0c9ff35c 100644 --- a/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi @@ -297,6 +297,8 @@ &usdhc3 { pinctrl-0 = <&pinctrl_usdhc3>; pinctrl-1 = <&pinctrl_usdhc3_100mhz>; pinctrl-2 = <&pinctrl_usdhc3_200mhz>; + assigned-clocks = <&clk IMX8MN_CLK_USDHC3>; + assigned-clock-rates = <400000000>; bus-width = <8>; non-removable; status = "okay"; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 081/480] arm64: dts: rockchip: Fix pinctrl node names for RK3528 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (79 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 080/480] arm64: dts: imx8mn-beacon: " Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 082/480] PM / devfreq: Check governor before using governor->name Greg Kroah-Hartman ` (410 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Jonas Karlman, Heiko Stuebner, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jonas Karlman <jonas@kwiboo.se> [ Upstream commit f2792bf1c7a54ef23fb3a84286b66f427bfc4853 ] Following warnings can be observed with CHECK_DTBS=y for the RK3528: rk3528-pinctrl.dtsi:101.36-105.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym0-led_dpx: Character '_' not recommended in node name rk3528-pinctrl.dtsi:108.38-112.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym0-led_link: Character '_' not recommended in node name rk3528-pinctrl.dtsi:115.36-119.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym0-led_spd: Character '_' not recommended in node name rk3528-pinctrl.dtsi:122.36-126.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym1-led_dpx: Character '_' not recommended in node name rk3528-pinctrl.dtsi:129.38-133.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym1-led_link: Character '_' not recommended in node name rk3528-pinctrl.dtsi:136.36-140.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym1-led_spd: Character '_' not recommended in node name rk3528-pinctrl.dtsi:782.32-790.5: Warning (node_name_chars_strict): /pinctrl/rgmii/rgmii-rx_bus2: Character '_' not recommended in node name rk3528-pinctrl.dtsi:793.32-801.5: Warning (node_name_chars_strict): /pinctrl/rgmii/rgmii-tx_bus2: Character '_' not recommended in node name rk3528-pinctrl.dtsi:804.36-810.5: Warning (node_name_chars_strict): /pinctrl/rgmii/rgmii-rgmii_clk: Character '_' not recommended in node name rk3528-pinctrl.dtsi:813.36-823.5: Warning (node_name_chars_strict): /pinctrl/rgmii/rgmii-rgmii_bus: Character '_' not recommended in node name Rename the affected nodes to fix these warnings. Fixes: a31fad19ae39 ("arm64: dts: rockchip: Add pinctrl and gpio nodes for RK3528") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20250621113859.2146400-1-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org> --- .../boot/dts/rockchip/rk3528-pinctrl.dtsi | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3528-pinctrl.dtsi b/arch/arm64/boot/dts/rockchip/rk3528-pinctrl.dtsi index ea051362fb26..59b75c91bbb7 100644 --- a/arch/arm64/boot/dts/rockchip/rk3528-pinctrl.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3528-pinctrl.dtsi @@ -98,42 +98,42 @@ eth_pins: eth-pins { fephy { /omit-if-no-ref/ - fephym0_led_dpx: fephym0-led_dpx { + fephym0_led_dpx: fephym0-led-dpx { rockchip,pins = /* fephy_led_dpx_m0 */ <4 RK_PB5 2 &pcfg_pull_none>; }; /omit-if-no-ref/ - fephym0_led_link: fephym0-led_link { + fephym0_led_link: fephym0-led-link { rockchip,pins = /* fephy_led_link_m0 */ <4 RK_PC0 2 &pcfg_pull_none>; }; /omit-if-no-ref/ - fephym0_led_spd: fephym0-led_spd { + fephym0_led_spd: fephym0-led-spd { rockchip,pins = /* fephy_led_spd_m0 */ <4 RK_PB7 2 &pcfg_pull_none>; }; /omit-if-no-ref/ - fephym1_led_dpx: fephym1-led_dpx { + fephym1_led_dpx: fephym1-led-dpx { rockchip,pins = /* fephy_led_dpx_m1 */ <2 RK_PA4 5 &pcfg_pull_none>; }; /omit-if-no-ref/ - fephym1_led_link: fephym1-led_link { + fephym1_led_link: fephym1-led-link { rockchip,pins = /* fephy_led_link_m1 */ <2 RK_PA6 5 &pcfg_pull_none>; }; /omit-if-no-ref/ - fephym1_led_spd: fephym1-led_spd { + fephym1_led_spd: fephym1-led-spd { rockchip,pins = /* fephy_led_spd_m1 */ <2 RK_PA5 5 &pcfg_pull_none>; @@ -779,7 +779,7 @@ rgmii_miim: rgmii-miim { }; /omit-if-no-ref/ - rgmii_rx_bus2: rgmii-rx_bus2 { + rgmii_rx_bus2: rgmii-rx-bus2 { rockchip,pins = /* rgmii_rxd0 */ <3 RK_PA3 2 &pcfg_pull_none>, @@ -790,7 +790,7 @@ rgmii_rx_bus2: rgmii-rx_bus2 { }; /omit-if-no-ref/ - rgmii_tx_bus2: rgmii-tx_bus2 { + rgmii_tx_bus2: rgmii-tx-bus2 { rockchip,pins = /* rgmii_txd0 */ <3 RK_PA1 2 &pcfg_pull_none_drv_level_2>, @@ -801,7 +801,7 @@ rgmii_tx_bus2: rgmii-tx_bus2 { }; /omit-if-no-ref/ - rgmii_rgmii_clk: rgmii-rgmii_clk { + rgmii_rgmii_clk: rgmii-rgmii-clk { rockchip,pins = /* rgmii_rxclk */ <3 RK_PA5 2 &pcfg_pull_none>, @@ -810,7 +810,7 @@ rgmii_rgmii_clk: rgmii-rgmii_clk { }; /omit-if-no-ref/ - rgmii_rgmii_bus: rgmii-rgmii_bus { + rgmii_rgmii_bus: rgmii-rgmii-bus { rockchip,pins = /* rgmii_rxd2 */ <3 RK_PA7 2 &pcfg_pull_none>, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 082/480] PM / devfreq: Check governor before using governor->name 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (80 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 081/480] arm64: dts: rockchip: Fix pinctrl node names for RK3528 Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 083/480] PM / devfreq: Fix a index typo in trans_stat Greg Kroah-Hartman ` (409 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Lifeng Zheng, Chanwoo Choi, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Lifeng Zheng <zhenglifeng1@huawei.com> [ Upstream commit bab7834c03820eb11269bc48f07c3800192460d2 ] Commit 96ffcdf239de ("PM / devfreq: Remove redundant governor_name from struct devfreq") removes governor_name and uses governor->name to replace it. But devfreq->governor may be NULL and directly using devfreq->governor->name may cause null pointer exception. Move the check of governor to before using governor->name. Fixes: 96ffcdf239de ("PM / devfreq: Remove redundant governor_name from struct devfreq") Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://lore.kernel.org/lkml/20250421030020.3108405-5-zhenglifeng1@huawei.com/ Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/devfreq/devfreq.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c index 98657d3b9435..713e6e52cca1 100644 --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq/devfreq.c @@ -1382,15 +1382,11 @@ int devfreq_remove_governor(struct devfreq_governor *governor) int ret; struct device *dev = devfreq->dev.parent; + if (!devfreq->governor) + continue; + if (!strncmp(devfreq->governor->name, governor->name, DEVFREQ_NAME_LEN)) { - /* we should have a devfreq governor! */ - if (!devfreq->governor) { - dev_warn(dev, "%s: Governor %s NOT present\n", - __func__, governor->name); - continue; - /* Fall through */ - } ret = devfreq->governor->event_handler(devfreq, DEVFREQ_GOV_STOP, NULL); if (ret) { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 083/480] PM / devfreq: Fix a index typo in trans_stat 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (81 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 082/480] PM / devfreq: Check governor before using governor->name Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 084/480] cpufreq: intel_pstate: Always use HWP_DESIRED_PERF in passive mode Greg Kroah-Hartman ` (408 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, pls, Chanwoo Choi, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Chanwoo Choi <cw00.choi@samsung.com> [ Upstream commit 78c5845fbbf6aaeb9959c5fbaee5cc53ef5f38c2 ] Fixes: 4920ee6dcfaf ("PM / devfreq: Convert to use sysfs_emit_at() API") Signed-off-by: pls <pleasurefish@126.com> Link: https://patchwork.kernel.org/project/linux-pm/patch/20250515143100.17849-1-chanwoo@kernel.org/ Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/devfreq/devfreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c index 713e6e52cca1..0d9f3d3282ec 100644 --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq/devfreq.c @@ -1739,7 +1739,7 @@ static ssize_t trans_stat_show(struct device *dev, for (i = 0; i < max_state; i++) { if (len >= PAGE_SIZE - 1) break; - if (df->freq_table[2] == df->previous_freq) + if (df->freq_table[i] == df->previous_freq) len += sysfs_emit_at(buf, len, "*"); else len += sysfs_emit_at(buf, len, " "); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 084/480] cpufreq: intel_pstate: Always use HWP_DESIRED_PERF in passive mode 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (82 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 083/480] PM / devfreq: Fix a index typo in trans_stat Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 085/480] cpufreq: Initialize cpufreq-based frequency-invariance later Greg Kroah-Hartman ` (407 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Rafael J. Wysocki, Shashank Balaji, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [ Upstream commit 1cefe495cacba5fb0417da3a75a1a76e3546d176 ] In the passive mode, intel_cpufreq_update_pstate() sets HWP_MIN_PERF in accordance with the target frequency to ensure delivering adequate performance, but it sets HWP_DESIRED_PERF to 0, so the processor has no indication that the desired performance level is actually equal to the floor one. This may cause it to choose a performance point way above the desired level. Moreover, this is inconsistent with intel_cpufreq_adjust_perf() which actually sets HWP_DESIRED_PERF in accordance with the target performance value. Address this by adjusting intel_cpufreq_update_pstate() to pass target_pstate as both the minimum and the desired performance levels to intel_cpufreq_hwp_update(). Fixes: a365ab6b9dfb ("cpufreq: intel_pstate: Implement the ->adjust_perf() callback") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Shashank Balaji <shashank.mahadasyam@sony.com> Link: https://patch.msgid.link/6173276.lOV4Wx5bFT@rjwysocki.net Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/cpufreq/intel_pstate.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index ba9bf06f1c77..f9205fe199b8 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -3130,8 +3130,8 @@ static int intel_cpufreq_update_pstate(struct cpufreq_policy *policy, int max_pstate = policy->strict_target ? target_pstate : cpu->max_perf_ratio; - intel_cpufreq_hwp_update(cpu, target_pstate, max_pstate, 0, - fast_switch); + intel_cpufreq_hwp_update(cpu, target_pstate, max_pstate, + target_pstate, fast_switch); } else if (target_pstate != old_pstate) { intel_cpufreq_perf_ctl_update(cpu, target_pstate, fast_switch); } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 085/480] cpufreq: Initialize cpufreq-based frequency-invariance later 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (83 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 084/480] cpufreq: intel_pstate: Always use HWP_DESIRED_PERF in passive mode Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 086/480] cpufreq: Init policy->rwsem before it may be possibly used Greg Kroah-Hartman ` (406 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Lifeng Zheng, Rafael J. Wysocki, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Lifeng Zheng <zhenglifeng1@huawei.com> [ Upstream commit 2a6c727387062a2ea79eb6cf5004820cb1b0afe2 ] The cpufreq-based invariance is enabled in cpufreq_register_driver(), but never disabled after registration fails. Move the invariance initialization to where all other initializations have been successfully done to solve this problem. Fixes: 874f63531064 ("cpufreq: report whether cpufreq supports Frequency Invariance (FI)") Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20250709104145.2348017-2-zhenglifeng1@huawei.com [ rjw: New subject ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/cpufreq/cpufreq.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index f45ded62b0e0..ea2a8d86d640 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -3009,15 +3009,6 @@ int cpufreq_register_driver(struct cpufreq_driver *driver_data) cpufreq_driver = driver_data; write_unlock_irqrestore(&cpufreq_driver_lock, flags); - /* - * Mark support for the scheduler's frequency invariance engine for - * drivers that implement target(), target_index() or fast_switch(). - */ - if (!cpufreq_driver->setpolicy) { - static_branch_enable_cpuslocked(&cpufreq_freq_invariance); - pr_debug("supports frequency invariance"); - } - if (driver_data->setpolicy) driver_data->flags |= CPUFREQ_CONST_LOOPS; @@ -3048,6 +3039,15 @@ int cpufreq_register_driver(struct cpufreq_driver *driver_data) hp_online = ret; ret = 0; + /* + * Mark support for the scheduler's frequency invariance engine for + * drivers that implement target(), target_index() or fast_switch(). + */ + if (!cpufreq_driver->setpolicy) { + static_branch_enable_cpuslocked(&cpufreq_freq_invariance); + pr_debug("supports frequency invariance"); + } + pr_debug("driver %s up and running\n", driver_data->name); goto out; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 086/480] cpufreq: Init policy->rwsem before it may be possibly used 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (84 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 085/480] cpufreq: Initialize cpufreq-based frequency-invariance later Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 087/480] ASoC: SDCA: Allow read-only controls to be deferrable Greg Kroah-Hartman ` (405 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Lifeng Zheng, Rafael J. Wysocki, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Lifeng Zheng <zhenglifeng1@huawei.com> [ Upstream commit d1378d1d7edb3a4c4935a44fe834ae135be03564 ] In cpufreq_policy_put_kobj(), policy->rwsem is used. But in cpufreq_policy_alloc(), if freq_qos_add_notifier() returns an error, error path via err_kobj_remove or err_min_qos_notifier will be reached and cpufreq_policy_put_kobj() will be called before policy->rwsem is initialized. Thus, the calling of init_rwsem() should be moved to where before these two error paths can be reached. Fixes: 67d874c3b2c6 ("cpufreq: Register notifiers with the PM QoS framework") Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20250709104145.2348017-3-zhenglifeng1@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/cpufreq/cpufreq.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index ea2a8d86d640..5c84d56341e2 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1323,6 +1323,8 @@ static struct cpufreq_policy *cpufreq_policy_alloc(unsigned int cpu) goto err_free_real_cpus; } + init_rwsem(&policy->rwsem); + freq_constraints_init(&policy->constraints); policy->nb_min.notifier_call = cpufreq_notifier_min; @@ -1345,7 +1347,6 @@ static struct cpufreq_policy *cpufreq_policy_alloc(unsigned int cpu) } INIT_LIST_HEAD(&policy->policy_list); - init_rwsem(&policy->rwsem); spin_lock_init(&policy->transition_lock); init_waitqueue_head(&policy->transition_wait); INIT_WORK(&policy->update, handle_update); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 087/480] ASoC: SDCA: Allow read-only controls to be deferrable 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (85 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 086/480] cpufreq: Init policy->rwsem before it may be possibly used Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 088/480] staging: greybus: gbphy: fix up const issue with the match callback Greg Kroah-Hartman ` (404 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Charles Keepax, Pierre-Louis Bossart, Mark Brown, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Charles Keepax <ckeepax@opensource.cirrus.com> [ Upstream commit 4eb6ad5d2080681b531db2c1764246f9a868062f ] The current SDCA Control parsing only checks the deferrable flag for Read/Write and Dual Ranked controls. However, reads can defer as well as writes so Read Only controls should also check for the deferrable flag. Add the handling for this into find_sdca_entity_control(). Fixes: 42b144cb6a2d ("ASoC: SDCA: Add SDCA Control parsing") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20250707124155.2596744-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- sound/soc/sdca/sdca_functions.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/soc/sdca/sdca_functions.c b/sound/soc/sdca/sdca_functions.c index 493f390f087a..15aa57a07c73 100644 --- a/sound/soc/sdca/sdca_functions.c +++ b/sound/soc/sdca/sdca_functions.c @@ -880,7 +880,8 @@ static int find_sdca_entity_control(struct device *dev, struct sdca_entity *enti control->value = tmp; control->has_fixed = true; } - + fallthrough; + case SDCA_ACCESS_MODE_RO: control->deferrable = fwnode_property_read_bool(control_node, "mipi-sdca-control-deferrable"); break; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 088/480] staging: greybus: gbphy: fix up const issue with the match callback 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (86 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 087/480] ASoC: SDCA: Allow read-only controls to be deferrable Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 089/480] samples: mei: Fix building on musl libc Greg Kroah-Hartman ` (403 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Alex Elder, greybus-dev, Johan Hovold, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [ Upstream commit ce32eff1cf3ae8ac2596171dd0af1657634c83eb ] gbphy_dev_match_id() should be taking a const pointer, as the pointer passed to it from the container_of() call was const to start with (it was accidentally cast away with the call.) Fix this all up by correctly marking the pointer types. Cc: Alex Elder <elder@kernel.org> Cc: greybus-dev@lists.linaro.org Fixes: d69d80484598 ("driver core: have match() callback in struct bus_type take a const *") Reviewed-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/2025070115-reoccupy-showy-e2ad@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/staging/greybus/gbphy.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/greybus/gbphy.c b/drivers/staging/greybus/gbphy.c index 6adcad286633..60cf09a302a7 100644 --- a/drivers/staging/greybus/gbphy.c +++ b/drivers/staging/greybus/gbphy.c @@ -102,8 +102,8 @@ static int gbphy_dev_uevent(const struct device *dev, struct kobj_uevent_env *en } static const struct gbphy_device_id * -gbphy_dev_match_id(struct gbphy_device *gbphy_dev, - struct gbphy_driver *gbphy_drv) +gbphy_dev_match_id(const struct gbphy_device *gbphy_dev, + const struct gbphy_driver *gbphy_drv) { const struct gbphy_device_id *id = gbphy_drv->id_table; @@ -119,7 +119,7 @@ gbphy_dev_match_id(struct gbphy_device *gbphy_dev, static int gbphy_dev_match(struct device *dev, const struct device_driver *drv) { - struct gbphy_driver *gbphy_drv = to_gbphy_driver(drv); + const struct gbphy_driver *gbphy_drv = to_gbphy_driver(drv); struct gbphy_device *gbphy_dev = to_gbphy_dev(dev); const struct gbphy_device_id *id; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 089/480] samples: mei: Fix building on musl libc 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (87 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 088/480] staging: greybus: gbphy: fix up const issue with the match callback Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 090/480] soc: qcom: pmic_glink: fix OF node leak Greg Kroah-Hartman ` (402 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Brahmajit Das, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Brahmajit Das <listout@listout.xyz> [ Upstream commit 239df3e4b4752524e7c0fb3417c218d8063654b4 ] The header bits/wordsize.h is glibc specific and on building on musl with allyesconfig results in samples/mei/mei-amt-version.c:77:10: fatal error: bits/wordsize.h: No such file or directory 77 | #include <bits/wordsize.h> | ^~~~~~~~~~~~~~~~~ mei-amt-version.c build file without bits/wordsize.h on musl and glibc. However on musl we get the follwing error without sys/time.h samples/mei/mei-amt-version.c: In function 'mei_recv_msg': samples/mei/mei-amt-version.c:159:24: error: storage size of 'tv' isn't known 159 | struct timeval tv; | ^~ samples/mei/mei-amt-version.c:160:9: error: unknown type name 'fd_set' 160 | fd_set set; | ^~~~~~ samples/mei/mei-amt-version.c:168:9: error: implicit declaration of function 'FD_ZERO' [-Wimplicit-function-declaration] 168 | FD_ZERO(&set); | ^~~~~~~ samples/mei/mei-amt-version.c:169:9: error: implicit declaration of function 'FD_SET'; did you mean 'L_SET'? [-Wimplicit-function-declaration] 169 | FD_SET(me->fd, &set); | ^~~~~~ | L_SET samples/mei/mei-amt-version.c:170:14: error: implicit declaration of function 'select' [-Wimplicit-function-declaration] 170 | rc = select(me->fd + 1, &set, NULL, NULL, &tv); | ^~~~~~ samples/mei/mei-amt-version.c:171:23: error: implicit declaration of function 'FD_ISSET' [-Wimplicit-function-declaration] 171 | if (rc > 0 && FD_ISSET(me->fd, &set)) { | ^~~~~~~~ samples/mei/mei-amt-version.c:159:24: warning: unused variable 'tv' [-Wunused-variable] 159 | struct timeval tv; | ^~ Hence the the file has been included. Fixes: c52827cc4ddf ("staging/mei: add mei user space example") Signed-off-by: Brahmajit Das <listout@listout.xyz> Link: https://lore.kernel.org/r/20250702135955.24955-1-listout@listout.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- samples/mei/mei-amt-version.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/samples/mei/mei-amt-version.c b/samples/mei/mei-amt-version.c index 867debd3b912..1d7254bcb44c 100644 --- a/samples/mei/mei-amt-version.c +++ b/samples/mei/mei-amt-version.c @@ -69,11 +69,11 @@ #include <string.h> #include <fcntl.h> #include <sys/ioctl.h> +#include <sys/time.h> #include <unistd.h> #include <errno.h> #include <stdint.h> #include <stdbool.h> -#include <bits/wordsize.h> #include <linux/mei.h> /***************************************************************************** -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 090/480] soc: qcom: pmic_glink: fix OF node leak 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (88 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 089/480] samples: mei: Fix building on musl libc Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:44 ` [PATCH 6.15 091/480] interconnect: qcom: sc8280xp: specify num_links for qnm_a1noc_cfg Greg Kroah-Hartman ` (401 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Bjorn Andersson, Johan Hovold, Konrad Dybcio, Bjorn Andersson, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Johan Hovold <johan@kernel.org> [ Upstream commit 65702c3d293e45d3cac5e4e175296a9c90404326 ] Make sure to drop the OF node reference taken when registering the auxiliary devices when the devices are later released. Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver") Cc: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250708085717.15922-1-johan@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/soc/qcom/pmic_glink.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/soc/qcom/pmic_glink.c b/drivers/soc/qcom/pmic_glink.c index cde19cdfd3c7..e57b47c17c3c 100644 --- a/drivers/soc/qcom/pmic_glink.c +++ b/drivers/soc/qcom/pmic_glink.c @@ -167,7 +167,10 @@ static int pmic_glink_rpmsg_callback(struct rpmsg_device *rpdev, void *data, return 0; } -static void pmic_glink_aux_release(struct device *dev) {} +static void pmic_glink_aux_release(struct device *dev) +{ + of_node_put(dev->of_node); +} static int pmic_glink_add_aux_device(struct pmic_glink *pg, struct auxiliary_device *aux, @@ -181,8 +184,10 @@ static int pmic_glink_add_aux_device(struct pmic_glink *pg, aux->dev.release = pmic_glink_aux_release; device_set_of_node_from_dev(&aux->dev, parent); ret = auxiliary_device_init(aux); - if (ret) + if (ret) { + of_node_put(aux->dev.of_node); return ret; + } ret = auxiliary_device_add(aux); if (ret) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 091/480] interconnect: qcom: sc8280xp: specify num_links for qnm_a1noc_cfg 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (89 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 090/480] soc: qcom: pmic_glink: fix OF node leak Greg Kroah-Hartman @ 2025-08-12 17:44 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 092/480] interconnect: qcom: sc8180x: specify num_nodes Greg Kroah-Hartman ` (400 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:44 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Dmitry Baryshkov, Georgi Djakov, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> [ Upstream commit 02ee375506dceb7d32007821a2bff31504d64b99 ] The qnm_a1noc_cfg declaration didn't include .num_links definition, fix it. Fixes: f29dabda7917 ("interconnect: qcom: Add SC8280XP interconnect provider") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250704-rework-icc-v2-1-875fac996ef5@oss.qualcomm.com Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/interconnect/qcom/sc8280xp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/interconnect/qcom/sc8280xp.c b/drivers/interconnect/qcom/sc8280xp.c index 0270f6c64481..c646cdf8a19b 100644 --- a/drivers/interconnect/qcom/sc8280xp.c +++ b/drivers/interconnect/qcom/sc8280xp.c @@ -48,6 +48,7 @@ static struct qcom_icc_node qnm_a1noc_cfg = { .id = SC8280XP_MASTER_A1NOC_CFG, .channels = 1, .buswidth = 4, + .num_links = 1, .links = { SC8280XP_SLAVE_SERVICE_A1NOC }, }; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 092/480] interconnect: qcom: sc8180x: specify num_nodes 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (90 preceding siblings ...) 2025-08-12 17:44 ` [PATCH 6.15 091/480] interconnect: qcom: sc8280xp: specify num_links for qnm_a1noc_cfg Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 093/480] interconnect: qcom: qcs615: Drop IP0 interconnects Greg Kroah-Hartman ` (399 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Dmitry Baryshkov, Georgi Djakov, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> [ Upstream commit 7e0b59496a02d25828612721e846ea4b717a97b9 ] Specify .num_nodes for several BCMs which missed this declaration. Fixes: 04548d4e2798 ("interconnect: qcom: sc8180x: Reformat node and bcm definitions") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250704-rework-icc-v2-2-875fac996ef5@oss.qualcomm.com Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/interconnect/qcom/sc8180x.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/interconnect/qcom/sc8180x.c b/drivers/interconnect/qcom/sc8180x.c index a741badaa966..4dd1d2f2e821 100644 --- a/drivers/interconnect/qcom/sc8180x.c +++ b/drivers/interconnect/qcom/sc8180x.c @@ -1492,34 +1492,40 @@ static struct qcom_icc_bcm bcm_sh3 = { static struct qcom_icc_bcm bcm_sn0 = { .name = "SN0", + .num_nodes = 1, .nodes = { &slv_qns_gemnoc_sf } }; static struct qcom_icc_bcm bcm_sn1 = { .name = "SN1", + .num_nodes = 1, .nodes = { &slv_qxs_imem } }; static struct qcom_icc_bcm bcm_sn2 = { .name = "SN2", .keepalive = true, + .num_nodes = 1, .nodes = { &slv_qns_gemnoc_gc } }; static struct qcom_icc_bcm bcm_co2 = { .name = "CO2", + .num_nodes = 1, .nodes = { &mas_qnm_npu } }; static struct qcom_icc_bcm bcm_sn3 = { .name = "SN3", .keepalive = true, + .num_nodes = 2, .nodes = { &slv_srvc_aggre1_noc, &slv_qns_cnoc } }; static struct qcom_icc_bcm bcm_sn4 = { .name = "SN4", + .num_nodes = 1, .nodes = { &slv_qxs_pimem } }; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 093/480] interconnect: qcom: qcs615: Drop IP0 interconnects 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (91 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 092/480] interconnect: qcom: sc8180x: specify num_nodes Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-13 8:57 ` Konrad Dybcio 2025-08-12 17:45 ` [PATCH 6.15 094/480] bus: mhi: host: pci_generic: Fix the modem name of Foxconn T99W640 Greg Kroah-Hartman ` (398 subsequent siblings) 491 siblings, 1 reply; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Konrad Dybcio, Dmitry Baryshkov, Georgi Djakov, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> [ Upstream commit cbabc73e85be9e706a5051c9416de4a8d391cf57 ] In the same spirit as e.g. Commit b136d257ee0b ("interconnect: qcom: sc8280xp: Drop IP0 interconnects"), drop the resources that should be taken care of through the clk-rpmh driver. Fixes: 77d79677b04b ("interconnect: qcom: add QCS615 interconnect provider driver") Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250627-topic-qcs615_icc_ipa-v1-2-dc47596cde69@oss.qualcomm.com Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/interconnect/qcom/qcs615.c | 42 ------------------------------ 1 file changed, 42 deletions(-) diff --git a/drivers/interconnect/qcom/qcs615.c b/drivers/interconnect/qcom/qcs615.c index 7e59e91ce886..0549cfcbac64 100644 --- a/drivers/interconnect/qcom/qcs615.c +++ b/drivers/interconnect/qcom/qcs615.c @@ -342,15 +342,6 @@ static struct qcom_icc_node qnm_snoc_sf = { .links = { QCS615_SLAVE_LLCC }, }; -static struct qcom_icc_node ipa_core_master = { - .name = "ipa_core_master", - .id = QCS615_MASTER_IPA_CORE, - .channels = 1, - .buswidth = 8, - .num_links = 1, - .links = { QCS615_SLAVE_IPA_CORE }, -}; - static struct qcom_icc_node llcc_mc = { .name = "llcc_mc", .id = QCS615_MASTER_LLCC, @@ -942,14 +933,6 @@ static struct qcom_icc_node srvc_gemnoc = { .num_links = 0, }; -static struct qcom_icc_node ipa_core_slave = { - .name = "ipa_core_slave", - .id = QCS615_SLAVE_IPA_CORE, - .channels = 1, - .buswidth = 8, - .num_links = 0, -}; - static struct qcom_icc_node ebi = { .name = "ebi", .id = QCS615_SLAVE_EBI1, @@ -1113,12 +1096,6 @@ static struct qcom_icc_bcm bcm_cn1 = { &qhs_sdc1, &qhs_sdc2 }, }; -static struct qcom_icc_bcm bcm_ip0 = { - .name = "IP0", - .num_nodes = 1, - .nodes = { &ipa_core_slave }, -}; - static struct qcom_icc_bcm bcm_mc0 = { .name = "MC0", .keepalive = true, @@ -1260,7 +1237,6 @@ static struct qcom_icc_bcm * const aggre1_noc_bcms[] = { &bcm_qup0, &bcm_sn3, &bcm_sn14, - &bcm_ip0, }; static struct qcom_icc_node * const aggre1_noc_nodes[] = { @@ -1411,22 +1387,6 @@ static const struct qcom_icc_desc qcs615_gem_noc = { .num_bcms = ARRAY_SIZE(gem_noc_bcms), }; -static struct qcom_icc_bcm * const ipa_virt_bcms[] = { - &bcm_ip0, -}; - -static struct qcom_icc_node * const ipa_virt_nodes[] = { - [MASTER_IPA_CORE] = &ipa_core_master, - [SLAVE_IPA_CORE] = &ipa_core_slave, -}; - -static const struct qcom_icc_desc qcs615_ipa_virt = { - .nodes = ipa_virt_nodes, - .num_nodes = ARRAY_SIZE(ipa_virt_nodes), - .bcms = ipa_virt_bcms, - .num_bcms = ARRAY_SIZE(ipa_virt_bcms), -}; - static struct qcom_icc_bcm * const mc_virt_bcms[] = { &bcm_acv, &bcm_mc0, @@ -1525,8 +1485,6 @@ static const struct of_device_id qnoc_of_match[] = { .data = &qcs615_dc_noc}, { .compatible = "qcom,qcs615-gem-noc", .data = &qcs615_gem_noc}, - { .compatible = "qcom,qcs615-ipa-virt", - .data = &qcs615_ipa_virt}, { .compatible = "qcom,qcs615-mc-virt", .data = &qcs615_mc_virt}, { .compatible = "qcom,qcs615-mmss-noc", -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: [PATCH 6.15 093/480] interconnect: qcom: qcs615: Drop IP0 interconnects 2025-08-12 17:45 ` [PATCH 6.15 093/480] interconnect: qcom: qcs615: Drop IP0 interconnects Greg Kroah-Hartman @ 2025-08-13 8:57 ` Konrad Dybcio 0 siblings, 0 replies; 1767+ messages in thread From: Konrad Dybcio @ 2025-08-13 8:57 UTC (permalink / raw) To: Greg Kroah-Hartman, stable Cc: patches, Dmitry Baryshkov, Georgi Djakov, Sasha Levin On 8/12/25 7:45 PM, Greg Kroah-Hartman wrote: > 6.15-stable review patch. If anyone has any objections, please let me know. > > ------------------ > > From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > > [ Upstream commit cbabc73e85be9e706a5051c9416de4a8d391cf57 ] > > In the same spirit as e.g. Commit b136d257ee0b ("interconnect: qcom: > sc8280xp: Drop IP0 interconnects"), drop the resources that should be > taken care of through the clk-rpmh driver. > > Fixes: 77d79677b04b ("interconnect: qcom: add QCS615 interconnect provider driver") > Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> > Link: https://lore.kernel.org/r/20250627-topic-qcs615_icc_ipa-v1-2-dc47596cde69@oss.qualcomm.com > Signed-off-by: Georgi Djakov <djakov@kernel.org> > Signed-off-by: Sasha Levin <sashal@kernel.org> > --- Please drop, this has cross-dependencies and even if we applied all of them, the series had no visible impact Konrad ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 094/480] bus: mhi: host: pci_generic: Fix the modem name of Foxconn T99W640 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (92 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 093/480] interconnect: qcom: qcs615: Drop IP0 interconnects Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 095/480] drm/xe: Correct the rev value for the DVSEC entries Greg Kroah-Hartman ` (397 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Slark Xiao, Manivannan Sadhasivam, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Slark Xiao <slark_xiao@163.com> [ Upstream commit ae5a34264354087aef38cdd07961827482a51c5a ] T99W640 was mistakenly mentioned as T99W515. T99W515 is a LGA device, not a M.2 modem device. So correct it's name to avoid name mismatch issue. Fixes: bf30a75e6e00 ("bus: mhi: host: Add support for Foxconn SDX72 modems") Signed-off-by: Slark Xiao <slark_xiao@163.com> [mani: commit message fixup] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20250606095019.383992-1-slark_xiao@163.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/bus/mhi/host/pci_generic.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/bus/mhi/host/pci_generic.c b/drivers/bus/mhi/host/pci_generic.c index 059cfd77382f..cd274f4dae93 100644 --- a/drivers/bus/mhi/host/pci_generic.c +++ b/drivers/bus/mhi/host/pci_generic.c @@ -593,8 +593,8 @@ static const struct mhi_pci_dev_info mhi_foxconn_dw5932e_info = { .sideband_wake = false, }; -static const struct mhi_pci_dev_info mhi_foxconn_t99w515_info = { - .name = "foxconn-t99w515", +static const struct mhi_pci_dev_info mhi_foxconn_t99w640_info = { + .name = "foxconn-t99w640", .edl = "qcom/sdx72m/foxconn/edl.mbn", .edl_trigger = true, .config = &modem_foxconn_sdx72_config, @@ -920,9 +920,9 @@ static const struct pci_device_id mhi_pci_id_table[] = { /* DW5932e (sdx62), Non-eSIM */ { PCI_DEVICE(PCI_VENDOR_ID_FOXCONN, 0xe0f9), .driver_data = (kernel_ulong_t) &mhi_foxconn_dw5932e_info }, - /* T99W515 (sdx72) */ + /* T99W640 (sdx72) */ { PCI_DEVICE(PCI_VENDOR_ID_FOXCONN, 0xe118), - .driver_data = (kernel_ulong_t) &mhi_foxconn_t99w515_info }, + .driver_data = (kernel_ulong_t) &mhi_foxconn_t99w640_info }, /* DW5934e(sdx72), With eSIM */ { PCI_DEVICE(PCI_VENDOR_ID_FOXCONN, 0xe11d), .driver_data = (kernel_ulong_t) &mhi_foxconn_dw5934e_info }, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 095/480] drm/xe: Correct the rev value for the DVSEC entries 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (93 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 094/480] bus: mhi: host: pci_generic: Fix the modem name of Foxconn T99W640 Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 096/480] drm/xe: Correct BMG VSEC header sizing Greg Kroah-Hartman ` (396 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Michael J. Ruhl, David E. Box, Ilpo Järvinen, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Michael J. Ruhl <michael.j.ruhl@intel.com> [ Upstream commit 0ba9e9cf76f2487654bc9bca38218780fa53030e ] By definition, the Designated Vendor Specific Extended Capability (DVSEC) revision should be 1. Add the rev value to be correct. Fixes: 0c45e76fcc62 ("drm/xe/vsec: Support BMG devices") Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Reviewed-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20250713172943.7335-3-michael.j.ruhl@intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/gpu/drm/xe/xe_vsec.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/xe/xe_vsec.c b/drivers/gpu/drm/xe/xe_vsec.c index b378848d3b7b..1bf7e709e110 100644 --- a/drivers/gpu/drm/xe/xe_vsec.c +++ b/drivers/gpu/drm/xe/xe_vsec.c @@ -24,6 +24,7 @@ #define BMG_DEVICE_ID 0xE2F8 static struct intel_vsec_header bmg_telemetry = { + .rev = 1, .length = 0x10, .id = VSEC_ID_TELEMETRY, .num_entries = 2, @@ -33,6 +34,7 @@ static struct intel_vsec_header bmg_telemetry = { }; static struct intel_vsec_header bmg_punit_crashlog = { + .rev = 1, .length = 0x10, .id = VSEC_ID_CRASHLOG, .num_entries = 1, @@ -42,6 +44,7 @@ static struct intel_vsec_header bmg_punit_crashlog = { }; static struct intel_vsec_header bmg_oobmsm_crashlog = { + .rev = 1, .length = 0x10, .id = VSEC_ID_CRASHLOG, .num_entries = 1, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 096/480] drm/xe: Correct BMG VSEC header sizing 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (94 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 095/480] drm/xe: Correct the rev value for the DVSEC entries Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 097/480] staging: nvec: Fix incorrect null termination of battery manufacturer Greg Kroah-Hartman ` (395 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Rodrigo Vivi, Michael J. Ruhl, David E. Box, Ilpo Järvinen, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Michael J. Ruhl <michael.j.ruhl@intel.com> [ Upstream commit 5b27388171a18cf6842c700520086ec50194e858 ] The intel_vsec_header information for the crashlog feature is incorrect. Update the VSEC header with correct sizing and count. Since the crashlog entries are "merged" (num_entries = 2), the separate capabilities entries must be merged as well. Fixes: 0c45e76fcc62 ("drm/xe/vsec: Support BMG devices") Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Reviewed-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20250713172943.7335-4-michael.j.ruhl@intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/gpu/drm/xe/xe_vsec.c | 19 ++++--------------- 1 file changed, 4 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_vsec.c b/drivers/gpu/drm/xe/xe_vsec.c index 1bf7e709e110..56930ad42962 100644 --- a/drivers/gpu/drm/xe/xe_vsec.c +++ b/drivers/gpu/drm/xe/xe_vsec.c @@ -33,30 +33,19 @@ static struct intel_vsec_header bmg_telemetry = { .offset = BMG_DISCOVERY_OFFSET, }; -static struct intel_vsec_header bmg_punit_crashlog = { +static struct intel_vsec_header bmg_crashlog = { .rev = 1, .length = 0x10, .id = VSEC_ID_CRASHLOG, - .num_entries = 1, - .entry_size = 4, + .num_entries = 2, + .entry_size = 6, .tbir = 0, .offset = BMG_DISCOVERY_OFFSET + 0x60, }; -static struct intel_vsec_header bmg_oobmsm_crashlog = { - .rev = 1, - .length = 0x10, - .id = VSEC_ID_CRASHLOG, - .num_entries = 1, - .entry_size = 4, - .tbir = 0, - .offset = BMG_DISCOVERY_OFFSET + 0x78, -}; - static struct intel_vsec_header *bmg_capabilities[] = { &bmg_telemetry, - &bmg_punit_crashlog, - &bmg_oobmsm_crashlog, + &bmg_crashlog, NULL }; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 097/480] staging: nvec: Fix incorrect null termination of battery manufacturer 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (95 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 096/480] drm/xe: Correct BMG VSEC header sizing Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 098/480] selftests/tracing: Fix false failure of subsystem event test Greg Kroah-Hartman ` (394 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Alok Tiwari, Dan Carpenter, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Alok Tiwari <alok.a.tiwari@oracle.com> [ Upstream commit a8934352ba01081c51d2df428e9d540aae0e88b5 ] The battery manufacturer string was incorrectly null terminated using bat_model instead of bat_manu. This could result in an unintended write to the wrong field and potentially incorrect behavior. fixe the issue by correctly null terminating the bat_manu string. Fixes: 32890b983086 ("Staging: initial version of the nvec driver") Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/20250719080755.3954373-1-alok.a.tiwari@oracle.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/staging/nvec/nvec_power.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/nvec/nvec_power.c b/drivers/staging/nvec/nvec_power.c index e0e67a3eb722..2faab9fdedef 100644 --- a/drivers/staging/nvec/nvec_power.c +++ b/drivers/staging/nvec/nvec_power.c @@ -194,7 +194,7 @@ static int nvec_power_bat_notifier(struct notifier_block *nb, break; case MANUFACTURER: memcpy(power->bat_manu, &res->plc, res->length - 2); - power->bat_model[res->length - 2] = '\0'; + power->bat_manu[res->length - 2] = '\0'; break; case MODEL: memcpy(power->bat_model, &res->plc, res->length - 2); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 098/480] selftests/tracing: Fix false failure of subsystem event test 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (96 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 097/480] staging: nvec: Fix incorrect null termination of battery manufacturer Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 099/480] drm/rockchip: cleanup fb when drm_gem_fb_afbc_init failed Greg Kroah-Hartman ` (393 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Tengda Wu, Steven Rostedt (Google), Shuah Khan, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Steven Rostedt <rostedt@goodmis.org> [ Upstream commit 213879061a9c60200ba971330dbefec6df3b4a30 ] The subsystem event test enables all "sched" events and makes sure there's at least 3 different events in the output. It used to cat the entire trace file to | wc -l, but on slow machines, that could last a very long time. To solve that, it was changed to just read the first 100 lines of the trace file. This can cause false failures as some events repeat so often, that the 100 lines that are examined could possibly be of only one event. Instead, create an awk script that looks for 3 different events and will exit out after it finds them. This will find the 3 events the test looks for (eventually if it works), and still exit out after the test is satisfied and not cause slower machines to run forever. Link: https://lore.kernel.org/r/20250721134212.53c3e140@batman.local.home Reported-by: Tengda Wu <wutengda@huaweicloud.com> Closes: https://lore.kernel.org/all/20250710130134.591066-1-wutengda@huaweicloud.com/ Fixes: 1a4ea83a6e67 ("selftests/ftrace: Limit length in subsystem-enable tests") Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- .../ftrace/test.d/event/subsystem-enable.tc | 28 +++++++++++++++++-- 1 file changed, 26 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc index b7c8f29c09a9..65916bb55dfb 100644 --- a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc +++ b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc @@ -14,11 +14,35 @@ fail() { #msg exit_fail } +# As reading trace can last forever, simply look for 3 different +# events then exit out of reading the file. If there's not 3 different +# events, then the test has failed. +check_unique() { + cat trace | grep -v '^#' | awk ' + BEGIN { cnt = 0; } + { + for (i = 0; i < cnt; i++) { + if (event[i] == $5) { + break; + } + } + if (i == cnt) { + event[cnt++] = $5; + if (cnt > 2) { + exit; + } + } + } + END { + printf "%d", cnt; + }' +} + echo 'sched:*' > set_event yield -count=`head -n 100 trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l` +count=`check_unique` if [ $count -lt 3 ]; then fail "at least fork, exec and exit events should be recorded" fi @@ -29,7 +53,7 @@ echo 1 > events/sched/enable yield -count=`head -n 100 trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l` +count=`check_unique` if [ $count -lt 3 ]; then fail "at least fork, exec and exit events should be recorded" fi -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 099/480] drm/rockchip: cleanup fb when drm_gem_fb_afbc_init failed 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (97 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 098/480] selftests/tracing: Fix false failure of subsystem event test Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 100/480] drm/connector: hdmi: Evaluate limited range after computing format Greg Kroah-Hartman ` (392 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Andy Yan, Heiko Stuebner, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Andy Yan <andy.yan@rock-chips.com> [ Upstream commit 099593a28138b48feea5be8ce700e5bc4565e31d ] In the function drm_gem_fb_init_with_funcs, the framebuffer (fb) and its corresponding object ID have already been registered. So we need to cleanup the drm framebuffer if the subsequent execution of drm_gem_fb_afbc_init fails. Directly call drm_framebuffer_put to ensure that all fb related resources are cleanup. Fixes: 7707f7227f09 ("drm/rockchip: Add support for afbc") Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250509031607.2542187-1-andyshrk@163.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c index dcc1f07632c3..5829ee061c61 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c @@ -52,16 +52,9 @@ rockchip_fb_create(struct drm_device *dev, struct drm_file *file, } if (drm_is_afbc(mode_cmd->modifier[0])) { - int ret, i; - ret = drm_gem_fb_afbc_init(dev, mode_cmd, afbc_fb); if (ret) { - struct drm_gem_object **obj = afbc_fb->base.obj; - - for (i = 0; i < info->num_planes; ++i) - drm_gem_object_put(obj[i]); - - kfree(afbc_fb); + drm_framebuffer_put(&afbc_fb->base); return ERR_PTR(ret); } } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 100/480] drm/connector: hdmi: Evaluate limited range after computing format 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (98 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 099/480] drm/rockchip: cleanup fb when drm_gem_fb_afbc_init failed Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 101/480] drm/panfrost: Fix panfrost device variable name in devfreq Greg Kroah-Hartman ` (391 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Dmitry Baryshkov, Cristian Ciocaltea, Maxime Ripard, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> [ Upstream commit 21f627139652dd8329a88e281df6600f3866d238 ] Evaluating the requirement to use a limited RGB quantization range involves a verification of the output format, among others, but this is currently performed before actually computing the format, hence relying on the old connector state. Move the call to hdmi_is_limited_range() after hdmi_compute_config() to ensure the verification is done on the updated output format. Fixes: 027d43590649 ("drm/connector: hdmi: Add RGB Quantization Range to the connector state") Reviewed-by: Dmitry Baryshkov <lumag@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-1-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/gpu/drm/display/drm_hdmi_state_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c b/drivers/gpu/drm/display/drm_hdmi_state_helper.c index c205f37da1e1..6bc96d5d1ab9 100644 --- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c +++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c @@ -506,12 +506,12 @@ int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector, if (!new_conn_state->crtc || !new_conn_state->best_encoder) return 0; - new_conn_state->hdmi.is_limited_range = hdmi_is_limited_range(connector, new_conn_state); - ret = hdmi_compute_config(connector, new_conn_state, mode); if (ret) return ret; + new_conn_state->hdmi.is_limited_range = hdmi_is_limited_range(connector, new_conn_state); + ret = hdmi_generate_infoframes(connector, new_conn_state); if (ret) return ret; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 101/480] drm/panfrost: Fix panfrost device variable name in devfreq 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (99 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 100/480] drm/connector: hdmi: Evaluate limited range after computing format Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 102/480] drm/panthor: Add missing explicit padding in drm_panthor_gpu_info Greg Kroah-Hartman ` (390 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Adrián Larumbe, Boris Brezillon, Steven Price, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Adrián Larumbe <adrian.larumbe@collabora.com> [ Upstream commit 6048f5587614bb4919c54966913452c1a0a43138 ] Commit 64111a0e22a9 ("drm/panfrost: Fix incorrect updating of current device frequency") was a Panfrost port of a similar fix in Panthor. Fix the Panfrost device pointer variable name so that it follows Panfrost naming conventions. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Fixes: 64111a0e22a9 ("drm/panfrost: Fix incorrect updating of current device frequency") Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250520174634.353267-6-adrian.larumbe@collabora.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/gpu/drm/panfrost/panfrost_devfreq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c b/drivers/gpu/drm/panfrost/panfrost_devfreq.c index 3385fd3ef41a..5d0dce10336b 100644 --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c @@ -29,7 +29,7 @@ static void panfrost_devfreq_update_utilization(struct panfrost_devfreq *pfdevfr static int panfrost_devfreq_target(struct device *dev, unsigned long *freq, u32 flags) { - struct panfrost_device *ptdev = dev_get_drvdata(dev); + struct panfrost_device *pfdev = dev_get_drvdata(dev); struct dev_pm_opp *opp; int err; @@ -40,7 +40,7 @@ static int panfrost_devfreq_target(struct device *dev, unsigned long *freq, err = dev_pm_opp_set_rate(dev, *freq); if (!err) - ptdev->pfdevfreq.current_frequency = *freq; + pfdev->pfdevfreq.current_frequency = *freq; return err; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 102/480] drm/panthor: Add missing explicit padding in drm_panthor_gpu_info 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (100 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 101/480] drm/panfrost: Fix panfrost device variable name in devfreq Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 103/480] wifi: rtw89: fix EHT 20MHz TX rate for non-AP STA Greg Kroah-Hartman ` (389 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Liviu Dudau, Adrián Larumbe, Steven Price, Boris Brezillon, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Boris Brezillon <boris.brezillon@collabora.com> [ Upstream commit 95cbab48782bf62e4093837dc15ac6133902c12f ] drm_panthor_gpu_info::shader_present is currently automatically offset by 4 byte to meet Arm's 32-bit/64-bit field alignment rules, but those constraints don't stand on 32-bit x86 and cause a mismatch when running an x86 binary in a user emulated environment like FEX. It's also generally agreed that uAPIs should explicitly pad their struct fields, which we originally intended to do, but a mistake slipped through during the submission process, leading drm_panthor_gpu_info::shader_present to be misaligned. This uAPI change doesn't break any of the existing users of panthor which are either arm32 or arm64 where the 64-bit alignment of u64 fields is already enforced a the compiler level. Changes in v2: - Rename the garbage field into pad0 and adjust the comment accordingly - Add Liviu's A-b Changes in v3: - Add R-bs Fixes: 0f25e493a246 ("drm/panthor: Add uAPI") Acked-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250606080932.4140010-2-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- include/uapi/drm/panthor_drm.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/uapi/drm/panthor_drm.h b/include/uapi/drm/panthor_drm.h index 97e2c4510e69..dbb907eae443 100644 --- a/include/uapi/drm/panthor_drm.h +++ b/include/uapi/drm/panthor_drm.h @@ -293,6 +293,9 @@ struct drm_panthor_gpu_info { /** @as_present: Bitmask encoding the number of address-space exposed by the MMU. */ __u32 as_present; + /** @pad0: MBZ. */ + __u32 pad0; + /** @shader_present: Bitmask encoding the shader cores exposed by the GPU. */ __u64 shader_present; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 103/480] wifi: rtw89: fix EHT 20MHz TX rate for non-AP STA 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (101 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 102/480] drm/panthor: Add missing explicit padding in drm_panthor_gpu_info Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 104/480] bpf, sockmap: Fix psock incorrectly pointing to sk Greg Kroah-Hartman ` (388 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Kuan-Chung Chen, Ping-Ke Shih, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Kuan-Chung Chen <damon.chen@realtek.com> [ Upstream commit fe30a8ae853bade282fce63e740b5f34bdc55f6e ] The 4-octet EHT MCS/NSS subfield is only used for 20 MHz-only non-AP STA. Correct the interpretation of this subfield to prevent improper rate limitations. Fixes: f1dfcee2eae9 ("wifi: rtw89: Correct EHT TX rate on 20MHz connection") Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250605114207.12381-6-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/wireless/realtek/rtw89/phy.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/realtek/rtw89/phy.c b/drivers/net/wireless/realtek/rtw89/phy.c index f4eee642e5ce..4bdc6d9da625 100644 --- a/drivers/net/wireless/realtek/rtw89/phy.c +++ b/drivers/net/wireless/realtek/rtw89/phy.c @@ -119,10 +119,12 @@ static u64 get_eht_mcs_ra_mask(u8 *max_nss, u8 start_mcs, u8 n_nss) return mask; } -static u64 get_eht_ra_mask(struct ieee80211_link_sta *link_sta) +static u64 get_eht_ra_mask(struct rtw89_vif_link *rtwvif_link, + struct ieee80211_link_sta *link_sta) { - struct ieee80211_sta_eht_cap *eht_cap = &link_sta->eht_cap; + struct ieee80211_vif *vif = rtwvif_link_to_vif(rtwvif_link); struct ieee80211_eht_mcs_nss_supp_20mhz_only *mcs_nss_20mhz; + struct ieee80211_sta_eht_cap *eht_cap = &link_sta->eht_cap; struct ieee80211_eht_mcs_nss_supp_bw *mcs_nss; u8 *he_phy_cap = link_sta->he_cap.he_cap_elem.phy_cap_info; @@ -136,8 +138,8 @@ static u64 get_eht_ra_mask(struct ieee80211_link_sta *link_sta) /* MCS 9, 11, 13 */ return get_eht_mcs_ra_mask(mcs_nss->rx_tx_max_nss, 9, 3); case IEEE80211_STA_RX_BW_20: - if (!(he_phy_cap[0] & - IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_MASK_ALL)) { + if (vif->type == NL80211_IFTYPE_AP && + !(he_phy_cap[0] & IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_MASK_ALL)) { mcs_nss_20mhz = &eht_cap->eht_mcs_nss_supp.only_20mhz; /* MCS 7, 9, 11, 13 */ return get_eht_mcs_ra_mask(mcs_nss_20mhz->rx_tx_max_nss, 7, 4); @@ -332,7 +334,7 @@ static void rtw89_phy_ra_sta_update(struct rtw89_dev *rtwdev, /* Set the ra mask from sta's capability */ if (link_sta->eht_cap.has_eht) { mode |= RTW89_RA_MODE_EHT; - ra_mask |= get_eht_ra_mask(link_sta); + ra_mask |= get_eht_ra_mask(rtwvif_link, link_sta); if (rtwdev->hal.no_mcs_12_13) high_rate_masks = rtw89_ra_mask_eht_mcs0_11; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 104/480] bpf, sockmap: Fix psock incorrectly pointing to sk 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (102 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 103/480] wifi: rtw89: fix EHT 20MHz TX rate for non-AP STA Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 105/480] netconsole: Only register console drivers when targets are configured Greg Kroah-Hartman ` (387 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Jiayuan Chen, Daniel Borkmann, John Fastabend, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jiayuan Chen <jiayuan.chen@linux.dev> [ Upstream commit 76be5fae32febb1fdb848ba09f78c4b2c76cb337 ] We observed an issue from the latest selftest: sockmap_redir where sk_psock(psock->sk) != psock in the backlog. The root cause is the special behavior in sockmap_redir - it frequently performs map_update() and map_delete() on the same socket. During map_update(), we create a new psock and during map_delete(), we eventually free the psock via rcu_work in sk_psock_drop(). However, pending workqueues might still exist and not be processed yet. If users immediately perform another map_update(), a new psock will be allocated for the same sk, resulting in two psocks pointing to the same sk. When the pending workqueue is later triggered, it uses the old psock to access sk for I/O operations, which is incorrect. Timing Diagram: cpu0 cpu1 map_update(sk): sk->psock = psock1 psock1->sk = sk map_delete(sk): rcu_work_free(psock1) map_update(sk): sk->psock = psock2 psock2->sk = sk workqueue: wakeup with psock1, but the sk of psock1 doesn't belong to psock1 rcu_handler: clean psock1 free(psock1) Previously, we used reference counting to address the concurrency issue between backlog and sock_map_close(). This logic remains necessary as it prevents the sk from being freed while processing the backlog. But this patch prevents pending backlogs from using a psock after it has been stopped. Note: We cannot call cancel_delayed_work_sync() in map_delete() since this might be invoked in BPF context by BPF helper, and the function may sleep. Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20250609025908.79331-1-jiayuan.chen@linux.dev Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/core/skmsg.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/net/core/skmsg.c b/net/core/skmsg.c index 34c51eb1a14f..83c78379932e 100644 --- a/net/core/skmsg.c +++ b/net/core/skmsg.c @@ -656,6 +656,13 @@ static void sk_psock_backlog(struct work_struct *work) bool ingress; int ret; + /* If sk is quickly removed from the map and then added back, the old + * psock should not be scheduled, because there are now two psocks + * pointing to the same sk. + */ + if (!sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED)) + return; + /* Increment the psock refcnt to synchronize with close(fd) path in * sock_map_close(), ensuring we wait for backlog thread completion * before sk_socket freed. If refcnt increment fails, it indicates -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 105/480] netconsole: Only register console drivers when targets are configured 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (103 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 104/480] bpf, sockmap: Fix psock incorrectly pointing to sk Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 106/480] bpf, ktls: Fix data corruption when using bpf_msg_pop_data() in ktls Greg Kroah-Hartman ` (386 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Breno Leitao, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Breno Leitao <leitao@debian.org> [ Upstream commit bc0cb64db1c765a81f69997d5a28f539e1731bc0 ] The netconsole driver currently registers the basic console driver unconditionally during initialization, even when only extended targets are configured. This results in unnecessary console registration and performance overhead, as the write_msg() callback is invoked for every log message only to return early when no matching targets are found. Optimize the driver by conditionally registering console drivers based on the actual target configuration. The basic console driver is now registered only when non-extended targets exist, same as the extended console. The implementation also handles dynamic target creation through the configfs interface. This change eliminates unnecessary console driver registrations, redundant write_msg() callbacks for unused console types, and associated lock contention and target list iterations. The optimization is particularly beneficial for systems using only the most common extended console type. Fixes: e2f15f9a79201 ("netconsole: implement extended console support") Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20250609-netcons_ext-v3-1-5336fa670326@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/netconsole.c | 30 ++++++++++++++++++++++-------- 1 file changed, 22 insertions(+), 8 deletions(-) diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c index 176935a8645f..a35b1fd4337b 100644 --- a/drivers/net/netconsole.c +++ b/drivers/net/netconsole.c @@ -86,10 +86,10 @@ static DEFINE_SPINLOCK(target_list_lock); static DEFINE_MUTEX(target_cleanup_list_lock); /* - * Console driver for extended netconsoles. Registered on the first use to - * avoid unnecessarily enabling ext message formatting. + * Console driver for netconsoles. Register only consoles that have + * an associated target of the same type. */ -static struct console netconsole_ext; +static struct console netconsole_ext, netconsole; struct netconsole_target_stats { u64_stats_t xmit_drop_count; @@ -97,6 +97,11 @@ struct netconsole_target_stats { struct u64_stats_sync syncp; }; +enum console_type { + CONS_BASIC = BIT(0), + CONS_EXTENDED = BIT(1), +}; + /* Features enabled in sysdata. Contrary to userdata, this data is populated by * the kernel. The fields are designed as bitwise flags, allowing multiple * features to be set in sysdata_fields. @@ -491,6 +496,12 @@ static ssize_t enabled_store(struct config_item *item, if (nt->extended && !console_is_registered(&netconsole_ext)) register_console(&netconsole_ext); + /* User might be enabling the basic format target for the very + * first time, make sure the console is registered. + */ + if (!nt->extended && !console_is_registered(&netconsole)) + register_console(&netconsole); + /* * Skip netpoll_parse_options() -- all the attributes are * already configured via configfs. Just print them out. @@ -1690,8 +1701,8 @@ static int __init init_netconsole(void) { int err; struct netconsole_target *nt, *tmp; + u32 console_type_needed = 0; unsigned int count = 0; - bool extended = false; unsigned long flags; char *target_config; char *input = config; @@ -1707,9 +1718,10 @@ static int __init init_netconsole(void) } /* Dump existing printks when we register */ if (nt->extended) { - extended = true; + console_type_needed |= CONS_EXTENDED; netconsole_ext.flags |= CON_PRINTBUFFER; } else { + console_type_needed |= CONS_BASIC; netconsole.flags |= CON_PRINTBUFFER; } @@ -1728,9 +1740,10 @@ static int __init init_netconsole(void) if (err) goto undonotifier; - if (extended) + if (console_type_needed & CONS_EXTENDED) register_console(&netconsole_ext); - register_console(&netconsole); + if (console_type_needed & CONS_BASIC) + register_console(&netconsole); pr_info("network logging started\n"); return err; @@ -1760,7 +1773,8 @@ static void __exit cleanup_netconsole(void) if (console_is_registered(&netconsole_ext)) unregister_console(&netconsole_ext); - unregister_console(&netconsole); + if (console_is_registered(&netconsole)) + unregister_console(&netconsole); dynamic_netconsole_exit(); unregister_netdevice_notifier(&netconsole_netdev_notifier); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 106/480] bpf, ktls: Fix data corruption when using bpf_msg_pop_data() in ktls 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (104 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 105/480] netconsole: Only register console drivers when targets are configured Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 107/480] selftests/bpf: fix signedness bug in redir_partial() Greg Kroah-Hartman ` (385 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Cong Wang, Jiayuan Chen, Daniel Borkmann, John Fastabend, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jiayuan Chen <jiayuan.chen@linux.dev> [ Upstream commit 178f6a5c8cb3b6be1602de0964cd440243f493c9 ] When sending plaintext data, we initially calculated the corresponding ciphertext length. However, if we later reduced the plaintext data length via socket policy, we failed to recalculate the ciphertext length. This results in transmitting buffers containing uninitialized data during ciphertext transmission. This causes uninitialized bytes to be appended after a complete "Application Data" packet, leading to errors on the receiving end when parsing TLS record. Fixes: d3b18ad31f93 ("tls: add bpf support to sk_msg handling") Reported-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Link: https://lore.kernel.org/bpf/20250609020910.397930-2-jiayuan.chen@linux.dev Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/tls/tls_sw.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index fc88e34b7f33..549d1ea01a72 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -872,6 +872,19 @@ static int bpf_exec_tx_verdict(struct sk_msg *msg, struct sock *sk, delta = msg->sg.size; psock->eval = sk_psock_msg_verdict(sk, psock, msg); delta -= msg->sg.size; + + if ((s32)delta > 0) { + /* It indicates that we executed bpf_msg_pop_data(), + * causing the plaintext data size to decrease. + * Therefore the encrypted data size also needs to + * correspondingly decrease. We only need to subtract + * delta to calculate the new ciphertext length since + * ktls does not support block encryption. + */ + struct sk_msg *enc = &ctx->open_rec->msg_encrypted; + + sk_msg_trim(sk, enc, enc->sg.size - delta); + } } if (msg->cork_bytes && msg->cork_bytes > msg->sg.size && !enospc && !full_record) { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 107/480] selftests/bpf: fix signedness bug in redir_partial() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (105 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 106/480] bpf, ktls: Fix data corruption when using bpf_msg_pop_data() in ktls Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 108/480] bpf: handle jset (if a & b ...) as a jump in CFG computation Greg Kroah-Hartman ` (384 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Fushuai Wang, Alexei Starovoitov, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Fushuai Wang <wangfushuai@baidu.com> [ Upstream commit 6a4bd31f680a1d1cf06492fe6dc4f08da09769e6 ] When xsend() returns -1 (error), the check 'n < sizeof(buf)' incorrectly treats it as success due to unsigned promotion. Explicitly check for -1 first. Fixes: a4b7193d8efd ("selftests/bpf: Add sockmap test for redirecting partial skb data") Signed-off-by: Fushuai Wang <wangfushuai@baidu.com> Link: https://lore.kernel.org/r/20250612084208.27722-1-wangfushuai@baidu.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/testing/selftests/bpf/prog_tests/sockmap_listen.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/testing/selftests/bpf/prog_tests/sockmap_listen.c b/tools/testing/selftests/bpf/prog_tests/sockmap_listen.c index 4ee1148d22be..1cfed83156b0 100644 --- a/tools/testing/selftests/bpf/prog_tests/sockmap_listen.c +++ b/tools/testing/selftests/bpf/prog_tests/sockmap_listen.c @@ -924,6 +924,8 @@ static void redir_partial(int family, int sotype, int sock_map, int parser_map) goto close; n = xsend(c1, buf, sizeof(buf), 0); + if (n == -1) + goto close; if (n < sizeof(buf)) FAIL("incomplete write"); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 108/480] bpf: handle jset (if a & b ...) as a jump in CFG computation 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (106 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 107/480] selftests/bpf: fix signedness bug in redir_partial() Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 109/480] selftests/bpf: Fix unintentional switch case fall through Greg Kroah-Hartman ` (383 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, syzbot+a36aac327960ff474804, Alexei Starovoitov, Eduard Zingerman, Alexei Starovoitov, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Eduard Zingerman <eddyz87@gmail.com> [ Upstream commit 3157f7e2999616ac91f4d559a8566214f74000a5 ] BPF_JSET is a conditional jump and currently verifier.c:can_jump() does not know about that. This can lead to incorrect live registers and SCC computation. E.g. in the following example: 1: r0 = 1; 2: r2 = 2; 3: if r1 & 0x7 goto +1; 4: exit; 5: r0 = r2; 6: exit; W/o this fix insn_successors(3) will return only (4), a jump to (5) would be missed and r2 won't be marked as alive at (3). Fixes: 14c8552db644 ("bpf: simple DFA-based live registers analysis") Reported-by: syzbot+a36aac327960ff474804@syzkaller.appspotmail.com Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com> Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20250613175331.3238739-1-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- kernel/bpf/verifier.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index c12dfbeb78a7..a1ecad2944a8 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -23657,6 +23657,7 @@ static bool can_jump(struct bpf_insn *insn) case BPF_JSLT: case BPF_JSLE: case BPF_JCOND: + case BPF_JSET: return true; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 109/480] selftests/bpf: Fix unintentional switch case fall through 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (107 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 108/480] bpf: handle jset (if a & b ...) as a jump in CFG computation Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 110/480] net: ipv6: ip6mr: Fix in/out netdev to pass to the FORWARD chain Greg Kroah-Hartman ` (382 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Mykyta Yatsenko, Andrii Nakryiko, Yonghong Song, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Mykyta Yatsenko <yatsenko@meta.com> [ Upstream commit 66ab68c9de89672366fdc474f4f185bb58cecf2d ] Break from switch expression after parsing -n CLI argument in veristat, instead of falling through and enabling comparison mode. Fixes: a5c57f81eb2b ("veristat: add ability to set BPF_F_TEST_SANITY_STRICT flag with -r flag") Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/bpf/20250617121536.1320074-1-mykyta.yatsenko5@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/testing/selftests/bpf/veristat.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/bpf/veristat.c b/tools/testing/selftests/bpf/veristat.c index a18972ffdeb6..2ff2c064f045 100644 --- a/tools/testing/selftests/bpf/veristat.c +++ b/tools/testing/selftests/bpf/veristat.c @@ -344,6 +344,7 @@ static error_t parse_arg(int key, char *arg, struct argp_state *state) fprintf(stderr, "invalid top N specifier: %s\n", arg); argp_usage(state); } + break; case 'C': env.comparison_mode = true; break; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 110/480] net: ipv6: ip6mr: Fix in/out netdev to pass to the FORWARD chain 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (108 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 109/480] selftests/bpf: Fix unintentional switch case fall through Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 111/480] drm/vmwgfx: Fix Host-Backed userspace on Guest-Backed kernel Greg Kroah-Hartman ` (381 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Petr Machata, Ido Schimmel, Nikolay Aleksandrov, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Petr Machata <petrm@nvidia.com> [ Upstream commit 3365afd3abda5f6a54f4a822dad5c9314e94c3fc ] The netfilter hook is invoked with skb->dev for input netdevice, and vif_dev for output netdevice. However at the point of invocation, skb->dev is already set to vif_dev, and MR-forwarded packets are reported with in=out: # ip6tables -A FORWARD -j LOG --log-prefix '[forw]' # cd tools/testing/selftests/net/forwarding # ./router_multicast.sh # dmesg | fgrep '[forw]' [ 1670.248245] [forw]IN=v5 OUT=v5 [...] For reference, IPv4 MR code shows in and out as appropriate. Fix by caching skb->dev and using the updated value for output netdev. Fixes: 7bc570c8b4f7 ("[IPV6] MROUTE: Support multicast forwarding.") Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://patch.msgid.link/3141ae8386fbe13fef4b793faa75e6bae58d798a.1750113335.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/ipv6/ip6mr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c index 3276cde5ebd7..63c90dae6cbf 100644 --- a/net/ipv6/ip6mr.c +++ b/net/ipv6/ip6mr.c @@ -2039,6 +2039,7 @@ static int ip6mr_forward2(struct net *net, struct mr_table *mrt, struct sk_buff *skb, int vifi) { struct vif_device *vif = &mrt->vif_table[vifi]; + struct net_device *indev = skb->dev; struct net_device *vif_dev; struct ipv6hdr *ipv6h; struct dst_entry *dst; @@ -2101,7 +2102,7 @@ static int ip6mr_forward2(struct net *net, struct mr_table *mrt, IP6CB(skb)->flags |= IP6SKB_FORWARDED; return NF_HOOK(NFPROTO_IPV6, NF_INET_FORWARD, - net, NULL, skb, skb->dev, vif_dev, + net, NULL, skb, indev, skb->dev, ip6mr_forward2_finish); out_free: -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 111/480] drm/vmwgfx: Fix Host-Backed userspace on Guest-Backed kernel 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (109 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 110/480] net: ipv6: ip6mr: Fix in/out netdev to pass to the FORWARD chain Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 112/480] slub: Fix a documentation build error for krealloc() Greg Kroah-Hartman ` (380 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Ian Forbes, Maaz Mombasawala, Zack Rusin, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ian Forbes <ian.forbes@broadcom.com> [ Upstream commit 7872997c048e989c7689c2995d230fdca7798000 ] Running 3D applications with SVGA_FORCE_HOST_BACKED=1 or using an ancient version of mesa was broken because the buffer was pinned in VMW_BO_DOMAIN_SYS and could not be moved to VMW_BO_DOMAIN_MOB during validation. The compat_shader buffer should not pinned. Fixes: 668b206601c5 ("drm/vmwgfx: Stop using raw ttm_buffer_object's") Signed-off-by: Ian Forbes <ian.forbes@broadcom.com> Reviewed-by: Maaz Mombasawala <maaz.mombasawala@broadcom.com> Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://lore.kernel.org/r/20250429203427.1742331-1-ian.forbes@broadcom.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/gpu/drm/vmwgfx/vmwgfx_shader.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c b/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c index 7fb1c88bcc47..69dfe69ce0f8 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c @@ -896,7 +896,7 @@ int vmw_compat_shader_add(struct vmw_private *dev_priv, .busy_domain = VMW_BO_DOMAIN_SYS, .bo_type = ttm_bo_type_device, .size = size, - .pin = true, + .pin = false, .keep_resv = true, }; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 112/480] slub: Fix a documentation build error for krealloc() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (110 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 111/480] drm/vmwgfx: Fix Host-Backed userspace on Guest-Backed kernel Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 113/480] drm/amdgpu: Remove nbiov7.9 replay count reporting Greg Kroah-Hartman ` (379 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Jonathan Corbet, Matthew Wilcox (Oracle), Vlastimil Babka, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jonathan Corbet <corbet@lwn.net> [ Upstream commit e8a45f198e3ae2434108f815bc28f37f6fe6742b ] The kerneldoc comment for krealloc() contains an unmarked literal block, leading to these warnings in the docs build: ./mm/slub.c:4936: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils] ./mm/slub.c:4936: ERROR: Undefined substitution referenced: "--------". [docutils] Mark up and indent the block properly to bring a bit of peace to our build logs. Fixes: 489a744e5fb1 (mm: krealloc: clarify valid usage of __GFP_ZERO) Signed-off-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Link: https://patch.msgid.link/20250611155916.2579160-6-willy@infradead.org Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org> --- mm/slub.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index be8b09e09d30..5c73b956615f 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -4929,12 +4929,12 @@ __do_krealloc(const void *p, size_t new_size, gfp_t flags) * When slub_debug_orig_size() is off, krealloc() only knows about the bucket * size of an allocation (but not the exact size it was allocated with) and * hence implements the following semantics for shrinking and growing buffers - * with __GFP_ZERO. + * with __GFP_ZERO:: * - * new bucket - * 0 size size - * |--------|----------------| - * | keep | zero | + * new bucket + * 0 size size + * |--------|----------------| + * | keep | zero | * * Otherwise, the original allocation size 'orig_size' could be used to * precisely clear the requested size, and the new size will also be stored -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 113/480] drm/amdgpu: Remove nbiov7.9 replay count reporting 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (111 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 112/480] slub: Fix a documentation build error for krealloc() Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 114/480] bpftool: Fix memory leak in dump_xx_nlmsg on realloc failure Greg Kroah-Hartman ` (378 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Lijo Lazar, Mangesh Gadre, Asad Kamal, Alex Deucher, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Lijo Lazar <lijo.lazar@amd.com> [ Upstream commit 0f566f0e9c614aa3d95082246f5b8c9e8a09c8b3 ] Direct pcie replay count reporting is not available on nbio v7.9. Reporting is done through firmware. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Acked-by: Mangesh Gadre <Mangesh.Gadre@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Fixes: 50709d18f4a6 ("drm/amdgpu: Add pci replay count to nbio v7.9") Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c | 20 -------------------- 1 file changed, 20 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c b/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c index f23cb79110d6..3a78d035e128 100644 --- a/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c +++ b/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c @@ -31,9 +31,6 @@ #define NPS_MODE_MASK 0x000000FFL -/* Core 0 Port 0 counter */ -#define smnPCIEP_NAK_COUNTER 0x1A340218 - static void nbio_v7_9_remap_hdp_registers(struct amdgpu_device *adev) { WREG32_SOC15(NBIO, 0, regBIF_BX0_REMAP_HDP_MEM_FLUSH_CNTL, @@ -463,22 +460,6 @@ static void nbio_v7_9_init_registers(struct amdgpu_device *adev) } } -static u64 nbio_v7_9_get_pcie_replay_count(struct amdgpu_device *adev) -{ - u32 val, nak_r, nak_g; - - if (adev->flags & AMD_IS_APU) - return 0; - - /* Get the number of NAKs received and generated */ - val = RREG32_PCIE(smnPCIEP_NAK_COUNTER); - nak_r = val & 0xFFFF; - nak_g = val >> 16; - - /* Add the total number of NAKs, i.e the number of replays */ - return (nak_r + nak_g); -} - #define MMIO_REG_HOLE_OFFSET 0x1A000 static void nbio_v7_9_set_reg_remap(struct amdgpu_device *adev) @@ -520,7 +501,6 @@ const struct amdgpu_nbio_funcs nbio_v7_9_funcs = { .get_memory_partition_mode = nbio_v7_9_get_memory_partition_mode, .is_nps_switch_requested = nbio_v7_9_is_nps_switch_requested, .init_registers = nbio_v7_9_init_registers, - .get_pcie_replay_count = nbio_v7_9_get_pcie_replay_count, .set_reg_remap = nbio_v7_9_set_reg_remap, }; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 114/480] bpftool: Fix memory leak in dump_xx_nlmsg on realloc failure 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (112 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 113/480] drm/amdgpu: Remove nbiov7.9 replay count reporting Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 115/480] powerpc/pseries/dlpar: Search DRC index from ibm,drc-indexes for IO add Greg Kroah-Hartman ` (377 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Yuan Chen, Quentin Monnet, Alexei Starovoitov, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Yuan Chen <chenyuan@kylinos.cn> [ Upstream commit 99fe8af069a9fa5b09140518b1364e35713a642e ] In function dump_xx_nlmsg(), when realloc() fails to allocate memory, the original pointer to the buffer is overwritten with NULL. This causes a memory leak because the previously allocated buffer becomes unreachable without being freed. Fixes: 7900efc19214 ("tools/bpf: bpftool: improve output format for bpftool net") Signed-off-by: Yuan Chen <chenyuan@kylinos.cn> Reviewed-by: Quentin Monnet <qmo@kernel.org> Link: https://lore.kernel.org/r/20250620012133.14819-1-chenyuan_fl@163.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/bpf/bpftool/net.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/tools/bpf/bpftool/net.c b/tools/bpf/bpftool/net.c index 64f958f437b0..cfc6f944f7c3 100644 --- a/tools/bpf/bpftool/net.c +++ b/tools/bpf/bpftool/net.c @@ -366,17 +366,18 @@ static int dump_link_nlmsg(void *cookie, void *msg, struct nlattr **tb) { struct bpf_netdev_t *netinfo = cookie; struct ifinfomsg *ifinfo = msg; + struct ip_devname_ifindex *tmp; if (netinfo->filter_idx > 0 && netinfo->filter_idx != ifinfo->ifi_index) return 0; if (netinfo->used_len == netinfo->array_len) { - netinfo->devices = realloc(netinfo->devices, - (netinfo->array_len + 16) * - sizeof(struct ip_devname_ifindex)); - if (!netinfo->devices) + tmp = realloc(netinfo->devices, + (netinfo->array_len + 16) * sizeof(struct ip_devname_ifindex)); + if (!tmp) return -ENOMEM; + netinfo->devices = tmp; netinfo->array_len += 16; } netinfo->devices[netinfo->used_len].ifindex = ifinfo->ifi_index; @@ -395,6 +396,7 @@ static int dump_class_qdisc_nlmsg(void *cookie, void *msg, struct nlattr **tb) { struct bpf_tcinfo_t *tcinfo = cookie; struct tcmsg *info = msg; + struct tc_kind_handle *tmp; if (tcinfo->is_qdisc) { /* skip clsact qdisc */ @@ -406,11 +408,12 @@ static int dump_class_qdisc_nlmsg(void *cookie, void *msg, struct nlattr **tb) } if (tcinfo->used_len == tcinfo->array_len) { - tcinfo->handle_array = realloc(tcinfo->handle_array, + tmp = realloc(tcinfo->handle_array, (tcinfo->array_len + 16) * sizeof(struct tc_kind_handle)); - if (!tcinfo->handle_array) + if (!tmp) return -ENOMEM; + tcinfo->handle_array = tmp; tcinfo->array_len += 16; } tcinfo->handle_array[tcinfo->used_len].handle = info->tcm_handle; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 115/480] powerpc/pseries/dlpar: Search DRC index from ibm,drc-indexes for IO add 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (113 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 114/480] bpftool: Fix memory leak in dump_xx_nlmsg on realloc failure Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 116/480] wifi: ath12k: Avoid accessing uninitialized arvif->ar during beacon miss Greg Kroah-Hartman ` (376 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Kowshik Jois, Haren Myneni, Amit Machhiwal, Tyrel Datwyler, Madhavan Srinivasan, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Haren Myneni <haren@linux.ibm.com> [ Upstream commit 41a1452759a8b1121df9cf7310acf31d766ba70b ] IO hotplug add event is handled in the user space with drmgr tool. After the device is enabled, the user space uses /sys/kernel/dlpar interface with “dt add index <drc_index>” to update the device tree. The kernel interface (dlpar_hp_dt_add()) finds the parent node for the specified ‘drc_index’ from ibm,drc-info property. The recent FW provides this property from 2017 onwards. But KVM guest code in some releases is still using the older SLOF firmware which has ibm,drc-indexes property instead of ibm,drc-info. If the ibm,drc-info is not available, this patch adds changes to search ‘drc_index’ from the indexes array in ibm,drc-indexes property to support old FW. Fixes: 02b98ff44a57 ("powerpc/pseries/dlpar: Add device tree nodes for DLPAR IO add") Reported-by: Kowshik Jois <kowsjois@linux.ibm.com> Signed-off-by: Haren Myneni <haren@linux.ibm.com> Tested-by: Amit Machhiwal <amachhiw@linux.ibm.com> Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250531235002.239213-1-haren@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/powerpc/platforms/pseries/dlpar.c | 52 +++++++++++++++++++++++++- 1 file changed, 50 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/pseries/dlpar.c b/arch/powerpc/platforms/pseries/dlpar.c index 213aa26dc8b3..979487da6522 100644 --- a/arch/powerpc/platforms/pseries/dlpar.c +++ b/arch/powerpc/platforms/pseries/dlpar.c @@ -404,6 +404,45 @@ get_device_node_with_drc_info(u32 index) return NULL; } +static struct device_node * +get_device_node_with_drc_indexes(u32 drc_index) +{ + struct device_node *np = NULL; + u32 nr_indexes, index; + int i, rc; + + for_each_node_with_property(np, "ibm,drc-indexes") { + /* + * First element in the array is the total number of + * DRC indexes returned. + */ + rc = of_property_read_u32_index(np, "ibm,drc-indexes", + 0, &nr_indexes); + if (rc) + goto out_put_np; + + /* + * Retrieve DRC index from the list and return the + * device node if matched with the specified index. + */ + for (i = 0; i < nr_indexes; i++) { + rc = of_property_read_u32_index(np, "ibm,drc-indexes", + i+1, &index); + if (rc) + goto out_put_np; + + if (drc_index == index) + return np; + } + } + + return NULL; + +out_put_np: + of_node_put(np); + return NULL; +} + static int dlpar_hp_dt_add(u32 index) { struct device_node *np, *nodes; @@ -423,10 +462,19 @@ static int dlpar_hp_dt_add(u32 index) goto out; } + /* + * Recent FW provides ibm,drc-info property. So search + * for the user specified DRC index from ibm,drc-info + * property. If this property is not available, search + * in the indexes array from ibm,drc-indexes property. + */ np = get_device_node_with_drc_info(index); - if (!np) - return -EIO; + if (!np) { + np = get_device_node_with_drc_indexes(index); + if (!np) + return -EIO; + } /* Next, configure the connector. */ nodes = dlpar_configure_connector(cpu_to_be32(index), np); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 116/480] wifi: ath12k: Avoid accessing uninitialized arvif->ar during beacon miss 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (114 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 115/480] powerpc/pseries/dlpar: Search DRC index from ibm,drc-indexes for IO add Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 117/480] wifi: ath12k: Fix double budget decrement while reaping monitor ring Greg Kroah-Hartman ` (375 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Rameshkumar Sundaram, Vasanthakumar Thiagarajan, Jeff Johnson, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> [ Upstream commit 36670b67de18f1e5d34900c5d2ac60a8970c293c ] During beacon miss handling, ath12k driver iterates over active virtual interfaces (vifs) and attempts to access the radio object (ar) via arvif->deflink->ar. However, after commit aa80f12f3bed ("wifi: ath12k: defer vdev creation for MLO"), arvif is linked to a radio only after vdev creation, typically when a channel is assigned or a scan is requested. For P2P capable devices, a default P2P interface is created by wpa_supplicant along with regular station interfaces, these serve as dummy interfaces for P2P-capable stations, lack an associated netdev and initiate frequent scans to discover neighbor p2p devices. When a scan is initiated on such P2P vifs, driver selects destination radio (ar) based on scan frequency, creates a scan vdev, and attaches arvif to the radio. Once the scan completes or is aborted, the scan vdev is deleted, detaching arvif from the radio and leaving arvif->ar uninitialized. While handling beacon miss for station interfaces, P2P interface is also encountered in the vif iteration and ath12k_mac_handle_beacon_miss_iter() tries to dereference the uninitialized arvif->deflink->ar. Fix this by verifying that vdev is created for the arvif before accessing its ar during beacon miss handling and similar vif iterator callbacks. ========================================================================== wlp6s0: detected beacon loss from AP (missed 7 beacons) - probing KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 5 UID: 0 PID: 0 Comm: swapper/5 Not tainted 6.16.0-rc1-wt-ath+ #2 PREEMPT(full) RIP: 0010:ath12k_mac_handle_beacon_miss_iter+0xb5/0x1a0 [ath12k] Call Trace: __iterate_interfaces+0x11a/0x410 [mac80211] ieee80211_iterate_active_interfaces_atomic+0x61/0x140 [mac80211] ath12k_mac_handle_beacon_miss+0xa1/0xf0 [ath12k] ath12k_roam_event+0x393/0x560 [ath12k] ath12k_wmi_op_rx+0x1486/0x28c0 [ath12k] ath12k_htc_process_trailer.isra.0+0x2fb/0x620 [ath12k] ath12k_htc_rx_completion_handler+0x448/0x830 [ath12k] ath12k_ce_recv_process_cb+0x549/0x9e0 [ath12k] ath12k_ce_per_engine_service+0xbe/0xf0 [ath12k] ath12k_pci_ce_workqueue+0x69/0x120 [ath12k] process_one_work+0xe3a/0x1430 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284.1-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: aa80f12f3bed ("wifi: ath12k: defer vdev creation for MLO") Signed-off-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250618185635.750470-1-rameshkumar.sundaram@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/wireless/ath/ath12k/mac.c | 15 +++++++++------ drivers/net/wireless/ath/ath12k/p2p.c | 3 ++- 2 files changed, 11 insertions(+), 7 deletions(-) diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c index d1d3c9f34372..7333ca58d541 100644 --- a/drivers/net/wireless/ath/ath12k/mac.c +++ b/drivers/net/wireless/ath/ath12k/mac.c @@ -685,6 +685,9 @@ static void ath12k_get_arvif_iter(void *data, u8 *mac, if (WARN_ON(!arvif)) continue; + if (!arvif->is_created) + continue; + if (arvif->vdev_id == arvif_iter->vdev_id && arvif->ar == arvif_iter->ar) { arvif_iter->arvif = arvif; @@ -1844,7 +1847,7 @@ static void ath12k_mac_handle_beacon_iter(void *data, u8 *mac, struct ath12k_vif *ahvif = ath12k_vif_to_ahvif(vif); struct ath12k_link_vif *arvif = &ahvif->deflink; - if (vif->type != NL80211_IFTYPE_STATION) + if (vif->type != NL80211_IFTYPE_STATION || !arvif->is_created) return; if (!ether_addr_equal(mgmt->bssid, vif->bss_conf.bssid)) @@ -1867,16 +1870,16 @@ static void ath12k_mac_handle_beacon_miss_iter(void *data, u8 *mac, u32 *vdev_id = data; struct ath12k_vif *ahvif = ath12k_vif_to_ahvif(vif); struct ath12k_link_vif *arvif = &ahvif->deflink; - struct ath12k *ar = arvif->ar; - struct ieee80211_hw *hw = ath12k_ar_to_hw(ar); + struct ieee80211_hw *hw; - if (arvif->vdev_id != *vdev_id) + if (!arvif->is_created || arvif->vdev_id != *vdev_id) return; if (!arvif->is_up) return; ieee80211_beacon_loss(vif); + hw = ath12k_ar_to_hw(arvif->ar); /* Firmware doesn't report beacon loss events repeatedly. If AP probe * (done by mac80211) succeeds but beacons do not resume then it @@ -9165,7 +9168,7 @@ ath12k_mac_change_chanctx_cnt_iter(void *data, u8 *mac, if (WARN_ON(!arvif)) continue; - if (arvif->ar != arg->ar) + if (!arvif->is_created || arvif->ar != arg->ar) continue; link_conf = wiphy_dereference(ahvif->ah->hw->wiphy, @@ -9200,7 +9203,7 @@ ath12k_mac_change_chanctx_fill_iter(void *data, u8 *mac, if (WARN_ON(!arvif)) continue; - if (arvif->ar != arg->ar) + if (!arvif->is_created || arvif->ar != arg->ar) continue; link_conf = wiphy_dereference(ahvif->ah->hw->wiphy, diff --git a/drivers/net/wireless/ath/ath12k/p2p.c b/drivers/net/wireless/ath/ath12k/p2p.c index 84cccf7d91e7..59589748f1a8 100644 --- a/drivers/net/wireless/ath/ath12k/p2p.c +++ b/drivers/net/wireless/ath/ath12k/p2p.c @@ -1,6 +1,7 @@ // SPDX-License-Identifier: BSD-3-Clause-Clear /* * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved. + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries. */ #include <net/mac80211.h> @@ -124,7 +125,7 @@ static void ath12k_p2p_noa_update_vdev_iter(void *data, u8 *mac, WARN_ON(!rcu_read_lock_any_held()); arvif = &ahvif->deflink; - if (arvif->ar != arg->ar || arvif->vdev_id != arg->vdev_id) + if (!arvif->is_created || arvif->ar != arg->ar || arvif->vdev_id != arg->vdev_id) return; ath12k_p2p_noa_update(arvif, arg->noa); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 117/480] wifi: ath12k: Fix double budget decrement while reaping monitor ring 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (115 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 116/480] wifi: ath12k: Avoid accessing uninitialized arvif->ar during beacon miss Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 118/480] wifi: ath12k: Pass ab pointer directly to ath12k_dp_tx_get_encap_type() Greg Kroah-Hartman ` (374 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, P Praneesh, Vasanthakumar Thiagarajan, Jeff Johnson, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: P Praneesh <praneesh.p@oss.qualcomm.com> [ Upstream commit 54c350055b1da2767f18a49c11e4fcc42cf33ff8 ] Currently, the budget for monitor ring is reduced during each ring entry reaping and again when the end reason is HAL_MON_END_OF_PPDU, leading to inefficient budget use. The below mentioned commit intended to decrement the budget only for HAL_MON_END_OF_PPDU but did not remove the other decrement. Fix this by eliminating the budget decrement for each ring entry reaping, ensuring the driver always reaps one full PPDU worth of entries from the monitor destination ring. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: 394a3fa7c538 ("wifi: ath12k: Optimize NAPI budget by adjusting PPDU processing") Signed-off-by: P Praneesh <praneesh.p@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250603103542.1164713-1-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/wireless/ath/ath12k/dp_mon.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath12k/dp_mon.c b/drivers/net/wireless/ath/ath12k/dp_mon.c index 826c9723a7a6..340a7b3474b1 100644 --- a/drivers/net/wireless/ath/ath12k/dp_mon.c +++ b/drivers/net/wireless/ath/ath12k/dp_mon.c @@ -3528,7 +3528,6 @@ int ath12k_dp_mon_srng_process(struct ath12k *ar, int *budget, ath12k_hal_srng_access_begin(ab, srng); while (likely(*budget)) { - *budget -= 1; mon_dst_desc = ath12k_hal_srng_dst_peek(ab, srng); if (unlikely(!mon_dst_desc)) break; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 118/480] wifi: ath12k: Pass ab pointer directly to ath12k_dp_tx_get_encap_type() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (116 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 117/480] wifi: ath12k: Fix double budget decrement while reaping monitor ring Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 119/480] caif: reduce stack size, again Greg Kroah-Hartman ` (373 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Tamizh Chelvam Raja, Vasanthakumar Thiagarajan, Jeff Johnson, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com> [ Upstream commit 05062834350f0bf7ad1abcebc2807220e90220eb ] In ath12k_dp_tx_get_encap_type(), the arvif parameter is only used to retrieve the ab pointer. In vdev delete sequence the arvif->ar could become NULL and that would trigger kernel panic. Since the caller ath12k_dp_tx() already has a valid ab pointer, pass it directly to avoid panic and unnecessary dereferencing. PC points to "ath12k_dp_tx+0x228/0x988 [ath12k]" LR points to "ath12k_dp_tx+0xc8/0x988 [ath12k]". The Backtrace obtained is as follows: ath12k_dp_tx+0x228/0x988 [ath12k] ath12k_mac_tx_check_max_limit+0x608/0x920 [ath12k] ieee80211_process_measurement_req+0x320/0x348 [mac80211] ieee80211_tx_dequeue+0x9ac/0x1518 [mac80211] ieee80211_tx_dequeue+0xb14/0x1518 [mac80211] ieee80211_tx_prepare_skb+0x224/0x254 [mac80211] ieee80211_xmit+0xec/0x100 [mac80211] __ieee80211_subif_start_xmit+0xc50/0xf40 [mac80211] ieee80211_subif_start_xmit+0x2e8/0x308 [mac80211] netdev_start_xmit+0x150/0x18c dev_hard_start_xmit+0x74/0xc0 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Fixes: e93bbd65547e ("wifi: ath12k: fix packets are sent in native wifi mode while we set raw mode") Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250606044936.3989400-1-tamizh.raja@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/wireless/ath/ath12k/dp_tx.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/ath/ath12k/dp_tx.c b/drivers/net/wireless/ath/ath12k/dp_tx.c index f82d2c58eff3..faf58e91d3eb 100644 --- a/drivers/net/wireless/ath/ath12k/dp_tx.c +++ b/drivers/net/wireless/ath/ath12k/dp_tx.c @@ -12,10 +12,9 @@ #include "mac.h" static enum hal_tcl_encap_type -ath12k_dp_tx_get_encap_type(struct ath12k_link_vif *arvif, struct sk_buff *skb) +ath12k_dp_tx_get_encap_type(struct ath12k_base *ab, struct sk_buff *skb) { struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb); - struct ath12k_base *ab = arvif->ar->ab; if (test_bit(ATH12K_FLAG_RAW_MODE, &ab->dev_flags)) return HAL_TCL_ENCAP_TYPE_RAW; @@ -302,7 +301,7 @@ int ath12k_dp_tx(struct ath12k *ar, struct ath12k_link_vif *arvif, u32_encode_bits(mcbc_gsn, HTT_TCL_META_DATA_GLOBAL_SEQ_NUM); } - ti.encap_type = ath12k_dp_tx_get_encap_type(arvif, skb); + ti.encap_type = ath12k_dp_tx_get_encap_type(ab, skb); ti.addr_search_flags = arvif->hal_addr_search_flags; ti.search_type = arvif->search_type; ti.type = HAL_TCL_DESC_TYPE_BUFFER; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 119/480] caif: reduce stack size, again 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (117 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 118/480] wifi: ath12k: Pass ab pointer directly to ath12k_dp_tx_get_encap_type() Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 120/480] wifi: rtw89: avoid NULL dereference when RX problematic packet on unsupported 6 GHz band Greg Kroah-Hartman ` (372 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Arnd Bergmann, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Arnd Bergmann <arnd@arndb.de> [ Upstream commit b630c781bcf6ff87657146661816d0d30a902139 ] I tried to fix the stack usage in this function a couple of years ago, but there is still a problem with the latest gcc versions in some configurations: net/caif/cfctrl.c:553:1: error: the frame size of 1296 bytes is larger than 1280 bytes [-Werror=frame-larger-than=] Reduce this once again, with a separate cfctrl_link_setup() function that holds the bulk of all the local variables. It also turns out that the param[] array that takes up a large portion of the stack is write-only and can be left out here. Fixes: ce6289661b14 ("caif: reduce stack size with KASAN") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20250620112244.3425554-1-arnd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/caif/cfctrl.c | 294 +++++++++++++++++++++++----------------------- 1 file changed, 144 insertions(+), 150 deletions(-) diff --git a/net/caif/cfctrl.c b/net/caif/cfctrl.c index 20139fa1be1f..06b604cf9d58 100644 --- a/net/caif/cfctrl.c +++ b/net/caif/cfctrl.c @@ -351,17 +351,154 @@ int cfctrl_cancel_req(struct cflayer *layr, struct cflayer *adap_layer) return found; } +static int cfctrl_link_setup(struct cfctrl *cfctrl, struct cfpkt *pkt, u8 cmdrsp) +{ + u8 len; + u8 linkid = 0; + enum cfctrl_srv serv; + enum cfctrl_srv servtype; + u8 endpoint; + u8 physlinkid; + u8 prio; + u8 tmp; + u8 *cp; + int i; + struct cfctrl_link_param linkparam; + struct cfctrl_request_info rsp, *req; + + memset(&linkparam, 0, sizeof(linkparam)); + + tmp = cfpkt_extr_head_u8(pkt); + + serv = tmp & CFCTRL_SRV_MASK; + linkparam.linktype = serv; + + servtype = tmp >> 4; + linkparam.chtype = servtype; + + tmp = cfpkt_extr_head_u8(pkt); + physlinkid = tmp & 0x07; + prio = tmp >> 3; + + linkparam.priority = prio; + linkparam.phyid = physlinkid; + endpoint = cfpkt_extr_head_u8(pkt); + linkparam.endpoint = endpoint & 0x03; + + switch (serv) { + case CFCTRL_SRV_VEI: + case CFCTRL_SRV_DBG: + if (CFCTRL_ERR_BIT & cmdrsp) + break; + /* Link ID */ + linkid = cfpkt_extr_head_u8(pkt); + break; + case CFCTRL_SRV_VIDEO: + tmp = cfpkt_extr_head_u8(pkt); + linkparam.u.video.connid = tmp; + if (CFCTRL_ERR_BIT & cmdrsp) + break; + /* Link ID */ + linkid = cfpkt_extr_head_u8(pkt); + break; + + case CFCTRL_SRV_DATAGRAM: + linkparam.u.datagram.connid = cfpkt_extr_head_u32(pkt); + if (CFCTRL_ERR_BIT & cmdrsp) + break; + /* Link ID */ + linkid = cfpkt_extr_head_u8(pkt); + break; + case CFCTRL_SRV_RFM: + /* Construct a frame, convert + * DatagramConnectionID + * to network format long and copy it out... + */ + linkparam.u.rfm.connid = cfpkt_extr_head_u32(pkt); + cp = (u8 *) linkparam.u.rfm.volume; + for (tmp = cfpkt_extr_head_u8(pkt); + cfpkt_more(pkt) && tmp != '\0'; + tmp = cfpkt_extr_head_u8(pkt)) + *cp++ = tmp; + *cp = '\0'; + + if (CFCTRL_ERR_BIT & cmdrsp) + break; + /* Link ID */ + linkid = cfpkt_extr_head_u8(pkt); + + break; + case CFCTRL_SRV_UTIL: + /* Construct a frame, convert + * DatagramConnectionID + * to network format long and copy it out... + */ + /* Fifosize KB */ + linkparam.u.utility.fifosize_kb = cfpkt_extr_head_u16(pkt); + /* Fifosize bufs */ + linkparam.u.utility.fifosize_bufs = cfpkt_extr_head_u16(pkt); + /* name */ + cp = (u8 *) linkparam.u.utility.name; + caif_assert(sizeof(linkparam.u.utility.name) + >= UTILITY_NAME_LENGTH); + for (i = 0; i < UTILITY_NAME_LENGTH && cfpkt_more(pkt); i++) { + tmp = cfpkt_extr_head_u8(pkt); + *cp++ = tmp; + } + /* Length */ + len = cfpkt_extr_head_u8(pkt); + linkparam.u.utility.paramlen = len; + /* Param Data */ + cp = linkparam.u.utility.params; + while (cfpkt_more(pkt) && len--) { + tmp = cfpkt_extr_head_u8(pkt); + *cp++ = tmp; + } + if (CFCTRL_ERR_BIT & cmdrsp) + break; + /* Link ID */ + linkid = cfpkt_extr_head_u8(pkt); + /* Length */ + len = cfpkt_extr_head_u8(pkt); + /* Param Data */ + cfpkt_extr_head(pkt, NULL, len); + break; + default: + pr_warn("Request setup, invalid type (%d)\n", serv); + return -1; + } + + rsp.cmd = CFCTRL_CMD_LINK_SETUP; + rsp.param = linkparam; + spin_lock_bh(&cfctrl->info_list_lock); + req = cfctrl_remove_req(cfctrl, &rsp); + + if (CFCTRL_ERR_BIT == (CFCTRL_ERR_BIT & cmdrsp) || + cfpkt_erroneous(pkt)) { + pr_err("Invalid O/E bit or parse error " + "on CAIF control channel\n"); + cfctrl->res.reject_rsp(cfctrl->serv.layer.up, 0, + req ? req->client_layer : NULL); + } else { + cfctrl->res.linksetup_rsp(cfctrl->serv.layer.up, linkid, + serv, physlinkid, + req ? req->client_layer : NULL); + } + + kfree(req); + + spin_unlock_bh(&cfctrl->info_list_lock); + + return 0; +} + static int cfctrl_recv(struct cflayer *layer, struct cfpkt *pkt) { u8 cmdrsp; u8 cmd; - int ret = -1; - u8 len; - u8 param[255]; + int ret = 0; u8 linkid = 0; struct cfctrl *cfctrl = container_obj(layer); - struct cfctrl_request_info rsp, *req; - cmdrsp = cfpkt_extr_head_u8(pkt); cmd = cmdrsp & CFCTRL_CMD_MASK; @@ -374,150 +511,7 @@ static int cfctrl_recv(struct cflayer *layer, struct cfpkt *pkt) switch (cmd) { case CFCTRL_CMD_LINK_SETUP: - { - enum cfctrl_srv serv; - enum cfctrl_srv servtype; - u8 endpoint; - u8 physlinkid; - u8 prio; - u8 tmp; - u8 *cp; - int i; - struct cfctrl_link_param linkparam; - memset(&linkparam, 0, sizeof(linkparam)); - - tmp = cfpkt_extr_head_u8(pkt); - - serv = tmp & CFCTRL_SRV_MASK; - linkparam.linktype = serv; - - servtype = tmp >> 4; - linkparam.chtype = servtype; - - tmp = cfpkt_extr_head_u8(pkt); - physlinkid = tmp & 0x07; - prio = tmp >> 3; - - linkparam.priority = prio; - linkparam.phyid = physlinkid; - endpoint = cfpkt_extr_head_u8(pkt); - linkparam.endpoint = endpoint & 0x03; - - switch (serv) { - case CFCTRL_SRV_VEI: - case CFCTRL_SRV_DBG: - if (CFCTRL_ERR_BIT & cmdrsp) - break; - /* Link ID */ - linkid = cfpkt_extr_head_u8(pkt); - break; - case CFCTRL_SRV_VIDEO: - tmp = cfpkt_extr_head_u8(pkt); - linkparam.u.video.connid = tmp; - if (CFCTRL_ERR_BIT & cmdrsp) - break; - /* Link ID */ - linkid = cfpkt_extr_head_u8(pkt); - break; - - case CFCTRL_SRV_DATAGRAM: - linkparam.u.datagram.connid = - cfpkt_extr_head_u32(pkt); - if (CFCTRL_ERR_BIT & cmdrsp) - break; - /* Link ID */ - linkid = cfpkt_extr_head_u8(pkt); - break; - case CFCTRL_SRV_RFM: - /* Construct a frame, convert - * DatagramConnectionID - * to network format long and copy it out... - */ - linkparam.u.rfm.connid = - cfpkt_extr_head_u32(pkt); - cp = (u8 *) linkparam.u.rfm.volume; - for (tmp = cfpkt_extr_head_u8(pkt); - cfpkt_more(pkt) && tmp != '\0'; - tmp = cfpkt_extr_head_u8(pkt)) - *cp++ = tmp; - *cp = '\0'; - - if (CFCTRL_ERR_BIT & cmdrsp) - break; - /* Link ID */ - linkid = cfpkt_extr_head_u8(pkt); - - break; - case CFCTRL_SRV_UTIL: - /* Construct a frame, convert - * DatagramConnectionID - * to network format long and copy it out... - */ - /* Fifosize KB */ - linkparam.u.utility.fifosize_kb = - cfpkt_extr_head_u16(pkt); - /* Fifosize bufs */ - linkparam.u.utility.fifosize_bufs = - cfpkt_extr_head_u16(pkt); - /* name */ - cp = (u8 *) linkparam.u.utility.name; - caif_assert(sizeof(linkparam.u.utility.name) - >= UTILITY_NAME_LENGTH); - for (i = 0; - i < UTILITY_NAME_LENGTH - && cfpkt_more(pkt); i++) { - tmp = cfpkt_extr_head_u8(pkt); - *cp++ = tmp; - } - /* Length */ - len = cfpkt_extr_head_u8(pkt); - linkparam.u.utility.paramlen = len; - /* Param Data */ - cp = linkparam.u.utility.params; - while (cfpkt_more(pkt) && len--) { - tmp = cfpkt_extr_head_u8(pkt); - *cp++ = tmp; - } - if (CFCTRL_ERR_BIT & cmdrsp) - break; - /* Link ID */ - linkid = cfpkt_extr_head_u8(pkt); - /* Length */ - len = cfpkt_extr_head_u8(pkt); - /* Param Data */ - cfpkt_extr_head(pkt, ¶m, len); - break; - default: - pr_warn("Request setup, invalid type (%d)\n", - serv); - goto error; - } - - rsp.cmd = cmd; - rsp.param = linkparam; - spin_lock_bh(&cfctrl->info_list_lock); - req = cfctrl_remove_req(cfctrl, &rsp); - - if (CFCTRL_ERR_BIT == (CFCTRL_ERR_BIT & cmdrsp) || - cfpkt_erroneous(pkt)) { - pr_err("Invalid O/E bit or parse error " - "on CAIF control channel\n"); - cfctrl->res.reject_rsp(cfctrl->serv.layer.up, - 0, - req ? req->client_layer - : NULL); - } else { - cfctrl->res.linksetup_rsp(cfctrl->serv. - layer.up, linkid, - serv, physlinkid, - req ? req-> - client_layer : NULL); - } - - kfree(req); - - spin_unlock_bh(&cfctrl->info_list_lock); - } + ret = cfctrl_link_setup(cfctrl, pkt, cmdrsp); break; case CFCTRL_CMD_LINK_DESTROY: linkid = cfpkt_extr_head_u8(pkt); @@ -544,9 +538,9 @@ static int cfctrl_recv(struct cflayer *layer, struct cfpkt *pkt) break; default: pr_err("Unrecognized Control Frame\n"); + ret = -1; goto error; } - ret = 0; error: cfpkt_destroy(pkt); return ret; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 120/480] wifi: rtw89: avoid NULL dereference when RX problematic packet on unsupported 6 GHz band 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (118 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 119/480] caif: reduce stack size, again Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 121/480] wifi: rtl818x: Kill URBs before clearing tx status queue Greg Kroah-Hartman ` (371 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Zong-Zhe Yang, Ping-Ke Shih, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Zong-Zhe Yang <kevin_yang@realtek.com> [ Upstream commit 7e04f01bb94fe61c73cc59f0495c3b6c16a83231 ] With a quite rare chance, RX report might be problematic to make SW think a packet is received on 6 GHz band even if the chip does not support 6 GHz band actually. Since SW won't initialize stuffs for unsupported bands, NULL dereference will happen then in the sequence, rtw89_vif_rx_stats_iter() -> rtw89_core_cancel_6ghz_probe_tx(). So, add a check to avoid it. The following is a crash log for this case. BUG: kernel NULL pointer dereference, address: 0000000000000032 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 1907 Comm: irq/131-rtw89_p Tainted: G U 6.6.56-05896-g89f5fb0eb30b #1 (HASH:1400 4) Hardware name: Google Telith/Telith, BIOS Google_Telith.15217.747.0 11/12/2024 RIP: 0010:rtw89_vif_rx_stats_iter+0xd2/0x310 [rtw89_core] Code: 4c 89 7d c8 48 89 55 c0 49 8d 44 24 02 48 89 45 b8 45 31 ff eb 11 41 c6 45 3a 01 41 b7 01 4d 8b 6d 00 4d 39 f5 74 42 8b 43 10 <41> 33 45 32 0f b7 4b 14 66 41 33 4d 36 0f b7 c9 09 c1 74 d8 4d 85 RSP: 0018:ffff9f3080138ca0 EFLAGS: 00010246 RAX: 00000000b8bf5770 RBX: ffff91b5e8c639c0 RCX: 0000000000000011 RDX: ffff91b582de1be8 RSI: 0000000000000000 RDI: ffff91b5e8c639e6 RBP: ffff9f3080138d00 R08: 0000000000000000 R09: 0000000000000000 R10: ffff91b59de70000 R11: ffffffffc069be50 R12: ffff91b5e8c639e4 R13: 0000000000000000 R14: ffff91b5828020b8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff91b8efa40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000032 CR3: 00000002bf838000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: <IRQ> ? __die_body+0x68/0xb0 ? page_fault_oops+0x379/0x3e0 ? exc_page_fault+0x4f/0xa0 ? asm_exc_page_fault+0x22/0x30 ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)] ? rtw89_vif_rx_stats_iter+0xd2/0x310 [rtw89_core (HASH:1400 5)] __iterate_interfaces+0x59/0x110 [mac80211 (HASH:1400 6)] ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)] ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)] ieee80211_iterate_active_interfaces_atomic+0x36/0x50 [mac80211 (HASH:1400 6)] rtw89_core_rx_to_mac80211+0xfd/0x1b0 [rtw89_core (HASH:1400 5)] rtw89_core_rx+0x43a/0x980 [rtw89_core (HASH:1400 5)] Fixes: c6aa9a9c4725 ("wifi: rtw89: add RNR support for 6 GHz scan") Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250618124649.11436-5-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/wireless/realtek/rtw89/core.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/net/wireless/realtek/rtw89/core.c b/drivers/net/wireless/realtek/rtw89/core.c index cc9b014457ac..69546a039494 100644 --- a/drivers/net/wireless/realtek/rtw89/core.c +++ b/drivers/net/wireless/realtek/rtw89/core.c @@ -2110,6 +2110,11 @@ static void rtw89_core_cancel_6ghz_probe_tx(struct rtw89_dev *rtwdev, if (rx_status->band != NL80211_BAND_6GHZ) return; + if (unlikely(!(rtwdev->chip->support_bands & BIT(NL80211_BAND_6GHZ)))) { + rtw89_debug(rtwdev, RTW89_DBG_UNEXP, "invalid rx on unsupported 6 GHz\n"); + return; + } + ssid_ie = cfg80211_find_ie(WLAN_EID_SSID, ies, skb->len); list_for_each_entry(info, &pkt_list[NL80211_BAND_6GHZ], list) { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 121/480] wifi: rtl818x: Kill URBs before clearing tx status queue 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (119 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 120/480] wifi: rtw89: avoid NULL dereference when RX problematic packet on unsupported 6 GHz band Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 122/480] wifi: iwlwifi: Fix memory leak in iwl_mvm_init() Greg Kroah-Hartman ` (370 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Daniil Dulov, Ping-Ke Shih, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Daniil Dulov <d.dulov@aladdin.ru> [ Upstream commit 16d8fd74dbfca0ea58645cd2fca13be10cae3cdd ] In rtl8187_stop() move the call of usb_kill_anchored_urbs() before clearing b_tx_status.queue. This change prevents callbacks from using already freed skb due to anchor was not killed before freeing such skb. BUG: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Not tainted 6.15.0 #8 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP: 0010:ieee80211_tx_status_irqsafe+0x21/0xc0 [mac80211] Call Trace: <IRQ> rtl8187_tx_cb+0x116/0x150 [rtl8187] __usb_hcd_giveback_urb+0x9d/0x120 usb_giveback_urb_bh+0xbb/0x140 process_one_work+0x19b/0x3c0 bh_worker+0x1a7/0x210 tasklet_action+0x10/0x30 handle_softirqs+0xf0/0x340 __irq_exit_rcu+0xcd/0xf0 common_interrupt+0x85/0xa0 </IRQ> Tested on RTL8187BvE device. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: c1db52b9d27e ("rtl8187: Use usb anchor facilities to manage urbs") Signed-off-by: Daniil Dulov <d.dulov@aladdin.ru> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250617135634.21760-1-d.dulov@aladdin.ru Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c b/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c index 220ac5bdf279..8a57d6c72335 100644 --- a/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c +++ b/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c @@ -1041,10 +1041,11 @@ static void rtl8187_stop(struct ieee80211_hw *dev, bool suspend) rtl818x_iowrite8(priv, &priv->map->CONFIG4, reg | RTL818X_CONFIG4_VCOOFF); rtl818x_iowrite8(priv, &priv->map->EEPROM_CMD, RTL818X_EEPROM_CMD_NORMAL); + usb_kill_anchored_urbs(&priv->anchored); + while ((skb = skb_dequeue(&priv->b_tx_status.queue))) dev_kfree_skb_any(skb); - usb_kill_anchored_urbs(&priv->anchored); mutex_unlock(&priv->conf_mutex); if (!priv->is_rtl8187b) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 122/480] wifi: iwlwifi: Fix memory leak in iwl_mvm_init() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (120 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 121/480] wifi: rtl818x: Kill URBs before clearing tx status queue Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 123/480] iwlwifi: Add missing check for alloc_ordered_workqueue Greg Kroah-Hartman ` (369 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Xiu Jianfeng, Miri Korenblit, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Xiu Jianfeng <xiujianfeng@huawei.com> [ Upstream commit ed2e916c890944633d6826dce267579334f63ea5 ] When iwl_opmode_register() fails, it does not unregster rate control, which will cause a memory leak issue, this patch fixes it. Fixes: 9f66a397c877 ("iwlwifi: mvm: rs: add ops for the new rate scaling in the FW") Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com> Link: https://patch.msgid.link/20221109035213.570-1-xiujianfeng@huawei.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/ops.c b/drivers/net/wireless/intel/iwlwifi/mvm/ops.c index 76603ef02704..15617cad967f 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/ops.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/ops.c @@ -61,8 +61,10 @@ static int __init iwl_mvm_init(void) } ret = iwl_opmode_register("iwlmvm", &iwl_mvm_ops); - if (ret) + if (ret) { pr_err("Unable to register MVM op_mode: %d\n", ret); + iwl_mvm_rate_control_unregister(); + } return ret; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 123/480] iwlwifi: Add missing check for alloc_ordered_workqueue 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (121 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 122/480] wifi: iwlwifi: Fix memory leak in iwl_mvm_init() Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 124/480] team: replace team lock with rtnl lock Greg Kroah-Hartman ` (368 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Jiasheng Jiang, Miri Korenblit, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jiasheng Jiang <jiasheng@iscas.ac.cn> [ Upstream commit 90a0d9f339960448a3acc1437a46730f975efd6a ] Add check for the return value of alloc_ordered_workqueue since it may return NULL pointer. Fixes: b481de9ca074 ("[IWLWIFI]: add iwlwifi wireless drivers") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Link: https://patch.msgid.link/20230110014848.28226-1-jiasheng@iscas.ac.cn Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/wireless/intel/iwlwifi/dvm/main.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/main.c b/drivers/net/wireless/intel/iwlwifi/dvm/main.c index a7f9e244c097..cd20958fb91a 100644 --- a/drivers/net/wireless/intel/iwlwifi/dvm/main.c +++ b/drivers/net/wireless/intel/iwlwifi/dvm/main.c @@ -1048,9 +1048,11 @@ static void iwl_bg_restart(struct work_struct *data) * *****************************************************************************/ -static void iwl_setup_deferred_work(struct iwl_priv *priv) +static int iwl_setup_deferred_work(struct iwl_priv *priv) { priv->workqueue = alloc_ordered_workqueue(DRV_NAME, 0); + if (!priv->workqueue) + return -ENOMEM; INIT_WORK(&priv->restart, iwl_bg_restart); INIT_WORK(&priv->beacon_update, iwl_bg_beacon_update); @@ -1067,6 +1069,8 @@ static void iwl_setup_deferred_work(struct iwl_priv *priv) timer_setup(&priv->statistics_periodic, iwl_bg_statistics_periodic, 0); timer_setup(&priv->ucode_trace, iwl_bg_ucode_trace, 0); + + return 0; } void iwl_cancel_deferred_work(struct iwl_priv *priv) @@ -1464,7 +1468,9 @@ static struct iwl_op_mode *iwl_op_mode_dvm_start(struct iwl_trans *trans, /******************** * 6. Setup services ********************/ - iwl_setup_deferred_work(priv); + if (iwl_setup_deferred_work(priv)) + goto out_uninit_drv; + iwl_setup_rx_handlers(priv); iwl_power_initialize(priv); @@ -1503,6 +1509,7 @@ static struct iwl_op_mode *iwl_op_mode_dvm_start(struct iwl_trans *trans, iwl_cancel_deferred_work(priv); destroy_workqueue(priv->workqueue); priv->workqueue = NULL; +out_uninit_drv: iwl_uninit_drv(priv); out_free_eeprom_blob: kfree(priv->eeprom_blob); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 124/480] team: replace team lock with rtnl lock 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (122 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 123/480] iwlwifi: Add missing check for alloc_ordered_workqueue Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 125/480] wifi: ath11k: clear initialized flag for deinit-ed srng lists Greg Kroah-Hartman ` (367 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Jiri Pirko, Tetsuo Handa, syzbot+705c61d60b091ef42c04, syzbot+71fd22ae4b81631e22fd, Stanislav Fomichev, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Stanislav Fomichev <sdf@fomichev.me> [ Upstream commit bfb4fb77f9a8ce33ce357224569eae5564eec573 ] syszbot reports various ordering issues for lower instance locks and team lock. Switch to using rtnl lock for protecting team device, similar to bonding. Based on the patch by Tetsuo Handa. Cc: Jiri Pirko <jiri@resnulli.us> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reported-by: syzbot+705c61d60b091ef42c04@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=705c61d60b091ef42c04 Reported-by: syzbot+71fd22ae4b81631e22fd@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=71fd22ae4b81631e22fd Fixes: 6b1d3c5f675c ("team: grab team lock during team_change_rx_flags") Link: https://lkml.kernel.org/r/ZoZ2RH9BcahEB9Sb@nanopsycho.orion Signed-off-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20250623153147.3413631-1-sdf@fomichev.me Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/team/team_core.c | 96 +++++++++++------------ drivers/net/team/team_mode_activebackup.c | 3 +- drivers/net/team/team_mode_loadbalance.c | 13 ++- include/linux/if_team.h | 3 - 4 files changed, 50 insertions(+), 65 deletions(-) diff --git a/drivers/net/team/team_core.c b/drivers/net/team/team_core.c index b75ceb90359f..94fc7eec4fca 100644 --- a/drivers/net/team/team_core.c +++ b/drivers/net/team/team_core.c @@ -933,7 +933,7 @@ static bool team_port_find(const struct team *team, * Enable/disable port by adding to enabled port hashlist and setting * port->index (Might be racy so reader could see incorrect ifindex when * processing a flying packet, but that is not a problem). Write guarded - * by team->lock. + * by RTNL. */ static void team_port_enable(struct team *team, struct team_port *port) @@ -1660,8 +1660,6 @@ static int team_init(struct net_device *dev) goto err_options_register; netif_carrier_off(dev); - lockdep_register_key(&team->team_lock_key); - __mutex_init(&team->lock, "team->team_lock_key", &team->team_lock_key); netdev_lockdep_set_classes(dev); return 0; @@ -1682,7 +1680,8 @@ static void team_uninit(struct net_device *dev) struct team_port *port; struct team_port *tmp; - mutex_lock(&team->lock); + ASSERT_RTNL(); + list_for_each_entry_safe(port, tmp, &team->port_list, list) team_port_del(team, port->dev); @@ -1691,9 +1690,7 @@ static void team_uninit(struct net_device *dev) team_mcast_rejoin_fini(team); team_notify_peers_fini(team); team_queue_override_fini(team); - mutex_unlock(&team->lock); netdev_change_features(dev); - lockdep_unregister_key(&team->team_lock_key); } static void team_destructor(struct net_device *dev) @@ -1778,7 +1775,8 @@ static void team_change_rx_flags(struct net_device *dev, int change) struct team_port *port; int inc; - mutex_lock(&team->lock); + ASSERT_RTNL(); + list_for_each_entry(port, &team->port_list, list) { if (change & IFF_PROMISC) { inc = dev->flags & IFF_PROMISC ? 1 : -1; @@ -1789,7 +1787,6 @@ static void team_change_rx_flags(struct net_device *dev, int change) dev_set_allmulti(port->dev, inc); } } - mutex_unlock(&team->lock); } static void team_set_rx_mode(struct net_device *dev) @@ -1811,14 +1808,14 @@ static int team_set_mac_address(struct net_device *dev, void *p) struct team *team = netdev_priv(dev); struct team_port *port; + ASSERT_RTNL(); + if (dev->type == ARPHRD_ETHER && !is_valid_ether_addr(addr->sa_data)) return -EADDRNOTAVAIL; dev_addr_set(dev, addr->sa_data); - mutex_lock(&team->lock); list_for_each_entry(port, &team->port_list, list) if (team->ops.port_change_dev_addr) team->ops.port_change_dev_addr(team, port); - mutex_unlock(&team->lock); return 0; } @@ -1828,11 +1825,8 @@ static int team_change_mtu(struct net_device *dev, int new_mtu) struct team_port *port; int err; - /* - * Alhough this is reader, it's guarded by team lock. It's not possible - * to traverse list in reverse under rcu_read_lock - */ - mutex_lock(&team->lock); + ASSERT_RTNL(); + team->port_mtu_change_allowed = true; list_for_each_entry(port, &team->port_list, list) { err = dev_set_mtu(port->dev, new_mtu); @@ -1843,7 +1837,6 @@ static int team_change_mtu(struct net_device *dev, int new_mtu) } } team->port_mtu_change_allowed = false; - mutex_unlock(&team->lock); WRITE_ONCE(dev->mtu, new_mtu); @@ -1853,7 +1846,6 @@ static int team_change_mtu(struct net_device *dev, int new_mtu) list_for_each_entry_continue_reverse(port, &team->port_list, list) dev_set_mtu(port->dev, dev->mtu); team->port_mtu_change_allowed = false; - mutex_unlock(&team->lock); return err; } @@ -1903,24 +1895,19 @@ static int team_vlan_rx_add_vid(struct net_device *dev, __be16 proto, u16 vid) struct team_port *port; int err; - /* - * Alhough this is reader, it's guarded by team lock. It's not possible - * to traverse list in reverse under rcu_read_lock - */ - mutex_lock(&team->lock); + ASSERT_RTNL(); + list_for_each_entry(port, &team->port_list, list) { err = vlan_vid_add(port->dev, proto, vid); if (err) goto unwind; } - mutex_unlock(&team->lock); return 0; unwind: list_for_each_entry_continue_reverse(port, &team->port_list, list) vlan_vid_del(port->dev, proto, vid); - mutex_unlock(&team->lock); return err; } @@ -1930,10 +1917,10 @@ static int team_vlan_rx_kill_vid(struct net_device *dev, __be16 proto, u16 vid) struct team *team = netdev_priv(dev); struct team_port *port; - mutex_lock(&team->lock); + ASSERT_RTNL(); + list_for_each_entry(port, &team->port_list, list) vlan_vid_del(port->dev, proto, vid); - mutex_unlock(&team->lock); return 0; } @@ -1955,9 +1942,9 @@ static void team_netpoll_cleanup(struct net_device *dev) { struct team *team = netdev_priv(dev); - mutex_lock(&team->lock); + ASSERT_RTNL(); + __team_netpoll_cleanup(team); - mutex_unlock(&team->lock); } static int team_netpoll_setup(struct net_device *dev) @@ -1966,7 +1953,8 @@ static int team_netpoll_setup(struct net_device *dev) struct team_port *port; int err = 0; - mutex_lock(&team->lock); + ASSERT_RTNL(); + list_for_each_entry(port, &team->port_list, list) { err = __team_port_enable_netpoll(port); if (err) { @@ -1974,7 +1962,6 @@ static int team_netpoll_setup(struct net_device *dev) break; } } - mutex_unlock(&team->lock); return err; } #endif @@ -1985,9 +1972,9 @@ static int team_add_slave(struct net_device *dev, struct net_device *port_dev, struct team *team = netdev_priv(dev); int err; - mutex_lock(&team->lock); + ASSERT_RTNL(); + err = team_port_add(team, port_dev, extack); - mutex_unlock(&team->lock); if (!err) netdev_change_features(dev); @@ -2000,18 +1987,13 @@ static int team_del_slave(struct net_device *dev, struct net_device *port_dev) struct team *team = netdev_priv(dev); int err; - mutex_lock(&team->lock); + ASSERT_RTNL(); + err = team_port_del(team, port_dev); - mutex_unlock(&team->lock); if (err) return err; - if (netif_is_team_master(port_dev)) { - lockdep_unregister_key(&team->team_lock_key); - lockdep_register_key(&team->team_lock_key); - lockdep_set_class(&team->lock, &team->team_lock_key); - } netdev_change_features(dev); return err; @@ -2304,9 +2286,10 @@ int team_nl_noop_doit(struct sk_buff *skb, struct genl_info *info) static struct team *team_nl_team_get(struct genl_info *info) { struct net *net = genl_info_net(info); - int ifindex; struct net_device *dev; - struct team *team; + int ifindex; + + ASSERT_RTNL(); if (!info->attrs[TEAM_ATTR_TEAM_IFINDEX]) return NULL; @@ -2318,14 +2301,11 @@ static struct team *team_nl_team_get(struct genl_info *info) return NULL; } - team = netdev_priv(dev); - mutex_lock(&team->lock); - return team; + return netdev_priv(dev); } static void team_nl_team_put(struct team *team) { - mutex_unlock(&team->lock); dev_put(team->dev); } @@ -2515,9 +2495,13 @@ int team_nl_options_get_doit(struct sk_buff *skb, struct genl_info *info) int err; LIST_HEAD(sel_opt_inst_list); + rtnl_lock(); + team = team_nl_team_get(info); - if (!team) - return -EINVAL; + if (!team) { + err = -EINVAL; + goto rtnl_unlock; + } list_for_each_entry(opt_inst, &team->option_inst_list, list) list_add_tail(&opt_inst->tmp_list, &sel_opt_inst_list); @@ -2527,6 +2511,9 @@ int team_nl_options_get_doit(struct sk_buff *skb, struct genl_info *info) team_nl_team_put(team); +rtnl_unlock: + rtnl_unlock(); + return err; } @@ -2805,15 +2792,22 @@ int team_nl_port_list_get_doit(struct sk_buff *skb, struct team *team; int err; + rtnl_lock(); + team = team_nl_team_get(info); - if (!team) - return -EINVAL; + if (!team) { + err = -EINVAL; + goto rtnl_unlock; + } err = team_nl_send_port_list_get(team, info->snd_portid, info->snd_seq, NLM_F_ACK, team_nl_send_unicast, NULL); team_nl_team_put(team); +rtnl_unlock: + rtnl_unlock(); + return err; } @@ -2961,11 +2955,9 @@ static void __team_port_change_port_removed(struct team_port *port) static void team_port_change_check(struct team_port *port, bool linkup) { - struct team *team = port->team; + ASSERT_RTNL(); - mutex_lock(&team->lock); __team_port_change_check(port, linkup); - mutex_unlock(&team->lock); } diff --git a/drivers/net/team/team_mode_activebackup.c b/drivers/net/team/team_mode_activebackup.c index e0f599e2a51d..1c3336c7a1b2 100644 --- a/drivers/net/team/team_mode_activebackup.c +++ b/drivers/net/team/team_mode_activebackup.c @@ -67,8 +67,7 @@ static void ab_active_port_get(struct team *team, struct team_gsetter_ctx *ctx) { struct team_port *active_port; - active_port = rcu_dereference_protected(ab_priv(team)->active_port, - lockdep_is_held(&team->lock)); + active_port = rtnl_dereference(ab_priv(team)->active_port); if (active_port) ctx->data.u32_val = active_port->dev->ifindex; else diff --git a/drivers/net/team/team_mode_loadbalance.c b/drivers/net/team/team_mode_loadbalance.c index 00f8989c29c0..b14538bde2f8 100644 --- a/drivers/net/team/team_mode_loadbalance.c +++ b/drivers/net/team/team_mode_loadbalance.c @@ -301,8 +301,7 @@ static int lb_bpf_func_set(struct team *team, struct team_gsetter_ctx *ctx) if (lb_priv->ex->orig_fprog) { /* Clear old filter data */ __fprog_destroy(lb_priv->ex->orig_fprog); - orig_fp = rcu_dereference_protected(lb_priv->fp, - lockdep_is_held(&team->lock)); + orig_fp = rtnl_dereference(lb_priv->fp); } rcu_assign_pointer(lb_priv->fp, fp); @@ -324,8 +323,7 @@ static void lb_bpf_func_free(struct team *team) return; __fprog_destroy(lb_priv->ex->orig_fprog); - fp = rcu_dereference_protected(lb_priv->fp, - lockdep_is_held(&team->lock)); + fp = rtnl_dereference(lb_priv->fp); bpf_prog_destroy(fp); } @@ -335,8 +333,7 @@ static void lb_tx_method_get(struct team *team, struct team_gsetter_ctx *ctx) lb_select_tx_port_func_t *func; char *name; - func = rcu_dereference_protected(lb_priv->select_tx_port_func, - lockdep_is_held(&team->lock)); + func = rtnl_dereference(lb_priv->select_tx_port_func); name = lb_select_tx_port_get_name(func); BUG_ON(!name); ctx->data.str_val = name; @@ -478,7 +475,7 @@ static void lb_stats_refresh(struct work_struct *work) team = lb_priv_ex->team; lb_priv = get_lb_priv(team); - if (!mutex_trylock(&team->lock)) { + if (!rtnl_trylock()) { schedule_delayed_work(&lb_priv_ex->stats.refresh_dw, 0); return; } @@ -515,7 +512,7 @@ static void lb_stats_refresh(struct work_struct *work) schedule_delayed_work(&lb_priv_ex->stats.refresh_dw, (lb_priv_ex->stats.refresh_interval * HZ) / 10); - mutex_unlock(&team->lock); + rtnl_unlock(); } static void lb_stats_refresh_interval_get(struct team *team, diff --git a/include/linux/if_team.h b/include/linux/if_team.h index cdc684e04a2f..ce97d891cf72 100644 --- a/include/linux/if_team.h +++ b/include/linux/if_team.h @@ -191,8 +191,6 @@ struct team { const struct header_ops *header_ops_cache; - struct mutex lock; /* used for overall locking, e.g. port lists write */ - /* * List of enabled ports and their count */ @@ -223,7 +221,6 @@ struct team { atomic_t count_pending; struct delayed_work dw; } mcast_rejoin; - struct lock_class_key team_lock_key; long mode_priv[TEAM_MODE_PRIV_LONGS]; }; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 125/480] wifi: ath11k: clear initialized flag for deinit-ed srng lists 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (123 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 124/480] team: replace team lock with rtnl lock Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 126/480] wifi: ath12k: Clear auth flag only for actual association in security mode Greg Kroah-Hartman ` (366 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Sergey Senozhatsky, Baochen Qiang, Jeff Johnson, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Sergey Senozhatsky <senozhatsky@chromium.org> [ Upstream commit a5b46aa7cf5f05c213316a018e49a8e086efd98e ] In a number of cases we see kernel panics on resume due to ath11k kernel page fault, which happens under the following circumstances: 1) First ath11k_hal_dump_srng_stats() call Last interrupt received for each group: ath11k_pci 0000:01:00.0: group_id 0 22511ms before ath11k_pci 0000:01:00.0: group_id 1 14440788ms before [..] ath11k_pci 0000:01:00.0: failed to receive control response completion, polling.. ath11k_pci 0000:01:00.0: Service connect timeout ath11k_pci 0000:01:00.0: failed to connect to HTT: -110 ath11k_pci 0000:01:00.0: failed to start core: -110 ath11k_pci 0000:01:00.0: firmware crashed: MHI_CB_EE_RDDM ath11k_pci 0000:01:00.0: already resetting count 2 ath11k_pci 0000:01:00.0: failed to wait wlan mode request (mode 4): -110 ath11k_pci 0000:01:00.0: qmi failed to send wlan mode off: -110 ath11k_pci 0000:01:00.0: failed to reconfigure driver on crash recovery [..] 2) At this point reconfiguration fails (we have 2 resets) and ath11k_core_reconfigure_on_crash() calls ath11k_hal_srng_deinit() which destroys srng lists. However, it does not reset per-list ->initialized flag. 3) Second ath11k_hal_dump_srng_stats() call sees stale ->initialized flag and attempts to dump srng stats: Last interrupt received for each group: ath11k_pci 0000:01:00.0: group_id 0 66785ms before ath11k_pci 0000:01:00.0: group_id 1 14485062ms before ath11k_pci 0000:01:00.0: group_id 2 14485062ms before ath11k_pci 0000:01:00.0: group_id 3 14485062ms before ath11k_pci 0000:01:00.0: group_id 4 14780845ms before ath11k_pci 0000:01:00.0: group_id 5 14780845ms before ath11k_pci 0000:01:00.0: group_id 6 14485062ms before ath11k_pci 0000:01:00.0: group_id 7 66814ms before ath11k_pci 0000:01:00.0: group_id 8 68997ms before ath11k_pci 0000:01:00.0: group_id 9 67588ms before ath11k_pci 0000:01:00.0: group_id 10 69511ms before BUG: unable to handle page fault for address: ffffa007404eb010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 10022d067 PMD 100b01067 PTE 0 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k] Call Trace: <TASK> ? __die_body+0xae/0xb0 ? page_fault_oops+0x381/0x3e0 ? exc_page_fault+0x69/0xa0 ? asm_exc_page_fault+0x22/0x30 ? ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k (HASH:6cea 4)] ath11k_qmi_driver_event_work+0xbd/0x1050 [ath11k (HASH:6cea 4)] worker_thread+0x389/0x930 kthread+0x149/0x170 Clear per-list ->initialized flag in ath11k_hal_srng_deinit(). Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org> Reviewed-by: Baochen Qiang <quic_bqiang@quicinc.com> Fixes: 5118935b1bc2 ("ath11k: dump SRNG stats during FW assert") Link: https://patch.msgid.link/20250612084551.702803-1-senozhatsky@chromium.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/wireless/ath/ath11k/hal.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/wireless/ath/ath11k/hal.c b/drivers/net/wireless/ath/ath11k/hal.c index 8cb1505a5a0c..cab11a35f911 100644 --- a/drivers/net/wireless/ath/ath11k/hal.c +++ b/drivers/net/wireless/ath/ath11k/hal.c @@ -1346,6 +1346,10 @@ EXPORT_SYMBOL(ath11k_hal_srng_init); void ath11k_hal_srng_deinit(struct ath11k_base *ab) { struct ath11k_hal *hal = &ab->hal; + int i; + + for (i = 0; i < HAL_SRNG_RING_ID_MAX; i++) + ab->hal.srng_list[i].initialized = 0; ath11k_hal_unregister_srng_key(ab); ath11k_hal_free_cont_rdp(ab); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 126/480] wifi: ath12k: Clear auth flag only for actual association in security mode 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (124 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 125/480] wifi: ath11k: clear initialized flag for deinit-ed srng lists Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 127/480] tcp: fix tcp_ofo_queue() to avoid including too much DUP SACK range Greg Kroah-Hartman ` (365 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Thiraviyam Mariyappan, Ramasamy Kaliappan, Jeff Johnson, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thiraviyam Mariyappan <thiraviyam.mariyappan@oss.qualcomm.com> [ Upstream commit c27bb624b3d789a337df3bbcc020a575680555cc ] When setting a new bitrate, WMI peer association command is sent from the host without the peer authentication bit set in peer_flags for security mode, which causes ping failure. The firmware handles peer_flags when the client is associating, as the peer authentication bit in peer_flags is set after the key exchange. When the WMI peer association command is sent from the host to update the new bitrate for an associated STA, the firmware expects the WMI peer authentication bit to be set in peer_flags. Fix this issue by ensuring that the WMI peer auth bit is set in peer_flags in WMI peer association command when updating the new bitrate. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Thiraviyam Mariyappan <thiraviyam.mariyappan@oss.qualcomm.com> Signed-off-by: Ramasamy Kaliappan <ramasamy.kaliappan@oss.qualcomm.com> Link: https://patch.msgid.link/20250608145651.1735236-1-ramasamy.kaliappan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/wireless/ath/ath12k/mac.c | 4 ++++ drivers/net/wireless/ath/ath12k/wmi.c | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c index 7333ca58d541..ccc27863f333 100644 --- a/drivers/net/wireless/ath/ath12k/mac.c +++ b/drivers/net/wireless/ath/ath12k/mac.c @@ -3315,6 +3315,7 @@ static void ath12k_bss_assoc(struct ath12k *ar, rcu_read_unlock(); + peer_arg->is_assoc = true; ret = ath12k_wmi_send_peer_assoc_cmd(ar, peer_arg); if (ret) { ath12k_warn(ar->ab, "failed to run peer assoc for %pM vdev %i: %d\n", @@ -5087,6 +5088,8 @@ static int ath12k_mac_station_assoc(struct ath12k *ar, "invalid peer NSS %d\n", peer_arg->peer_nss); return -EINVAL; } + + peer_arg->is_assoc = true; ret = ath12k_wmi_send_peer_assoc_cmd(ar, peer_arg); if (ret) { ath12k_warn(ar->ab, "failed to run peer assoc for STA %pM vdev %i: %d\n", @@ -5333,6 +5336,7 @@ static void ath12k_sta_rc_update_wk(struct wiphy *wiphy, struct wiphy_work *wk) ath12k_peer_assoc_prepare(ar, arvif, arsta, peer_arg, true); + peer_arg->is_assoc = false; err = ath12k_wmi_send_peer_assoc_cmd(ar, peer_arg); if (err) ath12k_warn(ar->ab, "failed to run peer assoc for STA %pM vdev %i: %d\n", diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c index a44fc9106634..f021498e5278 100644 --- a/drivers/net/wireless/ath/ath12k/wmi.c +++ b/drivers/net/wireless/ath/ath12k/wmi.c @@ -2136,7 +2136,7 @@ static void ath12k_wmi_copy_peer_flags(struct wmi_peer_assoc_complete_cmd *cmd, cmd->peer_flags |= cpu_to_le32(WMI_PEER_AUTH); if (arg->need_ptk_4_way) { cmd->peer_flags |= cpu_to_le32(WMI_PEER_NEED_PTK_4_WAY); - if (!hw_crypto_disabled) + if (!hw_crypto_disabled && arg->is_assoc) cmd->peer_flags &= cpu_to_le32(~WMI_PEER_AUTH); } if (arg->need_gtk_2_way) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 127/480] tcp: fix tcp_ofo_queue() to avoid including too much DUP SACK range 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (125 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 126/480] wifi: ath12k: Clear auth flag only for actual association in security mode Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 128/480] net/mlx5: Check device memory pointer before usage Greg Kroah-Hartman ` (364 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, xin.guo, Eric Dumazet, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: xin.guo <guoxin0309@gmail.com> [ Upstream commit a041f70e573e185d5d5fdbba53f0db2fbe7257ad ] If the new coming segment covers more than one skbs in the ofo queue, and which seq is equal to rcv_nxt, then the sequence range that is duplicated will be sent as DUP SACK, the detail as below, in step6, the {501,2001} range is clearly including too much DUP SACK range, in violation of RFC 2883 rules. 1. client > server: Flags [.], seq 501:1001, ack 1325288529, win 20000, length 500 2. server > client: Flags [.], ack 1, [nop,nop,sack 1 {501:1001}], length 0 3. client > server: Flags [.], seq 1501:2001, ack 1325288529, win 20000, length 500 4. server > client: Flags [.], ack 1, [nop,nop,sack 2 {1501:2001} {501:1001}], length 0 5. client > server: Flags [.], seq 1:2001, ack 1325288529, win 20000, length 2000 6. server > client: Flags [.], ack 2001, [nop,nop,sack 1 {501:2001}], length 0 After this fix, the final ACK is as below: 6. server > client: Flags [.], ack 2001, options [nop,nop,sack 1 {501:1001}], length 0 [edumazet] added a new packetdrill test in the following patch. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: xin.guo <guoxin0309@gmail.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20250626123420.1933835-2-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/ipv4/tcp_input.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index bce2a111cc9e..e75ee9023674 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -4986,8 +4986,9 @@ static void tcp_ofo_queue(struct sock *sk) if (before(TCP_SKB_CB(skb)->seq, dsack_high)) { __u32 dsack = dsack_high; + if (before(TCP_SKB_CB(skb)->end_seq, dsack_high)) - dsack_high = TCP_SKB_CB(skb)->end_seq; + dsack = TCP_SKB_CB(skb)->end_seq; tcp_dsack_extend(sk, TCP_SKB_CB(skb)->seq, dsack); } p = rb_next(p); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 128/480] net/mlx5: Check device memory pointer before usage 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (126 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 127/480] tcp: fix tcp_ofo_queue() to avoid including too much DUP SACK range Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 129/480] net: dst: annotate data-races around dst->input Greg Kroah-Hartman ` (363 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Stav Aviram, Leon Romanovsky, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Stav Aviram <saviram@nvidia.com> [ Upstream commit 70f238c902b8c0461ae6fbb8d1a0bbddc4350eea ] Add a NULL check before accessing device memory to prevent a crash if dev->dm allocation in mlx5_init_once() fails. Fixes: c9b9dcb430b3 ("net/mlx5: Move device memory management to mlx5_core") Signed-off-by: Stav Aviram <saviram@nvidia.com> Link: https://patch.msgid.link/c88711327f4d74d5cebc730dc629607e989ca187.1751370035.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/infiniband/hw/mlx5/dm.c | 2 +- drivers/net/ethernet/mellanox/mlx5/core/lib/dm.c | 4 ++-- drivers/net/ethernet/mellanox/mlx5/core/main.c | 3 --- 3 files changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/hw/mlx5/dm.c b/drivers/infiniband/hw/mlx5/dm.c index b4c97fb62abf..9ded2b7c1e31 100644 --- a/drivers/infiniband/hw/mlx5/dm.c +++ b/drivers/infiniband/hw/mlx5/dm.c @@ -282,7 +282,7 @@ static struct ib_dm *handle_alloc_dm_memic(struct ib_ucontext *ctx, int err; u64 address; - if (!MLX5_CAP_DEV_MEM(dm_db->dev, memic)) + if (!dm_db || !MLX5_CAP_DEV_MEM(dm_db->dev, memic)) return ERR_PTR(-EOPNOTSUPP); dm = kzalloc(sizeof(*dm), GFP_KERNEL); diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lib/dm.c b/drivers/net/ethernet/mellanox/mlx5/core/lib/dm.c index 7c5516b0a844..8115071c34a4 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/lib/dm.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/lib/dm.c @@ -30,7 +30,7 @@ struct mlx5_dm *mlx5_dm_create(struct mlx5_core_dev *dev) dm = kzalloc(sizeof(*dm), GFP_KERNEL); if (!dm) - return ERR_PTR(-ENOMEM); + return NULL; spin_lock_init(&dm->lock); @@ -96,7 +96,7 @@ struct mlx5_dm *mlx5_dm_create(struct mlx5_core_dev *dev) err_steering: kfree(dm); - return ERR_PTR(-ENOMEM); + return NULL; } void mlx5_dm_cleanup(struct mlx5_core_dev *dev) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c index 9c1504d29d34..e7bcd0f0a709 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c @@ -1102,9 +1102,6 @@ static int mlx5_init_once(struct mlx5_core_dev *dev) } dev->dm = mlx5_dm_create(dev); - if (IS_ERR(dev->dm)) - mlx5_core_warn(dev, "Failed to init device memory %ld\n", PTR_ERR(dev->dm)); - dev->tracer = mlx5_fw_tracer_create(dev); dev->hv_vhca = mlx5_hv_vhca_create(dev); dev->rsc_dump = mlx5_rsc_dump_create(dev); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 129/480] net: dst: annotate data-races around dst->input 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (127 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 128/480] net/mlx5: Check device memory pointer before usage Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 130/480] net: dst: annotate data-races around dst->output Greg Kroah-Hartman ` (362 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Eric Dumazet, Kuniyuki Iwashima, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Eric Dumazet <edumazet@google.com> [ Upstream commit f1c5fd34891a1c242885f48c2e4dc52df180f311 ] dst_dev_put() can overwrite dst->input while other cpus might read this field (for instance from dst_input()) Add READ_ONCE()/WRITE_ONCE() annotations to suppress potential issues. We will likely need full RCU protection later. Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()") Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20250630121934.3399505-5-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- include/net/dst.h | 2 +- include/net/lwtunnel.h | 4 ++-- net/core/dst.c | 2 +- net/ipv4/route.c | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/include/net/dst.h b/include/net/dst.h index 78c78cdce0e9..65d81116d6bf 100644 --- a/include/net/dst.h +++ b/include/net/dst.h @@ -466,7 +466,7 @@ INDIRECT_CALLABLE_DECLARE(int ip_local_deliver(struct sk_buff *)); /* Input packet from network to transport. */ static inline int dst_input(struct sk_buff *skb) { - return INDIRECT_CALL_INET(skb_dst(skb)->input, + return INDIRECT_CALL_INET(READ_ONCE(skb_dst(skb)->input), ip6_input, ip_local_deliver, skb); } diff --git a/include/net/lwtunnel.h b/include/net/lwtunnel.h index 39cd50300a18..a8cf7036c5e6 100644 --- a/include/net/lwtunnel.h +++ b/include/net/lwtunnel.h @@ -144,8 +144,8 @@ static inline void lwtunnel_set_redirect(struct dst_entry *dst) dst->output = lwtunnel_output; } if (lwtunnel_input_redirect(dst->lwtstate)) { - dst->lwtstate->orig_input = dst->input; - dst->input = lwtunnel_input; + dst->lwtstate->orig_input = READ_ONCE(dst->input); + WRITE_ONCE(dst->input, lwtunnel_input); } } #else diff --git a/net/core/dst.c b/net/core/dst.c index 795ca07e28a4..b46f7722a1b6 100644 --- a/net/core/dst.c +++ b/net/core/dst.c @@ -148,7 +148,7 @@ void dst_dev_put(struct dst_entry *dst) dst->obsolete = DST_OBSOLETE_DEAD; if (dst->ops->ifdown) dst->ops->ifdown(dst, dev); - dst->input = dst_discard; + WRITE_ONCE(dst->input, dst_discard); dst->output = dst_discard_out; dst->dev = blackhole_netdev; netdev_ref_replace(dev, blackhole_netdev, &dst->dev_tracker, diff --git a/net/ipv4/route.c b/net/ipv4/route.c index 5d7c7efea66c..3db3840cefee 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -1684,7 +1684,7 @@ struct rtable *rt_dst_clone(struct net_device *dev, struct rtable *rt) else if (rt->rt_gw_family == AF_INET6) new_rt->rt_gw6 = rt->rt_gw6; - new_rt->dst.input = rt->dst.input; + new_rt->dst.input = READ_ONCE(rt->dst.input); new_rt->dst.output = rt->dst.output; new_rt->dst.error = rt->dst.error; new_rt->dst.lastuse = jiffies; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 130/480] net: dst: annotate data-races around dst->output 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (128 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 129/480] net: dst: annotate data-races around dst->input Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 131/480] net: dst: add four helpers to annotate data-races around dst->dev Greg Kroah-Hartman ` (361 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Eric Dumazet, Kuniyuki Iwashima, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Eric Dumazet <edumazet@google.com> [ Upstream commit 2dce8c52a98995c4719def6f88629ab1581c0b82 ] dst_dev_put() can overwrite dst->output while other cpus might read this field (for instance from dst_output()) Add READ_ONCE()/WRITE_ONCE() annotations to suppress potential issues. We will likely need RCU protection in the future. Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()") Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20250630121934.3399505-6-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- include/net/dst.h | 2 +- include/net/lwtunnel.h | 4 ++-- net/core/dst.c | 2 +- net/ipv4/route.c | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/include/net/dst.h b/include/net/dst.h index 65d81116d6bf..2caf85e2ce86 100644 --- a/include/net/dst.h +++ b/include/net/dst.h @@ -456,7 +456,7 @@ INDIRECT_CALLABLE_DECLARE(int ip_output(struct net *, struct sock *, /* Output packet to network from transport. */ static inline int dst_output(struct net *net, struct sock *sk, struct sk_buff *skb) { - return INDIRECT_CALL_INET(skb_dst(skb)->output, + return INDIRECT_CALL_INET(READ_ONCE(skb_dst(skb)->output), ip6_output, ip_output, net, sk, skb); } diff --git a/include/net/lwtunnel.h b/include/net/lwtunnel.h index a8cf7036c5e6..eabe80d52a6c 100644 --- a/include/net/lwtunnel.h +++ b/include/net/lwtunnel.h @@ -140,8 +140,8 @@ int bpf_lwt_push_ip_encap(struct sk_buff *skb, void *hdr, u32 len, static inline void lwtunnel_set_redirect(struct dst_entry *dst) { if (lwtunnel_output_redirect(dst->lwtstate)) { - dst->lwtstate->orig_output = dst->output; - dst->output = lwtunnel_output; + dst->lwtstate->orig_output = READ_ONCE(dst->output); + WRITE_ONCE(dst->output, lwtunnel_output); } if (lwtunnel_input_redirect(dst->lwtstate)) { dst->lwtstate->orig_input = READ_ONCE(dst->input); diff --git a/net/core/dst.c b/net/core/dst.c index b46f7722a1b6..e483daf17666 100644 --- a/net/core/dst.c +++ b/net/core/dst.c @@ -149,7 +149,7 @@ void dst_dev_put(struct dst_entry *dst) if (dst->ops->ifdown) dst->ops->ifdown(dst, dev); WRITE_ONCE(dst->input, dst_discard); - dst->output = dst_discard_out; + WRITE_ONCE(dst->output, dst_discard_out); dst->dev = blackhole_netdev; netdev_ref_replace(dev, blackhole_netdev, &dst->dev_tracker, GFP_ATOMIC); diff --git a/net/ipv4/route.c b/net/ipv4/route.c index 3db3840cefee..e686f088bc67 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -1685,7 +1685,7 @@ struct rtable *rt_dst_clone(struct net_device *dev, struct rtable *rt) new_rt->rt_gw6 = rt->rt_gw6; new_rt->dst.input = READ_ONCE(rt->dst.input); - new_rt->dst.output = rt->dst.output; + new_rt->dst.output = READ_ONCE(rt->dst.output); new_rt->dst.error = rt->dst.error; new_rt->dst.lastuse = jiffies; new_rt->dst.lwtstate = lwtstate_get(rt->dst.lwtstate); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 131/480] net: dst: add four helpers to annotate data-races around dst->dev 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (129 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 130/480] net: dst: annotate data-races around dst->output Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 132/480] wifi: iwlwifi: Fix error code in iwl_op_mode_dvm_start() Greg Kroah-Hartman ` (360 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Eric Dumazet, Kuniyuki Iwashima, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Eric Dumazet <edumazet@google.com> [ Upstream commit 88fe14253e181878c2ddb51a298ae8c468a63010 ] dst->dev is read locklessly in many contexts, and written in dst_dev_put(). Fixing all the races is going to need many changes. We probably will have to add full RCU protection. Add three helpers to ease this painful process. static inline struct net_device *dst_dev(const struct dst_entry *dst) { return READ_ONCE(dst->dev); } static inline struct net_device *skb_dst_dev(const struct sk_buff *skb) { return dst_dev(skb_dst(skb)); } static inline struct net *skb_dst_dev_net(const struct sk_buff *skb) { return dev_net(skb_dst_dev(skb)); } static inline struct net *skb_dst_dev_net_rcu(const struct sk_buff *skb) { return dev_net_rcu(skb_dst_dev(skb)); } Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()") Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20250630121934.3399505-7-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- include/net/dst.h | 20 ++++++++++++++++++++ net/core/dst.c | 4 ++-- net/core/sock.c | 8 ++++---- 3 files changed, 26 insertions(+), 6 deletions(-) diff --git a/include/net/dst.h b/include/net/dst.h index 2caf85e2ce86..32dafbab4cd0 100644 --- a/include/net/dst.h +++ b/include/net/dst.h @@ -561,6 +561,26 @@ static inline void skb_dst_update_pmtu_no_confirm(struct sk_buff *skb, u32 mtu) dst->ops->update_pmtu(dst, NULL, skb, mtu, false); } +static inline struct net_device *dst_dev(const struct dst_entry *dst) +{ + return READ_ONCE(dst->dev); +} + +static inline struct net_device *skb_dst_dev(const struct sk_buff *skb) +{ + return dst_dev(skb_dst(skb)); +} + +static inline struct net *skb_dst_dev_net(const struct sk_buff *skb) +{ + return dev_net(skb_dst_dev(skb)); +} + +static inline struct net *skb_dst_dev_net_rcu(const struct sk_buff *skb) +{ + return dev_net_rcu(skb_dst_dev(skb)); +} + struct dst_entry *dst_blackhole_check(struct dst_entry *dst, u32 cookie); void dst_blackhole_update_pmtu(struct dst_entry *dst, struct sock *sk, struct sk_buff *skb, u32 mtu, bool confirm_neigh); diff --git a/net/core/dst.c b/net/core/dst.c index e483daf17666..b3a12c7c08af 100644 --- a/net/core/dst.c +++ b/net/core/dst.c @@ -150,7 +150,7 @@ void dst_dev_put(struct dst_entry *dst) dst->ops->ifdown(dst, dev); WRITE_ONCE(dst->input, dst_discard); WRITE_ONCE(dst->output, dst_discard_out); - dst->dev = blackhole_netdev; + WRITE_ONCE(dst->dev, blackhole_netdev); netdev_ref_replace(dev, blackhole_netdev, &dst->dev_tracker, GFP_ATOMIC); } @@ -263,7 +263,7 @@ unsigned int dst_blackhole_mtu(const struct dst_entry *dst) { unsigned int mtu = dst_metric_raw(dst, RTAX_MTU); - return mtu ? : dst->dev->mtu; + return mtu ? : dst_dev(dst)->mtu; } EXPORT_SYMBOL_GPL(dst_blackhole_mtu); diff --git a/net/core/sock.c b/net/core/sock.c index 3e8c548cb1f8..bcd0d6c757ce 100644 --- a/net/core/sock.c +++ b/net/core/sock.c @@ -2557,8 +2557,8 @@ static u32 sk_dst_gso_max_size(struct sock *sk, struct dst_entry *dst) !ipv6_addr_v4mapped(&sk->sk_v6_rcv_saddr)); #endif /* pairs with the WRITE_ONCE() in netif_set_gso(_ipv4)_max_size() */ - max_size = is_ipv6 ? READ_ONCE(dst->dev->gso_max_size) : - READ_ONCE(dst->dev->gso_ipv4_max_size); + max_size = is_ipv6 ? READ_ONCE(dst_dev(dst)->gso_max_size) : + READ_ONCE(dst_dev(dst)->gso_ipv4_max_size); if (max_size > GSO_LEGACY_MAX_SIZE && !sk_is_tcp(sk)) max_size = GSO_LEGACY_MAX_SIZE; @@ -2569,7 +2569,7 @@ void sk_setup_caps(struct sock *sk, struct dst_entry *dst) { u32 max_segs = 1; - sk->sk_route_caps = dst->dev->features; + sk->sk_route_caps = dst_dev(dst)->features; if (sk_is_tcp(sk)) { struct inet_connection_sock *icsk = inet_csk(sk); @@ -2587,7 +2587,7 @@ void sk_setup_caps(struct sock *sk, struct dst_entry *dst) sk->sk_route_caps |= NETIF_F_SG | NETIF_F_HW_CSUM; sk->sk_gso_max_size = sk_dst_gso_max_size(sk, dst); /* pairs with the WRITE_ONCE() in netif_set_gso_max_segs() */ - max_segs = max_t(u32, READ_ONCE(dst->dev->gso_max_segs), 1); + max_segs = max_t(u32, READ_ONCE(dst_dev(dst)->gso_max_segs), 1); } } sk->sk_gso_max_segs = max_segs; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 132/480] wifi: iwlwifi: Fix error code in iwl_op_mode_dvm_start() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (130 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 131/480] net: dst: add four helpers to annotate data-races around dst->dev Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 133/480] kselftest/arm64: Fix check for setting new VLs in sve-ptrace Greg Kroah-Hartman ` (359 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Dan Carpenter, Miri Korenblit, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Dan Carpenter <dan.carpenter@linaro.org> [ Upstream commit cf80c02a9fdb6c5bc8508beb6a0f6a1294fc32f6 ] Preserve the error code if iwl_setup_deferred_work() fails. The current code returns ERR_PTR(0) (which is NULL) on this path. I believe the missing error code potentially leads to a use after free involving debugfs. Fixes: 90a0d9f33996 ("iwlwifi: Add missing check for alloc_ordered_workqueue") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/a7a1cd2c-ce01-461a-9afd-dbe535f8df01@sabinyo.mountain Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/wireless/intel/iwlwifi/dvm/main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/main.c b/drivers/net/wireless/intel/iwlwifi/dvm/main.c index cd20958fb91a..59c13c40bb83 100644 --- a/drivers/net/wireless/intel/iwlwifi/dvm/main.c +++ b/drivers/net/wireless/intel/iwlwifi/dvm/main.c @@ -1468,7 +1468,8 @@ static struct iwl_op_mode *iwl_op_mode_dvm_start(struct iwl_trans *trans, /******************** * 6. Setup services ********************/ - if (iwl_setup_deferred_work(priv)) + err = iwl_setup_deferred_work(priv); + if (err) goto out_uninit_drv; iwl_setup_rx_handlers(priv); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 133/480] kselftest/arm64: Fix check for setting new VLs in sve-ptrace 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (131 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 132/480] wifi: iwlwifi: Fix error code in iwl_op_mode_dvm_start() Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 134/480] bpf: Ensure RCU lock is held around bpf_prog_ksym_find Greg Kroah-Hartman ` (358 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Mark Rutland, Dev Jain, Mark Brown, Catalin Marinas, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Mark Brown <broonie@kernel.org> [ Upstream commit 867446f090589626497638f70b10be5e61a0b925 ] The check that the new vector length we set was the expected one was typoed to an assignment statement which for some reason the compilers didn't spot, most likely due to the macros involved. Fixes: a1d7111257cd ("selftests: arm64: More comprehensively test the SVE ptrace interface") Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Dev Jain <dev.jain@arm.com> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250609-kselftest-arm64-ssve-fixups-v2-1-998fcfa6f240@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/testing/selftests/arm64/fp/sve-ptrace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/arm64/fp/sve-ptrace.c b/tools/testing/selftests/arm64/fp/sve-ptrace.c index 577b6e05e860..c499d5789dd5 100644 --- a/tools/testing/selftests/arm64/fp/sve-ptrace.c +++ b/tools/testing/selftests/arm64/fp/sve-ptrace.c @@ -253,7 +253,7 @@ static void ptrace_set_get_vl(pid_t child, const struct vec_type *type, return; } - ksft_test_result(new_sve->vl = prctl_vl, "Set %s VL %u\n", + ksft_test_result(new_sve->vl == prctl_vl, "Set %s VL %u\n", type->name, vl); free(new_sve); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 134/480] bpf: Ensure RCU lock is held around bpf_prog_ksym_find 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (132 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 133/480] kselftest/arm64: Fix check for setting new VLs in sve-ptrace Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 135/480] drm/msm/dpu: Fill in min_prefill_lines for SC8180X Greg Kroah-Hartman ` (357 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Emil Tsalapatis, Kumar Kartikeya Dwivedi, Alexei Starovoitov, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Kumar Kartikeya Dwivedi <memxor@gmail.com> [ Upstream commit d090326860096df9dac6f27cff76d3f8df44d4f1 ] Add a warning to ensure RCU lock is held around tree lookup, and then fix one of the invocations in bpf_stack_walker. The program has an active stack frame and won't disappear. Use the opportunity to remove unneeded invocation of is_bpf_text_address. Fixes: f18b03fabaa9 ("bpf: Implement BPF exceptions") Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/r/20250703204818.925464-5-memxor@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- kernel/bpf/core.c | 5 ++++- kernel/bpf/helpers.c | 11 +++++++++-- 2 files changed, 13 insertions(+), 3 deletions(-) diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c index c20babbf998f..93e49b0c218b 100644 --- a/kernel/bpf/core.c +++ b/kernel/bpf/core.c @@ -778,7 +778,10 @@ bool is_bpf_text_address(unsigned long addr) struct bpf_prog *bpf_prog_ksym_find(unsigned long addr) { - struct bpf_ksym *ksym = bpf_ksym_find(addr); + struct bpf_ksym *ksym; + + WARN_ON_ONCE(!rcu_read_lock_held()); + ksym = bpf_ksym_find(addr); return ksym && ksym->prog ? container_of(ksym, struct bpf_prog_aux, ksym)->prog : diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c index 52d02bc0abb2..3312442bc389 100644 --- a/kernel/bpf/helpers.c +++ b/kernel/bpf/helpers.c @@ -2864,9 +2864,16 @@ static bool bpf_stack_walker(void *cookie, u64 ip, u64 sp, u64 bp) struct bpf_throw_ctx *ctx = cookie; struct bpf_prog *prog; - if (!is_bpf_text_address(ip)) - return !ctx->cnt; + /* + * The RCU read lock is held to safely traverse the latch tree, but we + * don't need its protection when accessing the prog, since it has an + * active stack frame on the current stack trace, and won't disappear. + */ + rcu_read_lock(); prog = bpf_prog_ksym_find(ip); + rcu_read_unlock(); + if (!prog) + return !ctx->cnt; ctx->cnt++; if (bpf_is_subprog(prog)) return true; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 135/480] drm/msm/dpu: Fill in min_prefill_lines for SC8180X 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (133 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 134/480] bpf: Ensure RCU lock is held around bpf_prog_ksym_find Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 136/480] m68k: Dont unregister boot console needlessly Greg Kroah-Hartman ` (356 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Konrad Dybcio, Dmitry Baryshkov, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> [ Upstream commit 5136acc40afc0261802e5cb01b04f871bf6d876b ] Based on the downstream release, predictably same value as for SM8150. Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Fixes: f3af2d6ee9ab ("drm/msm/dpu: Add SC8180x to hw catalog") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/657794/ Link: https://lore.kernel.org/r/20250610-topic-dpu_8180_mpl-v1-1-f480cd22f11c@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h index e736eb73a7e6..49aed344d346 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h @@ -383,6 +383,7 @@ static const struct dpu_perf_cfg sc8180x_perf_data = { .min_core_ib = 2400000, .min_llcc_ib = 800000, .min_dram_ib = 800000, + .min_prefill_lines = 24, .danger_lut_tbl = {0xf, 0xffff, 0x0}, .safe_lut_tbl = {0xfff0, 0xf000, 0xffff}, .qos_lut_tbl = { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 136/480] m68k: Dont unregister boot console needlessly 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (134 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 135/480] drm/msm/dpu: Fill in min_prefill_lines for SC8180X Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 137/480] refscale: Check that nreaders and loops multiplication doesnt overflow Greg Kroah-Hartman ` (355 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Daniel Palmer, Finn Thain, Geert Uytterhoeven, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Finn Thain <fthain@linux-m68k.org> [ Upstream commit 83f672a7f69ec38b1bbb27221e342937f68c11c7 ] When MACH_IS_MVME147, the boot console calls mvme147_scc_write() to generate console output. That will continue to work even after debug_cons_nputs() becomes unavailable so there's no need to unregister the boot console. Take the opportunity to remove a repeated MACH_IS_* test. Use the actual .write method (instead of a wrapper) and test that pointer instead. This means adding an unused parameter to debug_cons_nputs() for consistency with the struct console API. early_printk.c is only built when CONFIG_EARLY_PRINTK=y. As of late, head.S is only built when CONFIG_MMU_MOTOROLA=y. So let the former symbol depend on the latter, to obviate some ifdef conditionals. Cc: Daniel Palmer <daniel@0x0f.com> Fixes: 077b33b9e283 ("m68k: mvme147: Reinstate early console") Signed-off-by: Finn Thain <fthain@linux-m68k.org> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/d1d4328e5aa9a87bd8352529ce62b767731c0530.1743467205.git.fthain@linux-m68k.org Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/m68k/Kconfig.debug | 2 +- arch/m68k/kernel/early_printk.c | 42 +++++++++++---------------------- arch/m68k/kernel/head.S | 8 +++---- 3 files changed, 19 insertions(+), 33 deletions(-) diff --git a/arch/m68k/Kconfig.debug b/arch/m68k/Kconfig.debug index 30638a6e8edc..d036f903864c 100644 --- a/arch/m68k/Kconfig.debug +++ b/arch/m68k/Kconfig.debug @@ -10,7 +10,7 @@ config BOOTPARAM_STRING config EARLY_PRINTK bool "Early printk" - depends on !(SUN3 || M68000 || COLDFIRE) + depends on MMU_MOTOROLA help Write kernel log output directly to a serial port. Where implemented, output goes to the framebuffer as well. diff --git a/arch/m68k/kernel/early_printk.c b/arch/m68k/kernel/early_printk.c index f11ef9f1f56f..521cbb8a150c 100644 --- a/arch/m68k/kernel/early_printk.c +++ b/arch/m68k/kernel/early_printk.c @@ -16,25 +16,10 @@ #include "../mvme147/mvme147.h" #include "../mvme16x/mvme16x.h" -asmlinkage void __init debug_cons_nputs(const char *s, unsigned n); - -static void __ref debug_cons_write(struct console *c, - const char *s, unsigned n) -{ -#if !(defined(CONFIG_SUN3) || defined(CONFIG_M68000) || \ - defined(CONFIG_COLDFIRE)) - if (MACH_IS_MVME147) - mvme147_scc_write(c, s, n); - else if (MACH_IS_MVME16x) - mvme16x_cons_write(c, s, n); - else - debug_cons_nputs(s, n); -#endif -} +asmlinkage void __init debug_cons_nputs(struct console *c, const char *s, unsigned int n); static struct console early_console_instance = { .name = "debug", - .write = debug_cons_write, .flags = CON_PRINTBUFFER | CON_BOOT, .index = -1 }; @@ -44,6 +29,12 @@ static int __init setup_early_printk(char *buf) if (early_console || buf) return 0; + if (MACH_IS_MVME147) + early_console_instance.write = mvme147_scc_write; + else if (MACH_IS_MVME16x) + early_console_instance.write = mvme16x_cons_write; + else + early_console_instance.write = debug_cons_nputs; early_console = &early_console_instance; register_console(early_console); @@ -51,20 +42,15 @@ static int __init setup_early_printk(char *buf) } early_param("earlyprintk", setup_early_printk); -/* - * debug_cons_nputs() defined in arch/m68k/kernel/head.S cannot be called - * after init sections are discarded (for platforms that use it). - */ -#if !(defined(CONFIG_SUN3) || defined(CONFIG_M68000) || \ - defined(CONFIG_COLDFIRE)) - static int __init unregister_early_console(void) { - if (!early_console || MACH_IS_MVME16x) - return 0; + /* + * debug_cons_nputs() defined in arch/m68k/kernel/head.S cannot be + * called after init sections are discarded (for platforms that use it). + */ + if (early_console && early_console->write == debug_cons_nputs) + return unregister_console(early_console); - return unregister_console(early_console); + return 0; } late_initcall(unregister_early_console); - -#endif diff --git a/arch/m68k/kernel/head.S b/arch/m68k/kernel/head.S index 852255cf60de..ba22bc2f3d6d 100644 --- a/arch/m68k/kernel/head.S +++ b/arch/m68k/kernel/head.S @@ -3263,8 +3263,8 @@ func_return putn * turns around and calls the internal routines. This routine * is used by the boot console. * - * The calling parameters are: - * void debug_cons_nputs(const char *str, unsigned length) + * The function signature is - + * void debug_cons_nputs(struct console *c, const char *s, unsigned int n) * * This routine does NOT understand variable arguments only * simple strings! @@ -3273,8 +3273,8 @@ ENTRY(debug_cons_nputs) moveml %d0/%d1/%a0,%sp@- movew %sr,%sp@- ori #0x0700,%sr - movel %sp@(18),%a0 /* fetch parameter */ - movel %sp@(22),%d1 /* fetch parameter */ + movel %sp@(22),%a0 /* char *s */ + movel %sp@(26),%d1 /* unsigned int n */ jra 2f 1: #ifdef CONSOLE_DEBUG -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 137/480] refscale: Check that nreaders and loops multiplication doesnt overflow 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (135 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 136/480] m68k: Dont unregister boot console needlessly Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 138/480] wifi: mt76: mt7996: Fix secondary link lookup in mt7996_mcu_sta_mld_setup_tlv() Greg Kroah-Hartman ` (354 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Artem Sadovnikov, Neeraj Upadhyay (AMD), Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Artem Sadovnikov <a.sadovnikov@ispras.ru> [ Upstream commit 005b6187705bc9723518ce19c5cb911fc1f7ef07 ] The nreaders and loops variables are exposed as module parameters, which, in certain combinations, can lead to multiplication overflow. Besides, loops parameter is defined as long, while through the code is used as int, which can cause truncation on 64-bit kernels and possible zeroes where they shouldn't appear. Since code uses result of multiplication as int anyway, it only makes sense to replace loops with int. Multiplication overflow check is also added due to possible multiplication between two very big numbers. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 653ed64b01dc ("refperf: Add a test to measure performance of read-side synchronization") Signed-off-by: Artem Sadovnikov <a.sadovnikov@ispras.ru> Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.upadhyay@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- kernel/rcu/refscale.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/kernel/rcu/refscale.c b/kernel/rcu/refscale.c index f11a7c2af778..ab7fcdc94cc0 100644 --- a/kernel/rcu/refscale.c +++ b/kernel/rcu/refscale.c @@ -85,7 +85,7 @@ torture_param(int, holdoff, IS_BUILTIN(CONFIG_RCU_REF_SCALE_TEST) ? 10 : 0, // Number of typesafe_lookup structures, that is, the degree of concurrency. torture_param(long, lookup_instances, 0, "Number of typesafe_lookup structures."); // Number of loops per experiment, all readers execute operations concurrently. -torture_param(long, loops, 10000, "Number of loops per experiment."); +torture_param(int, loops, 10000, "Number of loops per experiment."); // Number of readers, with -1 defaulting to about 75% of the CPUs. torture_param(int, nreaders, -1, "Number of readers, -1 for 75% of CPUs."); // Number of runs. @@ -1140,7 +1140,7 @@ static void ref_scale_print_module_parms(const struct ref_scale_ops *cur_ops, const char *tag) { pr_alert("%s" SCALE_FLAG - "--- %s: verbose=%d verbose_batched=%d shutdown=%d holdoff=%d lookup_instances=%ld loops=%ld nreaders=%d nruns=%d readdelay=%d\n", scale_type, tag, + "--- %s: verbose=%d verbose_batched=%d shutdown=%d holdoff=%d lookup_instances=%ld loops=%d nreaders=%d nruns=%d readdelay=%d\n", scale_type, tag, verbose, verbose_batched, shutdown, holdoff, lookup_instances, loops, nreaders, nruns, readdelay); } @@ -1238,12 +1238,16 @@ ref_scale_init(void) // Reader tasks (default to ~75% of online CPUs). if (nreaders < 0) nreaders = (num_online_cpus() >> 1) + (num_online_cpus() >> 2); - if (WARN_ONCE(loops <= 0, "%s: loops = %ld, adjusted to 1\n", __func__, loops)) + if (WARN_ONCE(loops <= 0, "%s: loops = %d, adjusted to 1\n", __func__, loops)) loops = 1; if (WARN_ONCE(nreaders <= 0, "%s: nreaders = %d, adjusted to 1\n", __func__, nreaders)) nreaders = 1; if (WARN_ONCE(nruns <= 0, "%s: nruns = %d, adjusted to 1\n", __func__, nruns)) nruns = 1; + if (WARN_ONCE(loops > INT_MAX / nreaders, + "%s: nreaders * loops will overflow, adjusted loops to %d", + __func__, INT_MAX / nreaders)) + loops = INT_MAX / nreaders; reader_tasks = kcalloc(nreaders, sizeof(reader_tasks[0]), GFP_KERNEL); if (!reader_tasks) { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 138/480] wifi: mt76: mt7996: Fix secondary link lookup in mt7996_mcu_sta_mld_setup_tlv() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (136 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 137/480] refscale: Check that nreaders and loops multiplication doesnt overflow Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 139/480] wifi: mt76: mt7996: Fix possible OOB access in mt7996_tx() Greg Kroah-Hartman ` (353 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Lorenzo Bianconi, Felix Fietkau, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Lorenzo Bianconi <lorenzo@kernel.org> [ Upstream commit e8d7eef07199887161cd6f3c062406628781f8b6 ] Use proper link_id value for secondary link lookup in mt7996_mcu_sta_mld_setup_tlv routine. Fixes: 00cef41d9d8f5 ("wifi: mt76: mt7996: Add mt7996_mcu_sta_mld_setup_tlv() and mt7996_mcu_sta_eht_mld_tlv()") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250704-mt7996-mlo-fixes-v1-2-356456c73f43@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/wireless/mediatek/mt76/mt7996/mcu.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c index 63dc6df20c3e..ce6e33d39d22 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c +++ b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c @@ -2307,8 +2307,7 @@ mt7996_mcu_sta_mld_setup_tlv(struct mt7996_dev *dev, struct sk_buff *skb, if (nlinks > 1) { link_id = __ffs(links & ~BIT(msta->deflink_id)); - msta_link = mt76_dereference(msta->link[msta->deflink_id], - &dev->mt76); + msta_link = mt76_dereference(msta->link[link_id], &dev->mt76); if (!msta_link) return; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 139/480] wifi: mt76: mt7996: Fix possible OOB access in mt7996_tx() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (137 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 138/480] wifi: mt76: mt7996: Fix secondary link lookup in mt7996_mcu_sta_mld_setup_tlv() Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 140/480] wifi: mt76: mt7996: Fix valid_links bitmask in mt7996_mac_sta_{add,remove} Greg Kroah-Hartman ` (352 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Lorenzo Bianconi, Felix Fietkau, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Lorenzo Bianconi <lorenzo@kernel.org> [ Upstream commit 64cbf0d7ce9afe20666da90ec6ecaec6ba5ac64b ] Fis possible Out-Of-Boundary access in mt7996_tx routine if link_id is set to IEEE80211_LINK_UNSPECIFIED Fixes: 3ce8acb86b661 ("wifi: mt76: mt7996: Update mt7996_tx to MLO support") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250704-mt7996-mlo-fixes-v1-6-356456c73f43@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Sasha Levin <sashal@kernel.org> --- .../net/wireless/mediatek/mt76/mt7996/main.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/main.c b/drivers/net/wireless/mediatek/mt76/mt7996/main.c index 5584bea9e2a3..631ad0f9ff93 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7996/main.c +++ b/drivers/net/wireless/mediatek/mt76/mt7996/main.c @@ -1216,10 +1216,17 @@ static void mt7996_tx(struct ieee80211_hw *hw, if (vif) { struct mt7996_vif *mvif = (void *)vif->drv_priv; - struct mt76_vif_link *mlink; + struct mt76_vif_link *mlink = &mvif->deflink.mt76; - mlink = rcu_dereference(mvif->mt76.link[link_id]); - if (mlink && mlink->wcid) + if (link_id < IEEE80211_LINK_UNSPECIFIED) + mlink = rcu_dereference(mvif->mt76.link[link_id]); + + if (!mlink) { + ieee80211_free_txskb(hw, skb); + goto unlock; + } + + if (mlink->wcid) wcid = mlink->wcid; if (mvif->mt76.roc_phy && @@ -1228,7 +1235,7 @@ static void mt7996_tx(struct ieee80211_hw *hw, if (mphy->roc_link) wcid = mphy->roc_link->wcid; } else { - mphy = mt76_vif_link_phy(&mvif->deflink.mt76); + mphy = mt76_vif_link_phy(mlink); } } @@ -1237,7 +1244,7 @@ static void mt7996_tx(struct ieee80211_hw *hw, goto unlock; } - if (control->sta) { + if (control->sta && link_id < IEEE80211_LINK_UNSPECIFIED) { struct mt7996_sta *msta = (void *)control->sta->drv_priv; struct mt7996_sta_link *msta_link; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 140/480] wifi: mt76: mt7996: Fix valid_links bitmask in mt7996_mac_sta_{add,remove} 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (138 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 139/480] wifi: mt76: mt7996: Fix possible OOB access in mt7996_tx() Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 141/480] drm/amd/pm/powerplay/hwmgr/smu_helper: fix order of mask and value Greg Kroah-Hartman ` (351 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Lorenzo Bianconi, Felix Fietkau, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Lorenzo Bianconi <lorenzo@kernel.org> [ Upstream commit a59650a2270190905fdab79431140371feb35251 ] sta->valid_links bitmask can be set even for non-MLO client. Fixes: dd82a9e02c054 ("wifi: mt76: mt7996: Rely on mt7996_sta_link in sta_add/sta_remove callbacks") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250704-mt7996-mlo-fixes-v1-7-356456c73f43@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/wireless/mediatek/mt76/mt7996/main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/main.c b/drivers/net/wireless/mediatek/mt76/mt7996/main.c index 631ad0f9ff93..45ef0f309135 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7996/main.c +++ b/drivers/net/wireless/mediatek/mt76/mt7996/main.c @@ -1061,7 +1061,7 @@ mt7996_mac_sta_add(struct mt76_phy *mphy, struct ieee80211_vif *vif, struct mt7996_dev *dev = container_of(mdev, struct mt7996_dev, mt76); struct mt7996_sta *msta = (struct mt7996_sta *)sta->drv_priv; struct mt7996_vif *mvif = (struct mt7996_vif *)vif->drv_priv; - unsigned long links = sta->mlo ? sta->valid_links : BIT(0); + unsigned long links = sta->valid_links ? sta->valid_links : BIT(0); int err; mutex_lock(&mdev->mutex); @@ -1155,7 +1155,7 @@ mt7996_mac_sta_remove(struct mt76_phy *mphy, struct ieee80211_vif *vif, { struct mt76_dev *mdev = mphy->dev; struct mt7996_dev *dev = container_of(mdev, struct mt7996_dev, mt76); - unsigned long links = sta->mlo ? sta->valid_links : BIT(0); + unsigned long links = sta->valid_links ? sta->valid_links : BIT(0); mutex_lock(&mdev->mutex); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 141/480] drm/amd/pm/powerplay/hwmgr/smu_helper: fix order of mask and value 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (139 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 140/480] wifi: mt76: mt7996: Fix valid_links bitmask in mt7996_mac_sta_{add,remove} Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 142/480] wifi: ath12k: Block radio bring-up in FTM mode Greg Kroah-Hartman ` (350 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Fedor Pchelkin, Alex Deucher, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Fedor Pchelkin <pchelkin@ispras.ru> [ Upstream commit a54e4639c4ef37a0241bac7d2a77f2e6ffb57099 ] There is a small typo in phm_wait_on_indirect_register(). Swap mask and value arguments provided to phm_wait_on_register() so that they satisfy the function signature and actual usage scheme. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool. In practice this doesn't fix any issues because the only place this function is used uses the same value for the value and mask. Fixes: 3bace3591493 ("drm/amd/powerplay: add hardware manager sub-component") Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu_helper.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu_helper.c index 79a566f3564a..c305ea4ec17d 100644 --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu_helper.c +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu_helper.c @@ -149,7 +149,7 @@ int phm_wait_on_indirect_register(struct pp_hwmgr *hwmgr, } cgs_write_register(hwmgr->device, indirect_port, index); - return phm_wait_on_register(hwmgr, indirect_port + 1, mask, value); + return phm_wait_on_register(hwmgr, indirect_port + 1, value, mask); } int phm_wait_for_register_unequal(struct pp_hwmgr *hwmgr, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 142/480] wifi: ath12k: Block radio bring-up in FTM mode 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (140 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 141/480] drm/amd/pm/powerplay/hwmgr/smu_helper: fix order of mask and value Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 143/480] drm/rockchip: vop2: fail cleanly if missing a primary plane for a video-port Greg Kroah-Hartman ` (349 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Aaradhana Sahu, Vasanthakumar Thiagarajan, Jeff Johnson, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com> [ Upstream commit 80570587e418f361e7ce3f9200477f728b38c94b ] Ensure that all radios remain down when the driver operates in Factory Test Mode (FTM). Reject any userspace attempts to bring up an interface in this mode. Currently, the driver allows userspace to bring up the interface even though it operates in FTM mode, which violates FTM constraints and leads to FTM command failures. Hence, block the radio start when the driver is in FTM mode. Also, remove ath12k_ftm_mode check from ath12k_drain_tx() because FTM mode check is already handled in the caller function (ath12k_mac_op_start()). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: 3bc374cbc49e ("wifi: ath12k: add factory test mode support") Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250630031502.8902-1-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/wireless/ath/ath12k/mac.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c index ccc27863f333..029376c57496 100644 --- a/drivers/net/wireless/ath/ath12k/mac.c +++ b/drivers/net/wireless/ath/ath12k/mac.c @@ -7689,14 +7689,9 @@ static int ath12k_mac_start(struct ath12k *ar) static void ath12k_drain_tx(struct ath12k_hw *ah) { - struct ath12k *ar = ah->radio; + struct ath12k *ar; int i; - if (ath12k_ftm_mode) { - ath12k_err(ar->ab, "fail to start mac operations in ftm mode\n"); - return; - } - lockdep_assert_wiphy(ah->hw->wiphy); for_each_ar(ah, ar, i) @@ -7709,6 +7704,9 @@ static int ath12k_mac_op_start(struct ieee80211_hw *hw) struct ath12k *ar; int ret, i; + if (ath12k_ftm_mode) + return -EPERM; + lockdep_assert_wiphy(hw->wiphy); ath12k_drain_tx(ah); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 143/480] drm/rockchip: vop2: fail cleanly if missing a primary plane for a video-port 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (141 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 142/480] wifi: ath12k: Block radio bring-up in FTM mode Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 144/480] drm/rockchip: vop2: Fix the update of LAYER/PORT select registers when there are multi display output on rk3588/rk3568 Greg Kroah-Hartman ` (348 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Andy Yan, Heiko Stuebner, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Heiko Stuebner <heiko@sntech.de> [ Upstream commit f9f68bf1d0efeadb6c427c9dbb30f307a7def19b ] Each window of a vop2 is usable by a specific set of video ports, so while binding the vop2, we look through the list of available windows trying to find one designated as primary-plane and usable by that specific port. The code later wants to use drm_crtc_init_with_planes with that found primary plane, but nothing has checked so far if a primary plane was actually found. For whatever reason, the rk3576 vp2 does not have a usable primary window (if vp0 is also in use) which brought the issue to light and ended in a null-pointer dereference further down. As we expect a primary-plane to exist for a video-port, add a check at the end of the window-iteration and fail probing if none was found. Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver") Reviewed-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250610212748.1062375-1-heiko@sntech.de Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c index d0f5fea15e21..6b37ce3ee60b 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c @@ -2422,6 +2422,10 @@ static int vop2_create_crtcs(struct vop2 *vop2) break; } } + + if (!vp->primary_plane) + return dev_err_probe(drm->dev, -ENOENT, + "no primary plane for vp %d\n", i); } /* Register all unused window as overlay plane */ -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 144/480] drm/rockchip: vop2: Fix the update of LAYER/PORT select registers when there are multi display output on rk3588/rk3568 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (142 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 143/480] drm/rockchip: vop2: fail cleanly if missing a primary plane for a video-port Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 145/480] sched/psi: Optimize psi_group_change() cpu_clock() usage Greg Kroah-Hartman ` (347 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Andy Yan, Heiko Stuebner, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Andy Yan <andy.yan@rock-chips.com> [ Upstream commit 3e89a8c6835476aa782da80585dee9ddae651eea ] The all video ports of rk3568/rk3588 share the same OVL_LAYER_SEL and OVL_PORT_SEL registers, and the configuration of these two registers can be set to take effect when the vsync signal arrives at a certain Video Port. If two threads for two display output choose to update these two registers simultaneously to meet their own plane adjustment requirements(change plane zpos or switch plane from one crtc to another), then no matter which Video Port'svsync signal we choose to follow for these two registers, the display output of the other Video Port will be abnormal. This is because the configuration of this Video Port does not take effect at the right time (its configuration should take effect when its VSYNC signal arrives). In order to solve this problem, when performing plane migration or change the zpos of planes, there are two things to be observed and followed: 1. When a plane is migrated from one VP to another, the configuration of the layer can only take effect after the Port mux configuration is enabled. 2. When change the zpos of planes, we must ensure that the change for the previous VP takes effect before we proceed to change the next VP. Otherwise, the new configuration might overwrite the previous one for the previous VP, or it could lead to the configuration of the previous VP being take effect along with the VSYNC of the new VP. This issue only occurs in scenarios where multi-display output is enabled. Fixes: c5996e4ab109 ("drm/rockchip: vop2: Make overlay layer select register configuration take effect by vsync") Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250421102156.424480-1-andyshrk@163.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 25 ++---- drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 33 ++++++++ drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 89 ++++++++++++++++++-- 3 files changed, 122 insertions(+), 25 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c index 6b37ce3ee60b..186f6452a7d3 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c @@ -146,25 +146,6 @@ static void vop2_unlock(struct vop2 *vop2) mutex_unlock(&vop2->vop2_lock); } -/* - * Note: - * The write mask function is documented but missing on rk3566/8, writes - * to these bits have no effect. For newer soc(rk3588 and following) the - * write mask is needed for register writes. - * - * GLB_CFG_DONE_EN has no write mask bit. - * - */ -static void vop2_cfg_done(struct vop2_video_port *vp) -{ - struct vop2 *vop2 = vp->vop2; - u32 val = RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN; - - val |= BIT(vp->id) | (BIT(vp->id) << 16); - - regmap_set_bits(vop2->map, RK3568_REG_CFG_DONE, val); -} - static void vop2_win_disable(struct vop2_win *win) { vop2_win_write(win, VOP2_WIN_ENABLE, 0); @@ -854,6 +835,11 @@ static void vop2_enable(struct vop2 *vop2) if (vop2->version == VOP_VERSION_RK3588) rk3588_vop2_power_domain_enable_all(vop2); + if (vop2->version <= VOP_VERSION_RK3588) { + vop2->old_layer_sel = vop2_readl(vop2, RK3568_OVL_LAYER_SEL); + vop2->old_port_sel = vop2_readl(vop2, RK3568_OVL_PORT_SEL); + } + vop2_writel(vop2, RK3568_REG_CFG_DONE, RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN); /* @@ -2728,6 +2714,7 @@ static int vop2_bind(struct device *dev, struct device *master, void *data) return dev_err_probe(drm->dev, vop2->irq, "cannot find irq for vop2\n"); mutex_init(&vop2->vop2_lock); + mutex_init(&vop2->ovl_lock); ret = devm_request_irq(dev, vop2->irq, vop2_isr, IRQF_SHARED, dev_name(dev), vop2); if (ret) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h index fc3ecb9fcd95..fa5c56f16047 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h @@ -334,6 +334,19 @@ struct vop2 { /* optional internal rgb encoder */ struct rockchip_rgb *rgb; + /* + * Used to record layer selection configuration on rk356x/rk3588 + * as register RK3568_OVL_LAYER_SEL and RK3568_OVL_PORT_SEL are + * shared for all the Video Ports. + */ + u32 old_layer_sel; + u32 old_port_sel; + /* + * Ensure that the updates to these two registers(RKK3568_OVL_LAYER_SEL/RK3568_OVL_PORT_SEL) + * take effect in sequence. + */ + struct mutex ovl_lock; + /* must be put at the end of the struct */ struct vop2_win win[]; }; @@ -727,6 +740,7 @@ enum dst_factor_mode { #define RK3588_OVL_PORT_SEL__CLUSTER2 GENMASK(21, 20) #define RK3568_OVL_PORT_SEL__CLUSTER1 GENMASK(19, 18) #define RK3568_OVL_PORT_SEL__CLUSTER0 GENMASK(17, 16) +#define RK3588_OVL_PORT_SET__PORT3_MUX GENMASK(15, 12) #define RK3568_OVL_PORT_SET__PORT2_MUX GENMASK(11, 8) #define RK3568_OVL_PORT_SET__PORT1_MUX GENMASK(7, 4) #define RK3568_OVL_PORT_SET__PORT0_MUX GENMASK(3, 0) @@ -831,4 +845,23 @@ static inline struct vop2_win *to_vop2_win(struct drm_plane *p) return container_of(p, struct vop2_win, base); } +/* + * Note: + * The write mask function is documented but missing on rk3566/8, writes + * to these bits have no effect. For newer soc(rk3588 and following) the + * write mask is needed for register writes. + * + * GLB_CFG_DONE_EN has no write mask bit. + * + */ +static inline void vop2_cfg_done(struct vop2_video_port *vp) +{ + struct vop2 *vop2 = vp->vop2; + u32 val = RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN; + + val |= BIT(vp->id) | (BIT(vp->id) << 16); + + regmap_set_bits(vop2->map, RK3568_REG_CFG_DONE, val); +} + #endif /* _ROCKCHIP_DRM_VOP2_H */ diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c index 32c4ed685739..45c5e3987813 100644 --- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c +++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c @@ -2052,12 +2052,55 @@ static void vop2_setup_alpha(struct vop2_video_port *vp) } } +static u32 rk3568_vop2_read_port_mux(struct vop2 *vop2) +{ + return vop2_readl(vop2, RK3568_OVL_PORT_SEL); +} + +static void rk3568_vop2_wait_for_port_mux_done(struct vop2 *vop2) +{ + u32 port_mux_sel; + int ret; + + /* + * Spin until the previous port_mux figuration is done. + */ + ret = readx_poll_timeout_atomic(rk3568_vop2_read_port_mux, vop2, port_mux_sel, + port_mux_sel == vop2->old_port_sel, 0, 50 * 1000); + if (ret) + DRM_DEV_ERROR(vop2->dev, "wait port_mux done timeout: 0x%x--0x%x\n", + port_mux_sel, vop2->old_port_sel); +} + +static u32 rk3568_vop2_read_layer_cfg(struct vop2 *vop2) +{ + return vop2_readl(vop2, RK3568_OVL_LAYER_SEL); +} + +static void rk3568_vop2_wait_for_layer_cfg_done(struct vop2 *vop2, u32 cfg) +{ + u32 atv_layer_cfg; + int ret; + + /* + * Spin until the previous layer configuration is done. + */ + ret = readx_poll_timeout_atomic(rk3568_vop2_read_layer_cfg, vop2, atv_layer_cfg, + atv_layer_cfg == cfg, 0, 50 * 1000); + if (ret) + DRM_DEV_ERROR(vop2->dev, "wait layer cfg done timeout: 0x%x--0x%x\n", + atv_layer_cfg, cfg); +} + static void rk3568_vop2_setup_layer_mixer(struct vop2_video_port *vp) { struct vop2 *vop2 = vp->vop2; struct drm_plane *plane; u32 layer_sel = 0; u32 port_sel; + u32 old_layer_sel = 0; + u32 atv_layer_sel = 0; + u32 old_port_sel = 0; u8 layer_id; u8 old_layer_id; u8 layer_sel_id; @@ -2069,19 +2112,18 @@ static void rk3568_vop2_setup_layer_mixer(struct vop2_video_port *vp) struct vop2_video_port *vp2 = &vop2->vps[2]; struct rockchip_crtc_state *vcstate = to_rockchip_crtc_state(vp->crtc.state); + mutex_lock(&vop2->ovl_lock); ovl_ctrl = vop2_readl(vop2, RK3568_OVL_CTRL); ovl_ctrl &= ~RK3568_OVL_CTRL__LAYERSEL_REGDONE_IMD; ovl_ctrl &= ~RK3568_OVL_CTRL__LAYERSEL_REGDONE_SEL; - ovl_ctrl |= FIELD_PREP(RK3568_OVL_CTRL__LAYERSEL_REGDONE_SEL, vp->id); if (vcstate->yuv_overlay) ovl_ctrl |= RK3568_OVL_CTRL__YUV_MODE(vp->id); else ovl_ctrl &= ~RK3568_OVL_CTRL__YUV_MODE(vp->id); - vop2_writel(vop2, RK3568_OVL_CTRL, ovl_ctrl); - - port_sel = vop2_readl(vop2, RK3568_OVL_PORT_SEL); + old_port_sel = vop2->old_port_sel; + port_sel = old_port_sel; port_sel &= RK3568_OVL_PORT_SEL__SEL_PORT; if (vp0->nlayers) @@ -2102,7 +2144,13 @@ static void rk3568_vop2_setup_layer_mixer(struct vop2_video_port *vp) else port_sel |= FIELD_PREP(RK3568_OVL_PORT_SET__PORT2_MUX, 8); - layer_sel = vop2_readl(vop2, RK3568_OVL_LAYER_SEL); + /* Fixed value for rk3588 */ + if (vop2->version == VOP_VERSION_RK3588) + port_sel |= FIELD_PREP(RK3588_OVL_PORT_SET__PORT3_MUX, 7); + + atv_layer_sel = vop2_readl(vop2, RK3568_OVL_LAYER_SEL); + old_layer_sel = vop2->old_layer_sel; + layer_sel = old_layer_sel; ofs = 0; for (i = 0; i < vp->id; i++) @@ -2186,8 +2234,37 @@ static void rk3568_vop2_setup_layer_mixer(struct vop2_video_port *vp) old_win->data->layer_sel_id[vp->id]); } + vop2->old_layer_sel = layer_sel; + vop2->old_port_sel = port_sel; + /* + * As the RK3568_OVL_LAYER_SEL and RK3568_OVL_PORT_SEL are shared by all Video Ports, + * and the configuration take effect by one Video Port's vsync. + * When performing layer migration or change the zpos of layers, there are two things + * to be observed and followed: + * 1. When a layer is migrated from one VP to another, the configuration of the layer + * can only take effect after the Port mux configuration is enabled. + * + * 2. When we change the zpos of layers, we must ensure that the change for the previous + * VP takes effect before we proceed to change the next VP. Otherwise, the new + * configuration might overwrite the previous one for the previous VP, or it could + * lead to the configuration of the previous VP being take effect along with the VSYNC + * of the new VP. + */ + if (layer_sel != old_layer_sel || port_sel != old_port_sel) + ovl_ctrl |= FIELD_PREP(RK3568_OVL_CTRL__LAYERSEL_REGDONE_SEL, vp->id); + vop2_writel(vop2, RK3568_OVL_CTRL, ovl_ctrl); + + if (port_sel != old_port_sel) { + vop2_writel(vop2, RK3568_OVL_PORT_SEL, port_sel); + vop2_cfg_done(vp); + rk3568_vop2_wait_for_port_mux_done(vop2); + } + + if (layer_sel != old_layer_sel && atv_layer_sel != old_layer_sel) + rk3568_vop2_wait_for_layer_cfg_done(vop2, vop2->old_layer_sel); + vop2_writel(vop2, RK3568_OVL_LAYER_SEL, layer_sel); - vop2_writel(vop2, RK3568_OVL_PORT_SEL, port_sel); + mutex_unlock(&vop2->ovl_lock); } static void rk3568_vop2_setup_dly_for_windows(struct vop2_video_port *vp) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 145/480] sched/psi: Optimize psi_group_change() cpu_clock() usage 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (143 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 144/480] drm/rockchip: vop2: Fix the update of LAYER/PORT select registers when there are multi display output on rk3588/rk3568 Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 146/480] sched/deadline: Less agressive dl_server handling Greg Kroah-Hartman ` (346 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Dietmar Eggemann, Peter Zijlstra (Intel), Johannes Weiner, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Peter Zijlstra <peterz@infradead.org> [ Upstream commit 570c8efd5eb79c3725ba439ce105ed1bedc5acd9 ] Dietmar reported that commit 3840cbe24cf0 ("sched: psi: fix bogus pressure spikes from aggregation race") caused a regression for him on a high context switch rate benchmark (schbench) due to the now repeating cpu_clock() calls. In particular the problem is that get_recent_times() will extrapolate the current state to 'now'. But if an update uses a timestamp from before the start of the update, it is possible to get two reads with inconsistent results. It is effectively back-dating an update. (note that this all hard-relies on the clock being synchronized across CPUs -- if this is not the case, all bets are off). Combine this problem with the fact that there are per-group-per-cpu seqcounts, the commit in question pushed the clock read into the group iteration, causing tree-depth cpu_clock() calls. On architectures where cpu_clock() has appreciable overhead, this hurts. Instead move to a per-cpu seqcount, which allows us to have a single clock read for all group updates, increasing internal consistency and lowering update overhead. This comes at the cost of a longer update side (proportional to the tree depth) which can cause the read side to retry more often. Fixes: 3840cbe24cf0 ("sched: psi: fix bogus pressure spikes from aggregation race") Reported-by: Dietmar Eggemann <dietmar.eggemann@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com>, Link: https://lkml.kernel.org/20250522084844.GC31726@noisy.programming.kicks-ass.net Signed-off-by: Sasha Levin <sashal@kernel.org> --- include/linux/psi_types.h | 6 +- kernel/sched/psi.c | 121 +++++++++++++++++++++----------------- 2 files changed, 68 insertions(+), 59 deletions(-) diff --git a/include/linux/psi_types.h b/include/linux/psi_types.h index f1fd3a8044e0..dd10c22299ab 100644 --- a/include/linux/psi_types.h +++ b/include/linux/psi_types.h @@ -84,11 +84,9 @@ enum psi_aggregators { struct psi_group_cpu { /* 1st cacheline updated by the scheduler */ - /* Aggregator needs to know of concurrent changes */ - seqcount_t seq ____cacheline_aligned_in_smp; - /* States of the tasks belonging to this group */ - unsigned int tasks[NR_PSI_TASK_COUNTS]; + unsigned int tasks[NR_PSI_TASK_COUNTS] + ____cacheline_aligned_in_smp; /* Aggregate pressure state derived from the tasks */ u32 state_mask; diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c index 1396674fa722..c62f4316a2b9 100644 --- a/kernel/sched/psi.c +++ b/kernel/sched/psi.c @@ -172,6 +172,28 @@ struct psi_group psi_system = { .pcpu = &system_group_pcpu, }; +static DEFINE_PER_CPU(seqcount_t, psi_seq); + +static inline void psi_write_begin(int cpu) +{ + write_seqcount_begin(per_cpu_ptr(&psi_seq, cpu)); +} + +static inline void psi_write_end(int cpu) +{ + write_seqcount_end(per_cpu_ptr(&psi_seq, cpu)); +} + +static inline u32 psi_read_begin(int cpu) +{ + return read_seqcount_begin(per_cpu_ptr(&psi_seq, cpu)); +} + +static inline bool psi_read_retry(int cpu, u32 seq) +{ + return read_seqcount_retry(per_cpu_ptr(&psi_seq, cpu), seq); +} + static void psi_avgs_work(struct work_struct *work); static void poll_timer_fn(struct timer_list *t); @@ -182,7 +204,7 @@ static void group_init(struct psi_group *group) group->enabled = true; for_each_possible_cpu(cpu) - seqcount_init(&per_cpu_ptr(group->pcpu, cpu)->seq); + seqcount_init(per_cpu_ptr(&psi_seq, cpu)); group->avg_last_update = sched_clock(); group->avg_next_update = group->avg_last_update + psi_period; mutex_init(&group->avgs_lock); @@ -262,14 +284,14 @@ static void get_recent_times(struct psi_group *group, int cpu, /* Snapshot a coherent view of the CPU state */ do { - seq = read_seqcount_begin(&groupc->seq); + seq = psi_read_begin(cpu); now = cpu_clock(cpu); memcpy(times, groupc->times, sizeof(groupc->times)); state_mask = groupc->state_mask; state_start = groupc->state_start; if (cpu == current_cpu) memcpy(tasks, groupc->tasks, sizeof(groupc->tasks)); - } while (read_seqcount_retry(&groupc->seq, seq)); + } while (psi_read_retry(cpu, seq)); /* Calculate state time deltas against the previous snapshot */ for (s = 0; s < NR_PSI_STATES; s++) { @@ -768,30 +790,20 @@ static void record_times(struct psi_group_cpu *groupc, u64 now) groupc->times[PSI_NONIDLE] += delta; } +#define for_each_group(iter, group) \ + for (typeof(group) iter = group; iter; iter = iter->parent) + static void psi_group_change(struct psi_group *group, int cpu, unsigned int clear, unsigned int set, - bool wake_clock) + u64 now, bool wake_clock) { struct psi_group_cpu *groupc; unsigned int t, m; u32 state_mask; - u64 now; lockdep_assert_rq_held(cpu_rq(cpu)); groupc = per_cpu_ptr(group->pcpu, cpu); - /* - * First we update the task counts according to the state - * change requested through the @clear and @set bits. - * - * Then if the cgroup PSI stats accounting enabled, we - * assess the aggregate resource states this CPU's tasks - * have been in since the last change, and account any - * SOME and FULL time these may have resulted in. - */ - write_seqcount_begin(&groupc->seq); - now = cpu_clock(cpu); - /* * Start with TSK_ONCPU, which doesn't have a corresponding * task count - it's just a boolean flag directly encoded in @@ -843,7 +855,6 @@ static void psi_group_change(struct psi_group *group, int cpu, groupc->state_mask = state_mask; - write_seqcount_end(&groupc->seq); return; } @@ -864,8 +875,6 @@ static void psi_group_change(struct psi_group *group, int cpu, groupc->state_mask = state_mask; - write_seqcount_end(&groupc->seq); - if (state_mask & group->rtpoll_states) psi_schedule_rtpoll_work(group, 1, false); @@ -900,24 +909,29 @@ static void psi_flags_change(struct task_struct *task, int clear, int set) void psi_task_change(struct task_struct *task, int clear, int set) { int cpu = task_cpu(task); - struct psi_group *group; + u64 now; if (!task->pid) return; psi_flags_change(task, clear, set); - group = task_psi_group(task); - do { - psi_group_change(group, cpu, clear, set, true); - } while ((group = group->parent)); + psi_write_begin(cpu); + now = cpu_clock(cpu); + for_each_group(group, task_psi_group(task)) + psi_group_change(group, cpu, clear, set, now, true); + psi_write_end(cpu); } void psi_task_switch(struct task_struct *prev, struct task_struct *next, bool sleep) { - struct psi_group *group, *common = NULL; + struct psi_group *common = NULL; int cpu = task_cpu(prev); + u64 now; + + psi_write_begin(cpu); + now = cpu_clock(cpu); if (next->pid) { psi_flags_change(next, 0, TSK_ONCPU); @@ -926,16 +940,15 @@ void psi_task_switch(struct task_struct *prev, struct task_struct *next, * ancestors with @prev, those will already have @prev's * TSK_ONCPU bit set, and we can stop the iteration there. */ - group = task_psi_group(next); - do { - if (per_cpu_ptr(group->pcpu, cpu)->state_mask & - PSI_ONCPU) { + for_each_group(group, task_psi_group(next)) { + struct psi_group_cpu *groupc = per_cpu_ptr(group->pcpu, cpu); + + if (groupc->state_mask & PSI_ONCPU) { common = group; break; } - - psi_group_change(group, cpu, 0, TSK_ONCPU, true); - } while ((group = group->parent)); + psi_group_change(group, cpu, 0, TSK_ONCPU, now, true); + } } if (prev->pid) { @@ -968,12 +981,11 @@ void psi_task_switch(struct task_struct *prev, struct task_struct *next, psi_flags_change(prev, clear, set); - group = task_psi_group(prev); - do { + for_each_group(group, task_psi_group(prev)) { if (group == common) break; - psi_group_change(group, cpu, clear, set, wake_clock); - } while ((group = group->parent)); + psi_group_change(group, cpu, clear, set, now, wake_clock); + } /* * TSK_ONCPU is handled up to the common ancestor. If there are @@ -983,20 +995,21 @@ void psi_task_switch(struct task_struct *prev, struct task_struct *next, */ if ((prev->psi_flags ^ next->psi_flags) & ~TSK_ONCPU) { clear &= ~TSK_ONCPU; - for (; group; group = group->parent) - psi_group_change(group, cpu, clear, set, wake_clock); + for_each_group(group, common) + psi_group_change(group, cpu, clear, set, now, wake_clock); } } + psi_write_end(cpu); } #ifdef CONFIG_IRQ_TIME_ACCOUNTING void psi_account_irqtime(struct rq *rq, struct task_struct *curr, struct task_struct *prev) { int cpu = task_cpu(curr); - struct psi_group *group; struct psi_group_cpu *groupc; s64 delta; u64 irq; + u64 now; if (static_branch_likely(&psi_disabled) || !irqtime_enabled()) return; @@ -1005,8 +1018,7 @@ void psi_account_irqtime(struct rq *rq, struct task_struct *curr, struct task_st return; lockdep_assert_rq_held(rq); - group = task_psi_group(curr); - if (prev && task_psi_group(prev) == group) + if (prev && task_psi_group(prev) == task_psi_group(curr)) return; irq = irq_time_read(cpu); @@ -1015,25 +1027,22 @@ void psi_account_irqtime(struct rq *rq, struct task_struct *curr, struct task_st return; rq->psi_irq_time = irq; - do { - u64 now; + psi_write_begin(cpu); + now = cpu_clock(cpu); + for_each_group(group, task_psi_group(curr)) { if (!group->enabled) continue; groupc = per_cpu_ptr(group->pcpu, cpu); - write_seqcount_begin(&groupc->seq); - now = cpu_clock(cpu); - record_times(groupc, now); groupc->times[PSI_IRQ_FULL] += delta; - write_seqcount_end(&groupc->seq); - if (group->rtpoll_states & (1 << PSI_IRQ_FULL)) psi_schedule_rtpoll_work(group, 1, false); - } while ((group = group->parent)); + } + psi_write_end(cpu); } #endif @@ -1221,12 +1230,14 @@ void psi_cgroup_restart(struct psi_group *group) return; for_each_possible_cpu(cpu) { - struct rq *rq = cpu_rq(cpu); - struct rq_flags rf; + u64 now; - rq_lock_irq(rq, &rf); - psi_group_change(group, cpu, 0, 0, true); - rq_unlock_irq(rq, &rf); + guard(rq_lock_irq)(cpu_rq(cpu)); + + psi_write_begin(cpu); + now = cpu_clock(cpu); + psi_group_change(group, cpu, 0, 0, now, true); + psi_write_end(cpu); } } #endif /* CONFIG_CGROUPS */ -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 146/480] sched/deadline: Less agressive dl_server handling 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (144 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 145/480] sched/psi: Optimize psi_group_change() cpu_clock() usage Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 147/480] fbcon: Fix outdated registered_fb reference in comment Greg Kroah-Hartman ` (345 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Chris Mason, Peter Zijlstra (Intel), Juri Lelli, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Peter Zijlstra <peterz@infradead.org> [ Upstream commit cccb45d7c4295bbfeba616582d0249f2d21e6df5 ] Chris reported that commit 5f6bd380c7bd ("sched/rt: Remove default bandwidth control") caused a significant dip in his favourite benchmark of the day. Simply disabling dl_server cured things. His workload hammers the 0->1, 1->0 transitions, and the dl_server_{start,stop}() overhead kills it -- fairly obviously a bad idea in hind sight and all that. Change things around to only disable the dl_server when there has not been a fair task around for a whole period. Since the default period is 1 second, this ensures the benchmark never trips this, overhead gone. Fixes: 557a6bfc662c ("sched/fair: Add trivial fair server") Reported-by: Chris Mason <clm@meta.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Juri Lelli <juri.lelli@redhat.com> Acked-by: Juri Lelli <juri.lelli@redhat.com> Link: https://lkml.kernel.org/r/20250702121158.465086194@infradead.org Signed-off-by: Sasha Levin <sashal@kernel.org> --- include/linux/sched.h | 1 + kernel/sched/deadline.c | 25 ++++++++++++++++++++++--- kernel/sched/fair.c | 9 --------- 3 files changed, 23 insertions(+), 12 deletions(-) diff --git a/include/linux/sched.h b/include/linux/sched.h index f96ac1982893..1f92572b20c0 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -702,6 +702,7 @@ struct sched_dl_entity { unsigned int dl_defer : 1; unsigned int dl_defer_armed : 1; unsigned int dl_defer_running : 1; + unsigned int dl_server_idle : 1; /* * Bandwidth enforcement timer. Each -deadline task has its diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index 89019a140826..094134c9b135 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -1215,6 +1215,8 @@ static void __push_dl_task(struct rq *rq, struct rq_flags *rf) /* a defer timer will not be reset if the runtime consumed was < dl_server_min_res */ static const u64 dl_server_min_res = 1 * NSEC_PER_MSEC; +static bool dl_server_stopped(struct sched_dl_entity *dl_se); + static enum hrtimer_restart dl_server_timer(struct hrtimer *timer, struct sched_dl_entity *dl_se) { struct rq *rq = rq_of_dl_se(dl_se); @@ -1234,6 +1236,7 @@ static enum hrtimer_restart dl_server_timer(struct hrtimer *timer, struct sched_ if (!dl_se->server_has_tasks(dl_se)) { replenish_dl_entity(dl_se); + dl_server_stopped(dl_se); return HRTIMER_NORESTART; } @@ -1639,8 +1642,10 @@ void dl_server_update_idle_time(struct rq *rq, struct task_struct *p) void dl_server_update(struct sched_dl_entity *dl_se, s64 delta_exec) { /* 0 runtime = fair server disabled */ - if (dl_se->dl_runtime) + if (dl_se->dl_runtime) { + dl_se->dl_server_idle = 0; update_curr_dl_se(dl_se->rq, dl_se, delta_exec); + } } void dl_server_start(struct sched_dl_entity *dl_se) @@ -1663,7 +1668,7 @@ void dl_server_start(struct sched_dl_entity *dl_se) setup_new_dl_entity(dl_se); } - if (!dl_se->dl_runtime) + if (!dl_se->dl_runtime || dl_se->dl_server_active) return; dl_se->dl_server_active = 1; @@ -1684,6 +1689,20 @@ void dl_server_stop(struct sched_dl_entity *dl_se) dl_se->dl_server_active = 0; } +static bool dl_server_stopped(struct sched_dl_entity *dl_se) +{ + if (!dl_se->dl_server_active) + return false; + + if (dl_se->dl_server_idle) { + dl_server_stop(dl_se); + return true; + } + + dl_se->dl_server_idle = 1; + return false; +} + void dl_server_init(struct sched_dl_entity *dl_se, struct rq *rq, dl_server_has_tasks_f has_tasks, dl_server_pick_f pick_task) @@ -2435,7 +2454,7 @@ static struct task_struct *__pick_task_dl(struct rq *rq) if (dl_server(dl_se)) { p = dl_se->server_pick_task(dl_se); if (!p) { - if (dl_server_active(dl_se)) { + if (!dl_server_stopped(dl_se)) { dl_se->dl_yielded = 1; update_curr_dl_se(rq, dl_se, 0); } diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 138d9f4658d5..9746eff2eff7 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -5886,7 +5886,6 @@ static bool throttle_cfs_rq(struct cfs_rq *cfs_rq) struct cfs_bandwidth *cfs_b = tg_cfs_bandwidth(cfs_rq->tg); struct sched_entity *se; long queued_delta, runnable_delta, idle_delta, dequeue = 1; - long rq_h_nr_queued = rq->cfs.h_nr_queued; raw_spin_lock(&cfs_b->lock); /* This will start the period timer if necessary */ @@ -5970,10 +5969,6 @@ static bool throttle_cfs_rq(struct cfs_rq *cfs_rq) /* At this point se is NULL and we are at root level*/ sub_nr_running(rq, queued_delta); - - /* Stop the fair server if throttling resulted in no runnable tasks */ - if (rq_h_nr_queued && !rq->cfs.h_nr_queued) - dl_server_stop(&rq->fair_server); done: /* * Note: distribution will already see us throttled via the @@ -7067,7 +7062,6 @@ static void set_next_buddy(struct sched_entity *se); static int dequeue_entities(struct rq *rq, struct sched_entity *se, int flags) { bool was_sched_idle = sched_idle_rq(rq); - int rq_h_nr_queued = rq->cfs.h_nr_queued; bool task_sleep = flags & DEQUEUE_SLEEP; bool task_delayed = flags & DEQUEUE_DELAYED; struct task_struct *p = NULL; @@ -7151,9 +7145,6 @@ static int dequeue_entities(struct rq *rq, struct sched_entity *se, int flags) sub_nr_running(rq, h_nr_queued); - if (rq_h_nr_queued && !rq->cfs.h_nr_queued) - dl_server_stop(&rq->fair_server); - /* balance early to pull high priority tasks */ if (unlikely(!was_sched_idle && sched_idle_rq(rq))) rq->next_balance = jiffies; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 147/480] fbcon: Fix outdated registered_fb reference in comment 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (145 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 146/480] sched/deadline: Less agressive dl_server handling Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 148/480] netfilter: nf_tables: Drop dead code from fill_*_info routines Greg Kroah-Hartman ` (344 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Shixiong Ou, Simona Vetter, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Shixiong Ou <oushixiong@kylinos.cn> [ Upstream commit 0f168e7be696a17487e83d1d47e5a408a181080f ] The variable was renamed to fbcon_registered_fb, but this comment was not updated along with the change. Correct it to avoid confusion. Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Fixes: efc3acbc105a ("fbcon: Maintain a private array of fb_info") [sima: Add Fixes: line.] Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20250709103438.572309-1-oushixiong1025@163.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/video/fbdev/core/fbcon.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index 2df48037688d..2b2d36c021ba 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -952,13 +952,13 @@ static const char *fbcon_startup(void) int rows, cols; /* - * If num_registered_fb is zero, this is a call for the dummy part. + * If fbcon_num_registered_fb is zero, this is a call for the dummy part. * The frame buffer devices weren't initialized yet. */ if (!fbcon_num_registered_fb || info_idx == -1) return display_desc; /* - * Instead of blindly using registered_fb[0], we use info_idx, set by + * Instead of blindly using fbcon_registered_fb[0], we use info_idx, set by * fbcon_fb_registered(); */ info = fbcon_registered_fb[info_idx]; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 148/480] netfilter: nf_tables: Drop dead code from fill_*_info routines 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (146 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 147/480] fbcon: Fix outdated registered_fb reference in comment Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 149/480] netfilter: nf_tables: adjust lockdep assertions handling Greg Kroah-Hartman ` (343 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Phil Sutter, Pablo Neira Ayuso, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Phil Sutter <phil@nwl.cc> [ Upstream commit 8080357a8c6cf4905bbd8969412c19d34be3395e ] This practically reverts commit 28339b21a365 ("netfilter: nf_tables: do not send complete notification of deletions"): The feature was never effective, due to prior modification of 'event' variable the conditional early return never happened. User space also relies upon the current behaviour, so better reintroduce the shortened deletion notifications once it is fixed. Fixes: 28339b21a365 ("netfilter: nf_tables: do not send complete notification of deletions") Signed-off-by: Phil Sutter <phil@nwl.cc> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/netfilter/nf_tables_api.c | 25 ------------------------- 1 file changed, 25 deletions(-) diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c index a133e1c175ce..3eb000ae2f27 100644 --- a/net/netfilter/nf_tables_api.c +++ b/net/netfilter/nf_tables_api.c @@ -1130,11 +1130,6 @@ static int nf_tables_fill_table_info(struct sk_buff *skb, struct net *net, NFTA_TABLE_PAD)) goto nla_put_failure; - if (event == NFT_MSG_DELTABLE) { - nlmsg_end(skb, nlh); - return 0; - } - if (nla_put_be32(skb, NFTA_TABLE_FLAGS, htonl(table->flags & NFT_TABLE_F_MASK))) goto nla_put_failure; @@ -1993,11 +1988,6 @@ static int nf_tables_fill_chain_info(struct sk_buff *skb, struct net *net, NFTA_CHAIN_PAD)) goto nla_put_failure; - if (event == NFT_MSG_DELCHAIN && !hook_list) { - nlmsg_end(skb, nlh); - return 0; - } - if (nft_is_base_chain(chain)) { const struct nft_base_chain *basechain = nft_base_chain(chain); struct nft_stats __percpu *stats; @@ -4788,11 +4778,6 @@ static int nf_tables_fill_set(struct sk_buff *skb, const struct nft_ctx *ctx, NFTA_SET_PAD)) goto nla_put_failure; - if (event == NFT_MSG_DELSET) { - nlmsg_end(skb, nlh); - return 0; - } - if (set->flags != 0) if (nla_put_be32(skb, NFTA_SET_FLAGS, htonl(set->flags))) goto nla_put_failure; @@ -8276,11 +8261,6 @@ static int nf_tables_fill_obj_info(struct sk_buff *skb, struct net *net, NFTA_OBJ_PAD)) goto nla_put_failure; - if (event == NFT_MSG_DELOBJ) { - nlmsg_end(skb, nlh); - return 0; - } - if (nla_put_be32(skb, NFTA_OBJ_TYPE, htonl(obj->ops->type->type)) || nla_put_be32(skb, NFTA_OBJ_USE, htonl(obj->use)) || nft_object_dump(skb, NFTA_OBJ_DATA, obj, reset)) @@ -9298,11 +9278,6 @@ static int nf_tables_fill_flowtable_info(struct sk_buff *skb, struct net *net, NFTA_FLOWTABLE_PAD)) goto nla_put_failure; - if (event == NFT_MSG_DELFLOWTABLE && !hook_list) { - nlmsg_end(skb, nlh); - return 0; - } - if (nla_put_be32(skb, NFTA_FLOWTABLE_USE, htonl(flowtable->use)) || nla_put_be32(skb, NFTA_FLOWTABLE_FLAGS, htonl(flowtable->data.flags))) goto nla_put_failure; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 149/480] netfilter: nf_tables: adjust lockdep assertions handling 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (147 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 148/480] netfilter: nf_tables: Drop dead code from fill_*_info routines Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 150/480] arch: powerpc: defconfig: Drop obsolete CONFIG_NET_CLS_TCINDEX Greg Kroah-Hartman ` (342 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Alexey Khoroshilov, Fedor Pchelkin, Florian Westphal, Pablo Neira Ayuso, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Fedor Pchelkin <pchelkin@ispras.ru> [ Upstream commit 8df1b40de76979bb8e975201d07b71103d5de820 ] It's needed to check the return value of lockdep_commit_lock_is_held(), otherwise there's no point in this assertion as it doesn't print any debug information on itself. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool. Fixes: b04df3da1b5c ("netfilter: nf_tables: do not defer rule destruction via call_rcu") Reported-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru> Acked-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/netfilter/nf_tables_api.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c index 3eb000ae2f27..843f2c3ce73c 100644 --- a/net/netfilter/nf_tables_api.c +++ b/net/netfilter/nf_tables_api.c @@ -3981,7 +3981,7 @@ void nf_tables_rule_destroy(const struct nft_ctx *ctx, struct nft_rule *rule) /* can only be used if rule is no longer visible to dumps */ static void nf_tables_rule_release(const struct nft_ctx *ctx, struct nft_rule *rule) { - lockdep_commit_lock_is_held(ctx->net); + WARN_ON_ONCE(!lockdep_commit_lock_is_held(ctx->net)); nft_rule_expr_deactivate(ctx, rule, NFT_TRANS_RELEASE); nf_tables_rule_destroy(ctx, rule); @@ -5770,7 +5770,7 @@ void nf_tables_deactivate_set(const struct nft_ctx *ctx, struct nft_set *set, struct nft_set_binding *binding, enum nft_trans_phase phase) { - lockdep_commit_lock_is_held(ctx->net); + WARN_ON_ONCE(!lockdep_commit_lock_is_held(ctx->net)); switch (phase) { case NFT_TRANS_PREPARE_ERROR: -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 150/480] arch: powerpc: defconfig: Drop obsolete CONFIG_NET_CLS_TCINDEX 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (148 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 149/480] netfilter: nf_tables: adjust lockdep assertions handling Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:45 ` [PATCH 6.15 151/480] um: rtc: Avoid shadowing err in uml_rtc_start() Greg Kroah-Hartman ` (341 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Johan Korsnes, Christophe Leroy, Madhavan Srinivasan, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Johan Korsnes <johan.korsnes@gmail.com> [ Upstream commit 75cd37c5f28b85979fd5a65174013010f6b78f27 ] This option was removed from the Kconfig in commit 8c710f75256b ("net/sched: Retire tcindex classifier") but it was not removed from the defconfigs. Fixes: 8c710f75256b ("net/sched: Retire tcindex classifier") Signed-off-by: Johan Korsnes <johan.korsnes@gmail.com> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250323191116.113482-1-johan.korsnes@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/powerpc/configs/ppc6xx_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/powerpc/configs/ppc6xx_defconfig b/arch/powerpc/configs/ppc6xx_defconfig index a91a766b71a4..efa1411a52e0 100644 --- a/arch/powerpc/configs/ppc6xx_defconfig +++ b/arch/powerpc/configs/ppc6xx_defconfig @@ -253,7 +253,6 @@ CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_CLS_BASIC=m -CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 151/480] um: rtc: Avoid shadowing err in uml_rtc_start() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (149 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 150/480] arch: powerpc: defconfig: Drop obsolete CONFIG_NET_CLS_TCINDEX Greg Kroah-Hartman @ 2025-08-12 17:45 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 152/480] iommu/amd: Enable PASID and ATS capabilities in the correct order Greg Kroah-Hartman ` (340 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:45 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Tiwei Bie, Johannes Berg, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Tiwei Bie <tiwei.btw@antgroup.com> [ Upstream commit 4c916e3b224a02019b3cc3983a15f32bfd9a22df ] Remove the declaration of 'err' inside the 'if (timetravel)' block, as it would otherwise be unavailable outside that block, potentially leading to uml_rtc_start() returning an uninitialized value. Fixes: dde8b58d5127 ("um: add a pseudo RTC") Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20250708090403.1067440-5-tiwei.bie@linux.dev Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/um/drivers/rtc_user.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/um/drivers/rtc_user.c b/arch/um/drivers/rtc_user.c index 51e79f3148cd..67912fcf7b28 100644 --- a/arch/um/drivers/rtc_user.c +++ b/arch/um/drivers/rtc_user.c @@ -28,7 +28,7 @@ int uml_rtc_start(bool timetravel) int err; if (timetravel) { - int err = os_pipe(uml_rtc_irq_fds, 1, 1); + err = os_pipe(uml_rtc_irq_fds, 1, 1); if (err) goto fail; } else { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 152/480] iommu/amd: Enable PASID and ATS capabilities in the correct order 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (150 preceding siblings ...) 2025-08-12 17:45 ` [PATCH 6.15 151/480] um: rtc: Avoid shadowing err in uml_rtc_start() Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 153/480] net/sched: Restrict conditions for adding duplicating netems to qdisc tree Greg Kroah-Hartman ` (339 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Suravee Suthikulpanit, Vasant Hegde, Jason Gunthorpe, Jerry Snitselaar, Easwar Hariharan, Joerg Roedel, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Easwar Hariharan <eahariha@linux.microsoft.com> [ Upstream commit c694bc8b612ddd0dd70e122a00f39cb1e2e6927f ] Per the PCIe spec, behavior of the PASID capability is undefined if the value of the PASID Enable bit changes while the Enable bit of the function's ATS control register is Set. Unfortunately, pdev_enable_caps() does exactly that by ordering enabling ATS for the device before enabling PASID. Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Cc: Vasant Hegde <vasant.hegde@amd.com> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Jerry Snitselaar <jsnitsel@redhat.com> Fixes: eda8c2860ab679 ("iommu/amd: Enable device ATS/PASID/PRI capabilities independently") Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20250703155433.6221-1-eahariha@linux.microsoft.com Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/iommu/amd/iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c index 31f8d208dedb..cef1d2400d47 100644 --- a/drivers/iommu/amd/iommu.c +++ b/drivers/iommu/amd/iommu.c @@ -634,8 +634,8 @@ static inline void pdev_disable_cap_pasid(struct pci_dev *pdev) static void pdev_enable_caps(struct pci_dev *pdev) { - pdev_enable_cap_ats(pdev); pdev_enable_cap_pasid(pdev); + pdev_enable_cap_ats(pdev); pdev_enable_cap_pri(pdev); } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 153/480] net/sched: Restrict conditions for adding duplicating netems to qdisc tree 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (151 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 152/480] iommu/amd: Enable PASID and ATS capabilities in the correct order Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 154/480] net_sched: act_ctinfo: use atomic64_t for three counters Greg Kroah-Hartman ` (338 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, William Liu, Savino Dicanosa, Jamal Hadi Salim, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: William Liu <will@willsroot.io> [ Upstream commit ec8e0e3d7adef940cdf9475e2352c0680189d14e ] netem_enqueue's duplication prevention logic breaks when a netem resides in a qdisc tree with other netems - this can lead to a soft lockup and OOM loop in netem_dequeue, as seen in [1]. Ensure that a duplicating netem cannot exist in a tree with other netems. Previous approaches suggested in discussions in chronological order: 1) Track duplication status or ttl in the sk_buff struct. Considered too specific a use case to extend such a struct, though this would be a resilient fix and address other previous and potential future DOS bugs like the one described in loopy fun [2]. 2) Restrict netem_enqueue recursion depth like in act_mirred with a per cpu variable. However, netem_dequeue can call enqueue on its child, and the depth restriction could be bypassed if the child is a netem. 3) Use the same approach as in 2, but add metadata in netem_skb_cb to handle the netem_dequeue case and track a packet's involvement in duplication. This is an overly complex approach, and Jamal notes that the skb cb can be overwritten to circumvent this safeguard. 4) Prevent the addition of a netem to a qdisc tree if its ancestral path contains a netem. However, filters and actions can cause a packet to change paths when re-enqueued to the root from netem duplication, leading us to the current solution: prevent a duplicating netem from inhabiting the same tree as other netems. [1] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/ [2] https://lwn.net/Articles/719297/ Fixes: 0afb51e72855 ("[PKT_SCHED]: netem: reinsert for duplication") Reported-by: William Liu <will@willsroot.io> Reported-by: Savino Dicanosa <savy@syst3mfailure.io> Signed-off-by: William Liu <will@willsroot.io> Signed-off-by: Savino Dicanosa <savy@syst3mfailure.io> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Link: https://patch.msgid.link/20250708164141.875402-1-will@willsroot.io Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/sched/sch_netem.c | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c index fdd79d3ccd8c..eafc316ae319 100644 --- a/net/sched/sch_netem.c +++ b/net/sched/sch_netem.c @@ -973,6 +973,41 @@ static int parse_attr(struct nlattr *tb[], int maxtype, struct nlattr *nla, return 0; } +static const struct Qdisc_class_ops netem_class_ops; + +static int check_netem_in_tree(struct Qdisc *sch, bool duplicates, + struct netlink_ext_ack *extack) +{ + struct Qdisc *root, *q; + unsigned int i; + + root = qdisc_root_sleeping(sch); + + if (sch != root && root->ops->cl_ops == &netem_class_ops) { + if (duplicates || + ((struct netem_sched_data *)qdisc_priv(root))->duplicate) + goto err; + } + + if (!qdisc_dev(root)) + return 0; + + hash_for_each(qdisc_dev(root)->qdisc_hash, i, q, hash) { + if (sch != q && q->ops->cl_ops == &netem_class_ops) { + if (duplicates || + ((struct netem_sched_data *)qdisc_priv(q))->duplicate) + goto err; + } + } + + return 0; + +err: + NL_SET_ERR_MSG(extack, + "netem: cannot mix duplicating netems with other netems in tree"); + return -EINVAL; +} + /* Parse netlink message to set options */ static int netem_change(struct Qdisc *sch, struct nlattr *opt, struct netlink_ext_ack *extack) @@ -1031,6 +1066,11 @@ static int netem_change(struct Qdisc *sch, struct nlattr *opt, q->gap = qopt->gap; q->counter = 0; q->loss = qopt->loss; + + ret = check_netem_in_tree(sch, qopt->duplicate, extack); + if (ret) + goto unlock; + q->duplicate = qopt->duplicate; /* for compatibility with earlier versions. -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 154/480] net_sched: act_ctinfo: use atomic64_t for three counters 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (152 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 153/480] net/sched: Restrict conditions for adding duplicating netems to qdisc tree Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 155/480] RDMA/mlx5: Fix UMR modifying of mkey page size Greg Kroah-Hartman ` (337 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Eric Dumazet, Pedro Tammela, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Eric Dumazet <edumazet@google.com> [ Upstream commit d300335b4e18672913dd792ff9f49e6cccf41d26 ] Commit 21c167aa0ba9 ("net/sched: act_ctinfo: use percpu stats") missed that stats_dscp_set, stats_dscp_error and stats_cpmark_set might be written (and read) locklessly. Use atomic64_t for these three fields, I doubt act_ctinfo is used heavily on big SMP hosts anyway. Fixes: 24ec483cec98 ("net: sched: Introduce act_ctinfo action") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Pedro Tammela <pctammela@mojatatu.com> Link: https://patch.msgid.link/20250709090204.797558-6-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- include/net/tc_act/tc_ctinfo.h | 6 +++--- net/sched/act_ctinfo.c | 19 +++++++++++-------- 2 files changed, 14 insertions(+), 11 deletions(-) diff --git a/include/net/tc_act/tc_ctinfo.h b/include/net/tc_act/tc_ctinfo.h index f071c1d70a25..a04bcac7adf4 100644 --- a/include/net/tc_act/tc_ctinfo.h +++ b/include/net/tc_act/tc_ctinfo.h @@ -18,9 +18,9 @@ struct tcf_ctinfo_params { struct tcf_ctinfo { struct tc_action common; struct tcf_ctinfo_params __rcu *params; - u64 stats_dscp_set; - u64 stats_dscp_error; - u64 stats_cpmark_set; + atomic64_t stats_dscp_set; + atomic64_t stats_dscp_error; + atomic64_t stats_cpmark_set; }; enum { diff --git a/net/sched/act_ctinfo.c b/net/sched/act_ctinfo.c index 5b1241ddc758..93ab3bcd6d31 100644 --- a/net/sched/act_ctinfo.c +++ b/net/sched/act_ctinfo.c @@ -44,9 +44,9 @@ static void tcf_ctinfo_dscp_set(struct nf_conn *ct, struct tcf_ctinfo *ca, ipv4_change_dsfield(ip_hdr(skb), INET_ECN_MASK, newdscp); - ca->stats_dscp_set++; + atomic64_inc(&ca->stats_dscp_set); } else { - ca->stats_dscp_error++; + atomic64_inc(&ca->stats_dscp_error); } } break; @@ -57,9 +57,9 @@ static void tcf_ctinfo_dscp_set(struct nf_conn *ct, struct tcf_ctinfo *ca, ipv6_change_dsfield(ipv6_hdr(skb), INET_ECN_MASK, newdscp); - ca->stats_dscp_set++; + atomic64_inc(&ca->stats_dscp_set); } else { - ca->stats_dscp_error++; + atomic64_inc(&ca->stats_dscp_error); } } break; @@ -72,7 +72,7 @@ static void tcf_ctinfo_cpmark_set(struct nf_conn *ct, struct tcf_ctinfo *ca, struct tcf_ctinfo_params *cp, struct sk_buff *skb) { - ca->stats_cpmark_set++; + atomic64_inc(&ca->stats_cpmark_set); skb->mark = READ_ONCE(ct->mark) & cp->cpmarkmask; } @@ -323,15 +323,18 @@ static int tcf_ctinfo_dump(struct sk_buff *skb, struct tc_action *a, } if (nla_put_u64_64bit(skb, TCA_CTINFO_STATS_DSCP_SET, - ci->stats_dscp_set, TCA_CTINFO_PAD)) + atomic64_read(&ci->stats_dscp_set), + TCA_CTINFO_PAD)) goto nla_put_failure; if (nla_put_u64_64bit(skb, TCA_CTINFO_STATS_DSCP_ERROR, - ci->stats_dscp_error, TCA_CTINFO_PAD)) + atomic64_read(&ci->stats_dscp_error), + TCA_CTINFO_PAD)) goto nla_put_failure; if (nla_put_u64_64bit(skb, TCA_CTINFO_STATS_CPMARK_SET, - ci->stats_cpmark_set, TCA_CTINFO_PAD)) + atomic64_read(&ci->stats_cpmark_set), + TCA_CTINFO_PAD)) goto nla_put_failure; spin_unlock_bh(&ci->tcf_lock); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 155/480] RDMA/mlx5: Fix UMR modifying of mkey page size 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (153 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 154/480] net_sched: act_ctinfo: use atomic64_t for three counters Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 156/480] xen: fix UAF in dmabuf_exp_from_pages() Greg Kroah-Hartman ` (336 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Edward Srouji, Michael Guralnik, Leon Romanovsky, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Edward Srouji <edwards@nvidia.com> [ Upstream commit c4f96972c3c206ac8f6770b5ecd5320b561d0058 ] When changing the page size on an mkey, the driver needs to set the appropriate bits in the mkey mask to indicate which fields are being modified. The 6th bit of a page size in mlx5 driver is considered an extension, and this bit has a dedicated capability and mask bits. Previously, the driver was not setting this mask in the mkey mask when performing page size changes, regardless of its hardware support, potentially leading to an incorrect page size updates. This fixes the issue by setting the relevant bit in the mkey mask when performing page size changes on an mkey and the 6th bit of this field is supported by the hardware. Fixes: cef7dde8836a ("net/mlx5: Expand mkey page size to support 6 bits") Signed-off-by: Edward Srouji <edwards@nvidia.com> Reviewed-by: Michael Guralnik <michaelgur@nvidia.com> Link: https://patch.msgid.link/9f43a9c73bf2db6085a99dc836f7137e76579f09.1751979184.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/infiniband/hw/mlx5/umr.c | 6 ++++-- include/linux/mlx5/device.h | 1 + 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/hw/mlx5/umr.c b/drivers/infiniband/hw/mlx5/umr.c index 793f3c5c4d01..80c665d15218 100644 --- a/drivers/infiniband/hw/mlx5/umr.c +++ b/drivers/infiniband/hw/mlx5/umr.c @@ -32,13 +32,15 @@ static __be64 get_umr_disable_mr_mask(void) return cpu_to_be64(result); } -static __be64 get_umr_update_translation_mask(void) +static __be64 get_umr_update_translation_mask(struct mlx5_ib_dev *dev) { u64 result; result = MLX5_MKEY_MASK_LEN | MLX5_MKEY_MASK_PAGE_SIZE | MLX5_MKEY_MASK_START_ADDR; + if (MLX5_CAP_GEN_2(dev->mdev, umr_log_entity_size_5)) + result |= MLX5_MKEY_MASK_PAGE_SIZE_5; return cpu_to_be64(result); } @@ -654,7 +656,7 @@ static void mlx5r_umr_final_update_xlt(struct mlx5_ib_dev *dev, flags & MLX5_IB_UPD_XLT_ENABLE || flags & MLX5_IB_UPD_XLT_ADDR; if (update_translation) { - wqe->ctrl_seg.mkey_mask |= get_umr_update_translation_mask(); + wqe->ctrl_seg.mkey_mask |= get_umr_update_translation_mask(dev); if (!mr->ibmr.length) MLX5_SET(mkc, &wqe->mkey_seg, length64, 1); } diff --git a/include/linux/mlx5/device.h b/include/linux/mlx5/device.h index 6822cfa5f4ad..9d2467f982ad 100644 --- a/include/linux/mlx5/device.h +++ b/include/linux/mlx5/device.h @@ -280,6 +280,7 @@ enum { MLX5_MKEY_MASK_SMALL_FENCE = 1ull << 23, MLX5_MKEY_MASK_RELAXED_ORDERING_WRITE = 1ull << 25, MLX5_MKEY_MASK_FREE = 1ull << 29, + MLX5_MKEY_MASK_PAGE_SIZE_5 = 1ull << 42, MLX5_MKEY_MASK_RELAXED_ORDERING_READ = 1ull << 47, }; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 156/480] xen: fix UAF in dmabuf_exp_from_pages() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (154 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 155/480] RDMA/mlx5: Fix UMR modifying of mkey page size Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 157/480] sched/deadline: Initialize dl_servers after SMP Greg Kroah-Hartman ` (335 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Al Viro, Juergen Gross, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Al Viro <viro@zeniv.linux.org.uk> [ Upstream commit 532c8b51b3a8676cbf533a291f8156774f30ea87 ] [dma_buf_fd() fixes; no preferences regarding the tree it goes through - up to xen folks] As soon as we'd inserted a file reference into descriptor table, another thread could close it. That's fine for the case when all we are doing is returning that descriptor to userland (it's a race, but it's a userland race and there's nothing the kernel can do about it). However, if we follow fd_install() with any kind of access to objects that would be destroyed on close (be it the struct file itself or anything destroyed by its ->release()), we have a UAF. dma_buf_fd() is a combination of reserving a descriptor and fd_install(). gntdev dmabuf_exp_from_pages() calls it and then proceeds to access the objects destroyed on close - starting with gntdev_dmabuf itself. Fix that by doing reserving descriptor before anything else and do fd_install() only when everything had been set up. Fixes: a240d6e42e28 ("xen/gntdev: Implement dma-buf export functionality") Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Acked-by: Juergen Gross <jgross@suse.com> Message-ID: <20250712050916.GY1880847@ZenIV> Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/xen/gntdev-dmabuf.c | 28 ++++++++++------------------ 1 file changed, 10 insertions(+), 18 deletions(-) diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c index 5453d86324f6..82855105ab85 100644 --- a/drivers/xen/gntdev-dmabuf.c +++ b/drivers/xen/gntdev-dmabuf.c @@ -357,8 +357,11 @@ struct gntdev_dmabuf_export_args { static int dmabuf_exp_from_pages(struct gntdev_dmabuf_export_args *args) { DEFINE_DMA_BUF_EXPORT_INFO(exp_info); - struct gntdev_dmabuf *gntdev_dmabuf; - int ret; + struct gntdev_dmabuf *gntdev_dmabuf __free(kfree) = NULL; + CLASS(get_unused_fd, ret)(O_CLOEXEC); + + if (ret < 0) + return ret; gntdev_dmabuf = kzalloc(sizeof(*gntdev_dmabuf), GFP_KERNEL); if (!gntdev_dmabuf) @@ -383,32 +386,21 @@ static int dmabuf_exp_from_pages(struct gntdev_dmabuf_export_args *args) exp_info.priv = gntdev_dmabuf; gntdev_dmabuf->dmabuf = dma_buf_export(&exp_info); - if (IS_ERR(gntdev_dmabuf->dmabuf)) { - ret = PTR_ERR(gntdev_dmabuf->dmabuf); - gntdev_dmabuf->dmabuf = NULL; - goto fail; - } - - ret = dma_buf_fd(gntdev_dmabuf->dmabuf, O_CLOEXEC); - if (ret < 0) - goto fail; + if (IS_ERR(gntdev_dmabuf->dmabuf)) + return PTR_ERR(gntdev_dmabuf->dmabuf); gntdev_dmabuf->fd = ret; args->fd = ret; pr_debug("Exporting DMA buffer with fd %d\n", ret); + get_file(gntdev_dmabuf->priv->filp); mutex_lock(&args->dmabuf_priv->lock); list_add(&gntdev_dmabuf->next, &args->dmabuf_priv->exp_list); mutex_unlock(&args->dmabuf_priv->lock); - get_file(gntdev_dmabuf->priv->filp); - return 0; -fail: - if (gntdev_dmabuf->dmabuf) - dma_buf_put(gntdev_dmabuf->dmabuf); - kfree(gntdev_dmabuf); - return ret; + fd_install(take_fd(ret), no_free_ptr(gntdev_dmabuf)->dmabuf->file); + return 0; } static struct gntdev_grant_map * -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 157/480] sched/deadline: Initialize dl_servers after SMP 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (155 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 156/480] xen: fix UAF in dmabuf_exp_from_pages() Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 158/480] sched/deadline: Reset extra_bw to max_bw when clearing root domains Greg Kroah-Hartman ` (334 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Marcel Ziswiler, Juri Lelli, Peter Zijlstra (Intel), Waiman Long, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Juri Lelli <juri.lelli@redhat.com> [ Upstream commit 9f239df55546ee1d28f0976130136ffd1cad0fd7 ] dl-servers are currently initialized too early at boot when CPUs are not fully up (only boot CPU is). This results in miscalculation of per runqueue DEADLINE variables like extra_bw (which needs a stable CPU count). Move initialization of dl-servers later on after SMP has been initialized and CPUs are all online, so that CPU count is stable and DEADLINE variables can be computed correctly. Fixes: d741f297bceaf ("sched/fair: Fair server interface") Reported-by: Marcel Ziswiler <marcel.ziswiler@codethink.co.uk> Signed-off-by: Juri Lelli <juri.lelli@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Waiman Long <longman@redhat.com> Tested-by: Marcel Ziswiler <marcel.ziswiler@codethink.co.uk> # nuc & rock5b Link: https://lore.kernel.org/r/20250627115118.438797-2-juri.lelli@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- kernel/sched/core.c | 2 ++ kernel/sched/deadline.c | 48 +++++++++++++++++++++++++---------------- kernel/sched/sched.h | 1 + 3 files changed, 33 insertions(+), 18 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 7d5f51e2f761..333743f143aa 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -8501,6 +8501,8 @@ void __init sched_init_smp(void) init_sched_rt_class(); init_sched_dl_class(); + sched_init_dl_servers(); + sched_smp_initialized = true; } diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index 094134c9b135..ef5b5c045769 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -824,6 +824,8 @@ static inline void setup_new_dl_entity(struct sched_dl_entity *dl_se) struct dl_rq *dl_rq = dl_rq_of_se(dl_se); struct rq *rq = rq_of_dl_rq(dl_rq); + update_rq_clock(rq); + WARN_ON(is_dl_boosted(dl_se)); WARN_ON(dl_time_before(rq_clock(rq), dl_se->deadline)); @@ -1652,23 +1654,7 @@ void dl_server_start(struct sched_dl_entity *dl_se) { struct rq *rq = dl_se->rq; - /* - * XXX: the apply do not work fine at the init phase for the - * fair server because things are not yet set. We need to improve - * this before getting generic. - */ - if (!dl_server(dl_se)) { - u64 runtime = 50 * NSEC_PER_MSEC; - u64 period = 1000 * NSEC_PER_MSEC; - - dl_server_apply_params(dl_se, runtime, period, 1); - - dl_se->dl_server = 1; - dl_se->dl_defer = 1; - setup_new_dl_entity(dl_se); - } - - if (!dl_se->dl_runtime || dl_se->dl_server_active) + if (!dl_server(dl_se) || dl_se->dl_server_active) return; dl_se->dl_server_active = 1; @@ -1679,7 +1665,7 @@ void dl_server_start(struct sched_dl_entity *dl_se) void dl_server_stop(struct sched_dl_entity *dl_se) { - if (!dl_se->dl_runtime) + if (!dl_server(dl_se) || !dl_server_active(dl_se)) return; dequeue_dl_entity(dl_se, DEQUEUE_SLEEP); @@ -1712,6 +1698,32 @@ void dl_server_init(struct sched_dl_entity *dl_se, struct rq *rq, dl_se->server_pick_task = pick_task; } +void sched_init_dl_servers(void) +{ + int cpu; + struct rq *rq; + struct sched_dl_entity *dl_se; + + for_each_online_cpu(cpu) { + u64 runtime = 50 * NSEC_PER_MSEC; + u64 period = 1000 * NSEC_PER_MSEC; + + rq = cpu_rq(cpu); + + guard(rq_lock_irq)(rq); + + dl_se = &rq->fair_server; + + WARN_ON(dl_server(dl_se)); + + dl_server_apply_params(dl_se, runtime, period, 1); + + dl_se->dl_server = 1; + dl_se->dl_defer = 1; + setup_new_dl_entity(dl_se); + } +} + void __dl_server_attach_root(struct sched_dl_entity *dl_se, struct rq *rq) { u64 new_bw = dl_se->dl_bw; diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index d6f82833f652..063f29a228ad 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -384,6 +384,7 @@ extern void dl_server_stop(struct sched_dl_entity *dl_se); extern void dl_server_init(struct sched_dl_entity *dl_se, struct rq *rq, dl_server_has_tasks_f has_tasks, dl_server_pick_f pick_task); +extern void sched_init_dl_servers(void); extern void dl_server_update_idle_time(struct rq *rq, struct task_struct *p); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 158/480] sched/deadline: Reset extra_bw to max_bw when clearing root domains 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (156 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 157/480] sched/deadline: Initialize dl_servers after SMP Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 159/480] iommu/vt-d: Do not wipe out the page table NID when devices detach Greg Kroah-Hartman ` (333 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Marcel Ziswiler, Juri Lelli, Peter Zijlstra (Intel), Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Juri Lelli <juri.lelli@redhat.com> [ Upstream commit fcc9276c4d331cd1fe9319d793e80b02e09727f5 ] dl_clear_root_domain() doesn't take into account the fact that per-rq extra_bw variables retain values computed before root domain changes, resulting in broken accounting. Fix it by resetting extra_bw to max_bw before restoring back dl-servers contributions. Fixes: 2ff899e351643 ("sched/deadline: Rebuild root domain accounting after every update") Reported-by: Marcel Ziswiler <marcel.ziswiler@codethink.co.uk> Signed-off-by: Juri Lelli <juri.lelli@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Marcel Ziswiler <marcel.ziswiler@codethink.co.uk> # nuc & rock5b Link: https://lore.kernel.org/r/20250627115118.438797-3-juri.lelli@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- kernel/sched/deadline.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index ef5b5c045769..135580a41e14 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -3007,7 +3007,14 @@ void dl_clear_root_domain(struct root_domain *rd) int i; guard(raw_spinlock_irqsave)(&rd->dl_bw.lock); + + /* + * Reset total_bw to zero and extra_bw to max_bw so that next + * loop will add dl-servers contributions back properly, + */ rd->dl_bw.total_bw = 0; + for_each_cpu(i, rd->span) + cpu_rq(i)->dl.extra_bw = cpu_rq(i)->dl.max_bw; /* * dl_servers are not tasks. Since dl_add_task_root_domain ignores -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 159/480] iommu/vt-d: Do not wipe out the page table NID when devices detach 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (157 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 158/480] sched/deadline: Reset extra_bw to max_bw when clearing root domains Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 160/480] iommu/arm-smmu: disable PRR on SM8250 Greg Kroah-Hartman ` (332 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Wei Wang, Kevin Tian, Jason Gunthorpe, Lu Baolu, Will Deacon, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jason Gunthorpe <jgg@nvidia.com> [ Upstream commit 5c3687d5789cfff8d285a2c76bceb47f145bf01f ] The NID is used to control which NUMA node memory for the page table is allocated it from. It should be a permanent property of the page table when it was allocated and not change during attach/detach of devices. Reviewed-by: Wei Wang <wei.w.wang@intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/3-v3-dbbe6f7e7ae3+124ffe-vtd_prep_jgg@nvidia.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Fixes: 7c204426b818 ("iommu/vt-d: Add domain_alloc_paging support") Link: https://lore.kernel.org/r/20250714045028.958850-6-baolu.lu@linux.intel.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/iommu/intel/iommu.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index ff07ee2940f5..024fb7c36d88 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -1440,7 +1440,6 @@ void domain_detach_iommu(struct dmar_domain *domain, struct intel_iommu *iommu) if (--info->refcnt == 0) { clear_bit(info->did, iommu->domain_ids); xa_erase(&domain->iommu_array, iommu->seq_id); - domain->nid = NUMA_NO_NODE; kfree(info); } spin_unlock(&iommu->lock); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 160/480] iommu/arm-smmu: disable PRR on SM8250 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (158 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 159/480] iommu/vt-d: Do not wipe out the page table NID when devices detach Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 161/480] xen/gntdev: remove struct gntdev_copy_batch from stack Greg Kroah-Hartman ` (331 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Dmitry Baryshkov, Akhil P Oommen, Rob Clark, Will Deacon, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> [ Upstream commit b9bb7e814cd0c3633791327a96749a1f9b7f3ef4 ] On SM8250 / QRB5165-RB5 using PRR bits resets the device, most likely because of the hyp limitations. Disable PRR support on that platform. Fixes: 7f2ef1bfc758 ("iommu/arm-smmu: Add support for PRR bit setup") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Rob Clark <robin.clark@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250705-iommu-fix-prr-v2-1-406fecc37cf8@oss.qualcomm.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c index 59d02687280e..4f4c9e376fc4 100644 --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c @@ -342,7 +342,8 @@ static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain, priv->set_prr_addr = NULL; if (of_device_is_compatible(np, "qcom,smmu-500") && - of_device_is_compatible(np, "qcom,adreno-smmu")) { + !of_device_is_compatible(np, "qcom,sm8250-smmu-500") && + of_device_is_compatible(np, "qcom,adreno-smmu")) { priv->set_prr_bit = qcom_adreno_smmu_set_prr_bit; priv->set_prr_addr = qcom_adreno_smmu_set_prr_addr; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 161/480] xen/gntdev: remove struct gntdev_copy_batch from stack 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (159 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 160/480] iommu/arm-smmu: disable PRR on SM8250 Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 162/480] tcp: call tcp_measure_rcv_mss() for ooo packets Greg Kroah-Hartman ` (330 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Abinash Singh, Stefano Stabellini, Juergen Gross, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Juergen Gross <jgross@suse.com> [ Upstream commit 70045cf6593cbf0740956ea9b7b4269142c6ee38 ] When compiling the kernel with LLVM, the following warning was issued: drivers/xen/gntdev.c:991: warning: stack frame size (1160) exceeds limit (1024) in function 'gntdev_ioctl' The main reason is struct gntdev_copy_batch which is located on the stack and has a size of nearly 1kb. For performance reasons it shouldn't by just dynamically allocated instead, so allocate a new instance when needed and instead of freeing it put it into a list of free structs anchored in struct gntdev_priv. Fixes: a4cdb556cae0 ("xen/gntdev: add ioctl for grant copy") Reported-by: Abinash Singh <abinashsinghlalotra@gmail.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Signed-off-by: Juergen Gross <jgross@suse.com> Message-ID: <20250703073259.17356-1-jgross@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/xen/gntdev-common.h | 4 +++ drivers/xen/gntdev.c | 71 ++++++++++++++++++++++++++----------- 2 files changed, 54 insertions(+), 21 deletions(-) diff --git a/drivers/xen/gntdev-common.h b/drivers/xen/gntdev-common.h index 9c286b2a1900..ac8ce3179ba2 100644 --- a/drivers/xen/gntdev-common.h +++ b/drivers/xen/gntdev-common.h @@ -26,6 +26,10 @@ struct gntdev_priv { /* lock protects maps and freeable_maps. */ struct mutex lock; + /* Free instances of struct gntdev_copy_batch. */ + struct gntdev_copy_batch *batch; + struct mutex batch_lock; + #ifdef CONFIG_XEN_GRANT_DMA_ALLOC /* Device for which DMA memory is allocated. */ struct device *dma_dev; diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index 61faea1f0663..1f2160765618 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c @@ -56,6 +56,18 @@ MODULE_AUTHOR("Derek G. Murray <Derek.Murray@cl.cam.ac.uk>, " "Gerd Hoffmann <kraxel@redhat.com>"); MODULE_DESCRIPTION("User-space granted page access driver"); +#define GNTDEV_COPY_BATCH 16 + +struct gntdev_copy_batch { + struct gnttab_copy ops[GNTDEV_COPY_BATCH]; + struct page *pages[GNTDEV_COPY_BATCH]; + s16 __user *status[GNTDEV_COPY_BATCH]; + unsigned int nr_ops; + unsigned int nr_pages; + bool writeable; + struct gntdev_copy_batch *next; +}; + static unsigned int limit = 64*1024; module_param(limit, uint, 0644); MODULE_PARM_DESC(limit, @@ -584,6 +596,8 @@ static int gntdev_open(struct inode *inode, struct file *flip) INIT_LIST_HEAD(&priv->maps); mutex_init(&priv->lock); + mutex_init(&priv->batch_lock); + #ifdef CONFIG_XEN_GNTDEV_DMABUF priv->dmabuf_priv = gntdev_dmabuf_init(flip); if (IS_ERR(priv->dmabuf_priv)) { @@ -608,6 +622,7 @@ static int gntdev_release(struct inode *inode, struct file *flip) { struct gntdev_priv *priv = flip->private_data; struct gntdev_grant_map *map; + struct gntdev_copy_batch *batch; pr_debug("priv %p\n", priv); @@ -620,6 +635,14 @@ static int gntdev_release(struct inode *inode, struct file *flip) } mutex_unlock(&priv->lock); + mutex_lock(&priv->batch_lock); + while (priv->batch) { + batch = priv->batch; + priv->batch = batch->next; + kfree(batch); + } + mutex_unlock(&priv->batch_lock); + #ifdef CONFIG_XEN_GNTDEV_DMABUF gntdev_dmabuf_fini(priv->dmabuf_priv); #endif @@ -785,17 +808,6 @@ static long gntdev_ioctl_notify(struct gntdev_priv *priv, void __user *u) return rc; } -#define GNTDEV_COPY_BATCH 16 - -struct gntdev_copy_batch { - struct gnttab_copy ops[GNTDEV_COPY_BATCH]; - struct page *pages[GNTDEV_COPY_BATCH]; - s16 __user *status[GNTDEV_COPY_BATCH]; - unsigned int nr_ops; - unsigned int nr_pages; - bool writeable; -}; - static int gntdev_get_page(struct gntdev_copy_batch *batch, void __user *virt, unsigned long *gfn) { @@ -953,36 +965,53 @@ static int gntdev_grant_copy_seg(struct gntdev_copy_batch *batch, static long gntdev_ioctl_grant_copy(struct gntdev_priv *priv, void __user *u) { struct ioctl_gntdev_grant_copy copy; - struct gntdev_copy_batch batch; + struct gntdev_copy_batch *batch; unsigned int i; int ret = 0; if (copy_from_user(©, u, sizeof(copy))) return -EFAULT; - batch.nr_ops = 0; - batch.nr_pages = 0; + mutex_lock(&priv->batch_lock); + if (!priv->batch) { + batch = kmalloc(sizeof(*batch), GFP_KERNEL); + } else { + batch = priv->batch; + priv->batch = batch->next; + } + mutex_unlock(&priv->batch_lock); + if (!batch) + return -ENOMEM; + + batch->nr_ops = 0; + batch->nr_pages = 0; for (i = 0; i < copy.count; i++) { struct gntdev_grant_copy_segment seg; if (copy_from_user(&seg, ©.segments[i], sizeof(seg))) { ret = -EFAULT; + gntdev_put_pages(batch); goto out; } - ret = gntdev_grant_copy_seg(&batch, &seg, ©.segments[i].status); - if (ret < 0) + ret = gntdev_grant_copy_seg(batch, &seg, ©.segments[i].status); + if (ret < 0) { + gntdev_put_pages(batch); goto out; + } cond_resched(); } - if (batch.nr_ops) - ret = gntdev_copy(&batch); - return ret; + if (batch->nr_ops) + ret = gntdev_copy(batch); + + out: + mutex_lock(&priv->batch_lock); + batch->next = priv->batch; + priv->batch = batch; + mutex_unlock(&priv->batch_lock); - out: - gntdev_put_pages(&batch); return ret; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 162/480] tcp: call tcp_measure_rcv_mss() for ooo packets 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (160 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 161/480] xen/gntdev: remove struct gntdev_copy_batch from stack Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 163/480] wifi: rtl8xxxu: Fix RX skb size for aggregation disabled Greg Kroah-Hartman ` (329 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Eric Dumazet, Kuniyuki Iwashima, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Eric Dumazet <edumazet@google.com> [ Upstream commit 38d7e444336567bae1c7b21fc18b7ceaaa5643a0 ] tcp_measure_rcv_mss() is used to update icsk->icsk_ack.rcv_mss (tcpi_rcv_mss in tcp_info) and tp->scaling_ratio. Calling it from tcp_data_queue_ofo() makes sure these fields are updated, and permits a better tuning of sk->sk_rcvbuf, in the case a new flow receives many ooo packets. Fixes: dfa2f0483360 ("tcp: get rid of sysctl_tcp_adv_win_scale") Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20250711114006.480026-5-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/ipv4/tcp_input.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index e75ee9023674..ca24c2ea359b 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -5056,6 +5056,7 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb) return; } + tcp_measure_rcv_mss(sk, skb); /* Disable header prediction. */ tp->pred_flags = 0; inet_csk_schedule_ack(sk); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 163/480] wifi: rtl8xxxu: Fix RX skb size for aggregation disabled 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (161 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 162/480] tcp: call tcp_measure_rcv_mss() for ooo packets Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 164/480] wifi: rtw88: Fix macid assigned to TDLS station Greg Kroah-Hartman ` (328 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Martin Kaistra, Ping-Ke Shih, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Martin Kaistra <martin.kaistra@linutronix.de> [ Upstream commit d76a1abcf57734d2bcd4a7ec051617edd4513d7f ] Commit 1e5b3b3fe9e0 ("rtl8xxxu: Adjust RX skb size to include space for phystats") increased the skb size when aggregation is enabled but decreased it for the aggregation disabled case. As a result, if a frame near the maximum size is received, rtl8xxxu_rx_complete() is called with status -EOVERFLOW and then the driver starts to malfunction and no further communication is possible. Restore the skb size in the aggregation disabled case. Fixes: 1e5b3b3fe9e0 ("rtl8xxxu: Adjust RX skb size to include space for phystats") Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250709121522.1992366-1-martin.kaistra@linutronix.de Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/wireless/realtek/rtl8xxxu/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/realtek/rtl8xxxu/core.c b/drivers/net/wireless/realtek/rtl8xxxu/core.c index 569856ca677f..c6f69d87c38d 100644 --- a/drivers/net/wireless/realtek/rtl8xxxu/core.c +++ b/drivers/net/wireless/realtek/rtl8xxxu/core.c @@ -6617,7 +6617,7 @@ static int rtl8xxxu_submit_rx_urb(struct rtl8xxxu_priv *priv, skb_size = fops->rx_agg_buf_size; skb_size += (rx_desc_sz + sizeof(struct rtl8723au_phy_stats)); } else { - skb_size = IEEE80211_MAX_FRAME_LEN; + skb_size = IEEE80211_MAX_FRAME_LEN + rx_desc_sz; } skb = __netdev_alloc_skb(NULL, skb_size, GFP_KERNEL); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 164/480] wifi: rtw88: Fix macid assigned to TDLS station 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (162 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 163/480] wifi: rtl8xxxu: Fix RX skb size for aggregation disabled Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 165/480] mwl8k: Add missing check after DMA map Greg Kroah-Hartman ` (327 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Bitterblue Smith, Ping-Ke Shih, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Bitterblue Smith <rtl8821cerfe2@gmail.com> [ Upstream commit 526b000991b557c40ea53e64ba24bb9e0fff0071 ] When working in station mode, TDLS peers are assigned macid 0, even though 0 was already assigned to the AP. This causes the connection with the AP to stop working after the TDLS connection is torn down. Assign the next available macid to TDLS peers, same as client stations in AP mode. Fixes: 902cb7b11f9a ("wifi: rtw88: assign mac_id for vif/sta and update to TX desc") Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/58648c09-8553-4bcc-a977-9dc9afd63780@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/wireless/realtek/rtw88/main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c index bc2c1a5a30b3..c589727c525e 100644 --- a/drivers/net/wireless/realtek/rtw88/main.c +++ b/drivers/net/wireless/realtek/rtw88/main.c @@ -349,7 +349,7 @@ int rtw_sta_add(struct rtw_dev *rtwdev, struct ieee80211_sta *sta, struct rtw_vif *rtwvif = (struct rtw_vif *)vif->drv_priv; int i; - if (vif->type == NL80211_IFTYPE_STATION) { + if (vif->type == NL80211_IFTYPE_STATION && !sta->tdls) { si->mac_id = rtwvif->mac_id; } else { si->mac_id = rtw_acquire_macid(rtwdev); @@ -386,7 +386,7 @@ void rtw_sta_remove(struct rtw_dev *rtwdev, struct ieee80211_sta *sta, cancel_work_sync(&si->rc_work); - if (vif->type != NL80211_IFTYPE_STATION) + if (vif->type != NL80211_IFTYPE_STATION || sta->tdls) rtw_release_macid(rtwdev, si->mac_id); if (fw_exist) rtw_fw_media_status_report(rtwdev, si->mac_id, false); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 165/480] mwl8k: Add missing check after DMA map 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (163 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 164/480] wifi: rtw88: Fix macid assigned to TDLS station Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 166/480] wifi: ath12k: Use HTT_TCL_METADATA_VER_V1 in FTM mode Greg Kroah-Hartman ` (326 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Thomas Fourier, Johannes Berg, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Fourier <fourier.thomas@gmail.com> [ Upstream commit 50459501b9a212dbe7a673727589ee105a8a9954 ] The DMA map functions can fail and should be tested for errors. If the mapping fails, unmap and return an error. Fixes: 788838ebe8a4 ("mwl8k: use pci_unmap_addr{,set}() to keep track of unmap addresses on rx") Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Link: https://patch.msgid.link/20250709111339.25360-2-fourier.thomas@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/wireless/marvell/mwl8k.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/wireless/marvell/mwl8k.c b/drivers/net/wireless/marvell/mwl8k.c index bab9ef37a1ab..8bcb1d0dd618 100644 --- a/drivers/net/wireless/marvell/mwl8k.c +++ b/drivers/net/wireless/marvell/mwl8k.c @@ -1227,6 +1227,10 @@ static int rxq_refill(struct ieee80211_hw *hw, int index, int limit) addr = dma_map_single(&priv->pdev->dev, skb->data, MWL8K_RX_MAXSZ, DMA_FROM_DEVICE); + if (dma_mapping_error(&priv->pdev->dev, addr)) { + kfree_skb(skb); + break; + } rxq->rxd_count++; rx = rxq->tail++; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 166/480] wifi: ath12k: Use HTT_TCL_METADATA_VER_V1 in FTM mode 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (164 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 165/480] mwl8k: Add missing check after DMA map Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 167/480] wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask() Greg Kroah-Hartman ` (325 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Aaradhana Sahu, Vasanthakumar Thiagarajan, Jeff Johnson, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com> [ Upstream commit 66b3ebc77d23d6574a965bdbfe41de8aeb7f384e ] Currently host sends HTT_TCL_METADATA_VER_V2 to the firmware regardless of the operating mode (Mission or FTM). Firmware expects additional software information (like peer ID, vdev ID, and link ID) in Tx packets when HTT_TCL_METADATA_VER_V2 is set. However, in FTM (Factory Test Mode) mode, no vdev is created on the host side (this is expected). As a result, the firmware fails to find the expected vdev during packet processing and ends up dropping packets. To fix this, send HTT_TCL_METADATA_VER_V1 in FTM mode because FTM mode doesn't support HTT_TCL_METADATA_VER_V2. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1 Fixes: 5d964966bd3f ("wifi: ath12k: Update HTT_TCL_METADATA version and bit mask definitions") Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250711035420.1509029-1-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/wireless/ath/ath12k/dp.h | 1 + drivers/net/wireless/ath/ath12k/dp_tx.c | 5 ++++- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath12k/dp.h b/drivers/net/wireless/ath/ath12k/dp.h index e8dbba0c3bb7..4003e81df535 100644 --- a/drivers/net/wireless/ath/ath12k/dp.h +++ b/drivers/net/wireless/ath/ath12k/dp.h @@ -425,6 +425,7 @@ enum htt_h2t_msg_type { }; #define HTT_VER_REQ_INFO_MSG_ID GENMASK(7, 0) +#define HTT_OPTION_TCL_METADATA_VER_V1 1 #define HTT_OPTION_TCL_METADATA_VER_V2 2 #define HTT_OPTION_TAG GENMASK(7, 0) #define HTT_OPTION_LEN GENMASK(15, 8) diff --git a/drivers/net/wireless/ath/ath12k/dp_tx.c b/drivers/net/wireless/ath/ath12k/dp_tx.c index faf58e91d3eb..5e741b221d87 100644 --- a/drivers/net/wireless/ath/ath12k/dp_tx.c +++ b/drivers/net/wireless/ath/ath12k/dp_tx.c @@ -1107,6 +1107,7 @@ int ath12k_dp_tx_htt_h2t_ver_req_msg(struct ath12k_base *ab) struct sk_buff *skb; struct htt_ver_req_cmd *cmd; int len = sizeof(*cmd); + u32 metadata_version; int ret; init_completion(&dp->htt_tgt_version_received); @@ -1119,12 +1120,14 @@ int ath12k_dp_tx_htt_h2t_ver_req_msg(struct ath12k_base *ab) cmd = (struct htt_ver_req_cmd *)skb->data; cmd->ver_reg_info = le32_encode_bits(HTT_H2T_MSG_TYPE_VERSION_REQ, HTT_OPTION_TAG); + metadata_version = ath12k_ftm_mode ? HTT_OPTION_TCL_METADATA_VER_V1 : + HTT_OPTION_TCL_METADATA_VER_V2; cmd->tcl_metadata_version = le32_encode_bits(HTT_TAG_TCL_METADATA_VERSION, HTT_OPTION_TAG) | le32_encode_bits(HTT_TCL_METADATA_VER_SZ, HTT_OPTION_LEN) | - le32_encode_bits(HTT_OPTION_TCL_METADATA_VER_V2, + le32_encode_bits(metadata_version, HTT_OPTION_VALUE); ret = ath12k_htc_send(&ab->htc, dp->eid, skb); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 167/480] wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (165 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 166/480] wifi: ath12k: Use HTT_TCL_METADATA_VER_V1 in FTM mode Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 168/480] drm/amdgpu/gfx9: fix kiq locking in KCQ reset Greg Kroah-Hartman ` (324 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Baochen Qiang, Jeff Johnson, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Baochen Qiang <quic_bqiang@quicinc.com> [ Upstream commit 65c12b104cb942d588a1a093acc4537fb3d3b129 ] ath11k_mac_disable_peer_fixed_rate() is passed as the iterator to ieee80211_iterate_stations_atomic(). Note in this case the iterator is required to be atomic, however ath11k_mac_disable_peer_fixed_rate() does not follow it as it might sleep. Consequently below warning is seen: BUG: sleeping function called from invalid context at wmi.c:304 Call Trace: <TASK> dump_stack_lvl __might_resched.cold ath11k_wmi_cmd_send ath11k_wmi_set_peer_param ath11k_mac_disable_peer_fixed_rate ieee80211_iterate_stations_atomic ath11k_mac_op_set_bitrate_mask.cold Change to ieee80211_iterate_stations_mtx() to fix this issue. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/20250603-ath11k-use-non-atomic-iterator-v1-1-d75762068d56@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/wireless/ath/ath11k/mac.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c index 4763b271309a..9514e95d5020 100644 --- a/drivers/net/wireless/ath/ath11k/mac.c +++ b/drivers/net/wireless/ath/ath11k/mac.c @@ -8734,9 +8734,9 @@ ath11k_mac_op_set_bitrate_mask(struct ieee80211_hw *hw, arvif->vdev_id, ret); return ret; } - ieee80211_iterate_stations_atomic(ar->hw, - ath11k_mac_disable_peer_fixed_rate, - arvif); + ieee80211_iterate_stations_mtx(ar->hw, + ath11k_mac_disable_peer_fixed_rate, + arvif); } else if (ath11k_mac_bitrate_mask_get_single_nss(ar, arvif, band, mask, &single_nss)) { rate = WMI_FIXED_RATE_NONE; @@ -8803,9 +8803,9 @@ ath11k_mac_op_set_bitrate_mask(struct ieee80211_hw *hw, } mutex_lock(&ar->conf_mutex); - ieee80211_iterate_stations_atomic(ar->hw, - ath11k_mac_disable_peer_fixed_rate, - arvif); + ieee80211_iterate_stations_mtx(ar->hw, + ath11k_mac_disable_peer_fixed_rate, + arvif); arvif->bitrate_mask = *mask; ieee80211_iterate_stations_atomic(ar->hw, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 168/480] drm/amdgpu/gfx9: fix kiq locking in KCQ reset 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (166 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 167/480] wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask() Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 169/480] drm/amdgpu/gfx9.4.3: " Greg Kroah-Hartman ` (323 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Christian König, Alex Deucher, Jiadong Zhu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Alex Deucher <alexander.deucher@amd.com> [ Upstream commit 730ea5074dac1b105717316be5d9c18b09829385 ] The ring test needs to be inside the lock. Fixes: fdbd69486b46 ("drm/amdgpu/gfx9: wait for reset done before remap") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Jiadong Zhu <Jiadong.Zhu@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c index d725e2e230a3..59ea6e88bd9e 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c @@ -7299,8 +7299,8 @@ static int gfx_v9_0_reset_kcq(struct amdgpu_ring *ring, } kiq->pmf->kiq_map_queues(kiq_ring, ring); amdgpu_ring_commit(kiq_ring); - spin_unlock_irqrestore(&kiq->ring_lock, flags); r = amdgpu_ring_test_ring(kiq_ring); + spin_unlock_irqrestore(&kiq->ring_lock, flags); if (r) { DRM_ERROR("fail to remap queue\n"); return r; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 169/480] drm/amdgpu/gfx9.4.3: fix kiq locking in KCQ reset 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (167 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 168/480] drm/amdgpu/gfx9: fix kiq locking in KCQ reset Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 170/480] drm/amdgpu/gfx10: " Greg Kroah-Hartman ` (322 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Christian König, Alex Deucher, Jiadong Zhu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Alex Deucher <alexander.deucher@amd.com> [ Upstream commit 08f116c59310728ea8b7e9dc3086569006c861cf ] The ring test needs to be inside the lock. Fixes: 4c953e53cc34 ("drm/amdgpu/gfx_9.4.3: wait for reset done before remap") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Jiadong Zhu <Jiadong.Zhu@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c b/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c index 53fbf6ca7cdb..c386b2f4cbcc 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c @@ -3572,9 +3572,8 @@ static int gfx_v9_4_3_reset_kcq(struct amdgpu_ring *ring, } kiq->pmf->kiq_map_queues(kiq_ring, ring); amdgpu_ring_commit(kiq_ring); - spin_unlock_irqrestore(&kiq->ring_lock, flags); - r = amdgpu_ring_test_ring(kiq_ring); + spin_unlock_irqrestore(&kiq->ring_lock, flags); if (r) { dev_err(adev->dev, "fail to remap queue\n"); return r; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 170/480] drm/amdgpu/gfx10: fix kiq locking in KCQ reset 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (168 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 169/480] drm/amdgpu/gfx9.4.3: " Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 171/480] selftests/bpf: fix implementation of smp_mb() Greg Kroah-Hartman ` (321 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Christian König, Alex Deucher, Jiadong Zhu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Alex Deucher <alexander.deucher@amd.com> [ Upstream commit a4b2ba8f631d3e44b30b9b46ee290fbfe608b7d0 ] The ring test needs to be inside the lock. Fixes: 097af47d3cfb ("drm/amdgpu/gfx10: wait for reset done before remap") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Jiadong Zhu <Jiadong.Zhu@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c index 2144d124c910..cd4605362a93 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c @@ -9567,9 +9567,8 @@ static int gfx_v10_0_reset_kcq(struct amdgpu_ring *ring, kiq->pmf->kiq_unmap_queues(kiq_ring, ring, RESET_QUEUES, 0, 0); amdgpu_ring_commit(kiq_ring); - spin_unlock_irqrestore(&kiq->ring_lock, flags); - r = amdgpu_ring_test_ring(kiq_ring); + spin_unlock_irqrestore(&kiq->ring_lock, flags); if (r) return r; @@ -9605,9 +9604,8 @@ static int gfx_v10_0_reset_kcq(struct amdgpu_ring *ring, } kiq->pmf->kiq_map_queues(kiq_ring, ring); amdgpu_ring_commit(kiq_ring); - spin_unlock_irqrestore(&kiq->ring_lock, flags); - r = amdgpu_ring_test_ring(kiq_ring); + spin_unlock_irqrestore(&kiq->ring_lock, flags); if (r) return r; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 171/480] selftests/bpf: fix implementation of smp_mb() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (169 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 170/480] drm/amdgpu/gfx10: " Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 172/480] iommu/amd: Fix geometry.aperture_end for V2 tables Greg Kroah-Hartman ` (320 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Puranjay Mohan, Alexei Starovoitov, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Puranjay Mohan <puranjay@kernel.org> [ Upstream commit 0769857a07b4451a1dc1c3ad1f1c86a6f4ce136a ] As BPF doesn't include any barrier instructions, smp_mb() is implemented by doing a dummy value returning atomic operation. Such an operation acts a full barrier as enforced by LKMM and also by the work in progress BPF memory model. If the returned value is not used, clang[1] can optimize the value returning atomic instruction in to a normal atomic instruction which provides no ordering guarantees. Mark the variable as volatile so the above optimization is never performed and smp_mb() works as expected. [1] https://godbolt.org/z/qzze7bG6z Fixes: 88d706ba7cc5 ("selftests/bpf: Introduce arena spin lock") Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Link: https://lore.kernel.org/r/20250710175434.18829-2-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/testing/selftests/bpf/bpf_atomic.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/bpf/bpf_atomic.h b/tools/testing/selftests/bpf/bpf_atomic.h index a9674e544322..c550e5711967 100644 --- a/tools/testing/selftests/bpf/bpf_atomic.h +++ b/tools/testing/selftests/bpf/bpf_atomic.h @@ -61,7 +61,7 @@ extern bool CONFIG_X86_64 __kconfig __weak; #define smp_mb() \ ({ \ - unsigned long __val; \ + volatile unsigned long __val; \ __sync_fetch_and_add(&__val, 0); \ }) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 172/480] iommu/amd: Fix geometry.aperture_end for V2 tables 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (170 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 171/480] selftests/bpf: fix implementation of smp_mb() Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 173/480] rcu: Fix delayed execution of hurry callbacks Greg Kroah-Hartman ` (319 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Jason Gunthorpe, Vasant Hegde, Lu Baolu, Will Deacon, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jason Gunthorpe <jgg@nvidia.com> [ Upstream commit 8637afa79cfa6123f602408cfafe8c9a73620ff1 ] The AMD IOMMU documentation seems pretty clear that the V2 table follows the normal CPU expectation of sign extension. This is shown in Figure 25: AMD64 Long Mode 4-Kbyte Page Address Translation Where bits Sign-Extend [63:57] == [56]. This is typical for x86 which would have three regions in the page table: lower, non-canonical, upper. The manual describes that the V1 table does not sign extend in section 2.2.4 Sharing AMD64 Processor and IOMMU Page Tables GPA-to-SPA Further, Vasant has checked this and indicates the HW has an addtional behavior that the manual does not yet describe. The AMDv2 table does not have the sign extended behavior when attached to PASID 0, which may explain why this has gone unnoticed. The iommu domain geometry does not directly support sign extended page tables. The driver should report only one of the lower/upper spaces. Solve this by removing the top VA bit from the geometry to use only the lower space. This will also make the iommu_domain work consistently on all PASID 0 and PASID != 1. Adjust dma_max_address() to remove the top VA bit. It now returns: 5 Level: Before 0x1ffffffffffffff After 0x0ffffffffffffff 4 Level: Before 0xffffffffffff After 0x7fffffffffff Fixes: 11c439a19466 ("iommu/amd/pgtbl_v2: Fix domain max address") Link: https://lore.kernel.org/all/8858d4d6-d360-4ef0-935c-bfd13ea54f42@amd.com/ Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/0-v2-0615cc99b88a+1ce-amdv2_geo_jgg@nvidia.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/iommu/amd/iommu.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c index cef1d2400d47..aafe94568e44 100644 --- a/drivers/iommu/amd/iommu.c +++ b/drivers/iommu/amd/iommu.c @@ -2526,8 +2526,21 @@ static inline u64 dma_max_address(enum protection_domain_mode pgtable) if (pgtable == PD_MODE_V1) return ~0ULL; - /* V2 with 4/5 level page table */ - return ((1ULL << PM_LEVEL_SHIFT(amd_iommu_gpt_level)) - 1); + /* + * V2 with 4/5 level page table. Note that "2.2.6.5 AMD64 4-Kbyte Page + * Translation" shows that the V2 table sign extends the top of the + * address space creating a reserved region in the middle of the + * translation, just like the CPU does. Further Vasant says the docs are + * incomplete and this only applies to non-zero PASIDs. If the AMDv2 + * page table is assigned to the 0 PASID then there is no sign extension + * check. + * + * Since the IOMMU must have a fixed geometry, and the core code does + * not understand sign extended addressing, we have to chop off the high + * bit to get consistent behavior with attachments of the domain to any + * PASID. + */ + return ((1ULL << (PM_LEVEL_SHIFT(amd_iommu_gpt_level) - 1)) - 1); } static bool amd_iommu_hd_support(struct amd_iommu *iommu) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 173/480] rcu: Fix delayed execution of hurry callbacks 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (171 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 172/480] iommu/amd: Fix geometry.aperture_end for V2 tables Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 174/480] wifi: mac80211: reject TDLS operations when station is not associated Greg Kroah-Hartman ` (318 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Cheng-jui Wang, Lorry.Luo, weiyangyang, Tze-nan Wu, Frederic Weisbecker, Neeraj Upadhyay (AMD), Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Tze-nan Wu <Tze-nan.Wu@mediatek.com> [ Upstream commit 463d46044f04013306a4893242f65788b8a16b2e ] We observed a regression in our customer’s environment after enabling CONFIG_LAZY_RCU. In the Android Update Engine scenario, where ioctl() is used heavily, we found that callbacks queued via call_rcu_hurry (such as percpu_ref_switch_to_atomic_rcu) can sometimes be delayed by up to 5 seconds before execution. This occurs because the new grace period does not start immediately after the previous one completes. The root cause is that the wake_nocb_gp_defer() function now checks "rdp->nocb_defer_wakeup" instead of "rdp_gp->nocb_defer_wakeup". On CPUs that are not rcuog, "rdp->nocb_defer_wakeup" may always be RCU_NOCB_WAKE_NOT. This can cause "rdp_gp->nocb_defer_wakeup" to be downgraded and the "rdp_gp->nocb_timer" to be postponed by up to 10 seconds, delaying the execution of hurry RCU callbacks. The trace log of one scenario we encountered is as follow: // previous GP ends at this point rcu_preempt [000] d..1. 137.240210: rcu_grace_period: rcu_preempt 8369 end rcu_preempt [000] ..... 137.240212: rcu_grace_period: rcu_preempt 8372 reqwait // call_rcu_hurry enqueues "percpu_ref_switch_to_atomic_rcu", the callback waited on by UpdateEngine update_engine [002] d..1. 137.301593: __call_rcu_common: wyy: unlikely p_ref = 00000000********. lazy = 0 // FirstQ on cpu 2 rdp_gp->nocb_timer is set to fire after 1 jiffy (4ms) // and the rdp_gp->nocb_defer_wakeup is set to RCU_NOCB_WAKE update_engine [002] d..2. 137.301595: rcu_nocb_wake: rcu_preempt 2 FirstQ on cpu2 with rdp_gp (cpu0). // FirstBQ event on cpu2 during the 1 jiffy, make the timer postpond 10 seconds later. // also, the rdp_gp->nocb_defer_wakeup is overwrite to RCU_NOCB_WAKE_LAZY update_engine [002] d..1. 137.301601: rcu_nocb_wake: rcu_preempt 2 WakeEmptyIsDeferred ... ... ... // before the 10 seconds timeout, cpu0 received another call_rcu_hurry // reset the timer to jiffies+1 and set the waketype = RCU_NOCB_WAKE. kworker/u32:0 [000] d..2. 142.557564: rcu_nocb_wake: rcu_preempt 0 FirstQ kworker/u32:0 [000] d..1. 142.557576: rcu_nocb_wake: rcu_preempt 0 WakeEmptyIsDeferred kworker/u32:0 [000] d..1. 142.558296: rcu_nocb_wake: rcu_preempt 0 WakeNot kworker/u32:0 [000] d..1. 142.558562: rcu_nocb_wake: rcu_preempt 0 WakeNot // idle(do_nocb_deferred_wakeup) wake rcuog due to waketype == RCU_NOCB_WAKE <idle> [000] d..1. 142.558786: rcu_nocb_wake: rcu_preempt 0 DoWake <idle> [000] dN.1. 142.558839: rcu_nocb_wake: rcu_preempt 0 DeferredWake rcuog/0 [000] ..... 142.558871: rcu_nocb_wake: rcu_preempt 0 EndSleep rcuog/0 [000] ..... 142.558877: rcu_nocb_wake: rcu_preempt 0 Check // finally rcuog request a new GP at this point (5 seconds after the FirstQ event) rcuog/0 [000] d..2. 142.558886: rcu_grace_period: rcu_preempt 8372 newreq rcu_preempt [001] d..1. 142.559458: rcu_grace_period: rcu_preempt 8373 start ... rcu_preempt [000] d..1. 142.564258: rcu_grace_period: rcu_preempt 8373 end rcuop/2 [000] D..1. 142.566337: rcu_batch_start: rcu_preempt CBs=219 bl=10 // the hurry CB is invoked at this point rcuop/2 [000] b.... 142.566352: blk_queue_usage_counter_release: wyy: wakeup. p_ref = 00000000********. This patch changes the condition to check "rdp_gp->nocb_defer_wakeup" in the lazy path. This prevents an already scheduled "rdp_gp->nocb_timer" from being postponed and avoids overwriting "rdp_gp->nocb_defer_wakeup" when it is not RCU_NOCB_WAKE_NOT. Fixes: 3cb278e73be5 ("rcu: Make call_rcu() lazy to save power") Co-developed-by: Cheng-jui Wang <cheng-jui.wang@mediatek.com> Signed-off-by: Cheng-jui Wang <cheng-jui.wang@mediatek.com> Co-developed-by: Lorry.Luo@mediatek.com Signed-off-by: Lorry.Luo@mediatek.com Tested-by: weiyangyang@vivo.com Signed-off-by: weiyangyang@vivo.com Signed-off-by: Tze-nan Wu <Tze-nan.Wu@mediatek.com> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.upadhyay@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- kernel/rcu/tree_nocb.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/rcu/tree_nocb.h b/kernel/rcu/tree_nocb.h index fa269d34167a..6b3118a4dde3 100644 --- a/kernel/rcu/tree_nocb.h +++ b/kernel/rcu/tree_nocb.h @@ -276,7 +276,7 @@ static void wake_nocb_gp_defer(struct rcu_data *rdp, int waketype, * callback storms, no need to wake up too early. */ if (waketype == RCU_NOCB_WAKE_LAZY && - rdp->nocb_defer_wakeup == RCU_NOCB_WAKE_NOT) { + rdp_gp->nocb_defer_wakeup == RCU_NOCB_WAKE_NOT) { mod_timer(&rdp_gp->nocb_timer, jiffies + rcu_get_jiffies_lazy_flush()); WRITE_ONCE(rdp_gp->nocb_defer_wakeup, waketype); } else if (waketype == RCU_NOCB_WAKE_BYPASS) { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 174/480] wifi: mac80211: reject TDLS operations when station is not associated 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (172 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 173/480] rcu: Fix delayed execution of hurry callbacks Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 175/480] wifi: plfxlc: Fix error handling in usb driver probe Greg Kroah-Hartman ` (317 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, syzbot+f73f203f8c9b19037380, Moon Hee Lee, Johannes Berg, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Moon Hee Lee <moonhee.lee.ca@gmail.com> [ Upstream commit 16ecdab5446f15a61ec88eb0d23d25d009821db0 ] syzbot triggered a WARN in ieee80211_tdls_oper() by sending NL80211_TDLS_ENABLE_LINK immediately after NL80211_CMD_CONNECT, before association completed and without prior TDLS setup. This left internal state like sdata->u.mgd.tdls_peer uninitialized, leading to a WARN_ON() in code paths that assumed it was valid. Reject the operation early if not in station mode or not associated. Reported-by: syzbot+f73f203f8c9b19037380@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f73f203f8c9b19037380 Fixes: 81dd2b882241 ("mac80211: move TDLS data to mgd private part") Tested-by: syzbot+f73f203f8c9b19037380@syzkaller.appspotmail.com Signed-off-by: Moon Hee Lee <moonhee.lee.ca@gmail.com> Link: https://patch.msgid.link/20250715230904.661092-2-moonhee.lee.ca@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/mac80211/tdls.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mac80211/tdls.c b/net/mac80211/tdls.c index 2f92e7c7f203..49c92c5d3909 100644 --- a/net/mac80211/tdls.c +++ b/net/mac80211/tdls.c @@ -1422,7 +1422,7 @@ int ieee80211_tdls_oper(struct wiphy *wiphy, struct net_device *dev, if (!(wiphy->flags & WIPHY_FLAG_SUPPORTS_TDLS)) return -EOPNOTSUPP; - if (sdata->vif.type != NL80211_IFTYPE_STATION) + if (sdata->vif.type != NL80211_IFTYPE_STATION || !sdata->vif.cfg.assoc) return -EINVAL; switch (oper) { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 175/480] wifi: plfxlc: Fix error handling in usb driver probe 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (173 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 174/480] wifi: mac80211: reject TDLS operations when station is not associated Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 176/480] wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac() Greg Kroah-Hartman ` (316 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Murad Masimov, Johannes Berg, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Murad Masimov <m.masimov@mt-integration.ru> [ Upstream commit 3fe79a25c3cd54d25d30bc235c0c57f8a123d9d5 ] If probe fails before ieee80211_register_hw() is successfully done, ieee80211_unregister_hw() will be called anyway. This may lead to various bugs as the implementation of ieee80211_unregister_hw() assumes that ieee80211_register_hw() has been called. Divide error handling section into relevant subsections, so that ieee80211_unregister_hw() is called only when it is appropriate. Correct the order of the calls: ieee80211_unregister_hw() should go before plfxlc_mac_release(). Also move ieee80211_free_hw() to plfxlc_mac_release() as it supposed to be the opposite to plfxlc_mac_alloc_hw() that calls ieee80211_alloc_hw(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 68d57a07bfe5 ("wireless: add plfxlc driver for pureLiFi X, XL, XC devices") Signed-off-by: Murad Masimov <m.masimov@mt-integration.ru> Link: https://patch.msgid.link/20250321185226.71-3-m.masimov@mt-integration.ru Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/wireless/purelifi/plfxlc/mac.c | 11 ++++---- drivers/net/wireless/purelifi/plfxlc/mac.h | 2 +- drivers/net/wireless/purelifi/plfxlc/usb.c | 29 +++++++++++----------- 3 files changed, 21 insertions(+), 21 deletions(-) diff --git a/drivers/net/wireless/purelifi/plfxlc/mac.c b/drivers/net/wireless/purelifi/plfxlc/mac.c index 82d1bf7edba2..a7f5d287e369 100644 --- a/drivers/net/wireless/purelifi/plfxlc/mac.c +++ b/drivers/net/wireless/purelifi/plfxlc/mac.c @@ -99,11 +99,6 @@ int plfxlc_mac_init_hw(struct ieee80211_hw *hw) return r; } -void plfxlc_mac_release(struct plfxlc_mac *mac) -{ - plfxlc_chip_release(&mac->chip); -} - int plfxlc_op_start(struct ieee80211_hw *hw) { plfxlc_hw_mac(hw)->chip.usb.initialized = 1; @@ -755,3 +750,9 @@ struct ieee80211_hw *plfxlc_mac_alloc_hw(struct usb_interface *intf) SET_IEEE80211_DEV(hw, &intf->dev); return hw; } + +void plfxlc_mac_release_hw(struct ieee80211_hw *hw) +{ + plfxlc_chip_release(&plfxlc_hw_mac(hw)->chip); + ieee80211_free_hw(hw); +} diff --git a/drivers/net/wireless/purelifi/plfxlc/mac.h b/drivers/net/wireless/purelifi/plfxlc/mac.h index 9384acddcf26..56da502999c1 100644 --- a/drivers/net/wireless/purelifi/plfxlc/mac.h +++ b/drivers/net/wireless/purelifi/plfxlc/mac.h @@ -168,7 +168,7 @@ static inline u8 *plfxlc_mac_get_perm_addr(struct plfxlc_mac *mac) } struct ieee80211_hw *plfxlc_mac_alloc_hw(struct usb_interface *intf); -void plfxlc_mac_release(struct plfxlc_mac *mac); +void plfxlc_mac_release_hw(struct ieee80211_hw *hw); int plfxlc_mac_preinit_hw(struct ieee80211_hw *hw, const u8 *hw_address); int plfxlc_mac_init_hw(struct ieee80211_hw *hw); diff --git a/drivers/net/wireless/purelifi/plfxlc/usb.c b/drivers/net/wireless/purelifi/plfxlc/usb.c index c2a1234b59db..0817506021c3 100644 --- a/drivers/net/wireless/purelifi/plfxlc/usb.c +++ b/drivers/net/wireless/purelifi/plfxlc/usb.c @@ -604,7 +604,7 @@ static int probe(struct usb_interface *intf, r = plfxlc_upload_mac_and_serial(intf, hw_address, serial_number); if (r) { dev_err(&intf->dev, "MAC and Serial upload failed (%d)\n", r); - goto error; + goto error_free_hw; } chip->unit_type = STA; @@ -613,13 +613,13 @@ static int probe(struct usb_interface *intf, r = plfxlc_mac_preinit_hw(hw, hw_address); if (r) { dev_err(&intf->dev, "Init mac failed (%d)\n", r); - goto error; + goto error_free_hw; } r = ieee80211_register_hw(hw); if (r) { dev_err(&intf->dev, "Register device failed (%d)\n", r); - goto error; + goto error_free_hw; } if ((le16_to_cpu(interface_to_usbdev(intf)->descriptor.idVendor) == @@ -632,7 +632,7 @@ static int probe(struct usb_interface *intf, } if (r != 0) { dev_err(&intf->dev, "FPGA download failed (%d)\n", r); - goto error; + goto error_unreg_hw; } tx->mac_fifo_full = 0; @@ -642,21 +642,21 @@ static int probe(struct usb_interface *intf, r = plfxlc_usb_init_hw(usb); if (r < 0) { dev_err(&intf->dev, "usb_init_hw failed (%d)\n", r); - goto error; + goto error_unreg_hw; } msleep(PLF_MSLEEP_TIME); r = plfxlc_chip_switch_radio(chip, PLFXLC_RADIO_ON); if (r < 0) { dev_dbg(&intf->dev, "chip_switch_radio_on failed (%d)\n", r); - goto error; + goto error_unreg_hw; } msleep(PLF_MSLEEP_TIME); r = plfxlc_chip_set_rate(chip, 8); if (r < 0) { dev_dbg(&intf->dev, "chip_set_rate failed (%d)\n", r); - goto error; + goto error_unreg_hw; } msleep(PLF_MSLEEP_TIME); @@ -664,7 +664,7 @@ static int probe(struct usb_interface *intf, hw_address, ETH_ALEN, USB_REQ_MAC_WR); if (r < 0) { dev_dbg(&intf->dev, "MAC_WR failure (%d)\n", r); - goto error; + goto error_unreg_hw; } plfxlc_chip_enable_rxtx(chip); @@ -691,12 +691,12 @@ static int probe(struct usb_interface *intf, plfxlc_mac_init_hw(hw); usb->initialized = true; return 0; + +error_unreg_hw: + ieee80211_unregister_hw(hw); +error_free_hw: + plfxlc_mac_release_hw(hw); error: - if (hw) { - plfxlc_mac_release(plfxlc_hw_mac(hw)); - ieee80211_unregister_hw(hw); - ieee80211_free_hw(hw); - } dev_err(&intf->dev, "pureLifi:Device error"); return r; } @@ -730,8 +730,7 @@ static void disconnect(struct usb_interface *intf) */ usb_reset_device(interface_to_usbdev(intf)); - plfxlc_mac_release(mac); - ieee80211_free_hw(hw); + plfxlc_mac_release_hw(hw); } static void plfxlc_usb_resume(struct plfxlc_usb *usb) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 176/480] wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (174 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 175/480] wifi: plfxlc: Fix error handling in usb driver probe Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 177/480] wifi: mac80211: Do not schedule stopped TXQs Greg Kroah-Hartman ` (315 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Alexander Wetzel, Johannes Berg, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Alexander Wetzel <Alexander@wetzel-home.de> [ Upstream commit 2c5dee15239f3f3e31aa5c8808f18996c039e2c1 ] Callers of wdev_chandef() must hold the wiphy mutex. But the worker cfg80211_propagate_cac_done_wk() never takes the lock. Which triggers the warning below with the mesh_peer_connected_dfs test from hostapd and not (yet) released mac80211 code changes: WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165 Modules linked in: CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf Workqueue: cfg80211 cfg80211_propagate_cac_done_wk Stack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000 Call Trace: [<6002ec30>] ? _printk+0x0/0x98 [<6003c2b3>] show_stack+0x10e/0x11a [<6002ec30>] ? _printk+0x0/0x98 [<60037608>] dump_stack_lvl+0x71/0xb8 [<6063717b>] ? wdev_chandef+0x60/0x165 [<6003766d>] dump_stack+0x1e/0x20 [<6005d1b7>] __warn+0x101/0x20f [<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d [<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<600b11a2>] ? mark_held_locks+0x5a/0x6e [<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d [<60052e53>] ? unblock_signals+0x3a/0xe7 [<60052f2d>] ? um_set_signals+0x2d/0x43 [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<607508b2>] ? lock_is_held_type+0x207/0x21f [<6063717b>] wdev_chandef+0x60/0x165 [<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f [<60052f00>] ? um_set_signals+0x0/0x43 [<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a [<6007e460>] process_scheduled_works+0x3bc/0x60e [<6007d0ec>] ? move_linked_works+0x4d/0x81 [<6007d120>] ? assign_work+0x0/0xaa [<6007f81f>] worker_thread+0x220/0x2dc [<600786ef>] ? set_pf_worker+0x0/0x57 [<60087c96>] ? to_kthread+0x0/0x43 [<6008ab3c>] kthread+0x2d3/0x2e2 [<6007f5ff>] ? worker_thread+0x0/0x2dc [<6006c05b>] ? calculate_sigpending+0x0/0x56 [<6003b37d>] new_thread_handler+0x4a/0x64 irq event stamp: 614611 hardirqs last enabled at (614621): [<00000000600bc96b>] __up_console_sem+0x82/0xaf hardirqs last disabled at (614630): [<00000000600bc92c>] __up_console_sem+0x43/0xaf softirqs last enabled at (614268): [<00000000606c55c6>] __ieee80211_wake_queue+0x933/0x985 softirqs last disabled at (614266): [<00000000606c52d6>] __ieee80211_wake_queue+0x643/0x985 Fixes: 26ec17a1dc5e ("cfg80211: Fix radar event during another phy CAC") Signed-off-by: Alexander Wetzel <Alexander@wetzel-home.de> Link: https://patch.msgid.link/20250717162547.94582-1-Alexander@wetzel-home.de Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/wireless/reg.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/wireless/reg.c b/net/wireless/reg.c index c1752b31734f..92e04370fa63 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -4229,6 +4229,8 @@ static void cfg80211_check_and_end_cac(struct cfg80211_registered_device *rdev) struct wireless_dev *wdev; unsigned int link_id; + guard(wiphy)(&rdev->wiphy); + /* If we finished CAC or received radar, we should end any * CAC running on the same channels. * the check !cfg80211_chandef_dfs_usable contain 2 options: -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 177/480] wifi: mac80211: Do not schedule stopped TXQs 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (175 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 176/480] wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac() Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 178/480] wifi: mac80211: Dont call fq_flow_idx() for management frames Greg Kroah-Hartman ` (314 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Alexander Wetzel, Johannes Berg, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Alexander Wetzel <Alexander@wetzel-home.de> [ Upstream commit 11e3e22fa533f5d7cf04e32343b05a27eda3c7a5 ] Ignore TXQs with the flag IEEE80211_TXQ_STOP when scheduling a queue. The flag is only set after all fragments have been dequeued and won't allow dequeueing other frames as long as the flag is set. For drivers using ieee80211_txq_schedule_start() this prevents an loop trying to push the queued frames while IEEE80211_TXQ_STOP is set: After setting IEEE80211_TXQ_STOP the driver will call ieee80211_return_txq(). Which calls __ieee80211_schedule_txq(), detects that there sill are frames in the queue and immediately restarts the stopped TXQ. Which can't dequeue any frame and thus starts over the loop. Signed-off-by: Alexander Wetzel <Alexander@wetzel-home.de> Fixes: ba8c3d6f16a1 ("mac80211: add an intermediate software queue implementation") Link: https://patch.msgid.link/20250717162547.94582-2-Alexander@wetzel-home.de Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/mac80211/tx.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index 695db38ccfb4..fd21a18a028d 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -4109,7 +4109,9 @@ void __ieee80211_schedule_txq(struct ieee80211_hw *hw, spin_lock_bh(&local->active_txq_lock[txq->ac]); - has_queue = force || txq_has_queue(txq); + has_queue = force || + (!test_bit(IEEE80211_TXQ_STOP, &txqi->flags) && + txq_has_queue(txq)); if (list_empty(&txqi->schedule_order) && (has_queue || ieee80211_txq_keep_active(txqi))) { /* If airtime accounting is active, always enqueue STAs at the -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 178/480] wifi: mac80211: Dont call fq_flow_idx() for management frames 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (176 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 177/480] wifi: mac80211: Do not schedule stopped TXQs Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 179/480] wifi: mac80211: Check 802.11 encaps offloading in ieee80211_tx_h_select_key() Greg Kroah-Hartman ` (313 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Alexander Wetzel, Johannes Berg, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Alexander Wetzel <Alexander@wetzel-home.de> [ Upstream commit cb3bb3d88dfcd177a1050c0a009a3ee147b2e5b9 ] skb_get_hash() can only be used when the skb is linked to a netdev device. Signed-off-by: Alexander Wetzel <Alexander@wetzel-home.de> Fixes: 73bc9e0af594 ("mac80211: don't apply flow control on management frames") Link: https://patch.msgid.link/20250717162547.94582-3-Alexander@wetzel-home.de Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/mac80211/tx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index fd21a18a028d..10e5fb294709 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -1438,7 +1438,7 @@ static void ieee80211_txq_enqueue(struct ieee80211_local *local, { struct fq *fq = &local->fq; struct fq_tin *tin = &txqi->tin; - u32 flow_idx = fq_flow_idx(fq, skb); + u32 flow_idx; ieee80211_set_skb_enqueue_time(skb); @@ -1454,6 +1454,7 @@ static void ieee80211_txq_enqueue(struct ieee80211_local *local, IEEE80211_TX_INTCFL_NEED_TXPROCESSING; __skb_queue_tail(&txqi->frags, skb); } else { + flow_idx = fq_flow_idx(fq, skb); fq_tin_enqueue(fq, tin, flow_idx, skb, fq_skb_free_func); } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 179/480] wifi: mac80211: Check 802.11 encaps offloading in ieee80211_tx_h_select_key() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (177 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 178/480] wifi: mac80211: Dont call fq_flow_idx() for management frames Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 180/480] Reapply "wifi: mac80211: Update skbs control block key in ieee80211_tx_dequeue()" Greg Kroah-Hartman ` (312 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Bert Karwatzki, Remi Pommarel, Johannes Berg, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Remi Pommarel <repk@triplefau.lt> [ Upstream commit 4037c468d1b3c508d69e6df0ef47fdee3d440e39 ] With 802.11 encapsulation offloading, ieee80211_tx_h_select_key() is called on 802.3 frames. In that case do not try to use skb data as valid 802.11 headers. Reported-by: Bert Karwatzki <spasswolf@web.de> Closes: https://lore.kernel.org/linux-wireless/20250410215527.3001-1-spasswolf@web.de Fixes: bb42f2d13ffc ("mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue") Signed-off-by: Remi Pommarel <repk@triplefau.lt> Link: https://patch.msgid.link/1af4b5b903a5fca5ebe67333d5854f93b2be5abe.1752765971.git.repk@triplefau.lt Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/mac80211/tx.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index 10e5fb294709..7799455b0403 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -622,6 +622,12 @@ ieee80211_tx_h_select_key(struct ieee80211_tx_data *tx) else tx->key = NULL; + if (info->flags & IEEE80211_TX_CTL_HW_80211_ENCAP) { + if (tx->key && tx->key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE) + info->control.hw_key = &tx->key->conf; + return TX_CONTINUE; + } + if (tx->key) { bool skip_hw = false; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 180/480] Reapply "wifi: mac80211: Update skbs control block key in ieee80211_tx_dequeue()" 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (178 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 179/480] wifi: mac80211: Check 802.11 encaps offloading in ieee80211_tx_h_select_key() Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 181/480] wifi: ath12k: fix endianness handling while accessing wmi service bit Greg Kroah-Hartman ` (311 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Remi Pommarel, Johannes Berg, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Remi Pommarel <repk@triplefau.lt> [ Upstream commit 754fe848b3b297fc85ec24cd959bad22b6df8cb8 ] This reverts commit 0937cb5f345c ("Revert "wifi: mac80211: Update skb's control block key in ieee80211_tx_dequeue()""). This commit broke TX with 802.11 encapsulation HW offloading, now that this is fixed, reapply it. Fixes: bb42f2d13ffc ("mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue") Signed-off-by: Remi Pommarel <repk@triplefau.lt> Link: https://patch.msgid.link/66b8fc39fb0194fa06c9ca7eeb6ffe0118dcb3ec.1752765971.git.repk@triplefau.lt Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/mac80211/tx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index 7799455b0403..506523803cc0 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -3894,6 +3894,7 @@ struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw, * The key can be removed while the packet was queued, so need to call * this here to get the current key. */ + info->control.hw_key = NULL; r = ieee80211_tx_h_select_key(&tx); if (r != TX_CONTINUE) { ieee80211_free_txskb(&local->hw, skb); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 181/480] wifi: ath12k: fix endianness handling while accessing wmi service bit 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (179 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 180/480] Reapply "wifi: mac80211: Update skbs control block key in ieee80211_tx_dequeue()" Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 182/480] wifi: brcmfmac: fix P2P discovery failure in P2P peer due to missing P2P IE Greg Kroah-Hartman ` (310 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Tamizh Chelvam Raja, Vasanthakumar Thiagarajan, Jeff Johnson, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com> [ Upstream commit 8f1a078842d4af4877fb686f3907788024d0d1b7 ] Currently there is no endian conversion in ath12k_wmi_tlv_services_parser() so the service bit parsing will be incorrect on a big endian platform and to fix this by using appropriate endian conversion. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00217-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: 342527f35338 ("wifi: ath12k: Add support to parse new WMI event for 6 GHz regulatory") Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250717173539.2523396-2-tamizh.raja@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/wireless/ath/ath12k/wmi.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c index f021498e5278..9ebe4b573f7e 100644 --- a/drivers/net/wireless/ath/ath12k/wmi.c +++ b/drivers/net/wireless/ath/ath12k/wmi.c @@ -6829,7 +6829,7 @@ static int ath12k_wmi_tlv_services_parser(struct ath12k_base *ab, void *data) { const struct wmi_service_available_event *ev; - u32 *wmi_ext2_service_bitmap; + __le32 *wmi_ext2_service_bitmap; int i, j; u16 expected_len; @@ -6861,12 +6861,12 @@ static int ath12k_wmi_tlv_services_parser(struct ath12k_base *ab, ev->wmi_service_segment_bitmap[3]); break; case WMI_TAG_ARRAY_UINT32: - wmi_ext2_service_bitmap = (u32 *)ptr; + wmi_ext2_service_bitmap = (__le32 *)ptr; for (i = 0, j = WMI_MAX_EXT_SERVICE; i < WMI_SERVICE_SEGMENT_BM_SIZE32 && j < WMI_MAX_EXT2_SERVICE; i++) { do { - if (wmi_ext2_service_bitmap[i] & + if (__le32_to_cpu(wmi_ext2_service_bitmap[i]) & BIT(j % WMI_AVAIL_SERVICE_BITS_IN_SIZE32)) set_bit(j, ab->wmi_ab.svc_map); } while (++j % WMI_AVAIL_SERVICE_BITS_IN_SIZE32); @@ -6874,8 +6874,10 @@ static int ath12k_wmi_tlv_services_parser(struct ath12k_base *ab, ath12k_dbg(ab, ATH12K_DBG_WMI, "wmi_ext2_service_bitmap 0x%04x 0x%04x 0x%04x 0x%04x", - wmi_ext2_service_bitmap[0], wmi_ext2_service_bitmap[1], - wmi_ext2_service_bitmap[2], wmi_ext2_service_bitmap[3]); + __le32_to_cpu(wmi_ext2_service_bitmap[0]), + __le32_to_cpu(wmi_ext2_service_bitmap[1]), + __le32_to_cpu(wmi_ext2_service_bitmap[2]), + __le32_to_cpu(wmi_ext2_service_bitmap[3])); break; } return 0; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 182/480] wifi: brcmfmac: fix P2P discovery failure in P2P peer due to missing P2P IE 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (180 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 181/480] wifi: ath12k: fix endianness handling while accessing wmi service bit Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 183/480] PM: cpufreq: powernv/tracing: Move powernv_throttle trace event Greg Kroah-Hartman ` (309 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Gokul Sivakumar, Arend van Spriel, Johannes Berg, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Gokul Sivakumar <gokulkumar.sivakumar@infineon.com> [ Upstream commit 579bf8037b70b644a674c126a32bbb2212cf5c21 ] After commit bd99a3013bdc ("brcmfmac: move configuration of probe request IEs"), the probe request MGMT IE addition operation brcmf_vif_set_mgmt_ie() got moved from the brcmf_p2p_scan_prep() to the brcmf_cfg80211_scan(). Because of this, as part of the scan request handler for the P2P Discovery, vif struct used for adding the Probe Request P2P IE in firmware got changed from the P2PAPI_BSSCFG_DEVICE vif to P2PAPI_BSSCFG_PRIMARY vif incorrectly. So the firmware stopped adding P2P IE to the outgoing P2P Discovery probe requests frames and the other P2P peers were unable to discover this device causing a regression on the P2P feature. To fix this, while setting the P2P IE in firmware, properly use the vif of the P2P discovery wdev on which the driver received the P2P scan request. This is done by not changing the vif pointer, until brcmf_vif_set_mgmt_ie() is completed. Fixes: bd99a3013bdc ("brcmfmac: move configuration of probe request IEs") Signed-off-by: Gokul Sivakumar <gokulkumar.sivakumar@infineon.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20250626050706.7271-1-gokulkumar.sivakumar@infineon.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- .../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c index 4b70845e1a26..075b99478e65 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c @@ -1545,10 +1545,6 @@ brcmf_cfg80211_scan(struct wiphy *wiphy, struct cfg80211_scan_request *request) return -EAGAIN; } - /* If scan req comes for p2p0, send it over primary I/F */ - if (vif == cfg->p2p.bss_idx[P2PAPI_BSSCFG_DEVICE].vif) - vif = cfg->p2p.bss_idx[P2PAPI_BSSCFG_PRIMARY].vif; - brcmf_dbg(SCAN, "START ESCAN\n"); cfg->scan_request = request; @@ -1564,6 +1560,10 @@ brcmf_cfg80211_scan(struct wiphy *wiphy, struct cfg80211_scan_request *request) if (err) goto scan_out; + /* If scan req comes for p2p0, send it over primary I/F */ + if (vif == cfg->p2p.bss_idx[P2PAPI_BSSCFG_DEVICE].vif) + vif = cfg->p2p.bss_idx[P2PAPI_BSSCFG_PRIMARY].vif; + err = brcmf_do_escan(vif->ifp, request); if (err) goto scan_out; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 183/480] PM: cpufreq: powernv/tracing: Move powernv_throttle trace event 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (181 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 182/480] wifi: brcmfmac: fix P2P discovery failure in P2P peer due to missing P2P IE Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 184/480] wifi: mac80211: Write cnt before copying in ieee80211_copy_rnr_beacon() Greg Kroah-Hartman ` (308 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton, Madhavan Srinivasan, Michael Ellerman, Viresh Kumar, Rafael J. Wysocki, Steven Rostedt (Google), Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Steven Rostedt <rostedt@goodmis.org> [ Upstream commit 647fe16b46999258ce1aec41f4bdeabb4f0cc8e7 ] As the trace event powernv_throttle is only used by the powernv code, move it to a separate include file and have that code directly enable it. Trace events can take up around 5K of memory when they are defined regardless if they are used or not. It wastes memory to have them defined in configurations where the tracepoint is not used. Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Madhavan Srinivasan <maddy@linux.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/20250612145407.906308844@goodmis.org Fixes: 0306e481d479a ("cpufreq: powernv/tracing: Add powernv_throttle tracepoint") Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/cpufreq/Makefile | 1 + drivers/cpufreq/powernv-cpufreq.c | 4 ++- drivers/cpufreq/powernv-trace.h | 44 +++++++++++++++++++++++++++++++ include/trace/events/power.h | 22 ---------------- kernel/trace/power-traces.c | 1 - 5 files changed, 48 insertions(+), 24 deletions(-) create mode 100644 drivers/cpufreq/powernv-trace.h diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile index 22ab45209f9b..246f58b496da 100644 --- a/drivers/cpufreq/Makefile +++ b/drivers/cpufreq/Makefile @@ -20,6 +20,7 @@ obj-$(CONFIG_CPUFREQ_VIRT) += virtual-cpufreq.o # Traces CFLAGS_amd-pstate-trace.o := -I$(src) +CFLAGS_powernv-cpufreq.o := -I$(src) amd_pstate-y := amd-pstate.o amd-pstate-trace.o ################################################################################## diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c index afe5abf89d33..b7c3251e7e87 100644 --- a/drivers/cpufreq/powernv-cpufreq.c +++ b/drivers/cpufreq/powernv-cpufreq.c @@ -21,7 +21,6 @@ #include <linux/string_choices.h> #include <linux/cpu.h> #include <linux/hashtable.h> -#include <trace/events/power.h> #include <asm/cputhreads.h> #include <asm/firmware.h> @@ -30,6 +29,9 @@ #include <asm/opal.h> #include <linux/timer.h> +#define CREATE_TRACE_POINTS +#include "powernv-trace.h" + #define POWERNV_MAX_PSTATES_ORDER 8 #define POWERNV_MAX_PSTATES (1UL << (POWERNV_MAX_PSTATES_ORDER)) #define PMSR_PSAFE_ENABLE (1UL << 30) diff --git a/drivers/cpufreq/powernv-trace.h b/drivers/cpufreq/powernv-trace.h new file mode 100644 index 000000000000..8cadb7c9427b --- /dev/null +++ b/drivers/cpufreq/powernv-trace.h @@ -0,0 +1,44 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#if !defined(_POWERNV_TRACE_H) || defined(TRACE_HEADER_MULTI_READ) +#define _POWERNV_TRACE_H + +#include <linux/cpufreq.h> +#include <linux/tracepoint.h> +#include <linux/trace_events.h> + +#undef TRACE_SYSTEM +#define TRACE_SYSTEM power + +TRACE_EVENT(powernv_throttle, + + TP_PROTO(int chip_id, const char *reason, int pmax), + + TP_ARGS(chip_id, reason, pmax), + + TP_STRUCT__entry( + __field(int, chip_id) + __string(reason, reason) + __field(int, pmax) + ), + + TP_fast_assign( + __entry->chip_id = chip_id; + __assign_str(reason); + __entry->pmax = pmax; + ), + + TP_printk("Chip %d Pmax %d %s", __entry->chip_id, + __entry->pmax, __get_str(reason)) +); + +#endif /* _POWERNV_TRACE_H */ + +/* This part must be outside protection */ +#undef TRACE_INCLUDE_PATH +#define TRACE_INCLUDE_PATH . + +#undef TRACE_INCLUDE_FILE +#define TRACE_INCLUDE_FILE powernv-trace + +#include <trace/define_trace.h> diff --git a/include/trace/events/power.h b/include/trace/events/power.h index 9253e83b9bb4..ff0974e9be9a 100644 --- a/include/trace/events/power.h +++ b/include/trace/events/power.h @@ -99,28 +99,6 @@ DEFINE_EVENT(psci_domain_idle, psci_domain_idle_exit, TP_ARGS(cpu_id, state, s2idle) ); -TRACE_EVENT(powernv_throttle, - - TP_PROTO(int chip_id, const char *reason, int pmax), - - TP_ARGS(chip_id, reason, pmax), - - TP_STRUCT__entry( - __field(int, chip_id) - __string(reason, reason) - __field(int, pmax) - ), - - TP_fast_assign( - __entry->chip_id = chip_id; - __assign_str(reason); - __entry->pmax = pmax; - ), - - TP_printk("Chip %d Pmax %d %s", __entry->chip_id, - __entry->pmax, __get_str(reason)) -); - TRACE_EVENT(pstate_sample, TP_PROTO(u32 core_busy, diff --git a/kernel/trace/power-traces.c b/kernel/trace/power-traces.c index 21bb161c2316..f2fe33573e54 100644 --- a/kernel/trace/power-traces.c +++ b/kernel/trace/power-traces.c @@ -17,5 +17,4 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(suspend_resume); EXPORT_TRACEPOINT_SYMBOL_GPL(cpu_idle); EXPORT_TRACEPOINT_SYMBOL_GPL(cpu_frequency); -EXPORT_TRACEPOINT_SYMBOL_GPL(powernv_throttle); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 184/480] wifi: mac80211: Write cnt before copying in ieee80211_copy_rnr_beacon() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (182 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 183/480] PM: cpufreq: powernv/tracing: Move powernv_throttle trace event Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 185/480] wifi: nl80211: Set num_sub_specs before looping through sub_specs Greg Kroah-Hartman ` (307 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Kees Cook, Gustavo A. R. Silva, Johannes Berg, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Kees Cook <kees@kernel.org> [ Upstream commit a37192c432adaec9e8ef29e4ddb319ea2f443aa6 ] While I caught the need for setting cnt early in nl80211_parse_rnr_elems() in the original annotation of struct cfg80211_rnr_elems with __counted_by, I missed a similar pattern in ieee80211_copy_rnr_beacon(). Fix this by moving the cnt assignment to before the loop. Fixes: 7b6d7087031b ("wifi: cfg80211: Annotate struct cfg80211_rnr_elems with __counted_by") Signed-off-by: Kees Cook <kees@kernel.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://patch.msgid.link/20250721182521.work.540-kees@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/mac80211/cfg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c index 4a8d9c3ea480..d9f96a962fa6 100644 --- a/net/mac80211/cfg.c +++ b/net/mac80211/cfg.c @@ -1109,13 +1109,13 @@ ieee80211_copy_rnr_beacon(u8 *pos, struct cfg80211_rnr_elems *dst, { int i, offset = 0; + dst->cnt = src->cnt; for (i = 0; i < src->cnt; i++) { memcpy(pos + offset, src->elem[i].data, src->elem[i].len); dst->elem[i].len = src->elem[i].len; dst->elem[i].data = pos + offset; offset += dst->elem[i].len; } - dst->cnt = src->cnt; return offset; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 185/480] wifi: nl80211: Set num_sub_specs before looping through sub_specs 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (183 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 184/480] wifi: mac80211: Write cnt before copying in ieee80211_copy_rnr_beacon() Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 186/480] ring-buffer: Remove ring_buffer_read_prepare_sync() Greg Kroah-Hartman ` (306 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Kees Cook, Gustavo A. R. Silva, Johannes Berg, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Kees Cook <kees@kernel.org> [ Upstream commit 2ed9a9fc9976262109d04f1a3c75c46de8ce4f22 ] The processing of the struct cfg80211_sar_specs::sub_specs flexible array requires its counter, num_sub_specs, to be assigned before the loop in nl80211_set_sar_specs(). Leave the final assignment after the loop in place in case fewer ended up in the array. Fixes: aa4ec06c455d ("wifi: cfg80211: use __counted_by where appropriate") Signed-off-by: Kees Cook <kees@kernel.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://patch.msgid.link/20250721183125.work.183-kees@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/wireless/nl80211.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index 0c7e8389bc49..5b348aefd77d 100644 --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -16892,6 +16892,7 @@ static int nl80211_set_sar_specs(struct sk_buff *skb, struct genl_info *info) if (!sar_spec) return -ENOMEM; + sar_spec->num_sub_specs = specs; sar_spec->type = type; specs = 0; nla_for_each_nested(spec_list, tb[NL80211_SAR_ATTR_SPECS], rem) { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 186/480] ring-buffer: Remove ring_buffer_read_prepare_sync() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (184 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 185/480] wifi: nl80211: Set num_sub_specs before looping through sub_specs Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 187/480] kcsan: test: Initialize dummy variable Greg Kroah-Hartman ` (305 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Mathieu Desnoyers, David Howells, Masami Hiramatsu (Google), Steven Rostedt (Google), Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Steven Rostedt <rostedt@goodmis.org> [ Upstream commit 119a5d573622ae90ba730d18acfae9bb75d77b9a ] When the ring buffer was first introduced, reading the non-consuming "trace" file required disabling the writing of the ring buffer. To make sure the writing was fully disabled before iterating the buffer with a non-consuming read, it would set the disable flag of the buffer and then call an RCU synchronization to make sure all the buffers were synchronized. The function ring_buffer_read_start() originally would initialize the iterator and call an RCU synchronization, but this was for each individual per CPU buffer where this would get called many times on a machine with many CPUs before the trace file could be read. The commit 72c9ddfd4c5bf ("ring-buffer: Make non-consuming read less expensive with lots of cpus.") separated ring_buffer_read_start into ring_buffer_read_prepare(), ring_buffer_read_sync() and then ring_buffer_read_start() to allow each of the per CPU buffers to be prepared, call the read_buffer_read_sync() once, and then the ring_buffer_read_start() for each of the CPUs which made things much faster. The commit 1039221cc278 ("ring-buffer: Do not disable recording when there is an iterator") removed the requirement of disabling the recording of the ring buffer in order to iterate it, but it did not remove the synchronization that was happening that was required to wait for all the buffers to have no more writers. It's now OK for the buffers to have writers and no synchronization is needed. Remove the synchronization and put back the interface for the ring buffer iterator back before commit 72c9ddfd4c5bf was applied. Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Link: https://lore.kernel.org/20250630180440.3eabb514@batman.local.home Reported-by: David Howells <dhowells@redhat.com> Fixes: 1039221cc278 ("ring-buffer: Do not disable recording when there is an iterator") Tested-by: David Howells <dhowells@redhat.com> Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- include/linux/ring_buffer.h | 4 +-- kernel/trace/ring_buffer.c | 63 ++++++------------------------------- kernel/trace/trace.c | 14 +++------ kernel/trace/trace_kdb.c | 8 ++--- 4 files changed, 18 insertions(+), 71 deletions(-) diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h index 56e27263acf8..00e232f3c2e8 100644 --- a/include/linux/ring_buffer.h +++ b/include/linux/ring_buffer.h @@ -152,9 +152,7 @@ ring_buffer_consume(struct trace_buffer *buffer, int cpu, u64 *ts, unsigned long *lost_events); struct ring_buffer_iter * -ring_buffer_read_prepare(struct trace_buffer *buffer, int cpu, gfp_t flags); -void ring_buffer_read_prepare_sync(void); -void ring_buffer_read_start(struct ring_buffer_iter *iter); +ring_buffer_read_start(struct trace_buffer *buffer, int cpu, gfp_t flags); void ring_buffer_read_finish(struct ring_buffer_iter *iter); struct ring_buffer_event * diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index 67707ff28fc5..f84210ee691e 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -5835,24 +5835,20 @@ ring_buffer_consume(struct trace_buffer *buffer, int cpu, u64 *ts, EXPORT_SYMBOL_GPL(ring_buffer_consume); /** - * ring_buffer_read_prepare - Prepare for a non consuming read of the buffer + * ring_buffer_read_start - start a non consuming read of the buffer * @buffer: The ring buffer to read from * @cpu: The cpu buffer to iterate over * @flags: gfp flags to use for memory allocation * - * This performs the initial preparations necessary to iterate - * through the buffer. Memory is allocated, buffer resizing - * is disabled, and the iterator pointer is returned to the caller. - * - * After a sequence of ring_buffer_read_prepare calls, the user is - * expected to make at least one call to ring_buffer_read_prepare_sync. - * Afterwards, ring_buffer_read_start is invoked to get things going - * for real. + * This creates an iterator to allow non-consuming iteration through + * the buffer. If the buffer is disabled for writing, it will produce + * the same information each time, but if the buffer is still writing + * then the first hit of a write will cause the iteration to stop. * - * This overall must be paired with ring_buffer_read_finish. + * Must be paired with ring_buffer_read_finish. */ struct ring_buffer_iter * -ring_buffer_read_prepare(struct trace_buffer *buffer, int cpu, gfp_t flags) +ring_buffer_read_start(struct trace_buffer *buffer, int cpu, gfp_t flags) { struct ring_buffer_per_cpu *cpu_buffer; struct ring_buffer_iter *iter; @@ -5878,51 +5874,12 @@ ring_buffer_read_prepare(struct trace_buffer *buffer, int cpu, gfp_t flags) atomic_inc(&cpu_buffer->resize_disabled); - return iter; -} -EXPORT_SYMBOL_GPL(ring_buffer_read_prepare); - -/** - * ring_buffer_read_prepare_sync - Synchronize a set of prepare calls - * - * All previously invoked ring_buffer_read_prepare calls to prepare - * iterators will be synchronized. Afterwards, read_buffer_read_start - * calls on those iterators are allowed. - */ -void -ring_buffer_read_prepare_sync(void) -{ - synchronize_rcu(); -} -EXPORT_SYMBOL_GPL(ring_buffer_read_prepare_sync); - -/** - * ring_buffer_read_start - start a non consuming read of the buffer - * @iter: The iterator returned by ring_buffer_read_prepare - * - * This finalizes the startup of an iteration through the buffer. - * The iterator comes from a call to ring_buffer_read_prepare and - * an intervening ring_buffer_read_prepare_sync must have been - * performed. - * - * Must be paired with ring_buffer_read_finish. - */ -void -ring_buffer_read_start(struct ring_buffer_iter *iter) -{ - struct ring_buffer_per_cpu *cpu_buffer; - unsigned long flags; - - if (!iter) - return; - - cpu_buffer = iter->cpu_buffer; - - raw_spin_lock_irqsave(&cpu_buffer->reader_lock, flags); + guard(raw_spinlock_irqsave)(&cpu_buffer->reader_lock); arch_spin_lock(&cpu_buffer->lock); rb_iter_reset(iter); arch_spin_unlock(&cpu_buffer->lock); - raw_spin_unlock_irqrestore(&cpu_buffer->reader_lock, flags); + + return iter; } EXPORT_SYMBOL_GPL(ring_buffer_read_start); diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 14e1e1ed5505..db3fd111b10a 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -4640,21 +4640,15 @@ __tracing_open(struct inode *inode, struct file *file, bool snapshot) if (iter->cpu_file == RING_BUFFER_ALL_CPUS) { for_each_tracing_cpu(cpu) { iter->buffer_iter[cpu] = - ring_buffer_read_prepare(iter->array_buffer->buffer, - cpu, GFP_KERNEL); - } - ring_buffer_read_prepare_sync(); - for_each_tracing_cpu(cpu) { - ring_buffer_read_start(iter->buffer_iter[cpu]); + ring_buffer_read_start(iter->array_buffer->buffer, + cpu, GFP_KERNEL); tracing_iter_reset(iter, cpu); } } else { cpu = iter->cpu_file; iter->buffer_iter[cpu] = - ring_buffer_read_prepare(iter->array_buffer->buffer, - cpu, GFP_KERNEL); - ring_buffer_read_prepare_sync(); - ring_buffer_read_start(iter->buffer_iter[cpu]); + ring_buffer_read_start(iter->array_buffer->buffer, + cpu, GFP_KERNEL); tracing_iter_reset(iter, cpu); } diff --git a/kernel/trace/trace_kdb.c b/kernel/trace/trace_kdb.c index 1e72d20b3c2f..1981d00e1f5d 100644 --- a/kernel/trace/trace_kdb.c +++ b/kernel/trace/trace_kdb.c @@ -43,17 +43,15 @@ static void ftrace_dump_buf(int skip_entries, long cpu_file) if (cpu_file == RING_BUFFER_ALL_CPUS) { for_each_tracing_cpu(cpu) { iter.buffer_iter[cpu] = - ring_buffer_read_prepare(iter.array_buffer->buffer, - cpu, GFP_ATOMIC); - ring_buffer_read_start(iter.buffer_iter[cpu]); + ring_buffer_read_start(iter.array_buffer->buffer, + cpu, GFP_ATOMIC); tracing_iter_reset(&iter, cpu); } } else { iter.cpu_file = cpu_file; iter.buffer_iter[cpu_file] = - ring_buffer_read_prepare(iter.array_buffer->buffer, + ring_buffer_read_start(iter.array_buffer->buffer, cpu_file, GFP_ATOMIC); - ring_buffer_read_start(iter.buffer_iter[cpu_file]); tracing_iter_reset(&iter, cpu_file); } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 187/480] kcsan: test: Initialize dummy variable 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (185 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 186/480] ring-buffer: Remove ring_buffer_read_prepare_sync() Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 188/480] memcg_slabinfo: Fix use of PG_slab Greg Kroah-Hartman ` (304 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Linux Kernel Functional Testing, Alexander Potapenko, Marco Elver, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Marco Elver <elver@google.com> [ Upstream commit 9872916ad1a1a5e7d089e05166c85dbd65e5b0e8 ] Newer compiler versions rightfully point out: kernel/kcsan/kcsan_test.c:591:41: error: variable 'dummy' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer] 591 | KCSAN_EXPECT_READ_BARRIER(atomic_read(&dummy), false); | ^~~~~ 1 error generated. Although this particular test does not care about the value stored in the dummy atomic variable, let's silence the warning. Link: https://lkml.kernel.org/r/CA+G9fYu8JY=k-r0hnBRSkQQrFJ1Bz+ShdXNwC1TNeMt0eXaxeA@mail.gmail.com Fixes: 8bc32b348178 ("kcsan: test: Add test cases for memory barrier instrumentation") Reported-by: Linux Kernel Functional Testing <lkft@linaro.org> Reviewed-by: Alexander Potapenko <glider@google.com> Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- kernel/kcsan/kcsan_test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/kcsan/kcsan_test.c b/kernel/kcsan/kcsan_test.c index 6ce73cceaf53..1305bc0e2479 100644 --- a/kernel/kcsan/kcsan_test.c +++ b/kernel/kcsan/kcsan_test.c @@ -533,7 +533,7 @@ static void test_barrier_nothreads(struct kunit *test) struct kcsan_scoped_access *reorder_access = NULL; #endif arch_spinlock_t arch_spinlock = __ARCH_SPIN_LOCK_UNLOCKED; - atomic_t dummy; + atomic_t dummy = ATOMIC_INIT(0); KCSAN_TEST_REQUIRES(test, reorder_access != NULL); KCSAN_TEST_REQUIRES(test, IS_ENABLED(CONFIG_SMP)); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 188/480] memcg_slabinfo: Fix use of PG_slab 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (186 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 187/480] kcsan: test: Initialize dummy variable Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 189/480] wifi: mac80211: fix WARN_ON for monitor mode on some devices Greg Kroah-Hartman ` (303 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Matthew Wilcox (Oracle), Roman Gushchin, Harry Yoo, Vlastimil Babka, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Matthew Wilcox (Oracle) <willy@infradead.org> [ Upstream commit 7f770e94d7936e8e35d4b4d5fa4618301b03ea33 ] Check PGTY_slab instead of PG_slab. Fixes: 4ffca5a96678 (mm: support only one page_type per page) Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Tested-by: Roman Gushchin <roman.gushchin@linux.dev> Reviewed-by: Roman Gushchin <roman.gushchin@linux.dev> Reviewed-by: Harry Yoo <harry.yoo@oracle.com> Link: https://patch.msgid.link/20250611155916.2579160-11-willy@infradead.org Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/cgroup/memcg_slabinfo.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/cgroup/memcg_slabinfo.py b/tools/cgroup/memcg_slabinfo.py index 270c28a0d098..6bf4bde77903 100644 --- a/tools/cgroup/memcg_slabinfo.py +++ b/tools/cgroup/memcg_slabinfo.py @@ -146,11 +146,11 @@ def detect_kernel_config(): def for_each_slab(prog): - PGSlab = ~prog.constant('PG_slab') + slabtype = prog.constant('PGTY_slab') for page in for_each_page(prog): try: - if page.page_type.value_() == PGSlab: + if (page.page_type.value_() >> 24) == slabtype: yield cast('struct slab *', page) except FaultError: pass -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 189/480] wifi: mac80211: fix WARN_ON for monitor mode on some devices 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (187 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 188/480] memcg_slabinfo: Fix use of PG_slab Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 190/480] arm64/gcs: task_gcs_el0_enable() should use passed task Greg Kroah-Hartman ` (302 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Martin Kaistra, Johannes Berg, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Johannes Berg <johannes.berg@intel.com> [ Upstream commit c57e5b9819dfd16d709bcd6cb633301ed0829a66 ] On devices without WANT_MONITOR_VIF (and probably without channel context support) we get a WARN_ON for changing the per-link setting of a monitor interface. Since we already skip AP_VLAN interfaces and MONITOR with WANT_MONITOR_VIF and/or NO_VIRTUAL_MONITOR should update the settings, catch this in the link change code instead of the warning. Reported-by: Martin Kaistra <martin.kaistra@linutronix.de> Link: https://lore.kernel.org/r/a9de62a0-28f1-4981-84df-253489da74ed@linutronix.de/ Fixes: c4382d5ca1af ("wifi: mac80211: update the right link for tx power") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/mac80211/main.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/net/mac80211/main.c b/net/mac80211/main.c index 6b6de43d9420..1bad353d8a77 100644 --- a/net/mac80211/main.c +++ b/net/mac80211/main.c @@ -407,9 +407,20 @@ void ieee80211_link_info_change_notify(struct ieee80211_sub_if_data *sdata, WARN_ON_ONCE(changed & BSS_CHANGED_VIF_CFG_FLAGS); - if (!changed || sdata->vif.type == NL80211_IFTYPE_AP_VLAN) + if (!changed) return; + switch (sdata->vif.type) { + case NL80211_IFTYPE_AP_VLAN: + return; + case NL80211_IFTYPE_MONITOR: + if (!ieee80211_hw_check(&local->hw, WANT_MONITOR_VIF)) + return; + break; + default: + break; + } + if (!check_sdata_in_driver(sdata)) return; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 190/480] arm64/gcs: task_gcs_el0_enable() should use passed task 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (188 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 189/480] wifi: mac80211: fix WARN_ON for monitor mode on some devices Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 191/480] wifi: iwlwifi: mld: decode EOF bit for AMPDUs Greg Kroah-Hartman ` (301 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Jeremy Linton, Mark Brown, Catalin Marinas, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jeremy Linton <jeremy.linton@arm.com> [ Upstream commit cbbcfb94c55c02a8c4ce52b5da0770b5591a314c ] Mark Rutland noticed that the task parameter is ignored and 'current' is being used instead. Since this is usually what its passed, it hasn't yet been causing problems but likely will as the code gets more testing. But, once this is fixed, it creates a new bug in copy_thread_gcs() since the gcs_el_mode isn't yet set for the task before its being checked. Move gcs_alloc_thread_stack() after the new task's gcs_el0_mode initialization to avoid this. Fixes: fc84bc5378a8 ("arm64/gcs: Context switch GCS state for EL0") Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250719043740.4548-2-jeremy.linton@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm64/include/asm/gcs.h | 2 +- arch/arm64/kernel/process.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm64/include/asm/gcs.h b/arch/arm64/include/asm/gcs.h index f50660603ecf..5bc432234d3a 100644 --- a/arch/arm64/include/asm/gcs.h +++ b/arch/arm64/include/asm/gcs.h @@ -58,7 +58,7 @@ static inline u64 gcsss2(void) static inline bool task_gcs_el0_enabled(struct task_struct *task) { - return current->thread.gcs_el0_mode & PR_SHADOW_STACK_ENABLE; + return task->thread.gcs_el0_mode & PR_SHADOW_STACK_ENABLE; } void gcs_set_el0_mode(struct task_struct *task); diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c index 4bc70205312e..ce21682fe129 100644 --- a/arch/arm64/kernel/process.c +++ b/arch/arm64/kernel/process.c @@ -305,13 +305,13 @@ static int copy_thread_gcs(struct task_struct *p, p->thread.gcs_base = 0; p->thread.gcs_size = 0; + p->thread.gcs_el0_mode = current->thread.gcs_el0_mode; + p->thread.gcs_el0_locked = current->thread.gcs_el0_locked; + gcs = gcs_alloc_thread_stack(p, args); if (IS_ERR_VALUE(gcs)) return PTR_ERR((void *)gcs); - p->thread.gcs_el0_mode = current->thread.gcs_el0_mode; - p->thread.gcs_el0_locked = current->thread.gcs_el0_locked; - return 0; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 191/480] wifi: iwlwifi: mld: decode EOF bit for AMPDUs 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (189 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 190/480] arm64/gcs: task_gcs_el0_enable() should use passed task Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 192/480] Bluetooth: hci_sync: fix double free in hci_discovery_filter_clear() Greg Kroah-Hartman ` (300 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Benjamin Berg, Daniel Gabay, Miri Korenblit, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Benjamin Berg <benjamin.berg@intel.com> [ Upstream commit bc404dfddbf6817cae9b170c34556dc72ea975e5 ] Only the EOF bit handling for single frames was ported to the MLD driver. The code to handle AMPDUs correctly was forgotten. Add it back so that the bit is reported in the radiotap headers again. Fixes: d1e879ec600f ("wifi: iwlwifi: add iwlmld sub-driver") Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Reviewed-by: Daniel Gabay <daniel.gabay@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250723094230.195be86372d5.I4db4abf348f7b6dfc75f869770dd77655a204bc7@changeid Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/wireless/intel/iwlwifi/mld/rx.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/net/wireless/intel/iwlwifi/mld/rx.c b/drivers/net/wireless/intel/iwlwifi/mld/rx.c index c4f189bcece2..5a206a663470 100644 --- a/drivers/net/wireless/intel/iwlwifi/mld/rx.c +++ b/drivers/net/wireless/intel/iwlwifi/mld/rx.c @@ -1039,6 +1039,15 @@ static void iwl_mld_rx_eht(struct iwl_mld *mld, struct sk_buff *skb, rx_status->flag |= RX_FLAG_AMPDU_EOF_BIT; } + /* update aggregation data for monitor sake on default queue */ + if (!queue && (phy_info & IWL_RX_MPDU_PHY_TSF_OVERLOAD) && + (phy_info & IWL_RX_MPDU_PHY_AMPDU) && phy_data->first_subframe) { + rx_status->flag |= RX_FLAG_AMPDU_EOF_BIT_KNOWN; + if (phy_data->data0 & + cpu_to_le32(IWL_RX_PHY_DATA0_EHT_DELIM_EOF)) + rx_status->flag |= RX_FLAG_AMPDU_EOF_BIT; + } + if (phy_info & IWL_RX_MPDU_PHY_TSF_OVERLOAD) iwl_mld_decode_eht_phy_data(mld, phy_data, rx_status, eht, usig); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 192/480] Bluetooth: hci_sync: fix double free in hci_discovery_filter_clear() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (190 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 191/480] wifi: iwlwifi: mld: decode EOF bit for AMPDUs Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 193/480] Bluetooth: hci_devcd_dump: fix out-of-bounds via dev_coredumpv Greg Kroah-Hartman ` (299 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Arseniy Krasnov, Luiz Augusto von Dentz, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Arseniy Krasnov <avkrasnov@salutedevices.com> [ Upstream commit 2935e556850e9c94d7a00adf14d3cd7fe406ac03 ] Function 'hci_discovery_filter_clear()' frees 'uuids' array and then sets it to NULL. There is a tiny chance of the following race: 'hci_cmd_sync_work()' 'update_passive_scan_sync()' 'hci_update_passive_scan_sync()' 'hci_discovery_filter_clear()' kfree(uuids); <-------------------------preempted--------------------------------> 'start_service_discovery()' 'hci_discovery_filter_clear()' kfree(uuids); // DOUBLE FREE <-------------------------preempted--------------------------------> uuids = NULL; To fix it let's add locking around 'kfree()' call and NULL pointer assignment. Otherwise the following backtrace fires: [ ] ------------[ cut here ]------------ [ ] kernel BUG at mm/slub.c:547! [ ] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1 [ ] Tainted: [O]=OOT_MODULE [ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ ] pc : __slab_free+0xf8/0x348 [ ] lr : __slab_free+0x48/0x348 ... [ ] Call trace: [ ] __slab_free+0xf8/0x348 [ ] kfree+0x164/0x27c [ ] start_service_discovery+0x1d0/0x2c0 [ ] hci_sock_sendmsg+0x518/0x924 [ ] __sock_sendmsg+0x54/0x60 [ ] sock_write_iter+0x98/0xf8 [ ] do_iter_readv_writev+0xe4/0x1c8 [ ] vfs_writev+0x128/0x2b0 [ ] do_writev+0xfc/0x118 [ ] __arm64_sys_writev+0x20/0x2c [ ] invoke_syscall+0x68/0xf0 [ ] el0_svc_common.constprop.0+0x40/0xe0 [ ] do_el0_svc+0x1c/0x28 [ ] el0_svc+0x30/0xd0 [ ] el0t_64_sync_handler+0x100/0x12c [ ] el0t_64_sync+0x194/0x198 [ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000) [ ] ---[ end trace 0000000000000000 ]--- Fixes: ad383c2c65a5 ("Bluetooth: hci_sync: Enable advertising when LL privacy is enabled") Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- include/net/bluetooth/hci_core.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h index d22468bb4341..351a9057e70e 100644 --- a/include/net/bluetooth/hci_core.h +++ b/include/net/bluetooth/hci_core.h @@ -29,6 +29,7 @@ #include <linux/idr.h> #include <linux/leds.h> #include <linux/rculist.h> +#include <linux/spinlock.h> #include <linux/srcu.h> #include <net/bluetooth/hci.h> @@ -93,6 +94,7 @@ struct discovery_state { u16 uuid_count; u8 (*uuids)[16]; unsigned long name_resolve_timeout; + spinlock_t lock; }; #define SUSPEND_NOTIFIER_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */ @@ -885,6 +887,7 @@ static inline void iso_recv(struct hci_conn *hcon, struct sk_buff *skb, static inline void discovery_init(struct hci_dev *hdev) { + spin_lock_init(&hdev->discovery.lock); hdev->discovery.state = DISCOVERY_STOPPED; INIT_LIST_HEAD(&hdev->discovery.all); INIT_LIST_HEAD(&hdev->discovery.unknown); @@ -899,8 +902,11 @@ static inline void hci_discovery_filter_clear(struct hci_dev *hdev) hdev->discovery.report_invalid_rssi = true; hdev->discovery.rssi = HCI_RSSI_INVALID; hdev->discovery.uuid_count = 0; + + spin_lock(&hdev->discovery.lock); kfree(hdev->discovery.uuids); hdev->discovery.uuids = NULL; + spin_unlock(&hdev->discovery.lock); } bool hci_discovery_active(struct hci_dev *hdev); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 193/480] Bluetooth: hci_devcd_dump: fix out-of-bounds via dev_coredumpv 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (191 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 192/480] Bluetooth: hci_sync: fix double free in hci_discovery_filter_clear() Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 194/480] Bluetooth: hci_event: Mask data status from LE ext adv reports Greg Kroah-Hartman ` (298 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, syzbot+ac3c79181f6aecc5120c, Ivan Pravdin, Luiz Augusto von Dentz, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ivan Pravdin <ipravdin.official@gmail.com> [ Upstream commit 7af4d7b53502286c6cf946d397ab183e76d14820 ] Currently both dev_coredumpv and skb_put_data in hci_devcd_dump use hdev->dump.head. However, dev_coredumpv can free the buffer. From dev_coredumpm_timeout documentation, which is used by dev_coredumpv: > Creates a new device coredump for the given device. If a previous one hasn't > been read yet, the new coredump is discarded. The data lifetime is determined > by the device coredump framework and when it is no longer needed the @free > function will be called to free the data. If the data has not been read by the userspace yet, dev_coredumpv will discard new buffer, freeing hdev->dump.head. This leads to vmalloc-out-of-bounds error when skb_put_data tries to access hdev->dump.head. A crash report from syzbot illustrates this: ================================================================== BUG: KASAN: vmalloc-out-of-bounds in skb_put_data include/linux/skbuff.h:2752 [inline] BUG: KASAN: vmalloc-out-of-bounds in hci_devcd_dump+0x142/0x240 net/bluetooth/coredump.c:258 Read of size 140 at addr ffffc90004ed5000 by task kworker/u9:2/5844 CPU: 1 UID: 0 PID: 5844 Comm: kworker/u9:2 Not tainted 6.14.0-syzkaller-10892-g4e82c87058f4 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Workqueue: hci0 hci_devcd_timeout Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 __asan_memcpy+0x23/0x60 mm/kasan/shadow.c:105 skb_put_data include/linux/skbuff.h:2752 [inline] hci_devcd_dump+0x142/0x240 net/bluetooth/coredump.c:258 hci_devcd_timeout+0xb5/0x2e0 net/bluetooth/coredump.c:413 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> The buggy address ffffc90004ed5000 belongs to a vmalloc virtual mapping Memory state around the buggy address: ffffc90004ed4f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90004ed4f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90004ed5000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90004ed5080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90004ed5100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== To avoid this issue, reorder dev_coredumpv to be called after skb_put_data that does not free the data. Reported-by: syzbot+ac3c79181f6aecc5120c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ac3c79181f6aecc5120c Fixes: b257e02ecc46 ("HCI: coredump: Log devcd dumps into the monitor") Tested-by: syzbot+ac3c79181f6aecc5120c@syzkaller.appspotmail.com Signed-off-by: Ivan Pravdin <ipravdin.official@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/bluetooth/coredump.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/bluetooth/coredump.c b/net/bluetooth/coredump.c index 819eacb38762..720cb79adf96 100644 --- a/net/bluetooth/coredump.c +++ b/net/bluetooth/coredump.c @@ -249,15 +249,15 @@ static void hci_devcd_dump(struct hci_dev *hdev) size = hdev->dump.tail - hdev->dump.head; - /* Emit a devcoredump with the available data */ - dev_coredumpv(&hdev->dev, hdev->dump.head, size, GFP_KERNEL); - /* Send a copy to monitor as a diagnostic packet */ skb = bt_skb_alloc(size, GFP_ATOMIC); if (skb) { skb_put_data(skb, hdev->dump.head, size); hci_recv_diag(hdev, skb); } + + /* Emit a devcoredump with the available data */ + dev_coredumpv(&hdev->dev, hdev->dump.head, size, GFP_KERNEL); } static void hci_devcd_handle_pkt_complete(struct hci_dev *hdev, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 194/480] Bluetooth: hci_event: Mask data status from LE ext adv reports 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (192 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 193/480] Bluetooth: hci_devcd_dump: fix out-of-bounds via dev_coredumpv Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 195/480] bpf: Disable migration in nf_hook_run_bpf() Greg Kroah-Hartman ` (297 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Chris Down, Luiz Augusto von Dentz, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Chris Down <chris@chrisdown.name> [ Upstream commit 0cadf8534f2a727bc3a01e8c583b085d25963ee0 ] The Event_Type field in an LE Extended Advertising Report uses bits 5 and 6 for data status (e.g. truncation or fragmentation), not the PDU type itself. The ext_evt_type_to_legacy() function fails to mask these status bits before evaluation. This causes valid advertisements with status bits set (e.g. a truncated non-connectable advertisement, which ends up showing as PDU type 0x40) to be misclassified as unknown and subsequently dropped. This is okay for most checks which use bitwise AND on the relevant event type bits, but it doesn't work for non-connectable types, which are checked with '== LE_EXT_ADV_NON_CONN_IND' (that is, zero). In terms of behaviour, first the device sends a truncated report: > HCI Event: LE Meta Event (0x3e) plen 26 LE Extended Advertising Report (0x0d) Entry 0 Event type: 0x0040 Data status: Incomplete, data truncated, no more to come Address type: Random (0x01) Address: 1D:12:46:FA:F8:6E (Non-Resolvable) SID: 0x03 RSSI: -98 dBm (0x9e) Data length: 0x00 Then, a few seconds later, it sends the subsequent complete report: > HCI Event: LE Meta Event (0x3e) plen 122 LE Extended Advertising Report (0x0d) Entry 0 Event type: 0x0000 Data status: Complete Address type: Random (0x01) Address: 1D:12:46:FA:F8:6E (Non-Resolvable) SID: 0x03 RSSI: -97 dBm (0x9f) Data length: 0x60 Service Data: Google (0xfef3) Data[92]: ... These devices often send multiple truncated reports per second. This patch introduces a PDU type mask to ensure only the relevant bits are evaluated, allowing for the correct translation of all valid extended advertising packets. Fixes: b2cc9761f144 ("Bluetooth: Handle extended ADV PDU types") Signed-off-by: Chris Down <chris@chrisdown.name> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- include/net/bluetooth/hci.h | 1 + net/bluetooth/hci_event.c | 8 ++++++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h index f47dfb8b5be7..ebe01eb28264 100644 --- a/include/net/bluetooth/hci.h +++ b/include/net/bluetooth/hci.h @@ -2633,6 +2633,7 @@ struct hci_ev_le_conn_complete { #define LE_EXT_ADV_DIRECT_IND 0x0004 #define LE_EXT_ADV_SCAN_RSP 0x0008 #define LE_EXT_ADV_LEGACY_PDU 0x0010 +#define LE_EXT_ADV_DATA_STATUS_MASK 0x0060 #define LE_EXT_ADV_EVT_TYPE_MASK 0x007f #define ADDR_LE_DEV_PUBLIC 0x00 diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c index cf4b30ac9e0e..c1dd8d78701f 100644 --- a/net/bluetooth/hci_event.c +++ b/net/bluetooth/hci_event.c @@ -6239,6 +6239,11 @@ static void hci_le_adv_report_evt(struct hci_dev *hdev, void *data, static u8 ext_evt_type_to_legacy(struct hci_dev *hdev, u16 evt_type) { + u16 pdu_type = evt_type & ~LE_EXT_ADV_DATA_STATUS_MASK; + + if (!pdu_type) + return LE_ADV_NONCONN_IND; + if (evt_type & LE_EXT_ADV_LEGACY_PDU) { switch (evt_type) { case LE_LEGACY_ADV_IND: @@ -6270,8 +6275,7 @@ static u8 ext_evt_type_to_legacy(struct hci_dev *hdev, u16 evt_type) if (evt_type & LE_EXT_ADV_SCAN_IND) return LE_ADV_SCAN_IND; - if (evt_type == LE_EXT_ADV_NON_CONN_IND || - evt_type & LE_EXT_ADV_DIRECT_IND) + if (evt_type & LE_EXT_ADV_DIRECT_IND) return LE_ADV_NONCONN_IND; invalid: -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 195/480] bpf: Disable migration in nf_hook_run_bpf(). 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (193 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 194/480] Bluetooth: hci_event: Mask data status from LE ext adv reports Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 196/480] tools/rv: Do not skip idle in trace Greg Kroah-Hartman ` (296 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, syzbot+40f772d37250b6d10efc, Kuniyuki Iwashima, Martin KaFai Lau, Florian Westphal, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Kuniyuki Iwashima <kuniyu@google.com> [ Upstream commit 17ce3e5949bc37557305ad46316f41c7875d6366 ] syzbot reported that the netfilter bpf prog can be called without migration disabled in xmit path. Then the assertion in __bpf_prog_run() fails, triggering the splat below. [0] Let's use bpf_prog_run_pin_on_cpu() in nf_hook_run_bpf(). [0]: BUG: assuming non migratable context at ./include/linux/filter.h:703 in_atomic(): 0, irqs_disabled(): 0, migration_disabled() 0 pid: 5829, name: sshd-session 3 locks held by sshd-session/5829: #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1667 [inline] #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x20/0x50 net/ipv4/tcp.c:1395 #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline] #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline] #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: __ip_queue_xmit+0x69/0x26c0 net/ipv4/ip_output.c:470 #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline] #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline] #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: nf_hook+0xb2/0x680 include/linux/netfilter.h:241 CPU: 0 UID: 0 PID: 5829 Comm: sshd-session Not tainted 6.16.0-rc6-syzkaller-00002-g155a3c003e55 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 __cant_migrate kernel/sched/core.c:8860 [inline] __cant_migrate+0x1c7/0x250 kernel/sched/core.c:8834 __bpf_prog_run include/linux/filter.h:703 [inline] bpf_prog_run include/linux/filter.h:725 [inline] nf_hook_run_bpf+0x83/0x1e0 net/netfilter/nf_bpf_link.c:20 nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline] nf_hook_slow+0xbb/0x200 net/netfilter/core.c:623 nf_hook+0x370/0x680 include/linux/netfilter.h:272 NF_HOOK_COND include/linux/netfilter.h:305 [inline] ip_output+0x1bc/0x2a0 net/ipv4/ip_output.c:433 dst_output include/net/dst.h:459 [inline] ip_local_out net/ipv4/ip_output.c:129 [inline] __ip_queue_xmit+0x1d7d/0x26c0 net/ipv4/ip_output.c:527 __tcp_transmit_skb+0x2686/0x3e90 net/ipv4/tcp_output.c:1479 tcp_transmit_skb net/ipv4/tcp_output.c:1497 [inline] tcp_write_xmit+0x1274/0x84e0 net/ipv4/tcp_output.c:2838 __tcp_push_pending_frames+0xaf/0x390 net/ipv4/tcp_output.c:3021 tcp_push+0x225/0x700 net/ipv4/tcp.c:759 tcp_sendmsg_locked+0x1870/0x42b0 net/ipv4/tcp.c:1359 tcp_sendmsg+0x2e/0x50 net/ipv4/tcp.c:1396 inet_sendmsg+0xb9/0x140 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] sock_write_iter+0x4aa/0x5b0 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x6c7/0x1150 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe7d365d407 Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff RSP: Fixes: fd9c663b9ad67 ("bpf: minimal support for programs hooked into netfilter framework") Reported-by: syzbot+40f772d37250b6d10efc@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6879466d.a00a0220.3af5df.0022.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Tested-by: syzbot+40f772d37250b6d10efc@syzkaller.appspotmail.com Acked-by: Florian Westphal <fw@strlen.de> Link: https://patch.msgid.link/20250722224041.112292-1-kuniyu@google.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/netfilter/nf_bpf_link.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/netfilter/nf_bpf_link.c b/net/netfilter/nf_bpf_link.c index 06b084844700..25bbac8986c2 100644 --- a/net/netfilter/nf_bpf_link.c +++ b/net/netfilter/nf_bpf_link.c @@ -17,7 +17,7 @@ static unsigned int nf_hook_run_bpf(void *bpf_prog, struct sk_buff *skb, .skb = skb, }; - return bpf_prog_run(prog, &ctx); + return bpf_prog_run_pin_on_cpu(prog, &ctx); } struct bpf_nf_link { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 196/480] tools/rv: Do not skip idle in trace 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (194 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 195/480] bpf: Disable migration in nf_hook_run_bpf() Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 197/480] selftests: drv-net: Fix remote command checking in require_cmd() Greg Kroah-Hartman ` (295 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Nam Cao, Tomas Glozar, Juri Lelli, Clark Williams, John Kacur, Gabriele Monaco, Steven Rostedt (Google), Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Gabriele Monaco <gmonaco@redhat.com> [ Upstream commit f60227f3448911b682c45041c3fbd94f6d3b15a2 ] Currently, the userspace RV tool skips trace events triggered by the RV tool itself, this can be changed by passing the parameter -s, which sets the variable config_my_pid to 0 (instead of the tool's PID). This has the side effect of skipping events generated by idle (PID 0). Set config_my_pid to -1 (an invalid pid) to avoid skipping idle. Cc: Nam Cao <namcao@linutronix.de> Cc: Tomas Glozar <tglozar@redhat.com> Cc: Juri Lelli <jlelli@redhat.com> Cc: Clark Williams <williams@redhat.com> Cc: John Kacur <jkacur@redhat.com> Link: https://lore.kernel.org/20250723161240.194860-2-gmonaco@redhat.com Fixes: 6d60f89691fc ("tools/rv: Add in-kernel monitor interface") Signed-off-by: Gabriele Monaco <gmonaco@redhat.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/verification/rv/src/in_kernel.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/verification/rv/src/in_kernel.c b/tools/verification/rv/src/in_kernel.c index c0dcee795c0d..4bb746ea6e17 100644 --- a/tools/verification/rv/src/in_kernel.c +++ b/tools/verification/rv/src/in_kernel.c @@ -431,7 +431,7 @@ ikm_event_handler(struct trace_seq *s, struct tep_record *record, if (config_has_id && (config_my_pid == id)) return 0; - else if (config_my_pid && (config_my_pid == pid)) + else if (config_my_pid == pid) return 0; tep_print_event(trace_event->tep, s, record, "%16s-%-8d [%.3d] ", @@ -734,7 +734,7 @@ static int parse_arguments(char *monitor_name, int argc, char **argv) config_reactor = optarg; break; case 's': - config_my_pid = 0; + config_my_pid = -1; break; case 't': config_trace = 1; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 197/480] selftests: drv-net: Fix remote command checking in require_cmd() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (195 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 196/480] tools/rv: Do not skip idle in trace Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 198/480] selftests: drv-net: tso: enable test cases based on hw_features Greg Kroah-Hartman ` (294 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Nimrod Oren, Gal Pressman, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Gal Pressman <gal@nvidia.com> [ Upstream commit b4d52c698210ae1a3ceb487b189701bc70551a48 ] The require_cmd() method was checking for command availability locally even when remote=True was specified, due to a missing host parameter. Fix by passing host=self.remote when checking remote command availability, ensuring commands are verified on the correct host. Fixes: f1e68a1a4a40 ("selftests: drv-net: add require_XYZ() helpers for validating env") Reviewed-by: Nimrod Oren <noren@nvidia.com> Signed-off-by: Gal Pressman <gal@nvidia.com> Link: https://patch.msgid.link/20250723135454.649342-2-gal@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/testing/selftests/drivers/net/lib/py/env.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/drivers/net/lib/py/env.py b/tools/testing/selftests/drivers/net/lib/py/env.py index ad5ff645183a..98bfc1e9e9ca 100644 --- a/tools/testing/selftests/drivers/net/lib/py/env.py +++ b/tools/testing/selftests/drivers/net/lib/py/env.py @@ -259,7 +259,7 @@ class NetDrvEpEnv(NetDrvEnvBase): if not self._require_cmd(comm, "local"): raise KsftSkipEx("Test requires command: " + comm) if remote: - if not self._require_cmd(comm, "remote"): + if not self._require_cmd(comm, "remote", host=self.remote): raise KsftSkipEx("Test requires (remote) command: " + comm) def wait_hw_stats_settle(self): -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 198/480] selftests: drv-net: tso: enable test cases based on hw_features 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (196 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 197/480] selftests: drv-net: Fix remote command checking in require_cmd() Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 199/480] selftests: drv-net: tso: fix vxlan tunnel flags to get correct gso_type Greg Kroah-Hartman ` (293 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Daniel Zahka, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Daniel Zahka <daniel.zahka@gmail.com> [ Upstream commit 266b835e5e84a0f8fec7fd988ee81925890e8d89 ] tso.py uses the active features at the time of test execution as the set of available gso features to test. This means if a gso feature is supported but toggled off at test start, the test will be skipped with a "Device does not support {feature}" message. Instead, we can enumerate the set of toggleable features by capturing the driver's hw_features bitmap. To avoid configuration side-effects from running the test, we also snapshot the wanted_features flag set before making any feature changes, and then attempt to restore the same set of wanted_features before test exit. Fixes: 0d0f4174f6c8 ("selftests: drv-net: add a simple TSO test") Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20250723184740.4075410-2-daniel.zahka@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/testing/selftests/drivers/net/hw/tso.py | 52 ++++++++++++++----- 1 file changed, 40 insertions(+), 12 deletions(-) diff --git a/tools/testing/selftests/drivers/net/hw/tso.py b/tools/testing/selftests/drivers/net/hw/tso.py index 3370827409aa..f8386e3d88cd 100755 --- a/tools/testing/selftests/drivers/net/hw/tso.py +++ b/tools/testing/selftests/drivers/net/hw/tso.py @@ -119,15 +119,30 @@ def build_tunnel(cfg, outer_ipver, tun_info): return remote_v4, remote_v6 +def restore_wanted_features(cfg): + features_cmd = "" + for feature in cfg.hw_features: + setting = "on" if feature in cfg.wanted_features else "off" + features_cmd += f" {feature} {setting}" + try: + ethtool(f"-K {cfg.ifname} {features_cmd}") + except Exception as e: + ksft_pr(f"WARNING: failure restoring wanted features: {e}") + + def test_builder(name, cfg, outer_ipver, feature, tun=None, inner_ipver=None): """Construct specific tests from the common template.""" def f(cfg): cfg.require_ipver(outer_ipver) + defer(restore_wanted_features, cfg) if not cfg.have_stat_super_count and \ not cfg.have_stat_wire_count: raise KsftSkipEx(f"Device does not support LSO queue stats") + if feature not in cfg.hw_features: + raise KsftSkipEx(f"Device does not support {feature}") + ipver = outer_ipver if tun: remote_v4, remote_v6 = build_tunnel(cfg, ipver, tun) @@ -138,12 +153,12 @@ def test_builder(name, cfg, outer_ipver, feature, tun=None, inner_ipver=None): tun_partial = tun and tun[1] # Tunnel which can silently fall back to gso-partial - has_gso_partial = tun and 'tx-gso-partial' in cfg.features + has_gso_partial = tun and 'tx-gso-partial' in cfg.hw_features # For TSO4 via partial we need mangleid if ipver == "4" and feature in cfg.partial_features: ksft_pr("Testing with mangleid enabled") - if 'tx-tcp-mangleid-segmentation' not in cfg.features: + if 'tx-tcp-mangleid-segmentation' not in cfg.hw_features: ethtool(f"-K {cfg.ifname} tx-tcp-mangleid-segmentation on") defer(ethtool, f"-K {cfg.ifname} tx-tcp-mangleid-segmentation off") @@ -161,11 +176,8 @@ def test_builder(name, cfg, outer_ipver, feature, tun=None, inner_ipver=None): should_lso=tun_partial) # Full feature enabled. - if feature in cfg.features: - ethtool(f"-K {cfg.ifname} {feature} on") - run_one_stream(cfg, ipver, remote_v4, remote_v6, should_lso=True) - else: - raise KsftXfailEx(f"Device does not support {feature}") + ethtool(f"-K {cfg.ifname} {feature} on") + run_one_stream(cfg, ipver, remote_v4, remote_v6, should_lso=True) f.__name__ = name + ((outer_ipver + "_") if tun else "") + "ipv" + inner_ipver return f @@ -176,23 +188,39 @@ def query_nic_features(cfg) -> None: cfg.have_stat_super_count = False cfg.have_stat_wire_count = False - cfg.features = set() features = cfg.ethnl.features_get({"header": {"dev-index": cfg.ifindex}}) - for f in features["active"]["bits"]["bit"]: - cfg.features.add(f["name"]) + + cfg.wanted_features = set() + for f in features["wanted"]["bits"]["bit"]: + cfg.wanted_features.add(f["name"]) + + cfg.hw_features = set() + hw_all_features_cmd = "" + for f in features["hw"]["bits"]["bit"]: + if f.get("value", False): + feature = f["name"] + cfg.hw_features.add(feature) + hw_all_features_cmd += f" {feature} on" + try: + ethtool(f"-K {cfg.ifname} {hw_all_features_cmd}") + except Exception as e: + ksft_pr(f"WARNING: failure enabling all hw features: {e}") + ksft_pr("partial gso feature detection may be impacted") # Check which features are supported via GSO partial cfg.partial_features = set() - if 'tx-gso-partial' in cfg.features: + if 'tx-gso-partial' in cfg.hw_features: ethtool(f"-K {cfg.ifname} tx-gso-partial off") no_partial = set() features = cfg.ethnl.features_get({"header": {"dev-index": cfg.ifindex}}) for f in features["active"]["bits"]["bit"]: no_partial.add(f["name"]) - cfg.partial_features = cfg.features - no_partial + cfg.partial_features = cfg.hw_features - no_partial ethtool(f"-K {cfg.ifname} tx-gso-partial on") + restore_wanted_features(cfg) + stats = cfg.netnl.qstats_get({"ifindex": cfg.ifindex}, dump=True) if stats: if 'tx-hw-gso-packets' in stats[0]: -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 199/480] selftests: drv-net: tso: fix vxlan tunnel flags to get correct gso_type 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (197 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 198/480] selftests: drv-net: tso: enable test cases based on hw_features Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 200/480] selftests: drv-net: tso: fix non-tunneled tso6 test case name Greg Kroah-Hartman ` (292 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Daniel Zahka, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Daniel Zahka <daniel.zahka@gmail.com> [ Upstream commit 2cfbcc5d8af9199823151c21f740e476b223dd2e ] When vxlan is used with ipv6 as the outer network header, the correct ip link parameters for acheiving the SKB_GSO_UDP_TUNNEL gso type is "udp6zerocsumtx udp6zerocsumrx". Otherwise the gso type will be SKB_GSO_UDP_TUNNEL_CSUM. This bug was the reason for the second of the three possible invocations of run_one_stream() invocations, so that can be deleted as well. We only need to test with the feature off and on. Fixes: 0d0f4174f6c8 ("selftests: drv-net: add a simple TSO test") Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20250723184740.4075410-3-daniel.zahka@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/testing/selftests/drivers/net/hw/tso.py | 37 +++++++------------ 1 file changed, 13 insertions(+), 24 deletions(-) diff --git a/tools/testing/selftests/drivers/net/hw/tso.py b/tools/testing/selftests/drivers/net/hw/tso.py index f8386e3d88cd..6461a83b3d0e 100755 --- a/tools/testing/selftests/drivers/net/hw/tso.py +++ b/tools/testing/selftests/drivers/net/hw/tso.py @@ -102,7 +102,7 @@ def build_tunnel(cfg, outer_ipver, tun_info): remote_addr = cfg.remote_addr_v[outer_ipver] tun_type = tun_info[0] - tun_arg = tun_info[2] + tun_arg = tun_info[1] ip(f"link add {tun_type}-ksft type {tun_type} {tun_arg} local {local_addr} remote {remote_addr} dev {cfg.ifname}") defer(ip, f"link del {tun_type}-ksft") ip(f"link set dev {tun_type}-ksft up") @@ -151,29 +151,17 @@ def test_builder(name, cfg, outer_ipver, feature, tun=None, inner_ipver=None): remote_v4 = cfg.remote_addr_v["4"] remote_v6 = cfg.remote_addr_v["6"] - tun_partial = tun and tun[1] - # Tunnel which can silently fall back to gso-partial - has_gso_partial = tun and 'tx-gso-partial' in cfg.hw_features - - # For TSO4 via partial we need mangleid - if ipver == "4" and feature in cfg.partial_features: - ksft_pr("Testing with mangleid enabled") - if 'tx-tcp-mangleid-segmentation' not in cfg.hw_features: - ethtool(f"-K {cfg.ifname} tx-tcp-mangleid-segmentation on") - defer(ethtool, f"-K {cfg.ifname} tx-tcp-mangleid-segmentation off") - # First test without the feature enabled. ethtool(f"-K {cfg.ifname} {feature} off") - if has_gso_partial: - ethtool(f"-K {cfg.ifname} tx-gso-partial off") run_one_stream(cfg, ipver, remote_v4, remote_v6, should_lso=False) - # Now test with the feature enabled. - # For compatible tunnels only - just GSO partial, not specific feature. - if has_gso_partial: + ethtool(f"-K {cfg.ifname} tx-gso-partial off") + ethtool(f"-K {cfg.ifname} tx-tcp-mangleid-segmentation off") + if feature in cfg.partial_features: ethtool(f"-K {cfg.ifname} tx-gso-partial on") - run_one_stream(cfg, ipver, remote_v4, remote_v6, - should_lso=tun_partial) + if ipver == "4": + ksft_pr("Testing with mangleid enabled") + ethtool(f"-K {cfg.ifname} tx-tcp-mangleid-segmentation on") # Full feature enabled. ethtool(f"-K {cfg.ifname} {feature} on") @@ -239,13 +227,14 @@ def main() -> None: query_nic_features(cfg) test_info = ( - # name, v4/v6 ethtool_feature tun:(type, partial, args) + # name, v4/v6 ethtool_feature tun:(type, args) ("", "4", "tx-tcp-segmentation", None), ("", "6", "tx-tcp6-segmentation", None), - ("vxlan", "", "tx-udp_tnl-segmentation", ("vxlan", True, "id 100 dstport 4789 noudpcsum")), - ("vxlan_csum", "", "tx-udp_tnl-csum-segmentation", ("vxlan", False, "id 100 dstport 4789 udpcsum")), - ("gre", "4", "tx-gre-segmentation", ("gre", False, "")), - ("gre", "6", "tx-gre-segmentation", ("ip6gre", False, "")), + ("vxlan", "4", "tx-udp_tnl-segmentation", ("vxlan", "id 100 dstport 4789 noudpcsum")), + ("vxlan", "6", "tx-udp_tnl-segmentation", ("vxlan", "id 100 dstport 4789 udp6zerocsumtx udp6zerocsumrx")), + ("vxlan_csum", "", "tx-udp_tnl-csum-segmentation", ("vxlan", "id 100 dstport 4789 udpcsum")), + ("gre", "4", "tx-gre-segmentation", ("gre", "")), + ("gre", "6", "tx-gre-segmentation", ("ip6gre", "")), ) cases = [] -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 200/480] selftests: drv-net: tso: fix non-tunneled tso6 test case name 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (198 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 199/480] selftests: drv-net: tso: fix vxlan tunnel flags to get correct gso_type Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 201/480] can: peak_usb: fix USB FD devices potential malfunction Greg Kroah-Hartman ` (291 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Daniel Zahka, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Daniel Zahka <daniel.zahka@gmail.com> [ Upstream commit b25b44cd178cc54277f2dc0ff3b3d5a37ae4b26b ] The non-tunneled tso6 test case was showing up as: ok 8 tso.ipv4 This is because of the way test_builder() uses the inner_ipver arg in test naming, and how test_info is iterated over in main(). Given that some tunnels not supported yet, e.g. ipip or sit, only support ipv4 or ipv6 as the inner network protocol, I think the best fix here is to call test_builder() in separate branches for tunneled and non-tunneled tests, and to make supported inner l3 types an explicit attribute of tunnel test cases. # Detected qstat for LSO wire-packets TAP version 13 1..14 ok 1 tso.ipv4 # Testing with mangleid enabled ok 2 tso.vxlan4_ipv4 ok 3 tso.vxlan4_ipv6 # Testing with mangleid enabled ok 4 tso.vxlan_csum4_ipv4 ok 5 tso.vxlan_csum4_ipv6 # Testing with mangleid enabled ok 6 tso.gre4_ipv4 ok 7 tso.gre4_ipv6 ok 8 tso.ipv6 # Testing with mangleid enabled ok 9 tso.vxlan6_ipv4 ok 10 tso.vxlan6_ipv6 # Testing with mangleid enabled ok 11 tso.vxlan_csum6_ipv4 ok 12 tso.vxlan_csum6_ipv6 # Testing with mangleid enabled ok 13 tso.gre6_ipv4 ok 14 tso.gre6_ipv6 # Totals: pass:14 fail:0 xfail:0 xpass:0 skip:0 error:0 Fixes: 0d0f4174f6c8 ("selftests: drv-net: add a simple TSO test") Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20250723184740.4075410-4-daniel.zahka@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/testing/selftests/drivers/net/hw/tso.py | 26 ++++++++++--------- 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/tools/testing/selftests/drivers/net/hw/tso.py b/tools/testing/selftests/drivers/net/hw/tso.py index 6461a83b3d0e..5fddb5056a20 100755 --- a/tools/testing/selftests/drivers/net/hw/tso.py +++ b/tools/testing/selftests/drivers/net/hw/tso.py @@ -227,14 +227,14 @@ def main() -> None: query_nic_features(cfg) test_info = ( - # name, v4/v6 ethtool_feature tun:(type, args) - ("", "4", "tx-tcp-segmentation", None), - ("", "6", "tx-tcp6-segmentation", None), - ("vxlan", "4", "tx-udp_tnl-segmentation", ("vxlan", "id 100 dstport 4789 noudpcsum")), - ("vxlan", "6", "tx-udp_tnl-segmentation", ("vxlan", "id 100 dstport 4789 udp6zerocsumtx udp6zerocsumrx")), - ("vxlan_csum", "", "tx-udp_tnl-csum-segmentation", ("vxlan", "id 100 dstport 4789 udpcsum")), - ("gre", "4", "tx-gre-segmentation", ("gre", "")), - ("gre", "6", "tx-gre-segmentation", ("ip6gre", "")), + # name, v4/v6 ethtool_feature tun:(type, args, inner ip versions) + ("", "4", "tx-tcp-segmentation", None), + ("", "6", "tx-tcp6-segmentation", None), + ("vxlan", "4", "tx-udp_tnl-segmentation", ("vxlan", "id 100 dstport 4789 noudpcsum", ("4", "6"))), + ("vxlan", "6", "tx-udp_tnl-segmentation", ("vxlan", "id 100 dstport 4789 udp6zerocsumtx udp6zerocsumrx", ("4", "6"))), + ("vxlan_csum", "", "tx-udp_tnl-csum-segmentation", ("vxlan", "id 100 dstport 4789 udpcsum", ("4", "6"))), + ("gre", "4", "tx-gre-segmentation", ("gre", "", ("4", "6"))), + ("gre", "6", "tx-gre-segmentation", ("ip6gre","", ("4", "6"))), ) cases = [] @@ -244,11 +244,13 @@ def main() -> None: if info[1] and outer_ipver != info[1]: continue - cases.append(test_builder(info[0], cfg, outer_ipver, info[2], - tun=info[3], inner_ipver="4")) if info[3]: - cases.append(test_builder(info[0], cfg, outer_ipver, info[2], - tun=info[3], inner_ipver="6")) + cases += [ + test_builder(info[0], cfg, outer_ipver, info[2], info[3], inner_ipver) + for inner_ipver in info[3][2] + ] + else: + cases.append(test_builder(info[0], cfg, outer_ipver, info[2], None, outer_ipver)) ksft_run(cases=cases, args=(cfg, )) ksft_exit() -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 201/480] can: peak_usb: fix USB FD devices potential malfunction 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (199 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 200/480] selftests: drv-net: tso: fix non-tunneled tso6 test case name Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 202/480] can: kvaser_pciefd: Store device channel index Greg Kroah-Hartman ` (290 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Stephane Grosjean, Vincent Mailhol, Marc Kleine-Budde, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Stephane Grosjean <stephane.grosjean@hms-networks.com> [ Upstream commit 788199b73b6efe4ee2ade4d7457b50bb45493488 ] The latest firmware versions of USB CAN FD interfaces export the EP numbers to be used to dialog with the device via the "type" field of a response to a vendor request structure, particularly when its value is greater than or equal to 2. Correct the driver's test of this field. Fixes: 4f232482467a ("can: peak_usb: include support for a new MCU") Signed-off-by: Stephane Grosjean <stephane.grosjean@hms-networks.com> Link: https://patch.msgid.link/20250724081550.11694-1-stephane.grosjean@free.fr Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> [mkl: rephrase commit message] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/can/usb/peak_usb/pcan_usb_fd.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_fd.c b/drivers/net/can/usb/peak_usb/pcan_usb_fd.c index 4d85b29a17b7..ebefc274b50a 100644 --- a/drivers/net/can/usb/peak_usb/pcan_usb_fd.c +++ b/drivers/net/can/usb/peak_usb/pcan_usb_fd.c @@ -49,7 +49,7 @@ struct __packed pcan_ufd_fw_info { __le32 ser_no; /* S/N */ __le32 flags; /* special functions */ - /* extended data when type == PCAN_USBFD_TYPE_EXT */ + /* extended data when type >= PCAN_USBFD_TYPE_EXT */ u8 cmd_out_ep; /* ep for cmd */ u8 cmd_in_ep; /* ep for replies */ u8 data_out_ep[2]; /* ep for CANx TX */ @@ -982,10 +982,11 @@ static int pcan_usb_fd_init(struct peak_usb_device *dev) dev->can.ctrlmode |= CAN_CTRLMODE_FD_NON_ISO; } - /* if vendor rsp is of type 2, then it contains EP numbers to - * use for cmds pipes. If not, then default EP should be used. + /* if vendor rsp type is greater than or equal to 2, then it + * contains EP numbers to use for cmds pipes. If not, then + * default EP should be used. */ - if (fw_info->type != cpu_to_le16(PCAN_USBFD_TYPE_EXT)) { + if (le16_to_cpu(fw_info->type) < PCAN_USBFD_TYPE_EXT) { fw_info->cmd_out_ep = PCAN_USBPRO_EP_CMDOUT; fw_info->cmd_in_ep = PCAN_USBPRO_EP_CMDIN; } @@ -1018,11 +1019,11 @@ static int pcan_usb_fd_init(struct peak_usb_device *dev) dev->can_channel_id = le32_to_cpu(pdev->usb_if->fw_info.dev_id[dev->ctrl_idx]); - /* if vendor rsp is of type 2, then it contains EP numbers to - * use for data pipes. If not, then statically defined EP are used - * (see peak_usb_create_dev()). + /* if vendor rsp type is greater than or equal to 2, then it contains EP + * numbers to use for data pipes. If not, then statically defined EP are + * used (see peak_usb_create_dev()). */ - if (fw_info->type == cpu_to_le16(PCAN_USBFD_TYPE_EXT)) { + if (le16_to_cpu(fw_info->type) >= PCAN_USBFD_TYPE_EXT) { dev->ep_msg_in = fw_info->data_in_ep; dev->ep_msg_out = fw_info->data_out_ep[dev->ctrl_idx]; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 202/480] can: kvaser_pciefd: Store device channel index 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (200 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 201/480] can: peak_usb: fix USB FD devices potential malfunction Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 203/480] can: kvaser_usb: Assign netdev.dev_port based on " Greg Kroah-Hartman ` (289 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Vincent Mailhol, Jimmy Assarsson, Marc Kleine-Budde, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jimmy Assarsson <extja@kvaser.com> [ Upstream commit d54b16b40ddadb7d0a77fff48af7b319a0cd6aae ] Store device channel index in netdev.dev_port. Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123230.8-6-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/can/kvaser_pciefd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/can/kvaser_pciefd.c b/drivers/net/can/kvaser_pciefd.c index 0071a51ce2c1..879b3ea6e9b0 100644 --- a/drivers/net/can/kvaser_pciefd.c +++ b/drivers/net/can/kvaser_pciefd.c @@ -981,6 +981,7 @@ static int kvaser_pciefd_setup_can_ctrls(struct kvaser_pciefd *pcie) can->completed_tx_bytes = 0; can->bec.txerr = 0; can->bec.rxerr = 0; + can->can.dev->dev_port = i; init_completion(&can->start_comp); init_completion(&can->flush_comp); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 203/480] can: kvaser_usb: Assign netdev.dev_port based on device channel index 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (201 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 202/480] can: kvaser_pciefd: Store device channel index Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 204/480] netfilter: xt_nfacct: dont assume acct name is null-terminated Greg Kroah-Hartman ` (288 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Vincent Mailhol, Jimmy Assarsson, Marc Kleine-Budde, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jimmy Assarsson <extja@kvaser.com> [ Upstream commit c151b06a087a61c7a1790b75ee2f1d6edb6a8a45 ] Assign netdev.dev_port based on the device channel index, to indicate the port number of the network device. While this driver already uses netdev.dev_id for that purpose, dev_port is more appropriate. However, retain dev_id to avoid potential regressions. Fixes: 3e66d0138c05 ("can: populate netdev::dev_id for udev discrimination") Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123452.41-4-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c b/drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c index dcb0bcbe0565..f73ccbc3140a 100644 --- a/drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c +++ b/drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c @@ -852,6 +852,7 @@ static int kvaser_usb_init_one(struct kvaser_usb *dev, int channel) netdev->ethtool_ops = &kvaser_usb_ethtool_ops; SET_NETDEV_DEV(netdev, &dev->intf->dev); netdev->dev_id = channel; + netdev->dev_port = channel; dev->nets[channel] = priv; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 204/480] netfilter: xt_nfacct: dont assume acct name is null-terminated 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (202 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 203/480] can: kvaser_usb: Assign netdev.dev_port based on " Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 205/480] net/mlx5e: Clear Read-Only port buffer size in PBMC before update Greg Kroah-Hartman ` (287 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, syzbot+4ff165b9251e4d295690, Florian Westphal, Pablo Neira Ayuso, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Florian Westphal <fw@strlen.de> [ Upstream commit bf58e667af7d96c8eb9411f926a0a0955f41ce21 ] BUG: KASAN: slab-out-of-bounds in .. lib/vsprintf.c:721 Read of size 1 at addr ffff88801eac95c8 by task syz-executor183/5851 [..] string+0x231/0x2b0 lib/vsprintf.c:721 vsnprintf+0x739/0xf00 lib/vsprintf.c:2874 [..] nfacct_mt_checkentry+0xd2/0xe0 net/netfilter/xt_nfacct.c:41 xt_check_match+0x3d1/0xab0 net/netfilter/x_tables.c:523 nfnl_acct_find_get() handles non-null input, but the error printk relied on its presence. Reported-by: syzbot+4ff165b9251e4d295690@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4ff165b9251e4d295690 Tested-by: syzbot+4ff165b9251e4d295690@syzkaller.appspotmail.com Fixes: ceb98d03eac5 ("netfilter: xtables: add nfacct match to support extended accounting") Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/netfilter/xt_nfacct.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/netfilter/xt_nfacct.c b/net/netfilter/xt_nfacct.c index 7c6bf1c16813..0ca1cdfc4095 100644 --- a/net/netfilter/xt_nfacct.c +++ b/net/netfilter/xt_nfacct.c @@ -38,8 +38,8 @@ nfacct_mt_checkentry(const struct xt_mtchk_param *par) nfacct = nfnl_acct_find_get(par->net, info->name); if (nfacct == NULL) { - pr_info_ratelimited("accounting object `%s' does not exists\n", - info->name); + pr_info_ratelimited("accounting object `%.*s' does not exist\n", + NFACCT_NAME_MAX, info->name); return -ENOENT; } info->nfacct = nfacct; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 205/480] net/mlx5e: Clear Read-Only port buffer size in PBMC before update 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (203 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 204/480] netfilter: xt_nfacct: dont assume acct name is null-terminated Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 206/480] net/mlx5e: Remove skb secpath if xfrm state is not found Greg Kroah-Hartman ` (286 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Alexei Lazar, Yael Chemla, Tariq Toukan, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Alexei Lazar <alazar@nvidia.com> [ Upstream commit fd4b97246a23c1149479b88490946bcfbd28de63 ] When updating the PBMC register, we read its current value, modify desired fields, then write it back. The port_buffer_size field within PBMC is Read-Only (RO). If this RO field contains a non-zero value when read, attempting to write it back will cause the entire PBMC register update to fail. This commit ensures port_buffer_size is explicitly cleared to zero after reading the PBMC register but before writing back the modified value. This allows updates to other fields in the PBMC register to succeed. Fixes: 0696d60853d5 ("net/mlx5e: Receive buffer configuration") Signed-off-by: Alexei Lazar <alazar@nvidia.com> Reviewed-by: Yael Chemla <ychemla@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1753256672-337784-2-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.c b/drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.c index 8e25f4ef5ccc..5ae787656a7c 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.c @@ -331,6 +331,9 @@ static int port_set_buffer(struct mlx5e_priv *priv, if (err) goto out; + /* RO bits should be set to 0 on write */ + MLX5_SET(pbmc_reg, in, port_buffer_size, 0); + err = mlx5e_port_set_pbmc(mdev, in); out: kfree(in); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 206/480] net/mlx5e: Remove skb secpath if xfrm state is not found 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (204 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 205/480] net/mlx5e: Clear Read-Only port buffer size in PBMC before update Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 207/480] macsec: set IFF_UNICAST_FLT priv flag Greg Kroah-Hartman ` (285 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Jianbo Liu, Dragos Tatulea, Yael Chemla, Tariq Toukan, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jianbo Liu <jianbol@nvidia.com> [ Upstream commit 6d19c44b5c6dd72f9a357d0399604ec16a77de3c ] Hardware returns a unique identifier for a decrypted packet's xfrm state, this state is looked up in an xarray. However, the state might have been freed by the time of this lookup. Currently, if the state is not found, only a counter is incremented. The secpath (sp) extension on the skb is not removed, resulting in sp->len becoming 0. Subsequently, functions like __xfrm_policy_check() attempt to access fields such as xfrm_input_state(skb)->xso.type (which dereferences sp->xvec[sp->len - 1]) without first validating sp->len. This leads to a crash when dereferencing an invalid state pointer. This patch prevents the crash by explicitly removing the secpath extension from the skb if the xfrm state is not found after hardware decryption. This ensures downstream functions do not operate on a zero-length secpath. BUG: unable to handle page fault for address: ffffffff000002c8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 282e067 P4D 282e067 PUD 0 Oops: Oops: 0000 [#1] SMP CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__xfrm_policy_check+0x61a/0xa30 Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa RSP: 0018:ffff88885fb04918 EFLAGS: 00010297 RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353 R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8 R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00 FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? try_to_wake_up+0x108/0x4c0 ? udp4_lib_lookup2+0xbe/0x150 ? udp_lib_lport_inuse+0x100/0x100 ? __udp4_lib_lookup+0x2b0/0x410 __xfrm_policy_check2.constprop.0+0x11e/0x130 udp_queue_rcv_one_skb+0x1d/0x530 udp_unicast_rcv_skb+0x76/0x90 __udp4_lib_rcv+0xa64/0xe90 ip_protocol_deliver_rcu+0x20/0x130 ip_local_deliver_finish+0x75/0xa0 ip_local_deliver+0xc1/0xd0 ? ip_protocol_deliver_rcu+0x130/0x130 ip_sublist_rcv+0x1f9/0x240 ? ip_rcv_finish_core+0x430/0x430 ip_list_rcv+0xfc/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x200/0x360 ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core] gro_receive_skb+0xfd/0x210 mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core] mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core] ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core] mlx5e_napi_poll+0x114/0xab0 [mlx5_core] __napi_poll+0x25/0x170 net_rx_action+0x32d/0x3a0 ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core] ? notifier_call_chain+0x33/0xa0 handle_softirqs+0xda/0x250 irq_exit_rcu+0x6d/0xc0 common_interrupt+0x81/0xa0 </IRQ> Fixes: b2ac7541e377 ("net/mlx5e: IPsec: Add Connect-X IPsec Rx data path offload") Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Yael Chemla <ychemla@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1753256672-337784-3-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c index 727fa7c18523..6056106edcc6 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c @@ -327,6 +327,10 @@ void mlx5e_ipsec_offload_handle_rx_skb(struct net_device *netdev, if (unlikely(!sa_entry)) { rcu_read_unlock(); atomic64_inc(&ipsec->sw_stats.ipsec_rx_drop_sadb_miss); + /* Clear secpath to prevent invalid dereference + * in downstream XFRM policy checks. + */ + secpath_reset(skb); return; } xfrm_state_hold(sa_entry->x); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 207/480] macsec: set IFF_UNICAST_FLT priv flag 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (205 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 206/480] net/mlx5e: Remove skb secpath if xfrm state is not found Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 208/480] net: dsa: microchip: Fix wrong rx drop MIB counter for KSZ8863 Greg Kroah-Hartman ` (284 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Simon Horman, Cosmin Ratiu, Stanislav Fomichev, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Stanislav Fomichev <sdf@fomichev.me> [ Upstream commit 0349659fd72f662c054ff20d432559bfaa228ce4 ] Cosmin reports the following locking issue: # BUG: sleeping function called from invalid context at kernel/locking/mutex.c:275 # dump_stack_lvl+0x4f/0x60 # __might_resched+0xeb/0x140 # mutex_lock+0x1a/0x40 # dev_set_promiscuity+0x26/0x90 # __dev_set_promiscuity+0x85/0x170 # __dev_set_rx_mode+0x69/0xa0 # dev_uc_add+0x6d/0x80 # vlan_dev_open+0x5f/0x120 [8021q] # __dev_open+0x10c/0x2a0 # __dev_change_flags+0x1a4/0x210 # netif_change_flags+0x22/0x60 # do_setlink.isra.0+0xdb0/0x10f0 # rtnl_newlink+0x797/0xb00 # rtnetlink_rcv_msg+0x1cb/0x3f0 # netlink_rcv_skb+0x53/0x100 # netlink_unicast+0x273/0x3b0 # netlink_sendmsg+0x1f2/0x430 Which is similar to recent syzkaller reports in [0] and [1] and triggers because macsec does not advertise IFF_UNICAST_FLT although it has proper ndo_set_rx_mode callback that takes care of pushing uc/mc addresses down to the real device. In general, dev_uc_add call path is problematic for stacking non-IFF_UNICAST_FLT because we might grab netdev instance lock under addr_list_lock spinlock, so this is not a systemic fix. 0: https://lore.kernel.org/netdev/686d55b4.050a0220.1ffab7.0014.GAE@google.com 1: https://lore.kernel.org/netdev/68712acf.a00a0220.26a83e.0051.GAE@google.com/ Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/netdev/2aff4342b0f5b1539c02ffd8df4c7e58dd9746e7.camel@nvidia.com Fixes: 7e4d784f5810 ("net: hold netdev instance lock during rtnetlink operations") Reported-by: Cosmin Ratiu <cratiu@nvidia.com> Tested-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20250723224715.1341121-1-sdf@fomichev.me Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/macsec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c index 7edbe76b5455..4c75d1fea552 100644 --- a/drivers/net/macsec.c +++ b/drivers/net/macsec.c @@ -3868,7 +3868,7 @@ static void macsec_setup(struct net_device *dev) ether_setup(dev); dev->min_mtu = 0; dev->max_mtu = ETH_MAX_MTU; - dev->priv_flags |= IFF_NO_QUEUE; + dev->priv_flags |= IFF_NO_QUEUE | IFF_UNICAST_FLT; dev->netdev_ops = &macsec_netdev_ops; dev->needs_free_netdev = true; dev->priv_destructor = macsec_free_netdev; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 208/480] net: dsa: microchip: Fix wrong rx drop MIB counter for KSZ8863 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (206 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 207/480] macsec: set IFF_UNICAST_FLT priv flag Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 209/480] neighbour: Fix null-ptr-deref in neigh_flush_dev() Greg Kroah-Hartman ` (283 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Tristram Ha, Oleksij Rempel, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Tristram Ha <tristram.ha@microchip.com> [ Upstream commit 165a7f5db919ab68a45ae755cceb751e067273ef ] When KSZ8863 support was first added to KSZ driver the RX drop MIB counter was somehow defined as 0x105. The TX drop MIB counter starts at 0x100 for port 1, 0x101 for port 2, and 0x102 for port 3, so the RX drop MIB counter should start at 0x103 for port 1, 0x104 for port 2, and 0x105 for port 3. There are 5 ports for KSZ8895, so its RX drop MIB counter starts at 0x105. Fixes: 4b20a07e103f ("net: dsa: microchip: ksz8795: add support for ksz88xx chips") Signed-off-by: Tristram Ha <tristram.ha@microchip.com> Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://patch.msgid.link/20250723030403.56878-1-Tristram.Ha@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/dsa/microchip/ksz8.c | 3 +++ drivers/net/dsa/microchip/ksz8_reg.h | 4 +++- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/dsa/microchip/ksz8.c b/drivers/net/dsa/microchip/ksz8.c index be433b4e2b1c..8f55be89f8bf 100644 --- a/drivers/net/dsa/microchip/ksz8.c +++ b/drivers/net/dsa/microchip/ksz8.c @@ -371,6 +371,9 @@ static void ksz8863_r_mib_pkt(struct ksz_device *dev, int port, u16 addr, addr -= dev->info->reg_mib_cnt; ctrl_addr = addr ? KSZ8863_MIB_PACKET_DROPPED_TX_0 : KSZ8863_MIB_PACKET_DROPPED_RX_0; + if (ksz_is_8895_family(dev) && + ctrl_addr == KSZ8863_MIB_PACKET_DROPPED_RX_0) + ctrl_addr = KSZ8895_MIB_PACKET_DROPPED_RX_0; ctrl_addr += port; ctrl_addr |= IND_ACC_TABLE(TABLE_MIB | TABLE_READ); diff --git a/drivers/net/dsa/microchip/ksz8_reg.h b/drivers/net/dsa/microchip/ksz8_reg.h index 329688603a58..da80e659c648 100644 --- a/drivers/net/dsa/microchip/ksz8_reg.h +++ b/drivers/net/dsa/microchip/ksz8_reg.h @@ -784,7 +784,9 @@ #define KSZ8795_MIB_TOTAL_TX_1 0x105 #define KSZ8863_MIB_PACKET_DROPPED_TX_0 0x100 -#define KSZ8863_MIB_PACKET_DROPPED_RX_0 0x105 +#define KSZ8863_MIB_PACKET_DROPPED_RX_0 0x103 + +#define KSZ8895_MIB_PACKET_DROPPED_RX_0 0x105 #define MIB_PACKET_DROPPED 0x0000FFFF -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 209/480] neighbour: Fix null-ptr-deref in neigh_flush_dev(). 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (207 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 208/480] net: dsa: microchip: Fix wrong rx drop MIB counter for KSZ8863 Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 210/480] stmmac: xsk: fix negative overflow of budget in zerocopy mode Greg Kroah-Hartman ` (282 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, kernel test robot, Kuniyuki Iwashima, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Kuniyuki Iwashima <kuniyu@google.com> [ Upstream commit 1bbb76a899486827394530916f01214d049931b3 ] kernel test robot reported null-ptr-deref in neigh_flush_dev(). [0] The cited commit introduced per-netdev neighbour list and converted neigh_flush_dev() to use it instead of the global hash table. One thing we missed is that neigh_table_clear() calls neigh_ifdown() with NULL dev. Let's restore the hash table iteration. Note that IPv6 module is no longer unloadable, so neigh_table_clear() is called only when IPv6 fails to initialise, which is unlikely to happen. [0]: IPv6: Attempt to unregister permanent protocol 136 IPv6: Attempt to unregister permanent protocol 17 Oops: general protection fault, probably for non-canonical address 0xdffffc00000001a0: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000d00-0x0000000000000d07] CPU: 1 UID: 0 PID: 1 Comm: systemd Tainted: G T 6.12.0-rc6-01246-gf7f52738637f #1 Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:neigh_flush_dev.llvm.6395807810224103582+0x52/0x570 Code: c1 e8 03 42 8a 04 38 84 c0 0f 85 15 05 00 00 31 c0 41 83 3e 0a 0f 94 c0 48 8d 1c c3 48 81 c3 f8 0c 00 00 48 89 d8 48 c1 e8 03 <42> 80 3c 38 00 74 08 48 89 df e8 f7 49 93 fe 4c 8b 3b 4d 85 ff 0f RSP: 0000:ffff88810026f408 EFLAGS: 00010206 RAX: 00000000000001a0 RBX: 0000000000000d00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffc0631640 RBP: ffff88810026f470 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffffffffc0625250 R14: ffffffffc0631640 R15: dffffc0000000000 FS: 00007f575cb83940(0000) GS:ffff8883aee00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f575db40008 CR3: 00000002bf936000 CR4: 00000000000406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __neigh_ifdown.llvm.6395807810224103582+0x44/0x390 neigh_table_clear+0xb1/0x268 ndisc_cleanup+0x21/0x38 [ipv6] init_module+0x2f5/0x468 [ipv6] do_one_initcall+0x1ba/0x628 do_init_module+0x21a/0x530 load_module+0x2550/0x2ea0 __se_sys_finit_module+0x3d2/0x620 __x64_sys_finit_module+0x76/0x88 x64_sys_call+0x7ff/0xde8 do_syscall_64+0xfb/0x1e8 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f575d6f2719 Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d b7 06 0d 00 f7 d8 64 89 01 48 RSP: 002b:00007fff82a2a268 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 0000557827b45310 RCX: 00007f575d6f2719 RDX: 0000000000000000 RSI: 00007f575d584efd RDI: 0000000000000004 RBP: 00007f575d584efd R08: 0000000000000000 R09: 0000557827b47b00 R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000020000 R13: 0000000000000000 R14: 0000557827b470e0 R15: 00007f575dbb4270 </TASK> Modules linked in: ipv6(+) Fixes: f7f52738637f4 ("neighbour: Create netdev->neighbour association") Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202507200931.7a89ecd8-lkp@intel.com Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20250723195443.448163-1-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/core/neighbour.c | 88 ++++++++++++++++++++++++++++++-------------- 1 file changed, 61 insertions(+), 27 deletions(-) diff --git a/net/core/neighbour.c b/net/core/neighbour.c index a07249b59ae1..559841334f1a 100644 --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -368,6 +368,43 @@ static void pneigh_queue_purge(struct sk_buff_head *list, struct net *net, } } +static void neigh_flush_one(struct neighbour *n) +{ + hlist_del_rcu(&n->hash); + hlist_del_rcu(&n->dev_list); + + write_lock(&n->lock); + + neigh_del_timer(n); + neigh_mark_dead(n); + + if (refcount_read(&n->refcnt) != 1) { + /* The most unpleasant situation. + * We must destroy neighbour entry, + * but someone still uses it. + * + * The destroy will be delayed until + * the last user releases us, but + * we must kill timers etc. and move + * it to safe state. + */ + __skb_queue_purge(&n->arp_queue); + n->arp_queue_len_bytes = 0; + WRITE_ONCE(n->output, neigh_blackhole); + + if (n->nud_state & NUD_VALID) + n->nud_state = NUD_NOARP; + else + n->nud_state = NUD_NONE; + + neigh_dbg(2, "neigh %p is stray\n", n); + } + + write_unlock(&n->lock); + + neigh_cleanup_and_release(n); +} + static void neigh_flush_dev(struct neigh_table *tbl, struct net_device *dev, bool skip_perm) { @@ -381,32 +418,24 @@ static void neigh_flush_dev(struct neigh_table *tbl, struct net_device *dev, if (skip_perm && n->nud_state & NUD_PERMANENT) continue; - hlist_del_rcu(&n->hash); - hlist_del_rcu(&n->dev_list); - write_lock(&n->lock); - neigh_del_timer(n); - neigh_mark_dead(n); - if (refcount_read(&n->refcnt) != 1) { - /* The most unpleasant situation. - * We must destroy neighbour entry, - * but someone still uses it. - * - * The destroy will be delayed until - * the last user releases us, but - * we must kill timers etc. and move - * it to safe state. - */ - __skb_queue_purge(&n->arp_queue); - n->arp_queue_len_bytes = 0; - WRITE_ONCE(n->output, neigh_blackhole); - if (n->nud_state & NUD_VALID) - n->nud_state = NUD_NOARP; - else - n->nud_state = NUD_NONE; - neigh_dbg(2, "neigh %p is stray\n", n); - } - write_unlock(&n->lock); - neigh_cleanup_and_release(n); + neigh_flush_one(n); + } +} + +static void neigh_flush_table(struct neigh_table *tbl) +{ + struct neigh_hash_table *nht; + int i; + + nht = rcu_dereference_protected(tbl->nht, + lockdep_is_held(&tbl->lock)); + + for (i = 0; i < (1 << nht->hash_shift); i++) { + struct hlist_node *tmp; + struct neighbour *n; + + neigh_for_each_in_bucket_safe(n, tmp, &nht->hash_heads[i]) + neigh_flush_one(n); } } @@ -422,7 +451,12 @@ static int __neigh_ifdown(struct neigh_table *tbl, struct net_device *dev, bool skip_perm) { write_lock_bh(&tbl->lock); - neigh_flush_dev(tbl, dev, skip_perm); + if (likely(dev)) { + neigh_flush_dev(tbl, dev, skip_perm); + } else { + DEBUG_NET_WARN_ON_ONCE(skip_perm); + neigh_flush_table(tbl); + } pneigh_ifdown_and_unlock(tbl, dev); pneigh_queue_purge(&tbl->proxy_queue, dev ? dev_net(dev) : NULL, tbl->family); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 210/480] stmmac: xsk: fix negative overflow of budget in zerocopy mode 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (208 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 209/480] neighbour: Fix null-ptr-deref in neigh_flush_dev() Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:46 ` [PATCH 6.15 211/480] igb: xsk: solve negative overflow of nb_pkts " Greg Kroah-Hartman ` (281 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Jason Xing, Aleksandr Loktionov, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jason Xing <kernelxing@tencent.com> [ Upstream commit 2764ab51d5f0e8c7d3b7043af426b1883e3bde1d ] A negative overflow can happen when the budget number of descs are consumed. as long as the budget is decreased to zero, it will again go into while (budget-- > 0) statement and get decreased by one, so the overflow issue can happen. It will lead to returning true whereas the expected value should be false. In this case where all the budget is used up, it means zc function should return false to let the poll run again because normally we might have more data to process. Without this patch, zc function would return true instead. Fixes: 132c32ee5bc0 ("net: stmmac: Add TX via XDP zero-copy socket") Signed-off-by: Jason Xing <kernelxing@tencent.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Link: https://patch.msgid.link/20250723142327.85187-2-kerneljasonxing@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index 1d716cee0cb1..77f800df6f37 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -2585,7 +2585,7 @@ static bool stmmac_xdp_xmit_zc(struct stmmac_priv *priv, u32 queue, u32 budget) budget = min(budget, stmmac_tx_avail(priv, queue)); - while (budget-- > 0) { + for (; budget > 0; budget--) { struct stmmac_metadata_request meta_req; struct xsk_tx_metadata *meta = NULL; dma_addr_t dma_addr; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 211/480] igb: xsk: solve negative overflow of nb_pkts in zerocopy mode 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (209 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 210/480] stmmac: xsk: fix negative overflow of budget in zerocopy mode Greg Kroah-Hartman @ 2025-08-12 17:46 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 212/480] selftests: rtnetlink.sh: remove esp4_offload after test Greg Kroah-Hartman ` (280 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:46 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Jason Xing, Aleksandr Loktionov, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jason Xing <kernelxing@tencent.com> [ Upstream commit 3b7c13dfdcc26a78756cc17a23cdf4310c5a24a9 ] There is no break time in the while() loop, so every time at the end of igb_xmit_zc(), negative overflow of nb_pkts will occur, which renders the return value always false. But theoretically, the result should be set after calling xsk_tx_peek_release_desc_batch(). We can take i40e_xmit_zc() as a good example. Returning false means we're not done with transmission and we need one more poll, which is exactly what igb_xmit_zc() always did before this patch. After this patch, the return value depends on the nb_pkts value. Two cases might happen then: 1. if (nb_pkts < budget), it means we process all the possible data, so return true and no more necessary poll will be triggered because of this. 2. if (nb_pkts == budget), it means we might have more data, so return false to let another poll run again. Fixes: f8e284a02afc ("igb: Add AF_XDP zero-copy Tx support") Signed-off-by: Jason Xing <kernelxing@tencent.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Link: https://patch.msgid.link/20250723142327.85187-3-kerneljasonxing@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/ethernet/intel/igb/igb_xsk.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/igb/igb_xsk.c b/drivers/net/ethernet/intel/igb/igb_xsk.c index 157d43787fa0..02935d4e1140 100644 --- a/drivers/net/ethernet/intel/igb/igb_xsk.c +++ b/drivers/net/ethernet/intel/igb/igb_xsk.c @@ -481,7 +481,7 @@ bool igb_xmit_zc(struct igb_ring *tx_ring, struct xsk_buff_pool *xsk_pool) if (!nb_pkts) return true; - while (nb_pkts-- > 0) { + for (; i < nb_pkts; i++) { dma = xsk_buff_raw_get_dma(xsk_pool, descs[i].addr); xsk_buff_raw_dma_sync_for_device(xsk_pool, dma, descs[i].len); @@ -511,7 +511,6 @@ bool igb_xmit_zc(struct igb_ring *tx_ring, struct xsk_buff_pool *xsk_pool) total_bytes += descs[i].len; - i++; tx_ring->next_to_use++; tx_buffer_info->next_to_watch = tx_desc; if (tx_ring->next_to_use == tx_ring->count) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 212/480] selftests: rtnetlink.sh: remove esp4_offload after test 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (210 preceding siblings ...) 2025-08-12 17:46 ` [PATCH 6.15 211/480] igb: xsk: solve negative overflow of nb_pkts " Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 213/480] vrf: Drop existing dst reference in vrf_ip6_input_dst Greg Kroah-Hartman ` (279 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Xiumei Mu, Shannon Nelson, Hangbin Liu, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Xiumei Mu <xmu@redhat.com> [ Upstream commit 5b32321fdaf3fd1a92ec726af18765e225b0ee2b ] The esp4_offload module, loaded during IPsec offload tests, should be reset to its default settings after testing. Otherwise, leaving it enabled could unintentionally affect subsequence test cases by keeping offload active. Without this fix: $ lsmod | grep offload; ./rtnetlink.sh -t kci_test_ipsec_offload ; lsmod | grep offload; PASS: ipsec_offload esp4_offload 12288 0 esp4 32768 1 esp4_offload With this fix: $ lsmod | grep offload; ./rtnetlink.sh -t kci_test_ipsec_offload ; lsmod | grep offload; PASS: ipsec_offload Fixes: 2766a11161cc ("selftests: rtnetlink: add ipsec offload API test") Signed-off-by: Xiumei Mu <xmu@redhat.com> Reviewed-by: Shannon Nelson <sln@onemain.com> Reviewed-by: Hangbin Liu <liuhangbin@gmail.com> Link: https://patch.msgid.link/6d3a1d777c4de4eb0ca94ced9e77be8d48c5b12f.1753415428.git.xmu@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/testing/selftests/net/rtnetlink.sh | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/tools/testing/selftests/net/rtnetlink.sh b/tools/testing/selftests/net/rtnetlink.sh index 2e8243a65b50..d2298da320a6 100755 --- a/tools/testing/selftests/net/rtnetlink.sh +++ b/tools/testing/selftests/net/rtnetlink.sh @@ -673,6 +673,11 @@ kci_test_ipsec_offload() sysfsf=$sysfsd/ipsec sysfsnet=/sys/bus/netdevsim/devices/netdevsim0/net/ probed=false + esp4_offload_probed_default=false + + if lsmod | grep -q esp4_offload; then + esp4_offload_probed_default=true + fi if ! mount | grep -q debugfs; then mount -t debugfs none /sys/kernel/debug/ &> /dev/null @@ -766,6 +771,7 @@ EOF fi # clean up any leftovers + ! "$esp4_offload_probed_default" && lsmod | grep -q esp4_offload && rmmod esp4_offload echo 0 > /sys/bus/netdevsim/del_device $probed && rmmod netdevsim -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 213/480] vrf: Drop existing dst reference in vrf_ip6_input_dst 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (211 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 212/480] selftests: rtnetlink.sh: remove esp4_offload after test Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 214/480] ipv6: prevent infinite loop in rt6_nlmsg_size() Greg Kroah-Hartman ` (278 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, David Ahern, Ido Schimmel, Stanislav Fomichev, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Stanislav Fomichev <sdf@fomichev.me> [ Upstream commit f388f807eca1de9e6e70f9ffb1a573c3811c4215 ] Commit ff3fbcdd4724 ("selftests: tc: Add generic erspan_opts matching support for tc-flower") started triggering the following kmemleak warning: unreferenced object 0xffff888015fb0e00 (size 512): comm "softirq", pid 0, jiffies 4294679065 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 40 d2 85 9e ff ff ff ff ........@....... 41 69 59 9d ff ff ff ff 00 00 00 00 00 00 00 00 AiY............. backtrace (crc 30b71e8b): __kmalloc_noprof+0x359/0x460 metadata_dst_alloc+0x28/0x490 erspan_rcv+0x4f1/0x1160 [ip_gre] gre_rcv+0x217/0x240 [ip_gre] gre_rcv+0x1b8/0x400 [gre] ip_protocol_deliver_rcu+0x31d/0x3a0 ip_local_deliver_finish+0x37d/0x620 ip_local_deliver+0x174/0x460 ip_rcv+0x52b/0x6b0 __netif_receive_skb_one_core+0x149/0x1a0 process_backlog+0x3c8/0x1390 __napi_poll.constprop.0+0xa1/0x390 net_rx_action+0x59b/0xe00 handle_softirqs+0x22b/0x630 do_softirq+0xb1/0xf0 __local_bh_enable_ip+0x115/0x150 vrf_ip6_input_dst unconditionally sets skb dst entry, add a call to skb_dst_drop to drop any existing entry. Cc: David Ahern <dsahern@kernel.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Fixes: 9ff74384600a ("net: vrf: Handle ipv6 multicast and link-local addresses") Signed-off-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20250725160043.350725-1-sdf@fomichev.me Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/vrf.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c index 7168b33adadb..8b12b3ae580d 100644 --- a/drivers/net/vrf.c +++ b/drivers/net/vrf.c @@ -1304,6 +1304,8 @@ static void vrf_ip6_input_dst(struct sk_buff *skb, struct net_device *vrf_dev, struct net *net = dev_net(vrf_dev); struct rt6_info *rt6; + skb_dst_drop(skb); + rt6 = vrf_ip6_route_lookup(net, vrf_dev, &fl6, ifindex, skb, RT6_LOOKUP_F_HAS_SADDR | RT6_LOOKUP_F_IFACE); if (unlikely(!rt6)) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 214/480] ipv6: prevent infinite loop in rt6_nlmsg_size() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (212 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 213/480] vrf: Drop existing dst reference in vrf_ip6_input_dst Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 215/480] ipv6: fix possible infinite loop in fib6_info_uses_dev() Greg Kroah-Hartman ` (277 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Eric Dumazet, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Eric Dumazet <edumazet@google.com> [ Upstream commit 54e6fe9dd3b0e7c481c2228782c9494d653546da ] While testing prior patch, I was able to trigger an infinite loop in rt6_nlmsg_size() in the following place: list_for_each_entry_rcu(sibling, &f6i->fib6_siblings, fib6_siblings) { rt6_nh_nlmsg_size(sibling->fib6_nh, &nexthop_len); } This is because fib6_del_route() and fib6_add_rt2node() uses list_del_rcu(), which can confuse rcu readers, because they might no longer see the head of the list. Restart the loop if f6i->fib6_nsiblings is zero. Fixes: d9ccb18f83ea ("ipv6: Fix soft lockups in fib6_select_path under high next hop churn") Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20250725140725.3626540-3-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/ipv6/ip6_fib.c | 4 ++-- net/ipv6/route.c | 34 ++++++++++++++++++---------------- 2 files changed, 20 insertions(+), 18 deletions(-) diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c index bf727149fdec..d7cf38f91c5b 100644 --- a/net/ipv6/ip6_fib.c +++ b/net/ipv6/ip6_fib.c @@ -1244,7 +1244,7 @@ static int fib6_add_rt2node(struct fib6_node *fn, struct fib6_info *rt, &rt->fib6_siblings, fib6_siblings) sibling->fib6_nsiblings--; - rt->fib6_nsiblings = 0; + WRITE_ONCE(rt->fib6_nsiblings, 0); list_del_rcu(&rt->fib6_siblings); rt6_multipath_rebalance(next_sibling); return err; @@ -1962,7 +1962,7 @@ static void fib6_del_route(struct fib6_table *table, struct fib6_node *fn, list_for_each_entry_safe(sibling, next_sibling, &rt->fib6_siblings, fib6_siblings) sibling->fib6_nsiblings--; - rt->fib6_nsiblings = 0; + WRITE_ONCE(rt->fib6_nsiblings, 0); list_del_rcu(&rt->fib6_siblings); rt6_multipath_rebalance(next_sibling); } diff --git a/net/ipv6/route.c b/net/ipv6/route.c index 96f1621e2381..ebb4abd5e69e 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -5596,32 +5596,34 @@ static int rt6_nh_nlmsg_size(struct fib6_nh *nh, void *arg) static size_t rt6_nlmsg_size(struct fib6_info *f6i) { + struct fib6_info *sibling; + struct fib6_nh *nh; int nexthop_len; if (f6i->nh) { nexthop_len = nla_total_size(4); /* RTA_NH_ID */ nexthop_for_each_fib6_nh(f6i->nh, rt6_nh_nlmsg_size, &nexthop_len); - } else { - struct fib6_nh *nh = f6i->fib6_nh; - struct fib6_info *sibling; - - nexthop_len = 0; - if (f6i->fib6_nsiblings) { - rt6_nh_nlmsg_size(nh, &nexthop_len); - - rcu_read_lock(); + goto common; + } - list_for_each_entry_rcu(sibling, &f6i->fib6_siblings, - fib6_siblings) { - rt6_nh_nlmsg_size(sibling->fib6_nh, &nexthop_len); - } + rcu_read_lock(); +retry: + nh = f6i->fib6_nh; + nexthop_len = 0; + if (READ_ONCE(f6i->fib6_nsiblings)) { + rt6_nh_nlmsg_size(nh, &nexthop_len); - rcu_read_unlock(); + list_for_each_entry_rcu(sibling, &f6i->fib6_siblings, + fib6_siblings) { + rt6_nh_nlmsg_size(sibling->fib6_nh, &nexthop_len); + if (!READ_ONCE(f6i->fib6_nsiblings)) + goto retry; } - nexthop_len += lwtunnel_get_encap_size(nh->fib_nh_lws); } - + rcu_read_unlock(); + nexthop_len += lwtunnel_get_encap_size(nh->fib_nh_lws); +common: return NLMSG_ALIGN(sizeof(struct rtmsg)) + nla_total_size(16) /* RTA_SRC */ + nla_total_size(16) /* RTA_DST */ -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 215/480] ipv6: fix possible infinite loop in fib6_info_uses_dev() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (213 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 214/480] ipv6: prevent infinite loop in rt6_nlmsg_size() Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 216/480] ipv6: annotate data-races around rt->fib6_nsiblings Greg Kroah-Hartman ` (276 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Eric Dumazet, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Eric Dumazet <edumazet@google.com> [ Upstream commit f8d8ce1b515a0a6af72b30502670a406cfb75073 ] fib6_info_uses_dev() seems to rely on RCU without an explicit protection. Like the prior fix in rt6_nlmsg_size(), we need to make sure fib6_del_route() or fib6_add_rt2node() have not removed the anchor from the list, or we risk an infinite loop. Fixes: d9ccb18f83ea ("ipv6: Fix soft lockups in fib6_select_path under high next hop churn") Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20250725140725.3626540-4-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/ipv6/route.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/net/ipv6/route.c b/net/ipv6/route.c index ebb4abd5e69e..506afe11fe3c 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -5884,16 +5884,21 @@ static bool fib6_info_uses_dev(const struct fib6_info *f6i, if (f6i->fib6_nh->fib_nh_dev == dev) return true; - if (f6i->fib6_nsiblings) { - struct fib6_info *sibling, *next_sibling; + if (READ_ONCE(f6i->fib6_nsiblings)) { + const struct fib6_info *sibling; - list_for_each_entry_safe(sibling, next_sibling, - &f6i->fib6_siblings, fib6_siblings) { - if (sibling->fib6_nh->fib_nh_dev == dev) + rcu_read_lock(); + list_for_each_entry_rcu(sibling, &f6i->fib6_siblings, + fib6_siblings) { + if (sibling->fib6_nh->fib_nh_dev == dev) { + rcu_read_unlock(); return true; + } + if (!READ_ONCE(f6i->fib6_nsiblings)) + break; } + rcu_read_unlock(); } - return false; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 216/480] ipv6: annotate data-races around rt->fib6_nsiblings 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (214 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 215/480] ipv6: fix possible infinite loop in fib6_info_uses_dev() Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 217/480] bpf/preload: Dont select USERMODE_DRIVER Greg Kroah-Hartman ` (275 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Eric Dumazet, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Eric Dumazet <edumazet@google.com> [ Upstream commit 31d7d67ba1274f42494256d52e86da80ed09f3cb ] rt->fib6_nsiblings can be read locklessly, add corresponding READ_ONCE() and WRITE_ONCE() annotations. Fixes: 66f5d6ce53e6 ("ipv6: replace rwlock with rcu and spinlock in fib6_table") Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20250725140725.3626540-5-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/ipv6/ip6_fib.c | 20 +++++++++++++------- net/ipv6/route.c | 5 +++-- 2 files changed, 16 insertions(+), 9 deletions(-) diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c index d7cf38f91c5b..3ac7e15d8d23 100644 --- a/net/ipv6/ip6_fib.c +++ b/net/ipv6/ip6_fib.c @@ -433,15 +433,17 @@ struct fib6_dump_arg { static int fib6_rt_dump(struct fib6_info *rt, struct fib6_dump_arg *arg) { enum fib_event_type fib_event = FIB_EVENT_ENTRY_REPLACE; + unsigned int nsiblings; int err; if (!rt || rt == arg->net->ipv6.fib6_null_entry) return 0; - if (rt->fib6_nsiblings) + nsiblings = READ_ONCE(rt->fib6_nsiblings); + if (nsiblings) err = call_fib6_multipath_entry_notifier(arg->nb, fib_event, rt, - rt->fib6_nsiblings, + nsiblings, arg->extack); else err = call_fib6_entry_notifier(arg->nb, fib_event, rt, @@ -1119,7 +1121,7 @@ static int fib6_add_rt2node(struct fib6_node *fn, struct fib6_info *rt, if (rt6_duplicate_nexthop(iter, rt)) { if (rt->fib6_nsiblings) - rt->fib6_nsiblings = 0; + WRITE_ONCE(rt->fib6_nsiblings, 0); if (!(iter->fib6_flags & RTF_EXPIRES)) return -EEXIST; if (!(rt->fib6_flags & RTF_EXPIRES)) { @@ -1148,7 +1150,8 @@ static int fib6_add_rt2node(struct fib6_node *fn, struct fib6_info *rt, */ if (rt_can_ecmp && rt6_qualify_for_ecmp(iter)) - rt->fib6_nsiblings++; + WRITE_ONCE(rt->fib6_nsiblings, + rt->fib6_nsiblings + 1); } if (iter->fib6_metric > rt->fib6_metric) @@ -1198,7 +1201,8 @@ static int fib6_add_rt2node(struct fib6_node *fn, struct fib6_info *rt, fib6_nsiblings = 0; list_for_each_entry_safe(sibling, temp_sibling, &rt->fib6_siblings, fib6_siblings) { - sibling->fib6_nsiblings++; + WRITE_ONCE(sibling->fib6_nsiblings, + sibling->fib6_nsiblings + 1); BUG_ON(sibling->fib6_nsiblings != rt->fib6_nsiblings); fib6_nsiblings++; } @@ -1243,7 +1247,8 @@ static int fib6_add_rt2node(struct fib6_node *fn, struct fib6_info *rt, list_for_each_entry_safe(sibling, next_sibling, &rt->fib6_siblings, fib6_siblings) - sibling->fib6_nsiblings--; + WRITE_ONCE(sibling->fib6_nsiblings, + sibling->fib6_nsiblings - 1); WRITE_ONCE(rt->fib6_nsiblings, 0); list_del_rcu(&rt->fib6_siblings); rt6_multipath_rebalance(next_sibling); @@ -1961,7 +1966,8 @@ static void fib6_del_route(struct fib6_table *table, struct fib6_node *fn, notify_del = true; list_for_each_entry_safe(sibling, next_sibling, &rt->fib6_siblings, fib6_siblings) - sibling->fib6_nsiblings--; + WRITE_ONCE(sibling->fib6_nsiblings, + sibling->fib6_nsiblings - 1); WRITE_ONCE(rt->fib6_nsiblings, 0); list_del_rcu(&rt->fib6_siblings); rt6_multipath_rebalance(next_sibling); diff --git a/net/ipv6/route.c b/net/ipv6/route.c index 506afe11fe3c..aa1341fc9933 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -5249,7 +5249,8 @@ static void ip6_route_mpath_notify(struct fib6_info *rt, */ rcu_read_lock(); - if ((nlflags & NLM_F_APPEND) && rt_last && rt_last->fib6_nsiblings) { + if ((nlflags & NLM_F_APPEND) && rt_last && + READ_ONCE(rt_last->fib6_nsiblings)) { rt = list_first_or_null_rcu(&rt_last->fib6_siblings, struct fib6_info, fib6_siblings); @@ -5782,7 +5783,7 @@ static int rt6_fill_node(struct net *net, struct sk_buff *skb, if (dst->lwtstate && lwtunnel_fill_encap(skb, dst->lwtstate, RTA_ENCAP, RTA_ENCAP_TYPE) < 0) goto nla_put_failure; - } else if (rt->fib6_nsiblings) { + } else if (READ_ONCE(rt->fib6_nsiblings)) { struct fib6_info *sibling; struct nlattr *mp; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 217/480] bpf/preload: Dont select USERMODE_DRIVER 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (215 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 216/480] ipv6: annotate data-races around rt->fib6_nsiblings Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 218/480] bpf, arm64: Fix fp initialization for exception boundary Greg Kroah-Hartman ` (274 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Thomas Weißschuh, Daniel Borkmann, Christoph Hellwig, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Weißschuh <thomas.weissschuh@linutronix.de> [ Upstream commit 2b03164eee20eac7ce0fe3aa4fbda7efc1e5427a ] The usermode driver framework is not used anymore by the BPF preload code. Fixes: cb80ddc67152 ("bpf: Convert bpf_preload.ko to use light skeleton.") Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/bpf/20250721-remove-usermode-driver-v1-1-0d0083334382@linutronix.de Signed-off-by: Sasha Levin <sashal@kernel.org> --- kernel/bpf/preload/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/bpf/preload/Kconfig b/kernel/bpf/preload/Kconfig index c9d45c9d6918..f9b11d01c3b5 100644 --- a/kernel/bpf/preload/Kconfig +++ b/kernel/bpf/preload/Kconfig @@ -10,7 +10,6 @@ menuconfig BPF_PRELOAD # The dependency on !COMPILE_TEST prevents it from being enabled # in allmodconfig or allyesconfig configurations depends on !COMPILE_TEST - select USERMODE_DRIVER help This builds kernel module with several embedded BPF programs that are pinned into BPF FS mount point as human readable files that are -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 218/480] bpf, arm64: Fix fp initialization for exception boundary 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (216 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 217/480] bpf/preload: Dont select USERMODE_DRIVER Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 219/480] RISC-V: KVM: Fix inclusion of Smnpm in the guest ISA bitmap Greg Kroah-Hartman ` (273 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Puranjay Mohan, Daniel Borkmann, Xu Kuohai, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Puranjay Mohan <puranjay@kernel.org> [ Upstream commit b114fcee766d5101eada1aca7bb5fd0a86c89b35 ] In the ARM64 BPF JIT when prog->aux->exception_boundary is set for a BPF program, find_used_callee_regs() is not called because for a program acting as exception boundary, all callee saved registers are saved. find_used_callee_regs() sets `ctx->fp_used = true;` when it sees FP being used in any of the instructions. For programs acting as exception boundary, ctx->fp_used remains false even if frame pointer is used by the program and therefore, FP is not set-up for such programs in the prologue. This can cause the kernel to crash due to a pagefault. Fix it by setting ctx->fp_used = true for exception boundary programs as fp is always saved in such programs. Fixes: 5d4fa9ec5643 ("bpf, arm64: Avoid blindly saving/restoring all callee-saved registers") Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Xu Kuohai <xukuohai@huawei.com> Link: https://lore.kernel.org/bpf/20250722133410.54161-2-puranjay@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm64/net/bpf_jit_comp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c index 634d78422adb..a85236d0afee 100644 --- a/arch/arm64/net/bpf_jit_comp.c +++ b/arch/arm64/net/bpf_jit_comp.c @@ -412,6 +412,7 @@ static void push_callee_regs(struct jit_ctx *ctx) emit(A64_PUSH(A64_R(23), A64_R(24), A64_SP), ctx); emit(A64_PUSH(A64_R(25), A64_R(26), A64_SP), ctx); emit(A64_PUSH(A64_R(27), A64_R(28), A64_SP), ctx); + ctx->fp_used = true; } else { find_used_callee_regs(ctx); for (i = 0; i + 1 < ctx->nr_used_callee_reg; i += 2) { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 219/480] RISC-V: KVM: Fix inclusion of Smnpm in the guest ISA bitmap 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (217 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 218/480] bpf, arm64: Fix fp initialization for exception boundary Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 220/480] rv: Adjust monitor dependencies Greg Kroah-Hartman ` (272 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Samuel Holland, Anup Patel, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Samuel Holland <samuel.holland@sifive.com> [ Upstream commit 7826c8f37220daabf90c09fcd9a835d6763f1372 ] The Smnpm extension requires special handling because the guest ISA extension maps to a different extension (Ssnpm) on the host side. commit 1851e7836212 ("RISC-V: KVM: Allow Smnpm and Ssnpm extensions for guests") missed that the vcpu->arch.isa bit is based only on the host extension, so currently both KVM_RISCV_ISA_EXT_{SMNPM,SSNPM} map to vcpu->arch.isa[RISCV_ISA_EXT_SSNPM]. This does not cause any problems for the guest, because both extensions are force-enabled anyway when the host supports Ssnpm, but prevents checking for (guest) Smnpm in the SBI FWFT logic. Redefine kvm_isa_ext_arr to look up the guest extension, since only the guest -> host mapping is unambiguous. Factor out the logic for checking for host support of an extension, so this special case only needs to be handled in one place, and be explicit about which variables hold a host vs a guest ISA extension. Fixes: 1851e7836212 ("RISC-V: KVM: Allow Smnpm and Ssnpm extensions for guests") Signed-off-by: Samuel Holland <samuel.holland@sifive.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20250111004702.2813013-2-samuel.holland@sifive.com Signed-off-by: Anup Patel <anup@brainfault.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/riscv/kvm/vcpu_onereg.c | 83 +++++++++++++++++++++++------------- 1 file changed, 53 insertions(+), 30 deletions(-) diff --git a/arch/riscv/kvm/vcpu_onereg.c b/arch/riscv/kvm/vcpu_onereg.c index 2e1b646f0d61..cce6a38ea54f 100644 --- a/arch/riscv/kvm/vcpu_onereg.c +++ b/arch/riscv/kvm/vcpu_onereg.c @@ -23,7 +23,7 @@ #define KVM_ISA_EXT_ARR(ext) \ [KVM_RISCV_ISA_EXT_##ext] = RISCV_ISA_EXT_##ext -/* Mapping between KVM ISA Extension ID & Host ISA extension ID */ +/* Mapping between KVM ISA Extension ID & guest ISA extension ID */ static const unsigned long kvm_isa_ext_arr[] = { /* Single letter extensions (alphabetically sorted) */ [KVM_RISCV_ISA_EXT_A] = RISCV_ISA_EXT_a, @@ -35,7 +35,7 @@ static const unsigned long kvm_isa_ext_arr[] = { [KVM_RISCV_ISA_EXT_M] = RISCV_ISA_EXT_m, [KVM_RISCV_ISA_EXT_V] = RISCV_ISA_EXT_v, /* Multi letter extensions (alphabetically sorted) */ - [KVM_RISCV_ISA_EXT_SMNPM] = RISCV_ISA_EXT_SSNPM, + KVM_ISA_EXT_ARR(SMNPM), KVM_ISA_EXT_ARR(SMSTATEEN), KVM_ISA_EXT_ARR(SSAIA), KVM_ISA_EXT_ARR(SSCOFPMF), @@ -112,6 +112,36 @@ static unsigned long kvm_riscv_vcpu_base2isa_ext(unsigned long base_ext) return KVM_RISCV_ISA_EXT_MAX; } +static int kvm_riscv_vcpu_isa_check_host(unsigned long kvm_ext, unsigned long *guest_ext) +{ + unsigned long host_ext; + + if (kvm_ext >= KVM_RISCV_ISA_EXT_MAX || + kvm_ext >= ARRAY_SIZE(kvm_isa_ext_arr)) + return -ENOENT; + + *guest_ext = kvm_isa_ext_arr[kvm_ext]; + switch (*guest_ext) { + case RISCV_ISA_EXT_SMNPM: + /* + * Pointer masking effective in (H)S-mode is provided by the + * Smnpm extension, so that extension is reported to the guest, + * even though the CSR bits for configuring VS-mode pointer + * masking on the host side are part of the Ssnpm extension. + */ + host_ext = RISCV_ISA_EXT_SSNPM; + break; + default: + host_ext = *guest_ext; + break; + } + + if (!__riscv_isa_extension_available(NULL, host_ext)) + return -ENOENT; + + return 0; +} + static bool kvm_riscv_vcpu_isa_enable_allowed(unsigned long ext) { switch (ext) { @@ -219,13 +249,13 @@ static bool kvm_riscv_vcpu_isa_disable_allowed(unsigned long ext) void kvm_riscv_vcpu_setup_isa(struct kvm_vcpu *vcpu) { - unsigned long host_isa, i; + unsigned long guest_ext, i; for (i = 0; i < ARRAY_SIZE(kvm_isa_ext_arr); i++) { - host_isa = kvm_isa_ext_arr[i]; - if (__riscv_isa_extension_available(NULL, host_isa) && - kvm_riscv_vcpu_isa_enable_allowed(i)) - set_bit(host_isa, vcpu->arch.isa); + if (kvm_riscv_vcpu_isa_check_host(i, &guest_ext)) + continue; + if (kvm_riscv_vcpu_isa_enable_allowed(i)) + set_bit(guest_ext, vcpu->arch.isa); } } @@ -607,18 +637,15 @@ static int riscv_vcpu_get_isa_ext_single(struct kvm_vcpu *vcpu, unsigned long reg_num, unsigned long *reg_val) { - unsigned long host_isa_ext; - - if (reg_num >= KVM_RISCV_ISA_EXT_MAX || - reg_num >= ARRAY_SIZE(kvm_isa_ext_arr)) - return -ENOENT; + unsigned long guest_ext; + int ret; - host_isa_ext = kvm_isa_ext_arr[reg_num]; - if (!__riscv_isa_extension_available(NULL, host_isa_ext)) - return -ENOENT; + ret = kvm_riscv_vcpu_isa_check_host(reg_num, &guest_ext); + if (ret) + return ret; *reg_val = 0; - if (__riscv_isa_extension_available(vcpu->arch.isa, host_isa_ext)) + if (__riscv_isa_extension_available(vcpu->arch.isa, guest_ext)) *reg_val = 1; /* Mark the given extension as available */ return 0; @@ -628,17 +655,14 @@ static int riscv_vcpu_set_isa_ext_single(struct kvm_vcpu *vcpu, unsigned long reg_num, unsigned long reg_val) { - unsigned long host_isa_ext; - - if (reg_num >= KVM_RISCV_ISA_EXT_MAX || - reg_num >= ARRAY_SIZE(kvm_isa_ext_arr)) - return -ENOENT; + unsigned long guest_ext; + int ret; - host_isa_ext = kvm_isa_ext_arr[reg_num]; - if (!__riscv_isa_extension_available(NULL, host_isa_ext)) - return -ENOENT; + ret = kvm_riscv_vcpu_isa_check_host(reg_num, &guest_ext); + if (ret) + return ret; - if (reg_val == test_bit(host_isa_ext, vcpu->arch.isa)) + if (reg_val == test_bit(guest_ext, vcpu->arch.isa)) return 0; if (!vcpu->arch.ran_atleast_once) { @@ -648,10 +672,10 @@ static int riscv_vcpu_set_isa_ext_single(struct kvm_vcpu *vcpu, */ if (reg_val == 1 && kvm_riscv_vcpu_isa_enable_allowed(reg_num)) - set_bit(host_isa_ext, vcpu->arch.isa); + set_bit(guest_ext, vcpu->arch.isa); else if (!reg_val && kvm_riscv_vcpu_isa_disable_allowed(reg_num)) - clear_bit(host_isa_ext, vcpu->arch.isa); + clear_bit(guest_ext, vcpu->arch.isa); else return -EINVAL; kvm_riscv_vcpu_fp_reset(vcpu); @@ -1009,16 +1033,15 @@ static int copy_fp_d_reg_indices(const struct kvm_vcpu *vcpu, static int copy_isa_ext_reg_indices(const struct kvm_vcpu *vcpu, u64 __user *uindices) { + unsigned long guest_ext; unsigned int n = 0; - unsigned long isa_ext; for (int i = 0; i < KVM_RISCV_ISA_EXT_MAX; i++) { u64 size = IS_ENABLED(CONFIG_32BIT) ? KVM_REG_SIZE_U32 : KVM_REG_SIZE_U64; u64 reg = KVM_REG_RISCV | size | KVM_REG_RISCV_ISA_EXT | i; - isa_ext = kvm_isa_ext_arr[i]; - if (!__riscv_isa_extension_available(NULL, isa_ext)) + if (kvm_riscv_vcpu_isa_check_host(i, &guest_ext)) continue; if (uindices) { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 220/480] rv: Adjust monitor dependencies 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (218 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 219/480] RISC-V: KVM: Fix inclusion of Smnpm in the guest ISA bitmap Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 221/480] staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int() Greg Kroah-Hartman ` (271 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Masami Hiramatsu, Ingo Molnar, Peter Zijlstra, Tomas Glozar, Juri Lelli, Clark Williams, John Kacur, Nam Cao, Gabriele Monaco, Steven Rostedt (Google), Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Gabriele Monaco <gmonaco@redhat.com> [ Upstream commit 79de661707a4a2dc695fd3e00529a14b4f5ec50d ] RV monitors relying on the preemptirqs tracepoints are set as dependent on PREEMPT_TRACER and IRQSOFF_TRACER. In fact, those configurations do enable the tracepoints but are not the minimal configurations enabling them, which are TRACE_PREEMPT_TOGGLE and TRACE_IRQFLAGS (not selectable manually). Set TRACE_PREEMPT_TOGGLE and TRACE_IRQFLAGS as dependencies for monitors. Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Tomas Glozar <tglozar@redhat.com> Cc: Juri Lelli <jlelli@redhat.com> Cc: Clark Williams <williams@redhat.com> Cc: John Kacur <jkacur@redhat.com> Link: https://lore.kernel.org/20250728135022.255578-5-gmonaco@redhat.com Fixes: fbe6c09b7eb4 ("rv: Add scpd, snep and sncid per-cpu monitors") Acked-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Gabriele Monaco <gmonaco@redhat.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- kernel/trace/rv/monitors/scpd/Kconfig | 2 +- kernel/trace/rv/monitors/sncid/Kconfig | 2 +- kernel/trace/rv/monitors/snep/Kconfig | 2 +- kernel/trace/rv/monitors/wip/Kconfig | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/kernel/trace/rv/monitors/scpd/Kconfig b/kernel/trace/rv/monitors/scpd/Kconfig index b9114fbf680f..682d0416188b 100644 --- a/kernel/trace/rv/monitors/scpd/Kconfig +++ b/kernel/trace/rv/monitors/scpd/Kconfig @@ -2,7 +2,7 @@ # config RV_MON_SCPD depends on RV - depends on PREEMPT_TRACER + depends on TRACE_PREEMPT_TOGGLE depends on RV_MON_SCHED default y select DA_MON_EVENTS_IMPLICIT diff --git a/kernel/trace/rv/monitors/sncid/Kconfig b/kernel/trace/rv/monitors/sncid/Kconfig index 76bcfef4fd10..3a5639feaaaf 100644 --- a/kernel/trace/rv/monitors/sncid/Kconfig +++ b/kernel/trace/rv/monitors/sncid/Kconfig @@ -2,7 +2,7 @@ # config RV_MON_SNCID depends on RV - depends on IRQSOFF_TRACER + depends on TRACE_IRQFLAGS depends on RV_MON_SCHED default y select DA_MON_EVENTS_IMPLICIT diff --git a/kernel/trace/rv/monitors/snep/Kconfig b/kernel/trace/rv/monitors/snep/Kconfig index 77527f971232..7dd54f434ff7 100644 --- a/kernel/trace/rv/monitors/snep/Kconfig +++ b/kernel/trace/rv/monitors/snep/Kconfig @@ -2,7 +2,7 @@ # config RV_MON_SNEP depends on RV - depends on PREEMPT_TRACER + depends on TRACE_PREEMPT_TOGGLE depends on RV_MON_SCHED default y select DA_MON_EVENTS_IMPLICIT diff --git a/kernel/trace/rv/monitors/wip/Kconfig b/kernel/trace/rv/monitors/wip/Kconfig index e464b9294865..87a26195792b 100644 --- a/kernel/trace/rv/monitors/wip/Kconfig +++ b/kernel/trace/rv/monitors/wip/Kconfig @@ -2,7 +2,7 @@ # config RV_MON_WIP depends on RV - depends on PREEMPT_TRACER + depends on TRACE_PREEMPT_TOGGLE select DA_MON_EVENTS_IMPLICIT bool "wip monitor" help -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 221/480] staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (219 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 220/480] rv: Adjust monitor dependencies Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 222/480] fortify: Fix incorrect reporting of read buffer size Greg Kroah-Hartman ` (270 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, zepta, Hans de Goede, Kees Cook, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Kees Cook <kees@kernel.org> [ Upstream commit ee4cf798202d285dcbe85e4467a094c44f5ed8e6 ] When gmin_get_config_var() calls efi.get_variable() and the EFI variable is larger than the expected buffer size, two behaviors combine to create a stack buffer overflow: 1. gmin_get_config_var() does not return the proper error code when efi.get_variable() fails. It returns the stale 'ret' value from earlier operations instead of indicating the EFI failure. 2. When efi.get_variable() returns EFI_BUFFER_TOO_SMALL, it updates *out_len to the required buffer size but writes no data to the output buffer. However, due to bug #1, gmin_get_var_int() believes the call succeeded. The caller gmin_get_var_int() then performs: - Allocates val[CFG_VAR_NAME_MAX + 1] (65 bytes) on stack - Calls gmin_get_config_var(dev, is_gmin, var, val, &len) with len=64 - If EFI variable is >64 bytes, efi.get_variable() sets len=required_size - Due to bug #1, thinks call succeeded with len=required_size - Executes val[len] = 0, writing past end of 65-byte stack buffer This creates a stack buffer overflow when EFI variables are larger than 64 bytes. Since EFI variables can be controlled by firmware or system configuration, this could potentially be exploited for code execution. Fix the bug by returning proper error codes from gmin_get_config_var() based on EFI status instead of stale 'ret' value. The gmin_get_var_int() function is called during device initialization for camera sensor configuration on Intel Bay Trail and Cherry Trail platforms using the atomisp camera stack. Reported-by: zepta <z3ptaa@gmail.com> Closes: https://lore.kernel.org/all/CAPBS6KoQyM7FMdPwOuXteXsOe44X4H3F8Fw+y_qWq6E+OdmxQA@mail.gmail.com Fixes: 38d4f74bc148 ("media: atomisp_gmin_platform: stop abusing efivar API") Reviewed-by: Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/r/20250724080756.work.741-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- .../staging/media/atomisp/pci/atomisp_gmin_platform.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c index e176483df301..b86494faa63a 100644 --- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c +++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c @@ -1358,14 +1358,15 @@ static int gmin_get_config_var(struct device *maindev, if (efi_rt_services_supported(EFI_RT_SUPPORTED_GET_VARIABLE)) status = efi.get_variable(var16, &GMIN_CFG_VAR_EFI_GUID, NULL, (unsigned long *)out_len, out); - if (status == EFI_SUCCESS) + if (status == EFI_SUCCESS) { dev_info(maindev, "found EFI entry for '%s'\n", var8); - else if (is_gmin) + return 0; + } + if (is_gmin) dev_info(maindev, "Failed to find EFI gmin variable %s\n", var8); else dev_info(maindev, "Failed to find EFI variable %s\n", var8); - - return ret; + return -ENOENT; } int gmin_get_var_int(struct device *dev, bool is_gmin, const char *var, int def) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 222/480] fortify: Fix incorrect reporting of read buffer size 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (220 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 221/480] staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int() Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 223/480] remoteproc: qcom: pas: Conclude the rename from adsp Greg Kroah-Hartman ` (269 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Gustavo A. R. Silva, Kees Cook, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Kees Cook <kees@kernel.org> [ Upstream commit 94fd44648dae2a5b6149a41faa0b07928c3e1963 ] When FORTIFY_SOURCE reports about a run-time buffer overread, the wrong buffer size was being shown in the error message. (The bounds checking was correct.) Fixes: 3d965b33e40d ("fortify: Improve buffer overflow reporting") Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20250729231817.work.023-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- include/linux/fortify-string.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/fortify-string.h b/include/linux/fortify-string.h index e4ce1cae03bf..b3b53f8c1b28 100644 --- a/include/linux/fortify-string.h +++ b/include/linux/fortify-string.h @@ -596,7 +596,7 @@ __FORTIFY_INLINE bool fortify_memcpy_chk(__kernel_size_t size, if (p_size != SIZE_MAX && p_size < size) fortify_panic(func, FORTIFY_WRITE, p_size, size, true); else if (q_size != SIZE_MAX && q_size < size) - fortify_panic(func, FORTIFY_READ, p_size, size, true); + fortify_panic(func, FORTIFY_READ, q_size, size, true); /* * Warn when writing beyond destination field size. -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 223/480] remoteproc: qcom: pas: Conclude the rename from adsp 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (221 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 222/480] fortify: Fix incorrect reporting of read buffer size Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 224/480] PCI: rockchip-host: Fix "Unexpected Completion" log message Greg Kroah-Hartman ` (268 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Bjorn Andersson, Wasim Nazir, Bjorn Andersson, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> [ Upstream commit 2c0c883f895f16fd9d367ec2e64bccab907d8d87 ] The change that renamed the driver from "adsp" to "pas" didn't change any of the implementation. The result is an aesthetic eyesore, and confusing to many. Conclude the rename of the driver, by updating function, structures and variable names to match what the driver actually is. The "Hexagon v5" is also dropped from the name and Kconfig, as this isn't correct either. No functional change. Fixes: 9e004f97161d ("remoteproc: qcom: Rename Hexagon v5 PAS driver") Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Reviewed-by: Wasim Nazir <quic_wasimn@quicinc.com> Link: https://lore.kernel.org/r/20250605-pas-rename-v2-1-f1c89e49e691@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/remoteproc/Kconfig | 11 +- drivers/remoteproc/qcom_q6v5_pas.c | 621 ++++++++++++++--------------- 2 files changed, 313 insertions(+), 319 deletions(-) diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig index 83962a114dc9..48a0d3a69ed0 100644 --- a/drivers/remoteproc/Kconfig +++ b/drivers/remoteproc/Kconfig @@ -214,7 +214,7 @@ config QCOM_Q6V5_MSS handled by QCOM_Q6V5_PAS driver. config QCOM_Q6V5_PAS - tristate "Qualcomm Hexagon v5 Peripheral Authentication Service support" + tristate "Qualcomm Peripheral Authentication Service support" depends on OF && ARCH_QCOM depends on QCOM_SMEM depends on RPMSG_QCOM_SMD || RPMSG_QCOM_SMD=n @@ -229,11 +229,10 @@ config QCOM_Q6V5_PAS select QCOM_RPROC_COMMON select QCOM_SCM help - Say y here to support the TrustZone based Peripheral Image Loader - for the Qualcomm Hexagon v5 based remote processors. This is commonly - used to control subsystems such as ADSP (Audio DSP), - CDSP (Compute DSP), MPSS (Modem Peripheral SubSystem), and - SLPI (Sensor Low Power Island). + Say y here to support the TrustZone based Peripheral Image Loader for + the Qualcomm remote processors. This is commonly used to control + subsystems such as ADSP (Audio DSP), CDSP (Compute DSP), MPSS (Modem + Peripheral SubSystem), and SLPI (Sensor Low Power Island). config QCOM_Q6V5_WCSS tristate "Qualcomm Hexagon based WCSS Peripheral Image Loader" diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c index b306f223127c..02e29171cbbe 100644 --- a/drivers/remoteproc/qcom_q6v5_pas.c +++ b/drivers/remoteproc/qcom_q6v5_pas.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0-only /* - * Qualcomm ADSP/SLPI Peripheral Image Loader for MSM8974 and MSM8996 + * Qualcomm Peripheral Authentication Service remoteproc driver * * Copyright (C) 2016 Linaro Ltd * Copyright (C) 2014 Sony Mobile Communications AB @@ -31,11 +31,11 @@ #include "qcom_q6v5.h" #include "remoteproc_internal.h" -#define ADSP_DECRYPT_SHUTDOWN_DELAY_MS 100 +#define QCOM_PAS_DECRYPT_SHUTDOWN_DELAY_MS 100 #define MAX_ASSIGN_COUNT 3 -struct adsp_data { +struct qcom_pas_data { int crash_reason_smem; const char *firmware_name; const char *dtb_firmware_name; @@ -60,7 +60,7 @@ struct adsp_data { int region_assign_vmid; }; -struct qcom_adsp { +struct qcom_pas { struct device *dev; struct rproc *rproc; @@ -119,36 +119,37 @@ struct qcom_adsp { struct qcom_scm_pas_metadata dtb_pas_metadata; }; -static void adsp_segment_dump(struct rproc *rproc, struct rproc_dump_segment *segment, - void *dest, size_t offset, size_t size) +static void qcom_pas_segment_dump(struct rproc *rproc, + struct rproc_dump_segment *segment, + void *dest, size_t offset, size_t size) { - struct qcom_adsp *adsp = rproc->priv; + struct qcom_pas *pas = rproc->priv; int total_offset; - total_offset = segment->da + segment->offset + offset - adsp->mem_phys; - if (total_offset < 0 || total_offset + size > adsp->mem_size) { - dev_err(adsp->dev, + total_offset = segment->da + segment->offset + offset - pas->mem_phys; + if (total_offset < 0 || total_offset + size > pas->mem_size) { + dev_err(pas->dev, "invalid copy request for segment %pad with offset %zu and size %zu)\n", &segment->da, offset, size); memset(dest, 0xff, size); return; } - memcpy_fromio(dest, adsp->mem_region + total_offset, size); + memcpy_fromio(dest, pas->mem_region + total_offset, size); } -static void adsp_minidump(struct rproc *rproc) +static void qcom_pas_minidump(struct rproc *rproc) { - struct qcom_adsp *adsp = rproc->priv; + struct qcom_pas *pas = rproc->priv; if (rproc->dump_conf == RPROC_COREDUMP_DISABLED) return; - qcom_minidump(rproc, adsp->minidump_id, adsp_segment_dump); + qcom_minidump(rproc, pas->minidump_id, qcom_pas_segment_dump); } -static int adsp_pds_enable(struct qcom_adsp *adsp, struct device **pds, - size_t pd_count) +static int qcom_pas_pds_enable(struct qcom_pas *pas, struct device **pds, + size_t pd_count) { int ret; int i; @@ -174,8 +175,8 @@ static int adsp_pds_enable(struct qcom_adsp *adsp, struct device **pds, return ret; }; -static void adsp_pds_disable(struct qcom_adsp *adsp, struct device **pds, - size_t pd_count) +static void qcom_pas_pds_disable(struct qcom_pas *pas, struct device **pds, + size_t pd_count) { int i; @@ -185,65 +186,65 @@ static void adsp_pds_disable(struct qcom_adsp *adsp, struct device **pds, } } -static int adsp_shutdown_poll_decrypt(struct qcom_adsp *adsp) +static int qcom_pas_shutdown_poll_decrypt(struct qcom_pas *pas) { unsigned int retry_num = 50; int ret; do { - msleep(ADSP_DECRYPT_SHUTDOWN_DELAY_MS); - ret = qcom_scm_pas_shutdown(adsp->pas_id); + msleep(QCOM_PAS_DECRYPT_SHUTDOWN_DELAY_MS); + ret = qcom_scm_pas_shutdown(pas->pas_id); } while (ret == -EINVAL && --retry_num); return ret; } -static int adsp_unprepare(struct rproc *rproc) +static int qcom_pas_unprepare(struct rproc *rproc) { - struct qcom_adsp *adsp = rproc->priv; + struct qcom_pas *pas = rproc->priv; /* - * adsp_load() did pass pas_metadata to the SCM driver for storing + * qcom_pas_load() did pass pas_metadata to the SCM driver for storing * metadata context. It might have been released already if * auth_and_reset() was successful, but in other cases clean it up * here. */ - qcom_scm_pas_metadata_release(&adsp->pas_metadata); - if (adsp->dtb_pas_id) - qcom_scm_pas_metadata_release(&adsp->dtb_pas_metadata); + qcom_scm_pas_metadata_release(&pas->pas_metadata); + if (pas->dtb_pas_id) + qcom_scm_pas_metadata_release(&pas->dtb_pas_metadata); return 0; } -static int adsp_load(struct rproc *rproc, const struct firmware *fw) +static int qcom_pas_load(struct rproc *rproc, const struct firmware *fw) { - struct qcom_adsp *adsp = rproc->priv; + struct qcom_pas *pas = rproc->priv; int ret; - /* Store firmware handle to be used in adsp_start() */ - adsp->firmware = fw; + /* Store firmware handle to be used in qcom_pas_start() */ + pas->firmware = fw; - if (adsp->lite_pas_id) - ret = qcom_scm_pas_shutdown(adsp->lite_pas_id); + if (pas->lite_pas_id) + ret = qcom_scm_pas_shutdown(pas->lite_pas_id); - if (adsp->dtb_pas_id) { - ret = request_firmware(&adsp->dtb_firmware, adsp->dtb_firmware_name, adsp->dev); + if (pas->dtb_pas_id) { + ret = request_firmware(&pas->dtb_firmware, pas->dtb_firmware_name, pas->dev); if (ret) { - dev_err(adsp->dev, "request_firmware failed for %s: %d\n", - adsp->dtb_firmware_name, ret); + dev_err(pas->dev, "request_firmware failed for %s: %d\n", + pas->dtb_firmware_name, ret); return ret; } - ret = qcom_mdt_pas_init(adsp->dev, adsp->dtb_firmware, adsp->dtb_firmware_name, - adsp->dtb_pas_id, adsp->dtb_mem_phys, - &adsp->dtb_pas_metadata); + ret = qcom_mdt_pas_init(pas->dev, pas->dtb_firmware, pas->dtb_firmware_name, + pas->dtb_pas_id, pas->dtb_mem_phys, + &pas->dtb_pas_metadata); if (ret) goto release_dtb_firmware; - ret = qcom_mdt_load_no_init(adsp->dev, adsp->dtb_firmware, adsp->dtb_firmware_name, - adsp->dtb_pas_id, adsp->dtb_mem_region, - adsp->dtb_mem_phys, adsp->dtb_mem_size, - &adsp->dtb_mem_reloc); + ret = qcom_mdt_load_no_init(pas->dev, pas->dtb_firmware, pas->dtb_firmware_name, + pas->dtb_pas_id, pas->dtb_mem_region, + pas->dtb_mem_phys, pas->dtb_mem_size, + &pas->dtb_mem_reloc); if (ret) goto release_dtb_metadata; } @@ -251,248 +252,246 @@ static int adsp_load(struct rproc *rproc, const struct firmware *fw) return 0; release_dtb_metadata: - qcom_scm_pas_metadata_release(&adsp->dtb_pas_metadata); + qcom_scm_pas_metadata_release(&pas->dtb_pas_metadata); release_dtb_firmware: - release_firmware(adsp->dtb_firmware); + release_firmware(pas->dtb_firmware); return ret; } -static int adsp_start(struct rproc *rproc) +static int qcom_pas_start(struct rproc *rproc) { - struct qcom_adsp *adsp = rproc->priv; + struct qcom_pas *pas = rproc->priv; int ret; - ret = qcom_q6v5_prepare(&adsp->q6v5); + ret = qcom_q6v5_prepare(&pas->q6v5); if (ret) return ret; - ret = adsp_pds_enable(adsp, adsp->proxy_pds, adsp->proxy_pd_count); + ret = qcom_pas_pds_enable(pas, pas->proxy_pds, pas->proxy_pd_count); if (ret < 0) goto disable_irqs; - ret = clk_prepare_enable(adsp->xo); + ret = clk_prepare_enable(pas->xo); if (ret) goto disable_proxy_pds; - ret = clk_prepare_enable(adsp->aggre2_clk); + ret = clk_prepare_enable(pas->aggre2_clk); if (ret) goto disable_xo_clk; - if (adsp->cx_supply) { - ret = regulator_enable(adsp->cx_supply); + if (pas->cx_supply) { + ret = regulator_enable(pas->cx_supply); if (ret) goto disable_aggre2_clk; } - if (adsp->px_supply) { - ret = regulator_enable(adsp->px_supply); + if (pas->px_supply) { + ret = regulator_enable(pas->px_supply); if (ret) goto disable_cx_supply; } - if (adsp->dtb_pas_id) { - ret = qcom_scm_pas_auth_and_reset(adsp->dtb_pas_id); + if (pas->dtb_pas_id) { + ret = qcom_scm_pas_auth_and_reset(pas->dtb_pas_id); if (ret) { - dev_err(adsp->dev, + dev_err(pas->dev, "failed to authenticate dtb image and release reset\n"); goto disable_px_supply; } } - ret = qcom_mdt_pas_init(adsp->dev, adsp->firmware, rproc->firmware, adsp->pas_id, - adsp->mem_phys, &adsp->pas_metadata); + ret = qcom_mdt_pas_init(pas->dev, pas->firmware, rproc->firmware, pas->pas_id, + pas->mem_phys, &pas->pas_metadata); if (ret) goto disable_px_supply; - ret = qcom_mdt_load_no_init(adsp->dev, adsp->firmware, rproc->firmware, adsp->pas_id, - adsp->mem_region, adsp->mem_phys, adsp->mem_size, - &adsp->mem_reloc); + ret = qcom_mdt_load_no_init(pas->dev, pas->firmware, rproc->firmware, pas->pas_id, + pas->mem_region, pas->mem_phys, pas->mem_size, + &pas->mem_reloc); if (ret) goto release_pas_metadata; - qcom_pil_info_store(adsp->info_name, adsp->mem_phys, adsp->mem_size); + qcom_pil_info_store(pas->info_name, pas->mem_phys, pas->mem_size); - ret = qcom_scm_pas_auth_and_reset(adsp->pas_id); + ret = qcom_scm_pas_auth_and_reset(pas->pas_id); if (ret) { - dev_err(adsp->dev, + dev_err(pas->dev, "failed to authenticate image and release reset\n"); goto release_pas_metadata; } - ret = qcom_q6v5_wait_for_start(&adsp->q6v5, msecs_to_jiffies(5000)); + ret = qcom_q6v5_wait_for_start(&pas->q6v5, msecs_to_jiffies(5000)); if (ret == -ETIMEDOUT) { - dev_err(adsp->dev, "start timed out\n"); - qcom_scm_pas_shutdown(adsp->pas_id); + dev_err(pas->dev, "start timed out\n"); + qcom_scm_pas_shutdown(pas->pas_id); goto release_pas_metadata; } - qcom_scm_pas_metadata_release(&adsp->pas_metadata); - if (adsp->dtb_pas_id) - qcom_scm_pas_metadata_release(&adsp->dtb_pas_metadata); + qcom_scm_pas_metadata_release(&pas->pas_metadata); + if (pas->dtb_pas_id) + qcom_scm_pas_metadata_release(&pas->dtb_pas_metadata); - /* Remove pointer to the loaded firmware, only valid in adsp_load() & adsp_start() */ - adsp->firmware = NULL; + /* firmware is used to pass reference from qcom_pas_start(), drop it now */ + pas->firmware = NULL; return 0; release_pas_metadata: - qcom_scm_pas_metadata_release(&adsp->pas_metadata); - if (adsp->dtb_pas_id) - qcom_scm_pas_metadata_release(&adsp->dtb_pas_metadata); + qcom_scm_pas_metadata_release(&pas->pas_metadata); + if (pas->dtb_pas_id) + qcom_scm_pas_metadata_release(&pas->dtb_pas_metadata); disable_px_supply: - if (adsp->px_supply) - regulator_disable(adsp->px_supply); + if (pas->px_supply) + regulator_disable(pas->px_supply); disable_cx_supply: - if (adsp->cx_supply) - regulator_disable(adsp->cx_supply); + if (pas->cx_supply) + regulator_disable(pas->cx_supply); disable_aggre2_clk: - clk_disable_unprepare(adsp->aggre2_clk); + clk_disable_unprepare(pas->aggre2_clk); disable_xo_clk: - clk_disable_unprepare(adsp->xo); + clk_disable_unprepare(pas->xo); disable_proxy_pds: - adsp_pds_disable(adsp, adsp->proxy_pds, adsp->proxy_pd_count); + qcom_pas_pds_disable(pas, pas->proxy_pds, pas->proxy_pd_count); disable_irqs: - qcom_q6v5_unprepare(&adsp->q6v5); + qcom_q6v5_unprepare(&pas->q6v5); - /* Remove pointer to the loaded firmware, only valid in adsp_load() & adsp_start() */ - adsp->firmware = NULL; + /* firmware is used to pass reference from qcom_pas_start(), drop it now */ + pas->firmware = NULL; return ret; } static void qcom_pas_handover(struct qcom_q6v5 *q6v5) { - struct qcom_adsp *adsp = container_of(q6v5, struct qcom_adsp, q6v5); - - if (adsp->px_supply) - regulator_disable(adsp->px_supply); - if (adsp->cx_supply) - regulator_disable(adsp->cx_supply); - clk_disable_unprepare(adsp->aggre2_clk); - clk_disable_unprepare(adsp->xo); - adsp_pds_disable(adsp, adsp->proxy_pds, adsp->proxy_pd_count); + struct qcom_pas *pas = container_of(q6v5, struct qcom_pas, q6v5); + + if (pas->px_supply) + regulator_disable(pas->px_supply); + if (pas->cx_supply) + regulator_disable(pas->cx_supply); + clk_disable_unprepare(pas->aggre2_clk); + clk_disable_unprepare(pas->xo); + qcom_pas_pds_disable(pas, pas->proxy_pds, pas->proxy_pd_count); } -static int adsp_stop(struct rproc *rproc) +static int qcom_pas_stop(struct rproc *rproc) { - struct qcom_adsp *adsp = rproc->priv; + struct qcom_pas *pas = rproc->priv; int handover; int ret; - ret = qcom_q6v5_request_stop(&adsp->q6v5, adsp->sysmon); + ret = qcom_q6v5_request_stop(&pas->q6v5, pas->sysmon); if (ret == -ETIMEDOUT) - dev_err(adsp->dev, "timed out on wait\n"); + dev_err(pas->dev, "timed out on wait\n"); - ret = qcom_scm_pas_shutdown(adsp->pas_id); - if (ret && adsp->decrypt_shutdown) - ret = adsp_shutdown_poll_decrypt(adsp); + ret = qcom_scm_pas_shutdown(pas->pas_id); + if (ret && pas->decrypt_shutdown) + ret = qcom_pas_shutdown_poll_decrypt(pas); if (ret) - dev_err(adsp->dev, "failed to shutdown: %d\n", ret); + dev_err(pas->dev, "failed to shutdown: %d\n", ret); - if (adsp->dtb_pas_id) { - ret = qcom_scm_pas_shutdown(adsp->dtb_pas_id); + if (pas->dtb_pas_id) { + ret = qcom_scm_pas_shutdown(pas->dtb_pas_id); if (ret) - dev_err(adsp->dev, "failed to shutdown dtb: %d\n", ret); + dev_err(pas->dev, "failed to shutdown dtb: %d\n", ret); } - handover = qcom_q6v5_unprepare(&adsp->q6v5); + handover = qcom_q6v5_unprepare(&pas->q6v5); if (handover) - qcom_pas_handover(&adsp->q6v5); + qcom_pas_handover(&pas->q6v5); - if (adsp->smem_host_id) - ret = qcom_smem_bust_hwspin_lock_by_host(adsp->smem_host_id); + if (pas->smem_host_id) + ret = qcom_smem_bust_hwspin_lock_by_host(pas->smem_host_id); return ret; } -static void *adsp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem) +static void *qcom_pas_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *is_iomem) { - struct qcom_adsp *adsp = rproc->priv; + struct qcom_pas *pas = rproc->priv; int offset; - offset = da - adsp->mem_reloc; - if (offset < 0 || offset + len > adsp->mem_size) + offset = da - pas->mem_reloc; + if (offset < 0 || offset + len > pas->mem_size) return NULL; if (is_iomem) *is_iomem = true; - return adsp->mem_region + offset; + return pas->mem_region + offset; } -static unsigned long adsp_panic(struct rproc *rproc) +static unsigned long qcom_pas_panic(struct rproc *rproc) { - struct qcom_adsp *adsp = rproc->priv; + struct qcom_pas *pas = rproc->priv; - return qcom_q6v5_panic(&adsp->q6v5); + return qcom_q6v5_panic(&pas->q6v5); } -static const struct rproc_ops adsp_ops = { - .unprepare = adsp_unprepare, - .start = adsp_start, - .stop = adsp_stop, - .da_to_va = adsp_da_to_va, +static const struct rproc_ops qcom_pas_ops = { + .unprepare = qcom_pas_unprepare, + .start = qcom_pas_start, + .stop = qcom_pas_stop, + .da_to_va = qcom_pas_da_to_va, .parse_fw = qcom_register_dump_segments, - .load = adsp_load, - .panic = adsp_panic, + .load = qcom_pas_load, + .panic = qcom_pas_panic, }; -static const struct rproc_ops adsp_minidump_ops = { - .unprepare = adsp_unprepare, - .start = adsp_start, - .stop = adsp_stop, - .da_to_va = adsp_da_to_va, +static const struct rproc_ops qcom_pas_minidump_ops = { + .unprepare = qcom_pas_unprepare, + .start = qcom_pas_start, + .stop = qcom_pas_stop, + .da_to_va = qcom_pas_da_to_va, .parse_fw = qcom_register_dump_segments, - .load = adsp_load, - .panic = adsp_panic, - .coredump = adsp_minidump, + .load = qcom_pas_load, + .panic = qcom_pas_panic, + .coredump = qcom_pas_minidump, }; -static int adsp_init_clock(struct qcom_adsp *adsp) +static int qcom_pas_init_clock(struct qcom_pas *pas) { - adsp->xo = devm_clk_get(adsp->dev, "xo"); - if (IS_ERR(adsp->xo)) - return dev_err_probe(adsp->dev, PTR_ERR(adsp->xo), + pas->xo = devm_clk_get(pas->dev, "xo"); + if (IS_ERR(pas->xo)) + return dev_err_probe(pas->dev, PTR_ERR(pas->xo), "failed to get xo clock"); - - adsp->aggre2_clk = devm_clk_get_optional(adsp->dev, "aggre2"); - if (IS_ERR(adsp->aggre2_clk)) - return dev_err_probe(adsp->dev, PTR_ERR(adsp->aggre2_clk), + pas->aggre2_clk = devm_clk_get_optional(pas->dev, "aggre2"); + if (IS_ERR(pas->aggre2_clk)) + return dev_err_probe(pas->dev, PTR_ERR(pas->aggre2_clk), "failed to get aggre2 clock"); return 0; } -static int adsp_init_regulator(struct qcom_adsp *adsp) +static int qcom_pas_init_regulator(struct qcom_pas *pas) { - adsp->cx_supply = devm_regulator_get_optional(adsp->dev, "cx"); - if (IS_ERR(adsp->cx_supply)) { - if (PTR_ERR(adsp->cx_supply) == -ENODEV) - adsp->cx_supply = NULL; + pas->cx_supply = devm_regulator_get_optional(pas->dev, "cx"); + if (IS_ERR(pas->cx_supply)) { + if (PTR_ERR(pas->cx_supply) == -ENODEV) + pas->cx_supply = NULL; else - return PTR_ERR(adsp->cx_supply); + return PTR_ERR(pas->cx_supply); } - if (adsp->cx_supply) - regulator_set_load(adsp->cx_supply, 100000); + if (pas->cx_supply) + regulator_set_load(pas->cx_supply, 100000); - adsp->px_supply = devm_regulator_get_optional(adsp->dev, "px"); - if (IS_ERR(adsp->px_supply)) { - if (PTR_ERR(adsp->px_supply) == -ENODEV) - adsp->px_supply = NULL; + pas->px_supply = devm_regulator_get_optional(pas->dev, "px"); + if (IS_ERR(pas->px_supply)) { + if (PTR_ERR(pas->px_supply) == -ENODEV) + pas->px_supply = NULL; else - return PTR_ERR(adsp->px_supply); + return PTR_ERR(pas->px_supply); } return 0; } -static int adsp_pds_attach(struct device *dev, struct device **devs, - char **pd_names) +static int qcom_pas_pds_attach(struct device *dev, struct device **devs, char **pd_names) { size_t num_pds = 0; int ret; @@ -528,10 +527,9 @@ static int adsp_pds_attach(struct device *dev, struct device **devs, return ret; }; -static void adsp_pds_detach(struct qcom_adsp *adsp, struct device **pds, - size_t pd_count) +static void qcom_pas_pds_detach(struct qcom_pas *pas, struct device **pds, size_t pd_count) { - struct device *dev = adsp->dev; + struct device *dev = pas->dev; int i; /* Handle single power domain */ @@ -544,62 +542,62 @@ static void adsp_pds_detach(struct qcom_adsp *adsp, struct device **pds, dev_pm_domain_detach(pds[i], false); } -static int adsp_alloc_memory_region(struct qcom_adsp *adsp) +static int qcom_pas_alloc_memory_region(struct qcom_pas *pas) { struct reserved_mem *rmem; struct device_node *node; - node = of_parse_phandle(adsp->dev->of_node, "memory-region", 0); + node = of_parse_phandle(pas->dev->of_node, "memory-region", 0); if (!node) { - dev_err(adsp->dev, "no memory-region specified\n"); + dev_err(pas->dev, "no memory-region specified\n"); return -EINVAL; } rmem = of_reserved_mem_lookup(node); of_node_put(node); if (!rmem) { - dev_err(adsp->dev, "unable to resolve memory-region\n"); + dev_err(pas->dev, "unable to resolve memory-region\n"); return -EINVAL; } - adsp->mem_phys = adsp->mem_reloc = rmem->base; - adsp->mem_size = rmem->size; - adsp->mem_region = devm_ioremap_wc(adsp->dev, adsp->mem_phys, adsp->mem_size); - if (!adsp->mem_region) { - dev_err(adsp->dev, "unable to map memory region: %pa+%zx\n", - &rmem->base, adsp->mem_size); + pas->mem_phys = pas->mem_reloc = rmem->base; + pas->mem_size = rmem->size; + pas->mem_region = devm_ioremap_wc(pas->dev, pas->mem_phys, pas->mem_size); + if (!pas->mem_region) { + dev_err(pas->dev, "unable to map memory region: %pa+%zx\n", + &rmem->base, pas->mem_size); return -EBUSY; } - if (!adsp->dtb_pas_id) + if (!pas->dtb_pas_id) return 0; - node = of_parse_phandle(adsp->dev->of_node, "memory-region", 1); + node = of_parse_phandle(pas->dev->of_node, "memory-region", 1); if (!node) { - dev_err(adsp->dev, "no dtb memory-region specified\n"); + dev_err(pas->dev, "no dtb memory-region specified\n"); return -EINVAL; } rmem = of_reserved_mem_lookup(node); of_node_put(node); if (!rmem) { - dev_err(adsp->dev, "unable to resolve dtb memory-region\n"); + dev_err(pas->dev, "unable to resolve dtb memory-region\n"); return -EINVAL; } - adsp->dtb_mem_phys = adsp->dtb_mem_reloc = rmem->base; - adsp->dtb_mem_size = rmem->size; - adsp->dtb_mem_region = devm_ioremap_wc(adsp->dev, adsp->dtb_mem_phys, adsp->dtb_mem_size); - if (!adsp->dtb_mem_region) { - dev_err(adsp->dev, "unable to map dtb memory region: %pa+%zx\n", - &rmem->base, adsp->dtb_mem_size); + pas->dtb_mem_phys = pas->dtb_mem_reloc = rmem->base; + pas->dtb_mem_size = rmem->size; + pas->dtb_mem_region = devm_ioremap_wc(pas->dev, pas->dtb_mem_phys, pas->dtb_mem_size); + if (!pas->dtb_mem_region) { + dev_err(pas->dev, "unable to map dtb memory region: %pa+%zx\n", + &rmem->base, pas->dtb_mem_size); return -EBUSY; } return 0; } -static int adsp_assign_memory_region(struct qcom_adsp *adsp) +static int qcom_pas_assign_memory_region(struct qcom_pas *pas) { struct qcom_scm_vmperm perm[MAX_ASSIGN_COUNT]; struct device_node *node; @@ -607,45 +605,45 @@ static int adsp_assign_memory_region(struct qcom_adsp *adsp) int offset; int ret; - if (!adsp->region_assign_idx) + if (!pas->region_assign_idx) return 0; - for (offset = 0; offset < adsp->region_assign_count; ++offset) { + for (offset = 0; offset < pas->region_assign_count; ++offset) { struct reserved_mem *rmem = NULL; - node = of_parse_phandle(adsp->dev->of_node, "memory-region", - adsp->region_assign_idx + offset); + node = of_parse_phandle(pas->dev->of_node, "memory-region", + pas->region_assign_idx + offset); if (node) rmem = of_reserved_mem_lookup(node); of_node_put(node); if (!rmem) { - dev_err(adsp->dev, "unable to resolve shareable memory-region index %d\n", + dev_err(pas->dev, "unable to resolve shareable memory-region index %d\n", offset); return -EINVAL; } - if (adsp->region_assign_shared) { + if (pas->region_assign_shared) { perm[0].vmid = QCOM_SCM_VMID_HLOS; perm[0].perm = QCOM_SCM_PERM_RW; - perm[1].vmid = adsp->region_assign_vmid; + perm[1].vmid = pas->region_assign_vmid; perm[1].perm = QCOM_SCM_PERM_RW; perm_size = 2; } else { - perm[0].vmid = adsp->region_assign_vmid; + perm[0].vmid = pas->region_assign_vmid; perm[0].perm = QCOM_SCM_PERM_RW; perm_size = 1; } - adsp->region_assign_phys[offset] = rmem->base; - adsp->region_assign_size[offset] = rmem->size; - adsp->region_assign_owners[offset] = BIT(QCOM_SCM_VMID_HLOS); + pas->region_assign_phys[offset] = rmem->base; + pas->region_assign_size[offset] = rmem->size; + pas->region_assign_owners[offset] = BIT(QCOM_SCM_VMID_HLOS); - ret = qcom_scm_assign_mem(adsp->region_assign_phys[offset], - adsp->region_assign_size[offset], - &adsp->region_assign_owners[offset], + ret = qcom_scm_assign_mem(pas->region_assign_phys[offset], + pas->region_assign_size[offset], + &pas->region_assign_owners[offset], perm, perm_size); if (ret < 0) { - dev_err(adsp->dev, "assign memory %d failed\n", offset); + dev_err(pas->dev, "assign memory %d failed\n", offset); return ret; } } @@ -653,35 +651,35 @@ static int adsp_assign_memory_region(struct qcom_adsp *adsp) return 0; } -static void adsp_unassign_memory_region(struct qcom_adsp *adsp) +static void qcom_pas_unassign_memory_region(struct qcom_pas *pas) { struct qcom_scm_vmperm perm; int offset; int ret; - if (!adsp->region_assign_idx || adsp->region_assign_shared) + if (!pas->region_assign_idx || pas->region_assign_shared) return; - for (offset = 0; offset < adsp->region_assign_count; ++offset) { + for (offset = 0; offset < pas->region_assign_count; ++offset) { perm.vmid = QCOM_SCM_VMID_HLOS; perm.perm = QCOM_SCM_PERM_RW; - ret = qcom_scm_assign_mem(adsp->region_assign_phys[offset], - adsp->region_assign_size[offset], - &adsp->region_assign_owners[offset], + ret = qcom_scm_assign_mem(pas->region_assign_phys[offset], + pas->region_assign_size[offset], + &pas->region_assign_owners[offset], &perm, 1); if (ret < 0) - dev_err(adsp->dev, "unassign memory %d failed\n", offset); + dev_err(pas->dev, "unassign memory %d failed\n", offset); } } -static int adsp_probe(struct platform_device *pdev) +static int qcom_pas_probe(struct platform_device *pdev) { - const struct adsp_data *desc; - struct qcom_adsp *adsp; + const struct qcom_pas_data *desc; + struct qcom_pas *pas; struct rproc *rproc; const char *fw_name, *dtb_fw_name = NULL; - const struct rproc_ops *ops = &adsp_ops; + const struct rproc_ops *ops = &qcom_pas_ops; int ret; desc = of_device_get_match_data(&pdev->dev); @@ -706,9 +704,9 @@ static int adsp_probe(struct platform_device *pdev) } if (desc->minidump_id) - ops = &adsp_minidump_ops; + ops = &qcom_pas_minidump_ops; - rproc = devm_rproc_alloc(&pdev->dev, desc->sysmon_name, ops, fw_name, sizeof(*adsp)); + rproc = devm_rproc_alloc(&pdev->dev, desc->sysmon_name, ops, fw_name, sizeof(*pas)); if (!rproc) { dev_err(&pdev->dev, "unable to allocate remoteproc\n"); @@ -718,68 +716,65 @@ static int adsp_probe(struct platform_device *pdev) rproc->auto_boot = desc->auto_boot; rproc_coredump_set_elf_info(rproc, ELFCLASS32, EM_NONE); - adsp = rproc->priv; - adsp->dev = &pdev->dev; - adsp->rproc = rproc; - adsp->minidump_id = desc->minidump_id; - adsp->pas_id = desc->pas_id; - adsp->lite_pas_id = desc->lite_pas_id; - adsp->info_name = desc->sysmon_name; - adsp->smem_host_id = desc->smem_host_id; - adsp->decrypt_shutdown = desc->decrypt_shutdown; - adsp->region_assign_idx = desc->region_assign_idx; - adsp->region_assign_count = min_t(int, MAX_ASSIGN_COUNT, desc->region_assign_count); - adsp->region_assign_vmid = desc->region_assign_vmid; - adsp->region_assign_shared = desc->region_assign_shared; + pas = rproc->priv; + pas->dev = &pdev->dev; + pas->rproc = rproc; + pas->minidump_id = desc->minidump_id; + pas->pas_id = desc->pas_id; + pas->lite_pas_id = desc->lite_pas_id; + pas->info_name = desc->sysmon_name; + pas->smem_host_id = desc->smem_host_id; + pas->decrypt_shutdown = desc->decrypt_shutdown; + pas->region_assign_idx = desc->region_assign_idx; + pas->region_assign_count = min_t(int, MAX_ASSIGN_COUNT, desc->region_assign_count); + pas->region_assign_vmid = desc->region_assign_vmid; + pas->region_assign_shared = desc->region_assign_shared; if (dtb_fw_name) { - adsp->dtb_firmware_name = dtb_fw_name; - adsp->dtb_pas_id = desc->dtb_pas_id; + pas->dtb_firmware_name = dtb_fw_name; + pas->dtb_pas_id = desc->dtb_pas_id; } - platform_set_drvdata(pdev, adsp); + platform_set_drvdata(pdev, pas); - ret = device_init_wakeup(adsp->dev, true); + ret = device_init_wakeup(pas->dev, true); if (ret) goto free_rproc; - ret = adsp_alloc_memory_region(adsp); + ret = qcom_pas_alloc_memory_region(pas); if (ret) goto free_rproc; - ret = adsp_assign_memory_region(adsp); + ret = qcom_pas_assign_memory_region(pas); if (ret) goto free_rproc; - ret = adsp_init_clock(adsp); + ret = qcom_pas_init_clock(pas); if (ret) goto unassign_mem; - ret = adsp_init_regulator(adsp); + ret = qcom_pas_init_regulator(pas); if (ret) goto unassign_mem; - ret = adsp_pds_attach(&pdev->dev, adsp->proxy_pds, - desc->proxy_pd_names); + ret = qcom_pas_pds_attach(&pdev->dev, pas->proxy_pds, desc->proxy_pd_names); if (ret < 0) goto unassign_mem; - adsp->proxy_pd_count = ret; + pas->proxy_pd_count = ret; - ret = qcom_q6v5_init(&adsp->q6v5, pdev, rproc, desc->crash_reason_smem, desc->load_state, - qcom_pas_handover); + ret = qcom_q6v5_init(&pas->q6v5, pdev, rproc, desc->crash_reason_smem, + desc->load_state, qcom_pas_handover); if (ret) goto detach_proxy_pds; - qcom_add_glink_subdev(rproc, &adsp->glink_subdev, desc->ssr_name); - qcom_add_smd_subdev(rproc, &adsp->smd_subdev); - qcom_add_pdm_subdev(rproc, &adsp->pdm_subdev); - adsp->sysmon = qcom_add_sysmon_subdev(rproc, - desc->sysmon_name, - desc->ssctl_id); - if (IS_ERR(adsp->sysmon)) { - ret = PTR_ERR(adsp->sysmon); + qcom_add_glink_subdev(rproc, &pas->glink_subdev, desc->ssr_name); + qcom_add_smd_subdev(rproc, &pas->smd_subdev); + qcom_add_pdm_subdev(rproc, &pas->pdm_subdev); + pas->sysmon = qcom_add_sysmon_subdev(rproc, desc->sysmon_name, desc->ssctl_id); + if (IS_ERR(pas->sysmon)) { + ret = PTR_ERR(pas->sysmon); goto deinit_remove_pdm_smd_glink; } - qcom_add_ssr_subdev(rproc, &adsp->ssr_subdev, desc->ssr_name); + qcom_add_ssr_subdev(rproc, &pas->ssr_subdev, desc->ssr_name); ret = rproc_add(rproc); if (ret) goto remove_ssr_sysmon; @@ -787,41 +782,41 @@ static int adsp_probe(struct platform_device *pdev) return 0; remove_ssr_sysmon: - qcom_remove_ssr_subdev(rproc, &adsp->ssr_subdev); - qcom_remove_sysmon_subdev(adsp->sysmon); + qcom_remove_ssr_subdev(rproc, &pas->ssr_subdev); + qcom_remove_sysmon_subdev(pas->sysmon); deinit_remove_pdm_smd_glink: - qcom_remove_pdm_subdev(rproc, &adsp->pdm_subdev); - qcom_remove_smd_subdev(rproc, &adsp->smd_subdev); - qcom_remove_glink_subdev(rproc, &adsp->glink_subdev); - qcom_q6v5_deinit(&adsp->q6v5); + qcom_remove_pdm_subdev(rproc, &pas->pdm_subdev); + qcom_remove_smd_subdev(rproc, &pas->smd_subdev); + qcom_remove_glink_subdev(rproc, &pas->glink_subdev); + qcom_q6v5_deinit(&pas->q6v5); detach_proxy_pds: - adsp_pds_detach(adsp, adsp->proxy_pds, adsp->proxy_pd_count); + qcom_pas_pds_detach(pas, pas->proxy_pds, pas->proxy_pd_count); unassign_mem: - adsp_unassign_memory_region(adsp); + qcom_pas_unassign_memory_region(pas); free_rproc: - device_init_wakeup(adsp->dev, false); + device_init_wakeup(pas->dev, false); return ret; } -static void adsp_remove(struct platform_device *pdev) +static void qcom_pas_remove(struct platform_device *pdev) { - struct qcom_adsp *adsp = platform_get_drvdata(pdev); - - rproc_del(adsp->rproc); - - qcom_q6v5_deinit(&adsp->q6v5); - adsp_unassign_memory_region(adsp); - qcom_remove_glink_subdev(adsp->rproc, &adsp->glink_subdev); - qcom_remove_sysmon_subdev(adsp->sysmon); - qcom_remove_smd_subdev(adsp->rproc, &adsp->smd_subdev); - qcom_remove_pdm_subdev(adsp->rproc, &adsp->pdm_subdev); - qcom_remove_ssr_subdev(adsp->rproc, &adsp->ssr_subdev); - adsp_pds_detach(adsp, adsp->proxy_pds, adsp->proxy_pd_count); - device_init_wakeup(adsp->dev, false); + struct qcom_pas *pas = platform_get_drvdata(pdev); + + rproc_del(pas->rproc); + + qcom_q6v5_deinit(&pas->q6v5); + qcom_pas_unassign_memory_region(pas); + qcom_remove_glink_subdev(pas->rproc, &pas->glink_subdev); + qcom_remove_sysmon_subdev(pas->sysmon); + qcom_remove_smd_subdev(pas->rproc, &pas->smd_subdev); + qcom_remove_pdm_subdev(pas->rproc, &pas->pdm_subdev); + qcom_remove_ssr_subdev(pas->rproc, &pas->ssr_subdev); + qcom_pas_pds_detach(pas, pas->proxy_pds, pas->proxy_pd_count); + device_init_wakeup(pas->dev, false); } -static const struct adsp_data adsp_resource_init = { +static const struct qcom_pas_data adsp_resource_init = { .crash_reason_smem = 423, .firmware_name = "adsp.mdt", .pas_id = 1, @@ -831,7 +826,7 @@ static const struct adsp_data adsp_resource_init = { .ssctl_id = 0x14, }; -static const struct adsp_data sa8775p_adsp_resource = { +static const struct qcom_pas_data sa8775p_adsp_resource = { .crash_reason_smem = 423, .firmware_name = "adsp.mbn", .pas_id = 1, @@ -848,7 +843,7 @@ static const struct adsp_data sa8775p_adsp_resource = { .ssctl_id = 0x14, }; -static const struct adsp_data sdm845_adsp_resource_init = { +static const struct qcom_pas_data sdm845_adsp_resource_init = { .crash_reason_smem = 423, .firmware_name = "adsp.mdt", .pas_id = 1, @@ -859,7 +854,7 @@ static const struct adsp_data sdm845_adsp_resource_init = { .ssctl_id = 0x14, }; -static const struct adsp_data sm6350_adsp_resource = { +static const struct qcom_pas_data sm6350_adsp_resource = { .crash_reason_smem = 423, .firmware_name = "adsp.mdt", .pas_id = 1, @@ -875,7 +870,7 @@ static const struct adsp_data sm6350_adsp_resource = { .ssctl_id = 0x14, }; -static const struct adsp_data sm6375_mpss_resource = { +static const struct qcom_pas_data sm6375_mpss_resource = { .crash_reason_smem = 421, .firmware_name = "modem.mdt", .pas_id = 4, @@ -890,7 +885,7 @@ static const struct adsp_data sm6375_mpss_resource = { .ssctl_id = 0x12, }; -static const struct adsp_data sm8150_adsp_resource = { +static const struct qcom_pas_data sm8150_adsp_resource = { .crash_reason_smem = 423, .firmware_name = "adsp.mdt", .pas_id = 1, @@ -905,7 +900,7 @@ static const struct adsp_data sm8150_adsp_resource = { .ssctl_id = 0x14, }; -static const struct adsp_data sm8250_adsp_resource = { +static const struct qcom_pas_data sm8250_adsp_resource = { .crash_reason_smem = 423, .firmware_name = "adsp.mdt", .pas_id = 1, @@ -922,7 +917,7 @@ static const struct adsp_data sm8250_adsp_resource = { .ssctl_id = 0x14, }; -static const struct adsp_data sm8350_adsp_resource = { +static const struct qcom_pas_data sm8350_adsp_resource = { .crash_reason_smem = 423, .firmware_name = "adsp.mdt", .pas_id = 1, @@ -938,7 +933,7 @@ static const struct adsp_data sm8350_adsp_resource = { .ssctl_id = 0x14, }; -static const struct adsp_data msm8996_adsp_resource = { +static const struct qcom_pas_data msm8996_adsp_resource = { .crash_reason_smem = 423, .firmware_name = "adsp.mdt", .pas_id = 1, @@ -952,7 +947,7 @@ static const struct adsp_data msm8996_adsp_resource = { .ssctl_id = 0x14, }; -static const struct adsp_data cdsp_resource_init = { +static const struct qcom_pas_data cdsp_resource_init = { .crash_reason_smem = 601, .firmware_name = "cdsp.mdt", .pas_id = 18, @@ -962,7 +957,7 @@ static const struct adsp_data cdsp_resource_init = { .ssctl_id = 0x17, }; -static const struct adsp_data sa8775p_cdsp0_resource = { +static const struct qcom_pas_data sa8775p_cdsp0_resource = { .crash_reason_smem = 601, .firmware_name = "cdsp0.mbn", .pas_id = 18, @@ -980,7 +975,7 @@ static const struct adsp_data sa8775p_cdsp0_resource = { .ssctl_id = 0x17, }; -static const struct adsp_data sa8775p_cdsp1_resource = { +static const struct qcom_pas_data sa8775p_cdsp1_resource = { .crash_reason_smem = 633, .firmware_name = "cdsp1.mbn", .pas_id = 30, @@ -998,7 +993,7 @@ static const struct adsp_data sa8775p_cdsp1_resource = { .ssctl_id = 0x20, }; -static const struct adsp_data sdm845_cdsp_resource_init = { +static const struct qcom_pas_data sdm845_cdsp_resource_init = { .crash_reason_smem = 601, .firmware_name = "cdsp.mdt", .pas_id = 18, @@ -1009,7 +1004,7 @@ static const struct adsp_data sdm845_cdsp_resource_init = { .ssctl_id = 0x17, }; -static const struct adsp_data sm6350_cdsp_resource = { +static const struct qcom_pas_data sm6350_cdsp_resource = { .crash_reason_smem = 601, .firmware_name = "cdsp.mdt", .pas_id = 18, @@ -1025,7 +1020,7 @@ static const struct adsp_data sm6350_cdsp_resource = { .ssctl_id = 0x17, }; -static const struct adsp_data sm8150_cdsp_resource = { +static const struct qcom_pas_data sm8150_cdsp_resource = { .crash_reason_smem = 601, .firmware_name = "cdsp.mdt", .pas_id = 18, @@ -1040,7 +1035,7 @@ static const struct adsp_data sm8150_cdsp_resource = { .ssctl_id = 0x17, }; -static const struct adsp_data sm8250_cdsp_resource = { +static const struct qcom_pas_data sm8250_cdsp_resource = { .crash_reason_smem = 601, .firmware_name = "cdsp.mdt", .pas_id = 18, @@ -1055,7 +1050,7 @@ static const struct adsp_data sm8250_cdsp_resource = { .ssctl_id = 0x17, }; -static const struct adsp_data sc8280xp_nsp0_resource = { +static const struct qcom_pas_data sc8280xp_nsp0_resource = { .crash_reason_smem = 601, .firmware_name = "cdsp.mdt", .pas_id = 18, @@ -1069,7 +1064,7 @@ static const struct adsp_data sc8280xp_nsp0_resource = { .ssctl_id = 0x17, }; -static const struct adsp_data sc8280xp_nsp1_resource = { +static const struct qcom_pas_data sc8280xp_nsp1_resource = { .crash_reason_smem = 633, .firmware_name = "cdsp.mdt", .pas_id = 30, @@ -1083,7 +1078,7 @@ static const struct adsp_data sc8280xp_nsp1_resource = { .ssctl_id = 0x20, }; -static const struct adsp_data x1e80100_adsp_resource = { +static const struct qcom_pas_data x1e80100_adsp_resource = { .crash_reason_smem = 423, .firmware_name = "adsp.mdt", .dtb_firmware_name = "adsp_dtb.mdt", @@ -1103,7 +1098,7 @@ static const struct adsp_data x1e80100_adsp_resource = { .ssctl_id = 0x14, }; -static const struct adsp_data x1e80100_cdsp_resource = { +static const struct qcom_pas_data x1e80100_cdsp_resource = { .crash_reason_smem = 601, .firmware_name = "cdsp.mdt", .dtb_firmware_name = "cdsp_dtb.mdt", @@ -1123,7 +1118,7 @@ static const struct adsp_data x1e80100_cdsp_resource = { .ssctl_id = 0x17, }; -static const struct adsp_data sm8350_cdsp_resource = { +static const struct qcom_pas_data sm8350_cdsp_resource = { .crash_reason_smem = 601, .firmware_name = "cdsp.mdt", .pas_id = 18, @@ -1140,7 +1135,7 @@ static const struct adsp_data sm8350_cdsp_resource = { .ssctl_id = 0x17, }; -static const struct adsp_data sa8775p_gpdsp0_resource = { +static const struct qcom_pas_data sa8775p_gpdsp0_resource = { .crash_reason_smem = 640, .firmware_name = "gpdsp0.mbn", .pas_id = 39, @@ -1157,7 +1152,7 @@ static const struct adsp_data sa8775p_gpdsp0_resource = { .ssctl_id = 0x21, }; -static const struct adsp_data sa8775p_gpdsp1_resource = { +static const struct qcom_pas_data sa8775p_gpdsp1_resource = { .crash_reason_smem = 641, .firmware_name = "gpdsp1.mbn", .pas_id = 40, @@ -1174,7 +1169,7 @@ static const struct adsp_data sa8775p_gpdsp1_resource = { .ssctl_id = 0x22, }; -static const struct adsp_data mpss_resource_init = { +static const struct qcom_pas_data mpss_resource_init = { .crash_reason_smem = 421, .firmware_name = "modem.mdt", .pas_id = 4, @@ -1191,7 +1186,7 @@ static const struct adsp_data mpss_resource_init = { .ssctl_id = 0x12, }; -static const struct adsp_data sc8180x_mpss_resource = { +static const struct qcom_pas_data sc8180x_mpss_resource = { .crash_reason_smem = 421, .firmware_name = "modem.mdt", .pas_id = 4, @@ -1206,7 +1201,7 @@ static const struct adsp_data sc8180x_mpss_resource = { .ssctl_id = 0x12, }; -static const struct adsp_data msm8996_slpi_resource_init = { +static const struct qcom_pas_data msm8996_slpi_resource_init = { .crash_reason_smem = 424, .firmware_name = "slpi.mdt", .pas_id = 12, @@ -1220,7 +1215,7 @@ static const struct adsp_data msm8996_slpi_resource_init = { .ssctl_id = 0x16, }; -static const struct adsp_data sdm845_slpi_resource_init = { +static const struct qcom_pas_data sdm845_slpi_resource_init = { .crash_reason_smem = 424, .firmware_name = "slpi.mdt", .pas_id = 12, @@ -1236,7 +1231,7 @@ static const struct adsp_data sdm845_slpi_resource_init = { .ssctl_id = 0x16, }; -static const struct adsp_data wcss_resource_init = { +static const struct qcom_pas_data wcss_resource_init = { .crash_reason_smem = 421, .firmware_name = "wcnss.mdt", .pas_id = 6, @@ -1246,7 +1241,7 @@ static const struct adsp_data wcss_resource_init = { .ssctl_id = 0x12, }; -static const struct adsp_data sdx55_mpss_resource = { +static const struct qcom_pas_data sdx55_mpss_resource = { .crash_reason_smem = 421, .firmware_name = "modem.mdt", .pas_id = 4, @@ -1261,7 +1256,7 @@ static const struct adsp_data sdx55_mpss_resource = { .ssctl_id = 0x22, }; -static const struct adsp_data sm8450_mpss_resource = { +static const struct qcom_pas_data sm8450_mpss_resource = { .crash_reason_smem = 421, .firmware_name = "modem.mdt", .pas_id = 4, @@ -1279,7 +1274,7 @@ static const struct adsp_data sm8450_mpss_resource = { .ssctl_id = 0x12, }; -static const struct adsp_data sm8550_adsp_resource = { +static const struct qcom_pas_data sm8550_adsp_resource = { .crash_reason_smem = 423, .firmware_name = "adsp.mdt", .dtb_firmware_name = "adsp_dtb.mdt", @@ -1299,7 +1294,7 @@ static const struct adsp_data sm8550_adsp_resource = { .smem_host_id = 2, }; -static const struct adsp_data sm8550_cdsp_resource = { +static const struct qcom_pas_data sm8550_cdsp_resource = { .crash_reason_smem = 601, .firmware_name = "cdsp.mdt", .dtb_firmware_name = "cdsp_dtb.mdt", @@ -1320,7 +1315,7 @@ static const struct adsp_data sm8550_cdsp_resource = { .smem_host_id = 5, }; -static const struct adsp_data sm8550_mpss_resource = { +static const struct qcom_pas_data sm8550_mpss_resource = { .crash_reason_smem = 421, .firmware_name = "modem.mdt", .dtb_firmware_name = "modem_dtb.mdt", @@ -1344,7 +1339,7 @@ static const struct adsp_data sm8550_mpss_resource = { .region_assign_vmid = QCOM_SCM_VMID_MSS_MSA, }; -static const struct adsp_data sc7280_wpss_resource = { +static const struct qcom_pas_data sc7280_wpss_resource = { .crash_reason_smem = 626, .firmware_name = "wpss.mdt", .pas_id = 6, @@ -1361,7 +1356,7 @@ static const struct adsp_data sc7280_wpss_resource = { .ssctl_id = 0x19, }; -static const struct adsp_data sm8650_cdsp_resource = { +static const struct qcom_pas_data sm8650_cdsp_resource = { .crash_reason_smem = 601, .firmware_name = "cdsp.mdt", .dtb_firmware_name = "cdsp_dtb.mdt", @@ -1386,7 +1381,7 @@ static const struct adsp_data sm8650_cdsp_resource = { .region_assign_vmid = QCOM_SCM_VMID_CDSP, }; -static const struct adsp_data sm8650_mpss_resource = { +static const struct qcom_pas_data sm8650_mpss_resource = { .crash_reason_smem = 421, .firmware_name = "modem.mdt", .dtb_firmware_name = "modem_dtb.mdt", @@ -1410,7 +1405,7 @@ static const struct adsp_data sm8650_mpss_resource = { .region_assign_vmid = QCOM_SCM_VMID_MSS_MSA, }; -static const struct adsp_data sm8750_mpss_resource = { +static const struct qcom_pas_data sm8750_mpss_resource = { .crash_reason_smem = 421, .firmware_name = "modem.mdt", .dtb_firmware_name = "modem_dtb.mdt", @@ -1434,7 +1429,7 @@ static const struct adsp_data sm8750_mpss_resource = { .region_assign_vmid = QCOM_SCM_VMID_MSS_MSA, }; -static const struct of_device_id adsp_of_match[] = { +static const struct of_device_id qcom_pas_of_match[] = { { .compatible = "qcom,msm8226-adsp-pil", .data = &msm8996_adsp_resource}, { .compatible = "qcom,msm8953-adsp-pil", .data = &msm8996_adsp_resource}, { .compatible = "qcom,msm8974-adsp-pil", .data = &adsp_resource_init}, @@ -1504,17 +1499,17 @@ static const struct of_device_id adsp_of_match[] = { { .compatible = "qcom,x1e80100-cdsp-pas", .data = &x1e80100_cdsp_resource}, { }, }; -MODULE_DEVICE_TABLE(of, adsp_of_match); +MODULE_DEVICE_TABLE(of, qcom_pas_of_match); -static struct platform_driver adsp_driver = { - .probe = adsp_probe, - .remove = adsp_remove, +static struct platform_driver qcom_pas_driver = { + .probe = qcom_pas_probe, + .remove = qcom_pas_remove, .driver = { .name = "qcom_q6v5_pas", - .of_match_table = adsp_of_match, + .of_match_table = qcom_pas_of_match, }, }; -module_platform_driver(adsp_driver); -MODULE_DESCRIPTION("Qualcomm Hexagon v5 Peripheral Authentication Service driver"); +module_platform_driver(qcom_pas_driver); +MODULE_DESCRIPTION("Qualcomm Peripheral Authentication Service remoteproc driver"); MODULE_LICENSE("GPL v2"); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 224/480] PCI: rockchip-host: Fix "Unexpected Completion" log message 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (222 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 223/480] remoteproc: qcom: pas: Conclude the rename from adsp Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 225/480] clk: renesas: rzv2h: Fix missing CLK_SET_RATE_PARENT flag for ddiv clocks Greg Kroah-Hartman ` (267 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Hans Zhang, Manivannan Sadhasivam, Shawn Lin, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Hans Zhang <18255117159@163.com> [ Upstream commit fcc5f586c4edbcc10de23fb9b8c0972a84e945cd ] Fix the debug message for the PCIE_CORE_INT_UCR interrupt to clearly indicate "Unexpected Completion" instead of a duplicate "malformed TLP" message. Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support") Signed-off-by: Hans Zhang <18255117159@163.com> [mani: added fixes tag] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Acked-by: Shawn Lin <shawn.lin@rock-chips.com> Link: https://patch.msgid.link/20250607160201.807043-2-18255117159@163.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/pci/controller/pcie-rockchip-host.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/controller/pcie-rockchip-host.c b/drivers/pci/controller/pcie-rockchip-host.c index 6a46be17aa91..2804980bab86 100644 --- a/drivers/pci/controller/pcie-rockchip-host.c +++ b/drivers/pci/controller/pcie-rockchip-host.c @@ -439,7 +439,7 @@ static irqreturn_t rockchip_pcie_subsys_irq_handler(int irq, void *arg) dev_dbg(dev, "malformed TLP received from the link\n"); if (sub_reg & PCIE_CORE_INT_UCR) - dev_dbg(dev, "malformed TLP received from the link\n"); + dev_dbg(dev, "Unexpected Completion received from the link\n"); if (sub_reg & PCIE_CORE_INT_FCE) dev_dbg(dev, "an error was observed in the flow control advertisements from the other side\n"); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 225/480] clk: renesas: rzv2h: Fix missing CLK_SET_RATE_PARENT flag for ddiv clocks 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (223 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 224/480] PCI: rockchip-host: Fix "Unexpected Completion" log message Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 226/480] crypto: sun8i-ce - fix nents passed to dma_unmap_sg() Greg Kroah-Hartman ` (266 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Lad Prabhakar, Geert Uytterhoeven, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> [ Upstream commit 715676d8418062f54d746451294ccce9786c1734 ] Commit bc4d25fdfadf ("clk: renesas: rzv2h: Add support for dynamic switching divider clocks") missed setting the `CLK_SET_RATE_PARENT` flag when registering ddiv clocks. Without this flag, rate changes to the divider clock do not propagate to its parent, potentially resulting in incorrect clock configurations. Fix this by setting `CLK_SET_RATE_PARENT` in the clock init data. Fixes: bc4d25fdfadfa ("clk: renesas: rzv2h: Add support for dynamic switching divider clocks") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250609140341.235919-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/clk/renesas/rzv2h-cpg.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/renesas/rzv2h-cpg.c b/drivers/clk/renesas/rzv2h-cpg.c index 2b9771ab2b3f..43d2e73f9601 100644 --- a/drivers/clk/renesas/rzv2h-cpg.c +++ b/drivers/clk/renesas/rzv2h-cpg.c @@ -323,6 +323,7 @@ rzv2h_cpg_ddiv_clk_register(const struct cpg_core_clk *core, init.ops = &rzv2h_ddiv_clk_divider_ops; init.parent_names = &parent_name; init.num_parents = 1; + init.flags = CLK_SET_RATE_PARENT; ddiv->priv = priv; ddiv->mon = cfg_ddiv.monbit; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 226/480] crypto: sun8i-ce - fix nents passed to dma_unmap_sg() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (224 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 225/480] clk: renesas: rzv2h: Fix missing CLK_SET_RATE_PARENT flag for ddiv clocks Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 227/480] crypto: qat - use unmanaged allocation for dc_data Greg Kroah-Hartman ` (265 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Ovidiu Panait, Corentin LABBE, Herbert Xu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ovidiu Panait <ovidiu.panait.oss@gmail.com> [ Upstream commit b6cd3cfb5afe49952f8f6be947aeeca9ba0faebb ] In sun8i_ce_cipher_unprepare(), dma_unmap_sg() is incorrectly called with the number of entries returned by dma_map_sg(), rather than using the original number of entries passed when mapping the scatterlist. To fix this, stash the original number of entries passed to dma_map_sg() in the request context. Fixes: 0605fa0f7826 ("crypto: sun8i-ce - split into prepare/run/unprepare") Signed-off-by: Ovidiu Panait <ovidiu.panait.oss@gmail.com> Acked-by: Corentin LABBE <clabbe.montjoie@gmail.com> Tested-by: Corentin LABBE <clabbe.montjoie@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c index 05f67661553c..63e66a85477e 100644 --- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c +++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c @@ -265,8 +265,8 @@ static int sun8i_ce_cipher_prepare(struct crypto_engine *engine, void *async_req } chan->timeout = areq->cryptlen; - rctx->nr_sgs = nr_sgs; - rctx->nr_sgd = nr_sgd; + rctx->nr_sgs = ns; + rctx->nr_sgd = nd; return 0; theend_sgs: -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 227/480] crypto: qat - use unmanaged allocation for dc_data 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (225 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 226/480] crypto: sun8i-ce - fix nents passed to dma_unmap_sg() Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 228/480] crypto: marvell/cesa - Fix engine load inaccuracy Greg Kroah-Hartman ` (264 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Suman Kumar Chakraborty, Giovanni Cabiddu, Herbert Xu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Suman Kumar Chakraborty <suman.kumar.chakraborty@intel.com> [ Upstream commit 4cc871ad0173e8bc22f80e3609e34d546d30ef1a ] The dc_data structure holds data required for handling compression operations, such as overflow buffers. In this context, the use of managed memory allocation APIs (devm_kzalloc() and devm_kfree()) is not necessary, as these data structures are freed and re-allocated when a device is restarted in adf_dev_down() and adf_dev_up(). Additionally, managed APIs automatically handle memory cleanup when the device is detached, which can lead to conflicts with manual cleanup processes. Specifically, if a device driver invokes the adf_dev_down() function as part of the cleanup registered with devm_add_action_or_reset(), it may attempt to free memory that is also managed by the device's resource management system, potentially leading to a double-free. This might result in a warning similar to the following when unloading the device specific driver, for example qat_6xxx.ko: qat_free_dc_data+0x4f/0x60 [intel_qat] qat_compression_event_handler+0x3d/0x1d0 [intel_qat] adf_dev_shutdown+0x6d/0x1a0 [intel_qat] adf_dev_down+0x32/0x50 [intel_qat] devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c1/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x74/0xf0 pci_unregister_driver+0x2e/0xb0 Use unmanaged memory allocation APIs (kzalloc_node() and kfree()) for the dc_data structure. This ensures that memory is explicitly allocated and freed under the control of the driver code, preventing manual deallocation from interfering with automatic cleanup. Fixes: 1198ae56c9a5 ("crypto: qat - expose deflate through acomp api for QAT GEN2") Signed-off-by: Suman Kumar Chakraborty <suman.kumar.chakraborty@intel.com> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/crypto/intel/qat/qat_common/qat_compression.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/intel/qat/qat_common/qat_compression.c b/drivers/crypto/intel/qat/qat_common/qat_compression.c index 7842a9f22178..2c3aa89b316a 100644 --- a/drivers/crypto/intel/qat/qat_common/qat_compression.c +++ b/drivers/crypto/intel/qat/qat_common/qat_compression.c @@ -197,7 +197,7 @@ static int qat_compression_alloc_dc_data(struct adf_accel_dev *accel_dev) struct adf_dc_data *dc_data = NULL; u8 *obuff = NULL; - dc_data = devm_kzalloc(dev, sizeof(*dc_data), GFP_KERNEL); + dc_data = kzalloc_node(sizeof(*dc_data), GFP_KERNEL, dev_to_node(dev)); if (!dc_data) goto err; @@ -235,7 +235,7 @@ static void qat_free_dc_data(struct adf_accel_dev *accel_dev) dma_unmap_single(dev, dc_data->ovf_buff_p, dc_data->ovf_buff_sz, DMA_FROM_DEVICE); kfree_sensitive(dc_data->ovf_buff); - devm_kfree(dev, dc_data); + kfree(dc_data); accel_dev->dc_data = NULL; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 228/480] crypto: marvell/cesa - Fix engine load inaccuracy 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (226 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 227/480] crypto: qat - use unmanaged allocation for dc_data Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 229/480] padata: Fix pd UAF once and for all Greg Kroah-Hartman ` (263 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Herbert Xu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Herbert Xu <herbert@gondor.apana.org.au> [ Upstream commit 442134ab30e75b7229c4bfc1ac5641d245cffe27 ] If an error occurs during queueing the engine load will never be decremented. Fix this by moving the engine load adjustment into the cleanup function. Fixes: bf8f91e71192 ("crypto: marvell - Add load balancing between engines") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/crypto/marvell/cesa/cipher.c | 4 +++- drivers/crypto/marvell/cesa/hash.c | 5 +++-- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/crypto/marvell/cesa/cipher.c b/drivers/crypto/marvell/cesa/cipher.c index 48c5c8ea8c43..3fe0fd9226cf 100644 --- a/drivers/crypto/marvell/cesa/cipher.c +++ b/drivers/crypto/marvell/cesa/cipher.c @@ -75,9 +75,12 @@ mv_cesa_skcipher_dma_cleanup(struct skcipher_request *req) static inline void mv_cesa_skcipher_cleanup(struct skcipher_request *req) { struct mv_cesa_skcipher_req *creq = skcipher_request_ctx(req); + struct mv_cesa_engine *engine = creq->base.engine; if (mv_cesa_req_get_type(&creq->base) == CESA_DMA_REQ) mv_cesa_skcipher_dma_cleanup(req); + + atomic_sub(req->cryptlen, &engine->load); } static void mv_cesa_skcipher_std_step(struct skcipher_request *req) @@ -212,7 +215,6 @@ mv_cesa_skcipher_complete(struct crypto_async_request *req) struct mv_cesa_engine *engine = creq->base.engine; unsigned int ivsize; - atomic_sub(skreq->cryptlen, &engine->load); ivsize = crypto_skcipher_ivsize(crypto_skcipher_reqtfm(skreq)); if (mv_cesa_req_get_type(&creq->base) == CESA_DMA_REQ) { diff --git a/drivers/crypto/marvell/cesa/hash.c b/drivers/crypto/marvell/cesa/hash.c index 6815eddc9068..e339ce7ad533 100644 --- a/drivers/crypto/marvell/cesa/hash.c +++ b/drivers/crypto/marvell/cesa/hash.c @@ -110,9 +110,12 @@ static inline void mv_cesa_ahash_dma_cleanup(struct ahash_request *req) static inline void mv_cesa_ahash_cleanup(struct ahash_request *req) { struct mv_cesa_ahash_req *creq = ahash_request_ctx(req); + struct mv_cesa_engine *engine = creq->base.engine; if (mv_cesa_req_get_type(&creq->base) == CESA_DMA_REQ) mv_cesa_ahash_dma_cleanup(req); + + atomic_sub(req->nbytes, &engine->load); } static void mv_cesa_ahash_last_cleanup(struct ahash_request *req) @@ -395,8 +398,6 @@ static void mv_cesa_ahash_complete(struct crypto_async_request *req) } } } - - atomic_sub(ahashreq->nbytes, &engine->load); } static void mv_cesa_ahash_prepare(struct crypto_async_request *req, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 229/480] padata: Fix pd UAF once and for all 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (227 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 228/480] crypto: marvell/cesa - Fix engine load inaccuracy Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 230/480] crypto: qat - allow enabling VFs in the absence of IOMMU Greg Kroah-Hartman ` (262 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Herbert Xu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Herbert Xu <herbert@gondor.apana.org.au> [ Upstream commit 71203f68c7749609d7fc8ae6ad054bdedeb24f91 ] There is a race condition/UAF in padata_reorder that goes back to the initial commit. A reference count is taken at the start of the process in padata_do_parallel, and released at the end in padata_serial_worker. This reference count is (and only is) required for padata_replace to function correctly. If padata_replace is never called then there is no issue. In the function padata_reorder which serves as the core of padata, as soon as padata is added to queue->serial.list, and the associated spin lock released, that padata may be processed and the reference count on pd would go away. Fix this by getting the next padata before the squeue->serial lock is released. In order to make this possible, simplify padata_reorder by only calling it once the next padata arrives. Fixes: 16295bec6398 ("padata: Generic parallelization/serialization interface") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> --- include/linux/padata.h | 3 - kernel/padata.c | 132 ++++++++++++----------------------------- 2 files changed, 37 insertions(+), 98 deletions(-) diff --git a/include/linux/padata.h b/include/linux/padata.h index 0146daf34430..b486c7359de2 100644 --- a/include/linux/padata.h +++ b/include/linux/padata.h @@ -91,7 +91,6 @@ struct padata_cpumask { * @cpu: Next CPU to be processed. * @cpumask: The cpumasks in use for parallel and serial workers. * @reorder_work: work struct for reordering. - * @lock: Reorder lock. */ struct parallel_data { struct padata_shell *ps; @@ -102,8 +101,6 @@ struct parallel_data { unsigned int processed; int cpu; struct padata_cpumask cpumask; - struct work_struct reorder_work; - spinlock_t ____cacheline_aligned lock; }; /** diff --git a/kernel/padata.c b/kernel/padata.c index 7eee94166357..25cd3406477a 100644 --- a/kernel/padata.c +++ b/kernel/padata.c @@ -261,20 +261,17 @@ EXPORT_SYMBOL(padata_do_parallel); * be parallel processed by another cpu and is not yet present in * the cpu's reorder queue. */ -static struct padata_priv *padata_find_next(struct parallel_data *pd, - bool remove_object) +static struct padata_priv *padata_find_next(struct parallel_data *pd, int cpu, + unsigned int processed) { struct padata_priv *padata; struct padata_list *reorder; - int cpu = pd->cpu; reorder = per_cpu_ptr(pd->reorder_list, cpu); spin_lock(&reorder->lock); - if (list_empty(&reorder->list)) { - spin_unlock(&reorder->lock); - return NULL; - } + if (list_empty(&reorder->list)) + goto notfound; padata = list_entry(reorder->list.next, struct padata_priv, list); @@ -282,97 +279,52 @@ static struct padata_priv *padata_find_next(struct parallel_data *pd, * Checks the rare case where two or more parallel jobs have hashed to * the same CPU and one of the later ones finishes first. */ - if (padata->seq_nr != pd->processed) { - spin_unlock(&reorder->lock); - return NULL; - } - - if (remove_object) { - list_del_init(&padata->list); - ++pd->processed; - pd->cpu = cpumask_next_wrap(cpu, pd->cpumask.pcpu); - } + if (padata->seq_nr != processed) + goto notfound; + list_del_init(&padata->list); spin_unlock(&reorder->lock); return padata; + +notfound: + pd->processed = processed; + pd->cpu = cpu; + spin_unlock(&reorder->lock); + return NULL; } -static void padata_reorder(struct parallel_data *pd) +static void padata_reorder(struct padata_priv *padata) { + struct parallel_data *pd = padata->pd; struct padata_instance *pinst = pd->ps->pinst; - int cb_cpu; - struct padata_priv *padata; - struct padata_serial_queue *squeue; - struct padata_list *reorder; + unsigned int processed; + int cpu; - /* - * We need to ensure that only one cpu can work on dequeueing of - * the reorder queue the time. Calculating in which percpu reorder - * queue the next object will arrive takes some time. A spinlock - * would be highly contended. Also it is not clear in which order - * the objects arrive to the reorder queues. So a cpu could wait to - * get the lock just to notice that there is nothing to do at the - * moment. Therefore we use a trylock and let the holder of the lock - * care for all the objects enqueued during the holdtime of the lock. - */ - if (!spin_trylock_bh(&pd->lock)) - return; + processed = pd->processed; + cpu = pd->cpu; - while (1) { - padata = padata_find_next(pd, true); + do { + struct padata_serial_queue *squeue; + int cb_cpu; - /* - * If the next object that needs serialization is parallel - * processed by another cpu and is still on it's way to the - * cpu's reorder queue, nothing to do for now. - */ - if (!padata) - break; + cpu = cpumask_next_wrap(cpu, pd->cpumask.pcpu); + processed++; cb_cpu = padata->cb_cpu; squeue = per_cpu_ptr(pd->squeue, cb_cpu); spin_lock(&squeue->serial.lock); list_add_tail(&padata->list, &squeue->serial.list); - spin_unlock(&squeue->serial.lock); - queue_work_on(cb_cpu, pinst->serial_wq, &squeue->work); - } - spin_unlock_bh(&pd->lock); - - /* - * The next object that needs serialization might have arrived to - * the reorder queues in the meantime. - * - * Ensure reorder queue is read after pd->lock is dropped so we see - * new objects from another task in padata_do_serial. Pairs with - * smp_mb in padata_do_serial. - */ - smp_mb(); - - reorder = per_cpu_ptr(pd->reorder_list, pd->cpu); - if (!list_empty(&reorder->list) && padata_find_next(pd, false)) { /* - * Other context(eg. the padata_serial_worker) can finish the request. - * To avoid UAF issue, add pd ref here, and put pd ref after reorder_work finish. + * If the next object that needs serialization is parallel + * processed by another cpu and is still on it's way to the + * cpu's reorder queue, end the loop. */ - padata_get_pd(pd); - if (!queue_work(pinst->serial_wq, &pd->reorder_work)) - padata_put_pd(pd); - } -} - -static void invoke_padata_reorder(struct work_struct *work) -{ - struct parallel_data *pd; - - local_bh_disable(); - pd = container_of(work, struct parallel_data, reorder_work); - padata_reorder(pd); - local_bh_enable(); - /* Pairs with putting the reorder_work in the serial_wq */ - padata_put_pd(pd); + padata = padata_find_next(pd, cpu, processed); + spin_unlock(&squeue->serial.lock); + } while (padata); } static void padata_serial_worker(struct work_struct *serial_work) @@ -423,6 +375,7 @@ void padata_do_serial(struct padata_priv *padata) struct padata_list *reorder = per_cpu_ptr(pd->reorder_list, hashed_cpu); struct padata_priv *cur; struct list_head *pos; + bool gotit = true; spin_lock(&reorder->lock); /* Sort in ascending order of sequence number. */ @@ -432,17 +385,14 @@ void padata_do_serial(struct padata_priv *padata) if ((signed int)(cur->seq_nr - padata->seq_nr) < 0) break; } - list_add(&padata->list, pos); + if (padata->seq_nr != pd->processed) { + gotit = false; + list_add(&padata->list, pos); + } spin_unlock(&reorder->lock); - /* - * Ensure the addition to the reorder list is ordered correctly - * with the trylock of pd->lock in padata_reorder. Pairs with smp_mb - * in padata_reorder. - */ - smp_mb(); - - padata_reorder(pd); + if (gotit) + padata_reorder(padata); } EXPORT_SYMBOL(padata_do_serial); @@ -632,9 +582,7 @@ static struct parallel_data *padata_alloc_pd(struct padata_shell *ps) padata_init_squeues(pd); pd->seq_nr = -1; refcount_set(&pd->refcnt, 1); - spin_lock_init(&pd->lock); pd->cpu = cpumask_first(pd->cpumask.pcpu); - INIT_WORK(&pd->reorder_work, invoke_padata_reorder); return pd; @@ -1144,12 +1092,6 @@ void padata_free_shell(struct padata_shell *ps) if (!ps) return; - /* - * Wait for all _do_serial calls to finish to avoid touching - * freed pd's and ps's. - */ - synchronize_rcu(); - mutex_lock(&ps->pinst->lock); list_del(&ps->list); pd = rcu_dereference_protected(ps->pd, 1); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 230/480] crypto: qat - allow enabling VFs in the absence of IOMMU 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (228 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 229/480] padata: Fix pd UAF once and for all Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 231/480] crypto: qat - fix state restore for banks with exceptions Greg Kroah-Hartman ` (261 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Ahsan Atta, Giovanni Cabiddu, Michal Witwicki, Herbert Xu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ahsan Atta <ahsan.atta@intel.com> [ Upstream commit 53669ff591d4deb2d80eed4c07593ad0c0b45899 ] The commit ca88a2bdd4dd ("crypto: qat - allow disabling SR-IOV VFs") introduced an unnecessary change that prevented enabling SR-IOV when IOMMU is disabled. In certain scenarios, it is desirable to enable SR-IOV even in the absence of IOMMU. Thus, restoring the previous functionality to allow VFs to be enumerated in the absence of IOMMU. Fixes: ca88a2bdd4dd ("crypto: qat - allow disabling SR-IOV VFs") Signed-off-by: Ahsan Atta <ahsan.atta@intel.com> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by: Michal Witwicki <michal.witwicki@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/crypto/intel/qat/qat_common/adf_sriov.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/crypto/intel/qat/qat_common/adf_sriov.c b/drivers/crypto/intel/qat/qat_common/adf_sriov.c index c75d0b6cb0ad..31d1ef0cb1f5 100644 --- a/drivers/crypto/intel/qat/qat_common/adf_sriov.c +++ b/drivers/crypto/intel/qat/qat_common/adf_sriov.c @@ -155,7 +155,6 @@ static int adf_do_enable_sriov(struct adf_accel_dev *accel_dev) if (!device_iommu_mapped(&GET_DEV(accel_dev))) { dev_warn(&GET_DEV(accel_dev), "IOMMU should be enabled for SR-IOV to work correctly\n"); - return -EINVAL; } if (adf_dev_started(accel_dev)) { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 231/480] crypto: qat - fix state restore for banks with exceptions 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (229 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 230/480] crypto: qat - allow enabling VFs in the absence of IOMMU Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 232/480] mtd: fix possible integer overflow in erase_xfer() Greg Kroah-Hartman ` (260 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Svyatoslav Pankratov, Giovanni Cabiddu, Herbert Xu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Svyatoslav Pankratov <svyatoslav.pankratov@intel.com> [ Upstream commit 254923ca8715f623704378266815b6d14eb26194 ] Change the logic in the restore function to properly handle bank exceptions. The check for exceptions in the saved state should be performed before conducting any other ringstat register checks. If a bank was saved with an exception, the ringstat will have the appropriate rp_halt/rp_exception bits set, causing the driver to exit the restore process with an error. Instead, the restore routine should first check the ringexpstat register, and if any exception was raised, it should stop further checks and return without any error. In other words, if a ring pair is in an exception state at the source, it should be restored the same way at the destination but without raising an error. Even though this approach might lead to losing the exception state during migration, the driver will log the exception from the saved state during the restore process. Signed-off-by: Svyatoslav Pankratov <svyatoslav.pankratov@intel.com> Fixes: bbfdde7d195f ("crypto: qat - add bank save and restore flows") Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> --- .../intel/qat/qat_common/adf_gen4_hw_data.c | 29 ++++++++++++++----- 1 file changed, 22 insertions(+), 7 deletions(-) diff --git a/drivers/crypto/intel/qat/qat_common/adf_gen4_hw_data.c b/drivers/crypto/intel/qat/qat_common/adf_gen4_hw_data.c index 099949a2421c..b661736d9ae1 100644 --- a/drivers/crypto/intel/qat/qat_common/adf_gen4_hw_data.c +++ b/drivers/crypto/intel/qat/qat_common/adf_gen4_hw_data.c @@ -579,6 +579,28 @@ static int bank_state_restore(struct adf_hw_csr_ops *ops, void __iomem *base, ops->write_csr_int_srcsel_w_val(base, bank, state->iaintflagsrcsel0); ops->write_csr_exp_int_en(base, bank, state->ringexpintenable); ops->write_csr_int_col_ctl(base, bank, state->iaintcolctl); + + /* + * Verify whether any exceptions were raised during the bank save process. + * If exceptions occurred, the status and exception registers cannot + * be directly restored. Consequently, further restoration is not + * feasible, and the current state of the ring should be maintained. + */ + val = state->ringexpstat; + if (val) { + pr_info("QAT: Bank %u state not fully restored due to exception in saved state (%#x)\n", + bank, val); + return 0; + } + + /* Ensure that the restoration process completed without exceptions */ + tmp_val = ops->read_csr_exp_stat(base, bank); + if (tmp_val) { + pr_err("QAT: Bank %u restored with exception: %#x\n", + bank, tmp_val); + return -EFAULT; + } + ops->write_csr_ring_srv_arb_en(base, bank, state->ringsrvarben); /* Check that all ring statuses match the saved state. */ @@ -612,13 +634,6 @@ static int bank_state_restore(struct adf_hw_csr_ops *ops, void __iomem *base, if (ret) return ret; - tmp_val = ops->read_csr_exp_stat(base, bank); - val = state->ringexpstat; - if (tmp_val && !val) { - pr_err("QAT: Bank was restored with exception: 0x%x\n", val); - return -EINVAL; - } - return 0; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 232/480] mtd: fix possible integer overflow in erase_xfer() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (230 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 231/480] crypto: qat - fix state restore for banks with exceptions Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 233/480] clk: davinci: Add NULL check in davinci_lpsc_clk_register() Greg Kroah-Hartman ` (259 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Ivan Stepchenko, Miquel Raynal, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ivan Stepchenko <sid@itb.spb.ru> [ Upstream commit 9358bdb9f9f54d94ceafc650deffefd737d19fdd ] The expression '1 << EraseUnitSize' is evaluated in int, which causes a negative result when shifting by 31 - the upper bound of the valid range [10, 31], enforced by scan_header(). This leads to incorrect extension when storing the result in 'erase->len' (uint64_t), producing a large unexpected value. Found by Linux Verification Center (linuxtesting.org) with Svace. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ivan Stepchenko <sid@itb.spb.ru> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/mtd/ftl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/ftl.c b/drivers/mtd/ftl.c index 8c22064ead38..f2bd1984609c 100644 --- a/drivers/mtd/ftl.c +++ b/drivers/mtd/ftl.c @@ -344,7 +344,7 @@ static int erase_xfer(partition_t *part, return -ENOMEM; erase->addr = xfer->Offset; - erase->len = 1 << part->header.EraseUnitSize; + erase->len = 1ULL << part->header.EraseUnitSize; ret = mtd_erase(part->mbd.mtd, erase); if (!ret) { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 233/480] clk: davinci: Add NULL check in davinci_lpsc_clk_register() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (231 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 232/480] mtd: fix possible integer overflow in erase_xfer() Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 234/480] media: v4l2-ctrls: Fix H264 SEPARATE_COLOUR_PLANE check Greg Kroah-Hartman ` (258 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Henry Martin, David Lechner, Stephen Boyd, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Henry Martin <bsdhenrymartin@gmail.com> [ Upstream commit 13de464f445d42738fe18c9a28bab056ba3a290a ] devm_kasprintf() returns NULL when memory allocation fails. Currently, davinci_lpsc_clk_register() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue and ensuring no resources are left allocated. Fixes: c6ed4d734bc7 ("clk: davinci: New driver for davinci PSC clocks") Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com> Link: https://lore.kernel.org/r/20250401131341.26800-1-bsdhenrymartin@gmail.com Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/clk/davinci/psc.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/clk/davinci/psc.c b/drivers/clk/davinci/psc.c index b48322176c21..f3ee9397bb0c 100644 --- a/drivers/clk/davinci/psc.c +++ b/drivers/clk/davinci/psc.c @@ -277,6 +277,11 @@ davinci_lpsc_clk_register(struct device *dev, const char *name, lpsc->pm_domain.name = devm_kasprintf(dev, GFP_KERNEL, "%s: %s", best_dev_name(dev), name); + if (!lpsc->pm_domain.name) { + clk_hw_unregister(&lpsc->hw); + kfree(lpsc); + return ERR_PTR(-ENOMEM); + } lpsc->pm_domain.attach_dev = davinci_psc_genpd_attach_dev; lpsc->pm_domain.detach_dev = davinci_psc_genpd_detach_dev; lpsc->pm_domain.flags = GENPD_FLAG_PM_CLK; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 234/480] media: v4l2-ctrls: Fix H264 SEPARATE_COLOUR_PLANE check 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (232 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 233/480] clk: davinci: Add NULL check in davinci_lpsc_clk_register() Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 235/480] perf parse-events: Set default GH modifier properly Greg Kroah-Hartman ` (257 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, James Cowgill, Nicolas Dufresne, Hans Verkuil, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: James Cowgill <james.cowgill@blaize.com> [ Upstream commit 803b9eabc649c778986449eb0596e5ffeb7a8aed ] The `separate_colour_plane_flag` element is only present in the SPS if `chroma_format_idc == 3`, so the corresponding flag should be disabled whenever that is not the case and not just on profiles where `chroma_format_idc` is not present. Fixes: b32e48503df0 ("media: controls: Validate H264 stateless controls") Signed-off-by: James Cowgill <james.cowgill@blaize.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/media/v4l2-core/v4l2-ctrls-core.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-ctrls-core.c b/drivers/media/v4l2-core/v4l2-ctrls-core.c index 90d25329661e..b45809a82f9a 100644 --- a/drivers/media/v4l2-core/v4l2-ctrls-core.c +++ b/drivers/media/v4l2-core/v4l2-ctrls-core.c @@ -968,12 +968,12 @@ static int std_validate_compound(const struct v4l2_ctrl *ctrl, u32 idx, p_h264_sps->flags &= ~V4L2_H264_SPS_FLAG_QPPRIME_Y_ZERO_TRANSFORM_BYPASS; - - if (p_h264_sps->chroma_format_idc < 3) - p_h264_sps->flags &= - ~V4L2_H264_SPS_FLAG_SEPARATE_COLOUR_PLANE; } + if (p_h264_sps->chroma_format_idc < 3) + p_h264_sps->flags &= + ~V4L2_H264_SPS_FLAG_SEPARATE_COLOUR_PLANE; + if (p_h264_sps->flags & V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY) p_h264_sps->flags &= ~V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 235/480] perf parse-events: Set default GH modifier properly 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (233 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 234/480] media: v4l2-ctrls: Fix H264 SEPARATE_COLOUR_PLANE check Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 236/480] clk: xilinx: vcu: unregister pll_post only if registered correctly Greg Kroah-Hartman ` (256 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Ian Rogers, Namhyung Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Namhyung Kim <namhyung@kernel.org> [ Upstream commit dcbe6e51a0bb80a40f9a8c87750c291c2364573d ] Commit 7b100989b4f6bce7 ("perf evlist: Remove __evlist__add_default") changed to use "cycles:P" as a default event. But the problem is it cannot set other default modifiers correctly. perf kvm needs to set attr.exclude_host by default but it didn't work because of the logic in the parse_events__modifier_list(). Also the exclude_GH_default was applied only if ":u" modifier was specified - which is strange. Move it out after handling the ":GH" and check perf_host and perf_guest properly. Before: $ ./perf kvm record -vv true |& grep exclude (nothing) But specifying an event (without a modifier) works: $ ./perf kvm record -vv -e cycles true |& grep exclude exclude_host 1 After: It now works for the both cases: $ ./perf kvm record -vv true |& grep exclude exclude_host 1 $ ./perf kvm record -vv -e cycles true |& grep exclude exclude_host 1 Reviewed-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20250606225431.2109754-1-namhyung@kernel.org Fixes: 35c8d21371e9b342 ("perf tools: Don't set attr.exclude_guest by default") Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/perf/util/parse-events.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c index 5152fd5a6ead..7ed3c3cadd6a 100644 --- a/tools/perf/util/parse-events.c +++ b/tools/perf/util/parse-events.c @@ -1733,13 +1733,11 @@ static int parse_events__modifier_list(struct parse_events_state *parse_state, int eH = group ? evsel->core.attr.exclude_host : 0; int eG = group ? evsel->core.attr.exclude_guest : 0; int exclude = eu | ek | eh; - int exclude_GH = group ? evsel->exclude_GH : 0; + int exclude_GH = eG | eH; if (mod.user) { if (!exclude) exclude = eu = ek = eh = 1; - if (!exclude_GH && !perf_guest && exclude_GH_default) - eG = 1; eu = 0; } if (mod.kernel) { @@ -1762,6 +1760,13 @@ static int parse_events__modifier_list(struct parse_events_state *parse_state, exclude_GH = eG = eH = 1; eH = 0; } + if (!exclude_GH && exclude_GH_default) { + if (perf_host) + eG = 1; + else if (perf_guest) + eH = 1; + } + evsel->core.attr.exclude_user = eu; evsel->core.attr.exclude_kernel = ek; evsel->core.attr.exclude_hv = eh; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 236/480] clk: xilinx: vcu: unregister pll_post only if registered correctly 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (234 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 235/480] perf parse-events: Set default GH modifier properly Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 237/480] power: supply: cpcap-charger: Fix null check for power_supply_get_by_name Greg Kroah-Hartman ` (255 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Rohit Visavalia, Stephen Boyd, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Rohit Visavalia <rohit.visavalia@amd.com> [ Upstream commit 3b0abc443ac22f7d4f61ddbbbbc5dbb06c87139d ] If registration of pll_post is failed, it will be set to NULL or ERR, unregistering same will fail with following call trace: Unable to handle kernel NULL pointer dereference at virtual address 008 pc : clk_hw_unregister+0xc/0x20 lr : clk_hw_unregister_fixed_factor+0x18/0x30 sp : ffff800011923850 ... Call trace: clk_hw_unregister+0xc/0x20 clk_hw_unregister_fixed_factor+0x18/0x30 xvcu_unregister_clock_provider+0xcc/0xf4 [xlnx_vcu] xvcu_probe+0x2bc/0x53c [xlnx_vcu] Fixes: 4472e1849db7 ("soc: xilinx: vcu: make pll post divider explicit") Signed-off-by: Rohit Visavalia <rohit.visavalia@amd.com> Link: https://lore.kernel.org/r/20250210113614.4149050-2-rohit.visavalia@amd.com Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/clk/xilinx/xlnx_vcu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/clk/xilinx/xlnx_vcu.c b/drivers/clk/xilinx/xlnx_vcu.c index 81501b48412e..88b3fd8250c2 100644 --- a/drivers/clk/xilinx/xlnx_vcu.c +++ b/drivers/clk/xilinx/xlnx_vcu.c @@ -587,8 +587,8 @@ static void xvcu_unregister_clock_provider(struct xvcu_device *xvcu) xvcu_clk_hw_unregister_leaf(hws[CLK_XVCU_ENC_MCU]); if (!IS_ERR_OR_NULL(hws[CLK_XVCU_ENC_CORE])) xvcu_clk_hw_unregister_leaf(hws[CLK_XVCU_ENC_CORE]); - - clk_hw_unregister_fixed_factor(xvcu->pll_post); + if (!IS_ERR_OR_NULL(xvcu->pll_post)) + clk_hw_unregister_fixed_factor(xvcu->pll_post); } /** -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 237/480] power: supply: cpcap-charger: Fix null check for power_supply_get_by_name 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (235 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 236/480] clk: xilinx: vcu: unregister pll_post only if registered correctly Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 238/480] power: supply: max14577: Handle NULL pdata when CONFIG_OF is not set Greg Kroah-Hartman ` (254 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Charles Han, Sebastian Reichel, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Charles Han <hanchunchao@inspur.com> [ Upstream commit d9fa3aae08f99493e67fb79413c0e95d30fca5e9 ] In the cpcap_usb_detect() function, the power_supply_get_by_name() function may return `NULL` instead of an error pointer. To prevent potential null pointer dereferences, Added a null check. Fixes: eab4e6d953c1 ("power: supply: cpcap-charger: get the battery inserted infomation from cpcap-battery") Signed-off-by: Charles Han <hanchunchao@inspur.com> Link: https://lore.kernel.org/r/20250519024741.5846-1-hanchunchao@inspur.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/power/supply/cpcap-charger.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/power/supply/cpcap-charger.c b/drivers/power/supply/cpcap-charger.c index 13300dc60baf..d0c3008db534 100644 --- a/drivers/power/supply/cpcap-charger.c +++ b/drivers/power/supply/cpcap-charger.c @@ -689,9 +689,8 @@ static void cpcap_usb_detect(struct work_struct *work) struct power_supply *battery; battery = power_supply_get_by_name("battery"); - if (IS_ERR_OR_NULL(battery)) { - dev_err(ddata->dev, "battery power_supply not available %li\n", - PTR_ERR(battery)); + if (!battery) { + dev_err(ddata->dev, "battery power_supply not available\n"); return; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 238/480] power: supply: max14577: Handle NULL pdata when CONFIG_OF is not set 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (236 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 237/480] power: supply: cpcap-charger: Fix null check for power_supply_get_by_name Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 239/480] power: supply: qcom_pmi8998_charger: fix wakeirq Greg Kroah-Hartman ` (253 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Charles Han, Krzysztof Kozlowski, Sebastian Reichel, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Charles Han <hanchunchao@inspur.com> [ Upstream commit 2937f5d2e24eefef8cb126244caec7fe3307f724 ] When the kernel is not configured CONFIG_OF, the max14577_charger_dt_init function returns NULL. Fix the max14577_charger_probe functionby returning -ENODATA instead of potentially passing a NULL pointer to PTR_ERR. This fixes the below smatch warning: max14577_charger_probe() warn: passing zero to 'PTR_ERR' Fixes: e30110e9c96f ("charger: max14577: Configure battery-dependent settings from DTS and sysfs") Signed-off-by: Charles Han <hanchunchao@inspur.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250519061601.8755-1-hanchunchao@inspur.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/power/supply/max14577_charger.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/power/supply/max14577_charger.c b/drivers/power/supply/max14577_charger.c index 1cef2f860b5f..63077d38ea30 100644 --- a/drivers/power/supply/max14577_charger.c +++ b/drivers/power/supply/max14577_charger.c @@ -501,7 +501,7 @@ static struct max14577_charger_platform_data *max14577_charger_dt_init( static struct max14577_charger_platform_data *max14577_charger_dt_init( struct platform_device *pdev) { - return NULL; + return ERR_PTR(-ENODATA); } #endif /* CONFIG_OF */ @@ -572,7 +572,7 @@ static int max14577_charger_probe(struct platform_device *pdev) chg->max14577 = max14577; chg->pdata = max14577_charger_dt_init(pdev); - if (IS_ERR_OR_NULL(chg->pdata)) + if (IS_ERR(chg->pdata)) return PTR_ERR(chg->pdata); ret = max14577_charger_reg_init(chg); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 239/480] power: supply: qcom_pmi8998_charger: fix wakeirq 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (237 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 238/480] power: supply: max14577: Handle NULL pdata when CONFIG_OF is not set Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 240/480] power: supply: max1720x correct capacity computation Greg Kroah-Hartman ` (252 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Casey Connolly, Dmitry Baryshkov, Sebastian Reichel, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Casey Connolly <casey.connolly@linaro.org> [ Upstream commit 6c5393771c50fac30f08dfb6d2f65f4f2cfeb8c7 ] Unloading and reloading the driver (e.g. when built as a module) currently leads to errors trying to enable wake IRQ since it's already enabled. Use devm to manage this for us so it correctly gets disabled when removing the driver. Additionally, call device_init_wakeup() so that charger attach/remove will trigger a wakeup by default. Fixes: 8648aeb5d7b7 ("power: supply: add Qualcomm PMI8998 SMB2 Charger driver") Signed-off-by: Casey Connolly <casey.connolly@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250619-smb2-smb5-support-v1-3-ac5dec51b6e1@linaro.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/power/supply/qcom_pmi8998_charger.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/power/supply/qcom_pmi8998_charger.c b/drivers/power/supply/qcom_pmi8998_charger.c index 74a8d8ed8d9f..8b641b822f52 100644 --- a/drivers/power/supply/qcom_pmi8998_charger.c +++ b/drivers/power/supply/qcom_pmi8998_charger.c @@ -1016,7 +1016,9 @@ static int smb2_probe(struct platform_device *pdev) if (rc < 0) return rc; - rc = dev_pm_set_wake_irq(chip->dev, chip->cable_irq); + devm_device_init_wakeup(chip->dev); + + rc = devm_pm_set_wake_irq(chip->dev, chip->cable_irq); if (rc < 0) return dev_err_probe(chip->dev, rc, "Couldn't set wake irq\n"); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 240/480] power: supply: max1720x correct capacity computation 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (238 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 239/480] power: supply: qcom_pmi8998_charger: fix wakeirq Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 241/480] crypto: arm/aes-neonbs - work around gcc-15 warning Greg Kroah-Hartman ` (251 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Thomas Antoine, Sebastian Reichel, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Antoine <t.antoine@uclouvain.be> [ Upstream commit 58ae036172b5f051a19a32eba94a3e5eb37bf47e ] >From the datasheet of the MAX17201/17205, the LSB should be "5.0μVh/RSENSE". The current computation sets it at 0.5mAh=5.0μVh/10mOhm, which does not take into account the value of rsense (which is in 10µV steps) which can be different from 10mOhm. Change the computation to fit the specs. Fixes: 479b6d04964b ("power: supply: add support for MAX1720x standalone fuel gauge") Signed-off-by: Thomas Antoine <t.antoine@uclouvain.be> Link: https://lore.kernel.org/r/20250523-b4-gs101_max77759_fg-v4-1-b49904e35a34@uclouvain.be Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/power/supply/max1720x_battery.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/power/supply/max1720x_battery.c b/drivers/power/supply/max1720x_battery.c index ea3912fd1de8..68b5314ecf3a 100644 --- a/drivers/power/supply/max1720x_battery.c +++ b/drivers/power/supply/max1720x_battery.c @@ -288,9 +288,10 @@ static int max172xx_voltage_to_ps(unsigned int reg) return reg * 1250; /* in uV */ } -static int max172xx_capacity_to_ps(unsigned int reg) +static int max172xx_capacity_to_ps(unsigned int reg, + struct max1720x_device_info *info) { - return reg * 500; /* in uAh */ + return reg * (500000 / info->rsense); /* in uAh */ } /* @@ -394,11 +395,11 @@ static int max1720x_battery_get_property(struct power_supply *psy, break; case POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN: ret = regmap_read(info->regmap, MAX172XX_DESIGN_CAP, ®_val); - val->intval = max172xx_capacity_to_ps(reg_val); + val->intval = max172xx_capacity_to_ps(reg_val, info); break; case POWER_SUPPLY_PROP_CHARGE_AVG: ret = regmap_read(info->regmap, MAX172XX_REPCAP, ®_val); - val->intval = max172xx_capacity_to_ps(reg_val); + val->intval = max172xx_capacity_to_ps(reg_val, info); break; case POWER_SUPPLY_PROP_TIME_TO_EMPTY_AVG: ret = regmap_read(info->regmap, MAX172XX_TTE, ®_val); @@ -422,7 +423,7 @@ static int max1720x_battery_get_property(struct power_supply *psy, break; case POWER_SUPPLY_PROP_CHARGE_FULL: ret = regmap_read(info->regmap, MAX172XX_FULL_CAP, ®_val); - val->intval = max172xx_capacity_to_ps(reg_val); + val->intval = max172xx_capacity_to_ps(reg_val, info); break; case POWER_SUPPLY_PROP_MODEL_NAME: ret = regmap_read(info->regmap, MAX172XX_DEV_NAME, ®_val); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 241/480] crypto: arm/aes-neonbs - work around gcc-15 warning 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (239 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 240/480] power: supply: max1720x correct capacity computation Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 242/480] PCI: endpoint: pci-epf-vntb: Return -ENOENT if pci_epc_get_next_free_bar() fails Greg Kroah-Hartman ` (250 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Arnd Bergmann, Ard Biesheuvel, Herbert Xu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Arnd Bergmann <arnd@arndb.de> [ Upstream commit d5fa96dc5590915f060fee3209143313e4f5b03b ] I get a very rare -Wstringop-overread warning with gcc-15 for one function in aesbs_ctr_encrypt(): arch/arm/crypto/aes-neonbs-glue.c: In function 'ctr_encrypt': arch/arm/crypto/aes-neonbs-glue.c:212:1446: error: '__builtin_memcpy' offset [17, 2147483647] is out of the bounds [0, 16] of object 'buf' with type 'u8[16]' {aka 'unsigned char[16]'} [-Werror=array-bounds=] 212 | src = dst = memcpy(buf + sizeof(buf) - bytes, arch/arm/crypto/aes-neonbs-glue.c: In function 'ctr_encrypt': arch/arm/crypto/aes-neonbs-glue.c:218:17: error: 'aesbs_ctr_encrypt' reading 1 byte from a region of size 0 [-Werror=stringop-overread] 218 | aesbs_ctr_encrypt(dst, src, ctx->rk, ctx->rounds, bytes, walk.iv); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/arm/crypto/aes-neonbs-glue.c:218:17: note: referencing argument 2 of type 'const u8[0]' {aka 'const unsigned char[]'} arch/arm/crypto/aes-neonbs-glue.c:218:17: note: referencing argument 3 of type 'const u8[0]' {aka 'const unsigned char[]'} arch/arm/crypto/aes-neonbs-glue.c:218:17: note: referencing argument 6 of type 'u8[0]' {aka 'unsigned char[]'} arch/arm/crypto/aes-neonbs-glue.c:36:17: note: in a call to function 'aesbs_ctr_encrypt' 36 | asmlinkage void aesbs_ctr_encrypt(u8 out[], u8 const in[], u8 const rk[], This could happen in theory if walk.nbytes is larger than INT_MAX and gets converted to a negative local variable. Keep the type unsigned like the orignal nbytes to be sure there is no integer overflow. Fixes: c8bf850e991a ("crypto: arm/aes-neonbs-ctr - deal with non-multiples of AES block size") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm/crypto/aes-neonbs-glue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/crypto/aes-neonbs-glue.c b/arch/arm/crypto/aes-neonbs-glue.c index f6be80b5938b..2fad3a0c0563 100644 --- a/arch/arm/crypto/aes-neonbs-glue.c +++ b/arch/arm/crypto/aes-neonbs-glue.c @@ -232,7 +232,7 @@ static int ctr_encrypt(struct skcipher_request *req) while (walk.nbytes > 0) { const u8 *src = walk.src.virt.addr; u8 *dst = walk.dst.virt.addr; - int bytes = walk.nbytes; + unsigned int bytes = walk.nbytes; if (unlikely(bytes < AES_BLOCK_SIZE)) src = dst = memcpy(buf + sizeof(buf) - bytes, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 242/480] PCI: endpoint: pci-epf-vntb: Return -ENOENT if pci_epc_get_next_free_bar() fails 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (240 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 241/480] crypto: arm/aes-neonbs - work around gcc-15 warning Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 243/480] pinctrl: sunxi: Fix memory leak on krealloc failure Greg Kroah-Hartman ` (249 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Jerome Brunet, Manivannan Sadhasivam, Frank Li, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jerome Brunet <jbrunet@baylibre.com> [ Upstream commit 7ea488cce73263231662e426639dd3e836537068 ] According the function documentation of epf_ntb_init_epc_bar(), the function should return an error code on error. However, it returns -1 when no BAR is available i.e., when pci_epc_get_next_free_bar() fails. Return -ENOENT instead. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> [mani: changed err code to -ENOENT] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20250603-pci-vntb-bar-mapping-v2-1-fc685a22ad28@baylibre.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/pci/endpoint/functions/pci-epf-vntb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/endpoint/functions/pci-epf-vntb.c b/drivers/pci/endpoint/functions/pci-epf-vntb.c index 874cb097b093..3cddfdd04029 100644 --- a/drivers/pci/endpoint/functions/pci-epf-vntb.c +++ b/drivers/pci/endpoint/functions/pci-epf-vntb.c @@ -700,7 +700,7 @@ static int epf_ntb_init_epc_bar(struct epf_ntb *ntb) barno = pci_epc_get_next_free_bar(epc_features, barno); if (barno < 0) { dev_err(dev, "Fail to get NTB function BAR\n"); - return barno; + return -ENOENT; } ntb->epf_ntb_bar[bar] = barno; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 243/480] pinctrl: sunxi: Fix memory leak on krealloc failure 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (241 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 242/480] PCI: endpoint: pci-epf-vntb: Return -ENOENT if pci_epc_get_next_free_bar() fails Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 244/480] pinctrl: berlin: fix memory leak in berlin_pinctrl_build_state() Greg Kroah-Hartman ` (248 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Yuan Chen, Linus Walleij, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Yuan Chen <chenyuan@kylinos.cn> [ Upstream commit e3507c56cbb208d4f160942748c527ef6a528ba1 ] In sunxi_pctrl_dt_node_to_map(), when krealloc() fails to resize the pinctrl_map array, the function returns -ENOMEM directly without freeing the previously allocated *map buffer. This results in a memory leak of the original kmalloc_array allocation. Fixes: e11dee2e98f8 ("pinctrl: sunxi: Deal with configless pins") Signed-off-by: Yuan Chen <chenyuan@kylinos.cn> Link: https://lore.kernel.org/20250620012708.16709-1-chenyuan_fl@163.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/pinctrl/sunxi/pinctrl-sunxi.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c index f1c5a991cf7b..ada2ec62916f 100644 --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c @@ -408,6 +408,7 @@ static int sunxi_pctrl_dt_node_to_map(struct pinctrl_dev *pctldev, const char *function, *pin_prop; const char *group; int ret, npins, nmaps, configlen = 0, i = 0; + struct pinctrl_map *new_map; *map = NULL; *num_maps = 0; @@ -482,9 +483,13 @@ static int sunxi_pctrl_dt_node_to_map(struct pinctrl_dev *pctldev, * We know have the number of maps we need, we can resize our * map array */ - *map = krealloc(*map, i * sizeof(struct pinctrl_map), GFP_KERNEL); - if (!*map) - return -ENOMEM; + new_map = krealloc(*map, i * sizeof(struct pinctrl_map), GFP_KERNEL); + if (!new_map) { + ret = -ENOMEM; + goto err_free_map; + } + + *map = new_map; return 0; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 244/480] pinctrl: berlin: fix memory leak in berlin_pinctrl_build_state() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (242 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 243/480] pinctrl: sunxi: Fix memory leak on krealloc failure Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 245/480] pinctrl: canaan: k230: add NULL check in DT parse Greg Kroah-Hartman ` (247 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Yuan Chen, Linus Walleij, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Yuan Chen <chenyuan@kylinos.cn> [ Upstream commit 8f6f303551100291bf2c1e1ccc66b758fffb1168 ] In the original implementation, krealloc() failure handling incorrectly assigned the original memory pointer to NULL after kfree(), causing a memory leak when reallocation failed. Fixes: de845036f997 ("pinctrl: berlin: fix error return code of berlin_pinctrl_build_state()") Signed-off-by: Yuan Chen <chenyuan@kylinos.cn> Link: https://lore.kernel.org/20250620015343.21494-1-chenyuan_fl@163.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/pinctrl/berlin/berlin.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/pinctrl/berlin/berlin.c b/drivers/pinctrl/berlin/berlin.c index c372a2a24be4..9dc2da8056b7 100644 --- a/drivers/pinctrl/berlin/berlin.c +++ b/drivers/pinctrl/berlin/berlin.c @@ -204,6 +204,7 @@ static int berlin_pinctrl_build_state(struct platform_device *pdev) const struct berlin_desc_group *desc_group; const struct berlin_desc_function *desc_function; int i, max_functions = 0; + struct pinfunction *new_functions; pctrl->nfunctions = 0; @@ -229,12 +230,15 @@ static int berlin_pinctrl_build_state(struct platform_device *pdev) } } - pctrl->functions = krealloc(pctrl->functions, + new_functions = krealloc(pctrl->functions, pctrl->nfunctions * sizeof(*pctrl->functions), GFP_KERNEL); - if (!pctrl->functions) + if (!new_functions) { + kfree(pctrl->functions); return -ENOMEM; + } + pctrl->functions = new_functions; /* map functions to theirs groups */ for (i = 0; i < pctrl->desc->ngroups; i++) { desc_group = pctrl->desc->groups + i; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 245/480] pinctrl: canaan: k230: add NULL check in DT parse 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (243 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 244/480] pinctrl: berlin: fix memory leak in berlin_pinctrl_build_state() Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 246/480] pinctrl: canaan: k230: Fix order of DT parse and pinctrl register Greg Kroah-Hartman ` (246 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Yao Zi, Ze Huang, Linus Walleij, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ze Huang <huangze@whut.edu.cn> [ Upstream commit 65bd0be486390fc12a84eafaad78758c5e5a55e6 ] Add a NULL check for the return value of of_get_property() when retrieving the "pinmux" property in the group parser. This avoids a potential NULL pointer dereference if the property is missing from the device tree node. Also fix a typo ("sintenel") in the device ID match table comment, correcting it to "sentinel". Fixes: 545887eab6f6 ("pinctrl: canaan: Add support for k230 SoC") Reported-by: Yao Zi <ziyao@disroot.org> Signed-off-by: Ze Huang <huangze@whut.edu.cn> Link: https://lore.kernel.org/20250624-k230-return-check-v1-1-6b4fc5ba0c41@whut.edu.cn Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/pinctrl/pinctrl-k230.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/pinctrl/pinctrl-k230.c b/drivers/pinctrl/pinctrl-k230.c index a9b4627b46b0..4976308e6237 100644 --- a/drivers/pinctrl/pinctrl-k230.c +++ b/drivers/pinctrl/pinctrl-k230.c @@ -477,6 +477,10 @@ static int k230_pinctrl_parse_groups(struct device_node *np, grp->name = np->name; list = of_get_property(np, "pinmux", &size); + if (!list) { + dev_err(dev, "failed to get pinmux property\n"); + return -EINVAL; + } size /= sizeof(*list); grp->num_pins = size; @@ -623,7 +627,7 @@ static int k230_pinctrl_probe(struct platform_device *pdev) static const struct of_device_id k230_dt_ids[] = { { .compatible = "canaan,k230-pinctrl", }, - { /* sintenel */ } + { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, k230_dt_ids); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 246/480] pinctrl: canaan: k230: Fix order of DT parse and pinctrl register 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (244 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 245/480] pinctrl: canaan: k230: add NULL check in DT parse Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 247/480] PCI: Adjust the position of reading the Link Control 2 register Greg Kroah-Hartman ` (245 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Yao Zi, Ze Huang, Linus Walleij, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ze Huang <huangze@whut.edu.cn> [ Upstream commit d94a32ac688f953dc9a9f12b5b4139ecad841bbb ] Move DT parse before pinctrl register. This ensures that device tree parsing is done before calling devm_pinctrl_register() to prevent using uninitialized pin resources. Fixes: 545887eab6f6 ("pinctrl: canaan: Add support for k230 SoC") Reported-by: Yao Zi <ziyao@disroot.org> Signed-off-by: Ze Huang <huangze@whut.edu.cn> Link: https://lore.kernel.org/20250624-k230-return-check-v1-2-6b4fc5ba0c41@whut.edu.cn Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/pinctrl/pinctrl-k230.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/pinctrl/pinctrl-k230.c b/drivers/pinctrl/pinctrl-k230.c index 4976308e6237..d716f23d837f 100644 --- a/drivers/pinctrl/pinctrl-k230.c +++ b/drivers/pinctrl/pinctrl-k230.c @@ -590,6 +590,7 @@ static int k230_pinctrl_probe(struct platform_device *pdev) struct device *dev = &pdev->dev; struct k230_pinctrl *info; struct pinctrl_desc *pctl; + int ret; info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL); if (!info) @@ -615,13 +616,15 @@ static int k230_pinctrl_probe(struct platform_device *pdev) return dev_err_probe(dev, PTR_ERR(info->regmap_base), "failed to init regmap\n"); + ret = k230_pinctrl_parse_dt(pdev, info); + if (ret) + return ret; + info->pctl_dev = devm_pinctrl_register(dev, pctl, info); if (IS_ERR(info->pctl_dev)) return dev_err_probe(dev, PTR_ERR(info->pctl_dev), "devm_pinctrl_register failed\n"); - k230_pinctrl_parse_dt(pdev, info); - return 0; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 247/480] PCI: Adjust the position of reading the Link Control 2 register 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (245 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 246/480] pinctrl: canaan: k230: Fix order of DT parse and pinctrl register Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 248/480] soundwire: Correct some property names Greg Kroah-Hartman ` (244 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Maciej W. Rozycki, Ilpo Järvinen, Jiwei Sun, Bjorn Helgaas, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jiwei Sun <sunjw10@lenovo.com> [ Upstream commit b85af48de3ece4e5bbdb2248a5360a409991cf67 ] In a89c82249c37 ("PCI: Work around PCIe link training failures"), if the speed limit is set to 2.5 GT/s and the retraining is successful, an attempt will be made to lift the speed limit. One condition for lifting the speed limit is to check whether the link speed field of the Link Control 2 register is PCI_EXP_LNKCTL2_TLS_2_5GT. However, since de9a6c8d5dbf ("PCI/bwctrl: Add pcie_set_target_speed() to set PCIe Link Speed"), the `lnkctl2` local variable does not undergo any changes during the speed limit setting and retraining process. As a result, the code intended to lift the speed limit is not executed. To address this issue, adjust the position of the Link Control 2 register read operation in the code and place it before its use. Fixes: de9a6c8d5dbf ("PCI/bwctrl: Add pcie_set_target_speed() to set PCIe Link Speed") Suggested-by: Maciej W. Rozycki <macro@orcam.me.uk> Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Jiwei Sun <sunjw10@lenovo.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20250123055155.22648-3-sjiwei@163.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/pci/quirks.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index d0f7b749b9a6..6e29f2b39dce 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -109,13 +109,13 @@ int pcie_failed_link_retrain(struct pci_dev *dev) !pcie_cap_has_lnkctl2(dev) || !dev->link_active_reporting) return ret; - pcie_capability_read_word(dev, PCI_EXP_LNKCTL2, &lnkctl2); pcie_capability_read_word(dev, PCI_EXP_LNKSTA, &lnksta); if (!(lnksta & PCI_EXP_LNKSTA_DLLLA) && pcie_lbms_seen(dev, lnksta)) { - u16 oldlnkctl2 = lnkctl2; + u16 oldlnkctl2; pci_info(dev, "broken device, retraining non-functional downstream link at 2.5GT/s\n"); + pcie_capability_read_word(dev, PCI_EXP_LNKCTL2, &oldlnkctl2); ret = pcie_set_target_speed(dev, PCIE_SPEED_2_5GT, false); if (ret) { pci_info(dev, "retraining failed\n"); @@ -127,6 +127,8 @@ int pcie_failed_link_retrain(struct pci_dev *dev) pcie_capability_read_word(dev, PCI_EXP_LNKSTA, &lnksta); } + pcie_capability_read_word(dev, PCI_EXP_LNKCTL2, &lnkctl2); + if ((lnksta & PCI_EXP_LNKSTA_DLLLA) && (lnkctl2 & PCI_EXP_LNKCTL2_TLS) == PCI_EXP_LNKCTL2_TLS_2_5GT && pci_match_id(ids, dev)) { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 248/480] soundwire: Correct some property names 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (246 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 247/480] PCI: Adjust the position of reading the Link Control 2 register Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 249/480] dmaengine: mmp: Fix again Wvoid-pointer-to-enum-cast warning Greg Kroah-Hartman ` (243 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Charles Keepax, Vinod Koul, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Charles Keepax <ckeepax@opensource.cirrus.com> [ Upstream commit ae6a0f5b8a5b0ca2e4bf1c0380267ad83aca8401 ] The DisCo properties should be mipi-sdw-paging-supported and mipi-sdw-bank-delay-supported, with an 'ed' on the end. Correct the property names used in sdw_slave_read_prop(). The internal flag bank_delay_support is currently unimplemented, so that being read wrong does not currently affect anything. The two existing users for this helper and the paging_support flag rt1320-sdw.c and rt721-sdca-sdw.c both manually set the flag in their slave properties, thus are not affected by this bug either. Fixes: 56d4fe31af77 ("soundwire: Add MIPI DisCo property helpers") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20250624125507.2866346-1-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/soundwire/mipi_disco.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/soundwire/mipi_disco.c b/drivers/soundwire/mipi_disco.c index 65afb28ef8fa..c69b78cd0b62 100644 --- a/drivers/soundwire/mipi_disco.c +++ b/drivers/soundwire/mipi_disco.c @@ -451,10 +451,10 @@ int sdw_slave_read_prop(struct sdw_slave *slave) "mipi-sdw-highPHY-capable"); prop->paging_support = mipi_device_property_read_bool(dev, - "mipi-sdw-paging-support"); + "mipi-sdw-paging-supported"); prop->bank_delay_support = mipi_device_property_read_bool(dev, - "mipi-sdw-bank-delay-support"); + "mipi-sdw-bank-delay-supported"); device_property_read_u32(dev, "mipi-sdw-port15-read-behavior", &prop->p15_behave); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 249/480] dmaengine: mmp: Fix again Wvoid-pointer-to-enum-cast warning 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (247 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 248/480] soundwire: Correct some property names Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 250/480] soundwire: debugfs: move debug statement outside of error handling Greg Kroah-Hartman ` (242 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Krzysztof Kozlowski, Vinod Koul, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> [ Upstream commit a0b1589b62e2fcfb112996e0f4d5593bd2edf069 ] This was fixed and re-introduced. 'type' is an enum, thus cast of pointer on 64-bit compile test with W=1 causes: mmp_tdma.c:644:9: error: cast to smaller integer type 'enum mmp_tdma_type' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast] Fixes: a67ba97dfb30 ("dmaengine: Use device_get_match_data()") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250525-dma-fixes-v1-5-89d06dac9bcb@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/dma/mmp_tdma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/mmp_tdma.c b/drivers/dma/mmp_tdma.c index c8dc504510f1..b7fb843c67a6 100644 --- a/drivers/dma/mmp_tdma.c +++ b/drivers/dma/mmp_tdma.c @@ -641,7 +641,7 @@ static int mmp_tdma_probe(struct platform_device *pdev) int chan_num = TDMA_CHANNEL_NUM; struct gen_pool *pool = NULL; - type = (enum mmp_tdma_type)device_get_match_data(&pdev->dev); + type = (kernel_ulong_t)device_get_match_data(&pdev->dev); /* always have couple channels */ tdev = devm_kzalloc(&pdev->dev, sizeof(*tdev), GFP_KERNEL); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 250/480] soundwire: debugfs: move debug statement outside of error handling 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (248 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 249/480] dmaengine: mmp: Fix again Wvoid-pointer-to-enum-cast warning Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 251/480] phy: qualcomm: phy-qcom-eusb2-repeater: Dont zero-out registers Greg Kroah-Hartman ` (241 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Rodrigo Gobbi, Dan Carpenter, Vinod Koul, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Rodrigo Gobbi <rodrigo.gobbi.7@gmail.com> [ Upstream commit 06f77ff9d852c9f2764659ea81489364d8a69a9c ] The start_t and finish_t variables are not properly initialized if errors happens over request_firmware actions. This was also detected by smatch: drivers/soundwire/debugfs.c:301 cmd_go() error: uninitialized symbol 'finish_t'. drivers/soundwire/debugfs.c:301 cmd_go() error: uninitialized symbol 'start_t'. Move the debug statement outside of firmware error handling. Signed-off-by: Rodrigo Gobbi <rodrigo.gobbi.7@gmail.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/linux-sound/0db6d0bf-7bac-43a7-b624-a00d3d2bf829@stanley.mountain/ Fixes: bb5cb09eedce ("soundwire: debugfs: add interface for BPT/BRA transfers") Link: https://lore.kernel.org/r/20250626213628.9575-1-rodrigo.gobbi.7@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/soundwire/debugfs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/soundwire/debugfs.c b/drivers/soundwire/debugfs.c index 3099ea074f10..230a51489486 100644 --- a/drivers/soundwire/debugfs.c +++ b/drivers/soundwire/debugfs.c @@ -291,6 +291,9 @@ static int cmd_go(void *data, u64 value) finish_t = ktime_get(); + dev_dbg(&slave->dev, "command completed, num_byte %zu status %d, time %lld ms\n", + num_bytes, ret, div_u64(finish_t - start_t, NSEC_PER_MSEC)); + out: if (fw) release_firmware(fw); @@ -298,9 +301,6 @@ static int cmd_go(void *data, u64 value) pm_runtime_mark_last_busy(&slave->dev); pm_runtime_put(&slave->dev); - dev_dbg(&slave->dev, "command completed, num_byte %zu status %d, time %lld ms\n", - num_bytes, ret, div_u64(finish_t - start_t, NSEC_PER_MSEC)); - return ret; } DEFINE_DEBUGFS_ATTRIBUTE(cmd_go_fops, NULL, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 251/480] phy: qualcomm: phy-qcom-eusb2-repeater: Dont zero-out registers 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (249 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 250/480] soundwire: debugfs: move debug statement outside of error handling Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 252/480] fanotify: sanitize handle_type values when reporting fid Greg Kroah-Hartman ` (240 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Konrad Dybcio, Neil Armstrong, Luca Weiss, Dmitry Baryshkov, Abel Vesa, Vinod Koul, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Luca Weiss <luca.weiss@fairphone.com> [ Upstream commit 31bc94de76026c527f82c238f414539a14f0f3e6 ] Zeroing out registers does not happen in the downstream kernel, and will "tune" the repeater in surely unexpected ways since most registers don't have a reset value of 0x0. Stop doing that and instead just set the registers that are in the init sequence (though long term I don't think there's actually PMIC-specific init sequences, there's board specific tuning, but that's a story for another day). Fixes: 99a517a582fc ("phy: qualcomm: phy-qcom-eusb2-repeater: Zero out untouched tuning regs") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20250617-eusb2-repeater-tuning-v2-2-ed6c484f18ee@fairphone.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- .../phy/qualcomm/phy-qcom-eusb2-repeater.c | 87 +++++++------------ 1 file changed, 32 insertions(+), 55 deletions(-) diff --git a/drivers/phy/qualcomm/phy-qcom-eusb2-repeater.c b/drivers/phy/qualcomm/phy-qcom-eusb2-repeater.c index 6bd1b3c75c77..d7493c2294ef 100644 --- a/drivers/phy/qualcomm/phy-qcom-eusb2-repeater.c +++ b/drivers/phy/qualcomm/phy-qcom-eusb2-repeater.c @@ -37,32 +37,13 @@ #define EUSB2_TUNE_EUSB_EQU 0x5A #define EUSB2_TUNE_EUSB_HS_COMP_CUR 0x5B -enum eusb2_reg_layout { - TUNE_EUSB_HS_COMP_CUR, - TUNE_EUSB_EQU, - TUNE_EUSB_SLEW, - TUNE_USB2_HS_COMP_CUR, - TUNE_USB2_PREEM, - TUNE_USB2_EQU, - TUNE_USB2_SLEW, - TUNE_SQUELCH_U, - TUNE_HSDISC, - TUNE_RES_FSDIF, - TUNE_IUSB2, - TUNE_USB2_CROSSOVER, - NUM_TUNE_FIELDS, - - FORCE_VAL_5 = NUM_TUNE_FIELDS, - FORCE_EN_5, - - EN_CTL1, - - RPTR_STATUS, - LAYOUT_SIZE, +struct eusb2_repeater_init_tbl_reg { + unsigned int reg; + unsigned int value; }; struct eusb2_repeater_cfg { - const u32 *init_tbl; + const struct eusb2_repeater_init_tbl_reg *init_tbl; int init_tbl_num; const char * const *vreg_list; int num_vregs; @@ -82,16 +63,16 @@ static const char * const pm8550b_vreg_l[] = { "vdd18", "vdd3", }; -static const u32 pm8550b_init_tbl[NUM_TUNE_FIELDS] = { - [TUNE_IUSB2] = 0x8, - [TUNE_SQUELCH_U] = 0x3, - [TUNE_USB2_PREEM] = 0x5, +static const struct eusb2_repeater_init_tbl_reg pm8550b_init_tbl[] = { + { EUSB2_TUNE_IUSB2, 0x8 }, + { EUSB2_TUNE_SQUELCH_U, 0x3 }, + { EUSB2_TUNE_USB2_PREEM, 0x5 }, }; -static const u32 smb2360_init_tbl[NUM_TUNE_FIELDS] = { - [TUNE_IUSB2] = 0x5, - [TUNE_SQUELCH_U] = 0x3, - [TUNE_USB2_PREEM] = 0x2, +static const struct eusb2_repeater_init_tbl_reg smb2360_init_tbl[] = { + { EUSB2_TUNE_IUSB2, 0x5 }, + { EUSB2_TUNE_SQUELCH_U, 0x3 }, + { EUSB2_TUNE_USB2_PREEM, 0x2 }, }; static const struct eusb2_repeater_cfg pm8550b_eusb2_cfg = { @@ -129,17 +110,10 @@ static int eusb2_repeater_init(struct phy *phy) struct eusb2_repeater *rptr = phy_get_drvdata(phy); struct device_node *np = rptr->dev->of_node; struct regmap *regmap = rptr->regmap; - const u32 *init_tbl = rptr->cfg->init_tbl; - u8 tune_usb2_preem = init_tbl[TUNE_USB2_PREEM]; - u8 tune_hsdisc = init_tbl[TUNE_HSDISC]; - u8 tune_iusb2 = init_tbl[TUNE_IUSB2]; u32 base = rptr->base; - u32 val; + u32 poll_val; int ret; - - of_property_read_u8(np, "qcom,tune-usb2-amplitude", &tune_iusb2); - of_property_read_u8(np, "qcom,tune-usb2-disc-thres", &tune_hsdisc); - of_property_read_u8(np, "qcom,tune-usb2-preem", &tune_usb2_preem); + u8 val; ret = regulator_bulk_enable(rptr->cfg->num_vregs, rptr->vregs); if (ret) @@ -147,21 +121,24 @@ static int eusb2_repeater_init(struct phy *phy) regmap_write(regmap, base + EUSB2_EN_CTL1, EUSB2_RPTR_EN); - regmap_write(regmap, base + EUSB2_TUNE_EUSB_HS_COMP_CUR, init_tbl[TUNE_EUSB_HS_COMP_CUR]); - regmap_write(regmap, base + EUSB2_TUNE_EUSB_EQU, init_tbl[TUNE_EUSB_EQU]); - regmap_write(regmap, base + EUSB2_TUNE_EUSB_SLEW, init_tbl[TUNE_EUSB_SLEW]); - regmap_write(regmap, base + EUSB2_TUNE_USB2_HS_COMP_CUR, init_tbl[TUNE_USB2_HS_COMP_CUR]); - regmap_write(regmap, base + EUSB2_TUNE_USB2_EQU, init_tbl[TUNE_USB2_EQU]); - regmap_write(regmap, base + EUSB2_TUNE_USB2_SLEW, init_tbl[TUNE_USB2_SLEW]); - regmap_write(regmap, base + EUSB2_TUNE_SQUELCH_U, init_tbl[TUNE_SQUELCH_U]); - regmap_write(regmap, base + EUSB2_TUNE_RES_FSDIF, init_tbl[TUNE_RES_FSDIF]); - regmap_write(regmap, base + EUSB2_TUNE_USB2_CROSSOVER, init_tbl[TUNE_USB2_CROSSOVER]); - - regmap_write(regmap, base + EUSB2_TUNE_USB2_PREEM, tune_usb2_preem); - regmap_write(regmap, base + EUSB2_TUNE_HSDISC, tune_hsdisc); - regmap_write(regmap, base + EUSB2_TUNE_IUSB2, tune_iusb2); - - ret = regmap_read_poll_timeout(regmap, base + EUSB2_RPTR_STATUS, val, val & RPTR_OK, 10, 5); + /* Write registers from init table */ + for (int i = 0; i < rptr->cfg->init_tbl_num; i++) + regmap_write(regmap, base + rptr->cfg->init_tbl[i].reg, + rptr->cfg->init_tbl[i].value); + + /* Override registers from devicetree values */ + if (!of_property_read_u8(np, "qcom,tune-usb2-amplitude", &val)) + regmap_write(regmap, base + EUSB2_TUNE_USB2_PREEM, val); + + if (!of_property_read_u8(np, "qcom,tune-usb2-disc-thres", &val)) + regmap_write(regmap, base + EUSB2_TUNE_HSDISC, val); + + if (!of_property_read_u8(np, "qcom,tune-usb2-preem", &val)) + regmap_write(regmap, base + EUSB2_TUNE_IUSB2, val); + + /* Wait for status OK */ + ret = regmap_read_poll_timeout(regmap, base + EUSB2_RPTR_STATUS, poll_val, + poll_val & RPTR_OK, 10, 5); if (ret) dev_err(rptr->dev, "initialization timed-out\n"); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 252/480] fanotify: sanitize handle_type values when reporting fid 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (250 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 251/480] phy: qualcomm: phy-qcom-eusb2-repeater: Dont zero-out registers Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 253/480] clk: clk-axi-clkgen: fix fpfd_max frequency for zynq Greg Kroah-Hartman ` (239 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Amir Goldstein, Jan Kara, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Amir Goldstein <amir73il@gmail.com> [ Upstream commit 8631e01c2c5d1fe6705bcc0d733a0b7a17d3daac ] Unlike file_handle, type and len of struct fanotify_fh are u8. Traditionally, filesystem return handle_type < 0xff, but there is no enforecement for that in vfs. Add a sanity check in fanotify to avoid truncating handle_type if its value is > 0xff. Fixes: 7cdafe6cc4a6 ("exportfs: check for error return value from exportfs_encode_*()") Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> Link: https://patch.msgid.link/20250627104835.184495-1-amir73il@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/notify/fanotify/fanotify.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c index 6d386080faf2..7834eadf40a7 100644 --- a/fs/notify/fanotify/fanotify.c +++ b/fs/notify/fanotify/fanotify.c @@ -454,7 +454,13 @@ static int fanotify_encode_fh(struct fanotify_fh *fh, struct inode *inode, dwords = fh_len >> 2; type = exportfs_encode_fid(inode, buf, &dwords); err = -EINVAL; - if (type <= 0 || type == FILEID_INVALID || fh_len != dwords << 2) + /* + * Unlike file_handle, type and len of struct fanotify_fh are u8. + * Traditionally, filesystem return handle_type < 0xff, but there + * is no enforecement for that in vfs. + */ + BUILD_BUG_ON(MAX_HANDLE_SZ > 0xff || FILEID_INVALID > 0xff); + if (type <= 0 || type >= FILEID_INVALID || fh_len != dwords << 2) goto out_err; fh->type = type; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 253/480] clk: clk-axi-clkgen: fix fpfd_max frequency for zynq 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (251 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 252/480] fanotify: sanitize handle_type values when reporting fid Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 254/480] Fix dma_unmap_sg() nents value Greg Kroah-Hartman ` (238 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Nuno Sá, David Lechner, Stephen Boyd, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Nuno Sá <nuno.sa@analog.com> [ Upstream commit ce8a9096699500e2c5bca09dde27b16edda5f636 ] The fpfd_max frequency should be set to 450 MHz instead of 300 MHz. Well, it actually depends on the platform speed grade but we are being conservative for ultrascale so let's be consistent. In a following change we will set these limits at runtime. Fixes: 0e646c52cf0e ("clk: Add axi-clkgen driver") Signed-off-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20250519-dev-axi-clkgen-limits-v6-1-bc4b3b61d1d4@analog.com Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/clk/clk-axi-clkgen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/clk-axi-clkgen.c b/drivers/clk/clk-axi-clkgen.c index 934e53a96ddd..00bf799964c6 100644 --- a/drivers/clk/clk-axi-clkgen.c +++ b/drivers/clk/clk-axi-clkgen.c @@ -118,7 +118,7 @@ static const struct axi_clkgen_limits axi_clkgen_zynqmp_default_limits = { static const struct axi_clkgen_limits axi_clkgen_zynq_default_limits = { .fpfd_min = 10000, - .fpfd_max = 300000, + .fpfd_max = 450000, .fvco_min = 600000, .fvco_max = 1200000, }; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 254/480] Fix dma_unmap_sg() nents value 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (252 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 253/480] clk: clk-axi-clkgen: fix fpfd_max frequency for zynq Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 255/480] perf tools: Fix use-after-free in help_unknown_cmd() Greg Kroah-Hartman ` (237 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Thomas Fourier, Leon Romanovsky, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Fourier <fourier.thomas@gmail.com> [ Upstream commit 1db50f7b7a793670adcf062df9ff27798829d963 ] The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned. Fixes: ed10435d3583 ("RDMA/erdma: Implement hierarchical MTT") Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Link: https://patch.msgid.link/20250630092346.81017-2-fourier.thomas@gmail.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/infiniband/hw/erdma/erdma_verbs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/erdma/erdma_verbs.c b/drivers/infiniband/hw/erdma/erdma_verbs.c index af36a8d2df22..ec0ad4086066 100644 --- a/drivers/infiniband/hw/erdma/erdma_verbs.c +++ b/drivers/infiniband/hw/erdma/erdma_verbs.c @@ -629,7 +629,8 @@ static struct erdma_mtt *erdma_create_cont_mtt(struct erdma_dev *dev, static void erdma_destroy_mtt_buf_sg(struct erdma_dev *dev, struct erdma_mtt *mtt) { - dma_unmap_sg(&dev->pdev->dev, mtt->sglist, mtt->nsg, DMA_TO_DEVICE); + dma_unmap_sg(&dev->pdev->dev, mtt->sglist, + DIV_ROUND_UP(mtt->size, PAGE_SIZE), DMA_TO_DEVICE); vfree(mtt->sglist); } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 255/480] perf tools: Fix use-after-free in help_unknown_cmd() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (253 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 254/480] Fix dma_unmap_sg() nents value Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 256/480] perf dso: Add missed dso__put to dso__load_kcore Greg Kroah-Hartman ` (236 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Ian Rogers, Namhyung Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Namhyung Kim <namhyung@kernel.org> [ Upstream commit 1fdf938168c4d26fa279d4f204768690d1f9c4ae ] Currently perf aborts when it finds an invalid command. I guess it depends on the environment as I have some custom commands in the path. $ perf bad-command perf: 'bad-command' is not a perf-command. See 'perf --help'. Aborted (core dumped) It's because the exclude_cmds() in libsubcmd has a use-after-free when it removes some entries. After copying one to another entry, it keeps the pointer in the both position. And the next copy operation will free the later one but it's the same entry in the previous one. For example, let's say cmds = { A, B, C, D, E } and excludes = { B, E }. ci cj ei cmds-name excludes -----------+-------------------- 0 0 0 | A B : cmp < 0, ci == cj 1 1 0 | B B : cmp == 0 2 1 1 | C E : cmp < 0, ci != cj At this point, it frees cmds->names[1] and cmds->names[1] is assigned to cmds->names[2]. 3 2 1 | D E : cmp < 0, ci != cj Now it frees cmds->names[2] but it's the same as cmds->names[1]. So accessing cmds->names[1] will be invalid. This makes the subcmd tests succeed. $ perf test subcmd 69: libsubcmd help tests : 69.1: Load subcmd names : Ok 69.2: Uniquify subcmd names : Ok 69.3: Exclude duplicate subcmd names : Ok Fixes: 4b96679170c6 ("libsubcmd: Avoid SEGV/use-after-free when commands aren't excluded") Reviewed-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20250701201027.1171561-3-namhyung@kernel.org Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/lib/subcmd/help.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/tools/lib/subcmd/help.c b/tools/lib/subcmd/help.c index 8561b0f01a24..9ef569492560 100644 --- a/tools/lib/subcmd/help.c +++ b/tools/lib/subcmd/help.c @@ -9,6 +9,7 @@ #include <sys/stat.h> #include <unistd.h> #include <dirent.h> +#include <assert.h> #include "subcmd-util.h" #include "help.h" #include "exec-cmd.h" @@ -82,10 +83,11 @@ void exclude_cmds(struct cmdnames *cmds, struct cmdnames *excludes) ci++; cj++; } else { - zfree(&cmds->names[cj]); - cmds->names[cj++] = cmds->names[ci++]; + cmds->names[cj++] = cmds->names[ci]; + cmds->names[ci++] = NULL; } } else if (cmp == 0) { + zfree(&cmds->names[ci]); ci++; ei++; } else if (cmp > 0) { @@ -94,12 +96,12 @@ void exclude_cmds(struct cmdnames *cmds, struct cmdnames *excludes) } if (ci != cj) { while (ci < cmds->cnt) { - zfree(&cmds->names[cj]); - cmds->names[cj++] = cmds->names[ci++]; + cmds->names[cj++] = cmds->names[ci]; + cmds->names[ci++] = NULL; } } for (ci = cj; ci < cmds->cnt; ci++) - zfree(&cmds->names[ci]); + assert(cmds->names[ci] == NULL); cmds->cnt = cj; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 256/480] perf dso: Add missed dso__put to dso__load_kcore 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (254 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 255/480] perf tools: Fix use-after-free in help_unknown_cmd() Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 257/480] mtd: spi-nor: spansion: Fixup params->set_4byte_addr_mode for SEMPER Greg Kroah-Hartman ` (235 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Ian Rogers, Namhyung Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ian Rogers <irogers@google.com> [ Upstream commit 63a088e999de3f431f87d9a367933da894ddb613 ] The kcore loading creates a set of list nodes that have reference counted references to maps of the kcore. The list node freeing in the success path wasn't releasing the maps, add the missing puts. It is unclear why this leak was being missed by leak sanitizer. Fixes: 83720209961f ("perf map: Move map list node into symbol") Signed-off-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20250624190326.2038704-2-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/perf/util/symbol.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c index 11540219481b..9c9e28bbb245 100644 --- a/tools/perf/util/symbol.c +++ b/tools/perf/util/symbol.c @@ -1414,6 +1414,7 @@ static int dso__load_kcore(struct dso *dso, struct map *map, goto out_err; } } + map__zput(new_node->map); free(new_node); } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 257/480] mtd: spi-nor: spansion: Fixup params->set_4byte_addr_mode for SEMPER 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (255 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 256/480] perf dso: Add missed dso__put to dso__load_kcore Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 258/480] perf sched: Make sure it frees the usage string Greg Kroah-Hartman ` (234 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Takahiro Kuwano, Tudor Ambarus, Pratyush Yadav, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> [ Upstream commit a45ab839f52f3f00ac3dae18a50e902efd216de2 ] Infineon SEMPER flash family does not support E9h opcode as Exit 4-byte mode (EX4B). Therefore, params->set_4byte_addr_mode is not determined by BFPT parse. Fixup it up by introducing vendor specific EX4B opcode (B8h) and function. Fixes: c87c9b11c53ce ("mtd: spi-nor: spansion: Determine current address mode") Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org> Acked-by: Pratyush Yadav <pratyush@kernel.org> Signed-off-by: Pratyush Yadav <pratyush@kernel.org> Link: https://lore.kernel.org/r/20250612074427.22263-1-Takahiro.Kuwano@infineon.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/mtd/spi-nor/spansion.c | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c index bf08dbf5e742..b9f156c0f8bc 100644 --- a/drivers/mtd/spi-nor/spansion.c +++ b/drivers/mtd/spi-nor/spansion.c @@ -17,6 +17,7 @@ #define SPINOR_OP_CLSR 0x30 /* Clear status register 1 */ #define SPINOR_OP_CLPEF 0x82 /* Clear program/erase failure flags */ +#define SPINOR_OP_CYPRESS_EX4B 0xB8 /* Exit 4-byte address mode */ #define SPINOR_OP_CYPRESS_DIE_ERASE 0x61 /* Chip (die) erase */ #define SPINOR_OP_RD_ANY_REG 0x65 /* Read any register */ #define SPINOR_OP_WR_ANY_REG 0x71 /* Write any register */ @@ -58,6 +59,13 @@ SPI_MEM_OP_DUMMY(ndummy, 0), \ SPI_MEM_OP_DATA_IN(1, buf, 0)) +#define CYPRESS_NOR_EN4B_EX4B_OP(enable) \ + SPI_MEM_OP(SPI_MEM_OP_CMD(enable ? SPINOR_OP_EN4B : \ + SPINOR_OP_CYPRESS_EX4B, 0), \ + SPI_MEM_OP_NO_ADDR, \ + SPI_MEM_OP_NO_DUMMY, \ + SPI_MEM_OP_NO_DATA) + #define SPANSION_OP(opcode) \ SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 0), \ SPI_MEM_OP_NO_ADDR, \ @@ -356,6 +364,20 @@ static int cypress_nor_quad_enable_volatile(struct spi_nor *nor) return 0; } +static int cypress_nor_set_4byte_addr_mode(struct spi_nor *nor, bool enable) +{ + int ret; + struct spi_mem_op op = CYPRESS_NOR_EN4B_EX4B_OP(enable); + + spi_nor_spimem_setup_op(nor, &op, nor->reg_proto); + + ret = spi_mem_exec_op(nor->spimem, &op); + if (ret) + dev_dbg(nor->dev, "error %d setting 4-byte mode\n", ret); + + return ret; +} + /** * cypress_nor_determine_addr_mode_by_sr1() - Determine current address mode * (3 or 4-byte) by querying status @@ -526,6 +548,9 @@ s25fs256t_post_bfpt_fixup(struct spi_nor *nor, struct spi_mem_op op; int ret; + /* Assign 4-byte address mode method that is not determined in BFPT */ + nor->params->set_4byte_addr_mode = cypress_nor_set_4byte_addr_mode; + ret = cypress_nor_set_addr_mode_nbytes(nor); if (ret) return ret; @@ -591,6 +616,9 @@ s25hx_t_post_bfpt_fixup(struct spi_nor *nor, { int ret; + /* Assign 4-byte address mode method that is not determined in BFPT */ + nor->params->set_4byte_addr_mode = cypress_nor_set_4byte_addr_mode; + ret = cypress_nor_set_addr_mode_nbytes(nor); if (ret) return ret; @@ -718,6 +746,9 @@ static int s28hx_t_post_bfpt_fixup(struct spi_nor *nor, const struct sfdp_parameter_header *bfpt_header, const struct sfdp_bfpt *bfpt) { + /* Assign 4-byte address mode method that is not determined in BFPT */ + nor->params->set_4byte_addr_mode = cypress_nor_set_4byte_addr_mode; + return cypress_nor_set_addr_mode_nbytes(nor); } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 258/480] perf sched: Make sure it frees the usage string 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (256 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 257/480] mtd: spi-nor: spansion: Fixup params->set_4byte_addr_mode for SEMPER Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 259/480] perf sched: Free thread->priv using priv_destructor Greg Kroah-Hartman ` (233 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Ian Rogers, Namhyung Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Namhyung Kim <namhyung@kernel.org> [ Upstream commit 10d9b89203765fb776512742c13af8dd92821842 ] The parse_options_subcommand() allocates the usage string based on the given subcommands. So it should reach the end of the function to free the string to prevent memory leaks. Fixes: 1a5efc9e13f357ab ("libsubcmd: Don't free the usage string") Reviewed-by: Ian Rogers <irogers@google.com> Tested-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20250703014942.1369397-2-namhyung@kernel.org Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/perf/builtin-sched.c | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c index 26ece6e9bfd1..b7bbfad0ed60 100644 --- a/tools/perf/builtin-sched.c +++ b/tools/perf/builtin-sched.c @@ -3902,9 +3902,9 @@ int cmd_sched(int argc, const char **argv) * Aliased to 'perf script' for now: */ if (!strcmp(argv[0], "script")) { - return cmd_script(argc, argv); + ret = cmd_script(argc, argv); } else if (strlen(argv[0]) > 2 && strstarts("record", argv[0])) { - return __cmd_record(argc, argv); + ret = __cmd_record(argc, argv); } else if (strlen(argv[0]) > 2 && strstarts("latency", argv[0])) { sched.tp_handler = &lat_ops; if (argc > 1) { @@ -3913,7 +3913,7 @@ int cmd_sched(int argc, const char **argv) usage_with_options(latency_usage, latency_options); } setup_sorting(&sched, latency_options, latency_usage); - return perf_sched__lat(&sched); + ret = perf_sched__lat(&sched); } else if (!strcmp(argv[0], "map")) { if (argc) { argc = parse_options(argc, argv, map_options, map_usage, 0); @@ -3924,13 +3924,14 @@ int cmd_sched(int argc, const char **argv) sched.map.task_names = strlist__new(sched.map.task_name, NULL); if (sched.map.task_names == NULL) { fprintf(stderr, "Failed to parse task names\n"); - return -1; + ret = -1; + goto out; } } } sched.tp_handler = &map_ops; setup_sorting(&sched, latency_options, latency_usage); - return perf_sched__map(&sched); + ret = perf_sched__map(&sched); } else if (strlen(argv[0]) > 2 && strstarts("replay", argv[0])) { sched.tp_handler = &replay_ops; if (argc) { @@ -3938,7 +3939,7 @@ int cmd_sched(int argc, const char **argv) if (argc) usage_with_options(replay_usage, replay_options); } - return perf_sched__replay(&sched); + ret = perf_sched__replay(&sched); } else if (!strcmp(argv[0], "timehist")) { if (argc) { argc = parse_options(argc, argv, timehist_options, @@ -3954,19 +3955,19 @@ int cmd_sched(int argc, const char **argv) parse_options_usage(NULL, timehist_options, "w", true); if (sched.show_next) parse_options_usage(NULL, timehist_options, "n", true); - return -EINVAL; + ret = -EINVAL; + goto out; } ret = symbol__validate_sym_arguments(); - if (ret) - return ret; - - return perf_sched__timehist(&sched); + if (!ret) + ret = perf_sched__timehist(&sched); } else { usage_with_options(sched_usage, sched_options); } +out: /* free usage string allocated by parse_options_subcommand */ free((void *)sched_usage[0]); - return 0; + return ret; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 259/480] perf sched: Free thread->priv using priv_destructor 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (257 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 258/480] perf sched: Make sure it frees the usage string Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 260/480] perf sched: Fix memory leaks in perf sched map Greg Kroah-Hartman ` (232 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Ian Rogers, Namhyung Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Namhyung Kim <namhyung@kernel.org> [ Upstream commit aa9fdd106bab8c478d37eba5703c0950ad5c0d4f ] In many perf sched subcommand saves priv data structure in the thread but it forgot to free them. As it's an opaque type with 'void *', it needs to register that knows how to free the data. In this case, just regular 'free()' is fine. Fixes: 04cb4fc4d40a5bf1 ("perf thread: Allow tools to register a thread->priv destructor") Reviewed-by: Ian Rogers <irogers@google.com> Tested-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20250703014942.1369397-3-namhyung@kernel.org Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/perf/builtin-sched.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c index b7bbfad0ed60..fa4052e04020 100644 --- a/tools/perf/builtin-sched.c +++ b/tools/perf/builtin-sched.c @@ -3898,6 +3898,8 @@ int cmd_sched(int argc, const char **argv) if (!argc) usage_with_options(sched_usage, sched_options); + thread__set_priv_destructor(free); + /* * Aliased to 'perf script' for now: */ -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 260/480] perf sched: Fix memory leaks in perf sched map 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (258 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 259/480] perf sched: Free thread->priv using priv_destructor Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 261/480] perf sched: Fix thread leaks in perf sched timehist Greg Kroah-Hartman ` (231 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Ian Rogers, Namhyung Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Namhyung Kim <namhyung@kernel.org> [ Upstream commit dc3a80c98884d86389b3b572c50ccc7f502cd41b ] It maintains per-cpu pointers for the current thread but it doesn't release the refcounts. Fixes: 5e895278697c014e ("perf sched: Move curr_thread initialization to perf_sched__map()") Reviewed-by: Ian Rogers <irogers@google.com> Tested-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20250703014942.1369397-4-namhyung@kernel.org Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/perf/builtin-sched.c | 31 ++++++++++++++++++++----------- 1 file changed, 20 insertions(+), 11 deletions(-) diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c index fa4052e04020..b73989fb6ace 100644 --- a/tools/perf/builtin-sched.c +++ b/tools/perf/builtin-sched.c @@ -1634,6 +1634,7 @@ static int map_switch_event(struct perf_sched *sched, struct evsel *evsel, const char *color = PERF_COLOR_NORMAL; char stimestamp[32]; const char *str; + int ret = -1; BUG_ON(this_cpu.cpu >= MAX_CPUS || this_cpu.cpu < 0); @@ -1664,17 +1665,20 @@ static int map_switch_event(struct perf_sched *sched, struct evsel *evsel, sched_in = map__findnew_thread(sched, machine, -1, next_pid); sched_out = map__findnew_thread(sched, machine, -1, prev_pid); if (sched_in == NULL || sched_out == NULL) - return -1; + goto out; tr = thread__get_runtime(sched_in); - if (tr == NULL) { - thread__put(sched_in); - return -1; - } + if (tr == NULL) + goto out; + + thread__put(sched->curr_thread[this_cpu.cpu]); + thread__put(sched->curr_out_thread[this_cpu.cpu]); sched->curr_thread[this_cpu.cpu] = thread__get(sched_in); sched->curr_out_thread[this_cpu.cpu] = thread__get(sched_out); + ret = 0; + str = thread__comm_str(sched_in); new_shortname = 0; if (!tr->shortname[0]) { @@ -1769,12 +1773,10 @@ static int map_switch_event(struct perf_sched *sched, struct evsel *evsel, color_fprintf(stdout, color, "\n"); out: - if (sched->map.task_name) - thread__put(sched_out); - + thread__put(sched_out); thread__put(sched_in); - return 0; + return ret; } static int process_sched_switch_event(const struct perf_tool *tool, @@ -3556,10 +3558,10 @@ static int perf_sched__map(struct perf_sched *sched) sched->curr_out_thread = calloc(MAX_CPUS, sizeof(*(sched->curr_out_thread))); if (!sched->curr_out_thread) - return rc; + goto out_free_curr_thread; if (setup_cpus_switch_event(sched)) - goto out_free_curr_thread; + goto out_free_curr_out_thread; if (setup_map_cpus(sched)) goto out_free_cpus_switch_event; @@ -3590,7 +3592,14 @@ static int perf_sched__map(struct perf_sched *sched) out_free_cpus_switch_event: free_cpus_switch_event(sched); +out_free_curr_out_thread: + for (int i = 0; i < MAX_CPUS; i++) + thread__put(sched->curr_out_thread[i]); + zfree(&sched->curr_out_thread); + out_free_curr_thread: + for (int i = 0; i < MAX_CPUS; i++) + thread__put(sched->curr_thread[i]); zfree(&sched->curr_thread); return rc; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 261/480] perf sched: Fix thread leaks in perf sched timehist 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (259 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 260/480] perf sched: Fix memory leaks in perf sched map Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 262/480] perf sched: Fix memory leaks for evsel->priv in timehist Greg Kroah-Hartman ` (230 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Ian Rogers, Namhyung Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Namhyung Kim <namhyung@kernel.org> [ Upstream commit e2eb59260c4f6bac403491d0112891766b8650d1 ] Add missing thread__put() after machine__findnew_thread() or timehist_get_thread(). Also idle threads' last_thread should be refcounted properly. Fixes: 699b5b920db04a6f ("perf sched timehist: Save callchain when entering idle") Reviewed-by: Ian Rogers <irogers@google.com> Tested-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20250703014942.1369397-5-namhyung@kernel.org Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/perf/builtin-sched.c | 48 +++++++++++++++++++++++++++++--------- 1 file changed, 37 insertions(+), 11 deletions(-) diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c index b73989fb6ace..83b5a85a91b7 100644 --- a/tools/perf/builtin-sched.c +++ b/tools/perf/builtin-sched.c @@ -2313,8 +2313,10 @@ static void save_task_callchain(struct perf_sched *sched, return; } - if (!sched->show_callchain || sample->callchain == NULL) + if (!sched->show_callchain || sample->callchain == NULL) { + thread__put(thread); return; + } cursor = get_tls_callchain_cursor(); @@ -2323,10 +2325,12 @@ static void save_task_callchain(struct perf_sched *sched, if (verbose > 0) pr_err("Failed to resolve callchain. Skipping\n"); + thread__put(thread); return; } callchain_cursor_commit(cursor); + thread__put(thread); while (true) { struct callchain_cursor_node *node; @@ -2403,8 +2407,17 @@ static void free_idle_threads(void) return; for (i = 0; i < idle_max_cpu; ++i) { - if ((idle_threads[i])) - thread__delete(idle_threads[i]); + struct thread *idle = idle_threads[i]; + + if (idle) { + struct idle_thread_runtime *itr; + + itr = thread__priv(idle); + if (itr) + thread__put(itr->last_thread); + + thread__delete(idle); + } } free(idle_threads); @@ -2441,7 +2454,7 @@ static struct thread *get_idle_thread(int cpu) } } - return idle_threads[cpu]; + return thread__get(idle_threads[cpu]); } static void save_idle_callchain(struct perf_sched *sched, @@ -2496,7 +2509,8 @@ static struct thread *timehist_get_thread(struct perf_sched *sched, if (itr == NULL) return NULL; - itr->last_thread = thread; + thread__put(itr->last_thread); + itr->last_thread = thread__get(thread); /* copy task callchain when entering to idle */ if (evsel__intval(evsel, sample, "next_pid") == 0) @@ -2567,6 +2581,7 @@ static void timehist_print_wakeup_event(struct perf_sched *sched, /* show wakeup unless both awakee and awaker are filtered */ if (timehist_skip_sample(sched, thread, evsel, sample) && timehist_skip_sample(sched, awakened, evsel, sample)) { + thread__put(thread); return; } @@ -2583,6 +2598,8 @@ static void timehist_print_wakeup_event(struct perf_sched *sched, printf("awakened: %s", timehist_get_commstr(awakened)); printf("\n"); + + thread__put(thread); } static int timehist_sched_wakeup_ignore(const struct perf_tool *tool __maybe_unused, @@ -2611,8 +2628,10 @@ static int timehist_sched_wakeup_event(const struct perf_tool *tool, return -1; tr = thread__get_runtime(thread); - if (tr == NULL) + if (tr == NULL) { + thread__put(thread); return -1; + } if (tr->ready_to_run == 0) tr->ready_to_run = sample->time; @@ -2622,6 +2641,7 @@ static int timehist_sched_wakeup_event(const struct perf_tool *tool, !perf_time__skip_sample(&sched->ptime, sample->time)) timehist_print_wakeup_event(sched, evsel, sample, machine, thread); + thread__put(thread); return 0; } @@ -2649,6 +2669,7 @@ static void timehist_print_migration_event(struct perf_sched *sched, if (timehist_skip_sample(sched, thread, evsel, sample) && timehist_skip_sample(sched, migrated, evsel, sample)) { + thread__put(thread); return; } @@ -2676,6 +2697,7 @@ static void timehist_print_migration_event(struct perf_sched *sched, printf(" cpu %d => %d", ocpu, dcpu); printf("\n"); + thread__put(thread); } static int timehist_migrate_task_event(const struct perf_tool *tool, @@ -2695,8 +2717,10 @@ static int timehist_migrate_task_event(const struct perf_tool *tool, return -1; tr = thread__get_runtime(thread); - if (tr == NULL) + if (tr == NULL) { + thread__put(thread); return -1; + } tr->migrations++; tr->migrated = sample->time; @@ -2706,6 +2730,7 @@ static int timehist_migrate_task_event(const struct perf_tool *tool, timehist_print_migration_event(sched, evsel, sample, machine, thread); } + thread__put(thread); return 0; } @@ -2728,10 +2753,10 @@ static void timehist_update_task_prio(struct evsel *evsel, return; tr = thread__get_runtime(thread); - if (tr == NULL) - return; + if (tr != NULL) + tr->prio = next_prio; - tr->prio = next_prio; + thread__put(thread); } static int timehist_sched_change_event(const struct perf_tool *tool, @@ -2743,7 +2768,7 @@ static int timehist_sched_change_event(const struct perf_tool *tool, struct perf_sched *sched = container_of(tool, struct perf_sched, tool); struct perf_time_interval *ptime = &sched->ptime; struct addr_location al; - struct thread *thread; + struct thread *thread = NULL; struct thread_runtime *tr = NULL; u64 tprev, t = sample->time; int rc = 0; @@ -2867,6 +2892,7 @@ static int timehist_sched_change_event(const struct perf_tool *tool, evsel__save_time(evsel, sample->time, sample->cpu); + thread__put(thread); addr_location__exit(&al); return rc; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 262/480] perf sched: Fix memory leaks for evsel->priv in timehist 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (260 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 261/480] perf sched: Fix thread leaks in perf sched timehist Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 263/480] perf sched: Use RC_CHK_EQUAL() to compare pointers Greg Kroah-Hartman ` (229 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Ian Rogers, Namhyung Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Namhyung Kim <namhyung@kernel.org> [ Upstream commit 117e5c33b1c44037af016d77ce6c0b086d55535f ] It uses evsel->priv to save per-cpu timing information. It should be freed when the evsel is released. Add the priv destructor for evsel same as thread to handle that. Fixes: 49394a2a24c78ce0 ("perf sched timehist: Introduce timehist command") Reviewed-by: Ian Rogers <irogers@google.com> Tested-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20250703014942.1369397-6-namhyung@kernel.org Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/perf/builtin-sched.c | 12 ++++++++++++ tools/perf/util/evsel.c | 11 +++++++++++ tools/perf/util/evsel.h | 2 ++ 3 files changed, 25 insertions(+) diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c index 83b5a85a91b7..a6eb0462dd5b 100644 --- a/tools/perf/builtin-sched.c +++ b/tools/perf/builtin-sched.c @@ -2020,6 +2020,16 @@ static u64 evsel__get_time(struct evsel *evsel, u32 cpu) return r->last_time[cpu]; } +static void timehist__evsel_priv_destructor(void *priv) +{ + struct evsel_runtime *r = priv; + + if (r) { + free(r->last_time); + free(r); + } +} + static int comm_width = 30; static char *timehist_get_commstr(struct thread *thread) @@ -3314,6 +3324,8 @@ static int perf_sched__timehist(struct perf_sched *sched) setup_pager(); + evsel__set_priv_destructor(timehist__evsel_priv_destructor); + /* prefer sched_waking if it is captured */ if (evlist__find_tracepoint_by_name(session->evlist, "sched:sched_waking")) handlers[1].handler = timehist_sched_wakeup_ignore; diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c index 3c030da2e477..08fd9b9afcf8 100644 --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -1652,6 +1652,15 @@ static void evsel__free_config_terms(struct evsel *evsel) free_config_terms(&evsel->config_terms); } +static void (*evsel__priv_destructor)(void *priv); + +void evsel__set_priv_destructor(void (*destructor)(void *priv)) +{ + assert(evsel__priv_destructor == NULL); + + evsel__priv_destructor = destructor; +} + void evsel__exit(struct evsel *evsel) { assert(list_empty(&evsel->core.node)); @@ -1680,6 +1689,8 @@ void evsel__exit(struct evsel *evsel) hashmap__free(evsel->per_pkg_mask); evsel->per_pkg_mask = NULL; zfree(&evsel->metric_events); + if (evsel__priv_destructor) + evsel__priv_destructor(evsel->priv); perf_evsel__object.fini(evsel); if (evsel__tool_event(evsel) == TOOL_PMU__EVENT_SYSTEM_TIME || evsel__tool_event(evsel) == TOOL_PMU__EVENT_USER_TIME) diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h index aae431d63d64..b7f8b29f30ea 100644 --- a/tools/perf/util/evsel.h +++ b/tools/perf/util/evsel.h @@ -270,6 +270,8 @@ void evsel__init(struct evsel *evsel, struct perf_event_attr *attr, int idx); void evsel__exit(struct evsel *evsel); void evsel__delete(struct evsel *evsel); +void evsel__set_priv_destructor(void (*destructor)(void *priv)); + struct callchain_param; void evsel__config(struct evsel *evsel, struct record_opts *opts, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 263/480] perf sched: Use RC_CHK_EQUAL() to compare pointers 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (261 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 262/480] perf sched: Fix memory leaks for evsel->priv in timehist Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 264/480] perf sched: Fix memory leaks in perf sched latency Greg Kroah-Hartman ` (228 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Ian Rogers, Namhyung Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Namhyung Kim <namhyung@kernel.org> [ Upstream commit 7a4002ec9e0fced907179da94f67c3082d7b4162 ] So that it can check two pointers to the same object properly when REFCNT_CHECKING is on. Fixes: 78c32f4cb12f9430 ("libperf rc_check: Add RC_CHK_EQUAL") Reviewed-by: Ian Rogers <irogers@google.com> Tested-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20250703014942.1369397-7-namhyung@kernel.org Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/perf/builtin-sched.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c index a6eb0462dd5b..087d4eaba5f7 100644 --- a/tools/perf/builtin-sched.c +++ b/tools/perf/builtin-sched.c @@ -994,7 +994,7 @@ thread_atoms_search(struct rb_root_cached *root, struct thread *thread, else if (cmp < 0) node = node->rb_right; else { - BUG_ON(thread != atoms->thread); + BUG_ON(!RC_CHK_EQUAL(thread, atoms->thread)); return atoms; } } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 264/480] perf sched: Fix memory leaks in perf sched latency 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (262 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 263/480] perf sched: Use RC_CHK_EQUAL() to compare pointers Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 265/480] RDMA/hns: Fix double destruction of rsv_qp Greg Kroah-Hartman ` (227 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Ian Rogers, Namhyung Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Namhyung Kim <namhyung@kernel.org> [ Upstream commit e68b1c0098b959cb88afce5c93dd6a9324e6da78 ] The work_atoms should be freed after use. Add free_work_atoms() to make sure to release all. It should use list_splice_init() when merging atoms to prevent accessing invalid pointers. Fixes: b1ffe8f3e0c96f552 ("perf sched: Finish latency => atom rename and misc cleanups") Reviewed-by: Ian Rogers <irogers@google.com> Tested-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20250703014942.1369397-8-namhyung@kernel.org Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/perf/builtin-sched.c | 27 ++++++++++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-) diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c index 087d4eaba5f7..4bbebd6ef2e4 100644 --- a/tools/perf/builtin-sched.c +++ b/tools/perf/builtin-sched.c @@ -1111,6 +1111,21 @@ add_sched_in_event(struct work_atoms *atoms, u64 timestamp) atoms->nb_atoms++; } +static void free_work_atoms(struct work_atoms *atoms) +{ + struct work_atom *atom, *tmp; + + if (atoms == NULL) + return; + + list_for_each_entry_safe(atom, tmp, &atoms->work_list, list) { + list_del(&atom->list); + free(atom); + } + thread__zput(atoms->thread); + free(atoms); +} + static int latency_switch_event(struct perf_sched *sched, struct evsel *evsel, struct perf_sample *sample, @@ -3426,13 +3441,13 @@ static void __merge_work_atoms(struct rb_root_cached *root, struct work_atoms *d this->total_runtime += data->total_runtime; this->nb_atoms += data->nb_atoms; this->total_lat += data->total_lat; - list_splice(&data->work_list, &this->work_list); + list_splice_init(&data->work_list, &this->work_list); if (this->max_lat < data->max_lat) { this->max_lat = data->max_lat; this->max_lat_start = data->max_lat_start; this->max_lat_end = data->max_lat_end; } - zfree(&data); + free_work_atoms(data); return; } } @@ -3511,7 +3526,6 @@ static int perf_sched__lat(struct perf_sched *sched) work_list = rb_entry(next, struct work_atoms, node); output_lat_thread(sched, work_list); next = rb_next(next); - thread__zput(work_list->thread); } printf(" -----------------------------------------------------------------------------------------------------------------\n"); @@ -3525,6 +3539,13 @@ static int perf_sched__lat(struct perf_sched *sched) rc = 0; + while ((next = rb_first_cached(&sched->sorted_atom_root))) { + struct work_atoms *data; + + data = rb_entry(next, struct work_atoms, node); + rb_erase_cached(next, &sched->sorted_atom_root); + free_work_atoms(data); + } out_free_cpus_switch_event: free_cpus_switch_event(sched); return rc; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 265/480] RDMA/hns: Fix double destruction of rsv_qp 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (263 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 264/480] perf sched: Fix memory leaks in perf sched latency Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 266/480] RDMA/hns: Fix HW configurations not cleared in error flow Greg Kroah-Hartman ` (226 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, wenglianfa, Junxian Huang, Leon Romanovsky, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: wenglianfa <wenglianfa@huawei.com> [ Upstream commit c6957b95ecc5b63c5a4bb4ecc28af326cf8f6dc8 ] rsv_qp may be double destroyed in error flow, first in free_mr_init(), and then in hns_roce_exit(). Fix it by moving the free_mr_init() call into hns_roce_v2_init(). list_del corruption, ffff589732eb9b50->next is LIST_POISON1 (dead000000000100) WARNING: CPU: 8 PID: 1047115 at lib/list_debug.c:53 __list_del_entry_valid+0x148/0x240 ... Call trace: __list_del_entry_valid+0x148/0x240 hns_roce_qp_remove+0x4c/0x3f0 [hns_roce_hw_v2] hns_roce_v2_destroy_qp_common+0x1dc/0x5f4 [hns_roce_hw_v2] hns_roce_v2_destroy_qp+0x22c/0x46c [hns_roce_hw_v2] free_mr_exit+0x6c/0x120 [hns_roce_hw_v2] hns_roce_v2_exit+0x170/0x200 [hns_roce_hw_v2] hns_roce_exit+0x118/0x350 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x1c8/0x304 [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify_init+0x170/0x21c [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify+0x6c/0x190 [hns_roce_hw_v2] hclge_notify_roce_client+0x6c/0x160 [hclge] hclge_reset_rebuild+0x150/0x5c0 [hclge] hclge_reset+0x10c/0x140 [hclge] hclge_reset_subtask+0x80/0x104 [hclge] hclge_reset_service_task+0x168/0x3ac [hclge] hclge_service_task+0x50/0x100 [hclge] process_one_work+0x250/0x9a0 worker_thread+0x324/0x990 kthread+0x190/0x210 ret_from_fork+0x10/0x18 Fixes: fd8489294dd2 ("RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08") Signed-off-by: wenglianfa <wenglianfa@huawei.com> Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com> Link: https://patch.msgid.link/20250703113905.3597124-2-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 25 +++++++++++----------- drivers/infiniband/hw/hns/hns_roce_main.c | 6 +++--- 2 files changed, 16 insertions(+), 15 deletions(-) diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c index bbf6e1983704..126990bf74b4 100644 --- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c @@ -2971,14 +2971,22 @@ static int hns_roce_v2_init(struct hns_roce_dev *hr_dev) { int ret; + if (hr_dev->pci_dev->revision == PCI_REVISION_ID_HIP08) { + ret = free_mr_init(hr_dev); + if (ret) { + dev_err(hr_dev->dev, "failed to init free mr!\n"); + return ret; + } + } + /* The hns ROCEE requires the extdb info to be cleared before using */ ret = hns_roce_clear_extdb_list_info(hr_dev); if (ret) - return ret; + goto err_clear_extdb_failed; ret = get_hem_table(hr_dev); if (ret) - return ret; + goto err_clear_extdb_failed; if (hr_dev->is_vf) return 0; @@ -2993,6 +3001,9 @@ static int hns_roce_v2_init(struct hns_roce_dev *hr_dev) err_llm_init_failed: put_hem_table(hr_dev); +err_clear_extdb_failed: + if (hr_dev->pci_dev->revision == PCI_REVISION_ID_HIP08) + free_mr_exit(hr_dev); return ret; } @@ -7027,21 +7038,11 @@ static int __hns_roce_hw_v2_init_instance(struct hnae3_handle *handle) goto error_failed_roce_init; } - if (hr_dev->pci_dev->revision == PCI_REVISION_ID_HIP08) { - ret = free_mr_init(hr_dev); - if (ret) { - dev_err(hr_dev->dev, "failed to init free mr!\n"); - goto error_failed_free_mr_init; - } - } handle->priv = hr_dev; return 0; -error_failed_free_mr_init: - hns_roce_exit(hr_dev); - error_failed_roce_init: kfree(hr_dev->priv); diff --git a/drivers/infiniband/hw/hns/hns_roce_main.c b/drivers/infiniband/hw/hns/hns_roce_main.c index e7a497cc125c..623610b3e2ec 100644 --- a/drivers/infiniband/hw/hns/hns_roce_main.c +++ b/drivers/infiniband/hw/hns/hns_roce_main.c @@ -965,6 +965,9 @@ static int hns_roce_setup_hca(struct hns_roce_dev *hr_dev) spin_lock_init(&hr_dev->sm_lock); + INIT_LIST_HEAD(&hr_dev->qp_list); + spin_lock_init(&hr_dev->qp_list_lock); + if (hr_dev->caps.flags & HNS_ROCE_CAP_FLAG_CQ_RECORD_DB || hr_dev->caps.flags & HNS_ROCE_CAP_FLAG_QP_RECORD_DB) { INIT_LIST_HEAD(&hr_dev->pgdir_list); @@ -1132,9 +1135,6 @@ int hns_roce_init(struct hns_roce_dev *hr_dev) } } - INIT_LIST_HEAD(&hr_dev->qp_list); - spin_lock_init(&hr_dev->qp_list_lock); - ret = hns_roce_register_device(hr_dev); if (ret) goto error_failed_register_device; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 266/480] RDMA/hns: Fix HW configurations not cleared in error flow 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (264 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 265/480] RDMA/hns: Fix double destruction of rsv_qp Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 267/480] crypto: ccp - Fix locking on alloc failure handling Greg Kroah-Hartman ` (225 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, wenglianfa, Junxian Huang, Leon Romanovsky, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: wenglianfa <wenglianfa@huawei.com> [ Upstream commit 998b41cb20b02c4e28ac558e4e7f8609d659ec05 ] hns_roce_clear_extdb_list_info() will eventually do some HW configurations through FW, and they need to be cleared by calling hns_roce_function_clear() when the initialization fails. Fixes: 7e78dd816e45 ("RDMA/hns: Clear extended doorbell info before using") Signed-off-by: wenglianfa <wenglianfa@huawei.com> Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com> Link: https://patch.msgid.link/20250703113905.3597124-3-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c index 126990bf74b4..217c252fc722 100644 --- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c @@ -2986,7 +2986,7 @@ static int hns_roce_v2_init(struct hns_roce_dev *hr_dev) ret = get_hem_table(hr_dev); if (ret) - goto err_clear_extdb_failed; + goto err_get_hem_table_failed; if (hr_dev->is_vf) return 0; @@ -3001,6 +3001,8 @@ static int hns_roce_v2_init(struct hns_roce_dev *hr_dev) err_llm_init_failed: put_hem_table(hr_dev); +err_get_hem_table_failed: + hns_roce_function_clear(hr_dev); err_clear_extdb_failed: if (hr_dev->pci_dev->revision == PCI_REVISION_ID_HIP08) free_mr_exit(hr_dev); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 267/480] crypto: ccp - Fix locking on alloc failure handling 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (265 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 266/480] RDMA/hns: Fix HW configurations not cleared in error flow Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 268/480] crypto: inside-secure - Fix `dma_unmap_sg()` nents value Greg Kroah-Hartman ` (224 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Alexey Kardashevskiy, Tom Lendacky, Pratik R. Sampat, Herbert Xu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Alexey Kardashevskiy <aik@amd.com> [ Upstream commit b4abeccb8d39db7d9b51cb0098d6458760b30a75 ] The __snp_alloc_firmware_pages() helper allocates pages in the firmware state (alloc + rmpupdate). In case of failed rmpupdate, it tries reclaiming pages with already changed state. This requires calling the PSP firmware and since there is sev_cmd_mutex to guard such calls, the helper takes a "locked" parameter so specify if the lock needs to be held. Most calls happen from snp_alloc_firmware_page() which executes without the lock. However commit 24512afa4336 ("crypto: ccp: Handle the legacy TMR allocation when SNP is enabled") switched sev_fw_alloc() from alloc_pages() (which does not call the PSP) to __snp_alloc_firmware_pages() (which does) but did not account for the fact that sev_fw_alloc() is called from __sev_platform_init_locked() (via __sev_platform_init_handle_tmr()) and executes with the lock held. Add a "locked" parameter to __snp_alloc_firmware_pages(). Make sev_fw_alloc() use the new parameter to prevent potential deadlock in rmp_mark_pages_firmware() if rmpupdate() failed. Fixes: 24512afa4336 ("crypto: ccp: Handle the legacy TMR allocation when SNP is enabled") Signed-off-by: Alexey Kardashevskiy <aik@amd.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Pratik R. Sampat <prsampat@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/crypto/ccp/sev-dev.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c index 2e87ca0e292a..4d790837af22 100644 --- a/drivers/crypto/ccp/sev-dev.c +++ b/drivers/crypto/ccp/sev-dev.c @@ -424,7 +424,7 @@ static int rmp_mark_pages_firmware(unsigned long paddr, unsigned int npages, boo return rc; } -static struct page *__snp_alloc_firmware_pages(gfp_t gfp_mask, int order) +static struct page *__snp_alloc_firmware_pages(gfp_t gfp_mask, int order, bool locked) { unsigned long npages = 1ul << order, paddr; struct sev_device *sev; @@ -443,7 +443,7 @@ static struct page *__snp_alloc_firmware_pages(gfp_t gfp_mask, int order) return page; paddr = __pa((unsigned long)page_address(page)); - if (rmp_mark_pages_firmware(paddr, npages, false)) + if (rmp_mark_pages_firmware(paddr, npages, locked)) return NULL; return page; @@ -453,7 +453,7 @@ void *snp_alloc_firmware_page(gfp_t gfp_mask) { struct page *page; - page = __snp_alloc_firmware_pages(gfp_mask, 0); + page = __snp_alloc_firmware_pages(gfp_mask, 0, false); return page ? page_address(page) : NULL; } @@ -488,7 +488,7 @@ static void *sev_fw_alloc(unsigned long len) { struct page *page; - page = __snp_alloc_firmware_pages(GFP_KERNEL, get_order(len)); + page = __snp_alloc_firmware_pages(GFP_KERNEL, get_order(len), true); if (!page) return NULL; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 268/480] crypto: inside-secure - Fix `dma_unmap_sg()` nents value 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (266 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 267/480] crypto: ccp - Fix locking on alloc failure handling Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 269/480] crypto: ccp - Fix crash when rebind ccp device for ccp.ko Greg Kroah-Hartman ` (223 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Thomas Fourier, Antoine Tenart, Herbert Xu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Fourier <fourier.thomas@gmail.com> [ Upstream commit cb7fa6b6fc71e0c801e271aa498e2f19e6df2931 ] The `dma_unmap_sg()` functions should be called with the same nents as the `dma_map_sg()`, not the value the map function returned. Fixes: c957f8b3e2e5 ("crypto: inside-secure - avoid unmapping DMA memory that was not mapped") Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Reviewed-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/crypto/inside-secure/safexcel_hash.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/inside-secure/safexcel_hash.c b/drivers/crypto/inside-secure/safexcel_hash.c index f44c08f5f5ec..af4b978189e5 100644 --- a/drivers/crypto/inside-secure/safexcel_hash.c +++ b/drivers/crypto/inside-secure/safexcel_hash.c @@ -249,7 +249,9 @@ static int safexcel_handle_req_result(struct safexcel_crypto_priv *priv, safexcel_complete(priv, ring); if (sreq->nents) { - dma_unmap_sg(priv->dev, areq->src, sreq->nents, DMA_TO_DEVICE); + dma_unmap_sg(priv->dev, areq->src, + sg_nents_for_len(areq->src, areq->nbytes), + DMA_TO_DEVICE); sreq->nents = 0; } @@ -497,7 +499,9 @@ static int safexcel_ahash_send_req(struct crypto_async_request *async, int ring, DMA_FROM_DEVICE); unmap_sg: if (req->nents) { - dma_unmap_sg(priv->dev, areq->src, req->nents, DMA_TO_DEVICE); + dma_unmap_sg(priv->dev, areq->src, + sg_nents_for_len(areq->src, areq->nbytes), + DMA_TO_DEVICE); req->nents = 0; } cdesc_rollback: -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 269/480] crypto: ccp - Fix crash when rebind ccp device for ccp.ko 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (267 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 268/480] crypto: inside-secure - Fix `dma_unmap_sg()` nents value Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 270/480] RDMA/hns: Get message length of ack_req from FW Greg Kroah-Hartman ` (222 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Mengbiao Xiong, Tom Lendacky, Herbert Xu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Mengbiao Xiong <xisme1998@gmail.com> [ Upstream commit 181698af38d3f93381229ad89c09b5bd0496661a ] When CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebinding the ccp device causes the following crash: $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind [ 204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098 [ 204.978026] #PF: supervisor write access in kernel mode [ 204.979126] #PF: error_code(0x0002) - not-present page [ 204.980226] PGD 0 P4D 0 [ 204.981317] Oops: Oops: 0002 [#1] SMP NOPTI ... [ 204.997852] Call Trace: [ 204.999074] <TASK> [ 205.000297] start_creating+0x9f/0x1c0 [ 205.001533] debugfs_create_dir+0x1f/0x170 [ 205.002769] ? srso_return_thunk+0x5/0x5f [ 205.004000] ccp5_debugfs_setup+0x87/0x170 [ccp] [ 205.005241] ccp5_init+0x8b2/0x960 [ccp] [ 205.006469] ccp_dev_init+0xd4/0x150 [ccp] [ 205.007709] sp_init+0x5f/0x80 [ccp] [ 205.008942] sp_pci_probe+0x283/0x2e0 [ccp] [ 205.010165] ? srso_return_thunk+0x5/0x5f [ 205.011376] local_pci_probe+0x4f/0xb0 [ 205.012584] pci_device_probe+0xdb/0x230 [ 205.013810] really_probe+0xed/0x380 [ 205.015024] __driver_probe_device+0x7e/0x160 [ 205.016240] device_driver_attach+0x2f/0x60 [ 205.017457] bind_store+0x7c/0xb0 [ 205.018663] drv_attr_store+0x28/0x40 [ 205.019868] sysfs_kf_write+0x5f/0x70 [ 205.021065] kernfs_fop_write_iter+0x145/0x1d0 [ 205.022267] vfs_write+0x308/0x440 [ 205.023453] ksys_write+0x6d/0xe0 [ 205.024616] __x64_sys_write+0x1e/0x30 [ 205.025778] x64_sys_call+0x16ba/0x2150 [ 205.026942] do_syscall_64+0x56/0x1e0 [ 205.028108] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 205.029276] RIP: 0033:0x7fbc36f10104 [ 205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5 This patch sets ccp_debugfs_dir to NULL after destroying it in ccp5_debugfs_destroy, allowing the directory dentry to be recreated when rebinding the ccp device. Tested on AMD Ryzen 7 1700X. Fixes: 3cdbe346ed3f ("crypto: ccp - Add debugfs entries for CCP information") Signed-off-by: Mengbiao Xiong <xisme1998@gmail.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/crypto/ccp/ccp-debugfs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/crypto/ccp/ccp-debugfs.c b/drivers/crypto/ccp/ccp-debugfs.c index a1055554b47a..dc26bc22c91d 100644 --- a/drivers/crypto/ccp/ccp-debugfs.c +++ b/drivers/crypto/ccp/ccp-debugfs.c @@ -319,5 +319,8 @@ void ccp5_debugfs_setup(struct ccp_device *ccp) void ccp5_debugfs_destroy(void) { + mutex_lock(&ccp_debugfs_lock); debugfs_remove_recursive(ccp_debugfs_dir); + ccp_debugfs_dir = NULL; + mutex_unlock(&ccp_debugfs_lock); } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 270/480] RDMA/hns: Get message length of ack_req from FW 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (268 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 269/480] crypto: ccp - Fix crash when rebind ccp device for ccp.ko Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:47 ` [PATCH 6.15 271/480] RDMA/hns: Fix accessing uninitialized resources Greg Kroah-Hartman ` (221 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Junxian Huang, Leon Romanovsky, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Junxian Huang <huangjunxian6@hisilicon.com> [ Upstream commit 2c2ec0106c0f1f12d4eefd11de318ac47557a750 ] ACK_REQ_FREQ indicates the number of packets (after MTU fragmentation) HW sends before setting an ACK request. When MTU is greater than or equal to 1024, the current ACK_REQ_FREQ value causes HW to request an ACK for every MTU fragment. The processing of a large number of ACKs severely impacts HW performance when sending large size payloads. Get message length of ack_req from FW so that we can adjust this parameter according to different situations. There are several constraints for ACK_REQ_FREQ: 1. mtu * (2 ^ ACK_REQ_FREQ) should not be too large, otherwise it may cause some unexpected retries when sending large payload. 2. ACK_REQ_FREQ should be larger than or equal to LP_PKTN_INI. 3. ACK_REQ_FREQ must be equal to LP_PKTN_INI when using LDCP or HC3 congestion control algorithm. Fixes: 56518a603fd2 ("RDMA/hns: Modify the value of long message loopback slice") Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com> Link: https://patch.msgid.link/20250703113905.3597124-4-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/infiniband/hw/hns/hns_roce_device.h | 1 + drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 45 ++++++++++++++++----- drivers/infiniband/hw/hns/hns_roce_hw_v2.h | 8 +++- 3 files changed, 43 insertions(+), 11 deletions(-) diff --git a/drivers/infiniband/hw/hns/hns_roce_device.h b/drivers/infiniband/hw/hns/hns_roce_device.h index 560a1d9de408..cbe73d9ad525 100644 --- a/drivers/infiniband/hw/hns/hns_roce_device.h +++ b/drivers/infiniband/hw/hns/hns_roce_device.h @@ -856,6 +856,7 @@ struct hns_roce_caps { u16 default_ceq_arm_st; u8 cong_cap; enum hns_roce_cong_type default_cong_type; + u32 max_ack_req_msg_len; }; enum hns_roce_device_state { diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c index 217c252fc722..1c55ed69b560 100644 --- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c @@ -2181,31 +2181,36 @@ static void apply_func_caps(struct hns_roce_dev *hr_dev) static int hns_roce_query_caps(struct hns_roce_dev *hr_dev) { - struct hns_roce_cmq_desc desc[HNS_ROCE_QUERY_PF_CAPS_CMD_NUM]; + struct hns_roce_cmq_desc desc[HNS_ROCE_QUERY_PF_CAPS_CMD_NUM] = {}; struct hns_roce_caps *caps = &hr_dev->caps; struct hns_roce_query_pf_caps_a *resp_a; struct hns_roce_query_pf_caps_b *resp_b; struct hns_roce_query_pf_caps_c *resp_c; struct hns_roce_query_pf_caps_d *resp_d; struct hns_roce_query_pf_caps_e *resp_e; + struct hns_roce_query_pf_caps_f *resp_f; enum hns_roce_opcode_type cmd; int ctx_hop_num; int pbl_hop_num; + int cmd_num; int ret; int i; cmd = hr_dev->is_vf ? HNS_ROCE_OPC_QUERY_VF_CAPS_NUM : HNS_ROCE_OPC_QUERY_PF_CAPS_NUM; + cmd_num = hr_dev->pci_dev->revision == PCI_REVISION_ID_HIP08 ? + HNS_ROCE_QUERY_PF_CAPS_CMD_NUM_HIP08 : + HNS_ROCE_QUERY_PF_CAPS_CMD_NUM; - for (i = 0; i < HNS_ROCE_QUERY_PF_CAPS_CMD_NUM; i++) { + for (i = 0; i < cmd_num - 1; i++) { hns_roce_cmq_setup_basic_desc(&desc[i], cmd, true); - if (i < (HNS_ROCE_QUERY_PF_CAPS_CMD_NUM - 1)) - desc[i].flag |= cpu_to_le16(HNS_ROCE_CMD_FLAG_NEXT); - else - desc[i].flag &= ~cpu_to_le16(HNS_ROCE_CMD_FLAG_NEXT); + desc[i].flag |= cpu_to_le16(HNS_ROCE_CMD_FLAG_NEXT); } - ret = hns_roce_cmq_send(hr_dev, desc, HNS_ROCE_QUERY_PF_CAPS_CMD_NUM); + hns_roce_cmq_setup_basic_desc(&desc[cmd_num - 1], cmd, true); + desc[cmd_num - 1].flag &= ~cpu_to_le16(HNS_ROCE_CMD_FLAG_NEXT); + + ret = hns_roce_cmq_send(hr_dev, desc, cmd_num); if (ret) return ret; @@ -2214,6 +2219,7 @@ static int hns_roce_query_caps(struct hns_roce_dev *hr_dev) resp_c = (struct hns_roce_query_pf_caps_c *)desc[2].data; resp_d = (struct hns_roce_query_pf_caps_d *)desc[3].data; resp_e = (struct hns_roce_query_pf_caps_e *)desc[4].data; + resp_f = (struct hns_roce_query_pf_caps_f *)desc[5].data; caps->local_ca_ack_delay = resp_a->local_ca_ack_delay; caps->max_sq_sg = le16_to_cpu(resp_a->max_sq_sg); @@ -2278,6 +2284,8 @@ static int hns_roce_query_caps(struct hns_roce_dev *hr_dev) caps->reserved_srqs = hr_reg_read(resp_e, PF_CAPS_E_RSV_SRQS); caps->reserved_lkey = hr_reg_read(resp_e, PF_CAPS_E_RSV_LKEYS); + caps->max_ack_req_msg_len = le32_to_cpu(resp_f->max_ack_req_msg_len); + caps->qpc_hop_num = ctx_hop_num; caps->sccc_hop_num = ctx_hop_num; caps->srqc_hop_num = ctx_hop_num; @@ -4559,7 +4567,9 @@ static int modify_qp_init_to_rtr(struct ib_qp *ibqp, dma_addr_t trrl_ba; dma_addr_t irrl_ba; enum ib_mtu ib_mtu; + u8 ack_req_freq; const u8 *smac; + int lp_msg_len; u8 lp_pktn_ini; u64 *mtts; u8 *dmac; @@ -4642,7 +4652,8 @@ static int modify_qp_init_to_rtr(struct ib_qp *ibqp, return -EINVAL; #define MIN_LP_MSG_LEN 1024 /* mtu * (2 ^ lp_pktn_ini) should be in the range of 1024 to mtu */ - lp_pktn_ini = ilog2(max(mtu, MIN_LP_MSG_LEN) / mtu); + lp_msg_len = max(mtu, MIN_LP_MSG_LEN); + lp_pktn_ini = ilog2(lp_msg_len / mtu); if (attr_mask & IB_QP_PATH_MTU) { hr_reg_write(context, QPC_MTU, ib_mtu); @@ -4652,8 +4663,22 @@ static int modify_qp_init_to_rtr(struct ib_qp *ibqp, hr_reg_write(context, QPC_LP_PKTN_INI, lp_pktn_ini); hr_reg_clear(qpc_mask, QPC_LP_PKTN_INI); - /* ACK_REQ_FREQ should be larger than or equal to LP_PKTN_INI */ - hr_reg_write(context, QPC_ACK_REQ_FREQ, lp_pktn_ini); + /* + * There are several constraints for ACK_REQ_FREQ: + * 1. mtu * (2 ^ ACK_REQ_FREQ) should not be too large, otherwise + * it may cause some unexpected retries when sending large + * payload. + * 2. ACK_REQ_FREQ should be larger than or equal to LP_PKTN_INI. + * 3. ACK_REQ_FREQ must be equal to LP_PKTN_INI when using LDCP + * or HC3 congestion control algorithm. + */ + if (hr_qp->cong_type == CONG_TYPE_LDCP || + hr_qp->cong_type == CONG_TYPE_HC3 || + hr_dev->caps.max_ack_req_msg_len < lp_msg_len) + ack_req_freq = lp_pktn_ini; + else + ack_req_freq = ilog2(hr_dev->caps.max_ack_req_msg_len / mtu); + hr_reg_write(context, QPC_ACK_REQ_FREQ, ack_req_freq); hr_reg_clear(qpc_mask, QPC_ACK_REQ_FREQ); hr_reg_clear(qpc_mask, QPC_RX_REQ_PSN_ERR); diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.h b/drivers/infiniband/hw/hns/hns_roce_hw_v2.h index bc7466830eaf..1c2660305d27 100644 --- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.h +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.h @@ -1168,7 +1168,8 @@ struct hns_roce_cfg_gmv_tb_b { #define GMV_TB_B_SMAC_H GMV_TB_B_FIELD_LOC(47, 32) #define GMV_TB_B_SGID_IDX GMV_TB_B_FIELD_LOC(71, 64) -#define HNS_ROCE_QUERY_PF_CAPS_CMD_NUM 5 +#define HNS_ROCE_QUERY_PF_CAPS_CMD_NUM_HIP08 5 +#define HNS_ROCE_QUERY_PF_CAPS_CMD_NUM 6 struct hns_roce_query_pf_caps_a { u8 number_ports; u8 local_ca_ack_delay; @@ -1280,6 +1281,11 @@ struct hns_roce_query_pf_caps_e { __le16 aeq_period; }; +struct hns_roce_query_pf_caps_f { + __le32 max_ack_req_msg_len; + __le32 rsv[5]; +}; + #define PF_CAPS_E_FIELD_LOC(h, l) \ FIELD_LOC(struct hns_roce_query_pf_caps_e, h, l) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 271/480] RDMA/hns: Fix accessing uninitialized resources 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (269 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 270/480] RDMA/hns: Get message length of ack_req from FW Greg Kroah-Hartman @ 2025-08-12 17:47 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 272/480] RDMA/hns: Drop GFP_NOWARN Greg Kroah-Hartman ` (220 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:47 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Junxian Huang, Leon Romanovsky, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Junxian Huang <huangjunxian6@hisilicon.com> [ Upstream commit 278c18a4a78a9a6bf529ef45ccde512a5686ea9d ] hr_dev->pgdir_list and hr_dev->pgdir_mutex won't be initialized if CQ/QP record db are not enabled, but they are also needed when using SRQ with SRQ record db enabled. Simplified the logic by always initailizing the reosurces. Fixes: c9813b0b9992 ("RDMA/hns: Support SRQ record doorbell") Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com> Link: https://patch.msgid.link/20250703113905.3597124-5-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/infiniband/hw/hns/hns_roce_main.c | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/drivers/infiniband/hw/hns/hns_roce_main.c b/drivers/infiniband/hw/hns/hns_roce_main.c index 623610b3e2ec..11fa64044a8d 100644 --- a/drivers/infiniband/hw/hns/hns_roce_main.c +++ b/drivers/infiniband/hw/hns/hns_roce_main.c @@ -947,10 +947,7 @@ static int hns_roce_init_hem(struct hns_roce_dev *hr_dev) static void hns_roce_teardown_hca(struct hns_roce_dev *hr_dev) { hns_roce_cleanup_bitmap(hr_dev); - - if (hr_dev->caps.flags & HNS_ROCE_CAP_FLAG_CQ_RECORD_DB || - hr_dev->caps.flags & HNS_ROCE_CAP_FLAG_QP_RECORD_DB) - mutex_destroy(&hr_dev->pgdir_mutex); + mutex_destroy(&hr_dev->pgdir_mutex); } /** @@ -968,11 +965,8 @@ static int hns_roce_setup_hca(struct hns_roce_dev *hr_dev) INIT_LIST_HEAD(&hr_dev->qp_list); spin_lock_init(&hr_dev->qp_list_lock); - if (hr_dev->caps.flags & HNS_ROCE_CAP_FLAG_CQ_RECORD_DB || - hr_dev->caps.flags & HNS_ROCE_CAP_FLAG_QP_RECORD_DB) { - INIT_LIST_HEAD(&hr_dev->pgdir_list); - mutex_init(&hr_dev->pgdir_mutex); - } + INIT_LIST_HEAD(&hr_dev->pgdir_list); + mutex_init(&hr_dev->pgdir_mutex); hns_roce_init_uar_table(hr_dev); @@ -1004,9 +998,7 @@ static int hns_roce_setup_hca(struct hns_roce_dev *hr_dev) err_uar_table_free: ida_destroy(&hr_dev->uar_ida.ida); - if (hr_dev->caps.flags & HNS_ROCE_CAP_FLAG_CQ_RECORD_DB || - hr_dev->caps.flags & HNS_ROCE_CAP_FLAG_QP_RECORD_DB) - mutex_destroy(&hr_dev->pgdir_mutex); + mutex_destroy(&hr_dev->pgdir_mutex); return ret; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 272/480] RDMA/hns: Drop GFP_NOWARN 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (270 preceding siblings ...) 2025-08-12 17:47 ` [PATCH 6.15 271/480] RDMA/hns: Fix accessing uninitialized resources Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 273/480] RDMA/hns: Fix -Wframe-larger-than issue Greg Kroah-Hartman ` (219 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Junxian Huang, Leon Romanovsky, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Junxian Huang <huangjunxian6@hisilicon.com> [ Upstream commit 5338abb299f0cd764edf78a7e71a0b746af35030 ] GFP_NOWARN silences all warnings on dma_alloc_coherent() failure, which might otherwise help with troubleshooting. Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver") Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com> Link: https://patch.msgid.link/20250703113905.3597124-6-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/infiniband/hw/hns/hns_roce_hem.c | 18 +++++------------- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/drivers/infiniband/hw/hns/hns_roce_hem.c b/drivers/infiniband/hw/hns/hns_roce_hem.c index ca0798224e56..3d479c63b117 100644 --- a/drivers/infiniband/hw/hns/hns_roce_hem.c +++ b/drivers/infiniband/hw/hns/hns_roce_hem.c @@ -249,15 +249,12 @@ int hns_roce_calc_hem_mhop(struct hns_roce_dev *hr_dev, } static struct hns_roce_hem *hns_roce_alloc_hem(struct hns_roce_dev *hr_dev, - unsigned long hem_alloc_size, - gfp_t gfp_mask) + unsigned long hem_alloc_size) { struct hns_roce_hem *hem; int order; void *buf; - WARN_ON(gfp_mask & __GFP_HIGHMEM); - order = get_order(hem_alloc_size); if (PAGE_SIZE << order != hem_alloc_size) { dev_err(hr_dev->dev, "invalid hem_alloc_size: %lu!\n", @@ -265,13 +262,12 @@ static struct hns_roce_hem *hns_roce_alloc_hem(struct hns_roce_dev *hr_dev, return NULL; } - hem = kmalloc(sizeof(*hem), - gfp_mask & ~(__GFP_HIGHMEM | __GFP_NOWARN)); + hem = kmalloc(sizeof(*hem), GFP_KERNEL); if (!hem) return NULL; buf = dma_alloc_coherent(hr_dev->dev, hem_alloc_size, - &hem->dma, gfp_mask); + &hem->dma, GFP_KERNEL); if (!buf) goto fail; @@ -378,7 +374,6 @@ static int alloc_mhop_hem(struct hns_roce_dev *hr_dev, { u32 bt_size = mhop->bt_chunk_size; struct device *dev = hr_dev->dev; - gfp_t flag; u64 bt_ba; u32 size; int ret; @@ -417,8 +412,7 @@ static int alloc_mhop_hem(struct hns_roce_dev *hr_dev, * alloc bt space chunk for MTT/CQE. */ size = table->type < HEM_TYPE_MTT ? mhop->buf_chunk_size : bt_size; - flag = GFP_KERNEL | __GFP_NOWARN; - table->hem[index->buf] = hns_roce_alloc_hem(hr_dev, size, flag); + table->hem[index->buf] = hns_roce_alloc_hem(hr_dev, size); if (!table->hem[index->buf]) { ret = -ENOMEM; goto err_alloc_hem; @@ -546,9 +540,7 @@ int hns_roce_table_get(struct hns_roce_dev *hr_dev, goto out; } - table->hem[i] = hns_roce_alloc_hem(hr_dev, - table->table_chunk_size, - GFP_KERNEL | __GFP_NOWARN); + table->hem[i] = hns_roce_alloc_hem(hr_dev, table->table_chunk_size); if (!table->hem[i]) { ret = -ENOMEM; goto out; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 273/480] RDMA/hns: Fix -Wframe-larger-than issue 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (271 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 272/480] RDMA/hns: Drop GFP_NOWARN Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 274/480] tracing: Use queue_rcu_work() to free filters Greg Kroah-Hartman ` (218 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, kernel test robot, Junxian Huang, Leon Romanovsky, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Junxian Huang <huangjunxian6@hisilicon.com> [ Upstream commit 79d56805c5068f2bc81518043e043c3dedd1c82a ] Fix -Wframe-larger-than issue by allocating memory for qpc struct with kzalloc() instead of using stack memory. Fixes: 606bf89e98ef ("RDMA/hns: Refactor for hns_roce_v2_modify_qp function") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202506240032.CSgIyFct-lkp@intel.com/ Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com> Link: https://patch.msgid.link/20250703113905.3597124-7-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c index 1c55ed69b560..07d93cf4557e 100644 --- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c @@ -5371,11 +5371,10 @@ static int hns_roce_v2_modify_qp(struct ib_qp *ibqp, { struct hns_roce_dev *hr_dev = to_hr_dev(ibqp->device); struct hns_roce_qp *hr_qp = to_hr_qp(ibqp); - struct hns_roce_v2_qp_context ctx[2]; - struct hns_roce_v2_qp_context *context = ctx; - struct hns_roce_v2_qp_context *qpc_mask = ctx + 1; + struct hns_roce_v2_qp_context *context; + struct hns_roce_v2_qp_context *qpc_mask; struct ib_device *ibdev = &hr_dev->ib_dev; - int ret; + int ret = -ENOMEM; if (attr_mask & ~IB_QP_ATTR_STANDARD_BITS) return -EOPNOTSUPP; @@ -5386,7 +5385,11 @@ static int hns_roce_v2_modify_qp(struct ib_qp *ibqp, * we should set all bits of the relevant fields in context mask to * 0 at the same time, else set them to 0x1. */ - memset(context, 0, hr_dev->caps.qpc_sz); + context = kvzalloc(sizeof(*context), GFP_KERNEL); + qpc_mask = kvzalloc(sizeof(*qpc_mask), GFP_KERNEL); + if (!context || !qpc_mask) + goto out; + memset(qpc_mask, 0xff, hr_dev->caps.qpc_sz); ret = hns_roce_v2_set_abs_fields(ibqp, attr, attr_mask, cur_state, @@ -5428,6 +5431,8 @@ static int hns_roce_v2_modify_qp(struct ib_qp *ibqp, clear_qp(hr_qp); out: + kvfree(qpc_mask); + kvfree(context); return ret; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 274/480] tracing: Use queue_rcu_work() to free filters 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (272 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 273/480] RDMA/hns: Fix -Wframe-larger-than issue Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 275/480] kernel: trace: preemptirq_delay_test: use offstack cpu mask Greg Kroah-Hartman ` (217 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Masami Hiramatsu, Mathieu Desnoyers, Paul E. McKenney, Steven Rostedt (Google), Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Steven Rostedt <rostedt@goodmis.org> [ Upstream commit 3aceaa539cfe3a2e62bd92e6697d9fae1c20c0be ] Freeing of filters requires to wait for both an RCU grace period as well as a RCU task trace wait period after they have been detached from their lists. The trace task period can be quite large so the freeing of the filters was moved to use the call_rcu*() routines. The problem with that is that the callback functions of call_rcu*() is done from a soft irq and can cause latencies if the callback takes a bit of time. The filters are freed per event in a system and the syscalls system contains an event per system call, which can be over 700 events. Freeing 700 filters in a bottom half is undesirable. Instead, move the freeing to use queue_rcu_work() which is done in task context. Link: https://lore.kernel.org/all/9a2f0cd0-1561-4206-8966-f93ccd25927f@paulmck-laptop/ Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Link: https://lore.kernel.org/20250609131732.04fd303b@gandalf.local.home Fixes: a9d0aab5eb33 ("tracing: Fix regression of filter waiting a long time on RCU synchronization") Suggested-by: "Paul E. McKenney" <paulmck@kernel.org> Reviewed-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- kernel/trace/trace_events_filter.c | 28 ++++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-) diff --git a/kernel/trace/trace_events_filter.c b/kernel/trace/trace_events_filter.c index cca676f651b1..8fc5323a2ed3 100644 --- a/kernel/trace/trace_events_filter.c +++ b/kernel/trace/trace_events_filter.c @@ -1342,13 +1342,14 @@ struct filter_list { struct filter_head { struct list_head list; - struct rcu_head rcu; + union { + struct rcu_head rcu; + struct rcu_work rwork; + }; }; - -static void free_filter_list(struct rcu_head *rhp) +static void free_filter_list(struct filter_head *filter_list) { - struct filter_head *filter_list = container_of(rhp, struct filter_head, rcu); struct filter_list *filter_item, *tmp; list_for_each_entry_safe(filter_item, tmp, &filter_list->list, list) { @@ -1359,9 +1360,20 @@ static void free_filter_list(struct rcu_head *rhp) kfree(filter_list); } +static void free_filter_list_work(struct work_struct *work) +{ + struct filter_head *filter_list; + + filter_list = container_of(to_rcu_work(work), struct filter_head, rwork); + free_filter_list(filter_list); +} + static void free_filter_list_tasks(struct rcu_head *rhp) { - call_rcu(rhp, free_filter_list); + struct filter_head *filter_list = container_of(rhp, struct filter_head, rcu); + + INIT_RCU_WORK(&filter_list->rwork, free_filter_list_work); + queue_rcu_work(system_wq, &filter_list->rwork); } /* @@ -1458,7 +1470,7 @@ static void filter_free_subsystem_filters(struct trace_subsystem_dir *dir, tracepoint_synchronize_unregister(); if (head) - free_filter_list(&head->rcu); + free_filter_list(head); list_for_each_entry(file, &tr->events, list) { if (file->system != dir || !file->filter) @@ -2303,7 +2315,7 @@ static int process_system_preds(struct trace_subsystem_dir *dir, return 0; fail: /* No call succeeded */ - free_filter_list(&filter_list->rcu); + free_filter_list(filter_list); parse_error(pe, FILT_ERR_BAD_SUBSYS_FILTER, 0); return -EINVAL; fail_mem: @@ -2313,7 +2325,7 @@ static int process_system_preds(struct trace_subsystem_dir *dir, if (!fail) delay_free_filter(filter_list); else - free_filter_list(&filter_list->rcu); + free_filter_list(filter_list); return -ENOMEM; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 275/480] kernel: trace: preemptirq_delay_test: use offstack cpu mask 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (273 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 274/480] tracing: Use queue_rcu_work() to free filters Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 276/480] proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al Greg Kroah-Hartman ` (216 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Masami Hiramatsu, Song Chen, Mathieu Desnoyers, Arnd Bergmann, Steven Rostedt (Google), Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Arnd Bergmann <arnd@arndb.de> [ Upstream commit adc353c0bfb243ebfd29b6222fa3bf149169a6de ] A CPU mask on the stack is broken for large values of CONFIG_NR_CPUS: kernel/trace/preemptirq_delay_test.c: In function ‘preemptirq_delay_run’: kernel/trace/preemptirq_delay_test.c:143:1: error: the frame size of 8512 bytes is larger than 1536 bytes [-Werror=frame-larger-than=] Fall back to dynamic allocation here. Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Song Chen <chensong_2000@189.cn> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Link: https://lore.kernel.org/20250620111215.3365305-1-arnd@kernel.org Fixes: 4b9091e1c194 ("kernel: trace: preemptirq_delay_test: add cpu affinity") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- kernel/trace/preemptirq_delay_test.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/kernel/trace/preemptirq_delay_test.c b/kernel/trace/preemptirq_delay_test.c index 314ffc143039..acb0c971a408 100644 --- a/kernel/trace/preemptirq_delay_test.c +++ b/kernel/trace/preemptirq_delay_test.c @@ -117,12 +117,15 @@ static int preemptirq_delay_run(void *data) { int i; int s = MIN(burst_size, NR_TEST_FUNCS); - struct cpumask cpu_mask; + cpumask_var_t cpu_mask; + + if (!alloc_cpumask_var(&cpu_mask, GFP_KERNEL)) + return -ENOMEM; if (cpu_affinity > -1) { - cpumask_clear(&cpu_mask); - cpumask_set_cpu(cpu_affinity, &cpu_mask); - if (set_cpus_allowed_ptr(current, &cpu_mask)) + cpumask_clear(cpu_mask); + cpumask_set_cpu(cpu_affinity, cpu_mask); + if (set_cpus_allowed_ptr(current, cpu_mask)) pr_err("cpu_affinity:%d, failed\n", cpu_affinity); } @@ -139,6 +142,8 @@ static int preemptirq_delay_run(void *data) __set_current_state(TASK_RUNNING); + free_cpumask_var(cpu_mask); + return 0; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 276/480] proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (274 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 275/480] kernel: trace: preemptirq_delay_test: use offstack cpu mask Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 277/480] pinmux: fix race causing mux_owner NULL with active mux_usecount Greg Kroah-Hartman ` (215 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, wangzijie, Alexey Dobriyan, Alexei Starovoitov, Al Viro, Edgecombe, Rick P, Kirill A. Shuemov, Andrew Morton, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: wangzijie <wangzijie1@honor.com> [ Upstream commit ff7ec8dc1b646296f8d94c39339e8d3833d16c05 ] Check pde->proc_ops->proc_lseek directly may cause UAF in rmmod scenario. It's a gap in proc_reg_open() after commit 654b33ada4ab("proc: fix UAF in proc_get_inode()"). Followed by AI Viro's suggestion, fix it in same manner. Link: https://lkml.kernel.org/r/20250607021353.1127963-1-wangzijie1@honor.com Fixes: 3f61631d47f1 ("take care to handle NULL ->proc_lseek()") Signed-off-by: wangzijie <wangzijie1@honor.com> Reviewed-by: Alexey Dobriyan <adobriyan@gmail.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com> Cc: Kirill A. Shuemov <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/proc/generic.c | 2 ++ fs/proc/inode.c | 2 +- fs/proc/internal.h | 5 +++++ include/linux/proc_fs.h | 1 + 4 files changed, 9 insertions(+), 1 deletion(-) diff --git a/fs/proc/generic.c b/fs/proc/generic.c index a3e22803cddf..e0e50914ab25 100644 --- a/fs/proc/generic.c +++ b/fs/proc/generic.c @@ -569,6 +569,8 @@ static void pde_set_flags(struct proc_dir_entry *pde) if (pde->proc_ops->proc_compat_ioctl) pde->flags |= PROC_ENTRY_proc_compat_ioctl; #endif + if (pde->proc_ops->proc_lseek) + pde->flags |= PROC_ENTRY_proc_lseek; } struct proc_dir_entry *proc_create_data(const char *name, umode_t mode, diff --git a/fs/proc/inode.c b/fs/proc/inode.c index 3604b616311c..129490151be1 100644 --- a/fs/proc/inode.c +++ b/fs/proc/inode.c @@ -473,7 +473,7 @@ static int proc_reg_open(struct inode *inode, struct file *file) typeof_member(struct proc_ops, proc_open) open; struct pde_opener *pdeo; - if (!pde->proc_ops->proc_lseek) + if (!pde_has_proc_lseek(pde)) file->f_mode &= ~FMODE_LSEEK; if (pde_is_permanent(pde)) { diff --git a/fs/proc/internal.h b/fs/proc/internal.h index 96122e91c645..3d48ffe72583 100644 --- a/fs/proc/internal.h +++ b/fs/proc/internal.h @@ -99,6 +99,11 @@ static inline bool pde_has_proc_compat_ioctl(const struct proc_dir_entry *pde) #endif } +static inline bool pde_has_proc_lseek(const struct proc_dir_entry *pde) +{ + return pde->flags & PROC_ENTRY_proc_lseek; +} + extern struct kmem_cache *proc_dir_entry_cache; void pde_free(struct proc_dir_entry *pde); diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h index ea62201c74c4..703d0c76cc9a 100644 --- a/include/linux/proc_fs.h +++ b/include/linux/proc_fs.h @@ -27,6 +27,7 @@ enum { PROC_ENTRY_proc_read_iter = 1U << 1, PROC_ENTRY_proc_compat_ioctl = 1U << 2, + PROC_ENTRY_proc_lseek = 1U << 3, }; struct proc_ops { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 277/480] pinmux: fix race causing mux_owner NULL with active mux_usecount 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (275 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 276/480] proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 278/480] perf tests bp_account: Fix leaked file descriptor Greg Kroah-Hartman ` (214 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Mukesh Ojha, Linus Walleij, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> [ Upstream commit 0b075c011032f88d1cfde3b45d6dcf08b44140eb ] commit 5a3e85c3c397 ("pinmux: Use sequential access to access desc->pinmux data") tried to address the issue when two client of the same gpio calls pinctrl_select_state() for the same functionality, was resulting in NULL pointer issue while accessing desc->mux_owner. However, issue was not completely fixed due to the way it was handled and it can still result in the same NULL pointer. The issue occurs due to the following interleaving: cpu0 (process A) cpu1 (process B) pin_request() { pin_free() { mutex_lock() desc->mux_usecount--; //becomes 0 .. mutex_unlock() mutex_lock(desc->mux) desc->mux_usecount++; // becomes 1 desc->mux_owner = owner; mutex_unlock(desc->mux) mutex_lock(desc->mux) desc->mux_owner = NULL; mutex_unlock(desc->mux) This sequence leads to a state where the pin appears to be in use (`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can cause NULL pointer on next pin_request on the same pin. Ensure that updates to mux_usecount and mux_owner are performed atomically under the same lock. Only clear mux_owner when mux_usecount reaches zero and no new owner has been assigned. Fixes: 5a3e85c3c397 ("pinmux: Use sequential access to access desc->pinmux data") Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/20250708-pinmux-race-fix-v2-1-8ae9e8a0d1a1@oss.qualcomm.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/pinctrl/pinmux.c | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c index 0743190da59e..2c31e7f2a27a 100644 --- a/drivers/pinctrl/pinmux.c +++ b/drivers/pinctrl/pinmux.c @@ -236,18 +236,7 @@ static const char *pin_free(struct pinctrl_dev *pctldev, int pin, if (desc->mux_usecount) return NULL; } - } - - /* - * If there is no kind of request function for the pin we just assume - * we got it by default and proceed. - */ - if (gpio_range && ops->gpio_disable_free) - ops->gpio_disable_free(pctldev, gpio_range, pin); - else if (ops->free) - ops->free(pctldev, pin); - scoped_guard(mutex, &desc->mux_lock) { if (gpio_range) { owner = desc->gpio_owner; desc->gpio_owner = NULL; @@ -258,6 +247,15 @@ static const char *pin_free(struct pinctrl_dev *pctldev, int pin, } } + /* + * If there is no kind of request function for the pin we just assume + * we got it by default and proceed. + */ + if (gpio_range && ops->gpio_disable_free) + ops->gpio_disable_free(pctldev, gpio_range, pin); + else if (ops->free) + ops->free(pctldev, pin); + module_put(pctldev->owner); return owner; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 278/480] perf tests bp_account: Fix leaked file descriptor 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (276 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 277/480] pinmux: fix race causing mux_owner NULL with active mux_usecount Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 279/480] perf hwmon_pmu: Avoid shortening hwmon PMU name Greg Kroah-Hartman ` (213 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Aishwarya TCV, Leo Yan, Ian Rogers, Namhyung Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Leo Yan <leo.yan@arm.com> [ Upstream commit 4a6cdecaa1497f1fbbd1d5307a225b6ca5a62a90 ] Since the commit e9846f5ead26 ("perf test: In forked mode add check that fds aren't leaked"), the test "Breakpoint accounting" reports the error: # perf test -vvv "Breakpoint accounting" 20: Breakpoint accounting: --- start --- test child forked, pid 373 failed opening event 0 failed opening event 0 watchpoints count 4, breakpoints count 6, has_ioctl 1, share 0 wp 0 created wp 1 created wp 2 created wp 3 created wp 0 modified to bp wp max created ---- end(0) ---- Leak of file descriptor 7 that opened: 'anon_inode:[perf_event]' A watchpoint's file descriptor was not properly released. This patch fixes the leak. Fixes: 032db28e5fa3 ("perf tests: Add breakpoint accounting/modify test") Reported-by: Aishwarya TCV <aishwarya.tcv@arm.com> Signed-off-by: Leo Yan <leo.yan@arm.com> Reviewed-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20250711-perf_fix_breakpoint_accounting-v1-1-b314393023f9@arm.com Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/perf/tests/bp_account.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/tests/bp_account.c b/tools/perf/tests/bp_account.c index 4cb7d486b5c1..047433c977bc 100644 --- a/tools/perf/tests/bp_account.c +++ b/tools/perf/tests/bp_account.c @@ -104,6 +104,7 @@ static int bp_accounting(int wp_cnt, int share) fd_wp = wp_event((void *)&the_var, &attr_new); TEST_ASSERT_VAL("failed to create max wp\n", fd_wp != -1); pr_debug("wp max created\n"); + close(fd_wp); } for (i = 0; i < wp_cnt; i++) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 279/480] perf hwmon_pmu: Avoid shortening hwmon PMU name 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (277 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 278/480] perf tests bp_account: Fix leaked file descriptor Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 280/480] RDMA/mana_ib: Fix DSCP value in modify QP Greg Kroah-Hartman ` (212 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Ian Rogers, Namhyung Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ian Rogers <irogers@google.com> [ Upstream commit 28f5aa8184c9c9b8eab35fa3884c416fe75e88e4 ] Long names like ucsi_source_psy_USBC000:001 when prefixed with hwmon_ exceed the buffer size and the last digit is lost. This causes confusion with similar names like ucsi_source_psy_USBC000:002. Extend the buffer size to avoid this. Fixes: 53cc0b351ec9 ("perf hwmon_pmu: Add a tool PMU exposing events from hwmon in sysfs") Signed-off-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20250710235126.1086011-2-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/perf/util/hwmon_pmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/hwmon_pmu.c b/tools/perf/util/hwmon_pmu.c index 3cce77fc8004..cf7156c7e3bc 100644 --- a/tools/perf/util/hwmon_pmu.c +++ b/tools/perf/util/hwmon_pmu.c @@ -344,7 +344,7 @@ static int hwmon_pmu__read_events(struct hwmon_pmu *pmu) struct perf_pmu *hwmon_pmu__new(struct list_head *pmus, int hwmon_dir, const char *sysfs_name, const char *name) { - char buf[32]; + char buf[64]; struct hwmon_pmu *hwm; hwm = zalloc(sizeof(*hwm)); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 280/480] RDMA/mana_ib: Fix DSCP value in modify QP 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (278 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 279/480] perf hwmon_pmu: Avoid shortening hwmon PMU name Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 281/480] clk: thead: th1520-ap: Correctly refer the parent of osc_12m Greg Kroah-Hartman ` (211 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Shiraz Saleem, Konstantin Taranov, Long Li, Leon Romanovsky, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Shiraz Saleem <shirazsaleem@microsoft.com> [ Upstream commit 62de0e67328e9503459a24b9343c3358937cdeef ] Convert the traffic_class in GRH to a DSCP value as required by the HW. Fixes: e095405b45bb ("RDMA/mana_ib: Modify QP state") Signed-off-by: Shiraz Saleem <shirazsaleem@microsoft.com> Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com> Link: https://patch.msgid.link/1752143085-4169-1-git-send-email-kotaranov@linux.microsoft.com Reviewed-by: Long Li <longli@microsoft.com> Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/infiniband/hw/mana/qp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/mana/qp.c b/drivers/infiniband/hw/mana/qp.c index c928af58f38b..456d78c6fcb8 100644 --- a/drivers/infiniband/hw/mana/qp.c +++ b/drivers/infiniband/hw/mana/qp.c @@ -773,7 +773,7 @@ static int mana_ib_gd_modify_qp(struct ib_qp *ibqp, struct ib_qp_attr *attr, req.ah_attr.dest_port = ROCE_V2_UDP_DPORT; req.ah_attr.src_port = rdma_get_udp_sport(attr->ah_attr.grh.flow_label, ibqp->qp_num, attr->dest_qp_num); - req.ah_attr.traffic_class = attr->ah_attr.grh.traffic_class; + req.ah_attr.traffic_class = attr->ah_attr.grh.traffic_class >> 2; req.ah_attr.hop_limit = attr->ah_attr.grh.hop_limit; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 281/480] clk: thead: th1520-ap: Correctly refer the parent of osc_12m 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (279 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 280/480] RDMA/mana_ib: Fix DSCP value in modify QP Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 282/480] clk: sunxi-ng: v3s: Fix de clock definition Greg Kroah-Hartman ` (210 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Yao Zi, Drew Fustini, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Yao Zi <ziyao@disroot.org> [ Upstream commit d274c77ffa202b70ad01d579f33b73b4de123375 ] The "osc_12m" fixed factor clock refers the external oscillator by setting clk_parent_data.fw_name to osc_24m, which is obviously wrong since no clock-names property is allowed for compatible thead,th1520-clk-ap. Refer the oscillator as parent by index instead. Fixes: ae81b69fd2b1 ("clk: thead: Add support for T-Head TH1520 AP_SUBSYS clocks") Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Drew Fustini <fustini@kernel.org> Signed-off-by: Drew Fustini <fustini@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/clk/thead/clk-th1520-ap.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/clk/thead/clk-th1520-ap.c b/drivers/clk/thead/clk-th1520-ap.c index 4c9555fc6184..6ab89245af12 100644 --- a/drivers/clk/thead/clk-th1520-ap.c +++ b/drivers/clk/thead/clk-th1520-ap.c @@ -582,7 +582,14 @@ static const struct clk_parent_data peri2sys_apb_pclk_pd[] = { { .hw = &peri2sys_apb_pclk.common.hw } }; -static CLK_FIXED_FACTOR_FW_NAME(osc12m_clk, "osc_12m", "osc_24m", 2, 1, 0); +static struct clk_fixed_factor osc12m_clk = { + .div = 2, + .mult = 1, + .hw.init = CLK_HW_INIT_PARENTS_DATA("osc_12m", + osc_24m_clk, + &clk_fixed_factor_ops, + 0), +}; static const char * const out_parents[] = { "osc_24m", "osc_12m" }; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 282/480] clk: sunxi-ng: v3s: Fix de clock definition 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (280 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 281/480] clk: thead: th1520-ap: Correctly refer the parent of osc_12m Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 283/480] scsi: ibmvscsi_tgt: Fix dma_unmap_sg() nents value Greg Kroah-Hartman ` (209 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Paul Kocialkowski, Chen-Yu Tsai, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Paul Kocialkowski <paulk@sys-base.io> [ Upstream commit e8ab346f9907a1a3aa2f0e5decf849925c06ae2e ] The de clock is marked with CLK_SET_RATE_PARENT, which is really not necessary (as confirmed from experimentation) and significantly restricts flexibility for other clocks using the same parent. In addition the source selection (parent) field is marked as using 2 bits, when it the documentation reports that it uses 3. Fix both issues in the de clock definition. Fixes: d0f11d14b0bc ("clk: sunxi-ng: add support for V3s CCU") Signed-off-by: Paul Kocialkowski <paulk@sys-base.io> Link: https://patch.msgid.link/20250704154008.3463257-1-paulk@sys-base.io Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/clk/sunxi-ng/ccu-sun8i-v3s.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-v3s.c b/drivers/clk/sunxi-ng/ccu-sun8i-v3s.c index 579a81bb46df..7744fc632ea6 100644 --- a/drivers/clk/sunxi-ng/ccu-sun8i-v3s.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-v3s.c @@ -347,8 +347,7 @@ static SUNXI_CCU_GATE(dram_ohci_clk, "dram-ohci", "dram", static const char * const de_parents[] = { "pll-video", "pll-periph0" }; static SUNXI_CCU_M_WITH_MUX_GATE(de_clk, "de", de_parents, - 0x104, 0, 4, 24, 2, BIT(31), - CLK_SET_RATE_PARENT); + 0x104, 0, 4, 24, 3, BIT(31), 0); static const char * const tcon_parents[] = { "pll-video" }; static SUNXI_CCU_M_WITH_MUX_GATE(tcon_clk, "tcon", tcon_parents, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 283/480] scsi: ibmvscsi_tgt: Fix dma_unmap_sg() nents value 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (281 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 282/480] clk: sunxi-ng: v3s: Fix de clock definition Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 284/480] scsi: elx: efct: " Greg Kroah-Hartman ` (208 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Thomas Fourier, Martin K. Petersen, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Fourier <fourier.thomas@gmail.com> [ Upstream commit 023a293b9cd0bb86a9b50cd7688a3d9d266826db ] The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned. Fixes: 88a678bbc34c ("ibmvscsis: Initial commit of IBM VSCSI Tgt Driver") Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Link: https://lore.kernel.org/r/20250630111803.94389-2-fourier.thomas@gmail.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/scsi/ibmvscsi_tgt/libsrp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/ibmvscsi_tgt/libsrp.c b/drivers/scsi/ibmvscsi_tgt/libsrp.c index 8a0e28aec928..0ecad398ed3d 100644 --- a/drivers/scsi/ibmvscsi_tgt/libsrp.c +++ b/drivers/scsi/ibmvscsi_tgt/libsrp.c @@ -184,7 +184,8 @@ static int srp_direct_data(struct ibmvscsis_cmd *cmd, struct srp_direct_buf *md, err = rdma_io(cmd, sg, nsg, md, 1, dir, len); if (dma_map) - dma_unmap_sg(iue->target->dev, sg, nsg, DMA_BIDIRECTIONAL); + dma_unmap_sg(iue->target->dev, sg, cmd->se_cmd.t_data_nents, + DMA_BIDIRECTIONAL); return err; } @@ -256,7 +257,8 @@ static int srp_indirect_data(struct ibmvscsis_cmd *cmd, struct srp_cmd *srp_cmd, err = rdma_io(cmd, sg, nsg, md, nmd, dir, len); if (dma_map) - dma_unmap_sg(iue->target->dev, sg, nsg, DMA_BIDIRECTIONAL); + dma_unmap_sg(iue->target->dev, sg, cmd->se_cmd.t_data_nents, + DMA_BIDIRECTIONAL); free_mem: if (token && dma_map) { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 284/480] scsi: elx: efct: Fix dma_unmap_sg() nents value 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (282 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 283/480] scsi: ibmvscsi_tgt: Fix dma_unmap_sg() nents value Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 285/480] scsi: mvsas: " Greg Kroah-Hartman ` (207 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Thomas Fourier, Martin K. Petersen, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Fourier <fourier.thomas@gmail.com> [ Upstream commit 3a988d0b65d7d1713ce7596eae288a293f3b938e ] The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned. Fixes: 692e5d73a811 ("scsi: elx: efct: LIO backend interface routines") Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Link: https://lore.kernel.org/r/20250627114117.188480-2-fourier.thomas@gmail.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/scsi/elx/efct/efct_lio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/elx/efct/efct_lio.c b/drivers/scsi/elx/efct/efct_lio.c index 9ac69356b13e..bd3d489e56ae 100644 --- a/drivers/scsi/elx/efct/efct_lio.c +++ b/drivers/scsi/elx/efct/efct_lio.c @@ -382,7 +382,7 @@ efct_lio_sg_unmap(struct efct_io *io) return; dma_unmap_sg(&io->efct->pci->dev, cmd->t_data_sg, - ocp->seg_map_cnt, cmd->data_direction); + cmd->t_data_nents, cmd->data_direction); ocp->seg_map_cnt = 0; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 285/480] scsi: mvsas: Fix dma_unmap_sg() nents value 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (283 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 284/480] scsi: elx: efct: " Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 286/480] scsi: isci: " Greg Kroah-Hartman ` (206 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Thomas Fourier, Martin K. Petersen, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Fourier <fourier.thomas@gmail.com> [ Upstream commit 0141618727bc929fe868153d21797f10ce5bef3f ] The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned. Fixes: b5762948263d ("[SCSI] mvsas: Add Marvell 6440 SAS/SATA driver") Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Link: https://lore.kernel.org/r/20250627134822.234813-2-fourier.thomas@gmail.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/scsi/mvsas/mv_sas.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/mvsas/mv_sas.c b/drivers/scsi/mvsas/mv_sas.c index 52ac10226cb0..3f12096528b1 100644 --- a/drivers/scsi/mvsas/mv_sas.c +++ b/drivers/scsi/mvsas/mv_sas.c @@ -818,7 +818,7 @@ static int mvs_task_prep(struct sas_task *task, struct mvs_info *mvi, int is_tmf dev_printk(KERN_ERR, mvi->dev, "mvsas prep failed[%d]!\n", rc); if (!sas_protocol_ata(task->task_proto)) if (n_elem) - dma_unmap_sg(mvi->dev, task->scatter, n_elem, + dma_unmap_sg(mvi->dev, task->scatter, task->num_scatter, task->data_dir); prep_out: return rc; @@ -864,7 +864,7 @@ static void mvs_slot_task_free(struct mvs_info *mvi, struct sas_task *task, if (!sas_protocol_ata(task->task_proto)) if (slot->n_elem) dma_unmap_sg(mvi->dev, task->scatter, - slot->n_elem, task->data_dir); + task->num_scatter, task->data_dir); switch (task->task_proto) { case SAS_PROTOCOL_SMP: -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 286/480] scsi: isci: Fix dma_unmap_sg() nents value 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (284 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 285/480] scsi: mvsas: " Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 287/480] PCI: Fix driver_managed_dma check Greg Kroah-Hartman ` (205 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Thomas Fourier, Martin K. Petersen, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Fourier <fourier.thomas@gmail.com> [ Upstream commit 063bec4444d54e5f35d11949c5c90eaa1ff84c11 ] The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned. Fixes: ddcc7e347a89 ("isci: fix dma_unmap_sg usage") Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Link: https://lore.kernel.org/r/20250627142451.241713-2-fourier.thomas@gmail.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/scsi/isci/request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/isci/request.c b/drivers/scsi/isci/request.c index 355a0bc0828e..bb89a2e33eb4 100644 --- a/drivers/scsi/isci/request.c +++ b/drivers/scsi/isci/request.c @@ -2904,7 +2904,7 @@ static void isci_request_io_request_complete(struct isci_host *ihost, task->total_xfer_len, task->data_dir); else /* unmap the sgl dma addresses */ dma_unmap_sg(&ihost->pdev->dev, task->scatter, - request->num_sg_entries, task->data_dir); + task->num_scatter, task->data_dir); break; case SAS_PROTOCOL_SMP: { struct scatterlist *sg = &task->smp_task.smp_req; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 287/480] PCI: Fix driver_managed_dma check 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (285 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 286/480] scsi: isci: " Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 288/480] watchdog: ziirave_wdt: check record length in ziirave_firm_verify() Greg Kroah-Hartman ` (204 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Will McVicker, Robin Murphy, Bjorn Helgaas, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Robin Murphy <robin.murphy@arm.com> [ Upstream commit 78447d4545b2ea76ee04f4e46d473639483158b2 ] Since it's not currently safe to take device_lock() in the IOMMU probe path, that can race against really_probe() setting dev->driver before attempting to bind. The race itself isn't so bad, since we're only concerned with dereferencing dev->driver itself anyway, but sadly my attempt to implement the check with minimal churn leads to a kind of Time-of-Check to Time-of-Use (TOCTOU) issue, where dev->driver becomes valid after to_pci_driver(NULL) is already computed, and thus the check fails to work as intended. Will and I both hit this with the platform bus, but the pattern here is the same, so fix it for correctness too. Fixes: bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper probe path") Reported-by: Will McVicker <willmcvicker@google.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Will McVicker <willmcvicker@google.com> Link: https://patch.msgid.link/20250425133929.646493-4-robin.murphy@arm.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/pci/pci-driver.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c index c8bd71a739f7..66e3bea7dc1a 100644 --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -1634,7 +1634,7 @@ static int pci_bus_num_vf(struct device *dev) */ static int pci_dma_configure(struct device *dev) { - struct pci_driver *driver = to_pci_driver(dev->driver); + const struct device_driver *drv = READ_ONCE(dev->driver); struct device *bridge; int ret = 0; @@ -1651,8 +1651,8 @@ static int pci_dma_configure(struct device *dev) pci_put_host_bridge_device(bridge); - /* @driver may not be valid when we're called from the IOMMU layer */ - if (!ret && dev->driver && !driver->driver_managed_dma) { + /* @drv may not be valid when we're called from the IOMMU layer */ + if (!ret && drv && !to_pci_driver(drv)->driver_managed_dma) { ret = iommu_device_use_default_domain(dev); if (ret) arch_teardown_dma_ops(dev); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 288/480] watchdog: ziirave_wdt: check record length in ziirave_firm_verify() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (286 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 287/480] PCI: Fix driver_managed_dma check Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 289/480] ext4: fix inode use after free in ext4_end_io_rsv_work() Greg Kroah-Hartman ` (203 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Dan Carpenter, Guenter Roeck, Wim Van Sebroeck, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Dan Carpenter <dan.carpenter@linaro.org> [ Upstream commit 8b61d8ca751bc15875b50e0ff6ac3ba0cf95a529 ] The "rec->len" value comes from the firmware. We generally do trust firmware, but it's always better to double check. If the length value is too large it would lead to memory corruption when we set "data[i] = ret;" Fixes: 217209db0204 ("watchdog: ziirave_wdt: Add support to upload the firmware.") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/3b58b453f0faa8b968c90523f52c11908b56c346.1748463049.git.dan.carpenter@linaro.org Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/watchdog/ziirave_wdt.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/watchdog/ziirave_wdt.c b/drivers/watchdog/ziirave_wdt.c index fcc1ba02e75b..5c6e3fa001d8 100644 --- a/drivers/watchdog/ziirave_wdt.c +++ b/drivers/watchdog/ziirave_wdt.c @@ -302,6 +302,9 @@ static int ziirave_firm_verify(struct watchdog_device *wdd, const u16 len = be16_to_cpu(rec->len); const u32 addr = be32_to_cpu(rec->addr); + if (len > sizeof(data)) + return -EINVAL; + if (ziirave_firm_addr_readonly(addr)) continue; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 289/480] ext4: fix inode use after free in ext4_end_io_rsv_work() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (287 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 288/480] watchdog: ziirave_wdt: check record length in ziirave_firm_verify() Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 290/480] ext4: Make sure BH_New bit is cleared in ->write_end handler Greg Kroah-Hartman ` (202 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Baokun Li, Zhang Yi, Jan Kara, Theodore Tso, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Baokun Li <libaokun1@huawei.com> [ Upstream commit c678bdc998754589cea2e6afab9401d7d8312ac4 ] In ext4_io_end_defer_completion(), check if io_end->list_vec is empty to avoid adding an io_end that requires no conversion to the i_rsv_conversion_list, which in turn prevents starting an unnecessary worker. An ext4_emergency_state() check is also added to avoid attempting to abort the journal in an emergency state. Additionally, ext4_put_io_end_defer() is refactored to call ext4_io_end_defer_completion() directly instead of being open-coded. This also prevents starting an unnecessary worker when EXT4_IO_END_FAILED is set but data_err=abort is not enabled. This ensures that the check in ext4_put_io_end_defer() is consistent with the check in ext4_end_bio(). Otherwise, we might add an io_end to the i_rsv_conversion_list and then call ext4_finish_bio(), after which the inode could be freed before ext4_end_io_rsv_work() is called, triggering a use-after-free issue. Fixes: ce51afb8cc5e ("ext4: abort journal on data writeback failure if in data_err=abort mode") Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Zhang Yi <yi.zhang@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://patch.msgid.link/20250708111504.3208660-1-libaokun@huaweicloud.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/ext4/page-io.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/fs/ext4/page-io.c b/fs/ext4/page-io.c index 179e54f3a3b6..3d8b0f6d2dea 100644 --- a/fs/ext4/page-io.c +++ b/fs/ext4/page-io.c @@ -236,10 +236,12 @@ static void dump_completed_IO(struct inode *inode, struct list_head *head) static bool ext4_io_end_defer_completion(ext4_io_end_t *io_end) { - if (io_end->flag & EXT4_IO_END_UNWRITTEN) + if (io_end->flag & EXT4_IO_END_UNWRITTEN && + !list_empty(&io_end->list_vec)) return true; if (test_opt(io_end->inode->i_sb, DATA_ERR_ABORT) && - io_end->flag & EXT4_IO_END_FAILED) + io_end->flag & EXT4_IO_END_FAILED && + !ext4_emergency_state(io_end->inode->i_sb)) return true; return false; } @@ -256,6 +258,7 @@ static void ext4_add_complete_io(ext4_io_end_t *io_end) WARN_ON(!(io_end->flag & EXT4_IO_END_DEFER_COMPLETION)); WARN_ON(io_end->flag & EXT4_IO_END_UNWRITTEN && !io_end->handle && sbi->s_journal); + WARN_ON(!io_end->bio); spin_lock_irqsave(&ei->i_completed_io_lock, flags); wq = sbi->rsv_conversion_wq; @@ -318,12 +321,9 @@ ext4_io_end_t *ext4_init_io_end(struct inode *inode, gfp_t flags) void ext4_put_io_end_defer(ext4_io_end_t *io_end) { if (refcount_dec_and_test(&io_end->count)) { - if (io_end->flag & EXT4_IO_END_FAILED || - (io_end->flag & EXT4_IO_END_UNWRITTEN && - !list_empty(&io_end->list_vec))) { - ext4_add_complete_io(io_end); - return; - } + if (ext4_io_end_defer_completion(io_end)) + return ext4_add_complete_io(io_end); + ext4_release_io_end(io_end); } } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 290/480] ext4: Make sure BH_New bit is cleared in ->write_end handler 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (288 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 289/480] ext4: fix inode use after free in ext4_end_io_rsv_work() Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 291/480] clk: at91: sam9x7: update pll clk ranges Greg Kroah-Hartman ` (201 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Baolin Liu, Zhi Long, Jan Kara, Theodore Tso, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jan Kara <jack@suse.cz> [ Upstream commit 91b8ca8b26729b729dda8a4eddb9aceaea706f37 ] Currently we clear BH_New bit in case of error and also in the standard ext4_write_end() handler (in block_commit_write()). However ext4_journalled_write_end() misses this clearing and thus we are leaving stale BH_New bits behind. Generally ext4_block_write_begin() clears these bits before any harm can be done but in case blocksize < pagesize and we hit some error when processing a page with these stale bits, we'll try to zero buffers with these stale BH_New bits and jbd2 will complain (as buffers were not prepared for writing in this transaction). Fix the problem by clearing BH_New bits in ext4_journalled_write_end() and WARN if ext4_block_write_begin() sees stale BH_New bits. Reported-by: Baolin Liu <liubaolin12138@163.com> Reported-by: Zhi Long <longzhi@sangfor.com.cn> Fixes: 3910b513fcdf ("ext4: persist the new uptodate buffers in ext4_journalled_zero_new_buffers") Signed-off-by: Jan Kara <jack@suse.cz> Link: https://patch.msgid.link/20250709084831.23876-2-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/ext4/inline.c | 2 ++ fs/ext4/inode.c | 3 ++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c index e5e6bf0d338b..f27d9da53fb7 100644 --- a/fs/ext4/inline.c +++ b/fs/ext4/inline.c @@ -611,6 +611,7 @@ static int ext4_convert_inline_data_to_extent(struct address_space *mapping, } else ret = ext4_block_write_begin(handle, folio, from, to, ext4_get_block); + clear_buffer_new(folio_buffers(folio)); if (!ret && ext4_should_journal_data(inode)) { ret = ext4_walk_page_buffers(handle, inode, @@ -890,6 +891,7 @@ static int ext4_da_convert_inline_data_to_extent(struct address_space *mapping, return ret; } + clear_buffer_new(folio_buffers(folio)); folio_mark_dirty(folio); folio_mark_uptodate(folio); ext4_clear_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA); diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 7fcdc01a0220..46bfb39f6108 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -1065,7 +1065,7 @@ int ext4_block_write_begin(handle_t *handle, struct folio *folio, } continue; } - if (buffer_new(bh)) + if (WARN_ON_ONCE(buffer_new(bh))) clear_buffer_new(bh); if (!buffer_mapped(bh)) { WARN_ON(bh->b_size != blocksize); @@ -1282,6 +1282,7 @@ static int write_end_fn(handle_t *handle, struct inode *inode, ret = ext4_dirty_journalled_data(handle, bh); clear_buffer_meta(bh); clear_buffer_prio(bh); + clear_buffer_new(bh); return ret; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 291/480] clk: at91: sam9x7: update pll clk ranges 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (289 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 290/480] ext4: Make sure BH_New bit is cleared in ->write_end handler Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 292/480] hwrng: mtk - handle devm_pm_runtime_enable errors Greg Kroah-Hartman ` (200 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Patrice Vilchez, Varshini Rajendran, Claudiu Beznea, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Varshini Rajendran <varshini.rajendran@microchip.com> [ Upstream commit c7f7ddbd27d55fa552a7269b7bae539adc2a3d46 ] Update the min, max ranges of the PLL clocks according to the latest datasheet to be coherent in the driver. This patch solves the issues in configuring the clocks related to peripherals with the desired frequency within the range. Fixes: 33013b43e271 ("clk: at91: sam9x7: add sam9x7 pmc driver") Suggested-by: Patrice Vilchez <Patrice.Vilchez@microchip.com> Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com> Link: https://lore.kernel.org/r/20250714093512.29944-1-varshini.rajendran@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/clk/at91/sam9x7.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/clk/at91/sam9x7.c b/drivers/clk/at91/sam9x7.c index cbb8b220f16b..ffab32b047a0 100644 --- a/drivers/clk/at91/sam9x7.c +++ b/drivers/clk/at91/sam9x7.c @@ -61,44 +61,44 @@ static const struct clk_master_layout sam9x7_master_layout = { /* Fractional PLL core output range. */ static const struct clk_range plla_core_outputs[] = { - { .min = 375000000, .max = 1600000000 }, + { .min = 800000000, .max = 1600000000 }, }; static const struct clk_range upll_core_outputs[] = { - { .min = 600000000, .max = 1200000000 }, + { .min = 600000000, .max = 960000000 }, }; static const struct clk_range lvdspll_core_outputs[] = { - { .min = 400000000, .max = 800000000 }, + { .min = 600000000, .max = 1200000000 }, }; static const struct clk_range audiopll_core_outputs[] = { - { .min = 400000000, .max = 800000000 }, + { .min = 600000000, .max = 1200000000 }, }; static const struct clk_range plladiv2_core_outputs[] = { - { .min = 375000000, .max = 1600000000 }, + { .min = 800000000, .max = 1600000000 }, }; /* Fractional PLL output range. */ static const struct clk_range plla_outputs[] = { - { .min = 732421, .max = 800000000 }, + { .min = 400000000, .max = 800000000 }, }; static const struct clk_range upll_outputs[] = { - { .min = 300000000, .max = 600000000 }, + { .min = 300000000, .max = 480000000 }, }; static const struct clk_range lvdspll_outputs[] = { - { .min = 10000000, .max = 800000000 }, + { .min = 175000000, .max = 550000000 }, }; static const struct clk_range audiopll_outputs[] = { - { .min = 10000000, .max = 800000000 }, + { .min = 0, .max = 300000000 }, }; static const struct clk_range plladiv2_outputs[] = { - { .min = 366210, .max = 400000000 }, + { .min = 200000000, .max = 400000000 }, }; /* PLL characteristics. */ -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 292/480] hwrng: mtk - handle devm_pm_runtime_enable errors 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (290 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 291/480] clk: at91: sam9x7: update pll clk ranges Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 293/480] crypto: keembay - Fix dma_unmap_sg() nents value Greg Kroah-Hartman ` (199 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Ovidiu Panait, Herbert Xu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ovidiu Panait <ovidiu.panait.oss@gmail.com> [ Upstream commit 522a242a18adc5c63a24836715dbeec4dc3faee1 ] Although unlikely, devm_pm_runtime_enable() call might fail, so handle the return value. Fixes: 78cb66caa6ab ("hwrng: mtk - Use devm_pm_runtime_enable") Signed-off-by: Ovidiu Panait <ovidiu.panait.oss@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/char/hw_random/mtk-rng.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/char/hw_random/mtk-rng.c b/drivers/char/hw_random/mtk-rng.c index 1e3048f2bb38..6c4e40d0365f 100644 --- a/drivers/char/hw_random/mtk-rng.c +++ b/drivers/char/hw_random/mtk-rng.c @@ -142,7 +142,9 @@ static int mtk_rng_probe(struct platform_device *pdev) dev_set_drvdata(&pdev->dev, priv); pm_runtime_set_autosuspend_delay(&pdev->dev, RNG_AUTOSUSPEND_TIMEOUT); pm_runtime_use_autosuspend(&pdev->dev); - devm_pm_runtime_enable(&pdev->dev); + ret = devm_pm_runtime_enable(&pdev->dev); + if (ret) + return ret; dev_info(&pdev->dev, "registered RNG driver\n"); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 293/480] crypto: keembay - Fix dma_unmap_sg() nents value 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (291 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 292/480] hwrng: mtk - handle devm_pm_runtime_enable errors Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 294/480] crypto: img-hash " Greg Kroah-Hartman ` (198 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Thomas Fourier, Herbert Xu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Fourier <fourier.thomas@gmail.com> [ Upstream commit 01951a7dc5ac1a37e5fb7d86ea7eb2dfbf96e8b6 ] The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned. Fixes: 472b04444cd3 ("crypto: keembay - Add Keem Bay OCS HCU driver") Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/crypto/intel/keembay/keembay-ocs-hcu-core.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/crypto/intel/keembay/keembay-ocs-hcu-core.c b/drivers/crypto/intel/keembay/keembay-ocs-hcu-core.c index 95dc8979918d..8f9e21ced0fe 100644 --- a/drivers/crypto/intel/keembay/keembay-ocs-hcu-core.c +++ b/drivers/crypto/intel/keembay/keembay-ocs-hcu-core.c @@ -68,6 +68,7 @@ struct ocs_hcu_ctx { * @sg_data_total: Total data in the SG list at any time. * @sg_data_offset: Offset into the data of the current individual SG node. * @sg_dma_nents: Number of sg entries mapped in dma_list. + * @nents: Number of entries in the scatterlist. */ struct ocs_hcu_rctx { struct ocs_hcu_dev *hcu_dev; @@ -91,6 +92,7 @@ struct ocs_hcu_rctx { unsigned int sg_data_total; unsigned int sg_data_offset; unsigned int sg_dma_nents; + unsigned int nents; }; /** @@ -199,7 +201,7 @@ static void kmb_ocs_hcu_dma_cleanup(struct ahash_request *req, /* Unmap req->src (if mapped). */ if (rctx->sg_dma_nents) { - dma_unmap_sg(dev, req->src, rctx->sg_dma_nents, DMA_TO_DEVICE); + dma_unmap_sg(dev, req->src, rctx->nents, DMA_TO_DEVICE); rctx->sg_dma_nents = 0; } @@ -260,6 +262,10 @@ static int kmb_ocs_dma_prepare(struct ahash_request *req) rc = -ENOMEM; goto cleanup; } + + /* Save the value of nents to pass to dma_unmap_sg. */ + rctx->nents = nents; + /* * The value returned by dma_map_sg() can be < nents; so update * nents accordingly. -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 294/480] crypto: img-hash - Fix dma_unmap_sg() nents value 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (292 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 293/480] crypto: keembay - Fix dma_unmap_sg() nents value Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 295/480] crypto: qat - disable ZUC-256 capability for QAT GEN5 Greg Kroah-Hartman ` (197 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Thomas Fourier, Herbert Xu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Fourier <fourier.thomas@gmail.com> [ Upstream commit 34b283636181ce02c52633551f594fec9876bec7 ] The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned. Fixes: d358f1abbf71 ("crypto: img-hash - Add Imagination Technologies hw hash accelerator") Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/crypto/img-hash.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/img-hash.c b/drivers/crypto/img-hash.c index 1dc2378aa88b..503bc1c9e3f3 100644 --- a/drivers/crypto/img-hash.c +++ b/drivers/crypto/img-hash.c @@ -436,7 +436,7 @@ static int img_hash_write_via_dma_stop(struct img_hash_dev *hdev) struct img_hash_request_ctx *ctx = ahash_request_ctx(hdev->req); if (ctx->flags & DRIVER_FLAGS_SG) - dma_unmap_sg(hdev->dev, ctx->sg, ctx->dma_ct, DMA_TO_DEVICE); + dma_unmap_sg(hdev->dev, ctx->sg, 1, DMA_TO_DEVICE); return 0; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 295/480] crypto: qat - disable ZUC-256 capability for QAT GEN5 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (293 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 294/480] crypto: img-hash " Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 296/480] crypto: krb5 - Fix memory leak in krb5_test_one_prf() Greg Kroah-Hartman ` (196 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Bairavi Alagappan, Giovanni Cabiddu, Herbert Xu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Bairavi Alagappan <bairavix.alagappan@intel.com> [ Upstream commit d956692c7dd523b331d4556ee03def8dd02609dc ] The ZUC-256 EEA (encryption) and EIA (integrity) algorithms are not supported on QAT GEN5 devices, as their current implementation does not align with the NIST specification. Earlier versions of the ZUC-256 specification used a different initialization scheme, which has since been revised to comply with the 5G specification. Due to this misalignment with the updated specification, remove support for ZUC-256 EEA and EIA for QAT GEN5 by masking out the ZUC-256 capability. Fixes: fcf60f4bcf549 ("crypto: qat - add support for 420xx devices") Signed-off-by: Bairavi Alagappan <bairavix.alagappan@intel.com> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/crypto/intel/qat/qat_420xx/adf_420xx_hw_data.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/drivers/crypto/intel/qat/qat_420xx/adf_420xx_hw_data.c b/drivers/crypto/intel/qat/qat_420xx/adf_420xx_hw_data.c index 4feeef83f7a3..3549167a9557 100644 --- a/drivers/crypto/intel/qat/qat_420xx/adf_420xx_hw_data.c +++ b/drivers/crypto/intel/qat/qat_420xx/adf_420xx_hw_data.c @@ -193,7 +193,6 @@ static u32 get_accel_cap(struct adf_accel_dev *accel_dev) ICP_ACCEL_CAPABILITIES_SM4 | ICP_ACCEL_CAPABILITIES_AES_V2 | ICP_ACCEL_CAPABILITIES_ZUC | - ICP_ACCEL_CAPABILITIES_ZUC_256 | ICP_ACCEL_CAPABILITIES_WIRELESS_CRYPTO_EXT | ICP_ACCEL_CAPABILITIES_EXT_ALGCHAIN; @@ -225,17 +224,11 @@ static u32 get_accel_cap(struct adf_accel_dev *accel_dev) if (fusectl1 & ICP_ACCEL_GEN4_MASK_WCP_WAT_SLICE) { capabilities_sym &= ~ICP_ACCEL_CAPABILITIES_ZUC; - capabilities_sym &= ~ICP_ACCEL_CAPABILITIES_ZUC_256; capabilities_sym &= ~ICP_ACCEL_CAPABILITIES_WIRELESS_CRYPTO_EXT; } - if (fusectl1 & ICP_ACCEL_GEN4_MASK_EIA3_SLICE) { + if (fusectl1 & ICP_ACCEL_GEN4_MASK_EIA3_SLICE) capabilities_sym &= ~ICP_ACCEL_CAPABILITIES_ZUC; - capabilities_sym &= ~ICP_ACCEL_CAPABILITIES_ZUC_256; - } - - if (fusectl1 & ICP_ACCEL_GEN4_MASK_ZUC_256_SLICE) - capabilities_sym &= ~ICP_ACCEL_CAPABILITIES_ZUC_256; capabilities_asym = ICP_ACCEL_CAPABILITIES_CRYPTO_ASYMMETRIC | ICP_ACCEL_CAPABILITIES_SM2 | -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 296/480] crypto: krb5 - Fix memory leak in krb5_test_one_prf() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (294 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 295/480] crypto: qat - disable ZUC-256 capability for QAT GEN5 Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 297/480] soundwire: stream: restore params when prepare ports fail Greg Kroah-Hartman ` (195 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Eric Biggers, David Howells, Herbert Xu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Eric Biggers <ebiggers@kernel.org> [ Upstream commit b19f1ab8d5bf417e00d5855c62e061fb449b13c5 ] Fix a leak reported by kmemleak: unreferenced object 0xffff8880093bf7a0 (size 32): comm "swapper/0", pid 1, jiffies 4294877529 hex dump (first 32 bytes): 9d 18 86 16 f6 38 52 fe 86 91 5b b8 40 b4 a8 86 .....8R...[.@... ff 3e 6b b0 f8 19 b4 9b 89 33 93 d3 93 85 42 95 .>k......3....B. backtrace (crc 8ba12f3b): kmemleak_alloc+0x8d/0xa0 __kmalloc_noprof+0x3cd/0x4d0 prep_buf+0x36/0x70 load_buf+0x10d/0x1c0 krb5_test_one_prf+0x1e1/0x3c0 krb5_selftest.cold+0x7c/0x54c crypto_krb5_init+0xd/0x20 do_one_initcall+0xa5/0x230 do_initcalls+0x213/0x250 kernel_init_freeable+0x220/0x260 kernel_init+0x1d/0x170 ret_from_fork+0x301/0x410 ret_from_fork_asm+0x1a/0x30 Fixes: fc0cf10c04f4 ("crypto/krb5: Implement crypto self-testing") Signed-off-by: Eric Biggers <ebiggers@kernel.org> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> --- crypto/krb5/selftest.c | 1 + 1 file changed, 1 insertion(+) diff --git a/crypto/krb5/selftest.c b/crypto/krb5/selftest.c index 2a81a6315a0d..4519c572d37e 100644 --- a/crypto/krb5/selftest.c +++ b/crypto/krb5/selftest.c @@ -152,6 +152,7 @@ static int krb5_test_one_prf(const struct krb5_prf_test *test) out: clear_buf(&result); + clear_buf(&prf); clear_buf(&octet); clear_buf(&key); return ret; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 297/480] soundwire: stream: restore params when prepare ports fail 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (295 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 296/480] crypto: krb5 - Fix memory leak in krb5_test_one_prf() Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 298/480] PCI: endpoint: pci-epf-vntb: Fix the incorrect usage of __iomem attribute Greg Kroah-Hartman ` (194 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Bard Liao, Péter Ujfalusi, Ranjani Sridharan, Vinod Koul, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Bard Liao <yung-chuan.liao@linux.intel.com> [ Upstream commit dba7d9dbfdc4389361ff3a910e767d3cfca22587 ] The bus->params should be restored if the stream is failed to prepare. The issue exists since beginning. The Fixes tag just indicates the first commit that the commit can be applied to. Fixes: 17ed5bef49f4 ("soundwire: add missing newlines in dynamic debug logs") Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20250626060952.405996-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/soundwire/stream.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/soundwire/stream.c b/drivers/soundwire/stream.c index a4bea742b5d9..38c9dbd35606 100644 --- a/drivers/soundwire/stream.c +++ b/drivers/soundwire/stream.c @@ -1510,7 +1510,7 @@ static int _sdw_prepare_stream(struct sdw_stream_runtime *stream, if (ret < 0) { dev_err(bus->dev, "Prepare port(s) failed ret = %d\n", ret); - return ret; + goto restore_params; } } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 298/480] PCI: endpoint: pci-epf-vntb: Fix the incorrect usage of __iomem attribute 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (296 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 297/480] soundwire: stream: restore params when prepare ports fail Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 299/480] clk: imx95-blk-ctl: Fix synchronous abort Greg Kroah-Hartman ` (193 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Manivannan Sadhasivam, Frank Li, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Manivannan Sadhasivam <mani@kernel.org> [ Upstream commit 61ae7f8694fb4b57a8c02a1a8d2b601806afc999 ] __iomem attribute is supposed to be used only with variables holding the MMIO pointer. But here, 'mw_addr' variable is just holding a 'void *' returned by pci_epf_alloc_space(). So annotating it with __iomem is clearly wrong. Hence, drop the attribute. This also fixes the below sparse warning: drivers/pci/endpoint/functions/pci-epf-vntb.c:524:17: warning: incorrect type in assignment (different address spaces) drivers/pci/endpoint/functions/pci-epf-vntb.c:524:17: expected void [noderef] __iomem *mw_addr drivers/pci/endpoint/functions/pci-epf-vntb.c:524:17: got void * drivers/pci/endpoint/functions/pci-epf-vntb.c:530:21: warning: incorrect type in assignment (different address spaces) drivers/pci/endpoint/functions/pci-epf-vntb.c:530:21: expected unsigned int [usertype] *epf_db drivers/pci/endpoint/functions/pci-epf-vntb.c:530:21: got void [noderef] __iomem *mw_addr drivers/pci/endpoint/functions/pci-epf-vntb.c:542:38: warning: incorrect type in argument 2 (different address spaces) drivers/pci/endpoint/functions/pci-epf-vntb.c:542:38: expected void *addr drivers/pci/endpoint/functions/pci-epf-vntb.c:542:38: got void [noderef] __iomem *mw_addr Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20250709125022.22524-1-mani@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/pci/endpoint/functions/pci-epf-vntb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/endpoint/functions/pci-epf-vntb.c b/drivers/pci/endpoint/functions/pci-epf-vntb.c index 3cddfdd04029..62d09a528e68 100644 --- a/drivers/pci/endpoint/functions/pci-epf-vntb.c +++ b/drivers/pci/endpoint/functions/pci-epf-vntb.c @@ -530,7 +530,7 @@ static int epf_ntb_db_bar_init(struct epf_ntb *ntb) struct device *dev = &ntb->epf->dev; int ret; struct pci_epf_bar *epf_bar; - void __iomem *mw_addr; + void *mw_addr; enum pci_barno barno; size_t size = sizeof(u32) * ntb->db_count; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 299/480] clk: imx95-blk-ctl: Fix synchronous abort 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (297 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 298/480] PCI: endpoint: pci-epf-vntb: Fix the incorrect usage of __iomem attribute Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 300/480] remoteproc: xlnx: Disable unsupported features Greg Kroah-Hartman ` (192 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Frank Li, Abel Vesa, Laurentiu Palcu, Peng Fan, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> [ Upstream commit b08217a257215ed9130fce93d35feba66b49bf0a ] When enabling runtime PM for clock suppliers that also belong to a power domain, the following crash is thrown: error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP Workqueue: events_unbound deferred_probe_work_func pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : clk_mux_get_parent+0x60/0x90 lr : clk_core_reparent_orphans_nolock+0x58/0xd8 Call trace: clk_mux_get_parent+0x60/0x90 clk_core_reparent_orphans_nolock+0x58/0xd8 of_clk_add_hw_provider.part.0+0x90/0x100 of_clk_add_hw_provider+0x1c/0x38 imx95_bc_probe+0x2e0/0x3f0 platform_probe+0x70/0xd8 Enabling runtime PM without explicitly resuming the device caused the power domain cut off after clk_register() is called. As a result, a crash happens when the clock hardware provider is added and attempts to access the BLK_CTL register. Fix this by using devm_pm_runtime_enable() instead of pm_runtime_enable() and getting rid of the pm_runtime_disable() in the cleanup path. Fixes: 5224b189462f ("clk: imx: add i.MX95 BLK CTL clk driver") Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20250707-imx95-blk-ctl-7-1-v3-2-c1b676ec13be@nxp.com Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/clk/imx/clk-imx95-blk-ctl.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/clk/imx/clk-imx95-blk-ctl.c b/drivers/clk/imx/clk-imx95-blk-ctl.c index cc2ee2be1819..86bdcd217531 100644 --- a/drivers/clk/imx/clk-imx95-blk-ctl.c +++ b/drivers/clk/imx/clk-imx95-blk-ctl.c @@ -342,8 +342,10 @@ static int imx95_bc_probe(struct platform_device *pdev) if (!clk_hw_data) return -ENOMEM; - if (bc_data->rpm_enabled) - pm_runtime_enable(&pdev->dev); + if (bc_data->rpm_enabled) { + devm_pm_runtime_enable(&pdev->dev); + pm_runtime_resume_and_get(&pdev->dev); + } clk_hw_data->num = bc_data->num_clks; hws = clk_hw_data->hws; @@ -383,8 +385,10 @@ static int imx95_bc_probe(struct platform_device *pdev) goto cleanup; } - if (pm_runtime_enabled(bc->dev)) + if (pm_runtime_enabled(bc->dev)) { + pm_runtime_put_sync(&pdev->dev); clk_disable_unprepare(bc->clk_apb); + } return 0; @@ -395,9 +399,6 @@ static int imx95_bc_probe(struct platform_device *pdev) clk_hw_unregister(hws[i]); } - if (bc_data->rpm_enabled) - pm_runtime_disable(&pdev->dev); - return ret; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 300/480] remoteproc: xlnx: Disable unsupported features 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (298 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 299/480] clk: imx95-blk-ctl: Fix synchronous abort Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 301/480] fs/orangefs: Allow 2 more characters in do_c_string() Greg Kroah-Hartman ` (191 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Tanmay Shah, Mathieu Poirier, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Tanmay Shah <tanmay.shah@amd.com> [ Upstream commit 699cdd706290208d47bd858a188b030df2e90357 ] AMD-Xilinx platform driver does not support iommu or recovery mechanism yet. Disable both features in platform driver. Signed-off-by: Tanmay Shah <tanmay.shah@amd.com> Link: https://lore.kernel.org/r/20250716213048.2316424-2-tanmay.shah@amd.com Fixes: 6b291e8020a8 ("drivers: remoteproc: Add Xilinx r5 remoteproc driver") Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/remoteproc/xlnx_r5_remoteproc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c index 5aeedeaf3c41..c165422d0651 100644 --- a/drivers/remoteproc/xlnx_r5_remoteproc.c +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c @@ -906,6 +906,8 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev) rproc_coredump_set_elf_info(r5_rproc, ELFCLASS32, EM_ARM); + r5_rproc->recovery_disabled = true; + r5_rproc->has_iommu = false; r5_rproc->auto_boot = false; r5_core = r5_rproc->priv; r5_core->dev = cdev; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 301/480] fs/orangefs: Allow 2 more characters in do_c_string() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (299 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 300/480] remoteproc: xlnx: Disable unsupported features Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 302/480] tools subcmd: Tighten the filename size in check_if_command_finished Greg Kroah-Hartman ` (190 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Dan Carpenter, Mike Marshall, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Dan Carpenter <dan.carpenter@linaro.org> [ Upstream commit 2138e89cb066b40386b1d9ddd61253347d356474 ] The do_k_string() and do_c_string() functions do essentially the same thing which is they add a string and a comma onto the end of an existing string. At the end, the caller will overwrite the last comma with a newline. Later, in orangefs_kernel_debug_init(), we add a newline to the string. The change to do_k_string() is just cosmetic. I moved the "- 1" to the other side of the comparison and made it "+ 1". This has no effect on runtime, I just wanted the functions to match each other and the rest of the file. However in do_c_string(), I removed the "- 2" which allows us to print two extra characters. I noticed this issue while reviewing the code and I doubt affects anything in real life. My guess is that this was double counting the comma and the newline. The "+ 1" accounts for the newline, and the caller will delete the final comma which ensures there is enough space for the newline. Removing the "- 2" lets us print 2 more characters, but mainly it makes the code more consistent and understandable for reviewers. Fixes: 44f4641073f1 ("orangefs: clean up debugfs globals") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Mike Marshall <hubcap@omnibond.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/orangefs/orangefs-debugfs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/orangefs/orangefs-debugfs.c b/fs/orangefs/orangefs-debugfs.c index f7095c91660c..e8e3badbc2ec 100644 --- a/fs/orangefs/orangefs-debugfs.c +++ b/fs/orangefs/orangefs-debugfs.c @@ -769,8 +769,8 @@ static void do_k_string(void *k_mask, int index) if (*mask & s_kmod_keyword_mask_map[index].mask_val) { if ((strlen(kernel_debug_string) + - strlen(s_kmod_keyword_mask_map[index].keyword)) - < ORANGEFS_MAX_DEBUG_STRING_LEN - 1) { + strlen(s_kmod_keyword_mask_map[index].keyword) + 1) + < ORANGEFS_MAX_DEBUG_STRING_LEN) { strcat(kernel_debug_string, s_kmod_keyword_mask_map[index].keyword); strcat(kernel_debug_string, ","); @@ -797,7 +797,7 @@ static void do_c_string(void *c_mask, int index) (mask->mask2 & cdm_array[index].mask2)) { if ((strlen(client_debug_string) + strlen(cdm_array[index].keyword) + 1) - < ORANGEFS_MAX_DEBUG_STRING_LEN - 2) { + < ORANGEFS_MAX_DEBUG_STRING_LEN) { strcat(client_debug_string, cdm_array[index].keyword); strcat(client_debug_string, ","); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 302/480] tools subcmd: Tighten the filename size in check_if_command_finished 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (300 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 301/480] fs/orangefs: Allow 2 more characters in do_c_string() Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 303/480] dmaengine: mv_xor: Fix missing check after DMA map and missing unmap Greg Kroah-Hartman ` (189 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Ian Rogers, Namhyung Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ian Rogers <irogers@google.com> [ Upstream commit 478272d1cdd9959a6d638e9d81f70642f04290c9 ] FILENAME_MAX is often PATH_MAX (4kb), far more than needed for the /proc path. Make the buffer size sufficient for the maximum integer plus "/proc/" and "/status" with a '\0' terminator. Fixes: 5ce42b5de461 ("tools subcmd: Add non-waitpid check_if_command_finished()") Signed-off-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20250717150855.1032526-1-irogers@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/lib/subcmd/run-command.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/tools/lib/subcmd/run-command.c b/tools/lib/subcmd/run-command.c index 0a764c25c384..b7510f83209a 100644 --- a/tools/lib/subcmd/run-command.c +++ b/tools/lib/subcmd/run-command.c @@ -5,6 +5,7 @@ #include <ctype.h> #include <fcntl.h> #include <string.h> +#include <linux/compiler.h> #include <linux/string.h> #include <errno.h> #include <sys/wait.h> @@ -216,10 +217,20 @@ static int wait_or_whine(struct child_process *cmd, bool block) return result; } +/* + * Conservative estimate of number of characaters needed to hold an a decoded + * integer, assume each 3 bits needs a character byte and plus a possible sign + * character. + */ +#ifndef is_signed_type +#define is_signed_type(type) (((type)(-1)) < (type)1) +#endif +#define MAX_STRLEN_TYPE(type) (sizeof(type) * 8 / 3 + (is_signed_type(type) ? 1 : 0)) + int check_if_command_finished(struct child_process *cmd) { #ifdef __linux__ - char filename[FILENAME_MAX + 12]; + char filename[6 + MAX_STRLEN_TYPE(typeof(cmd->pid)) + 7 + 1]; char status_line[256]; FILE *status_file; @@ -227,7 +238,7 @@ int check_if_command_finished(struct child_process *cmd) * Check by reading /proc/<pid>/status as calling waitpid causes * stdout/stderr to be closed and data lost. */ - sprintf(filename, "/proc/%d/status", cmd->pid); + sprintf(filename, "/proc/%u/status", cmd->pid); status_file = fopen(filename, "r"); if (status_file == NULL) { /* Open failed assume finish_command was called. */ -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 303/480] dmaengine: mv_xor: Fix missing check after DMA map and missing unmap 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (301 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 302/480] tools subcmd: Tighten the filename size in check_if_command_finished Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 304/480] dmaengine: nbpfaxi: Add missing check after DMA map Greg Kroah-Hartman ` (188 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Thomas Fourier, Vinod Koul, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Fourier <fourier.thomas@gmail.com> [ Upstream commit 60095aca6b471b7b7a79c80b7395f7e4e414b479 ] The DMA map functions can fail and should be tested for errors. In case of error, unmap the already mapped regions. Fixes: 22843545b200 ("dma: mv_xor: Add support for DMA_INTERRUPT") Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Link: https://lore.kernel.org/r/20250701123753.46935-2-fourier.thomas@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/dma/mv_xor.c | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c index fa6e4646fdc2..1fdcb0f5c9e7 100644 --- a/drivers/dma/mv_xor.c +++ b/drivers/dma/mv_xor.c @@ -1061,8 +1061,16 @@ mv_xor_channel_add(struct mv_xor_device *xordev, */ mv_chan->dummy_src_addr = dma_map_single(dma_dev->dev, mv_chan->dummy_src, MV_XOR_MIN_BYTE_COUNT, DMA_FROM_DEVICE); + if (dma_mapping_error(dma_dev->dev, mv_chan->dummy_src_addr)) + return ERR_PTR(-ENOMEM); + mv_chan->dummy_dst_addr = dma_map_single(dma_dev->dev, mv_chan->dummy_dst, MV_XOR_MIN_BYTE_COUNT, DMA_TO_DEVICE); + if (dma_mapping_error(dma_dev->dev, mv_chan->dummy_dst_addr)) { + ret = -ENOMEM; + goto err_unmap_src; + } + /* allocate coherent memory for hardware descriptors * note: writecombine gives slightly better performance, but @@ -1071,8 +1079,10 @@ mv_xor_channel_add(struct mv_xor_device *xordev, mv_chan->dma_desc_pool_virt = dma_alloc_wc(&pdev->dev, MV_XOR_POOL_SIZE, &mv_chan->dma_desc_pool, GFP_KERNEL); - if (!mv_chan->dma_desc_pool_virt) - return ERR_PTR(-ENOMEM); + if (!mv_chan->dma_desc_pool_virt) { + ret = -ENOMEM; + goto err_unmap_dst; + } /* discover transaction capabilities from the platform data */ dma_dev->cap_mask = cap_mask; @@ -1155,6 +1165,13 @@ mv_xor_channel_add(struct mv_xor_device *xordev, err_free_dma: dma_free_coherent(&pdev->dev, MV_XOR_POOL_SIZE, mv_chan->dma_desc_pool_virt, mv_chan->dma_desc_pool); +err_unmap_dst: + dma_unmap_single(dma_dev->dev, mv_chan->dummy_dst_addr, + MV_XOR_MIN_BYTE_COUNT, DMA_TO_DEVICE); +err_unmap_src: + dma_unmap_single(dma_dev->dev, mv_chan->dummy_src_addr, + MV_XOR_MIN_BYTE_COUNT, DMA_FROM_DEVICE); + return ERR_PTR(ret); } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 304/480] dmaengine: nbpfaxi: Add missing check after DMA map 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (302 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 303/480] dmaengine: mv_xor: Fix missing check after DMA map and missing unmap Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 305/480] mfd: tps65219: Update TPS65214 MFD cells GPIO compatible string Greg Kroah-Hartman ` (187 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Thomas Fourier, Vinod Koul, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Fourier <fourier.thomas@gmail.com> [ Upstream commit c6ee78fc8f3e653bec427cfd06fec7877ee782bd ] The DMA map functions can fail and should be tested for errors. If the mapping fails, unmap and return an error. Fixes: b45b262cefd5 ("dmaengine: add a driver for AMBA AXI NBPF DMAC IP cores") Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Link: https://lore.kernel.org/r/20250707075752.28674-2-fourier.thomas@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/dma/nbpfaxi.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/dma/nbpfaxi.c b/drivers/dma/nbpfaxi.c index 7a2488a0d6a3..765462303de0 100644 --- a/drivers/dma/nbpfaxi.c +++ b/drivers/dma/nbpfaxi.c @@ -711,6 +711,9 @@ static int nbpf_desc_page_alloc(struct nbpf_channel *chan) list_add_tail(&ldesc->node, &lhead); ldesc->hwdesc_dma_addr = dma_map_single(dchan->device->dev, hwdesc, sizeof(*hwdesc), DMA_TO_DEVICE); + if (dma_mapping_error(dchan->device->dev, + ldesc->hwdesc_dma_addr)) + goto unmap_error; dev_dbg(dev, "%s(): mapped 0x%p to %pad\n", __func__, hwdesc, &ldesc->hwdesc_dma_addr); @@ -737,6 +740,16 @@ static int nbpf_desc_page_alloc(struct nbpf_channel *chan) spin_unlock_irq(&chan->lock); return ARRAY_SIZE(dpage->desc); + +unmap_error: + while (i--) { + ldesc--; hwdesc--; + + dma_unmap_single(dchan->device->dev, ldesc->hwdesc_dma_addr, + sizeof(hwdesc), DMA_TO_DEVICE); + } + + return -ENOMEM; } static void nbpf_desc_put(struct nbpf_desc *desc) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 305/480] mfd: tps65219: Update TPS65214 MFD cells GPIO compatible string 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (303 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 304/480] dmaengine: nbpfaxi: Add missing check after DMA map Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 306/480] ASoC: SDCA: Fix some holes in the regmap readable/writeable helpers Greg Kroah-Hartman ` (186 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Shree Ramamoorthy, Lee Jones, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Shree Ramamoorthy <s-ramamoorthy@ti.com> [ Upstream commit 6f27d26e363a41fc651be852094823ce47a43243 ] This patch reflects the change made to move TPS65215 from 1 GPO and 1 GPIO to 2 GPOs and 1 GPIO. TPS65215 and TPS65219 both have 2 GPOs and 1 GPIO. TPS65214 has 1 GPO and 1 GPIO. TPS65215 will reuse the TPS65219 GPIO compatible string. TPS65214 TRM: https://www.ti.com/lit/pdf/slvud30 TPS65215 TRM: https://www.ti.com/lit/pdf/slvucw5/ Fixes: 7947219ab1a2 ("mfd: tps65219: Add support for TI TPS65214 PMIC") Signed-off-by: Shree Ramamoorthy <s-ramamoorthy@ti.com> Link: https://lore.kernel.org/r/20250527190455.169772-2-s-ramamoorthy@ti.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/mfd/tps65219.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/tps65219.c b/drivers/mfd/tps65219.c index fd390600fbf0..297511025dd4 100644 --- a/drivers/mfd/tps65219.c +++ b/drivers/mfd/tps65219.c @@ -190,7 +190,7 @@ static const struct resource tps65219_regulator_resources[] = { static const struct mfd_cell tps65214_cells[] = { MFD_CELL_RES("tps65214-regulator", tps65214_regulator_resources), - MFD_CELL_NAME("tps65215-gpio"), + MFD_CELL_NAME("tps65214-gpio"), }; static const struct mfd_cell tps65215_cells[] = { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 306/480] ASoC: SDCA: Fix some holes in the regmap readable/writeable helpers 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (304 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 305/480] mfd: tps65219: Update TPS65214 MFD cells GPIO compatible string Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 307/480] ASoC: fsl_xcvr: get channel status data when PHY is not exists Greg Kroah-Hartman ` (185 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Charles Keepax, Mark Brown, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Charles Keepax <ckeepax@opensource.cirrus.com> [ Upstream commit 061fade7a67f6cdfe918a675270d84107abbef61 ] The current regmap readable/writeable helper functions always allow the Next flag and allows any Control Number. Mask the Next flag based on SDCA_ACCESS_MODE_DUAL which is the only Mode that supports it. Also check that the Control Number is valid for the given control. Fixes: e3f7caf74b79 ("ASoC: SDCA: Add generic regmap SDCA helpers") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250718135432.1048566-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- sound/soc/sdca/sdca_regmap.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/sound/soc/sdca/sdca_regmap.c b/sound/soc/sdca/sdca_regmap.c index 4b78188cfceb..394058a0537c 100644 --- a/sound/soc/sdca/sdca_regmap.c +++ b/sound/soc/sdca/sdca_regmap.c @@ -72,12 +72,18 @@ bool sdca_regmap_readable(struct sdca_function_data *function, unsigned int reg) if (!control) return false; + if (!(BIT(SDW_SDCA_CTL_CNUM(reg)) & control->cn_list)) + return false; + switch (control->mode) { case SDCA_ACCESS_MODE_RW: case SDCA_ACCESS_MODE_RO: - case SDCA_ACCESS_MODE_DUAL: case SDCA_ACCESS_MODE_RW1S: case SDCA_ACCESS_MODE_RW1C: + if (SDW_SDCA_NEXT_CTL(0) & reg) + return false; + fallthrough; + case SDCA_ACCESS_MODE_DUAL: /* No access to registers marked solely for device use */ return control->layers & ~SDCA_ACCESS_LAYER_DEVICE; default: @@ -104,11 +110,17 @@ bool sdca_regmap_writeable(struct sdca_function_data *function, unsigned int reg if (!control) return false; + if (!(BIT(SDW_SDCA_CTL_CNUM(reg)) & control->cn_list)) + return false; + switch (control->mode) { case SDCA_ACCESS_MODE_RW: - case SDCA_ACCESS_MODE_DUAL: case SDCA_ACCESS_MODE_RW1S: case SDCA_ACCESS_MODE_RW1C: + if (SDW_SDCA_NEXT_CTL(0) & reg) + return false; + fallthrough; + case SDCA_ACCESS_MODE_DUAL: /* No access to registers marked solely for device use */ return control->layers & ~SDCA_ACCESS_LAYER_DEVICE; default: -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 307/480] ASoC: fsl_xcvr: get channel status data when PHY is not exists 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (305 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 306/480] ASoC: SDCA: Fix some holes in the regmap readable/writeable helpers Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 308/480] ASoC: fsl_xcvr: get channel status data with firmware exists Greg Kroah-Hartman ` (184 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Shengjiu Wang, Mark Brown, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Shengjiu Wang <shengjiu.wang@nxp.com> [ Upstream commit ca592e20659e0304ebd8f4dabb273da4f9385848 ] There is no PHY for the XCVR module on i.MX93, the channel status needs to be obtained from FSL_XCVR_RX_CS_DATA_* registers. And channel status acknowledge (CSA) bit should be set once channel status is processed. Fixes: e240b9329a30 ("ASoC: fsl_xcvr: Add support for i.MX93 platform") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://patch.msgid.link/20250710030405.3370671-2-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- sound/soc/fsl/fsl_xcvr.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/sound/soc/fsl/fsl_xcvr.c b/sound/soc/fsl/fsl_xcvr.c index 83aea341c1b6..5b1e5f377426 100644 --- a/sound/soc/fsl/fsl_xcvr.c +++ b/sound/soc/fsl/fsl_xcvr.c @@ -1423,6 +1423,26 @@ static irqreturn_t irq0_isr(int irq, void *devid) /* clear CS control register */ memset_io(reg_ctrl, 0, sizeof(val)); } + } else { + regmap_read(xcvr->regmap, FSL_XCVR_RX_CS_DATA_0, + (u32 *)&xcvr->rx_iec958.status[0]); + regmap_read(xcvr->regmap, FSL_XCVR_RX_CS_DATA_1, + (u32 *)&xcvr->rx_iec958.status[4]); + regmap_read(xcvr->regmap, FSL_XCVR_RX_CS_DATA_2, + (u32 *)&xcvr->rx_iec958.status[8]); + regmap_read(xcvr->regmap, FSL_XCVR_RX_CS_DATA_3, + (u32 *)&xcvr->rx_iec958.status[12]); + regmap_read(xcvr->regmap, FSL_XCVR_RX_CS_DATA_4, + (u32 *)&xcvr->rx_iec958.status[16]); + regmap_read(xcvr->regmap, FSL_XCVR_RX_CS_DATA_5, + (u32 *)&xcvr->rx_iec958.status[20]); + for (i = 0; i < 6; i++) { + val = *(u32 *)(xcvr->rx_iec958.status + i * 4); + *(u32 *)(xcvr->rx_iec958.status + i * 4) = + bitrev32(val); + } + regmap_set_bits(xcvr->regmap, FSL_XCVR_RX_DPTH_CTRL, + FSL_XCVR_RX_DPTH_CTRL_CSA); } } if (isr & FSL_XCVR_IRQ_NEW_UD) { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 308/480] ASoC: fsl_xcvr: get channel status data with firmware exists 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (306 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 307/480] ASoC: fsl_xcvr: get channel status data when PHY is not exists Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 309/480] sh: Do not use hyphen in exported variable name Greg Kroah-Hartman ` (183 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Shengjiu Wang, Mark Brown, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Shengjiu Wang <shengjiu.wang@nxp.com> [ Upstream commit 6776ecc9dd587c08a6bb334542f9f8821a091013 ] For the XCVR module on i.MX95, even though it only supports SPDIF, the channel status needs to be obtained from RAM space, which is processed by firmware. Firmware is necessary to trigger the FSL_XCVR_IRQ_NEW_CS interrupt. This change also applies for the SPDIF & ARC function on i.MX8MP which has the firmware. Fixes: e6a9750a346b ("ASoC: fsl_xcvr: Add suspend and resume support") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://patch.msgid.link/20250710030405.3370671-3-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- sound/soc/fsl/fsl_xcvr.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/sound/soc/fsl/fsl_xcvr.c b/sound/soc/fsl/fsl_xcvr.c index 5b1e5f377426..f877dcb2570a 100644 --- a/sound/soc/fsl/fsl_xcvr.c +++ b/sound/soc/fsl/fsl_xcvr.c @@ -1395,7 +1395,7 @@ static irqreturn_t irq0_isr(int irq, void *devid) if (isr & FSL_XCVR_IRQ_NEW_CS) { dev_dbg(dev, "Received new CS block\n"); isr_clr |= FSL_XCVR_IRQ_NEW_CS; - if (!xcvr->soc_data->spdif_only) { + if (xcvr->soc_data->fw_name) { /* Data RAM is 4KiB, last two pages: 8 and 9. Select page 8. */ regmap_update_bits(xcvr->regmap, FSL_XCVR_EXT_CTRL, FSL_XCVR_EXT_CTRL_PAGE_MASK, @@ -1517,6 +1517,7 @@ static const struct fsl_xcvr_soc_data fsl_xcvr_imx93_data = { }; static const struct fsl_xcvr_soc_data fsl_xcvr_imx95_data = { + .fw_name = "imx/xcvr/xcvr-imx95.bin", .spdif_only = true, .use_phy = true, .use_edma = true, @@ -1806,7 +1807,7 @@ static int fsl_xcvr_runtime_resume(struct device *dev) } } - if (xcvr->mode == FSL_XCVR_MODE_EARC) { + if (xcvr->soc_data->fw_name) { ret = fsl_xcvr_load_firmware(xcvr); if (ret) { dev_err(dev, "failed to load firmware.\n"); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 309/480] sh: Do not use hyphen in exported variable name 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (307 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 308/480] ASoC: fsl_xcvr: get channel status data with firmware exists Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 310/480] perf tools: Remove libtraceevent in .gitignore Greg Kroah-Hartman ` (182 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Ben Hutchings, John Paul Adrian Glaubitz, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ben Hutchings <benh@debian.org> [ Upstream commit c32969d0362a790fbc6117e0b6a737a7e510b843 ] arch/sh/Makefile defines and exports ld-bfd to be used by arch/sh/boot/compressed/Makefile and arch/sh/boot/romimage/Makefile. However some shells, including dash, will not pass through environment variables whose name includes a hyphen. Usually GNU make does not use a shell to recurse, but if e.g. $(srctree) contains '~' it will use a shell here. Other instances of this problem were previously fixed by commits 2bfbe7881ee0 "kbuild: Do not use hyphen in exported variable name" and 82977af93a0d "sh: rename suffix-y to suffix_y". Rename the variable to ld_bfd. References: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=sh4&ver=4.13%7Erc5-1%7Eexp1&stamp=1502943967&raw=0 Fixes: 7b022d07a0fd ("sh: Tidy up the ldscript output format specifier.") Signed-off-by: Ben Hutchings <benh@debian.org> Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/sh/Makefile | 10 +++++----- arch/sh/boot/compressed/Makefile | 4 ++-- arch/sh/boot/romimage/Makefile | 4 ++-- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/arch/sh/Makefile b/arch/sh/Makefile index cab2f9c011a8..7b420424b6d7 100644 --- a/arch/sh/Makefile +++ b/arch/sh/Makefile @@ -103,16 +103,16 @@ UTS_MACHINE := sh LDFLAGS_vmlinux += -e _stext ifdef CONFIG_CPU_LITTLE_ENDIAN -ld-bfd := elf32-sh-linux -LDFLAGS_vmlinux += --defsym jiffies=jiffies_64 --oformat $(ld-bfd) +ld_bfd := elf32-sh-linux +LDFLAGS_vmlinux += --defsym jiffies=jiffies_64 --oformat $(ld_bfd) KBUILD_LDFLAGS += -EL else -ld-bfd := elf32-shbig-linux -LDFLAGS_vmlinux += --defsym jiffies=jiffies_64+4 --oformat $(ld-bfd) +ld_bfd := elf32-shbig-linux +LDFLAGS_vmlinux += --defsym jiffies=jiffies_64+4 --oformat $(ld_bfd) KBUILD_LDFLAGS += -EB endif -export ld-bfd +export ld_bfd # Mach groups machdir-$(CONFIG_SOLUTION_ENGINE) += mach-se diff --git a/arch/sh/boot/compressed/Makefile b/arch/sh/boot/compressed/Makefile index 8bc319ff54bf..58df491778b2 100644 --- a/arch/sh/boot/compressed/Makefile +++ b/arch/sh/boot/compressed/Makefile @@ -27,7 +27,7 @@ endif ccflags-remove-$(CONFIG_MCOUNT) += -pg -LDFLAGS_vmlinux := --oformat $(ld-bfd) -Ttext $(IMAGE_OFFSET) -e startup \ +LDFLAGS_vmlinux := --oformat $(ld_bfd) -Ttext $(IMAGE_OFFSET) -e startup \ -T $(obj)/../../kernel/vmlinux.lds KBUILD_CFLAGS += -DDISABLE_BRANCH_PROFILING @@ -51,7 +51,7 @@ $(obj)/vmlinux.bin.lzo: $(obj)/vmlinux.bin FORCE OBJCOPYFLAGS += -R .empty_zero_page -LDFLAGS_piggy.o := -r --format binary --oformat $(ld-bfd) -T +LDFLAGS_piggy.o := -r --format binary --oformat $(ld_bfd) -T $(obj)/piggy.o: $(obj)/vmlinux.scr $(obj)/vmlinux.bin.$(suffix_y) FORCE $(call if_changed,ld) diff --git a/arch/sh/boot/romimage/Makefile b/arch/sh/boot/romimage/Makefile index c7c8be58400c..17b03df0a8de 100644 --- a/arch/sh/boot/romimage/Makefile +++ b/arch/sh/boot/romimage/Makefile @@ -13,7 +13,7 @@ mmcif-obj-$(CONFIG_CPU_SUBTYPE_SH7724) := $(obj)/mmcif-sh7724.o load-$(CONFIG_ROMIMAGE_MMCIF) := $(mmcif-load-y) obj-$(CONFIG_ROMIMAGE_MMCIF) := $(mmcif-obj-y) -LDFLAGS_vmlinux := --oformat $(ld-bfd) -Ttext $(load-y) -e romstart \ +LDFLAGS_vmlinux := --oformat $(ld_bfd) -Ttext $(load-y) -e romstart \ -T $(obj)/../../kernel/vmlinux.lds $(obj)/vmlinux: $(obj)/head.o $(obj-y) $(obj)/piggy.o FORCE @@ -24,7 +24,7 @@ OBJCOPYFLAGS += -j .empty_zero_page $(obj)/zeropage.bin: vmlinux FORCE $(call if_changed,objcopy) -LDFLAGS_piggy.o := -r --format binary --oformat $(ld-bfd) -T +LDFLAGS_piggy.o := -r --format binary --oformat $(ld_bfd) -T $(obj)/piggy.o: $(obj)/vmlinux.scr $(obj)/zeropage.bin arch/sh/boot/zImage FORCE $(call if_changed,ld) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 310/480] perf tools: Remove libtraceevent in .gitignore 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (308 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 309/480] sh: Do not use hyphen in exported variable name Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 311/480] clk: clocking-wizard: Fix the round rate handling for versal Greg Kroah-Hartman ` (181 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Chen Pei, Namhyung Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Chen Pei <cp0613@linux.alibaba.com> [ Upstream commit af470fb532fc803c4c582d15b4bd394682a77a15 ] The libtraceevent has been removed from the source tree, and .gitignore needs to be updated as well. Fixes: 4171925aa9f3f7bf ("tools lib traceevent: Remove libtraceevent") Signed-off-by: Chen Pei <cp0613@linux.alibaba.com> Link: https://lore.kernel.org/r/20250726111532.8031-1-cp0613@linux.alibaba.com Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/perf/.gitignore | 2 -- 1 file changed, 2 deletions(-) diff --git a/tools/perf/.gitignore b/tools/perf/.gitignore index 5aaf73df6700..b64302a76144 100644 --- a/tools/perf/.gitignore +++ b/tools/perf/.gitignore @@ -48,8 +48,6 @@ libbpf/ libperf/ libsubcmd/ libsymbol/ -libtraceevent/ -libtraceevent_plugins/ fixdep Documentation/doc.dep python_ext_build/ -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 311/480] clk: clocking-wizard: Fix the round rate handling for versal 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (309 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 310/480] perf tools: Remove libtraceevent in .gitignore Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 312/480] crypto: qat - fix DMA direction for compression on GEN2 devices Greg Kroah-Hartman ` (180 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Shubhrajyoti Datta, Stephen Boyd, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> [ Upstream commit 7f5e9ca0a424af44a708bb4727624d56f83ecffa ] Fix the `clk_round_rate` implementation for Versal platforms by calling the Versal-specific divider calculation helper. The existing code used the generic divider routine, which results in incorrect round rate. Fixes: 7681f64e6404 ("clk: clocking-wizard: calculate dividers fractional parts") Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> Link: https://lore.kernel.org/r/20250625054114.28273-1-shubhrajyoti.datta@amd.com Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/clk/xilinx/clk-xlnx-clock-wizard.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/xilinx/clk-xlnx-clock-wizard.c b/drivers/clk/xilinx/clk-xlnx-clock-wizard.c index bbf7714480e7..0295a13a811c 100644 --- a/drivers/clk/xilinx/clk-xlnx-clock-wizard.c +++ b/drivers/clk/xilinx/clk-xlnx-clock-wizard.c @@ -669,7 +669,7 @@ static long clk_wzrd_ver_round_rate_all(struct clk_hw *hw, unsigned long rate, u32 m, d, o, div, f; int err; - err = clk_wzrd_get_divisors(hw, rate, *prate); + err = clk_wzrd_get_divisors_ver(hw, rate, *prate); if (err) return err; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 312/480] crypto: qat - fix DMA direction for compression on GEN2 devices 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (310 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 311/480] clk: clocking-wizard: Fix the round rate handling for versal Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 313/480] crypto: qat - fix seq_file position update in adf_ring_next() Greg Kroah-Hartman ` (179 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Giovanni Cabiddu, Ahsan Atta, Herbert Xu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Giovanni Cabiddu <giovanni.cabiddu@intel.com> [ Upstream commit d41d75fe1b751ee6b347bf1cb1cfe9accc4fcb12 ] QAT devices perform an additional integrity check during compression by decompressing the output. Starting from QAT GEN4, this verification is done in-line by the hardware. However, on GEN2 devices, the hardware reads back the compressed output from the destination buffer and performs a decompression operation using it as the source. In the current QAT driver, destination buffers are always marked as write-only. This is incorrect for QAT GEN2 compression, where the buffer is also read during verification. Since commit 6f5dc7658094 ("iommu/vt-d: Restore WO permissions on second-level paging entries"), merged in v6.16-rc1, write-only permissions are strictly enforced, leading to DMAR errors when using QAT GEN2 devices for compression, if VT-d is enabled. Mark the destination buffers as DMA_BIDIRECTIONAL. This ensures compatibility with GEN2 devices, even though it is not required for QAT GEN4 and later. Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Fixes: cf5bb835b7c8 ("crypto: qat - fix DMA transfer direction") Reviewed-by: Ahsan Atta <ahsan.atta@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/crypto/intel/qat/qat_common/qat_bl.c | 6 +++--- drivers/crypto/intel/qat/qat_common/qat_compression.c | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/crypto/intel/qat/qat_common/qat_bl.c b/drivers/crypto/intel/qat/qat_common/qat_bl.c index 5e4dad4693ca..9b2338f58d97 100644 --- a/drivers/crypto/intel/qat/qat_common/qat_bl.c +++ b/drivers/crypto/intel/qat/qat_common/qat_bl.c @@ -38,7 +38,7 @@ void qat_bl_free_bufl(struct adf_accel_dev *accel_dev, for (i = 0; i < blout->num_mapped_bufs; i++) { dma_unmap_single(dev, blout->buffers[i].addr, blout->buffers[i].len, - DMA_FROM_DEVICE); + DMA_BIDIRECTIONAL); } dma_unmap_single(dev, blpout, sz_out, DMA_TO_DEVICE); @@ -162,7 +162,7 @@ static int __qat_bl_sgl_to_bufl(struct adf_accel_dev *accel_dev, } buffers[y].addr = dma_map_single(dev, sg_virt(sg) + left, sg->length - left, - DMA_FROM_DEVICE); + DMA_BIDIRECTIONAL); if (unlikely(dma_mapping_error(dev, buffers[y].addr))) goto err_out; buffers[y].len = sg->length; @@ -204,7 +204,7 @@ static int __qat_bl_sgl_to_bufl(struct adf_accel_dev *accel_dev, if (!dma_mapping_error(dev, buflout->buffers[i].addr)) dma_unmap_single(dev, buflout->buffers[i].addr, buflout->buffers[i].len, - DMA_FROM_DEVICE); + DMA_BIDIRECTIONAL); } if (!buf->sgl_dst_valid) diff --git a/drivers/crypto/intel/qat/qat_common/qat_compression.c b/drivers/crypto/intel/qat/qat_common/qat_compression.c index 2c3aa89b316a..cf94ba3011d5 100644 --- a/drivers/crypto/intel/qat/qat_common/qat_compression.c +++ b/drivers/crypto/intel/qat/qat_common/qat_compression.c @@ -205,7 +205,7 @@ static int qat_compression_alloc_dc_data(struct adf_accel_dev *accel_dev) if (!obuff) goto err; - obuff_p = dma_map_single(dev, obuff, ovf_buff_sz, DMA_FROM_DEVICE); + obuff_p = dma_map_single(dev, obuff, ovf_buff_sz, DMA_BIDIRECTIONAL); if (unlikely(dma_mapping_error(dev, obuff_p))) goto err; @@ -233,7 +233,7 @@ static void qat_free_dc_data(struct adf_accel_dev *accel_dev) return; dma_unmap_single(dev, dc_data->ovf_buff_p, dc_data->ovf_buff_sz, - DMA_FROM_DEVICE); + DMA_BIDIRECTIONAL); kfree_sensitive(dc_data->ovf_buff); kfree(dc_data); accel_dev->dc_data = NULL; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 313/480] crypto: qat - fix seq_file position update in adf_ring_next() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (311 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 312/480] crypto: qat - fix DMA direction for compression on GEN2 devices Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 314/480] fbdev: imxfb: Check fb_add_videomode to prevent null-ptr-deref Greg Kroah-Hartman ` (178 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Giovanni Cabiddu, Ahsan Atta, Herbert Xu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Giovanni Cabiddu <giovanni.cabiddu@intel.com> [ Upstream commit 6908c5f4f066a0412c3d9a6f543a09fa7d87824b ] The `adf_ring_next()` function in the QAT debug transport interface fails to correctly update the position index when reaching the end of the ring elements. This triggers the following kernel warning when reading ring files, such as /sys/kernel/debug/qat_c6xx_<D:B:D:F>/transport/bank_00/ring_00: [27725.022965] seq_file: buggy .next function adf_ring_next [intel_qat] did not update position index Ensure that the `*pos` index is incremented before returning NULL when after the last element in the ring is found, satisfying the seq_file API requirements and preventing the warning. Fixes: a672a9dc872e ("crypto: qat - Intel(R) QAT transport code") Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by: Ahsan Atta <ahsan.atta@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/crypto/intel/qat/qat_common/adf_transport_debug.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/crypto/intel/qat/qat_common/adf_transport_debug.c b/drivers/crypto/intel/qat/qat_common/adf_transport_debug.c index e2dd568b87b5..621b5d3dfcef 100644 --- a/drivers/crypto/intel/qat/qat_common/adf_transport_debug.c +++ b/drivers/crypto/intel/qat/qat_common/adf_transport_debug.c @@ -31,8 +31,10 @@ static void *adf_ring_next(struct seq_file *sfile, void *v, loff_t *pos) struct adf_etr_ring_data *ring = sfile->private; if (*pos >= (ADF_SIZE_TO_RING_SIZE_IN_BYTES(ring->ring_size) / - ADF_MSG_SIZE_TO_BYTES(ring->msg_size))) + ADF_MSG_SIZE_TO_BYTES(ring->msg_size))) { + (*pos)++; return NULL; + } return ring->base_addr + (ADF_MSG_SIZE_TO_BYTES(ring->msg_size) * (*pos)++); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 314/480] fbdev: imxfb: Check fb_add_videomode to prevent null-ptr-deref 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (312 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 313/480] crypto: qat - fix seq_file position update in adf_ring_next() Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 315/480] smb: client: allow parsing zero-length AV pairs Greg Kroah-Hartman ` (177 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Chenyuan Yang, Helge Deller, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Chenyuan Yang <chenyuan0y@gmail.com> [ Upstream commit da11e6a30e0bb8e911288bdc443b3dc8f6a7cac7 ] fb_add_videomode() can fail with -ENOMEM when its internal kmalloc() cannot allocate a struct fb_modelist. If that happens, the modelist stays empty but the driver continues to register. Add a check for its return value to prevent poteintial null-ptr-deref, which is similar to the commit 17186f1f90d3 ("fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var"). Fixes: 1b6c79361ba5 ("video: imxfb: Add DT support") Signed-off-by: Chenyuan Yang <chenyuan0y@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/video/fbdev/imxfb.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/video/fbdev/imxfb.c b/drivers/video/fbdev/imxfb.c index f30da32cdaed..a077bf346bdf 100644 --- a/drivers/video/fbdev/imxfb.c +++ b/drivers/video/fbdev/imxfb.c @@ -996,8 +996,13 @@ static int imxfb_probe(struct platform_device *pdev) info->fix.smem_start = fbi->map_dma; INIT_LIST_HEAD(&info->modelist); - for (i = 0; i < fbi->num_modes; i++) - fb_add_videomode(&fbi->mode[i].mode, &info->modelist); + for (i = 0; i < fbi->num_modes; i++) { + ret = fb_add_videomode(&fbi->mode[i].mode, &info->modelist); + if (ret) { + dev_err(&pdev->dev, "Failed to add videomode\n"); + goto failed_cmap; + } + } /* * This makes sure that our colour bitfield -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 315/480] smb: client: allow parsing zero-length AV pairs 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (313 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 314/480] fbdev: imxfb: Check fb_add_videomode to prevent null-ptr-deref Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 316/480] jfs: fix metapage reference count leak in dbAllocCtl Greg Kroah-Hartman ` (176 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, linux-cifs, David Howells, Paulo Alcantara (Red Hat), Steve French, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Paulo Alcantara <pc@manguebit.org> [ Upstream commit be77ab6b9fbe348daf3c2d3ee40f23ca5110a339 ] Zero-length AV pairs should be considered as valid target infos. Don't skip the next AV pairs that follow them. Cc: linux-cifs@vger.kernel.org Cc: David Howells <dhowells@redhat.com> Fixes: 0e8ae9b953bc ("smb: client: parse av pair type 4 in CHALLENGE_MESSAGE") Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/smb/client/cifsencrypt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/smb/client/cifsencrypt.c b/fs/smb/client/cifsencrypt.c index 35892df7335c..6be850d2a346 100644 --- a/fs/smb/client/cifsencrypt.c +++ b/fs/smb/client/cifsencrypt.c @@ -343,7 +343,7 @@ static struct ntlmssp2_name *find_next_av(struct cifs_ses *ses, len = AV_LEN(av); if (AV_TYPE(av) == NTLMSSP_AV_EOL) return NULL; - if (!len || (u8 *)av + sizeof(*av) + len > end) + if ((u8 *)av + sizeof(*av) + len > end) return NULL; return av; } @@ -363,7 +363,7 @@ static int find_av_name(struct cifs_ses *ses, u16 type, char **name, u16 maxlen) av_for_each_entry(ses, av) { len = AV_LEN(av); - if (AV_TYPE(av) != type) + if (AV_TYPE(av) != type || !len) continue; if (!IS_ALIGNED(len, sizeof(__le16))) { cifs_dbg(VFS | ONCE, "%s: bad length(%u) for type %u\n", -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 316/480] jfs: fix metapage reference count leak in dbAllocCtl 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (314 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 315/480] smb: client: allow parsing zero-length AV pairs Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 317/480] mtd: rawnand: atmel: Fix dma_mapping_error() address Greg Kroah-Hartman ` (175 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Zheng Yu, Dave Kleikamp, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Zheng Yu <zheng.yu@northwestern.edu> [ Upstream commit 856db37592021e9155384094e331e2d4589f28b1 ] In dbAllocCtl(), read_metapage() increases the reference count of the metapage. However, when dp->tree.budmin < 0, the function returns -EIO without calling release_metapage() to decrease the reference count, leading to a memory leak. Add release_metapage(mp) before the error return to properly manage the metapage reference count and prevent the leak. Fixes: a5f5e4698f8abbb25fe4959814093fb5bfa1aa9d ("jfs: fix shift-out-of-bounds in dbSplit") Signed-off-by: Zheng Yu <zheng.yu@northwestern.edu> Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/jfs/jfs_dmap.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c index 35e063c9f3a4..5a877261c3fe 100644 --- a/fs/jfs/jfs_dmap.c +++ b/fs/jfs/jfs_dmap.c @@ -1809,8 +1809,10 @@ dbAllocCtl(struct bmap * bmp, s64 nblocks, int l2nb, s64 blkno, s64 * results) return -EIO; dp = (struct dmap *) mp->data; - if (dp->tree.budmin < 0) + if (dp->tree.budmin < 0) { + release_metapage(mp); return -EIO; + } /* try to allocate the blocks. */ -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 317/480] mtd: rawnand: atmel: Fix dma_mapping_error() address 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (315 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 316/480] jfs: fix metapage reference count leak in dbAllocCtl Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 318/480] mtd: rawnand: rockchip: Add missing check after DMA map Greg Kroah-Hartman ` (174 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Thomas Fourier, Miquel Raynal, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Fourier <fourier.thomas@gmail.com> [ Upstream commit e1e6b933c56b1e9fda93caa0b8bae39f3f421e5c ] It seems like what was intended is to test if the dma_map of the previous line failed but the wrong dma address was passed. Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver") Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Rule: add Link: https://lore.kernel.org/stable/20250702064515.18145-2-fourier.thomas%40gmail.com Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/mtd/nand/raw/atmel/nand-controller.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c index dedcca87defc..84ab4a83cbd6 100644 --- a/drivers/mtd/nand/raw/atmel/nand-controller.c +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c @@ -373,7 +373,7 @@ static int atmel_nand_dma_transfer(struct atmel_nand_controller *nc, dma_cookie_t cookie; buf_dma = dma_map_single(nc->dev, buf, len, dir); - if (dma_mapping_error(nc->dev, dev_dma)) { + if (dma_mapping_error(nc->dev, buf_dma)) { dev_err(nc->dev, "Failed to prepare a buffer for DMA access\n"); goto err; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 318/480] mtd: rawnand: rockchip: Add missing check after DMA map 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (316 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 317/480] mtd: rawnand: atmel: Fix dma_mapping_error() address Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 319/480] mtd: rawnand: atmel: set pmecc data setup time Greg Kroah-Hartman ` (173 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Thomas Fourier, Miquel Raynal, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Fourier <fourier.thomas@gmail.com> [ Upstream commit 3b36f86dc47261828f96f826077131a35dd825fd ] The DMA map functions can fail and should be tested for errors. Fixes: 058e0e847d54 ("mtd: rawnand: rockchip: NFC driver for RK3308, RK2928 and others") Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/mtd/nand/raw/rockchip-nand-controller.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/drivers/mtd/nand/raw/rockchip-nand-controller.c b/drivers/mtd/nand/raw/rockchip-nand-controller.c index 63e7b9e39a5a..c5d7cd8a6cab 100644 --- a/drivers/mtd/nand/raw/rockchip-nand-controller.c +++ b/drivers/mtd/nand/raw/rockchip-nand-controller.c @@ -656,9 +656,16 @@ static int rk_nfc_write_page_hwecc(struct nand_chip *chip, const u8 *buf, dma_data = dma_map_single(nfc->dev, (void *)nfc->page_buf, mtd->writesize, DMA_TO_DEVICE); + if (dma_mapping_error(nfc->dev, dma_data)) + return -ENOMEM; + dma_oob = dma_map_single(nfc->dev, nfc->oob_buf, ecc->steps * oob_step, DMA_TO_DEVICE); + if (dma_mapping_error(nfc->dev, dma_oob)) { + dma_unmap_single(nfc->dev, dma_data, mtd->writesize, DMA_TO_DEVICE); + return -ENOMEM; + } reinit_completion(&nfc->done); writel(INT_DMA, nfc->regs + nfc->cfg->int_en_off); @@ -772,9 +779,17 @@ static int rk_nfc_read_page_hwecc(struct nand_chip *chip, u8 *buf, int oob_on, dma_data = dma_map_single(nfc->dev, nfc->page_buf, mtd->writesize, DMA_FROM_DEVICE); + if (dma_mapping_error(nfc->dev, dma_data)) + return -ENOMEM; + dma_oob = dma_map_single(nfc->dev, nfc->oob_buf, ecc->steps * oob_step, DMA_FROM_DEVICE); + if (dma_mapping_error(nfc->dev, dma_oob)) { + dma_unmap_single(nfc->dev, dma_data, mtd->writesize, + DMA_FROM_DEVICE); + return -ENOMEM; + } /* * The first blocks (4, 8 or 16 depending on the device) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 319/480] mtd: rawnand: atmel: set pmecc data setup time 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (317 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 318/480] mtd: rawnand: rockchip: Add missing check after DMA map Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 320/480] drm/xe/vf: Disable CSC support on VF Greg Kroah-Hartman ` (172 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Zixun LI, Ada Couprie Diaz, Balamanikandan Gunasundar, Miquel Raynal, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com> [ Upstream commit f552a7c7e0a14215cb8a6fd89e60fa3932a74786 ] Setup the pmecc data setup time as 3 clock cycles for 133MHz as recommended by the datasheet. Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver") Reported-by: Zixun LI <admin@hifiphile.com> Closes: https://lore.kernel.org/all/c015bb20-6a57-4f63-8102-34b3d83e0f5b@microchip.com Suggested-by: Ada Couprie Diaz <ada.coupriediaz@arm.com> Signed-off-by: Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/mtd/nand/raw/atmel/pmecc.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/mtd/nand/raw/atmel/pmecc.c b/drivers/mtd/nand/raw/atmel/pmecc.c index 3c7dee1be21d..0b402823b619 100644 --- a/drivers/mtd/nand/raw/atmel/pmecc.c +++ b/drivers/mtd/nand/raw/atmel/pmecc.c @@ -143,6 +143,7 @@ struct atmel_pmecc_caps { int nstrengths; int el_offset; bool correct_erased_chunks; + bool clk_ctrl; }; struct atmel_pmecc { @@ -843,6 +844,10 @@ static struct atmel_pmecc *atmel_pmecc_create(struct platform_device *pdev, if (IS_ERR(pmecc->regs.errloc)) return ERR_CAST(pmecc->regs.errloc); + /* pmecc data setup time */ + if (caps->clk_ctrl) + writel(PMECC_CLK_133MHZ, pmecc->regs.base + ATMEL_PMECC_CLK); + /* Disable all interrupts before registering the PMECC handler. */ writel(0xffffffff, pmecc->regs.base + ATMEL_PMECC_IDR); atmel_pmecc_reset(pmecc); @@ -896,6 +901,7 @@ static struct atmel_pmecc_caps at91sam9g45_caps = { .strengths = atmel_pmecc_strengths, .nstrengths = 5, .el_offset = 0x8c, + .clk_ctrl = true, }; static struct atmel_pmecc_caps sama5d4_caps = { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 320/480] drm/xe/vf: Disable CSC support on VF 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (318 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 319/480] mtd: rawnand: atmel: set pmecc data setup time Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 321/480] selftests: ALSA: fix memory leak in utimer test Greg Kroah-Hartman ` (171 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Lukasz Laguna, Alexander Usyskin, Michal Wajdeczko, Rodrigo Vivi, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Lukasz Laguna <lukasz.laguna@intel.com> [ Upstream commit f62408efc8669b82541295a4611494c8c8c52684 ] CSC is not accessible by VF drivers, so disable its support flag on VF to prevent further initialization attempts. Fixes: e02cea83d32d ("drm/xe/gsc: add Battlemage support") Signed-off-by: Lukasz Laguna <lukasz.laguna@intel.com> Cc: Alexander Usyskin <alexander.usyskin@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20250729123437.5933-1-lukasz.laguna@intel.com (cherry picked from commit 552dbba1caaf0cb40ce961806d757615e26ec668) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/gpu/drm/xe/xe_device.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c index f3123914b1ab..258c9616de19 100644 --- a/drivers/gpu/drm/xe/xe_device.c +++ b/drivers/gpu/drm/xe/xe_device.c @@ -678,6 +678,7 @@ static void sriov_update_device_info(struct xe_device *xe) /* disable features that are not available/applicable to VFs */ if (IS_SRIOV_VF(xe)) { xe->info.probe_display = 0; + xe->info.has_heci_cscfi = 0; xe->info.has_heci_gscfi = 0; xe->info.skip_guc_pc = 1; xe->info.skip_pcode = 1; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 321/480] selftests: ALSA: fix memory leak in utimer test 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (319 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 320/480] drm/xe/vf: Disable CSC support on VF Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 322/480] ALSA: usb: scarlett2: Fix missing NULL check Greg Kroah-Hartman ` (170 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Jun Zhan, WangYuli, Takashi Iwai, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: WangYuli <wangyuli@uniontech.com> [ Upstream commit 6260da046819b7bda828bacae148fc8856fdebd7 ] Free the malloc'd buffer in TEST_F(timer_f, utimer) to prevent memory leak. Fixes: 1026392d10af ("selftests: ALSA: Cover userspace-driven timers with test") Reported-by: Jun Zhan <zhanjun@uniontech.com> Signed-off-by: WangYuli <wangyuli@uniontech.com> Link: https://patch.msgid.link/DE4D931FCF54F3DB+20250731100222.65748-1-wangyuli@uniontech.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/testing/selftests/alsa/utimer-test.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/alsa/utimer-test.c b/tools/testing/selftests/alsa/utimer-test.c index 32ee3ce57721..37964f311a33 100644 --- a/tools/testing/selftests/alsa/utimer-test.c +++ b/tools/testing/selftests/alsa/utimer-test.c @@ -135,6 +135,7 @@ TEST_F(timer_f, utimer) { pthread_join(ticking_thread, NULL); ASSERT_EQ(total_ticks, TICKS_COUNT); pclose(rfp); + free(buf); } TEST(wrong_timers_test) { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 322/480] ALSA: usb: scarlett2: Fix missing NULL check 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (320 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 321/480] selftests: ALSA: fix memory leak in utimer test Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 323/480] perf record: Cache build-ID of hit DSOs only Greg Kroah-Hartman ` (169 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Takashi Iwai, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Takashi Iwai <tiwai@suse.de> [ Upstream commit df485a4b2b3ee5b35c80f990beb554e38a8a5fb1 ] scarlett2_input_select_ctl_info() sets up the string arrays allocated via kasprintf(), but it misses NULL checks, which may lead to NULL dereference Oops. Let's add the proper NULL check. Fixes: 8eba063b5b2b ("ALSA: scarlett2: Simplify linked channel handling") Link: https://patch.msgid.link/20250731053714.29414-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org> --- sound/usb/mixer_scarlett2.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/sound/usb/mixer_scarlett2.c b/sound/usb/mixer_scarlett2.c index 288d22e6a0b2..5d47502c2858 100644 --- a/sound/usb/mixer_scarlett2.c +++ b/sound/usb/mixer_scarlett2.c @@ -3971,8 +3971,13 @@ static int scarlett2_input_select_ctl_info( goto unlock; /* Loop through each input */ - for (i = 0; i < inputs; i++) + for (i = 0; i < inputs; i++) { values[i] = kasprintf(GFP_KERNEL, "Input %d", i + 1); + if (!values[i]) { + err = -ENOMEM; + goto unlock; + } + } err = snd_ctl_enum_info(uinfo, 1, i, (const char * const *)values); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 323/480] perf record: Cache build-ID of hit DSOs only 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (321 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 322/480] ALSA: usb: scarlett2: Fix missing NULL check Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 324/480] vdpa/mlx5: Fix needs_teardown flag calculation Greg Kroah-Hartman ` (168 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Arnaldo Carvalho de Melo, Namhyung Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Namhyung Kim <namhyung@kernel.org> [ Upstream commit 6235ce77749f45cac27f630337e2fdf04e8a6c73 ] It post-processes samples to find which DSO has samples. Based on that info, it can save used DSOs in the build-ID cache directory. But for some reason, it saves all DSOs without checking the hit mark. Skipping unused DSOs can give some speedup especially with --buildid-mmap being default. On my idle machine, `time perf record -a sleep 1` goes down from 3 sec to 1.5 sec with this change. Fixes: e29386c8f7d71fa5 ("perf record: Add --buildid-mmap option to enable PERF_RECORD_MMAP2's build id") Reviewed-by: Arnaldo Carvalho de Melo <acme@redhat.com> Link: https://lore.kernel.org/r/20250731070330.57116-1-namhyung@kernel.org Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/perf/util/build-id.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/build-id.c b/tools/perf/util/build-id.c index e763e8d99a43..ee00313d5d7e 100644 --- a/tools/perf/util/build-id.c +++ b/tools/perf/util/build-id.c @@ -864,7 +864,7 @@ static int dso__cache_build_id(struct dso *dso, struct machine *machine, char *allocated_name = NULL; int ret = 0; - if (!dso__has_build_id(dso)) + if (!dso__has_build_id(dso) || !dso__hit(dso)) return 0; if (dso__is_kcore(dso)) { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 324/480] vdpa/mlx5: Fix needs_teardown flag calculation 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (322 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 323/480] perf record: Cache build-ID of hit DSOs only Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 325/480] vhost-scsi: Fix log flooding with target does not exist errors Greg Kroah-Hartman ` (167 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Dragos Tatulea, Shahar Shitrit, Si-Wei Liu, Michael S. Tsirkin, Jason Wang, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Dragos Tatulea <dtatulea@nvidia.com> [ Upstream commit 6f0f3d7fc4e05797b801ded4910a64d16db230e9 ] needs_teardown is a device flag that indicates when virtual queues need to be recreated. This happens for certain configuration changes: queue size and some specific features. Currently, the needs_teardown state can be incorrectly reset by subsequent .set_vq_num() calls. For example, for 1 rx VQ with size 512 and 1 tx VQ with size 256: .set_vq_num(0, 512) -> sets needs_teardown to true (rx queue has a non-default size) .set_vq_num(1, 256) -> sets needs_teardown to false (tx queue has a default size) This change takes into account the previous value of the needs_teardown flag when re-calculating it during VQ size configuration. Fixes: 0fe963d6fc16 ("vdpa/mlx5: Re-create HW VQs under certain conditions") Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Shahar Shitrit <shshitrit@nvidia.com> Reviewed-by: Si-Wei Liu <si-wei.liu@oracle.com> Tested-by: Si-Wei Liu<si-wei.liu@oracle.com> Message-Id: <20250604184802.2625300-1-dtatulea@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c index cccc49a08a1a..efb5fa694f1e 100644 --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c @@ -2491,7 +2491,7 @@ static void mlx5_vdpa_set_vq_num(struct vdpa_device *vdev, u16 idx, u32 num) } mvq = &ndev->vqs[idx]; - ndev->needs_teardown = num != mvq->num_ent; + ndev->needs_teardown |= num != mvq->num_ent; mvq->num_ent = num; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 325/480] vhost-scsi: Fix log flooding with target does not exist errors 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (323 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 324/480] vdpa/mlx5: Fix needs_teardown flag calculation Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 326/480] vhost-scsi: Fix check for inline_sg_cnt exceeding preallocated limit Greg Kroah-Hartman ` (166 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Mike Christie, Stefan Hajnoczi, Stefano Garzarella, Michael S. Tsirkin, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Mike Christie <michael.christie@oracle.com> [ Upstream commit 69cd720a8a5e9ef0f05ce5dd8c9ea6e018245c82 ] As part of the normal initiator side scanning the guest's scsi layer will loop over all possible targets and send an inquiry. Since the max number of targets for virtio-scsi is 256, this can result in 255 error messages about targets not existing if you only have a single target. When there's more than 1 vhost-scsi device each with a single target, then you get N * 255 log messages. It looks like the log message was added by accident in: commit 3f8ca2e115e5 ("vhost/scsi: Extract common handling code from control queue handler") when we added common helpers. Then in: commit 09d7583294aa ("vhost/scsi: Use common handling code in request queue handler") we converted the scsi command processing path to use the new helpers so we started to see the extra log messages during scanning. The patches were just making some code common but added the vq_err call and I'm guessing the patch author forgot to enable the vq_err call (vq_err is implemented by pr_debug which defaults to off). So this patch removes the call since it's expected to hit this path during device discovery. Fixes: 09d7583294aa ("vhost/scsi: Use common handling code in request queue handler") Signed-off-by: Mike Christie <michael.christie@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Message-Id: <20250611210113.10912-1-michael.christie@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/vhost/scsi.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c index 26bcf3a7f70c..5b112de79f27 100644 --- a/drivers/vhost/scsi.c +++ b/drivers/vhost/scsi.c @@ -1148,10 +1148,8 @@ vhost_scsi_get_req(struct vhost_virtqueue *vq, struct vhost_scsi_ctx *vc, /* validated at handler entry */ vs_tpg = vhost_vq_get_backend(vq); tpg = READ_ONCE(vs_tpg[*vc->target]); - if (unlikely(!tpg)) { - vq_err(vq, "Target 0x%x does not exist\n", *vc->target); + if (unlikely(!tpg)) goto out; - } } if (tpgp) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 326/480] vhost-scsi: Fix check for inline_sg_cnt exceeding preallocated limit 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (324 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 325/480] vhost-scsi: Fix log flooding with target does not exist errors Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 327/480] vdpa/mlx5: Fix release of uninitialized resources on error path Greg Kroah-Hartman ` (165 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Alok Tiwari, Mike Christie, Stefan Hajnoczi, Michael S. Tsirkin, Jason Wang, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Alok Tiwari <alok.a.tiwari@oracle.com> [ Upstream commit 400cad513c78f9af72c5a20f3611c1f1dc71d465 ] The condition comparing ret to VHOST_SCSI_PREALLOC_SGLS was incorrect, as ret holds the result of kstrtouint() (typically 0 on success), not the parsed value. Update the check to use cnt, which contains the actual user-provided value. prevents silently accepting values exceeding the maximum inline_sg_cnt. Fixes: bca939d5bcd0 ("vhost-scsi: Dynamically allocate scatterlists") Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Reviewed-by: Mike Christie <michael.christie@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20250628183405.3979538-1-alok.a.tiwari@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/vhost/scsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c index 5b112de79f27..d3b8355f7953 100644 --- a/drivers/vhost/scsi.c +++ b/drivers/vhost/scsi.c @@ -71,7 +71,7 @@ static int vhost_scsi_set_inline_sg_cnt(const char *buf, if (ret) return ret; - if (ret > VHOST_SCSI_PREALLOC_SGLS) { + if (cnt > VHOST_SCSI_PREALLOC_SGLS) { pr_err("Max inline_sg_cnt is %u\n", VHOST_SCSI_PREALLOC_SGLS); return -EINVAL; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 327/480] vdpa/mlx5: Fix release of uninitialized resources on error path 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (325 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 326/480] vhost-scsi: Fix check for inline_sg_cnt exceeding preallocated limit Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 328/480] vdpa: Fix IDR memory leak in VDUSE module exit Greg Kroah-Hartman ` (164 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Dragos Tatulea, Wenli Quan, Tariq Toukan, Cosmin Ratiu, Jason Wang, Michael S. Tsirkin, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Dragos Tatulea <dtatulea@nvidia.com> [ Upstream commit cc51a66815999afb7e9cd845968de4fdf07567b7 ] The commit in the fixes tag made sure that mlx5_vdpa_free() is the single entrypoint for removing the vdpa device resources added in mlx5_vdpa_dev_add(), even in the cleanup path of mlx5_vdpa_dev_add(). This means that all functions from mlx5_vdpa_free() should be able to handle uninitialized resources. This was not the case though: mlx5_vdpa_destroy_mr_resources() and mlx5_cmd_cleanup_async_ctx() were not able to do so. This caused the splat below when adding a vdpa device without a MAC address. This patch fixes these remaining issues: - Makes mlx5_vdpa_destroy_mr_resources() return early if called on uninitialized resources. - Moves mlx5_cmd_init_async_ctx() early on during device addition because it can't fail. This means that mlx5_cmd_cleanup_async_ctx() also can't fail. To mirror this, move the call site of mlx5_cmd_cleanup_async_ctx() in mlx5_vdpa_free(). An additional comment was added in mlx5_vdpa_free() to document the expectations of functions called from this context. Splat: mlx5_core 0000:b5:03.2: mlx5_vdpa_dev_add:3950:(pid 2306) warning: No mac address provisioned? ------------[ cut here ]------------ WARNING: CPU: 13 PID: 2306 at kernel/workqueue.c:4207 __flush_work+0x9a/0xb0 [...] Call Trace: <TASK> ? __try_to_del_timer_sync+0x61/0x90 ? __timer_delete_sync+0x2b/0x40 mlx5_vdpa_destroy_mr_resources+0x1c/0x40 [mlx5_vdpa] mlx5_vdpa_free+0x45/0x160 [mlx5_vdpa] vdpa_release_dev+0x1e/0x50 [vdpa] device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x327/0x890 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x2c1/0x4d0 [vdpa] genl_family_rcv_msg_doit+0xd8/0x130 genl_family_rcv_msg+0x14b/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa] genl_rcv_msg+0x47/0xa0 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x27b/0x3b0 netlink_sendmsg+0x1f7/0x430 __sys_sendto+0x1fa/0x210 ? ___pte_offset_map+0x17/0x160 ? next_uptodate_folio+0x85/0x2b0 ? percpu_counter_add_batch+0x51/0x90 ? filemap_map_pages+0x515/0x660 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x7b/0x2c0 ? do_read_fault+0x108/0x220 ? do_pte_missing+0x14a/0x3e0 ? __handle_mm_fault+0x321/0x730 ? count_memcg_events+0x13f/0x180 ? handle_mm_fault+0x1fb/0x2d0 ? do_user_addr_fault+0x20c/0x700 ? syscall_exit_work+0x104/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0c25b0feca [...] ---[ end trace 0000000000000000 ]--- Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Fixes: 83e445e64f48 ("vdpa/mlx5: Fix error path during device add") Reported-by: Wenli Quan <wquan@redhat.com> Closes: https://lore.kernel.org/virtualization/CADZSLS0r78HhZAStBaN1evCSoPqRJU95Lt8AqZNJ6+wwYQ6vPQ@mail.gmail.com/ Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Message-Id: <20250708120424.2363354-2-dtatulea@nvidia.com> Tested-by: Wenli Quan <wquan@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/vdpa/mlx5/core/mr.c | 3 +++ drivers/vdpa/mlx5/net/mlx5_vnet.c | 10 ++++++---- 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c index 61424342c096..c7a20278bc3c 100644 --- a/drivers/vdpa/mlx5/core/mr.c +++ b/drivers/vdpa/mlx5/core/mr.c @@ -908,6 +908,9 @@ void mlx5_vdpa_destroy_mr_resources(struct mlx5_vdpa_dev *mvdev) { struct mlx5_vdpa_mr_resources *mres = &mvdev->mres; + if (!mres->wq_gc) + return; + atomic_set(&mres->shutdown, 1); flush_delayed_work(&mres->gc_dwork_ent); diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c index efb5fa694f1e..0ed2fc28e1ce 100644 --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c @@ -3432,15 +3432,17 @@ static void mlx5_vdpa_free(struct vdpa_device *vdev) ndev = to_mlx5_vdpa_ndev(mvdev); + /* Functions called here should be able to work with + * uninitialized resources. + */ free_fixed_resources(ndev); mlx5_vdpa_clean_mrs(mvdev); mlx5_vdpa_destroy_mr_resources(&ndev->mvdev); - mlx5_cmd_cleanup_async_ctx(&mvdev->async_ctx); - if (!is_zero_ether_addr(ndev->config.mac)) { pfmdev = pci_get_drvdata(pci_physfn(mvdev->mdev->pdev)); mlx5_mpfs_del_mac(pfmdev, ndev->config.mac); } + mlx5_cmd_cleanup_async_ctx(&mvdev->async_ctx); mlx5_vdpa_free_resources(&ndev->mvdev); free_irqs(ndev); kfree(ndev->event_cbs); @@ -3888,6 +3890,8 @@ static int mlx5_vdpa_dev_add(struct vdpa_mgmt_dev *v_mdev, const char *name, mvdev->actual_features = (device_features & BIT_ULL(VIRTIO_F_VERSION_1)); + mlx5_cmd_init_async_ctx(mdev, &mvdev->async_ctx); + ndev->vqs = kcalloc(max_vqs, sizeof(*ndev->vqs), GFP_KERNEL); ndev->event_cbs = kcalloc(max_vqs + 1, sizeof(*ndev->event_cbs), GFP_KERNEL); if (!ndev->vqs || !ndev->event_cbs) { @@ -3960,8 +3964,6 @@ static int mlx5_vdpa_dev_add(struct vdpa_mgmt_dev *v_mdev, const char *name, ndev->rqt_size = 1; } - mlx5_cmd_init_async_ctx(mdev, &mvdev->async_ctx); - ndev->mvdev.mlx_features = device_features; mvdev->vdev.dma_dev = &mdev->pdev->dev; err = mlx5_vdpa_alloc_resources(&ndev->mvdev); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 328/480] vdpa: Fix IDR memory leak in VDUSE module exit 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (326 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 327/480] vdpa/mlx5: Fix release of uninitialized resources on error path Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 329/480] vhost: Reintroduce kthread API and add mode selection Greg Kroah-Hartman ` (163 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Anders Roxell, Michael S. Tsirkin, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Anders Roxell <anders.roxell@linaro.org> [ Upstream commit d9ea58b5dc6b4b50fbb6a10c73f840e8b10442b7 ] Add missing idr_destroy() call in vduse_exit() to properly free the vduse_idr radix tree nodes. Without this, module load/unload cycles leak 576-byte radix tree node allocations, detectable by kmemleak as: unreferenced object (size 576): backtrace: [<ffffffff81234567>] radix_tree_node_alloc+0xa0/0xf0 [<ffffffff81234568>] idr_get_free+0x128/0x280 The vduse_idr is initialized via DEFINE_IDR() at line 136 and used throughout the VDUSE (vDPA Device in Userspace) driver for device ID management. The fix follows the documented pattern in lib/idr.c and matches the cleanup approach used by other drivers. This leak was discovered through comprehensive module testing with cumulative kmemleak detection across 10 load/unload iterations per module. Fixes: c8a6153b6c59 ("vduse: Introduce VDUSE - vDPA Device in Userspace") Signed-off-by: Anders Roxell <anders.roxell@linaro.org> Message-Id: <20250704125335.1084649-1-anders.roxell@linaro.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/vdpa/vdpa_user/vduse_dev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c index 6a9a37351310..04620bb77203 100644 --- a/drivers/vdpa/vdpa_user/vduse_dev.c +++ b/drivers/vdpa/vdpa_user/vduse_dev.c @@ -2216,6 +2216,7 @@ static void vduse_exit(void) cdev_del(&vduse_ctrl_cdev); unregister_chrdev_region(vduse_major, VDUSE_DEV_MAX); class_unregister(&vduse_class); + idr_destroy(&vduse_idr); } module_exit(vduse_exit); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 329/480] vhost: Reintroduce kthread API and add mode selection 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (327 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 328/480] vdpa: Fix IDR memory leak in VDUSE module exit Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 330/480] bpf: Check flow_dissector ctx accesses are aligned Greg Kroah-Hartman ` (162 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Cindy Lu, Michael S. Tsirkin, Jason Wang, Lei Yang, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Cindy Lu <lulu@redhat.com> [ Upstream commit 7d9896e9f6d02d8aa85e63f736871f96c59a5263 ] Since commit 6e890c5d5021 ("vhost: use vhost_tasks for worker threads"), the vhost uses vhost_task and operates as a child of the owner thread. This is required for correct CPU usage accounting, especially when using containers. However, this change has caused confusion for some legacy userspace applications, and we didn't notice until it's too late. Unfortunately, it's too late to revert - we now have userspace depending both on old and new behaviour :( To address the issue, reintroduce kthread mode for vhost workers and provide a configuration to select between kthread and task worker. - Add 'fork_owner' parameter to vhost_dev to let users select kthread or task mode. Default mode is task mode(VHOST_FORK_OWNER_TASK). - Reintroduce kthread mode support: * Bring back the original vhost_worker() implementation, and renamed to vhost_run_work_kthread_list(). * Add cgroup support for the kthread * Introduce struct vhost_worker_ops: - Encapsulates create / stop / wake‑up callbacks. - vhost_worker_create() selects the proper ops according to inherit_owner. - Userspace configuration interface: * New IOCTLs: - VHOST_SET_FORK_FROM_OWNER lets userspace select task mode (VHOST_FORK_OWNER_TASK) or kthread mode (VHOST_FORK_OWNER_KTHREAD) - VHOST_GET_FORK_FROM_OWNER reads the current worker mode * Expose module parameter 'fork_from_owner_default' to allow system administrators to configure the default mode for vhost workers * Kconfig option CONFIG_VHOST_ENABLE_FORK_OWNER_CONTROL controls whether these IOCTLs and the parameter are available - The VHOST_NEW_WORKER functionality requires fork_owner to be set to true, with validation added to ensure proper configuration This partially reverts or improves upon: commit 6e890c5d5021 ("vhost: use vhost_tasks for worker threads") commit 1cdaafa1b8b4 ("vhost: replace single worker pointer with xarray") Fixes: 6e890c5d5021 ("vhost: use vhost_tasks for worker threads"), Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20250714071333.59794-2-lulu@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/vhost/Kconfig | 18 +++ drivers/vhost/vhost.c | 244 ++++++++++++++++++++++++++++++++++--- drivers/vhost/vhost.h | 22 ++++ include/uapi/linux/vhost.h | 29 +++++ 4 files changed, 295 insertions(+), 18 deletions(-) diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig index 020d4fbb947c..bc0f38574497 100644 --- a/drivers/vhost/Kconfig +++ b/drivers/vhost/Kconfig @@ -95,4 +95,22 @@ config VHOST_CROSS_ENDIAN_LEGACY If unsure, say "N". +config VHOST_ENABLE_FORK_OWNER_CONTROL + bool "Enable VHOST_ENABLE_FORK_OWNER_CONTROL" + default y + help + This option enables two IOCTLs: VHOST_SET_FORK_FROM_OWNER and + VHOST_GET_FORK_FROM_OWNER. These allow userspace applications + to modify the vhost worker mode for vhost devices. + + Also expose module parameter 'fork_from_owner_default' to allow users + to configure the default mode for vhost workers. + + By default, `VHOST_ENABLE_FORK_OWNER_CONTROL` is set to `y`, + users can change the worker thread mode as needed. + If this config is disabled (n),the related IOCTLs and parameters will + be unavailable. + + If unsure, say "Y". + endif diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index 63612faeab72..79b0b7cd2860 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -22,6 +22,7 @@ #include <linux/slab.h> #include <linux/vmalloc.h> #include <linux/kthread.h> +#include <linux/cgroup.h> #include <linux/module.h> #include <linux/sort.h> #include <linux/sched/mm.h> @@ -41,6 +42,13 @@ static int max_iotlb_entries = 2048; module_param(max_iotlb_entries, int, 0444); MODULE_PARM_DESC(max_iotlb_entries, "Maximum number of iotlb entries. (default: 2048)"); +static bool fork_from_owner_default = VHOST_FORK_OWNER_TASK; + +#ifdef CONFIG_VHOST_ENABLE_FORK_OWNER_CONTROL +module_param(fork_from_owner_default, bool, 0444); +MODULE_PARM_DESC(fork_from_owner_default, + "Set task mode as the default(default: Y)"); +#endif enum { VHOST_MEMORY_F_LOG = 0x1, @@ -242,7 +250,7 @@ static void vhost_worker_queue(struct vhost_worker *worker, * test_and_set_bit() implies a memory barrier. */ llist_add(&work->node, &worker->work_list); - vhost_task_wake(worker->vtsk); + worker->ops->wakeup(worker); } } @@ -388,6 +396,44 @@ static void vhost_vq_reset(struct vhost_dev *dev, __vhost_vq_meta_reset(vq); } +static int vhost_run_work_kthread_list(void *data) +{ + struct vhost_worker *worker = data; + struct vhost_work *work, *work_next; + struct vhost_dev *dev = worker->dev; + struct llist_node *node; + + kthread_use_mm(dev->mm); + + for (;;) { + /* mb paired w/ kthread_stop */ + set_current_state(TASK_INTERRUPTIBLE); + + if (kthread_should_stop()) { + __set_current_state(TASK_RUNNING); + break; + } + node = llist_del_all(&worker->work_list); + if (!node) + schedule(); + + node = llist_reverse_order(node); + /* make sure flag is seen after deletion */ + smp_wmb(); + llist_for_each_entry_safe(work, work_next, node, node) { + clear_bit(VHOST_WORK_QUEUED, &work->flags); + __set_current_state(TASK_RUNNING); + kcov_remote_start_common(worker->kcov_handle); + work->fn(work); + kcov_remote_stop(); + cond_resched(); + } + } + kthread_unuse_mm(dev->mm); + + return 0; +} + static bool vhost_run_work_list(void *data) { struct vhost_worker *worker = data; @@ -552,6 +598,7 @@ void vhost_dev_init(struct vhost_dev *dev, dev->byte_weight = byte_weight; dev->use_worker = use_worker; dev->msg_handler = msg_handler; + dev->fork_owner = fork_from_owner_default; init_waitqueue_head(&dev->wait); INIT_LIST_HEAD(&dev->read_list); INIT_LIST_HEAD(&dev->pending_list); @@ -581,6 +628,46 @@ long vhost_dev_check_owner(struct vhost_dev *dev) } EXPORT_SYMBOL_GPL(vhost_dev_check_owner); +struct vhost_attach_cgroups_struct { + struct vhost_work work; + struct task_struct *owner; + int ret; +}; + +static void vhost_attach_cgroups_work(struct vhost_work *work) +{ + struct vhost_attach_cgroups_struct *s; + + s = container_of(work, struct vhost_attach_cgroups_struct, work); + s->ret = cgroup_attach_task_all(s->owner, current); +} + +static int vhost_attach_task_to_cgroups(struct vhost_worker *worker) +{ + struct vhost_attach_cgroups_struct attach; + int saved_cnt; + + attach.owner = current; + + vhost_work_init(&attach.work, vhost_attach_cgroups_work); + vhost_worker_queue(worker, &attach.work); + + mutex_lock(&worker->mutex); + + /* + * Bypass attachment_cnt check in __vhost_worker_flush: + * Temporarily change it to INT_MAX to bypass the check + */ + saved_cnt = worker->attachment_cnt; + worker->attachment_cnt = INT_MAX; + __vhost_worker_flush(worker); + worker->attachment_cnt = saved_cnt; + + mutex_unlock(&worker->mutex); + + return attach.ret; +} + /* Caller should have device mutex */ bool vhost_dev_has_owner(struct vhost_dev *dev) { @@ -626,7 +713,7 @@ static void vhost_worker_destroy(struct vhost_dev *dev, WARN_ON(!llist_empty(&worker->work_list)); xa_erase(&dev->worker_xa, worker->id); - vhost_task_stop(worker->vtsk); + worker->ops->stop(worker); kfree(worker); } @@ -649,42 +736,115 @@ static void vhost_workers_free(struct vhost_dev *dev) xa_destroy(&dev->worker_xa); } +static void vhost_task_wakeup(struct vhost_worker *worker) +{ + return vhost_task_wake(worker->vtsk); +} + +static void vhost_kthread_wakeup(struct vhost_worker *worker) +{ + wake_up_process(worker->kthread_task); +} + +static void vhost_task_do_stop(struct vhost_worker *worker) +{ + return vhost_task_stop(worker->vtsk); +} + +static void vhost_kthread_do_stop(struct vhost_worker *worker) +{ + kthread_stop(worker->kthread_task); +} + +static int vhost_task_worker_create(struct vhost_worker *worker, + struct vhost_dev *dev, const char *name) +{ + struct vhost_task *vtsk; + u32 id; + int ret; + + vtsk = vhost_task_create(vhost_run_work_list, vhost_worker_killed, + worker, name); + if (IS_ERR(vtsk)) + return PTR_ERR(vtsk); + + worker->vtsk = vtsk; + vhost_task_start(vtsk); + ret = xa_alloc(&dev->worker_xa, &id, worker, xa_limit_32b, GFP_KERNEL); + if (ret < 0) { + vhost_task_do_stop(worker); + return ret; + } + worker->id = id; + return 0; +} + +static int vhost_kthread_worker_create(struct vhost_worker *worker, + struct vhost_dev *dev, const char *name) +{ + struct task_struct *task; + u32 id; + int ret; + + task = kthread_create(vhost_run_work_kthread_list, worker, "%s", name); + if (IS_ERR(task)) + return PTR_ERR(task); + + worker->kthread_task = task; + wake_up_process(task); + ret = xa_alloc(&dev->worker_xa, &id, worker, xa_limit_32b, GFP_KERNEL); + if (ret < 0) + goto stop_worker; + + ret = vhost_attach_task_to_cgroups(worker); + if (ret) + goto stop_worker; + + worker->id = id; + return 0; + +stop_worker: + vhost_kthread_do_stop(worker); + return ret; +} + +static const struct vhost_worker_ops kthread_ops = { + .create = vhost_kthread_worker_create, + .stop = vhost_kthread_do_stop, + .wakeup = vhost_kthread_wakeup, +}; + +static const struct vhost_worker_ops vhost_task_ops = { + .create = vhost_task_worker_create, + .stop = vhost_task_do_stop, + .wakeup = vhost_task_wakeup, +}; + static struct vhost_worker *vhost_worker_create(struct vhost_dev *dev) { struct vhost_worker *worker; - struct vhost_task *vtsk; char name[TASK_COMM_LEN]; int ret; - u32 id; + const struct vhost_worker_ops *ops = dev->fork_owner ? &vhost_task_ops : + &kthread_ops; worker = kzalloc(sizeof(*worker), GFP_KERNEL_ACCOUNT); if (!worker) return NULL; worker->dev = dev; + worker->ops = ops; snprintf(name, sizeof(name), "vhost-%d", current->pid); - vtsk = vhost_task_create(vhost_run_work_list, vhost_worker_killed, - worker, name); - if (IS_ERR(vtsk)) - goto free_worker; - mutex_init(&worker->mutex); init_llist_head(&worker->work_list); worker->kcov_handle = kcov_common_handle(); - worker->vtsk = vtsk; - - vhost_task_start(vtsk); - - ret = xa_alloc(&dev->worker_xa, &id, worker, xa_limit_32b, GFP_KERNEL); + ret = ops->create(worker, dev, name); if (ret < 0) - goto stop_worker; - worker->id = id; + goto free_worker; return worker; -stop_worker: - vhost_task_stop(vtsk); free_worker: kfree(worker); return NULL; @@ -865,6 +1025,14 @@ long vhost_worker_ioctl(struct vhost_dev *dev, unsigned int ioctl, switch (ioctl) { /* dev worker ioctls */ case VHOST_NEW_WORKER: + /* + * vhost_tasks will account for worker threads under the parent's + * NPROC value but kthreads do not. To avoid userspace overflowing + * the system with worker threads fork_owner must be true. + */ + if (!dev->fork_owner) + return -EFAULT; + ret = vhost_new_worker(dev, &state); if (!ret && copy_to_user(argp, &state, sizeof(state))) ret = -EFAULT; @@ -982,6 +1150,7 @@ void vhost_dev_reset_owner(struct vhost_dev *dev, struct vhost_iotlb *umem) vhost_dev_cleanup(dev); + dev->fork_owner = fork_from_owner_default; dev->umem = umem; /* We don't need VQ locks below since vhost_dev_cleanup makes sure * VQs aren't running. @@ -2135,6 +2304,45 @@ long vhost_dev_ioctl(struct vhost_dev *d, unsigned int ioctl, void __user *argp) goto done; } +#ifdef CONFIG_VHOST_ENABLE_FORK_OWNER_CONTROL + if (ioctl == VHOST_SET_FORK_FROM_OWNER) { + /* Only allow modification before owner is set */ + if (vhost_dev_has_owner(d)) { + r = -EBUSY; + goto done; + } + u8 fork_owner_val; + + if (get_user(fork_owner_val, (u8 __user *)argp)) { + r = -EFAULT; + goto done; + } + if (fork_owner_val != VHOST_FORK_OWNER_TASK && + fork_owner_val != VHOST_FORK_OWNER_KTHREAD) { + r = -EINVAL; + goto done; + } + d->fork_owner = !!fork_owner_val; + r = 0; + goto done; + } + if (ioctl == VHOST_GET_FORK_FROM_OWNER) { + u8 fork_owner_val = d->fork_owner; + + if (fork_owner_val != VHOST_FORK_OWNER_TASK && + fork_owner_val != VHOST_FORK_OWNER_KTHREAD) { + r = -EINVAL; + goto done; + } + if (put_user(fork_owner_val, (u8 __user *)argp)) { + r = -EFAULT; + goto done; + } + r = 0; + goto done; + } +#endif + /* You must be the owner to do anything else */ r = vhost_dev_check_owner(d); if (r) diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h index bb75a292d50c..ab704d84fb34 100644 --- a/drivers/vhost/vhost.h +++ b/drivers/vhost/vhost.h @@ -26,7 +26,18 @@ struct vhost_work { unsigned long flags; }; +struct vhost_worker; +struct vhost_dev; + +struct vhost_worker_ops { + int (*create)(struct vhost_worker *worker, struct vhost_dev *dev, + const char *name); + void (*stop)(struct vhost_worker *worker); + void (*wakeup)(struct vhost_worker *worker); +}; + struct vhost_worker { + struct task_struct *kthread_task; struct vhost_task *vtsk; struct vhost_dev *dev; /* Used to serialize device wide flushing with worker swapping. */ @@ -36,6 +47,7 @@ struct vhost_worker { u32 id; int attachment_cnt; bool killed; + const struct vhost_worker_ops *ops; }; /* Poll a file (eventfd or socket) */ @@ -176,6 +188,16 @@ struct vhost_dev { int byte_weight; struct xarray worker_xa; bool use_worker; + /* + * If fork_owner is true we use vhost_tasks to create + * the worker so all settings/limits like cgroups, NPROC, + * scheduler, etc are inherited from the owner. If false, + * we use kthreads and only attach to the same cgroups + * as the owner for compat with older kernels. + * here we use true as default value. + * The default value is set by fork_from_owner_default + */ + bool fork_owner; int (*msg_handler)(struct vhost_dev *dev, u32 asid, struct vhost_iotlb_msg *msg); }; diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h index d4b3e2ae1314..e72f2655459e 100644 --- a/include/uapi/linux/vhost.h +++ b/include/uapi/linux/vhost.h @@ -235,4 +235,33 @@ */ #define VHOST_VDPA_GET_VRING_SIZE _IOWR(VHOST_VIRTIO, 0x82, \ struct vhost_vring_state) + +/* fork_owner values for vhost */ +#define VHOST_FORK_OWNER_KTHREAD 0 +#define VHOST_FORK_OWNER_TASK 1 + +/** + * VHOST_SET_FORK_FROM_OWNER - Set the fork_owner flag for the vhost device, + * This ioctl must called before VHOST_SET_OWNER. + * Only available when CONFIG_VHOST_ENABLE_FORK_OWNER_CONTROL=y + * + * @param fork_owner: An 8-bit value that determines the vhost thread mode + * + * When fork_owner is set to VHOST_FORK_OWNER_TASK(default value): + * - Vhost will create vhost worker as tasks forked from the owner, + * inheriting all of the owner's attributes. + * + * When fork_owner is set to VHOST_FORK_OWNER_KTHREAD: + * - Vhost will create vhost workers as kernel threads. + */ +#define VHOST_SET_FORK_FROM_OWNER _IOW(VHOST_VIRTIO, 0x83, __u8) + +/** + * VHOST_GET_FORK_OWNER - Get the current fork_owner flag for the vhost device. + * Only available when CONFIG_VHOST_ENABLE_FORK_OWNER_CONTROL=y + * + * @return: An 8-bit value indicating the current thread mode. + */ +#define VHOST_GET_FORK_FROM_OWNER _IOR(VHOST_VIRTIO, 0x84, __u8) + #endif -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 330/480] bpf: Check flow_dissector ctx accesses are aligned 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (328 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 329/480] vhost: Reintroduce kthread API and add mode selection Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:48 ` [PATCH 6.15 331/480] bpf: Check netfilter " Greg Kroah-Hartman ` (161 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, syzbot+ccac90e482b2a81d74aa, Paul Chaignon, Yonghong Song, Eduard Zingerman, Alexei Starovoitov, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Paul Chaignon <paul.chaignon@gmail.com> [ Upstream commit ead3d7b2b6afa5ee7958620c4329982a7d9c2b78 ] flow_dissector_is_valid_access doesn't check that the context access is aligned. As a consequence, an unaligned access within one of the exposed field is considered valid and later rejected by flow_dissector_convert_ctx_access when we try to convert it. The later rejection is problematic because it's reported as a verifier bug with a kernel warning and doesn't point to the right instruction in verifier logs. Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook") Reported-by: syzbot+ccac90e482b2a81d74aa@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ccac90e482b2a81d74aa Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Acked-by: Yonghong Song <yonghong.song@linux.dev> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/cc1b036be484c99be45eddf48bd78cc6f72839b1.1754039605.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/core/filter.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/core/filter.c b/net/core/filter.c index 34f91c3aacb2..ac2cb6eba56e 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -9463,6 +9463,9 @@ static bool flow_dissector_is_valid_access(int off, int size, if (off < 0 || off >= sizeof(struct __sk_buff)) return false; + if (off % size != 0) + return false; + if (type == BPF_WRITE) return false; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 331/480] bpf: Check netfilter ctx accesses are aligned 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (329 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 330/480] bpf: Check flow_dissector ctx accesses are aligned Greg Kroah-Hartman @ 2025-08-12 17:48 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 332/480] apparmor: ensure WB_HISTORY_SIZE value is a power of 2 Greg Kroah-Hartman ` (160 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:48 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Paul Chaignon, Yonghong Song, Eduard Zingerman, Alexei Starovoitov, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Paul Chaignon <paul.chaignon@gmail.com> [ Upstream commit 9e6448f7b1efb27f8d508b067ecd33ed664a4246 ] Similarly to the previous patch fixing the flow_dissector ctx accesses, nf_is_valid_access also doesn't check that ctx accesses are aligned. Contrary to flow_dissector programs, netfilter programs don't have context conversion. The unaligned ctx accesses are therefore allowed by the verifier. Fixes: fd9c663b9ad6 ("bpf: minimal support for programs hooked into netfilter framework") Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Acked-by: Yonghong Song <yonghong.song@linux.dev> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/853ae9ed5edaa5196e8472ff0f1bb1cc24059214.1754039605.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/netfilter/nf_bpf_link.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/netfilter/nf_bpf_link.c b/net/netfilter/nf_bpf_link.c index 25bbac8986c2..c12250e50a8b 100644 --- a/net/netfilter/nf_bpf_link.c +++ b/net/netfilter/nf_bpf_link.c @@ -295,6 +295,9 @@ static bool nf_is_valid_access(int off, int size, enum bpf_access_type type, if (off < 0 || off >= sizeof(struct bpf_nf_ctx)) return false; + if (off % size != 0) + return false; + if (type == BPF_WRITE) return false; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 332/480] apparmor: ensure WB_HISTORY_SIZE value is a power of 2 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (330 preceding siblings ...) 2025-08-12 17:48 ` [PATCH 6.15 331/480] bpf: Check netfilter " Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 333/480] apparmor: fix loop detection used in conflicting attachment resolution Greg Kroah-Hartman ` (159 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Ryan Lee, John Johansen, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ryan Lee <ryan.lee@canonical.com> [ Upstream commit 6c055e62560b958354625604293652753d82bcae ] WB_HISTORY_SIZE was defined to be a value not a power of 2, despite a comment in the declaration of struct match_workbuf stating it is and a modular arithmetic usage in the inc_wb_pos macro assuming that it is. Bump WB_HISTORY_SIZE's value up to 32 and add a BUILD_BUG_ON_NOT_POWER_OF_2 line to ensure that any future changes to the value of WB_HISTORY_SIZE respect this requirement. Fixes: 136db994852a ("apparmor: increase left match history buffer size") Signed-off-by: Ryan Lee <ryan.lee@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- security/apparmor/include/match.h | 3 ++- security/apparmor/match.c | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/security/apparmor/include/match.h b/security/apparmor/include/match.h index 536ce3abd598..b45fc39fa837 100644 --- a/security/apparmor/include/match.h +++ b/security/apparmor/include/match.h @@ -137,7 +137,8 @@ aa_state_t aa_dfa_matchn_until(struct aa_dfa *dfa, aa_state_t start, void aa_dfa_free_kref(struct kref *kref); -#define WB_HISTORY_SIZE 24 +/* This needs to be a power of 2 */ +#define WB_HISTORY_SIZE 32 struct match_workbuf { unsigned int count; unsigned int pos; diff --git a/security/apparmor/match.c b/security/apparmor/match.c index f2d9c57f8794..1ceabde550f2 100644 --- a/security/apparmor/match.c +++ b/security/apparmor/match.c @@ -681,6 +681,7 @@ aa_state_t aa_dfa_matchn_until(struct aa_dfa *dfa, aa_state_t start, #define inc_wb_pos(wb) \ do { \ + BUILD_BUG_ON_NOT_POWER_OF_2(WB_HISTORY_SIZE); \ wb->pos = (wb->pos + 1) & (WB_HISTORY_SIZE - 1); \ wb->len = (wb->len + 1) & (WB_HISTORY_SIZE - 1); \ } while (0) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 333/480] apparmor: fix loop detection used in conflicting attachment resolution 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (331 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 332/480] apparmor: ensure WB_HISTORY_SIZE value is a power of 2 Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 334/480] scripts: gdb: move MNT_* constants to gdb-parsed Greg Kroah-Hartman ` (158 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Ryan Lee, John Johansen, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ryan Lee <ryan.lee@canonical.com> [ Upstream commit a88db916b8c77552f49f7d9f8744095ea01a268f ] Conflicting attachment resolution is based on the number of states traversed to reach an accepting state in the attachment DFA, accounting for DFA loops traversed during the matching process. However, the loop counting logic had multiple bugs: - The inc_wb_pos macro increments both position and length, but length is supposed to saturate upon hitting buffer capacity, instead of wrapping around. - If no revisited state is found when traversing the history, is_loop would still return true, as if there was a loop found the length of the history buffer, instead of returning false and signalling that no loop was found. As a result, the adjustment step of aa_dfa_leftmatch would sometimes produce negative counts with loop- free DFAs that traversed enough states. - The iteration in the is_loop for loop is supposed to stop before i = wb->len, so the conditional should be < instead of <=. This patch fixes the above bugs as well as the following nits: - The count and size fields in struct match_workbuf were not used, so they can be removed. - The history buffer in match_workbuf semantically stores aa_state_t and not unsigned ints, even if aa_state_t is currently unsigned int. - The local variables in is_loop are counters, and thus should be unsigned ints instead of aa_state_t's. Fixes: 21f606610502 ("apparmor: improve overlapping domain attachment resolution") Signed-off-by: Ryan Lee <ryan.lee@canonical.com> Co-developed-by: John Johansen <john.johansen@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- security/apparmor/include/match.h | 5 +---- security/apparmor/match.c | 22 +++++++++++----------- 2 files changed, 12 insertions(+), 15 deletions(-) diff --git a/security/apparmor/include/match.h b/security/apparmor/include/match.h index b45fc39fa837..27cf23b0396b 100644 --- a/security/apparmor/include/match.h +++ b/security/apparmor/include/match.h @@ -140,15 +140,12 @@ void aa_dfa_free_kref(struct kref *kref); /* This needs to be a power of 2 */ #define WB_HISTORY_SIZE 32 struct match_workbuf { - unsigned int count; unsigned int pos; unsigned int len; - unsigned int size; /* power of 2, same as history size */ - unsigned int history[WB_HISTORY_SIZE]; + aa_state_t history[WB_HISTORY_SIZE]; }; #define DEFINE_MATCH_WB(N) \ struct match_workbuf N = { \ - .count = 0, \ .pos = 0, \ .len = 0, \ } diff --git a/security/apparmor/match.c b/security/apparmor/match.c index 1ceabde550f2..c5a91600842a 100644 --- a/security/apparmor/match.c +++ b/security/apparmor/match.c @@ -679,35 +679,35 @@ aa_state_t aa_dfa_matchn_until(struct aa_dfa *dfa, aa_state_t start, return state; } -#define inc_wb_pos(wb) \ -do { \ +#define inc_wb_pos(wb) \ +do { \ BUILD_BUG_ON_NOT_POWER_OF_2(WB_HISTORY_SIZE); \ wb->pos = (wb->pos + 1) & (WB_HISTORY_SIZE - 1); \ - wb->len = (wb->len + 1) & (WB_HISTORY_SIZE - 1); \ + wb->len = (wb->len + 1) > WB_HISTORY_SIZE ? WB_HISTORY_SIZE : \ + wb->len + 1; \ } while (0) /* For DFAs that don't support extended tagging of states */ +/* adjust is only set if is_loop returns true */ static bool is_loop(struct match_workbuf *wb, aa_state_t state, unsigned int *adjust) { - aa_state_t pos = wb->pos; - aa_state_t i; + int pos = wb->pos; + int i; if (wb->history[pos] < state) return false; - for (i = 0; i <= wb->len; i++) { + for (i = 0; i < wb->len; i++) { if (wb->history[pos] == state) { *adjust = i; return true; } - if (pos == 0) - pos = WB_HISTORY_SIZE; - pos--; + /* -1 wraps to WB_HISTORY_SIZE - 1 */ + pos = (pos - 1) & (WB_HISTORY_SIZE - 1); } - *adjust = i; - return true; + return false; } static aa_state_t leftmatch_fb(struct aa_dfa *dfa, aa_state_t start, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 334/480] scripts: gdb: move MNT_* constants to gdb-parsed 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (332 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 333/480] apparmor: fix loop detection used in conflicting attachment resolution Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 335/480] apparmor: Fix unaligned memory accesses in KUnit test Greg Kroah-Hartman ` (157 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Benjamin Berg, Johannes Berg, Jan Kiszka, Kieran Bingham, Stephen Brennan, Andrew Morton, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Johannes Berg <johannes.berg@intel.com> [ Upstream commit 41a7f737685eed2700654720d3faaffdf0132135 ] Since these are now no longer defines, but in an enum. Link: https://lkml.kernel.org/r/20250618134629.25700-2-johannes@sipsolutions.net Fixes: 101f2bbab541 ("fs: convert mount flags to enum") Reviewed-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Stephen Brennan <stephen.s.brennan@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- scripts/gdb/linux/constants.py.in | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/scripts/gdb/linux/constants.py.in b/scripts/gdb/linux/constants.py.in index f795302ddfa8..c3886739a028 100644 --- a/scripts/gdb/linux/constants.py.in +++ b/scripts/gdb/linux/constants.py.in @@ -74,12 +74,12 @@ if IS_BUILTIN(CONFIG_MODULES): LX_GDBPARSED(MOD_RO_AFTER_INIT) /* linux/mount.h */ -LX_VALUE(MNT_NOSUID) -LX_VALUE(MNT_NODEV) -LX_VALUE(MNT_NOEXEC) -LX_VALUE(MNT_NOATIME) -LX_VALUE(MNT_NODIRATIME) -LX_VALUE(MNT_RELATIME) +LX_GDBPARSED(MNT_NOSUID) +LX_GDBPARSED(MNT_NODEV) +LX_GDBPARSED(MNT_NOEXEC) +LX_GDBPARSED(MNT_NOATIME) +LX_GDBPARSED(MNT_NODIRATIME) +LX_GDBPARSED(MNT_RELATIME) /* linux/threads.h */ LX_VALUE(NR_CPUS) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 335/480] apparmor: Fix unaligned memory accesses in KUnit test 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (333 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 334/480] scripts: gdb: move MNT_* constants to gdb-parsed Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 336/480] i3c: master: svc: Fix npcm845 FIFO_EMPTY quirk Greg Kroah-Hartman ` (156 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Helge Deller, John Johansen, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Helge Deller <deller@gmx.de> [ Upstream commit c68804199dd9d63868497a27b5da3c3cd15356db ] The testcase triggers some unnecessary unaligned memory accesses on the parisc architecture: Kernel: unaligned access to 0x12f28e27 in policy_unpack_test_init+0x180/0x374 (iir 0x0cdc1280) Kernel: unaligned access to 0x12f28e67 in policy_unpack_test_init+0x270/0x374 (iir 0x64dc00ce) Use the existing helper functions put_unaligned_le32() and put_unaligned_le16() to avoid such warnings on architectures which prefer aligned memory accesses. Signed-off-by: Helge Deller <deller@gmx.de> Fixes: 98c0cc48e27e ("apparmor: fix policy_unpack_test on big endian systems") Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- security/apparmor/policy_unpack_test.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/security/apparmor/policy_unpack_test.c b/security/apparmor/policy_unpack_test.c index 5b2ba88ae9e2..cf18744dafe2 100644 --- a/security/apparmor/policy_unpack_test.c +++ b/security/apparmor/policy_unpack_test.c @@ -9,6 +9,8 @@ #include "include/policy.h" #include "include/policy_unpack.h" +#include <linux/unaligned.h> + #define TEST_STRING_NAME "TEST_STRING" #define TEST_STRING_DATA "testing" #define TEST_STRING_BUF_OFFSET \ @@ -80,7 +82,7 @@ static struct aa_ext *build_aa_ext_struct(struct policy_unpack_fixture *puf, *(buf + 1) = strlen(TEST_U32_NAME) + 1; strscpy(buf + 3, TEST_U32_NAME, e->end - (void *)(buf + 3)); *(buf + 3 + strlen(TEST_U32_NAME) + 1) = AA_U32; - *((__le32 *)(buf + 3 + strlen(TEST_U32_NAME) + 2)) = cpu_to_le32(TEST_U32_DATA); + put_unaligned_le32(TEST_U32_DATA, buf + 3 + strlen(TEST_U32_NAME) + 2); buf = e->start + TEST_NAMED_U64_BUF_OFFSET; *buf = AA_NAME; @@ -103,7 +105,7 @@ static struct aa_ext *build_aa_ext_struct(struct policy_unpack_fixture *puf, *(buf + 1) = strlen(TEST_ARRAY_NAME) + 1; strscpy(buf + 3, TEST_ARRAY_NAME, e->end - (void *)(buf + 3)); *(buf + 3 + strlen(TEST_ARRAY_NAME) + 1) = AA_ARRAY; - *((__le16 *)(buf + 3 + strlen(TEST_ARRAY_NAME) + 2)) = cpu_to_le16(TEST_ARRAY_SIZE); + put_unaligned_le16(TEST_ARRAY_SIZE, buf + 3 + strlen(TEST_ARRAY_NAME) + 2); return e; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 336/480] i3c: master: svc: Fix npcm845 FIFO_EMPTY quirk 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (334 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 335/480] apparmor: Fix unaligned memory accesses in KUnit test Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 337/480] module: Restore the moduleparam prefix length check Greg Kroah-Hartman ` (155 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Stanley Chu, Alexandre Belloni, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Stanley Chu <yschu@nuvoton.com> [ Upstream commit bc4a09d8e79cadccdd505f47b01903a80bc666e7 ] In a private write transfer, the driver pre-fills the FIFO to work around the FIFO_EMPTY quirk. However, if an IBIWON event occurs, the hardware emits a NACK and the driver initiates a retry. During the retry, driver attempts to pre-fill the FIFO again if there is remaining data, but since the FIFO is already full, this leads to data loss. Check available space in FIFO to prevent overflow. Fixes: 4008a74e0f9b ("i3c: master: svc: Fix npcm845 FIFO empty issue") Signed-off-by: Stanley Chu <yschu@nuvoton.com> Link: https://lore.kernel.org/r/20250730003719.1825593-1-yschu@nuvoton.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/i3c/master/svc-i3c-master.c | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/drivers/i3c/master/svc-i3c-master.c b/drivers/i3c/master/svc-i3c-master.c index 85e16de208d3..01295eb80806 100644 --- a/drivers/i3c/master/svc-i3c-master.c +++ b/drivers/i3c/master/svc-i3c-master.c @@ -104,6 +104,7 @@ #define SVC_I3C_MDATACTRL_TXTRIG_FIFO_NOT_FULL GENMASK(5, 4) #define SVC_I3C_MDATACTRL_RXTRIG_FIFO_NOT_EMPTY 0 #define SVC_I3C_MDATACTRL_RXCOUNT(x) FIELD_GET(GENMASK(28, 24), (x)) +#define SVC_I3C_MDATACTRL_TXCOUNT(x) FIELD_GET(GENMASK(20, 16), (x)) #define SVC_I3C_MDATACTRL_TXFULL BIT(30) #define SVC_I3C_MDATACTRL_RXEMPTY BIT(31) @@ -1308,14 +1309,19 @@ static int svc_i3c_master_xfer(struct svc_i3c_master *master, * FIFO start filling as soon as possible after EmitStartAddr. */ if (svc_has_quirk(master, SVC_I3C_QUIRK_FIFO_EMPTY) && !rnw && xfer_len) { - u32 end = xfer_len > SVC_I3C_FIFO_SIZE ? 0 : SVC_I3C_MWDATAB_END; - u32 len = min_t(u32, xfer_len, SVC_I3C_FIFO_SIZE); - - writesb(master->regs + SVC_I3C_MWDATAB1, out, len - 1); - /* Mark END bit if this is the last byte */ - writel(out[len - 1] | end, master->regs + SVC_I3C_MWDATAB); - xfer_len -= len; - out += len; + u32 space, end, len; + + reg = readl(master->regs + SVC_I3C_MDATACTRL); + space = SVC_I3C_FIFO_SIZE - SVC_I3C_MDATACTRL_TXCOUNT(reg); + if (space) { + end = xfer_len > space ? 0 : SVC_I3C_MWDATAB_END; + len = min_t(u32, xfer_len, space); + writesb(master->regs + SVC_I3C_MWDATAB1, out, len - 1); + /* Mark END bit if this is the last byte */ + writel(out[len - 1] | end, master->regs + SVC_I3C_MWDATAB); + xfer_len -= len; + out += len; + } } ret = readl_poll_timeout(master->regs + SVC_I3C_MSTATUS, reg, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 337/480] module: Restore the moduleparam prefix length check 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (335 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 336/480] i3c: master: svc: Fix npcm845 FIFO_EMPTY quirk Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 338/480] ucount: fix atomic_long_inc_below() argument type Greg Kroah-Hartman ` (154 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Petr Pavlu, Daniel Gomez, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Petr Pavlu <petr.pavlu@suse.com> [ Upstream commit bdc877ba6b7ff1b6d2ebeff11e63da4a50a54854 ] The moduleparam code allows modules to provide their own definition of MODULE_PARAM_PREFIX, instead of using the default KBUILD_MODNAME ".". Commit 730b69d22525 ("module: check kernel param length at compile time, not runtime") added a check to ensure the prefix doesn't exceed MODULE_NAME_LEN, as this is what param_sysfs_builtin() expects. Later, commit 58f86cc89c33 ("VERIFY_OCTAL_PERMISSIONS: stricter checking for sysfs perms.") removed this check, but there is no indication this was intentional. Since the check is still useful for param_sysfs_builtin() to function properly, reintroduce it in __module_param_call(), but in a modernized form using static_assert(). While here, clean up the __module_param_call() comments. In particular, remove the comment "Default value instead of permissions?", which comes from commit 9774a1f54f17 ("[PATCH] Compile-time check re world-writeable module params"). This comment was related to the test variable __param_perm_check_##name, which was removed in the previously mentioned commit 58f86cc89c33. Fixes: 58f86cc89c33 ("VERIFY_OCTAL_PERMISSIONS: stricter checking for sysfs perms.") Signed-off-by: Petr Pavlu <petr.pavlu@suse.com> Reviewed-by: Daniel Gomez <da.gomez@samsung.com> Link: https://lore.kernel.org/r/20250630143535.267745-4-petr.pavlu@suse.com Signed-off-by: Daniel Gomez <da.gomez@samsung.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- include/linux/moduleparam.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h index bfb85fd13e1f..110e9d09de24 100644 --- a/include/linux/moduleparam.h +++ b/include/linux/moduleparam.h @@ -282,10 +282,9 @@ struct kparam_array #define __moduleparam_const const #endif -/* This is the fundamental function for registering boot/module - parameters. */ +/* This is the fundamental function for registering boot/module parameters. */ #define __module_param_call(prefix, name, ops, arg, perm, level, flags) \ - /* Default value instead of permissions? */ \ + static_assert(sizeof(""prefix) - 1 <= MAX_PARAM_PREFIX_LEN); \ static const char __param_str_##name[] = prefix #name; \ static struct kernel_param __moduleparam_const __param_##name \ __used __section("__param") \ -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 338/480] ucount: fix atomic_long_inc_below() argument type 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (336 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 337/480] module: Restore the moduleparam prefix length check Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 339/480] rtc: ds1307: fix incorrect maximum clock rate handling Greg Kroah-Hartman ` (153 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Uros Bizjak, Eric W. Biederman, Sebastian Andrzej Siewior, Paul E. McKenney, Alexey Gladkov, Roman Gushchin, MengEn Sun, Thomas Weißschuh, Mark Rutland, Andrew Morton, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Uros Bizjak <ubizjak@gmail.com> [ Upstream commit f8cd9193b62e92ad25def5370ca8ea2bc7585381 ] The type of u argument of atomic_long_inc_below() should be long to avoid unwanted truncation to int. The patch fixes the wrong argument type of an internal function to prevent unwanted argument truncation. It fixes an internal locking primitive; it should not have any direct effect on userspace. Mark said : AFAICT there's no problem in practice because atomic_long_inc_below() : is only used by inc_ucount(), and it looks like the value is : constrained between 0 and INT_MAX. : : In inc_ucount() the limit value is taken from : user_namespace::ucount_max[], and AFAICT that's only written by : sysctls, to the table setup by setup_userns_sysctls(), where : UCOUNT_ENTRY() limits the value between 0 and INT_MAX. : : This is certainly a cleanup, but there might be no functional issue in : practice as above. Link: https://lkml.kernel.org/r/20250721174610.28361-1-ubizjak@gmail.com Fixes: f9c82a4ea89c ("Increase size of ucounts to atomic_long_t") Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: "Paul E. McKenney" <paulmck@kernel.org> Cc: Alexey Gladkov <legion@kernel.org> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: MengEn Sun <mengensun@tencent.com> Cc: "Thomas Weißschuh" <linux@weissschuh.net> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- kernel/ucount.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/ucount.c b/kernel/ucount.c index 8686e329b8f2..f629db485a07 100644 --- a/kernel/ucount.c +++ b/kernel/ucount.c @@ -199,7 +199,7 @@ void put_ucounts(struct ucounts *ucounts) } } -static inline bool atomic_long_inc_below(atomic_long_t *v, int u) +static inline bool atomic_long_inc_below(atomic_long_t *v, long u) { long c, old; c = atomic_long_read(v); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 339/480] rtc: ds1307: fix incorrect maximum clock rate handling 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (337 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 338/480] ucount: fix atomic_long_inc_below() argument type Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 340/480] rtc: hym8563: " Greg Kroah-Hartman ` (152 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Brian Masney, Alexandre Belloni, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Brian Masney <bmasney@redhat.com> [ Upstream commit cf6eb547a24af7ad7bbd2abe9c5327f956bbeae8 ] When ds3231_clk_sqw_round_rate() is called with a requested rate higher than the highest supported rate, it currently returns 0, which disables the clock. According to the clk API, round_rate() should instead return the highest supported rate. Update the function to return the maximum supported rate in this case. Fixes: 6c6ff145b3346 ("rtc: ds1307: add clock provider support for DS3231") Signed-off-by: Brian Masney <bmasney@redhat.com> Link: https://lore.kernel.org/r/20250710-rtc-clk-round-rate-v1-1-33140bb2278e@redhat.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/rtc/rtc-ds1307.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c index 5efbe69bf5ca..c8a666de9cbe 100644 --- a/drivers/rtc/rtc-ds1307.c +++ b/drivers/rtc/rtc-ds1307.c @@ -1466,7 +1466,7 @@ static long ds3231_clk_sqw_round_rate(struct clk_hw *hw, unsigned long rate, return ds3231_clk_sqw_rates[i]; } - return 0; + return ds3231_clk_sqw_rates[ARRAY_SIZE(ds3231_clk_sqw_rates) - 1]; } static int ds3231_clk_sqw_set_rate(struct clk_hw *hw, unsigned long rate, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 340/480] rtc: hym8563: fix incorrect maximum clock rate handling 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (338 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 339/480] rtc: ds1307: fix incorrect maximum clock rate handling Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 341/480] rtc: nct3018y: " Greg Kroah-Hartman ` (151 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Brian Masney, Alexandre Belloni, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Brian Masney <bmasney@redhat.com> [ Upstream commit d0a518eb0a692a2ab8357e844970660c5ea37720 ] When hym8563_clkout_round_rate() is called with a requested rate higher than the highest supported rate, it currently returns 0, which disables the clock. According to the clk API, round_rate() should instead return the highest supported rate. Update the function to return the maximum supported rate in this case. Fixes: dcaf038493525 ("rtc: add hym8563 rtc-driver") Signed-off-by: Brian Masney <bmasney@redhat.com> Link: https://lore.kernel.org/r/20250710-rtc-clk-round-rate-v1-2-33140bb2278e@redhat.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/rtc/rtc-hym8563.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-hym8563.c b/drivers/rtc/rtc-hym8563.c index 63f11ea3589d..759dc2ad6e3b 100644 --- a/drivers/rtc/rtc-hym8563.c +++ b/drivers/rtc/rtc-hym8563.c @@ -294,7 +294,7 @@ static long hym8563_clkout_round_rate(struct clk_hw *hw, unsigned long rate, if (clkout_rates[i] <= rate) return clkout_rates[i]; - return 0; + return clkout_rates[0]; } static int hym8563_clkout_set_rate(struct clk_hw *hw, unsigned long rate, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 341/480] rtc: nct3018y: fix incorrect maximum clock rate handling 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (339 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 340/480] rtc: hym8563: " Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 342/480] rtc: pcf85063: " Greg Kroah-Hartman ` (150 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Brian Masney, Alexandre Belloni, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Brian Masney <bmasney@redhat.com> [ Upstream commit 437c59e4b222cd697b4cf95995d933e7d583c5f1 ] When nct3018y_clkout_round_rate() is called with a requested rate higher than the highest supported rate, it currently returns 0, which disables the clock. According to the clk API, round_rate() should instead return the highest supported rate. Update the function to return the maximum supported rate in this case. Fixes: 5adbaed16cc63 ("rtc: Add NCT3018Y real time clock driver") Signed-off-by: Brian Masney <bmasney@redhat.com> Link: https://lore.kernel.org/r/20250710-rtc-clk-round-rate-v1-3-33140bb2278e@redhat.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/rtc/rtc-nct3018y.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-nct3018y.c b/drivers/rtc/rtc-nct3018y.c index 76c5f464b2da..cea05fca0bcc 100644 --- a/drivers/rtc/rtc-nct3018y.c +++ b/drivers/rtc/rtc-nct3018y.c @@ -376,7 +376,7 @@ static long nct3018y_clkout_round_rate(struct clk_hw *hw, unsigned long rate, if (clkout_rates[i] <= rate) return clkout_rates[i]; - return 0; + return clkout_rates[0]; } static int nct3018y_clkout_set_rate(struct clk_hw *hw, unsigned long rate, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 342/480] rtc: pcf85063: fix incorrect maximum clock rate handling 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (340 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 341/480] rtc: nct3018y: " Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 343/480] rtc: pcf8563: " Greg Kroah-Hartman ` (149 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Brian Masney, Alexandre Belloni, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Brian Masney <bmasney@redhat.com> [ Upstream commit 186ae1869880e58bb3f142d222abdb35ecb4df0f ] When pcf85063_clkout_round_rate() is called with a requested rate higher than the highest supported rate, it currently returns 0, which disables the clock. According to the clk API, round_rate() should instead return the highest supported rate. Update the function to return the maximum supported rate in this case. Fixes: 8c229ab6048b7 ("rtc: pcf85063: Add pcf85063 clkout control to common clock framework") Signed-off-by: Brian Masney <bmasney@redhat.com> Link: https://lore.kernel.org/r/20250710-rtc-clk-round-rate-v1-4-33140bb2278e@redhat.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/rtc/rtc-pcf85063.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-pcf85063.c b/drivers/rtc/rtc-pcf85063.c index 4fa5c4ecdd5a..b26c9bfad5d9 100644 --- a/drivers/rtc/rtc-pcf85063.c +++ b/drivers/rtc/rtc-pcf85063.c @@ -410,7 +410,7 @@ static long pcf85063_clkout_round_rate(struct clk_hw *hw, unsigned long rate, if (clkout_rates[i] <= rate) return clkout_rates[i]; - return 0; + return clkout_rates[0]; } static int pcf85063_clkout_set_rate(struct clk_hw *hw, unsigned long rate, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 343/480] rtc: pcf8563: fix incorrect maximum clock rate handling 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (341 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 342/480] rtc: pcf85063: " Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 344/480] rtc: rv3028: " Greg Kroah-Hartman ` (148 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Brian Masney, Alexandre Belloni, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Brian Masney <bmasney@redhat.com> [ Upstream commit 906726a5efeefe0ef0103ccff5312a09080c04ae ] When pcf8563_clkout_round_rate() is called with a requested rate higher than the highest supported rate, it currently returns 0, which disables the clock. According to the clk API, round_rate() should instead return the highest supported rate. Update the function to return the maximum supported rate in this case. Fixes: a39a6405d5f94 ("rtc: pcf8563: add CLKOUT to common clock framework") Signed-off-by: Brian Masney <bmasney@redhat.com> Link: https://lore.kernel.org/r/20250710-rtc-clk-round-rate-v1-5-33140bb2278e@redhat.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/rtc/rtc-pcf8563.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c index 5a084d426e58..e79da8901544 100644 --- a/drivers/rtc/rtc-pcf8563.c +++ b/drivers/rtc/rtc-pcf8563.c @@ -339,7 +339,7 @@ static long pcf8563_clkout_round_rate(struct clk_hw *hw, unsigned long rate, if (clkout_rates[i] <= rate) return clkout_rates[i]; - return 0; + return clkout_rates[0]; } static int pcf8563_clkout_set_rate(struct clk_hw *hw, unsigned long rate, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 344/480] rtc: rv3028: fix incorrect maximum clock rate handling 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (342 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 343/480] rtc: pcf8563: " Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 345/480] f2fs: turn off one_time when forcibly set to foreground GC Greg Kroah-Hartman ` (147 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Brian Masney, Alexandre Belloni, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Brian Masney <bmasney@redhat.com> [ Upstream commit b574acb3cf7591d2513a9f29f8c2021ad55fb881 ] When rv3028_clkout_round_rate() is called with a requested rate higher than the highest supported rate, it currently returns 0, which disables the clock. According to the clk API, round_rate() should instead return the highest supported rate. Update the function to return the maximum supported rate in this case. Fixes: f583c341a515f ("rtc: rv3028: add clkout support") Signed-off-by: Brian Masney <bmasney@redhat.com> Link: https://lore.kernel.org/r/20250710-rtc-clk-round-rate-v1-6-33140bb2278e@redhat.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/rtc/rtc-rv3028.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-rv3028.c b/drivers/rtc/rtc-rv3028.c index 868d1b1eb0f4..278841c2e47e 100644 --- a/drivers/rtc/rtc-rv3028.c +++ b/drivers/rtc/rtc-rv3028.c @@ -740,7 +740,7 @@ static long rv3028_clkout_round_rate(struct clk_hw *hw, unsigned long rate, if (clkout_rates[i] <= rate) return clkout_rates[i]; - return 0; + return clkout_rates[0]; } static int rv3028_clkout_set_rate(struct clk_hw *hw, unsigned long rate, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 345/480] f2fs: turn off one_time when forcibly set to foreground GC 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (343 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 344/480] rtc: rv3028: " Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 346/480] f2fs: fix bio memleak when committing super block Greg Kroah-Hartman ` (146 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Daeho Jeong, Chao Yu, Jaegeuk Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Daeho Jeong <daehojeong@google.com> [ Upstream commit 8142daf8a53806689186ee255cc02f89af7f8890 ] one_time mode is only for background GC. So, we need to set it back to false when foreground GC is enforced. Fixes: 9748c2ddea4a ("f2fs: do FG_GC when GC boosting is required for zoned devices") Signed-off-by: Daeho Jeong <daehojeong@google.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/f2fs/gc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c index 8b5a55b72264..67f04d140e0f 100644 --- a/fs/f2fs/gc.c +++ b/fs/f2fs/gc.c @@ -1893,6 +1893,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, struct f2fs_gc_control *gc_control) /* Let's run FG_GC, if we don't have enough space. */ if (has_not_enough_free_secs(sbi, 0, 0)) { gc_type = FG_GC; + gc_control->one_time = false; /* * For example, if there are many prefree_segments below given -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 346/480] f2fs: fix bio memleak when committing super block 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (344 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 345/480] f2fs: turn off one_time when forcibly set to foreground GC Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 347/480] f2fs: fix to avoid invalid wait context issue Greg Kroah-Hartman ` (145 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Sheng Yong, Chao Yu, Jaegeuk Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Sheng Yong <shengyong1@xiaomi.com> [ Upstream commit 554d9b7242a73d701ce121ac81bb578a3fca538e ] When committing new super block, bio is allocated but not freed, and kmemleak complains: unreferenced object 0xffff88801d185600 (size 192): comm "kworker/3:2", pid 128, jiffies 4298624992 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 80 67 c3 00 81 88 ff ff .........g...... 01 08 06 00 00 00 00 00 00 00 00 00 01 00 00 00 ................ backtrace (crc 650ecdb1): kmem_cache_alloc_noprof+0x3a9/0x460 mempool_alloc_noprof+0x12f/0x310 bio_alloc_bioset+0x1e2/0x7e0 __f2fs_commit_super+0xe0/0x370 f2fs_commit_super+0x4ed/0x8c0 f2fs_record_error_work+0xc7/0x190 process_one_work+0x7db/0x1970 worker_thread+0x518/0xea0 kthread+0x359/0x690 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30 The issue can be reproduced by: mount /dev/vda /mnt i=0 while :; do echo '[h]abc' > /sys/fs/f2fs/vda/extension_list echo '[h]!abc' > /sys/fs/f2fs/vda/extension_list echo scan > /sys/kernel/debug/kmemleak dmesg | grep "new suspected memory leaks" [ $? -eq 0 ] && break i=$((i + 1)) echo "$i" done umount /mnt Fixes: 5bcde4557862 ("f2fs: get rid of buffer_head use") Signed-off-by: Sheng Yong <shengyong1@xiaomi.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/f2fs/super.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index 86dd30eb50b1..f3d0495f3a5f 100644 --- a/fs/f2fs/super.c +++ b/fs/f2fs/super.c @@ -3446,6 +3446,7 @@ static int __f2fs_commit_super(struct f2fs_sb_info *sbi, struct folio *folio, f2fs_bug_on(sbi, 1); ret = submit_bio_wait(bio); + bio_put(bio); folio_end_writeback(folio); return ret; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 347/480] f2fs: fix to avoid invalid wait context issue 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (345 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 346/480] f2fs: fix bio memleak when committing super block Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 348/480] f2fs: fix KMSAN uninit-value in extent_info usage Greg Kroah-Hartman ` (144 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Chao Yu, Jaegeuk Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Chao Yu <chao@kernel.org> [ Upstream commit 90d5c9ba3ed91950f1546bf123a7a57cd958b452 ] ============================= [ BUG: Invalid wait context ] 6.13.0-rc1 #84 Tainted: G O ----------------------------- cat/56160 is trying to lock: ffff888105c86648 (&cprc->stat_lock){+.+.}-{3:3}, at: update_general_status+0x32a/0x8c0 [f2fs] other info that might help us debug this: context-{5:5} 2 locks held by cat/56160: #0: ffff88810a002a98 (&p->lock){+.+.}-{4:4}, at: seq_read_iter+0x56/0x4c0 #1: ffffffffa0462638 (f2fs_stat_lock){....}-{2:2}, at: stat_show+0x29/0x1020 [f2fs] stack backtrace: CPU: 0 UID: 0 PID: 56160 Comm: cat Tainted: G O 6.13.0-rc1 #84 Tainted: [O]=OOT_MODULE Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 Call Trace: <TASK> dump_stack_lvl+0x88/0xd0 dump_stack+0x14/0x20 __lock_acquire+0x8d4/0xbb0 lock_acquire+0xd6/0x300 _raw_spin_lock+0x38/0x50 update_general_status+0x32a/0x8c0 [f2fs] stat_show+0x50/0x1020 [f2fs] seq_read_iter+0x116/0x4c0 seq_read+0xfa/0x130 full_proxy_read+0x66/0x90 vfs_read+0xc4/0x350 ksys_read+0x74/0xf0 __x64_sys_read+0x1d/0x20 x64_sys_call+0x17d9/0x1b80 do_syscall_64+0x68/0x130 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f2ca53147e2 - seq_read - stat_show - raw_spin_lock_irqsave(&f2fs_stat_lock, flags) : f2fs_stat_lock is raw_spinlock_t type variable - update_general_status - spin_lock(&sbi->cprc_info.stat_lock); : stat_lock is spinlock_t type variable The root cause is the lock order is incorrect [1], we should not acquire spinlock_t lock after raw_spinlock_t lock, as if CONFIG_PREEMPT_LOCK is on, spinlock_t is implemented based on rtmutex, which can sleep after holding the lock. To fix this issue, let's use change f2fs_stat_lock lock type from raw_spinlock_t to spinlock_t, it's safe due to: - we don't need to use raw version of spinlock as the path is not performance sensitive. - we don't need to use irqsave version of spinlock as it won't be used in irq context. Quoted from [1]: "Extend lockdep to validate lock wait-type context. The current wait-types are: LD_WAIT_FREE, /* wait free, rcu etc.. */ LD_WAIT_SPIN, /* spin loops, raw_spinlock_t etc.. */ LD_WAIT_CONFIG, /* CONFIG_PREEMPT_LOCK, spinlock_t etc.. */ LD_WAIT_SLEEP, /* sleeping locks, mutex_t etc.. */ Where lockdep validates that the current lock (the one being acquired) fits in the current wait-context (as generated by the held stack). This ensures that there is no attempt to acquire mutexes while holding spinlocks, to acquire spinlocks while holding raw_spinlocks and so on. In other words, its a more fancy might_sleep()." [1] https://lore.kernel.org/all/20200321113242.427089655@linutronix.de Fixes: 98237fcda4a2 ("f2fs: use spin_lock to avoid hang") Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/f2fs/debug.c | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c index 16c2dfb4f595..3417e7e550b2 100644 --- a/fs/f2fs/debug.c +++ b/fs/f2fs/debug.c @@ -21,7 +21,7 @@ #include "gc.h" static LIST_HEAD(f2fs_stat_list); -static DEFINE_RAW_SPINLOCK(f2fs_stat_lock); +static DEFINE_SPINLOCK(f2fs_stat_lock); #ifdef CONFIG_DEBUG_FS static struct dentry *f2fs_debugfs_root; #endif @@ -439,9 +439,8 @@ static int stat_show(struct seq_file *s, void *v) { struct f2fs_stat_info *si; int i = 0, j = 0; - unsigned long flags; - raw_spin_lock_irqsave(&f2fs_stat_lock, flags); + spin_lock(&f2fs_stat_lock); list_for_each_entry(si, &f2fs_stat_list, stat_list) { struct f2fs_sb_info *sbi = si->sbi; @@ -753,7 +752,7 @@ static int stat_show(struct seq_file *s, void *v) seq_printf(s, " - paged : %llu KB\n", si->page_mem >> 10); } - raw_spin_unlock_irqrestore(&f2fs_stat_lock, flags); + spin_unlock(&f2fs_stat_lock); return 0; } @@ -765,7 +764,6 @@ int f2fs_build_stats(struct f2fs_sb_info *sbi) struct f2fs_super_block *raw_super = F2FS_RAW_SUPER(sbi); struct f2fs_stat_info *si; struct f2fs_dev_stats *dev_stats; - unsigned long flags; int i; si = f2fs_kzalloc(sbi, sizeof(struct f2fs_stat_info), GFP_KERNEL); @@ -817,9 +815,9 @@ int f2fs_build_stats(struct f2fs_sb_info *sbi) atomic_set(&sbi->max_aw_cnt, 0); - raw_spin_lock_irqsave(&f2fs_stat_lock, flags); + spin_lock(&f2fs_stat_lock); list_add_tail(&si->stat_list, &f2fs_stat_list); - raw_spin_unlock_irqrestore(&f2fs_stat_lock, flags); + spin_unlock(&f2fs_stat_lock); return 0; } @@ -827,11 +825,10 @@ int f2fs_build_stats(struct f2fs_sb_info *sbi) void f2fs_destroy_stats(struct f2fs_sb_info *sbi) { struct f2fs_stat_info *si = F2FS_STAT(sbi); - unsigned long flags; - raw_spin_lock_irqsave(&f2fs_stat_lock, flags); + spin_lock(&f2fs_stat_lock); list_del(&si->stat_list); - raw_spin_unlock_irqrestore(&f2fs_stat_lock, flags); + spin_unlock(&f2fs_stat_lock); kfree(si->dev_stats); kfree(si); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 348/480] f2fs: fix KMSAN uninit-value in extent_info usage 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (346 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 347/480] f2fs: fix to avoid invalid wait context issue Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 349/480] f2fs: fix to check upper boundary for value of gc_boost_zoned_gc_percent Greg Kroah-Hartman ` (143 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, syzbot+b8c1d60e95df65e827d4, Chao Yu, Abinash Singh, Jaegeuk Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Abinash Singh <abinashlalotra@gmail.com> [ Upstream commit 154467f4ad033473e5c903a03e7b9bca7df9a0fa ] KMSAN reported a use of uninitialized value in `__is_extent_mergeable()` and `__is_back_mergeable()` via the read extent tree path. The root cause is that `get_read_extent_info()` only initializes three fields (`fofs`, `blk`, `len`) of `struct extent_info`, leaving the remaining fields uninitialized. This leads to undefined behavior when those fields are accessed later, especially during extent merging. Fix it by zero-initializing the `extent_info` struct before population. Reported-by: syzbot+b8c1d60e95df65e827d4@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b8c1d60e95df65e827d4 Fixes: 94afd6d6e525 ("f2fs: extent cache: support unaligned extent") Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Abinash Singh <abinashsinghlalotra@gmail.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/f2fs/extent_cache.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/extent_cache.c b/fs/f2fs/extent_cache.c index 347b3b647834..c4d79ab0ae91 100644 --- a/fs/f2fs/extent_cache.c +++ b/fs/f2fs/extent_cache.c @@ -414,7 +414,7 @@ void f2fs_init_read_extent_tree(struct inode *inode, struct page *ipage) struct f2fs_extent *i_ext = &F2FS_INODE(ipage)->i_ext; struct extent_tree *et; struct extent_node *en; - struct extent_info ei; + struct extent_info ei = {0}; if (!__may_extent_tree(inode, EX_READ)) { /* drop largest read extent */ -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 349/480] f2fs: fix to check upper boundary for value of gc_boost_zoned_gc_percent 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (347 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 348/480] f2fs: fix KMSAN uninit-value in extent_info usage Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 350/480] f2fs: fix to check upper boundary for gc_valid_thresh_ratio Greg Kroah-Hartman ` (142 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, yohan.joung, Chao Yu, Jaegeuk Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: yohan.joung <yohan.joung@sk.com> [ Upstream commit 10dcaa56ef93f2a45e4c3fec27d8e1594edad110 ] to check the upper boundary when setting gc_boost_zoned_gc_percent Fixes: 9a481a1c16f4 ("f2fs: create gc_no_zoned_gc_percent and gc_boost_zoned_gc_percent") Signed-off-by: yohan.joung <yohan.joung@sk.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/f2fs/sysfs.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c index c69161366467..932df15df328 100644 --- a/fs/f2fs/sysfs.c +++ b/fs/f2fs/sysfs.c @@ -621,6 +621,13 @@ static ssize_t __sbi_store(struct f2fs_attr *a, return count; } + if (!strcmp(a->attr.name, "gc_boost_zoned_gc_percent")) { + if (t > 100) + return -EINVAL; + *ui = (unsigned int)t; + return count; + } + #ifdef CONFIG_F2FS_IOSTAT if (!strcmp(a->attr.name, "iostat_enable")) { sbi->iostat_enable = !!t; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 350/480] f2fs: fix to check upper boundary for gc_valid_thresh_ratio 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (348 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 349/480] f2fs: fix to check upper boundary for value of gc_boost_zoned_gc_percent Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 351/480] f2fs: fix to check upper boundary for gc_no_zoned_gc_percent Greg Kroah-Hartman ` (141 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Daeho Jeong, Chao Yu, Jaegeuk Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Chao Yu <chao@kernel.org> [ Upstream commit 7a96d1d73ce9de5041e891a623b722f900651561 ] This patch adds missing upper boundary check while setting gc_valid_thresh_ratio via sysfs. Fixes: e791d00bd06c ("f2fs: add valid block ratio not to do excessive GC for one time GC") Cc: Daeho Jeong <daehojeong@google.com> Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/f2fs/sysfs.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c index 932df15df328..db5418f72ff8 100644 --- a/fs/f2fs/sysfs.c +++ b/fs/f2fs/sysfs.c @@ -628,6 +628,13 @@ static ssize_t __sbi_store(struct f2fs_attr *a, return count; } + if (!strcmp(a->attr.name, "gc_valid_thresh_ratio")) { + if (t > 100) + return -EINVAL; + *ui = (unsigned int)t; + return count; + } + #ifdef CONFIG_F2FS_IOSTAT if (!strcmp(a->attr.name, "iostat_enable")) { sbi->iostat_enable = !!t; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 351/480] f2fs: fix to check upper boundary for gc_no_zoned_gc_percent 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (349 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 350/480] f2fs: fix to check upper boundary for gc_valid_thresh_ratio Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 352/480] f2fs: doc: fix wrong quota mount option description Greg Kroah-Hartman ` (140 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Daeho Jeong, Chao Yu, Jaegeuk Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Chao Yu <chao@kernel.org> [ Upstream commit a919ae794ad2dc6d04b3eea2f9bc86332c1630cc ] This patch adds missing upper boundary check while setting gc_no_zoned_gc_percent via sysfs. Fixes: 9a481a1c16f4 ("f2fs: create gc_no_zoned_gc_percent and gc_boost_zoned_gc_percent") Cc: Daeho Jeong <daehojeong@google.com> Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/f2fs/sysfs.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c index db5418f72ff8..05e5d8316c70 100644 --- a/fs/f2fs/sysfs.c +++ b/fs/f2fs/sysfs.c @@ -621,6 +621,13 @@ static ssize_t __sbi_store(struct f2fs_attr *a, return count; } + if (!strcmp(a->attr.name, "gc_no_zoned_gc_percent")) { + if (t > 100) + return -EINVAL; + *ui = (unsigned int)t; + return count; + } + if (!strcmp(a->attr.name, "gc_boost_zoned_gc_percent")) { if (t > 100) return -EINVAL; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 352/480] f2fs: doc: fix wrong quota mount option description 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (350 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 351/480] f2fs: fix to check upper boundary for gc_no_zoned_gc_percent Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 353/480] f2fs: fix to avoid UAF in f2fs_sync_inode_meta() Greg Kroah-Hartman ` (139 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Chao Yu, Jaegeuk Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Chao Yu <chao@kernel.org> [ Upstream commit 81b6ecca2f15922e8d653dc037df5871e754be6e ] We should use "{usr,grp,prj}jquota=" to disable journaled quota, rather than using off{usr,grp,prj}jquota. Fixes: 4b2414d04e99 ("f2fs: support journalled quota") Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- Documentation/filesystems/f2fs.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst index e15c4275862a..edfd30b198f7 100644 --- a/Documentation/filesystems/f2fs.rst +++ b/Documentation/filesystems/f2fs.rst @@ -236,9 +236,9 @@ usrjquota=<file> Appoint specified file and type during mount, so that quota grpjquota=<file> information can be properly updated during recovery flow, prjjquota=<file> <quota file>: must be in root directory; jqfmt=<quota type> <quota type>: [vfsold,vfsv0,vfsv1]. -offusrjquota Turn off user journalled quota. -offgrpjquota Turn off group journalled quota. -offprjjquota Turn off project journalled quota. +usrjquota= Turn off user journalled quota. +grpjquota= Turn off group journalled quota. +prjjquota= Turn off project journalled quota. quota Enable plain user disk quota accounting. noquota Disable all plain disk quota option. alloc_mode=%s Adjust block allocation policy, which supports "reuse" -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 353/480] f2fs: fix to avoid UAF in f2fs_sync_inode_meta() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (351 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 352/480] f2fs: doc: fix wrong quota mount option description Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 354/480] f2fs: fix to avoid panic in f2fs_evict_inode Greg Kroah-Hartman ` (138 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Chao Yu, Jaegeuk Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Chao Yu <chao@kernel.org> [ Upstream commit 7c30d79930132466f5be7d0b57add14d1a016bda ] syzbot reported an UAF issue as below: [1] [2] [1] https://syzkaller.appspot.com/text?tag=CrashReport&x=16594c60580000 ================================================================== BUG: KASAN: use-after-free in __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 Read of size 8 at addr ffff888100567dc8 by task kworker/u4:0/8 CPU: 1 PID: 8 Comm: kworker/u4:0 Tainted: G W 6.1.129-syzkaller-00017-g642656a36791 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Workqueue: writeback wb_workfn (flush-7:0) Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x151/0x1b7 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:316 [inline] print_report+0x158/0x4e0 mm/kasan/report.c:427 kasan_report+0x13c/0x170 mm/kasan/report.c:531 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:351 __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 __list_del_entry include/linux/list.h:134 [inline] list_del_init include/linux/list.h:206 [inline] f2fs_inode_synced+0x100/0x2e0 fs/f2fs/super.c:1553 f2fs_update_inode+0x72/0x1c40 fs/f2fs/inode.c:588 f2fs_update_inode_page+0x135/0x170 fs/f2fs/inode.c:706 f2fs_write_inode+0x416/0x790 fs/f2fs/inode.c:734 write_inode fs/fs-writeback.c:1460 [inline] __writeback_single_inode+0x4cf/0xb80 fs/fs-writeback.c:1677 writeback_sb_inodes+0xb32/0x1910 fs/fs-writeback.c:1903 __writeback_inodes_wb+0x118/0x3f0 fs/fs-writeback.c:1974 wb_writeback+0x3da/0xa00 fs/fs-writeback.c:2081 wb_check_background_flush fs/fs-writeback.c:2151 [inline] wb_do_writeback fs/fs-writeback.c:2239 [inline] wb_workfn+0xbba/0x1030 fs/fs-writeback.c:2266 process_one_work+0x73d/0xcb0 kernel/workqueue.c:2299 worker_thread+0xa60/0x1260 kernel/workqueue.c:2446 kthread+0x26d/0x300 kernel/kthread.c:386 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> Allocated by task 298: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x4b/0x70 mm/kasan/common.c:52 kasan_save_alloc_info+0x1f/0x30 mm/kasan/generic.c:505 __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:333 kasan_slab_alloc include/linux/kasan.h:202 [inline] slab_post_alloc_hook+0x53/0x2c0 mm/slab.h:768 slab_alloc_node mm/slub.c:3421 [inline] slab_alloc mm/slub.c:3431 [inline] __kmem_cache_alloc_lru mm/slub.c:3438 [inline] kmem_cache_alloc_lru+0x102/0x270 mm/slub.c:3454 alloc_inode_sb include/linux/fs.h:3255 [inline] f2fs_alloc_inode+0x2d/0x350 fs/f2fs/super.c:1437 alloc_inode fs/inode.c:261 [inline] iget_locked+0x18c/0x7e0 fs/inode.c:1373 f2fs_iget+0x55/0x4ca0 fs/f2fs/inode.c:486 f2fs_lookup+0x3c1/0xb50 fs/f2fs/namei.c:484 __lookup_slow+0x2b9/0x3e0 fs/namei.c:1689 lookup_slow+0x5a/0x80 fs/namei.c:1706 walk_component+0x2e7/0x410 fs/namei.c:1997 lookup_last fs/namei.c:2454 [inline] path_lookupat+0x16d/0x450 fs/namei.c:2478 filename_lookup+0x251/0x600 fs/namei.c:2507 vfs_statx+0x107/0x4b0 fs/stat.c:229 vfs_fstatat fs/stat.c:267 [inline] vfs_lstat include/linux/fs.h:3434 [inline] __do_sys_newlstat fs/stat.c:423 [inline] __se_sys_newlstat+0xda/0x7c0 fs/stat.c:417 __x64_sys_newlstat+0x5b/0x70 fs/stat.c:417 x64_sys_call+0x52/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:7 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x3b/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x68/0xd2 Freed by task 0: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x4b/0x70 mm/kasan/common.c:52 kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:516 ____kasan_slab_free+0x131/0x180 mm/kasan/common.c:241 __kasan_slab_free+0x11/0x20 mm/kasan/common.c:249 kasan_slab_free include/linux/kasan.h:178 [inline] slab_free_hook mm/slub.c:1745 [inline] slab_free_freelist_hook mm/slub.c:1771 [inline] slab_free mm/slub.c:3686 [inline] kmem_cache_free+0x291/0x560 mm/slub.c:3711 f2fs_free_inode+0x24/0x30 fs/f2fs/super.c:1584 i_callback+0x4b/0x70 fs/inode.c:250 rcu_do_batch+0x552/0xbe0 kernel/rcu/tree.c:2297 rcu_core+0x502/0xf40 kernel/rcu/tree.c:2557 rcu_core_si+0x9/0x10 kernel/rcu/tree.c:2574 handle_softirqs+0x1db/0x650 kernel/softirq.c:624 __do_softirq kernel/softirq.c:662 [inline] invoke_softirq kernel/softirq.c:479 [inline] __irq_exit_rcu+0x52/0xf0 kernel/softirq.c:711 irq_exit_rcu+0x9/0x10 kernel/softirq.c:723 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1118 [inline] sysvec_apic_timer_interrupt+0xa9/0xc0 arch/x86/kernel/apic/apic.c:1118 asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:691 Last potentially related work creation: kasan_save_stack+0x3b/0x60 mm/kasan/common.c:45 __kasan_record_aux_stack+0xb4/0xc0 mm/kasan/generic.c:486 kasan_record_aux_stack_noalloc+0xb/0x10 mm/kasan/generic.c:496 __call_rcu_common kernel/rcu/tree.c:2807 [inline] call_rcu+0xdc/0x10f0 kernel/rcu/tree.c:2926 destroy_inode fs/inode.c:316 [inline] evict+0x87d/0x930 fs/inode.c:720 iput_final fs/inode.c:1834 [inline] iput+0x616/0x690 fs/inode.c:1860 do_unlinkat+0x4e1/0x920 fs/namei.c:4396 __do_sys_unlink fs/namei.c:4437 [inline] __se_sys_unlink fs/namei.c:4435 [inline] __x64_sys_unlink+0x49/0x50 fs/namei.c:4435 x64_sys_call+0x289/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:88 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x3b/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x68/0xd2 The buggy address belongs to the object at ffff888100567a10 which belongs to the cache f2fs_inode_cache of size 1360 The buggy address is located 952 bytes inside of 1360-byte region [ffff888100567a10, ffff888100567f60) The buggy address belongs to the physical page: page:ffffea0004015800 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x100560 head:ffffea0004015800 order:3 compound_mapcount:0 compound_pincount:0 flags: 0x4000000000010200(slab|head|zone=1) raw: 4000000000010200 0000000000000000 dead000000000122 ffff8881002c4d80 raw: 0000000000000000 0000000080160016 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 3, migratetype Reclaimable, gfp_mask 0xd2050(__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_RECLAIMABLE), pid 298, tgid 298 (syz-executor330), ts 26489303743, free_ts 0 set_page_owner include/linux/page_owner.h:33 [inline] post_alloc_hook+0x213/0x220 mm/page_alloc.c:2637 prep_new_page+0x1b/0x110 mm/page_alloc.c:2644 get_page_from_freelist+0x3a98/0x3b10 mm/page_alloc.c:4539 __alloc_pages+0x234/0x610 mm/page_alloc.c:5837 alloc_slab_page+0x6c/0xf0 include/linux/gfp.h:-1 allocate_slab mm/slub.c:1962 [inline] new_slab+0x90/0x3e0 mm/slub.c:2015 ___slab_alloc+0x6f9/0xb80 mm/slub.c:3203 __slab_alloc+0x5d/0xa0 mm/slub.c:3302 slab_alloc_node mm/slub.c:3387 [inline] slab_alloc mm/slub.c:3431 [inline] __kmem_cache_alloc_lru mm/slub.c:3438 [inline] kmem_cache_alloc_lru+0x149/0x270 mm/slub.c:3454 alloc_inode_sb include/linux/fs.h:3255 [inline] f2fs_alloc_inode+0x2d/0x350 fs/f2fs/super.c:1437 alloc_inode fs/inode.c:261 [inline] iget_locked+0x18c/0x7e0 fs/inode.c:1373 f2fs_iget+0x55/0x4ca0 fs/f2fs/inode.c:486 f2fs_fill_super+0x5360/0x6dc0 fs/f2fs/super.c:4488 mount_bdev+0x282/0x3b0 fs/super.c:1445 f2fs_mount+0x34/0x40 fs/f2fs/super.c:4743 legacy_get_tree+0xf1/0x190 fs/fs_context.c:632 page_owner free stack trace missing Memory state around the buggy address: ffff888100567c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888100567d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100567d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888100567e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888100567e80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== [2] https://syzkaller.appspot.com/text?tag=CrashLog&x=13654c60580000 [ 24.675720][ T28] audit: type=1400 audit(1745327318.732:72): avc: denied { write } for pid=298 comm="syz-executor399" name="/" dev="loop0" ino=3 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:unlabeled_t tclass=dir permissive=1 [ 24.705426][ T296] ------------[ cut here ]------------ [ 24.706608][ T28] audit: type=1400 audit(1745327318.732:73): avc: denied { remove_name } for pid=298 comm="syz-executor399" name="file0" dev="loop0" ino=4 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:unlabeled_t tclass=dir permissive=1 [ 24.711550][ T296] WARNING: CPU: 0 PID: 296 at fs/f2fs/inode.c:847 f2fs_evict_inode+0x1262/0x1540 [ 24.734141][ T28] audit: type=1400 audit(1745327318.732:74): avc: denied { rename } for pid=298 comm="syz-executor399" name="file0" dev="loop0" ino=4 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:unlabeled_t tclass=dir permissive=1 [ 24.742969][ T296] Modules linked in: [ 24.765201][ T28] audit: type=1400 audit(1745327318.732:75): avc: denied { add_name } for pid=298 comm="syz-executor399" name="bus" scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:unlabeled_t tclass=dir permissive=1 [ 24.768847][ T296] CPU: 0 PID: 296 Comm: syz-executor399 Not tainted 6.1.129-syzkaller-00017-g642656a36791 #0 [ 24.799506][ T296] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 [ 24.809401][ T296] RIP: 0010:f2fs_evict_inode+0x1262/0x1540 [ 24.815018][ T296] Code: 34 70 4a ff eb 0d e8 2d 70 4a ff 4d 89 e5 4c 8b 64 24 18 48 8b 5c 24 28 4c 89 e7 e8 78 38 03 00 e9 84 fc ff ff e8 0e 70 4a ff <0f> 0b 4c 89 f7 be 08 00 00 00 e8 7f 21 92 ff f0 41 80 0e 04 e9 61 [ 24.834584][ T296] RSP: 0018:ffffc90000db7a40 EFLAGS: 00010293 [ 24.840465][ T296] RAX: ffffffff822aca42 RBX: 0000000000000002 RCX: ffff888110948000 [ 24.848291][ T296] RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000 [ 24.856064][ T296] RBP: ffffc90000db7bb0 R08: ffffffff822ac6a8 R09: ffffed10200b005d [ 24.864073][ T296] R10: 0000000000000000 R11: dffffc0000000001 R12: ffff888100580000 [ 24.871812][ T296] R13: dffffc0000000000 R14: ffff88810fef4078 R15: 1ffff920001b6f5c The root cause is w/ a fuzzed image, f2fs may missed to clear FI_DIRTY_INODE flag for target inode, after f2fs_evict_inode(), the inode is still linked in sbi->inode_list[DIRTY_META] global list, once it triggers checkpoint, f2fs_sync_inode_meta() may access the released inode. In f2fs_evict_inode(), let's always call f2fs_inode_synced() to clear FI_DIRTY_INODE flag and drop inode from global dirty list to avoid this UAF issue. Fixes: 0f18b462b2e5 ("f2fs: flush inode metadata when checkpoint is doing") Closes: https://syzkaller.appspot.com/bug?extid=849174b2efaf0d8be6ba Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/f2fs/inode.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c index f5991e8751b9..b9a1e428b23f 100644 --- a/fs/f2fs/inode.c +++ b/fs/f2fs/inode.c @@ -950,8 +950,12 @@ void f2fs_evict_inode(struct inode *inode) if (likely(!f2fs_cp_error(sbi) && !is_sbi_flag_set(sbi, SBI_CP_DISABLED))) f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE)); - else - f2fs_inode_synced(inode); + + /* + * anyway, it needs to remove the inode from sbi->inode_list[DIRTY_META] + * list to avoid UAF in f2fs_sync_inode_meta() during checkpoint. + */ + f2fs_inode_synced(inode); /* for the case f2fs_new_inode() was failed, .i_ino is zero, skip it */ if (inode->i_ino) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 354/480] f2fs: fix to avoid panic in f2fs_evict_inode 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (352 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 353/480] f2fs: fix to avoid UAF in f2fs_sync_inode_meta() Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 355/480] f2fs: fix to avoid out-of-boundary access in devs.path Greg Kroah-Hartman ` (137 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Chao Yu, Jaegeuk Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Chao Yu <chao@kernel.org> [ Upstream commit a509a55f8eecc8970b3980c6f06886bbff0e2f68 ] As syzbot [1] reported as below: R10: 0000000000000100 R11: 0000000000000206 R12: 00007ffe17473450 R13: 00007f28b1c10854 R14: 000000000000dae5 R15: 00007ffe17474520 </TASK> ---[ end trace 0000000000000000 ]--- ================================================================== BUG: KASAN: use-after-free in __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 Read of size 8 at addr ffff88812d962278 by task syz-executor/564 CPU: 1 PID: 564 Comm: syz-executor Tainted: G W 6.1.129-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call Trace: <TASK> __dump_stack+0x21/0x24 lib/dump_stack.c:88 dump_stack_lvl+0xee/0x158 lib/dump_stack.c:106 print_address_description+0x71/0x210 mm/kasan/report.c:316 print_report+0x4a/0x60 mm/kasan/report.c:427 kasan_report+0x122/0x150 mm/kasan/report.c:531 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:351 __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62 __list_del_entry include/linux/list.h:134 [inline] list_del_init include/linux/list.h:206 [inline] f2fs_inode_synced+0xf7/0x2e0 fs/f2fs/super.c:1531 f2fs_update_inode+0x74/0x1c40 fs/f2fs/inode.c:585 f2fs_update_inode_page+0x137/0x170 fs/f2fs/inode.c:703 f2fs_write_inode+0x4ec/0x770 fs/f2fs/inode.c:731 write_inode fs/fs-writeback.c:1460 [inline] __writeback_single_inode+0x4a0/0xab0 fs/fs-writeback.c:1677 writeback_single_inode+0x221/0x8b0 fs/fs-writeback.c:1733 sync_inode_metadata+0xb6/0x110 fs/fs-writeback.c:2789 f2fs_sync_inode_meta+0x16d/0x2a0 fs/f2fs/checkpoint.c:1159 block_operations fs/f2fs/checkpoint.c:1269 [inline] f2fs_write_checkpoint+0xca3/0x2100 fs/f2fs/checkpoint.c:1658 kill_f2fs_super+0x231/0x390 fs/f2fs/super.c:4668 deactivate_locked_super+0x98/0x100 fs/super.c:332 deactivate_super+0xaf/0xe0 fs/super.c:363 cleanup_mnt+0x45f/0x4e0 fs/namespace.c:1186 __cleanup_mnt+0x19/0x20 fs/namespace.c:1193 task_work_run+0x1c6/0x230 kernel/task_work.c:203 exit_task_work include/linux/task_work.h:39 [inline] do_exit+0x9fb/0x2410 kernel/exit.c:871 do_group_exit+0x210/0x2d0 kernel/exit.c:1021 __do_sys_exit_group kernel/exit.c:1032 [inline] __se_sys_exit_group kernel/exit.c:1030 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1030 x64_sys_call+0x7b4/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x4c/0xa0 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x68/0xd2 RIP: 0033:0x7f28b1b8e169 Code: Unable to access opcode bytes at 0x7f28b1b8e13f. RSP: 002b:00007ffe174710a8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00007f28b1c10879 RCX: 00007f28b1b8e169 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001 RBP: 0000000000000002 R08: 00007ffe1746ee47 R09: 00007ffe17472360 R10: 0000000000000009 R11: 0000000000000246 R12: 00007ffe17472360 R13: 00007f28b1c10854 R14: 000000000000dae5 R15: 00007ffe17474520 </TASK> Allocated by task 569: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x4b/0x70 mm/kasan/common.c:52 kasan_save_alloc_info+0x25/0x30 mm/kasan/generic.c:505 __kasan_slab_alloc+0x72/0x80 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook+0x4f/0x2c0 mm/slab.h:737 slab_alloc_node mm/slub.c:3398 [inline] slab_alloc mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline] kmem_cache_alloc_lru+0x104/0x220 mm/slub.c:3429 alloc_inode_sb include/linux/fs.h:3245 [inline] f2fs_alloc_inode+0x2d/0x340 fs/f2fs/super.c:1419 alloc_inode fs/inode.c:261 [inline] iget_locked+0x186/0x880 fs/inode.c:1373 f2fs_iget+0x55/0x4c60 fs/f2fs/inode.c:483 f2fs_lookup+0x366/0xab0 fs/f2fs/namei.c:487 __lookup_slow+0x2a3/0x3d0 fs/namei.c:1690 lookup_slow+0x57/0x70 fs/namei.c:1707 walk_component+0x2e6/0x410 fs/namei.c:1998 lookup_last fs/namei.c:2455 [inline] path_lookupat+0x180/0x490 fs/namei.c:2479 filename_lookup+0x1f0/0x500 fs/namei.c:2508 vfs_statx+0x10b/0x660 fs/stat.c:229 vfs_fstatat fs/stat.c:267 [inline] vfs_lstat include/linux/fs.h:3424 [inline] __do_sys_newlstat fs/stat.c:423 [inline] __se_sys_newlstat+0xd5/0x350 fs/stat.c:417 __x64_sys_newlstat+0x5b/0x70 fs/stat.c:417 x64_sys_call+0x393/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:7 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x4c/0xa0 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x68/0xd2 Freed by task 13: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x4b/0x70 mm/kasan/common.c:52 kasan_save_free_info+0x31/0x50 mm/kasan/generic.c:516 ____kasan_slab_free+0x132/0x180 mm/kasan/common.c:236 __kasan_slab_free+0x11/0x20 mm/kasan/common.c:244 kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1724 [inline] slab_free_freelist_hook+0xc2/0x190 mm/slub.c:1750 slab_free mm/slub.c:3661 [inline] kmem_cache_free+0x12d/0x2a0 mm/slub.c:3683 f2fs_free_inode+0x24/0x30 fs/f2fs/super.c:1562 i_callback+0x4c/0x70 fs/inode.c:250 rcu_do_batch+0x503/0xb80 kernel/rcu/tree.c:2297 rcu_core+0x5a2/0xe70 kernel/rcu/tree.c:2557 rcu_core_si+0x9/0x10 kernel/rcu/tree.c:2574 handle_softirqs+0x178/0x500 kernel/softirq.c:578 run_ksoftirqd+0x28/0x30 kernel/softirq.c:945 smpboot_thread_fn+0x45a/0x8c0 kernel/smpboot.c:164 kthread+0x270/0x310 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 Last potentially related work creation: kasan_save_stack+0x3a/0x60 mm/kasan/common.c:45 __kasan_record_aux_stack+0xb6/0xc0 mm/kasan/generic.c:486 kasan_record_aux_stack_noalloc+0xb/0x10 mm/kasan/generic.c:496 call_rcu+0xd4/0xf70 kernel/rcu/tree.c:2845 destroy_inode fs/inode.c:316 [inline] evict+0x7da/0x870 fs/inode.c:720 iput_final fs/inode.c:1834 [inline] iput+0x62b/0x830 fs/inode.c:1860 do_unlinkat+0x356/0x540 fs/namei.c:4397 __do_sys_unlink fs/namei.c:4438 [inline] __se_sys_unlink fs/namei.c:4436 [inline] __x64_sys_unlink+0x49/0x50 fs/namei.c:4436 x64_sys_call+0x958/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:88 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x4c/0xa0 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x68/0xd2 The buggy address belongs to the object at ffff88812d961f20 which belongs to the cache f2fs_inode_cache of size 1200 The buggy address is located 856 bytes inside of 1200-byte region [ffff88812d961f20, ffff88812d9623d0) The buggy address belongs to the physical page: page:ffffea0004b65800 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x12d960 head:ffffea0004b65800 order:2 compound_mapcount:0 compound_pincount:0 flags: 0x4000000000010200(slab|head|zone=1) raw: 4000000000010200 0000000000000000 dead000000000122 ffff88810a94c500 raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 2, migratetype Reclaimable, gfp_mask 0x1d2050(__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_RECLAIMABLE), pid 569, tgid 568 (syz.2.16), ts 55943246141, free_ts 0 set_page_owner include/linux/page_owner.h:31 [inline] post_alloc_hook+0x1d0/0x1f0 mm/page_alloc.c:2532 prep_new_page mm/page_alloc.c:2539 [inline] get_page_from_freelist+0x2e63/0x2ef0 mm/page_alloc.c:4328 __alloc_pages+0x235/0x4b0 mm/page_alloc.c:5605 alloc_slab_page include/linux/gfp.h:-1 [inline] allocate_slab mm/slub.c:1939 [inline] new_slab+0xec/0x4b0 mm/slub.c:1992 ___slab_alloc+0x6f6/0xb50 mm/slub.c:3180 __slab_alloc+0x5e/0xa0 mm/slub.c:3279 slab_alloc_node mm/slub.c:3364 [inline] slab_alloc mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline] kmem_cache_alloc_lru+0x13f/0x220 mm/slub.c:3429 alloc_inode_sb include/linux/fs.h:3245 [inline] f2fs_alloc_inode+0x2d/0x340 fs/f2fs/super.c:1419 alloc_inode fs/inode.c:261 [inline] iget_locked+0x186/0x880 fs/inode.c:1373 f2fs_iget+0x55/0x4c60 fs/f2fs/inode.c:483 f2fs_fill_super+0x3ad7/0x6bb0 fs/f2fs/super.c:4293 mount_bdev+0x2ae/0x3e0 fs/super.c:1443 f2fs_mount+0x34/0x40 fs/f2fs/super.c:4642 legacy_get_tree+0xea/0x190 fs/fs_context.c:632 vfs_get_tree+0x89/0x260 fs/super.c:1573 do_new_mount+0x25a/0xa20 fs/namespace.c:3056 page_owner free stack trace missing Memory state around the buggy address: ffff88812d962100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88812d962180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff88812d962200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88812d962280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88812d962300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== [1] https://syzkaller.appspot.com/x/report.txt?x=13448368580000 This bug can be reproduced w/ the reproducer [2], once we enable CONFIG_F2FS_CHECK_FS config, the reproducer will trigger panic as below, so the direct reason of this bug is the same as the one below patch [3] fixed. kernel BUG at fs/f2fs/inode.c:857! RIP: 0010:f2fs_evict_inode+0x1204/0x1a20 Call Trace: <TASK> evict+0x32a/0x7a0 do_unlinkat+0x37b/0x5b0 __x64_sys_unlink+0xad/0x100 do_syscall_64+0x5a/0xb0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0010:f2fs_evict_inode+0x1204/0x1a20 [2] https://syzkaller.appspot.com/x/repro.c?x=17495ccc580000 [3] https://lore.kernel.org/linux-f2fs-devel/20250702120321.1080759-1-chao@kernel.org Tracepoints before panic: f2fs_unlink_enter: dev = (7,0), dir ino = 3, i_size = 4096, i_blocks = 8, name = file1 f2fs_unlink_exit: dev = (7,0), ino = 7, ret = 0 f2fs_evict_inode: dev = (7,0), ino = 7, pino = 3, i_mode = 0x81ed, i_size = 10, i_nlink = 0, i_blocks = 0, i_advise = 0x0 f2fs_truncate_node: dev = (7,0), ino = 7, nid = 8, block_address = 0x3c05 f2fs_unlink_enter: dev = (7,0), dir ino = 3, i_size = 4096, i_blocks = 8, name = file3 f2fs_unlink_exit: dev = (7,0), ino = 8, ret = 0 f2fs_evict_inode: dev = (7,0), ino = 8, pino = 3, i_mode = 0x81ed, i_size = 9000, i_nlink = 0, i_blocks = 24, i_advise = 0x4 f2fs_truncate: dev = (7,0), ino = 8, pino = 3, i_mode = 0x81ed, i_size = 0, i_nlink = 0, i_blocks = 24, i_advise = 0x4 f2fs_truncate_blocks_enter: dev = (7,0), ino = 8, i_size = 0, i_blocks = 24, start file offset = 0 f2fs_truncate_blocks_exit: dev = (7,0), ino = 8, ret = -2 The root cause is: in the fuzzed image, dnode #8 belongs to inode #7, after inode #7 eviction, dnode #8 was dropped. However there is dirent that has ino #8, so, once we unlink file3, in f2fs_evict_inode(), both f2fs_truncate() and f2fs_update_inode_page() will fail due to we can not load node #8, result in we missed to call f2fs_inode_synced() to clear inode dirty status. Let's fix this by calling f2fs_inode_synced() in error path of f2fs_evict_inode(). PS: As I verified, the reproducer [2] can trigger this bug in v6.1.129, but it failed in v6.16-rc4, this is because the testcase will stop due to other corruption has been detected by f2fs: F2FS-fs (loop0): inconsistent node block, node_type:2, nid:8, node_footer[nid:8,ino:8,ofs:0,cpver:5013063228981249506,blkaddr:15366] F2FS-fs (loop0): f2fs_lookup: inode (ino=9) has zero i_nlink Fixes: 0f18b462b2e5 ("f2fs: flush inode metadata when checkpoint is doing") Closes: https://syzkaller.appspot.com/x/report.txt?x=13448368580000 Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/f2fs/inode.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c index b9a1e428b23f..f3c5e6e7579b 100644 --- a/fs/f2fs/inode.c +++ b/fs/f2fs/inode.c @@ -934,6 +934,19 @@ void f2fs_evict_inode(struct inode *inode) f2fs_update_inode_page(inode); if (dquot_initialize_needed(inode)) set_sbi_flag(sbi, SBI_QUOTA_NEED_REPAIR); + + /* + * If both f2fs_truncate() and f2fs_update_inode_page() failed + * due to fuzzed corrupted inode, call f2fs_inode_synced() to + * avoid triggering later f2fs_bug_on(). + */ + if (is_inode_flag_set(inode, FI_DIRTY_INODE)) { + f2fs_warn(sbi, + "f2fs_evict_inode: inode is dirty, ino:%lu", + inode->i_ino); + f2fs_inode_synced(inode); + set_sbi_flag(sbi, SBI_NEED_FSCK); + } } if (freeze_protected) sb_end_intwrite(inode->i_sb); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 355/480] f2fs: fix to avoid out-of-boundary access in devs.path 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (353 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 354/480] f2fs: fix to avoid panic in f2fs_evict_inode Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 356/480] f2fs: vm_unmap_ram() may be called from an invalid context Greg Kroah-Hartman ` (136 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Chao Yu, Jaegeuk Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Chao Yu <chao@kernel.org> [ Upstream commit 5661998536af52848cc4d52a377e90368196edea ] - touch /mnt/f2fs/012345678901234567890123456789012345678901234567890123 - truncate -s $((1024*1024*1024)) \ /mnt/f2fs/012345678901234567890123456789012345678901234567890123 - touch /mnt/f2fs/file - truncate -s $((1024*1024*1024)) /mnt/f2fs/file - mkfs.f2fs /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \ -c /mnt/f2fs/file - mount /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \ /mnt/f2fs/loop [16937.192225] F2FS-fs (loop0): Mount Device [ 0]: /mnt/f2fs/012345678901234567890123456789012345678901234567890123\xff\x01, 511, 0 - 3ffff [16937.192268] F2FS-fs (loop0): Failed to find devices If device path length equals to MAX_PATH_LEN, sbi->devs.path[] may not end up w/ null character due to path array is fully filled, So accidently, fields locate after path[] may be treated as part of device path, result in parsing wrong device path. struct f2fs_dev_info { ... char path[MAX_PATH_LEN]; ... }; Let's add one byte space for sbi->devs.path[] to store null character of device path string. Fixes: 3c62be17d4f5 ("f2fs: support multiple devices") Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/f2fs/f2fs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index 34e4ae2a5f5b..8a8d15c219dc 100644 --- a/fs/f2fs/f2fs.h +++ b/fs/f2fs/f2fs.h @@ -1273,7 +1273,7 @@ struct f2fs_bio_info { struct f2fs_dev_info { struct file *bdev_file; struct block_device *bdev; - char path[MAX_PATH_LEN]; + char path[MAX_PATH_LEN + 1]; unsigned int total_segments; block_t start_blk; block_t end_blk; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 356/480] f2fs: vm_unmap_ram() may be called from an invalid context 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (354 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 355/480] f2fs: fix to avoid out-of-boundary access in devs.path Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 357/480] f2fs: fix to update upper_p in __get_secs_required() correctly Greg Kroah-Hartman ` (135 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Jan Prusakowski, Chao Yu, Jaegeuk Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jan Prusakowski <jprusakowski@google.com> [ Upstream commit 08a7efc5b02a0620ae16aa9584060e980a69cb55 ] When testing F2FS with xfstests using UFS backed virtual disks the kernel complains sometimes that f2fs_release_decomp_mem() calls vm_unmap_ram() from an invalid context. Example trace from f2fs/007 test: f2fs/007 5s ... [12:59:38][ 8.902525] run fstests f2fs/007 [ 11.468026] BUG: sleeping function called from invalid context at mm/vmalloc.c:2978 [ 11.471849] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 68, name: irq/22-ufshcd [ 11.475357] preempt_count: 1, expected: 0 [ 11.476970] RCU nest depth: 0, expected: 0 [ 11.478531] CPU: 0 UID: 0 PID: 68 Comm: irq/22-ufshcd Tainted: G W 6.16.0-rc5-xfstests-ufs-g40f92e79b0aa #9 PREEMPT(none) [ 11.478535] Tainted: [W]=WARN [ 11.478536] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 11.478537] Call Trace: [ 11.478543] <TASK> [ 11.478545] dump_stack_lvl+0x4e/0x70 [ 11.478554] __might_resched.cold+0xaf/0xbe [ 11.478557] vm_unmap_ram+0x21/0xb0 [ 11.478560] f2fs_release_decomp_mem+0x59/0x80 [ 11.478563] f2fs_free_dic+0x18/0x1a0 [ 11.478565] f2fs_finish_read_bio+0xd7/0x290 [ 11.478570] blk_update_request+0xec/0x3b0 [ 11.478574] ? sbitmap_queue_clear+0x3b/0x60 [ 11.478576] scsi_end_request+0x27/0x1a0 [ 11.478582] scsi_io_completion+0x40/0x300 [ 11.478583] ufshcd_mcq_poll_cqe_lock+0xa3/0xe0 [ 11.478588] ufshcd_sl_intr+0x194/0x1f0 [ 11.478592] ufshcd_threaded_intr+0x68/0xb0 [ 11.478594] ? __pfx_irq_thread_fn+0x10/0x10 [ 11.478599] irq_thread_fn+0x20/0x60 [ 11.478602] ? __pfx_irq_thread_fn+0x10/0x10 [ 11.478603] irq_thread+0xb9/0x180 [ 11.478605] ? __pfx_irq_thread_dtor+0x10/0x10 [ 11.478607] ? __pfx_irq_thread+0x10/0x10 [ 11.478609] kthread+0x10a/0x230 [ 11.478614] ? __pfx_kthread+0x10/0x10 [ 11.478615] ret_from_fork+0x7e/0xd0 [ 11.478619] ? __pfx_kthread+0x10/0x10 [ 11.478621] ret_from_fork_asm+0x1a/0x30 [ 11.478623] </TASK> This patch modifies in_task() check inside f2fs_read_end_io() to also check if interrupts are disabled. This ensures that pages are unmapped asynchronously in an interrupt handler. Fixes: bff139b49d9f ("f2fs: handle decompress only post processing in softirq") Signed-off-by: Jan Prusakowski <jprusakowski@google.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/f2fs/data.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index b0b8748ae287..84d45e58a5ff 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -282,7 +282,7 @@ static void f2fs_read_end_io(struct bio *bio) { struct f2fs_sb_info *sbi = F2FS_P_SB(bio_first_page_all(bio)); struct bio_post_read_ctx *ctx; - bool intask = in_task(); + bool intask = in_task() && !irqs_disabled(); iostat_update_and_unbind_ctx(bio); ctx = bio->bi_private; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 357/480] f2fs: fix to update upper_p in __get_secs_required() correctly 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (355 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 356/480] f2fs: vm_unmap_ram() may be called from an invalid context Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 358/480] f2fs: fix to calculate dirty data during has_not_enough_free_secs() Greg Kroah-Hartman ` (134 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Daeho Jeong, Chao Yu, Jaegeuk Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Chao Yu <chao@kernel.org> [ Upstream commit 6840faddb65683b4e7bd8196f177b038a1e19faf ] Commit 1acd73edbbfe ("f2fs: fix to account dirty data in __get_secs_required()") missed to calculate upper_p w/ data_secs, fix it. Fixes: 1acd73edbbfe ("f2fs: fix to account dirty data in __get_secs_required()") Cc: Daeho Jeong <daehojeong@google.com> Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/f2fs/segment.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h index 503f6df690bf..4c3a0d54be7e 100644 --- a/fs/f2fs/segment.h +++ b/fs/f2fs/segment.h @@ -633,7 +633,7 @@ static inline void __get_secs_required(struct f2fs_sb_info *sbi, if (lower_p) *lower_p = node_secs + dent_secs + data_secs; if (upper_p) - *upper_p = node_secs + dent_secs + + *upper_p = node_secs + dent_secs + data_secs + (node_blocks ? 1 : 0) + (dent_blocks ? 1 : 0) + (data_blocks ? 1 : 0); if (curseg_p) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 358/480] f2fs: fix to calculate dirty data during has_not_enough_free_secs() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (356 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 357/480] f2fs: fix to update upper_p in __get_secs_required() correctly Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 359/480] f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode Greg Kroah-Hartman ` (133 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Daeho Jeong, Chao Yu, Jaegeuk Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Chao Yu <chao@kernel.org> [ Upstream commit e194e140ab7de2ce2782e64b9e086a43ca6ff4f2 ] In lfs mode, dirty data needs OPU, we'd better calculate lower_p and upper_p w/ them during has_not_enough_free_secs(), otherwise we may encounter out-of-space issue due to we missed to reclaim enough free section w/ foreground gc. Fixes: 36abef4e796d ("f2fs: introduce mode=lfs mount option") Cc: Daeho Jeong <daehojeong@google.com> Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/f2fs/segment.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h index 4c3a0d54be7e..4e0a56f10780 100644 --- a/fs/f2fs/segment.h +++ b/fs/f2fs/segment.h @@ -623,8 +623,7 @@ static inline void __get_secs_required(struct f2fs_sb_info *sbi, unsigned int dent_blocks = total_dent_blocks % CAP_BLKS_PER_SEC(sbi); unsigned int data_blocks = 0; - if (f2fs_lfs_mode(sbi) && - unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED))) { + if (f2fs_lfs_mode(sbi)) { total_data_blocks = get_pages(sbi, F2FS_DIRTY_DATA); data_secs = total_data_blocks / CAP_BLKS_PER_SEC(sbi); data_blocks = total_data_blocks % CAP_BLKS_PER_SEC(sbi); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 359/480] f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (357 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 358/480] f2fs: fix to calculate dirty data during has_not_enough_free_secs() Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 360/480] exfat: fdatasync flag should be same like generic_write_sync() Greg Kroah-Hartman ` (132 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Daeho Jeong, Chao Yu, Jaegeuk Kim, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Chao Yu <chao@kernel.org> [ Upstream commit 1005a3ca28e90c7a64fa43023f866b960a60f791 ] w/ "mode=lfs" mount option, generic/299 will cause system panic as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2835! Call Trace: <TASK> f2fs_allocate_data_block+0x6f4/0xc50 f2fs_map_blocks+0x970/0x1550 f2fs_iomap_begin+0xb2/0x1e0 iomap_iter+0x1d6/0x430 __iomap_dio_rw+0x208/0x9a0 f2fs_file_write_iter+0x6b3/0xfa0 aio_write+0x15d/0x2e0 io_submit_one+0x55e/0xab0 __x64_sys_io_submit+0xa5/0x230 do_syscall_64+0x84/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0010:new_curseg+0x70f/0x720 The root cause of we run out-of-space is: in f2fs_map_blocks(), f2fs may trigger foreground gc only if it allocates any physical block, it will be a little bit later when there is multiple threads writing data w/ aio/dio/bufio method in parallel, since we always use OPU in lfs mode, so f2fs_map_blocks() does block allocations aggressively. In order to fix this issue, let's give a chance to trigger foreground gc in prior to block allocation in f2fs_map_blocks(). Fixes: 36abef4e796d ("f2fs: introduce mode=lfs mount option") Cc: Daeho Jeong <daehojeong@google.com> Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/f2fs/data.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index 84d45e58a5ff..80eb44dfe0f1 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -1572,8 +1572,11 @@ int f2fs_map_blocks(struct inode *inode, struct f2fs_map_blocks *map, int flag) end = pgofs + maxblocks; next_dnode: - if (map->m_may_create) + if (map->m_may_create) { + if (f2fs_lfs_mode(sbi)) + f2fs_balance_fs(sbi, true); f2fs_map_lock(sbi, flag); + } /* When reading holes, we need its node page */ set_new_dnode(&dn, inode, NULL, NULL, 0); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 360/480] exfat: fdatasync flag should be same like generic_write_sync() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (358 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 359/480] f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 361/480] i2c: muxes: mule: Fix an error handling path in mule_i2c_mux_probe() Greg Kroah-Hartman ` (131 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Zhengxu Zhang, Yuezhang Mo, Namjae Jeon, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Zhengxu Zhang <zhengxu.zhang@unisoc.com> [ Upstream commit 2f2d42a17b5a6711378d39df74f1f69a831c5d4e ] Test: androbench by default setting, use 64GB sdcard. the random write speed: without this patch 3.5MB/s with this patch 7MB/s After patch "11a347fb6cef", the random write speed decreased significantly. the .write_iter() interface had been modified, and check the differences with generic_file_write_iter(), when calling generic_write_sync() and exfat_file_write_iter() to call vfs_fsync_range(), the fdatasync flag is wrong, and make not use the fdatasync mode, and make random write speed decreased. So use generic_write_sync() instead of vfs_fsync_range(). Fixes: 11a347fb6cef ("exfat: change to get file size from DataLength") Signed-off-by: Zhengxu Zhang <zhengxu.zhang@unisoc.com> Acked-by: Yuezhang Mo <Yuezhang.Mo@sony.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/exfat/file.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/fs/exfat/file.c b/fs/exfat/file.c index 841a5b18e3df..7ac5126aa4f1 100644 --- a/fs/exfat/file.c +++ b/fs/exfat/file.c @@ -623,9 +623,8 @@ static ssize_t exfat_file_write_iter(struct kiocb *iocb, struct iov_iter *iter) if (pos > valid_size) pos = valid_size; - if (iocb_is_dsync(iocb) && iocb->ki_pos > pos) { - ssize_t err = vfs_fsync_range(file, pos, iocb->ki_pos - 1, - iocb->ki_flags & IOCB_SYNC); + if (iocb->ki_pos > pos) { + ssize_t err = generic_write_sync(iocb, iocb->ki_pos - pos); if (err < 0) return err; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 361/480] i2c: muxes: mule: Fix an error handling path in mule_i2c_mux_probe() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (359 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 360/480] exfat: fdatasync flag should be same like generic_write_sync() Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 362/480] vfio: Fix unbalanced vfio_df_close call in no-iommu mode Greg Kroah-Hartman ` (130 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Christophe JAILLET, Wolfram Sang, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Christophe JAILLET <christophe.jaillet@wanadoo.fr> [ Upstream commit 33ac5155891cab165c93b51b0e22e153eacc2ee7 ] If an error occurs in the loop that creates the device adapters, then a reference to 'dev' still needs to be released. Use for_each_child_of_node_scoped() to both fix the issue and save one line of code. Fixes: d0f8e97866bf ("i2c: muxes: add support for tsd,mule-i2c multiplexer") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/i2c/muxes/i2c-mux-mule.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/i2c/muxes/i2c-mux-mule.c b/drivers/i2c/muxes/i2c-mux-mule.c index 284ff4afeeac..d3b32b794172 100644 --- a/drivers/i2c/muxes/i2c-mux-mule.c +++ b/drivers/i2c/muxes/i2c-mux-mule.c @@ -47,7 +47,6 @@ static int mule_i2c_mux_probe(struct platform_device *pdev) struct mule_i2c_reg_mux *priv; struct i2c_client *client; struct i2c_mux_core *muxc; - struct device_node *dev; unsigned int readback; int ndev, ret; bool old_fw; @@ -95,7 +94,7 @@ static int mule_i2c_mux_probe(struct platform_device *pdev) "Failed to register mux remove\n"); /* Create device adapters */ - for_each_child_of_node(mux_dev->of_node, dev) { + for_each_child_of_node_scoped(mux_dev->of_node, dev) { u32 reg; ret = of_property_read_u32(dev, "reg", ®); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 362/480] vfio: Fix unbalanced vfio_df_close call in no-iommu mode 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (360 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 361/480] i2c: muxes: mule: Fix an error handling path in mule_i2c_mux_probe() Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 363/480] vfio: Prevent open_count decrement to negative Greg Kroah-Hartman ` (129 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Alex Williamson, Jason Gunthorpe, Jacob Pan, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jacob Pan <jacob.pan@linux.microsoft.com> [ Upstream commit b25e271b377999191b12f0afbe1861edcf57e3fe ] For devices with no-iommu enabled in IOMMUFD VFIO compat mode, the group open path skips vfio_df_open(), leaving open_count at 0. This causes a warning in vfio_assert_device_open(device) when vfio_df_close() is called during group close. The correct behavior is to skip only the IOMMUFD bind in the device open path for no-iommu devices. Commit 6086efe73498 omitted vfio_df_open(), which was too broad. This patch restores the previous behavior, ensuring the vfio_df_open is called in the group open path. Fixes: 6086efe73498 ("vfio-iommufd: Move noiommu compat validation out of vfio_iommufd_bind()") Suggested-by: Alex Williamson <alex.williamson@redhat.com> Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Jacob Pan <jacob.pan@linux.microsoft.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20250618234618.1910456-1-jacob.pan@linux.microsoft.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/vfio/group.c | 7 +++---- drivers/vfio/iommufd.c | 4 ++++ 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c index c321d442f0da..c376a6279de0 100644 --- a/drivers/vfio/group.c +++ b/drivers/vfio/group.c @@ -192,11 +192,10 @@ static int vfio_df_group_open(struct vfio_device_file *df) * implies they expected translation to exist */ if (!capable(CAP_SYS_RAWIO) || - vfio_iommufd_device_has_compat_ioas(device, df->iommufd)) + vfio_iommufd_device_has_compat_ioas(device, df->iommufd)) { ret = -EPERM; - else - ret = 0; - goto out_put_kvm; + goto out_put_kvm; + } } ret = vfio_df_open(df); diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c index c8c3a2d53f86..a38d262c6028 100644 --- a/drivers/vfio/iommufd.c +++ b/drivers/vfio/iommufd.c @@ -25,6 +25,10 @@ int vfio_df_iommufd_bind(struct vfio_device_file *df) lockdep_assert_held(&vdev->dev_set->lock); + /* Returns 0 to permit device opening under noiommu mode */ + if (vfio_device_is_noiommu(vdev)) + return 0; + return vdev->ops->bind_iommufd(vdev, ictx, &df->devid); } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 363/480] vfio: Prevent open_count decrement to negative 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (361 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 362/480] vfio: Fix unbalanced vfio_df_close call in no-iommu mode Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 364/480] vfio/pds: Fix missing detach_ioas op Greg Kroah-Hartman ` (128 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Jason Gunthorpe, Yi Liu, Jacob Pan, Alex Williamson, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jacob Pan <jacob.pan@linux.microsoft.com> [ Upstream commit 982ddd59ed97dc7e63efd97ed50273ffb817bd41 ] When vfio_df_close() is called with open_count=0, it triggers a warning in vfio_assert_device_open() but still decrements open_count to -1. This allows a subsequent open to incorrectly pass the open_count == 0 check, leading to unintended behavior, such as setting df->access_granted = true. For example, running an IOMMUFD compat no-IOMMU device with VFIO tests (https://github.com/awilliam/tests/blob/master/vfio-noiommu-pci-device-open.c) results in a warning and a failed VFIO_GROUP_GET_DEVICE_FD ioctl on the first run, but the second run succeeds incorrectly. Add checks to avoid decrementing open_count below zero. Fixes: 05f37e1c03b6 ("vfio: Pass struct vfio_device_file * to vfio_device_open/close()") Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Jacob Pan <jacob.pan@linux.microsoft.com> Link: https://lore.kernel.org/r/20250618234618.1910456-2-jacob.pan@linux.microsoft.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/vfio/vfio_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c index 1fd261efc582..5046cae05222 100644 --- a/drivers/vfio/vfio_main.c +++ b/drivers/vfio/vfio_main.c @@ -583,7 +583,8 @@ void vfio_df_close(struct vfio_device_file *df) lockdep_assert_held(&device->dev_set->lock); - vfio_assert_device_open(device); + if (!vfio_assert_device_open(device)) + return; if (device->open_count == 1) vfio_df_device_last_close(df); device->open_count--; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 364/480] vfio/pds: Fix missing detach_ioas op 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (362 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 363/480] vfio: Prevent open_count decrement to negative Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 365/480] vfio/pci: Separate SR-IOV VF dev_set Greg Kroah-Hartman ` (127 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Brett Creeley, Kevin Tian, Alex Williamson, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Brett Creeley <brett.creeley@amd.com> [ Upstream commit fe24d5bc635e103a517ec201c3cb571eeab8be2f ] When CONFIG_IOMMUFD is enabled and a device is bound to the pds_vfio_pci driver, the following WARN_ON() trace is seen and probe fails: WARNING: CPU: 0 PID: 5040 at drivers/vfio/vfio_main.c:317 __vfio_register_dev+0x130/0x140 [vfio] <...> pds_vfio_pci 0000:08:00.1: probe with driver pds_vfio_pci failed with error -22 This is because the driver's vfio_device_ops.detach_ioas isn't set. Fix this by using the generic vfio_iommufd_physical_detach_ioas function. Fixes: 38fe3975b4c2 ("vfio/pds: Initial support for pds VFIO driver") Signed-off-by: Brett Creeley <brett.creeley@amd.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20250702163744.69767-1-brett.creeley@amd.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/vfio/pci/pds/vfio_dev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vfio/pci/pds/vfio_dev.c b/drivers/vfio/pci/pds/vfio_dev.c index 76a80ae7087b..f6e0253a8a14 100644 --- a/drivers/vfio/pci/pds/vfio_dev.c +++ b/drivers/vfio/pci/pds/vfio_dev.c @@ -204,6 +204,7 @@ static const struct vfio_device_ops pds_vfio_ops = { .bind_iommufd = vfio_iommufd_physical_bind, .unbind_iommufd = vfio_iommufd_physical_unbind, .attach_ioas = vfio_iommufd_physical_attach_ioas, + .detach_ioas = vfio_iommufd_physical_detach_ioas, }; const struct vfio_device_ops *pds_vfio_ops_info(void) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 365/480] vfio/pci: Separate SR-IOV VF dev_set 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (363 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 364/480] vfio/pds: Fix missing detach_ioas op Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 366/480] scsi: mpt3sas: Fix a fw_event memory leak Greg Kroah-Hartman ` (126 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Aaron Lewis, Yi Liu, Kevin Tian, Jason Gunthorpe, Alex Williamson, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Alex Williamson <alex.williamson@redhat.com> [ Upstream commit e908f58b6beb337cbe4481d52c3f5c78167b1aab ] In the below noted Fixes commit we introduced a reflck mutex to allow better scaling between devices for open and close. The reflck was based on the hot reset granularity, device level for root bus devices which cannot support hot reset or bus/slot reset otherwise. Overlooked in this were SR-IOV VFs, where there's also no bus reset option, but the default for a non-root-bus, non-slot-based device is bus level reflck granularity. The reflck mutex has since become the dev_set mutex (via commit 2cd8b14aaa66 ("vfio/pci: Move to the device set infrastructure")) and is our defacto serialization for various operations and ioctls. It still seems to be the case though that sets of vfio-pci devices really only need serialization relative to hot resets affecting the entire set, which is not relevant to SR-IOV VFs. As described in the Closes link below, this serialization contributes to startup latency when multiple VFs sharing the same "bus" are opened concurrently. Mark the device itself as the basis of the dev_set for SR-IOV VFs. Reported-by: Aaron Lewis <aaronlewis@google.com> Closes: https://lore.kernel.org/all/20250626180424.632628-1-aaronlewis@google.com Tested-by: Aaron Lewis <aaronlewis@google.com> Fixes: e309df5b0c9e ("vfio/pci: Parallelize device open and release") Reviewed-by: Yi Liu <yi.l.liu@intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20250626225623.1180952-1-alex.williamson@redhat.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/vfio/pci/vfio_pci_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c index 6328c3a05bcd..261a6dc5a5fc 100644 --- a/drivers/vfio/pci/vfio_pci_core.c +++ b/drivers/vfio/pci/vfio_pci_core.c @@ -2149,7 +2149,7 @@ int vfio_pci_core_register_device(struct vfio_pci_core_device *vdev) return -EBUSY; } - if (pci_is_root_bus(pdev->bus)) { + if (pci_is_root_bus(pdev->bus) || pdev->is_virtfn) { ret = vfio_assign_device_set(&vdev->vdev, vdev); } else if (!pci_probe_reset_slot(pdev->slot)) { ret = vfio_assign_device_set(&vdev->vdev, pdev->slot); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 366/480] scsi: mpt3sas: Fix a fw_event memory leak 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (364 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 365/480] vfio/pci: Separate SR-IOV VF dev_set Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 367/480] scsi: Revert "scsi: iscsi: Fix HW conn removal use after free" Greg Kroah-Hartman ` (125 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Tomas Henzl, Sathya Prakash Veerichetty, Martin K. Petersen, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Tomas Henzl <thenzl@redhat.com> [ Upstream commit 3e90b38781e3bdd651edaf789585687611638862 ] In _mpt3sas_fw_work() the fw_event reference is removed, it should also be freed in all cases. Fixes: 4318c7347847 ("scsi: mpt3sas: Handle NVMe PCIe device related events generated from firmware.") Signed-off-by: Tomas Henzl <thenzl@redhat.com> Link: https://lore.kernel.org/r/20250723153018.50518-1-thenzl@redhat.com Acked-by: Sathya Prakash Veerichetty <sathya.prakash@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c index 508861e88d9f..0f900ddb3047 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c @@ -10790,8 +10790,7 @@ _mpt3sas_fw_work(struct MPT3SAS_ADAPTER *ioc, struct fw_event_work *fw_event) break; case MPI2_EVENT_PCIE_TOPOLOGY_CHANGE_LIST: _scsih_pcie_topology_change_event(ioc, fw_event); - ioc->current_event = NULL; - return; + break; } out: fw_event_work_put(fw_event); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 367/480] scsi: Revert "scsi: iscsi: Fix HW conn removal use after free" 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (365 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 366/480] scsi: mpt3sas: Fix a fw_event memory leak Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 368/480] scsi: ufs: core: Use link recovery when h8 exit fails during runtime resume Greg Kroah-Hartman ` (124 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Li Lingfeng, Mike Christie, Martin K. Petersen, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Li Lingfeng <lilingfeng3@huawei.com> [ Upstream commit 7bdc68921481c19cd8c85ddf805a834211c19e61 ] This reverts commit c577ab7ba5f3bf9062db8a58b6e89d4fe370447e. The invocation of iscsi_put_conn() in iscsi_iter_destory_conn_fn() is used to free the initial reference counter of iscsi_cls_conn. For non-qla4xxx cases, the ->destroy_conn() callback (e.g., iscsi_conn_teardown) will call iscsi_remove_conn() and iscsi_put_conn() to remove the connection from the children list of session and free the connection at last. However for qla4xxx, it is not the case. The ->destroy_conn() callback of qla4xxx will keep the connection in the session conn_list and doesn't use iscsi_put_conn() to free the initial reference counter. Therefore, it seems necessary to keep the iscsi_put_conn() in the iscsi_iter_destroy_conn_fn(), otherwise, there will be memory leak problem. Link: https://lore.kernel.org/all/88334658-072b-4b90-a949-9c74ef93cfd1@huawei.com/ Fixes: c577ab7ba5f3 ("scsi: iscsi: Fix HW conn removal use after free") Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com> Link: https://lore.kernel.org/r/20250715073926.3529456-1-lilingfeng3@huawei.com Reviewed-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/scsi/scsi_transport_iscsi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/scsi/scsi_transport_iscsi.c b/drivers/scsi/scsi_transport_iscsi.c index c75a806496d6..743b4c792ceb 100644 --- a/drivers/scsi/scsi_transport_iscsi.c +++ b/drivers/scsi/scsi_transport_iscsi.c @@ -2143,6 +2143,8 @@ static int iscsi_iter_destroy_conn_fn(struct device *dev, void *data) return 0; iscsi_remove_conn(iscsi_dev_to_conn(dev)); + iscsi_put_conn(iscsi_dev_to_conn(dev)); + return 0; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 368/480] scsi: ufs: core: Use link recovery when h8 exit fails during runtime resume 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (366 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 367/480] scsi: Revert "scsi: iscsi: Fix HW conn removal use after free" Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 369/480] scsi: sd: Make sd shutdown issue START STOP UNIT appropriately Greg Kroah-Hartman ` (123 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Seunghui Lee, Bean Huo, Bart Van Assche, Martin K. Petersen, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Seunghui Lee <sh043.lee@samsung.com> [ Upstream commit 35dabf4503b94a697bababe94678a8bc989c3223 ] If the h8 exit fails during runtime resume process, the runtime thread enters runtime suspend immediately and the error handler operates at the same time. It becomes stuck and cannot be recovered through the error handler. To fix this, use link recovery instead of the error handler. Fixes: 4db7a2360597 ("scsi: ufs: Fix concurrency of error handler and other error recovery paths") Signed-off-by: Seunghui Lee <sh043.lee@samsung.com> Link: https://lore.kernel.org/r/20250717081213.6811-1-sh043.lee@samsung.com Reviewed-by: Bean Huo <beanhuo@micron.com> Acked-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/ufs/core/ufshcd.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c index e7e6bbc04d21..db2a2760c0d6 100644 --- a/drivers/ufs/core/ufshcd.c +++ b/drivers/ufs/core/ufshcd.c @@ -4322,7 +4322,7 @@ static int ufshcd_uic_pwr_ctrl(struct ufs_hba *hba, struct uic_command *cmd) hba->uic_async_done = NULL; if (reenable_intr) ufshcd_enable_intr(hba, UIC_COMMAND_COMPL); - if (ret) { + if (ret && !hba->pm_op_in_progress) { ufshcd_set_link_broken(hba); ufshcd_schedule_eh_work(hba); } @@ -4330,6 +4330,14 @@ static int ufshcd_uic_pwr_ctrl(struct ufs_hba *hba, struct uic_command *cmd) spin_unlock_irqrestore(hba->host->host_lock, flags); mutex_unlock(&hba->uic_cmd_mutex); + /* + * If the h8 exit fails during the runtime resume process, it becomes + * stuck and cannot be recovered through the error handler. To fix + * this, use link recovery instead of the error handler. + */ + if (ret && hba->pm_op_in_progress) + ret = ufshcd_link_recovery(hba); + return ret; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 369/480] scsi: sd: Make sd shutdown issue START STOP UNIT appropriately 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (367 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 368/480] scsi: ufs: core: Use link recovery when h8 exit fails during runtime resume Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 370/480] kconfig: qconf: fix ConfigList::updateListAllforAll() Greg Kroah-Hartman ` (122 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Salomon Dushimirimana, Damien Le Moal, Martin K. Petersen, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Salomon Dushimirimana <salomondush@google.com> [ Upstream commit 8e48727c26c4d839ff9b4b73d1cae486bea7fe19 ] Commit aa3998dbeb3a ("ata: libata-scsi: Disable scsi device manage_system_start_stop") enabled libata EH to manage device power mode trasitions for system suspend/resume and removed the flag from ata_scsi_dev_config. However, since the sd_shutdown() function still relies on the manage_system_start_stop flag, a spin-down command is not issued to the disk with command "echo 1 > /sys/block/sdb/device/delete" sd_shutdown() can be called for both system/runtime start stop operations, so utilize the manage_run_time_start_stop flag set in the ata_scsi_dev_config and issue a spin-down command during disk removal when the system is running. This is in addition to when the system is powering off and manage_shutdown flag is set. The manage_system_start_stop flag will still be used for drivers that still set the flag. Fixes: aa3998dbeb3a ("ata: libata-scsi: Disable scsi device manage_system_start_stop") Signed-off-by: Salomon Dushimirimana <salomondush@google.com> Link: https://lore.kernel.org/r/20250724214520.112927-1-salomondush@google.com Tested-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/scsi/sd.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index 89d5c4b17bc4..2f64caa3b253 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -4173,7 +4173,9 @@ static void sd_shutdown(struct device *dev) if ((system_state != SYSTEM_RESTART && sdkp->device->manage_system_start_stop) || (system_state == SYSTEM_POWER_OFF && - sdkp->device->manage_shutdown)) { + sdkp->device->manage_shutdown) || + (system_state == SYSTEM_RUNNING && + sdkp->device->manage_runtime_start_stop)) { sd_printk(KERN_NOTICE, sdkp, "Stopping disk\n"); sd_start_stop_device(sdkp, 0); } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 370/480] kconfig: qconf: fix ConfigList::updateListAllforAll() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (368 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 369/480] scsi: sd: Make sd shutdown issue START STOP UNIT appropriately Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 371/480] vfio/pci: Do vf_token checks for VFIO_DEVICE_BIND_IOMMUFD Greg Kroah-Hartman ` (121 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Masahiro Yamada, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Masahiro Yamada <masahiroy@kernel.org> [ Upstream commit 721bfe583c52ba1ea74b3736a31a9dcfe6dd6d95 ] ConfigList::updateListForAll() and ConfigList::updateListAllforAll() are identical. Commit f9b918fae678 ("kconfig: qconf: move ConfigView::updateList(All) to ConfigList class") was a misconversion. Fixes: f9b918fae678 ("kconfig: qconf: move ConfigView::updateList(All) to ConfigList class") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- scripts/kconfig/qconf.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc index eaa465b0ccf9..49607555d343 100644 --- a/scripts/kconfig/qconf.cc +++ b/scripts/kconfig/qconf.cc @@ -478,7 +478,7 @@ void ConfigList::updateListAllForAll() while (it.hasNext()) { ConfigList *list = it.next(); - list->updateList(); + list->updateListAll(); } } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 371/480] vfio/pci: Do vf_token checks for VFIO_DEVICE_BIND_IOMMUFD 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (369 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 370/480] kconfig: qconf: fix ConfigList::updateListAllforAll() Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 372/480] sched/psi: Fix psi_seq initialization Greg Kroah-Hartman ` (120 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Shameer Kolothum, Yi Liu, Jason Gunthorpe, Kevin Tian, Alex Williamson, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jason Gunthorpe <jgg@nvidia.com> [ Upstream commit 86624ba3b522b6512def25534341da93356c8da4 ] This was missed during the initial implementation. The VFIO PCI encodes the vf_token inside the device name when opening the device from the group FD, something like: "0000:04:10.0 vf_token=bd8d9d2b-5a5f-4f5a-a211-f591514ba1f3" This is used to control access to a VF unless there is co-ordination with the owner of the PF. Since we no longer have a device name in the cdev path, pass the token directly through VFIO_DEVICE_BIND_IOMMUFD using an optional field indicated by VFIO_DEVICE_BIND_FLAG_TOKEN. Fixes: 5fcc26969a16 ("vfio: Add VFIO_DEVICE_BIND_IOMMUFD") Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/0-v3-bdd8716e85fe+3978a-vfio_token_jgg@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/vfio/device_cdev.c | 38 +++++++++++++++++-- .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c | 1 + drivers/vfio/pci/mlx5/main.c | 1 + drivers/vfio/pci/nvgrace-gpu/main.c | 2 + drivers/vfio/pci/pds/vfio_dev.c | 1 + drivers/vfio/pci/qat/main.c | 1 + drivers/vfio/pci/vfio_pci.c | 1 + drivers/vfio/pci/vfio_pci_core.c | 22 +++++++---- drivers/vfio/pci/virtio/main.c | 3 ++ include/linux/vfio.h | 4 ++ include/linux/vfio_pci_core.h | 2 + include/uapi/linux/vfio.h | 12 +++++- 12 files changed, 76 insertions(+), 12 deletions(-) diff --git a/drivers/vfio/device_cdev.c b/drivers/vfio/device_cdev.c index 281a8dc3ed49..480cac3a0c27 100644 --- a/drivers/vfio/device_cdev.c +++ b/drivers/vfio/device_cdev.c @@ -60,22 +60,50 @@ static void vfio_df_get_kvm_safe(struct vfio_device_file *df) spin_unlock(&df->kvm_ref_lock); } +static int vfio_df_check_token(struct vfio_device *device, + const struct vfio_device_bind_iommufd *bind) +{ + uuid_t uuid; + + if (!device->ops->match_token_uuid) { + if (bind->flags & VFIO_DEVICE_BIND_FLAG_TOKEN) + return -EINVAL; + return 0; + } + + if (!(bind->flags & VFIO_DEVICE_BIND_FLAG_TOKEN)) + return device->ops->match_token_uuid(device, NULL); + + if (copy_from_user(&uuid, u64_to_user_ptr(bind->token_uuid_ptr), + sizeof(uuid))) + return -EFAULT; + return device->ops->match_token_uuid(device, &uuid); +} + long vfio_df_ioctl_bind_iommufd(struct vfio_device_file *df, struct vfio_device_bind_iommufd __user *arg) { + const u32 VALID_FLAGS = VFIO_DEVICE_BIND_FLAG_TOKEN; struct vfio_device *device = df->device; struct vfio_device_bind_iommufd bind; unsigned long minsz; + u32 user_size; int ret; static_assert(__same_type(arg->out_devid, df->devid)); minsz = offsetofend(struct vfio_device_bind_iommufd, out_devid); - if (copy_from_user(&bind, arg, minsz)) - return -EFAULT; + ret = get_user(user_size, &arg->argsz); + if (ret) + return ret; + if (user_size < minsz) + return -EINVAL; + ret = copy_struct_from_user(&bind, minsz, arg, user_size); + if (ret) + return ret; - if (bind.argsz < minsz || bind.flags || bind.iommufd < 0) + if (bind.iommufd < 0 || bind.flags & ~VALID_FLAGS) return -EINVAL; /* BIND_IOMMUFD only allowed for cdev fds */ @@ -93,6 +121,10 @@ long vfio_df_ioctl_bind_iommufd(struct vfio_device_file *df, goto out_unlock; } + ret = vfio_df_check_token(device, &bind); + if (ret) + goto out_unlock; + df->iommufd = iommufd_ctx_from_fd(bind.iommufd); if (IS_ERR(df->iommufd)) { ret = PTR_ERR(df->iommufd); diff --git a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c index d12a350440d3..36b60e293204 100644 --- a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c +++ b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c @@ -1580,6 +1580,7 @@ static const struct vfio_device_ops hisi_acc_vfio_pci_ops = { .mmap = vfio_pci_core_mmap, .request = vfio_pci_core_request, .match = vfio_pci_core_match, + .match_token_uuid = vfio_pci_core_match_token_uuid, .bind_iommufd = vfio_iommufd_physical_bind, .unbind_iommufd = vfio_iommufd_physical_unbind, .attach_ioas = vfio_iommufd_physical_attach_ioas, diff --git a/drivers/vfio/pci/mlx5/main.c b/drivers/vfio/pci/mlx5/main.c index 709543e7eb04..d83249aea275 100644 --- a/drivers/vfio/pci/mlx5/main.c +++ b/drivers/vfio/pci/mlx5/main.c @@ -1387,6 +1387,7 @@ static const struct vfio_device_ops mlx5vf_pci_ops = { .mmap = vfio_pci_core_mmap, .request = vfio_pci_core_request, .match = vfio_pci_core_match, + .match_token_uuid = vfio_pci_core_match_token_uuid, .bind_iommufd = vfio_iommufd_physical_bind, .unbind_iommufd = vfio_iommufd_physical_unbind, .attach_ioas = vfio_iommufd_physical_attach_ioas, diff --git a/drivers/vfio/pci/nvgrace-gpu/main.c b/drivers/vfio/pci/nvgrace-gpu/main.c index e5ac39c4cc6b..d95761dcdd58 100644 --- a/drivers/vfio/pci/nvgrace-gpu/main.c +++ b/drivers/vfio/pci/nvgrace-gpu/main.c @@ -696,6 +696,7 @@ static const struct vfio_device_ops nvgrace_gpu_pci_ops = { .mmap = nvgrace_gpu_mmap, .request = vfio_pci_core_request, .match = vfio_pci_core_match, + .match_token_uuid = vfio_pci_core_match_token_uuid, .bind_iommufd = vfio_iommufd_physical_bind, .unbind_iommufd = vfio_iommufd_physical_unbind, .attach_ioas = vfio_iommufd_physical_attach_ioas, @@ -715,6 +716,7 @@ static const struct vfio_device_ops nvgrace_gpu_pci_core_ops = { .mmap = vfio_pci_core_mmap, .request = vfio_pci_core_request, .match = vfio_pci_core_match, + .match_token_uuid = vfio_pci_core_match_token_uuid, .bind_iommufd = vfio_iommufd_physical_bind, .unbind_iommufd = vfio_iommufd_physical_unbind, .attach_ioas = vfio_iommufd_physical_attach_ioas, diff --git a/drivers/vfio/pci/pds/vfio_dev.c b/drivers/vfio/pci/pds/vfio_dev.c index f6e0253a8a14..f3ccb0008f67 100644 --- a/drivers/vfio/pci/pds/vfio_dev.c +++ b/drivers/vfio/pci/pds/vfio_dev.c @@ -201,6 +201,7 @@ static const struct vfio_device_ops pds_vfio_ops = { .mmap = vfio_pci_core_mmap, .request = vfio_pci_core_request, .match = vfio_pci_core_match, + .match_token_uuid = vfio_pci_core_match_token_uuid, .bind_iommufd = vfio_iommufd_physical_bind, .unbind_iommufd = vfio_iommufd_physical_unbind, .attach_ioas = vfio_iommufd_physical_attach_ioas, diff --git a/drivers/vfio/pci/qat/main.c b/drivers/vfio/pci/qat/main.c index 845ed15b6771..5cce6b0b8d2f 100644 --- a/drivers/vfio/pci/qat/main.c +++ b/drivers/vfio/pci/qat/main.c @@ -614,6 +614,7 @@ static const struct vfio_device_ops qat_vf_pci_ops = { .mmap = vfio_pci_core_mmap, .request = vfio_pci_core_request, .match = vfio_pci_core_match, + .match_token_uuid = vfio_pci_core_match_token_uuid, .bind_iommufd = vfio_iommufd_physical_bind, .unbind_iommufd = vfio_iommufd_physical_unbind, .attach_ioas = vfio_iommufd_physical_attach_ioas, diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c index 5ba39f7623bb..ac10f14417f2 100644 --- a/drivers/vfio/pci/vfio_pci.c +++ b/drivers/vfio/pci/vfio_pci.c @@ -138,6 +138,7 @@ static const struct vfio_device_ops vfio_pci_ops = { .mmap = vfio_pci_core_mmap, .request = vfio_pci_core_request, .match = vfio_pci_core_match, + .match_token_uuid = vfio_pci_core_match_token_uuid, .bind_iommufd = vfio_iommufd_physical_bind, .unbind_iommufd = vfio_iommufd_physical_unbind, .attach_ioas = vfio_iommufd_physical_attach_ioas, diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c index 261a6dc5a5fc..fad410cf91bc 100644 --- a/drivers/vfio/pci/vfio_pci_core.c +++ b/drivers/vfio/pci/vfio_pci_core.c @@ -1821,9 +1821,13 @@ void vfio_pci_core_request(struct vfio_device *core_vdev, unsigned int count) } EXPORT_SYMBOL_GPL(vfio_pci_core_request); -static int vfio_pci_validate_vf_token(struct vfio_pci_core_device *vdev, - bool vf_token, uuid_t *uuid) +int vfio_pci_core_match_token_uuid(struct vfio_device *core_vdev, + const uuid_t *uuid) + { + struct vfio_pci_core_device *vdev = + container_of(core_vdev, struct vfio_pci_core_device, vdev); + /* * There's always some degree of trust or collaboration between SR-IOV * PF and VFs, even if just that the PF hosts the SR-IOV capability and @@ -1854,7 +1858,7 @@ static int vfio_pci_validate_vf_token(struct vfio_pci_core_device *vdev, bool match; if (!pf_vdev) { - if (!vf_token) + if (!uuid) return 0; /* PF is not vfio-pci, no VF token */ pci_info_ratelimited(vdev->pdev, @@ -1862,7 +1866,7 @@ static int vfio_pci_validate_vf_token(struct vfio_pci_core_device *vdev, return -EINVAL; } - if (!vf_token) { + if (!uuid) { pci_info_ratelimited(vdev->pdev, "VF token required to access device\n"); return -EACCES; @@ -1880,7 +1884,7 @@ static int vfio_pci_validate_vf_token(struct vfio_pci_core_device *vdev, } else if (vdev->vf_token) { mutex_lock(&vdev->vf_token->lock); if (vdev->vf_token->users) { - if (!vf_token) { + if (!uuid) { mutex_unlock(&vdev->vf_token->lock); pci_info_ratelimited(vdev->pdev, "VF token required to access device\n"); @@ -1893,12 +1897,12 @@ static int vfio_pci_validate_vf_token(struct vfio_pci_core_device *vdev, "Incorrect VF token provided for device\n"); return -EACCES; } - } else if (vf_token) { + } else if (uuid) { uuid_copy(&vdev->vf_token->uuid, uuid); } mutex_unlock(&vdev->vf_token->lock); - } else if (vf_token) { + } else if (uuid) { pci_info_ratelimited(vdev->pdev, "VF token incorrectly provided, not a PF or VF\n"); return -EINVAL; @@ -1906,6 +1910,7 @@ static int vfio_pci_validate_vf_token(struct vfio_pci_core_device *vdev, return 0; } +EXPORT_SYMBOL_GPL(vfio_pci_core_match_token_uuid); #define VF_TOKEN_ARG "vf_token=" @@ -1952,7 +1957,8 @@ int vfio_pci_core_match(struct vfio_device *core_vdev, char *buf) } } - ret = vfio_pci_validate_vf_token(vdev, vf_token, &uuid); + ret = core_vdev->ops->match_token_uuid(core_vdev, + vf_token ? &uuid : NULL); if (ret) return ret; diff --git a/drivers/vfio/pci/virtio/main.c b/drivers/vfio/pci/virtio/main.c index 515fe1b9f94d..8084f3e36a9f 100644 --- a/drivers/vfio/pci/virtio/main.c +++ b/drivers/vfio/pci/virtio/main.c @@ -94,6 +94,7 @@ static const struct vfio_device_ops virtiovf_vfio_pci_lm_ops = { .mmap = vfio_pci_core_mmap, .request = vfio_pci_core_request, .match = vfio_pci_core_match, + .match_token_uuid = vfio_pci_core_match_token_uuid, .bind_iommufd = vfio_iommufd_physical_bind, .unbind_iommufd = vfio_iommufd_physical_unbind, .attach_ioas = vfio_iommufd_physical_attach_ioas, @@ -114,6 +115,7 @@ static const struct vfio_device_ops virtiovf_vfio_pci_tran_lm_ops = { .mmap = vfio_pci_core_mmap, .request = vfio_pci_core_request, .match = vfio_pci_core_match, + .match_token_uuid = vfio_pci_core_match_token_uuid, .bind_iommufd = vfio_iommufd_physical_bind, .unbind_iommufd = vfio_iommufd_physical_unbind, .attach_ioas = vfio_iommufd_physical_attach_ioas, @@ -134,6 +136,7 @@ static const struct vfio_device_ops virtiovf_vfio_pci_ops = { .mmap = vfio_pci_core_mmap, .request = vfio_pci_core_request, .match = vfio_pci_core_match, + .match_token_uuid = vfio_pci_core_match_token_uuid, .bind_iommufd = vfio_iommufd_physical_bind, .unbind_iommufd = vfio_iommufd_physical_unbind, .attach_ioas = vfio_iommufd_physical_attach_ioas, diff --git a/include/linux/vfio.h b/include/linux/vfio.h index 707b00772ce1..eb563f538dee 100644 --- a/include/linux/vfio.h +++ b/include/linux/vfio.h @@ -105,6 +105,9 @@ struct vfio_device { * @match: Optional device name match callback (return: 0 for no-match, >0 for * match, -errno for abort (ex. match with insufficient or incorrect * additional args) + * @match_token_uuid: Optional device token match/validation. Return 0 + * if the uuid is valid for the device, -errno otherwise. uuid is NULL + * if none was provided. * @dma_unmap: Called when userspace unmaps IOVA from the container * this device is attached to. * @device_feature: Optional, fill in the VFIO_DEVICE_FEATURE ioctl @@ -132,6 +135,7 @@ struct vfio_device_ops { int (*mmap)(struct vfio_device *vdev, struct vm_area_struct *vma); void (*request)(struct vfio_device *vdev, unsigned int count); int (*match)(struct vfio_device *vdev, char *buf); + int (*match_token_uuid)(struct vfio_device *vdev, const uuid_t *uuid); void (*dma_unmap)(struct vfio_device *vdev, u64 iova, u64 length); int (*device_feature)(struct vfio_device *device, u32 flags, void __user *arg, size_t argsz); diff --git a/include/linux/vfio_pci_core.h b/include/linux/vfio_pci_core.h index fbb472dd99b3..f541044e42a2 100644 --- a/include/linux/vfio_pci_core.h +++ b/include/linux/vfio_pci_core.h @@ -122,6 +122,8 @@ ssize_t vfio_pci_core_write(struct vfio_device *core_vdev, const char __user *bu int vfio_pci_core_mmap(struct vfio_device *core_vdev, struct vm_area_struct *vma); void vfio_pci_core_request(struct vfio_device *core_vdev, unsigned int count); int vfio_pci_core_match(struct vfio_device *core_vdev, char *buf); +int vfio_pci_core_match_token_uuid(struct vfio_device *core_vdev, + const uuid_t *uuid); int vfio_pci_core_enable(struct vfio_pci_core_device *vdev); void vfio_pci_core_disable(struct vfio_pci_core_device *vdev); void vfio_pci_core_finish_enable(struct vfio_pci_core_device *vdev); diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h index 5764f315137f..75100bf009ba 100644 --- a/include/uapi/linux/vfio.h +++ b/include/uapi/linux/vfio.h @@ -905,10 +905,12 @@ struct vfio_device_feature { * VFIO_DEVICE_BIND_IOMMUFD - _IOR(VFIO_TYPE, VFIO_BASE + 18, * struct vfio_device_bind_iommufd) * @argsz: User filled size of this data. - * @flags: Must be 0. + * @flags: Must be 0 or a bit flags of VFIO_DEVICE_BIND_* * @iommufd: iommufd to bind. * @out_devid: The device id generated by this bind. devid is a handle for * this device/iommufd bond and can be used in IOMMUFD commands. + * @token_uuid_ptr: Valid if VFIO_DEVICE_BIND_FLAG_TOKEN. Points to a 16 byte + * UUID in the same format as VFIO_DEVICE_FEATURE_PCI_VF_TOKEN. * * Bind a vfio_device to the specified iommufd. * @@ -917,13 +919,21 @@ struct vfio_device_feature { * * Unbind is automatically conducted when device fd is closed. * + * A token is sometimes required to open the device, unless this is known to be + * needed VFIO_DEVICE_BIND_FLAG_TOKEN should not be set and token_uuid_ptr is + * ignored. The only case today is a PF/VF relationship where the VF bind must + * be provided the same token as VFIO_DEVICE_FEATURE_PCI_VF_TOKEN provided to + * the PF. + * * Return: 0 on success, -errno on failure. */ struct vfio_device_bind_iommufd { __u32 argsz; __u32 flags; +#define VFIO_DEVICE_BIND_FLAG_TOKEN (1 << 0) __s32 iommufd; __u32 out_devid; + __aligned_u64 token_uuid_ptr; }; #define VFIO_DEVICE_BIND_IOMMUFD _IO(VFIO_TYPE, VFIO_BASE + 18) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 372/480] sched/psi: Fix psi_seq initialization 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (370 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 371/480] vfio/pci: Do vf_token checks for VFIO_DEVICE_BIND_IOMMUFD Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 373/480] padata: Remove comment for reorder_work Greg Kroah-Hartman ` (119 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Chris Mason, Beata Michalska, Peter Zijlstra (Intel), Linus Torvalds, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Peter Zijlstra <peterz@infradead.org> [ Upstream commit 99b773d720aeea1ef2170dce5fcfa80649e26b78 ] With the seqcount moved out of the group into a global psi_seq, re-initializing the seqcount on group creation is causing seqcount corruption. Fixes: 570c8efd5eb7 ("sched/psi: Optimize psi_group_change() cpu_clock() usage") Reported-by: Chris Mason <clm@meta.com> Suggested-by: Beata Michalska <beata.michalska@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- kernel/sched/psi.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c index c62f4316a2b9..e0ad56b26171 100644 --- a/kernel/sched/psi.c +++ b/kernel/sched/psi.c @@ -172,7 +172,7 @@ struct psi_group psi_system = { .pcpu = &system_group_pcpu, }; -static DEFINE_PER_CPU(seqcount_t, psi_seq); +static DEFINE_PER_CPU(seqcount_t, psi_seq) = SEQCNT_ZERO(psi_seq); static inline void psi_write_begin(int cpu) { @@ -200,11 +200,7 @@ static void poll_timer_fn(struct timer_list *t); static void group_init(struct psi_group *group) { - int cpu; - group->enabled = true; - for_each_possible_cpu(cpu) - seqcount_init(per_cpu_ptr(&psi_seq, cpu)); group->avg_last_update = sched_clock(); group->avg_next_update = group->avg_last_update + psi_period; mutex_init(&group->avgs_lock); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 373/480] padata: Remove comment for reorder_work 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (371 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 372/480] sched/psi: Fix psi_seq initialization Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 374/480] PCI: pnv_php: Clean up allocated IRQs on unplug Greg Kroah-Hartman ` (118 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Stephen Rothwell, Herbert Xu, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Herbert Xu <herbert@gondor.apana.org.au> [ Upstream commit 82a0302e7167d0b7c6cde56613db3748f8dd806d ] Remove comment for reorder_work which no longer exists. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 71203f68c774 ("padata: Fix pd UAF once and for all") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> --- include/linux/padata.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/padata.h b/include/linux/padata.h index b486c7359de2..765f2778e264 100644 --- a/include/linux/padata.h +++ b/include/linux/padata.h @@ -90,7 +90,6 @@ struct padata_cpumask { * @processed: Number of already processed objects. * @cpu: Next CPU to be processed. * @cpumask: The cpumasks in use for parallel and serial workers. - * @reorder_work: work struct for reordering. */ struct parallel_data { struct padata_shell *ps; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 374/480] PCI: pnv_php: Clean up allocated IRQs on unplug 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (372 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 373/480] padata: Remove comment for reorder_work Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 375/480] PCI: pnv_php: Work around switches with broken presence detection Greg Kroah-Hartman ` (117 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Shawn Anastasio, Timothy Pearson, Bjorn Helgaas, Madhavan Srinivasan, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Timothy Pearson <tpearson@raptorengineering.com> [ Upstream commit 4668619092554e1b95c9a5ac2941ca47ba6d548a ] When the root of a nested PCIe bridge configuration is unplugged, the pnv_php driver leaked the allocated IRQ resources for the child bridges' hotplug event notifications, resulting in a panic. Fix this by walking all child buses and deallocating all its IRQ resources before calling pci_hp_remove_devices(). Also modify the lifetime of the workqueue at struct pnv_php_slot::wq so that it is only destroyed in pnv_php_free_slot(), instead of pnv_php_disable_irq(). This is required since pnv_php_disable_irq() will now be called by workers triggered by hot unplug interrupts, so the workqueue needs to stay allocated. The abridged kernel panic that occurs without this patch is as follows: WARNING: CPU: 0 PID: 687 at kernel/irq/msi.c:292 msi_device_data_release+0x6c/0x9c CPU: 0 UID: 0 PID: 687 Comm: bash Not tainted 6.14.0-rc5+ #2 Call Trace: msi_device_data_release+0x34/0x9c (unreliable) release_nodes+0x64/0x13c devres_release_all+0xc0/0x140 device_del+0x2d4/0x46c pci_destroy_dev+0x5c/0x194 pci_hp_remove_devices+0x90/0x128 pci_hp_remove_devices+0x44/0x128 pnv_php_disable_slot+0x54/0xd4 power_write_file+0xf8/0x18c pci_slot_attr_store+0x40/0x5c sysfs_kf_write+0x64/0x78 kernfs_fop_write_iter+0x1b0/0x290 vfs_write+0x3bc/0x50c ksys_write+0x84/0x140 system_call_exception+0x124/0x230 system_call_vectored_common+0x15c/0x2ec Signed-off-by: Shawn Anastasio <sanastasio@raptorengineering.com> Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com> [bhelgaas: tidy comments] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/2013845045.1359852.1752615367790.JavaMail.zimbra@raptorengineeringinc.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/pci/hotplug/pnv_php.c | 96 ++++++++++++++++++++++++++++------- 1 file changed, 77 insertions(+), 19 deletions(-) diff --git a/drivers/pci/hotplug/pnv_php.c b/drivers/pci/hotplug/pnv_php.c index 573a41869c15..1304329ca6f7 100644 --- a/drivers/pci/hotplug/pnv_php.c +++ b/drivers/pci/hotplug/pnv_php.c @@ -3,6 +3,7 @@ * PCI Hotplug Driver for PowerPC PowerNV platform. * * Copyright Gavin Shan, IBM Corporation 2016. + * Copyright (C) 2025 Raptor Engineering, LLC */ #include <linux/bitfield.h> @@ -36,8 +37,10 @@ static void pnv_php_register(struct device_node *dn); static void pnv_php_unregister_one(struct device_node *dn); static void pnv_php_unregister(struct device_node *dn); +static void pnv_php_enable_irq(struct pnv_php_slot *php_slot); + static void pnv_php_disable_irq(struct pnv_php_slot *php_slot, - bool disable_device) + bool disable_device, bool disable_msi) { struct pci_dev *pdev = php_slot->pdev; u16 ctrl; @@ -53,19 +56,15 @@ static void pnv_php_disable_irq(struct pnv_php_slot *php_slot, php_slot->irq = 0; } - if (php_slot->wq) { - destroy_workqueue(php_slot->wq); - php_slot->wq = NULL; - } - - if (disable_device) { + if (disable_device || disable_msi) { if (pdev->msix_enabled) pci_disable_msix(pdev); else if (pdev->msi_enabled) pci_disable_msi(pdev); + } + if (disable_device) pci_disable_device(pdev); - } } static void pnv_php_free_slot(struct kref *kref) @@ -74,7 +73,8 @@ static void pnv_php_free_slot(struct kref *kref) struct pnv_php_slot, kref); WARN_ON(!list_empty(&php_slot->children)); - pnv_php_disable_irq(php_slot, false); + pnv_php_disable_irq(php_slot, false, false); + destroy_workqueue(php_slot->wq); kfree(php_slot->name); kfree(php_slot); } @@ -561,8 +561,58 @@ static int pnv_php_reset_slot(struct hotplug_slot *slot, bool probe) static int pnv_php_enable_slot(struct hotplug_slot *slot) { struct pnv_php_slot *php_slot = to_pnv_php_slot(slot); + u32 prop32; + int ret; + + ret = pnv_php_enable(php_slot, true); + if (ret) + return ret; + + /* (Re-)enable interrupt if the slot supports surprise hotplug */ + ret = of_property_read_u32(php_slot->dn, "ibm,slot-surprise-pluggable", + &prop32); + if (!ret && prop32) + pnv_php_enable_irq(php_slot); - return pnv_php_enable(php_slot, true); + return 0; +} + +/* + * Disable any hotplug interrupts for all slots on the provided bus, as well as + * all downstream slots in preparation for a hot unplug. + */ +static int pnv_php_disable_all_irqs(struct pci_bus *bus) +{ + struct pci_bus *child_bus; + struct pci_slot *slot; + + /* First go down child buses */ + list_for_each_entry(child_bus, &bus->children, node) + pnv_php_disable_all_irqs(child_bus); + + /* Disable IRQs for all pnv_php slots on this bus */ + list_for_each_entry(slot, &bus->slots, list) { + struct pnv_php_slot *php_slot = to_pnv_php_slot(slot->hotplug); + + pnv_php_disable_irq(php_slot, false, true); + } + + return 0; +} + +/* + * Disable any hotplug interrupts for all downstream slots on the provided + * bus in preparation for a hot unplug. + */ +static int pnv_php_disable_all_downstream_irqs(struct pci_bus *bus) +{ + struct pci_bus *child_bus; + + /* Go down child buses, recursively deactivating their IRQs */ + list_for_each_entry(child_bus, &bus->children, node) + pnv_php_disable_all_irqs(child_bus); + + return 0; } static int pnv_php_disable_slot(struct hotplug_slot *slot) @@ -579,6 +629,13 @@ static int pnv_php_disable_slot(struct hotplug_slot *slot) php_slot->state != PNV_PHP_STATE_REGISTERED) return 0; + /* + * Free all IRQ resources from all child slots before remove. + * Note that we do not disable the root slot IRQ here as that + * would also deactivate the slot hot (re)plug interrupt! + */ + pnv_php_disable_all_downstream_irqs(php_slot->bus); + /* Remove all devices behind the slot */ pci_lock_rescan_remove(); pci_hp_remove_devices(php_slot->bus); @@ -647,6 +704,15 @@ static struct pnv_php_slot *pnv_php_alloc_slot(struct device_node *dn) return NULL; } + /* Allocate workqueue for this slot's interrupt handling */ + php_slot->wq = alloc_workqueue("pciehp-%s", 0, 0, php_slot->name); + if (!php_slot->wq) { + SLOT_WARN(php_slot, "Cannot alloc workqueue\n"); + kfree(php_slot->name); + kfree(php_slot); + return NULL; + } + if (dn->child && PCI_DN(dn->child)) php_slot->slot_no = PCI_SLOT(PCI_DN(dn->child)->devfn); else @@ -843,14 +909,6 @@ static void pnv_php_init_irq(struct pnv_php_slot *php_slot, int irq) u16 sts, ctrl; int ret; - /* Allocate workqueue */ - php_slot->wq = alloc_workqueue("pciehp-%s", 0, 0, php_slot->name); - if (!php_slot->wq) { - SLOT_WARN(php_slot, "Cannot alloc workqueue\n"); - pnv_php_disable_irq(php_slot, true); - return; - } - /* Check PDC (Presence Detection Change) is broken or not */ ret = of_property_read_u32(php_slot->dn, "ibm,slot-broken-pdc", &broken_pdc); @@ -869,7 +927,7 @@ static void pnv_php_init_irq(struct pnv_php_slot *php_slot, int irq) ret = request_irq(irq, pnv_php_interrupt, IRQF_SHARED, php_slot->name, php_slot); if (ret) { - pnv_php_disable_irq(php_slot, true); + pnv_php_disable_irq(php_slot, true, true); SLOT_WARN(php_slot, "Error %d enabling IRQ %d\n", ret, irq); return; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 375/480] PCI: pnv_php: Work around switches with broken presence detection 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (373 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 374/480] PCI: pnv_php: Clean up allocated IRQs on unplug Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 376/480] powerpc/eeh: Export eeh_unfreeze_pe() Greg Kroah-Hartman ` (116 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Shawn Anastasio, Timothy Pearson, Bjorn Helgaas, Madhavan Srinivasan, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Timothy Pearson <tpearson@raptorengineering.com> [ Upstream commit 80f9fc2362797538ebd4fd70a1dfa838cc2c2cdb ] The Microsemi Switchtec PM8533 PFX 48xG3 [11f8:8533] PCIe switch system was observed to incorrectly assert the Presence Detect Set bit in its capabilities when tested on a Raptor Computing Systems Blackbird system, resulting in the hot insert path never attempting a rescan of the bus and any downstream devices not being re-detected. Work around this by additionally checking whether the PCIe data link is active or not when performing presence detection on downstream switches' ports, similar to the pciehp_hpc.c driver. Signed-off-by: Shawn Anastasio <sanastasio@raptorengineering.com> Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/505981576.1359853.1752615415117.JavaMail.zimbra@raptorengineeringinc.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/pci/hotplug/pnv_php.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/drivers/pci/hotplug/pnv_php.c b/drivers/pci/hotplug/pnv_php.c index 1304329ca6f7..5476c9e7760d 100644 --- a/drivers/pci/hotplug/pnv_php.c +++ b/drivers/pci/hotplug/pnv_php.c @@ -391,6 +391,20 @@ static int pnv_php_get_power_state(struct hotplug_slot *slot, u8 *state) return 0; } +static int pcie_check_link_active(struct pci_dev *pdev) +{ + u16 lnk_status; + int ret; + + ret = pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, &lnk_status); + if (ret == PCIBIOS_DEVICE_NOT_FOUND || PCI_POSSIBLE_ERROR(lnk_status)) + return -ENODEV; + + ret = !!(lnk_status & PCI_EXP_LNKSTA_DLLLA); + + return ret; +} + static int pnv_php_get_adapter_state(struct hotplug_slot *slot, u8 *state) { struct pnv_php_slot *php_slot = to_pnv_php_slot(slot); @@ -403,6 +417,19 @@ static int pnv_php_get_adapter_state(struct hotplug_slot *slot, u8 *state) */ ret = pnv_pci_get_presence_state(php_slot->id, &presence); if (ret >= 0) { + if (pci_pcie_type(php_slot->pdev) == PCI_EXP_TYPE_DOWNSTREAM && + presence == OPAL_PCI_SLOT_EMPTY) { + /* + * Similar to pciehp_hpc, check whether the Link Active + * bit is set to account for broken downstream bridges + * that don't properly assert Presence Detect State, as + * was observed on the Microsemi Switchtec PM8533 PFX + * [11f8:8533]. + */ + if (pcie_check_link_active(php_slot->pdev) > 0) + presence = OPAL_PCI_SLOT_PRESENT; + } + *state = presence; ret = 0; } else { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 376/480] powerpc/eeh: Export eeh_unfreeze_pe() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (374 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 375/480] PCI: pnv_php: Work around switches with broken presence detection Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 377/480] powerpc/eeh: Make EEH driver device hotplug safe Greg Kroah-Hartman ` (115 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Timothy Pearson, Bjorn Helgaas, Madhavan Srinivasan, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Timothy Pearson <tpearson@raptorengineering.com> [ Upstream commit e82b34eed04b0ddcff4548b62633467235672fd3 ] The PowerNV hotplug driver needs to be able to clear any frozen PE(s) on the PHB after suprise removal of a downstream device. Export the eeh_unfreeze_pe() symbol to allow implementation of this functionality in the php_nv module. Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/1778535414.1359858.1752615454618.JavaMail.zimbra@raptorengineeringinc.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/powerpc/kernel/eeh.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c index ca7f7bb2b478..2b5f3323e107 100644 --- a/arch/powerpc/kernel/eeh.c +++ b/arch/powerpc/kernel/eeh.c @@ -1139,6 +1139,7 @@ int eeh_unfreeze_pe(struct eeh_pe *pe) return ret; } +EXPORT_SYMBOL_GPL(eeh_unfreeze_pe); static struct pci_device_id eeh_reset_ids[] = { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 377/480] powerpc/eeh: Make EEH driver device hotplug safe 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (375 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 376/480] powerpc/eeh: Export eeh_unfreeze_pe() Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 378/480] PCI: pnv_php: Fix surprise plug detection and recovery Greg Kroah-Hartman ` (114 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Timothy Pearson, Bjorn Helgaas, Madhavan Srinivasan, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Timothy Pearson <tpearson@raptorengineering.com> [ Upstream commit 1010b4c012b0d78dfb9d3132b49aa2ef024a07a7 ] Multiple race conditions existed between the PCIe hotplug driver and the EEH driver, leading to a variety of kernel oopses of the same general nature: <pcie device unplug> <eeh driver trigger> <hotplug removal trigger> <pcie tree reconfiguration> <eeh recovery next step> <oops in EEH driver bus iteration loop> A second class of oops is also seen when the underlying bus disappears during device recovery. Refactor the EEH module to be PCI rescan and remove safe. Also clean up a few minor formatting / readability issues. Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/1334208367.1359861.1752615503144.JavaMail.zimbra@raptorengineeringinc.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/powerpc/kernel/eeh_driver.c | 48 +++++++++++++++++++++----------- arch/powerpc/kernel/eeh_pe.c | 10 ++++--- 2 files changed, 38 insertions(+), 20 deletions(-) diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c index 7efe04c68f0f..dd50de91c438 100644 --- a/arch/powerpc/kernel/eeh_driver.c +++ b/arch/powerpc/kernel/eeh_driver.c @@ -257,13 +257,12 @@ static void eeh_pe_report_edev(struct eeh_dev *edev, eeh_report_fn fn, struct pci_driver *driver; enum pci_ers_result new_result; - pci_lock_rescan_remove(); pdev = edev->pdev; if (pdev) get_device(&pdev->dev); - pci_unlock_rescan_remove(); if (!pdev) { eeh_edev_info(edev, "no device"); + *result = PCI_ERS_RESULT_DISCONNECT; return; } device_lock(&pdev->dev); @@ -304,8 +303,9 @@ static void eeh_pe_report(const char *name, struct eeh_pe *root, struct eeh_dev *edev, *tmp; pr_info("EEH: Beginning: '%s'\n", name); - eeh_for_each_pe(root, pe) eeh_pe_for_each_dev(pe, edev, tmp) - eeh_pe_report_edev(edev, fn, result); + eeh_for_each_pe(root, pe) + eeh_pe_for_each_dev(pe, edev, tmp) + eeh_pe_report_edev(edev, fn, result); if (result) pr_info("EEH: Finished:'%s' with aggregate recovery state:'%s'\n", name, pci_ers_result_name(*result)); @@ -383,6 +383,8 @@ static void eeh_dev_restore_state(struct eeh_dev *edev, void *userdata) if (!edev) return; + pci_lock_rescan_remove(); + /* * The content in the config space isn't saved because * the blocked config space on some adapters. We have @@ -393,14 +395,19 @@ static void eeh_dev_restore_state(struct eeh_dev *edev, void *userdata) if (list_is_last(&edev->entry, &edev->pe->edevs)) eeh_pe_restore_bars(edev->pe); + pci_unlock_rescan_remove(); return; } pdev = eeh_dev_to_pci_dev(edev); - if (!pdev) + if (!pdev) { + pci_unlock_rescan_remove(); return; + } pci_restore_state(pdev); + + pci_unlock_rescan_remove(); } /** @@ -647,9 +654,7 @@ static int eeh_reset_device(struct eeh_pe *pe, struct pci_bus *bus, if (any_passed || driver_eeh_aware || (pe->type & EEH_PE_VF)) { eeh_pe_dev_traverse(pe, eeh_rmv_device, rmv_data); } else { - pci_lock_rescan_remove(); pci_hp_remove_devices(bus); - pci_unlock_rescan_remove(); } /* @@ -665,8 +670,6 @@ static int eeh_reset_device(struct eeh_pe *pe, struct pci_bus *bus, if (rc) return rc; - pci_lock_rescan_remove(); - /* Restore PE */ eeh_ops->configure_bridge(pe); eeh_pe_restore_bars(pe); @@ -674,7 +677,6 @@ static int eeh_reset_device(struct eeh_pe *pe, struct pci_bus *bus, /* Clear frozen state */ rc = eeh_clear_pe_frozen_state(pe, false); if (rc) { - pci_unlock_rescan_remove(); return rc; } @@ -709,7 +711,6 @@ static int eeh_reset_device(struct eeh_pe *pe, struct pci_bus *bus, pe->tstamp = tstamp; pe->freeze_count = cnt; - pci_unlock_rescan_remove(); return 0; } @@ -843,10 +844,13 @@ void eeh_handle_normal_event(struct eeh_pe *pe) {LIST_HEAD_INIT(rmv_data.removed_vf_list), 0}; int devices = 0; + pci_lock_rescan_remove(); + bus = eeh_pe_bus_get(pe); if (!bus) { pr_err("%s: Cannot find PCI bus for PHB#%x-PE#%x\n", __func__, pe->phb->global_number, pe->addr); + pci_unlock_rescan_remove(); return; } @@ -1094,10 +1098,15 @@ void eeh_handle_normal_event(struct eeh_pe *pe) eeh_pe_state_clear(pe, EEH_PE_PRI_BUS, true); eeh_pe_dev_mode_mark(pe, EEH_DEV_REMOVED); - pci_lock_rescan_remove(); - pci_hp_remove_devices(bus); - pci_unlock_rescan_remove(); + bus = eeh_pe_bus_get(pe); + if (bus) + pci_hp_remove_devices(bus); + else + pr_err("%s: PCI bus for PHB#%x-PE#%x disappeared\n", + __func__, pe->phb->global_number, pe->addr); + /* The passed PE should no longer be used */ + pci_unlock_rescan_remove(); return; } @@ -1114,6 +1123,8 @@ void eeh_handle_normal_event(struct eeh_pe *pe) eeh_clear_slot_attention(edev->pdev); eeh_pe_state_clear(pe, EEH_PE_RECOVERING, true); + + pci_unlock_rescan_remove(); } /** @@ -1132,6 +1143,7 @@ void eeh_handle_special_event(void) unsigned long flags; int rc; + pci_lock_rescan_remove(); do { rc = eeh_ops->next_error(&pe); @@ -1171,10 +1183,12 @@ void eeh_handle_special_event(void) break; case EEH_NEXT_ERR_NONE: + pci_unlock_rescan_remove(); return; default: pr_warn("%s: Invalid value %d from next_error()\n", __func__, rc); + pci_unlock_rescan_remove(); return; } @@ -1186,7 +1200,9 @@ void eeh_handle_special_event(void) if (rc == EEH_NEXT_ERR_FROZEN_PE || rc == EEH_NEXT_ERR_FENCED_PHB) { eeh_pe_state_mark(pe, EEH_PE_RECOVERING); + pci_unlock_rescan_remove(); eeh_handle_normal_event(pe); + pci_lock_rescan_remove(); } else { eeh_for_each_pe(pe, tmp_pe) eeh_pe_for_each_dev(tmp_pe, edev, tmp_edev) @@ -1199,7 +1215,6 @@ void eeh_handle_special_event(void) eeh_report_failure, NULL); eeh_set_channel_state(pe, pci_channel_io_perm_failure); - pci_lock_rescan_remove(); list_for_each_entry(hose, &hose_list, list_node) { phb_pe = eeh_phb_pe_get(hose); if (!phb_pe || @@ -1218,7 +1233,6 @@ void eeh_handle_special_event(void) } pci_hp_remove_devices(bus); } - pci_unlock_rescan_remove(); } /* @@ -1228,4 +1242,6 @@ void eeh_handle_special_event(void) if (rc == EEH_NEXT_ERR_DEAD_IOC) break; } while (rc != EEH_NEXT_ERR_NONE); + + pci_unlock_rescan_remove(); } diff --git a/arch/powerpc/kernel/eeh_pe.c b/arch/powerpc/kernel/eeh_pe.c index d283d281d28e..e740101fadf3 100644 --- a/arch/powerpc/kernel/eeh_pe.c +++ b/arch/powerpc/kernel/eeh_pe.c @@ -671,10 +671,12 @@ static void eeh_bridge_check_link(struct eeh_dev *edev) eeh_ops->write_config(edev, cap + PCI_EXP_LNKCTL, 2, val); /* Check link */ - if (!edev->pdev->link_active_reporting) { - eeh_edev_dbg(edev, "No link reporting capability\n"); - msleep(1000); - return; + if (edev->pdev) { + if (!edev->pdev->link_active_reporting) { + eeh_edev_dbg(edev, "No link reporting capability\n"); + msleep(1000); + return; + } } /* Wait the link is up until timeout (5s) */ -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 378/480] PCI: pnv_php: Fix surprise plug detection and recovery 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (376 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 377/480] powerpc/eeh: Make EEH driver device hotplug safe Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 379/480] tools/power turbostat: regression fix: --show C1E% Greg Kroah-Hartman ` (113 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Timothy Pearson, Bjorn Helgaas, Madhavan Srinivasan, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Timothy Pearson <tpearson@raptorengineering.com> [ Upstream commit a2a2a6fc2469524caa713036297c542746d148dc ] The existing PowerNV hotplug code did not handle surprise plug events correctly, leading to a complete failure of the hotplug system after device removal and a required reboot to detect new devices. This comes down to two issues: 1) When a device is surprise removed, often the bridge upstream port will cause a PE freeze on the PHB. If this freeze is not cleared, the MSI interrupts from the bridge hotplug notification logic will not be received by the kernel, stalling all plug events on all slots associated with the PE. 2) When a device is removed from a slot, regardless of surprise or programmatic removal, the associated PHB/PE ls left frozen. If this freeze is not cleared via a fundamental reset, skiboot is unable to clear the freeze and cannot retrain / rescan the slot. This also requires a reboot to clear the freeze and redetect the device in the slot. Issue the appropriate unfreeze and rescan commands on hotplug events, and don't oops on hotplug if pci_bus_to_OF_node() returns NULL. Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com> [bhelgaas: tidy comments] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/171044224.1359864.1752615546988.JavaMail.zimbra@raptorengineeringinc.com Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/powerpc/kernel/pci-hotplug.c | 3 + drivers/pci/hotplug/pnv_php.c | 110 +++++++++++++++++++++++++++++- 2 files changed, 110 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/kernel/pci-hotplug.c b/arch/powerpc/kernel/pci-hotplug.c index 9ea74973d78d..6f444d0822d8 100644 --- a/arch/powerpc/kernel/pci-hotplug.c +++ b/arch/powerpc/kernel/pci-hotplug.c @@ -141,6 +141,9 @@ void pci_hp_add_devices(struct pci_bus *bus) struct pci_controller *phb; struct device_node *dn = pci_bus_to_OF_node(bus); + if (!dn) + return; + phb = pci_bus_to_host(bus); mode = PCI_PROBE_NORMAL; diff --git a/drivers/pci/hotplug/pnv_php.c b/drivers/pci/hotplug/pnv_php.c index 5476c9e7760d..4f85e7fe29ec 100644 --- a/drivers/pci/hotplug/pnv_php.c +++ b/drivers/pci/hotplug/pnv_php.c @@ -4,12 +4,14 @@ * * Copyright Gavin Shan, IBM Corporation 2016. * Copyright (C) 2025 Raptor Engineering, LLC + * Copyright (C) 2025 Raptor Computing Systems, LLC */ #include <linux/bitfield.h> #include <linux/libfdt.h> #include <linux/module.h> #include <linux/pci.h> +#include <linux/delay.h> #include <linux/pci_hotplug.h> #include <linux/of_fdt.h> @@ -469,6 +471,61 @@ static int pnv_php_set_attention_state(struct hotplug_slot *slot, u8 state) return 0; } +static int pnv_php_activate_slot(struct pnv_php_slot *php_slot, + struct hotplug_slot *slot) +{ + int ret, i; + + /* + * Issue initial slot activation command to firmware + * + * Firmware will power slot on, attempt to train the link, and + * discover any downstream devices. If this process fails, firmware + * will return an error code and an invalid device tree. Failure + * can be caused for multiple reasons, including a faulty + * downstream device, poor connection to the downstream device, or + * a previously latched PHB fence. On failure, issue fundamental + * reset up to three times before aborting. + */ + ret = pnv_php_set_slot_power_state(slot, OPAL_PCI_SLOT_POWER_ON); + if (ret) { + SLOT_WARN( + php_slot, + "PCI slot activation failed with error code %d, possible frozen PHB", + ret); + SLOT_WARN( + php_slot, + "Attempting complete PHB reset before retrying slot activation\n"); + for (i = 0; i < 3; i++) { + /* + * Slot activation failed, PHB may be fenced from a + * prior device failure. + * + * Use the OPAL fundamental reset call to both try a + * device reset and clear any potentially active PHB + * fence / freeze. + */ + SLOT_WARN(php_slot, "Try %d...\n", i + 1); + pci_set_pcie_reset_state(php_slot->pdev, + pcie_warm_reset); + msleep(250); + pci_set_pcie_reset_state(php_slot->pdev, + pcie_deassert_reset); + + ret = pnv_php_set_slot_power_state( + slot, OPAL_PCI_SLOT_POWER_ON); + if (!ret) + break; + } + + if (i >= 3) + SLOT_WARN(php_slot, + "Failed to bring slot online, aborting!\n"); + } + + return ret; +} + static int pnv_php_enable(struct pnv_php_slot *php_slot, bool rescan) { struct hotplug_slot *slot = &php_slot->slot; @@ -531,7 +588,7 @@ static int pnv_php_enable(struct pnv_php_slot *php_slot, bool rescan) goto scan; /* Power is off, turn it on and then scan the slot */ - ret = pnv_php_set_slot_power_state(slot, OPAL_PCI_SLOT_POWER_ON); + ret = pnv_php_activate_slot(php_slot, slot); if (ret) return ret; @@ -838,16 +895,63 @@ static int pnv_php_enable_msix(struct pnv_php_slot *php_slot) return entry.vector; } +static void +pnv_php_detect_clear_suprise_removal_freeze(struct pnv_php_slot *php_slot) +{ + struct pci_dev *pdev = php_slot->pdev; + struct eeh_dev *edev; + struct eeh_pe *pe; + int i, rc; + + /* + * When a device is surprise removed from a downstream bridge slot, + * the upstream bridge port can still end up frozen due to related EEH + * events, which will in turn block the MSI interrupts for slot hotplug + * detection. + * + * Detect and thaw any frozen upstream PE after slot deactivation. + */ + edev = pci_dev_to_eeh_dev(pdev); + pe = edev ? edev->pe : NULL; + rc = eeh_pe_get_state(pe); + if ((rc == -ENODEV) || (rc == -ENOENT)) { + SLOT_WARN( + php_slot, + "Upstream bridge PE state unknown, hotplug detect may fail\n"); + } else { + if (pe->state & EEH_PE_ISOLATED) { + SLOT_WARN( + php_slot, + "Upstream bridge PE %02x frozen, thawing...\n", + pe->addr); + for (i = 0; i < 3; i++) + if (!eeh_unfreeze_pe(pe)) + break; + if (i >= 3) + SLOT_WARN( + php_slot, + "Unable to thaw PE %02x, hotplug detect will fail!\n", + pe->addr); + else + SLOT_WARN(php_slot, + "PE %02x thawed successfully\n", + pe->addr); + } + } +} + static void pnv_php_event_handler(struct work_struct *work) { struct pnv_php_event *event = container_of(work, struct pnv_php_event, work); struct pnv_php_slot *php_slot = event->php_slot; - if (event->added) + if (event->added) { pnv_php_enable_slot(&php_slot->slot); - else + } else { pnv_php_disable_slot(&php_slot->slot); + pnv_php_detect_clear_suprise_removal_freeze(php_slot); + } kfree(event); } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 379/480] tools/power turbostat: regression fix: --show C1E% 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (377 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 378/480] PCI: pnv_php: Fix surprise plug detection and recovery Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 380/480] pNFS/flexfiles: dont attempt pnfs on fatal DS errors Greg Kroah-Hartman ` (112 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Zhang Rui, Len Brown, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Len Brown <len.brown@intel.com> [ Upstream commit 5d939fbdd480cdf276eccc01eda3ed41e37d3f8a ] The new default idle counter groupings broke "--show C1E%" (or any other C-state %) Also delete a stray debug printf from the same offending commit. Reported-by: Zhang Rui <rui.zhang@intel.com> Fixes: ec4acd3166d8 ("tools/power turbostat: disable "cpuidle" invocation counters, by default") Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/power/x86/turbostat/turbostat.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/tools/power/x86/turbostat/turbostat.c b/tools/power/x86/turbostat/turbostat.c index ab79854cb296..7a407694d221 100644 --- a/tools/power/x86/turbostat/turbostat.c +++ b/tools/power/x86/turbostat/turbostat.c @@ -2385,7 +2385,6 @@ unsigned long long bic_lookup(char *name_list, enum show_hide_mode mode) } if (i == MAX_BIC) { - fprintf(stderr, "deferred %s\n", name_list); if (mode == SHOW_LIST) { deferred_add_names[deferred_add_index++] = name_list; if (deferred_add_index >= MAX_DEFERRED) { @@ -10314,9 +10313,6 @@ void probe_cpuidle_residency(void) int min_state = 1024, max_state = 0; char *sp; - if (!DO_BIC(BIC_pct_idle)) - return; - for (state = 10; state >= 0; --state) { sprintf(path, "/sys/devices/system/cpu/cpu%d/cpuidle/state%d/name", base_cpu, state); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 380/480] pNFS/flexfiles: dont attempt pnfs on fatal DS errors 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (378 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 379/480] tools/power turbostat: regression fix: --show C1E% Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 381/480] NFS: Fix wakeup of __nfs_lookup_revalidate() in unblock_revalidate() Greg Kroah-Hartman ` (111 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Tigran Mkrtchyan, Trond Myklebust, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de> [ Upstream commit f06bedfa62d57f7b67d44aacd6badad2e13a803f ] When an applications get killed (SIGTERM/SIGINT) while pNFS client performs a connection to DS, client ends in an infinite loop of connect-disconnect. This source of the issue, it that flexfilelayoutdev#nfs4_ff_layout_prepare_ds gets an error on nfs4_pnfs_ds_connect with status ERESTARTSYS, which is set by rpc_signal_task, but the error is treated as transient, thus retried. The issue is reproducible with Ctrl+C the following script(there should be ~1000 files in a directory, client should must not have any connections to DSes): ``` echo 3 > /proc/sys/vm/drop_caches for i in * do head -1 $i done ``` The change aims to propagate the nfs4_ff_layout_prepare_ds error state to the caller that can decide whatever this is a retryable error or not. Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de> Link: https://lore.kernel.org/r/20250627071751.189663-1-tigran.mkrtchyan@desy.de Fixes: 260f32adb88d ("pNFS/flexfiles: Check the result of nfs4_pnfs_ds_connect") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/nfs/flexfilelayout/flexfilelayout.c | 26 ++++++++++++++--------- fs/nfs/flexfilelayout/flexfilelayoutdev.c | 6 +++--- 2 files changed, 19 insertions(+), 13 deletions(-) diff --git a/fs/nfs/flexfilelayout/flexfilelayout.c b/fs/nfs/flexfilelayout/flexfilelayout.c index 4bea008dbebd..8dc921d83538 100644 --- a/fs/nfs/flexfilelayout/flexfilelayout.c +++ b/fs/nfs/flexfilelayout/flexfilelayout.c @@ -762,14 +762,14 @@ ff_layout_choose_ds_for_read(struct pnfs_layout_segment *lseg, { struct nfs4_ff_layout_segment *fls = FF_LAYOUT_LSEG(lseg); struct nfs4_ff_layout_mirror *mirror; - struct nfs4_pnfs_ds *ds; + struct nfs4_pnfs_ds *ds = ERR_PTR(-EAGAIN); u32 idx; /* mirrors are initially sorted by efficiency */ for (idx = start_idx; idx < fls->mirror_array_cnt; idx++) { mirror = FF_LAYOUT_COMP(lseg, idx); ds = nfs4_ff_layout_prepare_ds(lseg, mirror, false); - if (!ds) + if (IS_ERR(ds)) continue; if (check_device && @@ -777,10 +777,10 @@ ff_layout_choose_ds_for_read(struct pnfs_layout_segment *lseg, continue; *best_idx = idx; - return ds; + break; } - return NULL; + return ds; } static struct nfs4_pnfs_ds * @@ -942,7 +942,7 @@ ff_layout_pg_init_write(struct nfs_pageio_descriptor *pgio, for (i = 0; i < pgio->pg_mirror_count; i++) { mirror = FF_LAYOUT_COMP(pgio->pg_lseg, i); ds = nfs4_ff_layout_prepare_ds(pgio->pg_lseg, mirror, true); - if (!ds) { + if (IS_ERR(ds)) { if (!ff_layout_no_fallback_to_mds(pgio->pg_lseg)) goto out_mds; pnfs_generic_pg_cleanup(pgio); @@ -1867,6 +1867,7 @@ ff_layout_read_pagelist(struct nfs_pgio_header *hdr) u32 idx = hdr->pgio_mirror_idx; int vers; struct nfs_fh *fh; + bool ds_fatal_error = false; dprintk("--> %s ino %lu pgbase %u req %zu@%llu\n", __func__, hdr->inode->i_ino, @@ -1874,8 +1875,10 @@ ff_layout_read_pagelist(struct nfs_pgio_header *hdr) mirror = FF_LAYOUT_COMP(lseg, idx); ds = nfs4_ff_layout_prepare_ds(lseg, mirror, false); - if (!ds) + if (IS_ERR(ds)) { + ds_fatal_error = nfs_error_is_fatal(PTR_ERR(ds)); goto out_failed; + } ds_clnt = nfs4_ff_find_or_create_ds_client(mirror, ds->ds_clp, hdr->inode); @@ -1923,7 +1926,7 @@ ff_layout_read_pagelist(struct nfs_pgio_header *hdr) return PNFS_ATTEMPTED; out_failed: - if (ff_layout_avoid_mds_available_ds(lseg)) + if (ff_layout_avoid_mds_available_ds(lseg) && !ds_fatal_error) return PNFS_TRY_AGAIN; trace_pnfs_mds_fallback_read_pagelist(hdr->inode, hdr->args.offset, hdr->args.count, @@ -1945,11 +1948,14 @@ ff_layout_write_pagelist(struct nfs_pgio_header *hdr, int sync) int vers; struct nfs_fh *fh; u32 idx = hdr->pgio_mirror_idx; + bool ds_fatal_error = false; mirror = FF_LAYOUT_COMP(lseg, idx); ds = nfs4_ff_layout_prepare_ds(lseg, mirror, true); - if (!ds) + if (IS_ERR(ds)) { + ds_fatal_error = nfs_error_is_fatal(PTR_ERR(ds)); goto out_failed; + } ds_clnt = nfs4_ff_find_or_create_ds_client(mirror, ds->ds_clp, hdr->inode); @@ -2000,7 +2006,7 @@ ff_layout_write_pagelist(struct nfs_pgio_header *hdr, int sync) return PNFS_ATTEMPTED; out_failed: - if (ff_layout_avoid_mds_available_ds(lseg)) + if (ff_layout_avoid_mds_available_ds(lseg) && !ds_fatal_error) return PNFS_TRY_AGAIN; trace_pnfs_mds_fallback_write_pagelist(hdr->inode, hdr->args.offset, hdr->args.count, @@ -2043,7 +2049,7 @@ static int ff_layout_initiate_commit(struct nfs_commit_data *data, int how) idx = calc_ds_index_from_commit(lseg, data->ds_commit_index); mirror = FF_LAYOUT_COMP(lseg, idx); ds = nfs4_ff_layout_prepare_ds(lseg, mirror, true); - if (!ds) + if (IS_ERR(ds)) goto out_err; ds_clnt = nfs4_ff_find_or_create_ds_client(mirror, ds->ds_clp, diff --git a/fs/nfs/flexfilelayout/flexfilelayoutdev.c b/fs/nfs/flexfilelayout/flexfilelayoutdev.c index 656d5c50bbce..30365ec782bb 100644 --- a/fs/nfs/flexfilelayout/flexfilelayoutdev.c +++ b/fs/nfs/flexfilelayout/flexfilelayoutdev.c @@ -370,11 +370,11 @@ nfs4_ff_layout_prepare_ds(struct pnfs_layout_segment *lseg, struct nfs4_ff_layout_mirror *mirror, bool fail_return) { - struct nfs4_pnfs_ds *ds = NULL; + struct nfs4_pnfs_ds *ds; struct inode *ino = lseg->pls_layout->plh_inode; struct nfs_server *s = NFS_SERVER(ino); unsigned int max_payload; - int status; + int status = -EAGAIN; if (!ff_layout_init_mirror_ds(lseg->pls_layout, mirror)) goto noconnect; @@ -418,7 +418,7 @@ nfs4_ff_layout_prepare_ds(struct pnfs_layout_segment *lseg, ff_layout_send_layouterror(lseg); if (fail_return || !ff_layout_has_available_ds(lseg)) pnfs_error_mark_layout_for_return(ino, lseg); - ds = NULL; + ds = ERR_PTR(status); out: return ds; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 381/480] NFS: Fix wakeup of __nfs_lookup_revalidate() in unblock_revalidate() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (379 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 380/480] pNFS/flexfiles: dont attempt pnfs on fatal DS errors Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 382/480] NFS: Fix filehandle bounds checking in nfs_fh_to_dentry() Greg Kroah-Hartman ` (110 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Lukáš Hejtmánek, Santosh Pradhan, Trond Myklebust, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Trond Myklebust <trond.myklebust@hammerspace.com> [ Upstream commit 1db3a48e83bb64a70bf27263b7002585574a9c2d ] Use store_release_wake_up() to add the appropriate memory barrier before calling wake_up_var(&dentry->d_fsdata). Reported-by: Lukáš Hejtmánek<xhejtman@ics.muni.cz> Suggested-by: Santosh Pradhan <santosh.pradhan@gmail.com> Link: https://lore.kernel.org/all/18945D18-3EDB-4771-B019-0335CE671077@ics.muni.cz/ Fixes: 99bc9f2eb3f7 ("NFS: add barriers when testing for NFS_FSDATA_BLOCKED") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/nfs/dir.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c index d0e0b435a843..d81217923936 100644 --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -1828,9 +1828,7 @@ static void block_revalidate(struct dentry *dentry) static void unblock_revalidate(struct dentry *dentry) { - /* store_release ensures wait_var_event() sees the update */ - smp_store_release(&dentry->d_fsdata, NULL); - wake_up_var(&dentry->d_fsdata); + store_release_wake_up(&dentry->d_fsdata, NULL); } /* -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 382/480] NFS: Fix filehandle bounds checking in nfs_fh_to_dentry() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (380 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 381/480] NFS: Fix wakeup of __nfs_lookup_revalidate() in unblock_revalidate() Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 383/480] NFSv4.2: another fix for listxattr Greg Kroah-Hartman ` (109 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, zhangjian, Trond Myklebust, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Trond Myklebust <trond.myklebust@hammerspace.com> [ Upstream commit ef93a685e01a281b5e2a25ce4e3428cf9371a205 ] The function needs to check the minimal filehandle length before it can access the embedded filehandle. Reported-by: zhangjian <zhangjian496@huawei.com> Fixes: 20fa19027286 ("nfs: add export operations") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/nfs/export.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/fs/nfs/export.c b/fs/nfs/export.c index e9c233b6fd20..a10dd5f9d078 100644 --- a/fs/nfs/export.c +++ b/fs/nfs/export.c @@ -66,14 +66,21 @@ nfs_fh_to_dentry(struct super_block *sb, struct fid *fid, { struct nfs_fattr *fattr = NULL; struct nfs_fh *server_fh = nfs_exp_embedfh(fid->raw); - size_t fh_size = offsetof(struct nfs_fh, data) + server_fh->size; + size_t fh_size = offsetof(struct nfs_fh, data); const struct nfs_rpc_ops *rpc_ops; struct dentry *dentry; struct inode *inode; - int len = EMBED_FH_OFF + XDR_QUADLEN(fh_size); + int len = EMBED_FH_OFF; u32 *p = fid->raw; int ret; + /* Initial check of bounds */ + if (fh_len < len + XDR_QUADLEN(fh_size) || + fh_len > XDR_QUADLEN(NFS_MAXFHSIZE)) + return NULL; + /* Calculate embedded filehandle size */ + fh_size += server_fh->size; + len += XDR_QUADLEN(fh_size); /* NULL translates to ESTALE */ if (fh_len < len || fh_type != len) return NULL; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 383/480] NFSv4.2: another fix for listxattr 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (381 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 382/480] NFS: Fix filehandle bounds checking in nfs_fh_to_dentry() Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 384/480] NFS: Fixup allocation flags for nfsiods __GFP_NORETRY Greg Kroah-Hartman ` (108 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Olga Kornievskaia, Trond Myklebust, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Olga Kornievskaia <okorniev@redhat.com> [ Upstream commit 9acb237deff7667b0f6b10fe6b1b70c4429ea049 ] Currently, when the server supports NFS4.1 security labels then security.selinux label in included twice. Instead, only add it when the server doesn't possess security label support. Fixes: 243fea134633 ("NFSv4.2: fix listxattr to return selinux security label") Signed-off-by: Olga Kornievskaia <okorniev@redhat.com> Link: https://lore.kernel.org/r/20250722205641.79394-1-okorniev@redhat.com Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/nfs/nfs4proc.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index 2f5a6aa3fd48..3c1ef174aa81 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -10866,7 +10866,7 @@ const struct nfs4_minor_version_ops *nfs_v4_minor_ops[] = { static ssize_t nfs4_listxattr(struct dentry *dentry, char *list, size_t size) { - ssize_t error, error2, error3, error4; + ssize_t error, error2, error3, error4 = 0; size_t left = size; error = generic_listxattr(dentry, list, left); @@ -10894,9 +10894,11 @@ static ssize_t nfs4_listxattr(struct dentry *dentry, char *list, size_t size) left -= error3; } - error4 = security_inode_listsecurity(d_inode(dentry), list, left); - if (error4 < 0) - return error4; + if (!nfs_server_capable(d_inode(dentry), NFS_CAP_SECURITY_LABEL)) { + error4 = security_inode_listsecurity(d_inode(dentry), list, left); + if (error4 < 0) + return error4; + } error += error2 + error3 + error4; if (size && error > size) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 384/480] NFS: Fixup allocation flags for nfsiods __GFP_NORETRY 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (382 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 383/480] NFSv4.2: another fix for listxattr Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 385/480] md/md-cluster: handle REMOVE message earlier Greg Kroah-Hartman ` (107 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Trond Myklebust, Benjamin Coddington, Laurence Oberman, Jeff Layton, Trond Myklebust, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Benjamin Coddington <bcodding@redhat.com> [ Upstream commit 99765233ab42bf7a4950377ad7894dce8a5c0e60 ] If the NFS client is doing writeback from a workqueue context, avoid using __GFP_NORETRY for allocations if the task has set PF_MEMALLOC_NOIO or PF_MEMALLOC_NOFS. The combination of these flags makes memory allocation failures much more likely. We've seen those allocation failures show up when the loopback driver is doing writeback from a workqueue to a file on NFS, where memory allocation failure results in errors or corruption within the loopback device's filesystem. Suggested-by: Trond Myklebust <trondmy@kernel.org> Fixes: 0bae835b63c5 ("NFS: Avoid writeback threads getting stuck in mempool_alloc()") Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Reviewed-by: Laurence Oberman <loberman@redhat.com> Tested-by: Laurence Oberman <loberman@redhat.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> Link: https://lore.kernel.org/r/f83ac1155a4bc670f2663959a7a068571e06afd9.1752111622.git.bcodding@redhat.com Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/nfs/internal.h | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/fs/nfs/internal.h b/fs/nfs/internal.h index 69c2c10ee658..d8f768254f16 100644 --- a/fs/nfs/internal.h +++ b/fs/nfs/internal.h @@ -671,9 +671,12 @@ nfs_write_match_verf(const struct nfs_writeverf *verf, static inline gfp_t nfs_io_gfp_mask(void) { - if (current->flags & PF_WQ_WORKER) - return GFP_KERNEL | __GFP_NORETRY | __GFP_NOWARN; - return GFP_KERNEL; + gfp_t ret = current_gfp_context(GFP_KERNEL); + + /* For workers __GFP_NORETRY only with __GFP_IO or __GFP_FS */ + if ((current->flags & PF_WQ_WORKER) && ret == GFP_KERNEL) + ret |= __GFP_NORETRY | __GFP_NOWARN; + return ret; } /* -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 385/480] md/md-cluster: handle REMOVE message earlier 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (383 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 384/480] NFS: Fixup allocation flags for nfsiods __GFP_NORETRY Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 386/480] netpoll: prevent hanging NAPI when netcons gets enabled Greg Kroah-Hartman ` (106 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Heming Zhao, Su Yue, Yu Kuai, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Heming Zhao <heming.zhao@suse.com> [ Upstream commit 948b1fe12005d39e2b49087b50e5ee55c9a8f76f ] Commit a1fd37f97808 ("md: Don't wait for MD_RECOVERY_NEEDED for HOT_REMOVE_DISK ioctl") introduced a regression in the md_cluster module. (Failed cases 02r1_Manage_re-add & 02r10_Manage_re-add) Consider a 2-node cluster: - node1 set faulty & remove command on a disk. - node2 must correctly update the array metadata. Before a1fd37f97808, on node1, the delay between msg:METADATA_UPDATED (triggered by faulty) and msg:REMOVE was sufficient for node2 to reload the disk info (written by node1). After a1fd37f97808, node1 no longer waits between faulty and remove, causing it to send msg:REMOVE while node2 is still reloading disk info. This often results in node2 failing to remove the faulty disk. == how to trigger == set up a 2-node cluster (node1 & node2) with disks vdc & vdd. on node1: mdadm -CR /dev/md0 -l1 -b clustered -n2 /dev/vdc /dev/vdd --assume-clean ssh node2-ip mdadm -A /dev/md0 /dev/vdc /dev/vdd mdadm --manage /dev/md0 --fail /dev/vdc --remove /dev/vdc check array status on both nodes with "mdadm -D /dev/md0". node1 output: Number Major Minor RaidDevice State - 0 0 0 removed 1 254 48 1 active sync /dev/vdd node2 output: Number Major Minor RaidDevice State - 0 0 0 removed 1 254 48 1 active sync /dev/vdd 0 254 32 - faulty /dev/vdc Fixes: a1fd37f97808 ("md: Don't wait for MD_RECOVERY_NEEDED for HOT_REMOVE_DISK ioctl") Signed-off-by: Heming Zhao <heming.zhao@suse.com> Reviewed-by: Su Yue <glass.su@suse.com> Link: https://lore.kernel.org/linux-raid/20250728042145.9989-1-heming.zhao@suse.com Signed-off-by: Yu Kuai <yukuai3@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/md/md.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/md/md.c b/drivers/md/md.c index 0de87d451a47..47f3253c4757 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -9692,8 +9692,8 @@ void md_check_recovery(struct mddev *mddev) * remove disk. */ rdev_for_each_safe(rdev, tmp, mddev) { - if (test_and_clear_bit(ClusterRemove, &rdev->flags) && - rdev->raid_disk < 0) + if (rdev->raid_disk < 0 && + test_and_clear_bit(ClusterRemove, &rdev->flags)) md_kick_rdev_from_array(rdev); } } @@ -9999,8 +9999,11 @@ static void check_sb_changes(struct mddev *mddev, struct md_rdev *rdev) /* Check for change of roles in the active devices */ rdev_for_each_safe(rdev2, tmp, mddev) { - if (test_bit(Faulty, &rdev2->flags)) + if (test_bit(Faulty, &rdev2->flags)) { + if (test_bit(ClusterRemove, &rdev2->flags)) + set_bit(MD_RECOVERY_NEEDED, &mddev->recovery); continue; + } /* Check if the roles changed */ role = le16_to_cpu(sb->dev_roles[rdev2->desc_nr]); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 386/480] netpoll: prevent hanging NAPI when netcons gets enabled 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (384 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 385/480] md/md-cluster: handle REMOVE message earlier Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 387/480] phy: mscc: Fix parsing of unicast frames Greg Kroah-Hartman ` (105 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Paolo Abeni, Jason Wang, Xuan Zhuo, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jakub Kicinski <kuba@kernel.org> [ Upstream commit 2da4def0f487f24bbb0cece3bb2bcdcb918a0b72 ] Paolo spotted hangs in NIPA running driver tests against virtio. The tests hang in virtnet_close() -> virtnet_napi_tx_disable(). The problem is only reproducible if running multiple of our tests in sequence (I used TEST_PROGS="xdp.py ping.py netcons_basic.sh \ netpoll_basic.py stats.py"). Initial suspicion was that this is a simple case of double-disable of NAPI, but instrumenting the code reveals: Deadlocked on NAPI ffff888007cd82c0 (virtnet_poll_tx): state: 0x37, disabled: false, owner: 0, listed: false, weight: 64 The NAPI was not in fact disabled, owner is 0 (rather than -1), so the NAPI "thinks" it's scheduled for CPU 0 but it's not listed (!list_empty(&n->poll_list) => false). It seems odd that normal NAPI processing would wedge itself like this. Better suspicion is that netpoll gets enabled while NAPI is polling, and also grabs the NAPI instance. This confuses napi_complete_done(): [netpoll] [normal NAPI] napi_poll() have = netpoll_poll_lock() rcu_access_pointer(dev->npinfo) return NULL # no netpoll __napi_poll() ->poll(->weight) poll_napi() cmpxchg(->poll_owner, -1, cpu) poll_one_napi() set_bit(NAPI_STATE_NPSVC, ->state) napi_complete_done() if (NAPIF_STATE_NPSVC) return false # exit without clearing SCHED This feels very unlikely, but perhaps virtio has some interactions with the hypervisor in the NAPI ->poll that makes the race window larger? Best I could to to prove the theory was to add and trigger this warning in napi_poll (just before netpoll_poll_unlock()): WARN_ONCE(!have && rcu_access_pointer(n->dev->npinfo) && napi_is_scheduled(n) && list_empty(&n->poll_list), "NAPI race with netpoll %px", n); If this warning hits the next virtio_close() will hang. This patch survived 30 test iterations without a hang (without it the longest clean run was around 10). Credit for triggering this goes to Breno's recent netconsole tests. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Paolo Abeni <pabeni@redhat.com> Link: https://lore.kernel.org/c5a93ed1-9abe-4880-a3bb-8d1678018b1d@redhat.com Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Link: https://patch.msgid.link/20250726010846.1105875-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/core/netpoll.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/net/core/netpoll.c b/net/core/netpoll.c index 6ad84d4a2b46..63477a6dd6e9 100644 --- a/net/core/netpoll.c +++ b/net/core/netpoll.c @@ -831,6 +831,13 @@ int netpoll_setup(struct netpoll *np) if (err) goto flush; rtnl_unlock(); + + /* Make sure all NAPI polls which started before dev->npinfo + * was visible have exited before we start calling NAPI poll. + * NAPI skips locking if dev->npinfo is NULL. + */ + synchronize_rcu(); + return 0; flush: -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 387/480] phy: mscc: Fix parsing of unicast frames 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (385 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 386/480] netpoll: prevent hanging NAPI when netcons gets enabled Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 388/480] net: ipa: add IPA v5.1 and v5.5 to ipa_version_string() Greg Kroah-Hartman ` (104 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Horatiu Vultur, Andrew Lunn, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Horatiu Vultur <horatiu.vultur@microchip.com> [ Upstream commit 6fb5ff63b35b7e849cc8510957f25753f87f63d2 ] According to the 1588 standard, it is possible to use both unicast and multicast frames to send the PTP information. It was noticed that if the frames were unicast they were not processed by the analyzer meaning that they were not timestamped. Therefore fix this to match also these unicast frames. Fixes: ab2bf9339357 ("net: phy: mscc: 1588 block initialization") Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250726140307.3039694-1-horatiu.vultur@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/phy/mscc/mscc_ptp.c | 1 + drivers/net/phy/mscc/mscc_ptp.h | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/net/phy/mscc/mscc_ptp.c b/drivers/net/phy/mscc/mscc_ptp.c index 6b800081eed5..275706de5847 100644 --- a/drivers/net/phy/mscc/mscc_ptp.c +++ b/drivers/net/phy/mscc/mscc_ptp.c @@ -900,6 +900,7 @@ static int vsc85xx_eth1_conf(struct phy_device *phydev, enum ts_blk blk, get_unaligned_be32(ptp_multicast)); } else { val |= ANA_ETH1_FLOW_ADDR_MATCH2_ANY_MULTICAST; + val |= ANA_ETH1_FLOW_ADDR_MATCH2_ANY_UNICAST; vsc85xx_ts_write_csr(phydev, blk, MSCC_ANA_ETH1_FLOW_ADDR_MATCH2(0), val); vsc85xx_ts_write_csr(phydev, blk, diff --git a/drivers/net/phy/mscc/mscc_ptp.h b/drivers/net/phy/mscc/mscc_ptp.h index da3465360e90..ae9ad925bfa8 100644 --- a/drivers/net/phy/mscc/mscc_ptp.h +++ b/drivers/net/phy/mscc/mscc_ptp.h @@ -98,6 +98,7 @@ #define MSCC_ANA_ETH1_FLOW_ADDR_MATCH2(x) (MSCC_ANA_ETH1_FLOW_ENA(x) + 3) #define ANA_ETH1_FLOW_ADDR_MATCH2_MASK_MASK GENMASK(22, 20) #define ANA_ETH1_FLOW_ADDR_MATCH2_ANY_MULTICAST 0x400000 +#define ANA_ETH1_FLOW_ADDR_MATCH2_ANY_UNICAST 0x200000 #define ANA_ETH1_FLOW_ADDR_MATCH2_FULL_ADDR 0x100000 #define ANA_ETH1_FLOW_ADDR_MATCH2_SRC_DEST_MASK GENMASK(17, 16) #define ANA_ETH1_FLOW_ADDR_MATCH2_SRC_DEST 0x020000 -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 388/480] net: ipa: add IPA v5.1 and v5.5 to ipa_version_string() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (386 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 387/480] phy: mscc: Fix parsing of unicast frames Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 389/480] pptp: ensure minimal skb length in pptp_xmit() Greg Kroah-Hartman ` (103 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Luca Weiss, Dawid Osuchowski, Alex Elder, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Luca Weiss <luca.weiss@fairphone.com> [ Upstream commit f2aa00e4f65efcf25ff6bc8198e21f031e7b9b1b ] Handle the case for v5.1 and v5.5 instead of returning "0.0". Also reword the comment below since I don't see any evidence of such a check happening, and - since 5.5 has been missing - can happen. Fixes: 3aac8ec1c028 ("net: ipa: add some new IPA versions") Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Reviewed-by: Alex Elder <elder@riscstar.com> Link: https://patch.msgid.link/20250728-ipa-5-1-5-5-version_string-v1-1-d7a5623d7ece@fairphone.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/ipa/ipa_sysfs.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/net/ipa/ipa_sysfs.c b/drivers/net/ipa/ipa_sysfs.c index a59bd215494c..a53e9e6f6cdf 100644 --- a/drivers/net/ipa/ipa_sysfs.c +++ b/drivers/net/ipa/ipa_sysfs.c @@ -37,8 +37,12 @@ static const char *ipa_version_string(struct ipa *ipa) return "4.11"; case IPA_VERSION_5_0: return "5.0"; + case IPA_VERSION_5_1: + return "5.1"; + case IPA_VERSION_5_5: + return "5.5"; default: - return "0.0"; /* Won't happen (checked at probe time) */ + return "0.0"; /* Should not happen */ } } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 389/480] pptp: ensure minimal skb length in pptp_xmit() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (387 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 388/480] net: ipa: add IPA v5.1 and v5.5 to ipa_version_string() Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 390/480] nvmet: initialize discovery subsys after debugfs is initialized Greg Kroah-Hartman ` (102 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, syzbot+afad90ffc8645324afe5, Eric Dumazet, Dawid Osuchowski, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Eric Dumazet <edumazet@google.com> [ Upstream commit de9c4861fb42f0cd72da844c3c34f692d5895b7b ] Commit aabc6596ffb3 ("net: ppp: Add bound checking for skb data on ppp_sync_txmung") fixed ppp_sync_txmunge() We need a similar fix in pptp_xmit(), otherwise we might read uninit data as reported by syzbot. BUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline] ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314 pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x893/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+afad90ffc8645324afe5@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/68887d86.a00a0220.b12ec.00cd.GAE@google.com/T/#u Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Link: https://patch.msgid.link/20250729080207.1863408-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/ppp/pptp.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/drivers/net/ppp/pptp.c b/drivers/net/ppp/pptp.c index 5feaa70b5f47..4cd6f67bd5d3 100644 --- a/drivers/net/ppp/pptp.c +++ b/drivers/net/ppp/pptp.c @@ -159,9 +159,7 @@ static int pptp_xmit(struct ppp_channel *chan, struct sk_buff *skb) int len; unsigned char *data; __u32 seq_recv; - - - struct rtable *rt; + struct rtable *rt = NULL; struct net_device *tdev; struct iphdr *iph; int max_headroom; @@ -179,16 +177,20 @@ static int pptp_xmit(struct ppp_channel *chan, struct sk_buff *skb) if (skb_headroom(skb) < max_headroom || skb_cloned(skb) || skb_shared(skb)) { struct sk_buff *new_skb = skb_realloc_headroom(skb, max_headroom); - if (!new_skb) { - ip_rt_put(rt); + + if (!new_skb) goto tx_error; - } + if (skb->sk) skb_set_owner_w(new_skb, skb->sk); consume_skb(skb); skb = new_skb; } + /* Ensure we can safely access protocol field and LCP code */ + if (!pskb_may_pull(skb, 3)) + goto tx_error; + data = skb->data; islcp = ((data[0] << 8) + data[1]) == PPP_LCP && 1 <= data[2] && data[2] <= 7; @@ -262,6 +264,7 @@ static int pptp_xmit(struct ppp_channel *chan, struct sk_buff *skb) return 1; tx_error: + ip_rt_put(rt); kfree_skb(skb); return 1; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 390/480] nvmet: initialize discovery subsys after debugfs is initialized 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (388 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 389/480] pptp: ensure minimal skb length in pptp_xmit() Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:49 ` [PATCH 6.15 391/480] s390/ap: Unmask SLCF bit in card and queue ap functions sysfs Greg Kroah-Hartman ` (101 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Mohamed Khalfella, Chaitanya Kulkarni, Hannes Reinecke, Daniel Wagner, Christoph Hellwig, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Mohamed Khalfella <mkhalfella@purestorage.com> [ Upstream commit 528589947c1802b9357c2a9b96d88cc4a11cd88b ] During nvme target initialization discovery subsystem is initialized before "nvmet" debugfs directory is created. This results in discovery subsystem debugfs directory to be created in debugfs root directory. nvmet_init() -> nvmet_init_discovery() -> nvmet_subsys_alloc() -> nvmet_debugfs_subsys_setup() In other words, the codepath above is exeucted before nvmet_debugfs is created. We get /sys/kernel/debug/nqn.2014-08.org.nvmexpress.discovery instead of /sys/kernel/debug/nvmet/nqn.2014-08.org.nvmexpress.discovery. Move nvmet_init_discovery() call after nvmet_init_debugfs() to fix it. Fixes: 649fd41420a8 ("nvmet: add debugfs support") Signed-off-by: Mohamed Khalfella <mkhalfella@purestorage.com> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Reviewed-by: Hannes Reinecke <hare@kernel.org> Reviewed-by: Daniel Wagner <dwagner@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/nvme/target/core.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/nvme/target/core.c b/drivers/nvme/target/core.c index 69b1ddff6731..82d0a0fdf912 100644 --- a/drivers/nvme/target/core.c +++ b/drivers/nvme/target/core.c @@ -1906,24 +1906,24 @@ static int __init nvmet_init(void) if (!nvmet_wq) goto out_free_buffered_work_queue; - error = nvmet_init_discovery(); + error = nvmet_init_debugfs(); if (error) goto out_free_nvmet_work_queue; - error = nvmet_init_debugfs(); + error = nvmet_init_discovery(); if (error) - goto out_exit_discovery; + goto out_exit_debugfs; error = nvmet_init_configfs(); if (error) - goto out_exit_debugfs; + goto out_exit_discovery; return 0; -out_exit_debugfs: - nvmet_exit_debugfs(); out_exit_discovery: nvmet_exit_discovery(); +out_exit_debugfs: + nvmet_exit_debugfs(); out_free_nvmet_work_queue: destroy_workqueue(nvmet_wq); out_free_buffered_work_queue: -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 391/480] s390/ap: Unmask SLCF bit in card and queue ap functions sysfs 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (389 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 390/480] nvmet: initialize discovery subsys after debugfs is initialized Greg Kroah-Hartman @ 2025-08-12 17:49 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 392/480] s390/mm: Set high_memory at the end of the identity mapping Greg Kroah-Hartman ` (100 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:49 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Harald Freudenberger, Holger Dengler, Heiko Carstens, Alexander Gordeev, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Harald Freudenberger <freude@linux.ibm.com> [ Upstream commit 123b7c7c2ba725daf3bfa5ce421d65b92cb5c075 ] The SLCF bit ("stateless command filtering") introduced with CEX8 cards was because of the function mask's default value suppressed when user space read the ap function for an AP card or queue. Unmask this bit so that user space applications like lszcrypt can evaluate and list this feature. Fixes: d4c53ae8e494 ("s390/ap: store TAPQ hwinfo in struct ap_card") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/s390/include/asm/ap.h | 2 +- drivers/s390/crypto/ap_bus.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/s390/include/asm/ap.h b/arch/s390/include/asm/ap.h index 395b02d6a133..352108727d7e 100644 --- a/arch/s390/include/asm/ap.h +++ b/arch/s390/include/asm/ap.h @@ -103,7 +103,7 @@ struct ap_tapq_hwinfo { unsigned int accel : 1; /* A */ unsigned int ep11 : 1; /* X */ unsigned int apxa : 1; /* APXA */ - unsigned int : 1; + unsigned int slcf : 1; /* Cmd filtering avail. */ unsigned int class : 8; unsigned int bs : 2; /* SE bind/assoc */ unsigned int : 14; diff --git a/drivers/s390/crypto/ap_bus.h b/drivers/s390/crypto/ap_bus.h index f4622ee4d894..6111913c858c 100644 --- a/drivers/s390/crypto/ap_bus.h +++ b/drivers/s390/crypto/ap_bus.h @@ -180,7 +180,7 @@ struct ap_card { atomic64_t total_request_count; /* # requests ever for this AP device.*/ }; -#define TAPQ_CARD_HWINFO_MASK 0xFEFF0000FFFF0F0FUL +#define TAPQ_CARD_HWINFO_MASK 0xFFFF0000FFFF0F0FUL #define ASSOC_IDX_INVALID 0x10000 #define to_ap_card(x) container_of((x), struct ap_card, ap_dev.device) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 392/480] s390/mm: Set high_memory at the end of the identity mapping 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (390 preceding siblings ...) 2025-08-12 17:49 ` [PATCH 6.15 391/480] s390/ap: Unmask SLCF bit in card and queue ap functions sysfs Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 393/480] netlink: specs: ethtool: fix module EEPROM input/output arguments Greg Kroah-Hartman ` (99 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Mikhail Zaslonko, Heiko Carstens, Gerald Schaefer, Alexander Gordeev, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Alexander Gordeev <agordeev@linux.ibm.com> [ Upstream commit 56f4cfab1c93b14da422cdcd23898eb008033696 ] The value of high_memory variable is set by set_high_memory() function to a value returned by memblock_end_of_DRAM(). The latter function returns by default the upper bound of the last online memory block, not the upper bound of the directly mapped memory region. As result, in case the end of memory happens to be offline, high_memory variable is set to a value that is short on the last offline memory blocks size: RANGE SIZE STATE REMOVABLE BLOCK 0x0000000000000000-0x000000ffffffffff 1T online yes 0-511 0x0000010000000000-0x0000011fffffffff 128G offline 512-575 Memory block size: 2G Total online memory: 1T Total offline memory: 128G crash> p/x vm_layout $1 = { kaslr_offset = 0x3453e918000, kaslr_offset_phys = 0xa534218000, identity_base = 0x0, identity_size = 0x12000000000 } crash> p/x high_memory $2 = 0x10000000000 In the past the value of high_memory was derived from max_low_pfn, which in turn was derived from the identity_size. Since identity_size accommodates the whole memory size - including tailing offline blocks, the offlined blocks did not impose any problem. But since commit e120d1bc12da ("arch, mm: set high_memory in free_area_init()") the value of high_memory is derived from the last memblock online region, and that is where the problem comes from. The value of high_memory is used by several drivers and by external tools (e.g. crash tool aborts while loading a dump). Similarily to ARM, use the override path provided by set_high_memory() function and set the value of high_memory at the end of the identity mapping early. That forces set_high_memory() to leave in high_memory the correct value, even when the end of available memory is offline. Fixes: e120d1bc12da ("arch, mm: set high_memory in free_area_init()") Tested-by: Mikhail Zaslonko <zaslonko@linux.ibm.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/s390/kernel/setup.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c index f244c5560e7f..5c9789804120 100644 --- a/arch/s390/kernel/setup.c +++ b/arch/s390/kernel/setup.c @@ -719,6 +719,11 @@ static void __init memblock_add_physmem_info(void) memblock_set_node(0, ULONG_MAX, &memblock.memory, 0); } +static void __init setup_high_memory(void) +{ + high_memory = __va(ident_map_size); +} + /* * Reserve memory used for lowcore. */ @@ -951,6 +956,7 @@ void __init setup_arch(char **cmdline_p) free_physmem_info(); setup_memory_end(); + setup_high_memory(); memblock_dump_all(); setup_memory(); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 393/480] netlink: specs: ethtool: fix module EEPROM input/output arguments 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (391 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 392/480] s390/mm: Set high_memory at the end of the identity mapping Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 394/480] block: Fix default IO priority if there is no IO context Greg Kroah-Hartman ` (98 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Duo Yi, Stanislav Fomichev, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jakub Kicinski <kuba@kernel.org> [ Upstream commit 01051012887329ea78eaca19b1d2eac4c9f601b5 ] Module (SFP) eeprom GET has a lot of input params, they are all mistakenly listed as output in the spec. Looks like kernel doesn't output them at all. Correct what are the inputs and what the outputs. Reported-by: Duo Yi <duo@meta.com> Fixes: a353318ebf24 ("tools: ynl: populate most of the ethtool spec") Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20250730172137.1322351-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- Documentation/netlink/specs/ethtool.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml index c650cd3dcb80..85e1d3b7512d 100644 --- a/Documentation/netlink/specs/ethtool.yaml +++ b/Documentation/netlink/specs/ethtool.yaml @@ -2077,9 +2077,6 @@ operations: do: &module-eeprom-get-op request: - attributes: - - header - reply: attributes: - header - offset @@ -2087,6 +2084,9 @@ operations: - page - bank - i2c-address + reply: + attributes: + - header - data dump: *module-eeprom-get-op - -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 394/480] block: Fix default IO priority if there is no IO context 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (392 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 393/480] netlink: specs: ethtool: fix module EEPROM input/output arguments Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 395/480] block: ensure discard_granularity is zero when discard is not supported Greg Kroah-Hartman ` (97 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Jens Axboe, Bart Van Assche, Guenter Roeck, Yu Kuai, Damien Le Moal, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Guenter Roeck <linux@roeck-us.net> [ Upstream commit e2ba58ccc9099514380c3300cbc0750b5055fc1c ] Upstream commit 53889bcaf536 ("block: make __get_task_ioprio() easier to read") changes the IO priority returned to the caller if no IO context is defined for the task. Prior to this commit, the returned IO priority was determined by task_nice_ioclass() and task_nice_ioprio(). Now it is always IOPRIO_DEFAULT, which translates to IOPRIO_CLASS_NONE with priority 0. However, task_nice_ioclass() returns IOPRIO_CLASS_IDLE, IOPRIO_CLASS_RT, or IOPRIO_CLASS_BE depending on the task scheduling policy, and task_nice_ioprio() returns a value determined by task_nice(). This causes regressions in test code checking the IO priority and class of IO operations on tasks with no IO context. Fix the problem by returning the IO priority calculated from task_nice_ioclass() and task_nice_ioprio() if no IO context is defined to match earlier behavior. Fixes: 53889bcaf536 ("block: make __get_task_ioprio() easier to read") Cc: Jens Axboe <axboe@kernel.dk> Cc: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Link: https://lore.kernel.org/r/20250731044953.1852690-1-linux@roeck-us.net Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org> --- include/linux/ioprio.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/linux/ioprio.h b/include/linux/ioprio.h index b25377b6ea98..5210e8371238 100644 --- a/include/linux/ioprio.h +++ b/include/linux/ioprio.h @@ -60,7 +60,8 @@ static inline int __get_task_ioprio(struct task_struct *p) int prio; if (!ioc) - return IOPRIO_DEFAULT; + return IOPRIO_PRIO_VALUE(task_nice_ioclass(p), + task_nice_ioprio(p)); if (p != current) lockdep_assert_held(&p->alloc_lock); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 395/480] block: ensure discard_granularity is zero when discard is not supported 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (393 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 394/480] block: Fix default IO priority if there is no IO context Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 396/480] ASoC: tas2781: Fix the wrong step for TLV on tas2781 Greg Kroah-Hartman ` (96 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Christoph Hellwig, Martin K. Petersen, Jens Axboe, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Christoph Hellwig <hch@lst.de> [ Upstream commit fad6551fcf537375702b9af012508156a16a1ff7 ] Documentation/ABI/stable/sysfs-block states: What: /sys/block/<disk>/queue/discard_granularity [...] A discard_granularity of 0 means that the device does not support discard functionality. but this got broken when sorting out the block limits updates. Fix this by setting the discard_granularity limit to zero when the combined max_discard_sectors is zero. Fixes: 3c407dc723bb ("block: default the discard granularity to sector size") Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Link: https://lore.kernel.org/r/20250731152228.873923-1-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org> --- block/blk-settings.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/block/blk-settings.c b/block/blk-settings.c index d8c79e5112b4..47a31e1c0909 100644 --- a/block/blk-settings.c +++ b/block/blk-settings.c @@ -347,12 +347,19 @@ int blk_validate_limits(struct queue_limits *lim) lim->max_discard_sectors = min(lim->max_hw_discard_sectors, lim->max_user_discard_sectors); + /* + * When discard is not supported, discard_granularity should be reported + * as 0 to userspace. + */ + if (lim->max_discard_sectors) + lim->discard_granularity = + max(lim->discard_granularity, lim->physical_block_size); + else + lim->discard_granularity = 0; + if (!lim->max_discard_segments) lim->max_discard_segments = 1; - if (lim->discard_granularity < lim->physical_block_size) - lim->discard_granularity = lim->physical_block_size; - /* * By default there is no limit on the segment boundary alignment, * but if there is one it can't be smaller than the page size as -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 396/480] ASoC: tas2781: Fix the wrong step for TLV on tas2781 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (394 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 395/480] block: ensure discard_granularity is zero when discard is not supported Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 397/480] spi: cs42l43: Property entry should be a null-terminated array Greg Kroah-Hartman ` (95 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Baojun Xu, Mark Brown, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Baojun Xu <baojun.xu@ti.com> [ Upstream commit 9843cf7b6fd6f938c16fde51e86dd0e3ddbefb12 ] The step for TLV on tas2781, should be 50 (-0.5dB). Fixes: 678f38eba1f2 ("ASoC: tas2781: Add Header file for tas2781 driver") Signed-off-by: Baojun Xu <baojun.xu@ti.com> Link: https://patch.msgid.link/20250801021618.64627-1-baojun.xu@ti.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- include/sound/tas2781-tlv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/sound/tas2781-tlv.h b/include/sound/tas2781-tlv.h index d87263e43fdb..ef9b9f19d212 100644 --- a/include/sound/tas2781-tlv.h +++ b/include/sound/tas2781-tlv.h @@ -15,7 +15,7 @@ #ifndef __TAS2781_TLV_H__ #define __TAS2781_TLV_H__ -static const __maybe_unused DECLARE_TLV_DB_SCALE(dvc_tlv, -10000, 100, 0); +static const __maybe_unused DECLARE_TLV_DB_SCALE(dvc_tlv, -10000, 50, 0); static const __maybe_unused DECLARE_TLV_DB_SCALE(amp_vol_tlv, 1100, 50, 0); #endif -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 397/480] spi: cs42l43: Property entry should be a null-terminated array 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (395 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 396/480] ASoC: tas2781: Fix the wrong step for TLV on tas2781 Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 398/480] net/mlx5: Correctly set gso_segs when LRO is used Greg Kroah-Hartman ` (94 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Simon Trimmer, Mark Brown, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Simon Trimmer <simont@opensource.cirrus.com> [ Upstream commit ffcfd071eec7973e58c4ffff7da4cb0e9ca7b667 ] The software node does not specify a count of property entries, so the array must be null-terminated. When unterminated, this can lead to a fault in the downstream cs35l56 amplifier driver, because the node parse walks off the end of the array into unknown memory. Fixes: 0ca645ab5b15 ("spi: cs42l43: Add speaker id support to the bridge configuration") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220371 Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com> Link: https://patch.msgid.link/20250731160109.1547131-1-simont@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/spi/spi-cs42l43.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-cs42l43.c b/drivers/spi/spi-cs42l43.c index ceefc253c549..004801c2c925 100644 --- a/drivers/spi/spi-cs42l43.c +++ b/drivers/spi/spi-cs42l43.c @@ -293,7 +293,7 @@ static struct spi_board_info *cs42l43_create_bridge_amp(struct cs42l43_spi *priv struct spi_board_info *info; if (spkid >= 0) { - props = devm_kmalloc(priv->dev, sizeof(*props), GFP_KERNEL); + props = devm_kcalloc(priv->dev, 2, sizeof(*props), GFP_KERNEL); if (!props) return NULL; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 398/480] net/mlx5: Correctly set gso_segs when LRO is used 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (396 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 397/480] spi: cs42l43: Property entry should be a null-terminated array Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 399/480] ipv6: reject malicious packets in ipv6_gso_segment() Greg Kroah-Hartman ` (93 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Gal Pressman, Christoph Paasch, Eric Dumazet, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Christoph Paasch <cpaasch@openai.com> [ Upstream commit 77bf1c55b2acc7fa3734b14f4561e3d75aea1a90 ] When gso_segs is left at 0, a number of assumptions will end up being incorrect throughout the stack. For example, in the GRO-path, we set NAPI_GRO_CB()->count to gso_segs. So, if a non-LRO'ed packet followed by an LRO'ed packet is being processed in GRO, the first one will have NAPI_GRO_CB()->count set to 1 and the next one to 0 (in dev_gro_receive()). Since commit 531d0d32de3e ("net/mlx5: Correctly set gso_size when LRO is used") these packets will get merged (as their gso_size now matches). So, we end up in gro_complete() with NAPI_GRO_CB()->count == 1 and thus don't call inet_gro_complete(). Meaning, checksum-validation in tcp_checksum_complete() will fail with a "hw csum failure". Even before the above mentioned commit, incorrect gso_segs means that other things like TCP's accounting of incoming packets (tp->segs_in, data_segs_in, rcv_ooopack) will be incorrect. Which means that if one does bytes_received/data_segs_in, the result will be bigger than the MTU. Fix this by initializing gso_segs correctly when LRO is used. Fixes: e586b3b0baee ("net/mlx5: Ethernet Datapath files") Reported-by: Gal Pressman <gal@nvidia.com> Closes: https://lore.kernel.org/netdev/6583783f-f0fb-4fb1-a415-feec8155bc69@nvidia.com/ Signed-off-by: Christoph Paasch <cpaasch@openai.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20250729-mlx5_gso_segs-v1-1-b48c480c1c12@openai.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c index e37cf4f754c4..b6d733138de3 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c @@ -1567,6 +1567,7 @@ static inline void mlx5e_build_rx_skb(struct mlx5_cqe64 *cqe, unsigned int hdrlen = mlx5e_lro_update_hdr(skb, cqe, cqe_bcnt); skb_shinfo(skb)->gso_size = DIV_ROUND_UP(cqe_bcnt - hdrlen, lro_num_seg); + skb_shinfo(skb)->gso_segs = lro_num_seg; /* Subtract one since we already counted this as one * "regular" packet in mlx5e_complete_rx_cqe() */ -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 399/480] ipv6: reject malicious packets in ipv6_gso_segment() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (397 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 398/480] net/mlx5: Correctly set gso_segs when LRO is used Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 400/480] net: mdio: mdio-bcm-unimac: Correct rate fallback logic Greg Kroah-Hartman ` (92 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, syzbot+af43e647fd835acc02df, Eric Dumazet, Dawid Osuchowski, Willem de Bruijn, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Eric Dumazet <edumazet@google.com> [ Upstream commit d45cf1e7d7180256e17c9ce88e32e8061a7887fe ] syzbot was able to craft a packet with very long IPv6 extension headers leading to an overflow of skb->transport_header. This 16bit field has a limited range. Add skb_reset_transport_header_careful() helper and use it from ipv6_gso_segment() WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline] WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Modules linked in: CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline] RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Call Trace: <TASK> skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110 skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 __skb_gso_segment+0x342/0x510 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950 validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000 sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329 __dev_xmit_skb net/core/dev.c:4102 [inline] __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679 Fixes: d1da932ed4ec ("ipv6: Separate ipv6 offload support") Reported-by: syzbot+af43e647fd835acc02df@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/688a1a05.050a0220.5d226.0008.GAE@google.com/T/#u Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20250730131738.3385939-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- include/linux/skbuff.h | 23 +++++++++++++++++++++++ net/ipv6/ip6_offload.c | 4 +++- 2 files changed, 26 insertions(+), 1 deletion(-) diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h index b974a277975a..fad2fc972d23 100644 --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h @@ -3032,6 +3032,29 @@ static inline void skb_reset_transport_header(struct sk_buff *skb) skb->transport_header = offset; } +/** + * skb_reset_transport_header_careful - conditionally reset transport header + * @skb: buffer to alter + * + * Hardened version of skb_reset_transport_header(). + * + * Returns: true if the operation was a success. + */ +static inline bool __must_check +skb_reset_transport_header_careful(struct sk_buff *skb) +{ + long offset = skb->data - skb->head; + + if (unlikely(offset != (typeof(skb->transport_header))offset)) + return false; + + if (unlikely(offset == (typeof(skb->transport_header))~0U)) + return false; + + skb->transport_header = offset; + return true; +} + static inline void skb_set_transport_header(struct sk_buff *skb, const int offset) { diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c index 9822163428b0..fce91183797a 100644 --- a/net/ipv6/ip6_offload.c +++ b/net/ipv6/ip6_offload.c @@ -148,7 +148,9 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff *skb, ops = rcu_dereference(inet6_offloads[proto]); if (likely(ops && ops->callbacks.gso_segment)) { - skb_reset_transport_header(skb); + if (!skb_reset_transport_header_careful(skb)) + goto out; + segs = ops->callbacks.gso_segment(skb, features); if (!segs) skb->network_header = skb_mac_header(skb) + nhoff - skb->head; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 400/480] net: mdio: mdio-bcm-unimac: Correct rate fallback logic 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (398 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 399/480] ipv6: reject malicious packets in ipv6_gso_segment() Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 401/480] net: drop UFO packets in udp_rcv_segment() Greg Kroah-Hartman ` (91 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Florian Fainelli, Andrew Lunn, Simon Horman, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Florian Fainelli <florian.fainelli@broadcom.com> [ Upstream commit a81649a4efd382497bf3d34a623360263adc6993 ] When the parent clock is a gated clock which has multiple parents, the clock provider (clk-scmi typically) might return a rate of 0 since there is not one of those particular parent clocks that should be chosen for returning a rate. Prior to ee975351cf0c ("net: mdio: mdio-bcm-unimac: Manage clock around I/O accesses"), we would not always be passing a clock reference depending upon how mdio-bcm-unimac was instantiated. In that case, we would take the fallback path where the rate is hard coded to 250MHz. Make sure that we still fallback to using a fixed rate for the divider calculation, otherwise we simply ignore the desired MDIO bus clock frequency which can prevent us from interfacing with Ethernet PHYs properly. Fixes: ee975351cf0c ("net: mdio: mdio-bcm-unimac: Manage clock around I/O accesses") Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250730202533.3463529-1-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/mdio/mdio-bcm-unimac.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/net/mdio/mdio-bcm-unimac.c b/drivers/net/mdio/mdio-bcm-unimac.c index 074d96328f41..60565e7c88bd 100644 --- a/drivers/net/mdio/mdio-bcm-unimac.c +++ b/drivers/net/mdio/mdio-bcm-unimac.c @@ -209,10 +209,9 @@ static int unimac_mdio_clk_set(struct unimac_mdio_priv *priv) if (ret) return ret; - if (!priv->clk) + rate = clk_get_rate(priv->clk); + if (!rate) rate = 250000000; - else - rate = clk_get_rate(priv->clk); div = (rate / (2 * priv->clk_freq)) - 1; if (div & ~MDIO_CLK_DIV_MASK) { -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 401/480] net: drop UFO packets in udp_rcv_segment() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (399 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 400/480] net: mdio: mdio-bcm-unimac: Correct rate fallback logic Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 402/480] net/sched: taprio: enforce minimum value for picos_per_byte Greg Kroah-Hartman ` (90 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Willem de Bruijn, Wang Liang, Willem de Bruijn, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Wang Liang <wangliang74@huawei.com> [ Upstream commit d46e51f1c78b9ab9323610feb14238d06d46d519 ] When sending a packet with virtio_net_hdr to tun device, if the gso_type in virtio_net_hdr is SKB_GSO_UDP and the gso_size is less than udphdr size, below crash may happen. ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:4572! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 62 Comm: mytest Not tainted 6.16.0-rc7 #203 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:skb_pull_rcsum+0x8e/0xa0 Code: 00 00 5b c3 cc cc cc cc 8b 93 88 00 00 00 f7 da e8 37 44 38 00 f7 d8 89 83 88 00 00 00 48 8b 83 c8 00 00 00 5b c3 cc cc cc cc <0f> 0b 0f 0b 66 66 2e 0f 1f 84 00 000 RSP: 0018:ffffc900001fba38 EFLAGS: 00000297 RAX: 0000000000000004 RBX: ffff8880040c1000 RCX: ffffc900001fb948 RDX: ffff888003e6d700 RSI: 0000000000000008 RDI: ffff88800411a062 RBP: ffff8880040c1000 R08: 0000000000000000 R09: 0000000000000001 R10: ffff888003606c00 R11: 0000000000000001 R12: 0000000000000000 R13: ffff888004060900 R14: ffff888004050000 R15: ffff888004060900 FS: 000000002406d3c0(0000) GS:ffff888084a19000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000040 CR3: 0000000004007000 CR4: 00000000000006f0 Call Trace: <TASK> udp_queue_rcv_one_skb+0x176/0x4b0 net/ipv4/udp.c:2445 udp_queue_rcv_skb+0x155/0x1f0 net/ipv4/udp.c:2475 udp_unicast_rcv_skb+0x71/0x90 net/ipv4/udp.c:2626 __udp4_lib_rcv+0x433/0xb00 net/ipv4/udp.c:2690 ip_protocol_deliver_rcu+0xa6/0x160 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x72/0x90 net/ipv4/ip_input.c:233 ip_sublist_rcv_finish+0x5f/0x70 net/ipv4/ip_input.c:579 ip_sublist_rcv+0x122/0x1b0 net/ipv4/ip_input.c:636 ip_list_rcv+0xf7/0x130 net/ipv4/ip_input.c:670 __netif_receive_skb_list_core+0x21d/0x240 net/core/dev.c:6067 netif_receive_skb_list_internal+0x186/0x2b0 net/core/dev.c:6210 napi_complete_done+0x78/0x180 net/core/dev.c:6580 tun_get_user+0xa63/0x1120 drivers/net/tun.c:1909 tun_chr_write_iter+0x65/0xb0 drivers/net/tun.c:1984 vfs_write+0x300/0x420 fs/read_write.c:593 ksys_write+0x60/0xd0 fs/read_write.c:686 do_syscall_64+0x50/0x1c0 arch/x86/entry/syscall_64.c:63 </TASK> To trigger gso segment in udp_queue_rcv_skb(), we should also set option UDP_ENCAP_ESPINUDP to enable udp_sk(sk)->encap_rcv. When the encap_rcv hook return 1 in udp_queue_rcv_one_skb(), udp_csum_pull_header() will try to pull udphdr, but the skb size has been segmented to gso size, which leads to this crash. Previous commit cf329aa42b66 ("udp: cope with UDP GRO packet misdirection") introduces segmentation in UDP receive path only for GRO, which was never intended to be used for UFO, so drop UFO packets in udp_rcv_segment(). Link: https://lore.kernel.org/netdev/20250724083005.3918375-1-wangliang74@huawei.com/ Link: https://lore.kernel.org/netdev/20250729123907.3318425-1-wangliang74@huawei.com/ Fixes: cf329aa42b66 ("udp: cope with UDP GRO packet misdirection") Suggested-by: Willem de Bruijn <willemdebruijn.kernel@gmail.com> Signed-off-by: Wang Liang <wangliang74@huawei.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20250730101458.3470788-1-wangliang74@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- include/net/udp.h | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/include/net/udp.h b/include/net/udp.h index 6e89520e100d..b59462c5b97a 100644 --- a/include/net/udp.h +++ b/include/net/udp.h @@ -586,6 +586,16 @@ static inline struct sk_buff *udp_rcv_segment(struct sock *sk, { netdev_features_t features = NETIF_F_SG; struct sk_buff *segs; + int drop_count; + + /* + * Segmentation in UDP receive path is only for UDP GRO, drop udp + * fragmentation offload (UFO) packets. + */ + if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP) { + drop_count = 1; + goto drop; + } /* Avoid csum recalculation by skb_segment unless userspace explicitly * asks for the final checksum values @@ -609,16 +619,18 @@ static inline struct sk_buff *udp_rcv_segment(struct sock *sk, */ segs = __skb_gso_segment(skb, features, false); if (IS_ERR_OR_NULL(segs)) { - int segs_nr = skb_shinfo(skb)->gso_segs; - - atomic_add(segs_nr, &sk->sk_drops); - SNMP_ADD_STATS(__UDPX_MIB(sk, ipv4), UDP_MIB_INERRORS, segs_nr); - kfree_skb(skb); - return NULL; + drop_count = skb_shinfo(skb)->gso_segs; + goto drop; } consume_skb(skb); return segs; + +drop: + atomic_add(drop_count, &sk->sk_drops); + SNMP_ADD_STATS(__UDPX_MIB(sk, ipv4), UDP_MIB_INERRORS, drop_count); + kfree_skb(skb); + return NULL; } static inline void udp_post_segment_fix_csum(struct sk_buff *skb) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 402/480] net/sched: taprio: enforce minimum value for picos_per_byte 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (400 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 401/480] net: drop UFO packets in udp_rcv_segment() Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 403/480] sunrpc: fix client side handling of tls alerts Greg Kroah-Hartman ` (89 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, syzbot+398e1ee4ca2cac05fddb, Takamitsu Iwai, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Takamitsu Iwai <takamitz@amazon.co.jp> [ Upstream commit ae8508b25def57982493c48694ef135973bfabe0 ] Syzbot reported a WARNING in taprio_get_start_time(). When link speed is 470,589 or greater, q->picos_per_byte becomes too small, causing length_to_duration(q, ETH_ZLEN) to return zero. This zero value leads to validation failures in fill_sched_entry() and parse_taprio_schedule(), allowing arbitrary values to be assigned to entry->interval and cycle_time. As a result, sched->cycle can become zero. Since SPEED_800000 is the largest defined speed in include/uapi/linux/ethtool.h, this issue can occur in realistic scenarios. To ensure length_to_duration() returns a non-zero value for minimum-sized Ethernet frames (ETH_ZLEN = 60), picos_per_byte must be at least 17 (60 * 17 > PSEC_PER_NSEC which is 1000). This patch enforces a minimum value of 17 for picos_per_byte when the calculated value would be lower, and adds a warning message to inform users that scheduling accuracy may be affected at very high link speeds. Fixes: fb66df20a720 ("net/sched: taprio: extend minimum interval restriction to entire cycle too") Reported-by: syzbot+398e1ee4ca2cac05fddb@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=398e1ee4ca2cac05fddb Signed-off-by: Takamitsu Iwai <takamitz@amazon.co.jp> Link: https://patch.msgid.link/20250728173149.45585-1-takamitz@amazon.co.jp Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/sched/sch_taprio.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c index 2b14c81a87e5..85d84f39e220 100644 --- a/net/sched/sch_taprio.c +++ b/net/sched/sch_taprio.c @@ -43,6 +43,11 @@ static struct static_key_false taprio_have_working_mqprio; #define TAPRIO_SUPPORTED_FLAGS \ (TCA_TAPRIO_ATTR_FLAG_TXTIME_ASSIST | TCA_TAPRIO_ATTR_FLAG_FULL_OFFLOAD) #define TAPRIO_FLAGS_INVALID U32_MAX +/* Minimum value for picos_per_byte to ensure non-zero duration + * for minimum-sized Ethernet frames (ETH_ZLEN = 60). + * 60 * 17 > PSEC_PER_NSEC (1000) + */ +#define TAPRIO_PICOS_PER_BYTE_MIN 17 struct sched_entry { /* Durations between this GCL entry and the GCL entry where the @@ -1284,7 +1289,8 @@ static void taprio_start_sched(struct Qdisc *sch, } static void taprio_set_picos_per_byte(struct net_device *dev, - struct taprio_sched *q) + struct taprio_sched *q, + struct netlink_ext_ack *extack) { struct ethtool_link_ksettings ecmd; int speed = SPEED_10; @@ -1300,6 +1306,15 @@ static void taprio_set_picos_per_byte(struct net_device *dev, skip: picos_per_byte = (USEC_PER_SEC * 8) / speed; + if (picos_per_byte < TAPRIO_PICOS_PER_BYTE_MIN) { + if (!extack) + pr_warn("Link speed %d is too high. Schedule may be inaccurate.\n", + speed); + NL_SET_ERR_MSG_FMT_MOD(extack, + "Link speed %d is too high. Schedule may be inaccurate.", + speed); + picos_per_byte = TAPRIO_PICOS_PER_BYTE_MIN; + } atomic64_set(&q->picos_per_byte, picos_per_byte); netdev_dbg(dev, "taprio: set %s's picos_per_byte to: %lld, linkspeed: %d\n", @@ -1324,7 +1339,7 @@ static int taprio_dev_notifier(struct notifier_block *nb, unsigned long event, if (dev != qdisc_dev(q->root)) continue; - taprio_set_picos_per_byte(dev, q); + taprio_set_picos_per_byte(dev, q, NULL); stab = rtnl_dereference(q->root->stab); @@ -1848,7 +1863,7 @@ static int taprio_change(struct Qdisc *sch, struct nlattr *opt, q->flags = taprio_flags; /* Needed for length_to_duration() during netlink attribute parsing */ - taprio_set_picos_per_byte(dev, q); + taprio_set_picos_per_byte(dev, q, extack); err = taprio_parse_mqprio_opt(dev, mqprio, extack, q->flags); if (err < 0) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 403/480] sunrpc: fix client side handling of tls alerts 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (401 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 402/480] net/sched: taprio: enforce minimum value for picos_per_byte Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 404/480] drm/xe/pf: Disable PF restart worker on device removal Greg Kroah-Hartman ` (88 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Trond Myklebust, Scott Mayhew, Olga Kornievskaia, Trond Myklebust, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Olga Kornievskaia <okorniev@redhat.com> [ Upstream commit cc5d59081fa26506d02de2127ab822f40d88bc5a ] A security exploit was discovered in NFS over TLS in tls_alert_recv due to its assumption that there is valid data in the msghdr's iterator's kvec. Instead, this patch proposes the rework how control messages are setup and used by sock_recvmsg(). If no control message structure is setup, kTLS layer will read and process TLS data record types. As soon as it encounters a TLS control message, it would return an error. At that point, NFS can setup a kvec backed control buffer and read in the control message such as a TLS alert. Scott found that a msg iterator can advance the kvec pointer as a part of the copy process thus we need to revert the iterator before calling into the tls_alert_recv. Fixes: dea034b963c8 ("SUNRPC: Capture CMSG metadata on client-side receive") Suggested-by: Trond Myklebust <trondmy@hammerspace.com> Suggested-by: Scott Mayhew <smayhew@redhat.com> Signed-off-by: Olga Kornievskaia <okorniev@redhat.com> Link: https://lore.kernel.org/r/20250731180058.4669-3-okorniev@redhat.com Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/sunrpc/xprtsock.c | 40 ++++++++++++++++++++++++++++++---------- 1 file changed, 30 insertions(+), 10 deletions(-) diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c index 4b10ecf4c265..9b2328b727b6 100644 --- a/net/sunrpc/xprtsock.c +++ b/net/sunrpc/xprtsock.c @@ -358,7 +358,7 @@ xs_alloc_sparse_pages(struct xdr_buf *buf, size_t want, gfp_t gfp) static int xs_sock_process_cmsg(struct socket *sock, struct msghdr *msg, - struct cmsghdr *cmsg, int ret) + unsigned int *msg_flags, struct cmsghdr *cmsg, int ret) { u8 content_type = tls_get_record_type(sock->sk, cmsg); u8 level, description; @@ -371,7 +371,7 @@ xs_sock_process_cmsg(struct socket *sock, struct msghdr *msg, * record, even though there might be more frames * waiting to be decrypted. */ - msg->msg_flags &= ~MSG_EOR; + *msg_flags &= ~MSG_EOR; break; case TLS_RECORD_TYPE_ALERT: tls_alert_recv(sock->sk, msg, &level, &description); @@ -386,19 +386,33 @@ xs_sock_process_cmsg(struct socket *sock, struct msghdr *msg, } static int -xs_sock_recv_cmsg(struct socket *sock, struct msghdr *msg, int flags) +xs_sock_recv_cmsg(struct socket *sock, unsigned int *msg_flags, int flags) { union { struct cmsghdr cmsg; u8 buf[CMSG_SPACE(sizeof(u8))]; } u; + u8 alert[2]; + struct kvec alert_kvec = { + .iov_base = alert, + .iov_len = sizeof(alert), + }; + struct msghdr msg = { + .msg_flags = *msg_flags, + .msg_control = &u, + .msg_controllen = sizeof(u), + }; int ret; - msg->msg_control = &u; - msg->msg_controllen = sizeof(u); - ret = sock_recvmsg(sock, msg, flags); - if (msg->msg_controllen != sizeof(u)) - ret = xs_sock_process_cmsg(sock, msg, &u.cmsg, ret); + iov_iter_kvec(&msg.msg_iter, ITER_DEST, &alert_kvec, 1, + alert_kvec.iov_len); + ret = sock_recvmsg(sock, &msg, flags); + if (ret > 0 && + tls_get_record_type(sock->sk, &u.cmsg) == TLS_RECORD_TYPE_ALERT) { + iov_iter_revert(&msg.msg_iter, ret); + ret = xs_sock_process_cmsg(sock, &msg, msg_flags, &u.cmsg, + -EAGAIN); + } return ret; } @@ -408,7 +422,13 @@ xs_sock_recvmsg(struct socket *sock, struct msghdr *msg, int flags, size_t seek) ssize_t ret; if (seek != 0) iov_iter_advance(&msg->msg_iter, seek); - ret = xs_sock_recv_cmsg(sock, msg, flags); + ret = sock_recvmsg(sock, msg, flags); + /* Handle TLS inband control message lazily */ + if (msg->msg_flags & MSG_CTRUNC) { + msg->msg_flags &= ~(MSG_CTRUNC | MSG_EOR); + if (ret == 0 || ret == -EIO) + ret = xs_sock_recv_cmsg(sock, &msg->msg_flags, flags); + } return ret > 0 ? ret + seek : ret; } @@ -434,7 +454,7 @@ xs_read_discard(struct socket *sock, struct msghdr *msg, int flags, size_t count) { iov_iter_discard(&msg->msg_iter, ITER_DEST, count); - return xs_sock_recv_cmsg(sock, msg, flags); + return xs_sock_recvmsg(sock, msg, flags, 0); } #if ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 404/480] drm/xe/pf: Disable PF restart worker on device removal 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (402 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 403/480] sunrpc: fix client side handling of tls alerts Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 405/480] x86/irq: Plug vector setup race Greg Kroah-Hartman ` (87 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Michal Wajdeczko, Piotr Piórkowski, Jonathan Cavitt, Rodrigo Vivi, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Michal Wajdeczko <michal.wajdeczko@intel.com> [ Upstream commit c286ce6b01f633806b4db3e4ec8e0162928299cd ] We can't let restart worker run once device is removed, since other data that it might want to access could be already released. Explicitly disable worker as part of device cleanup action. Fixes: a4d1c5d0b99b ("drm/xe/pf: Move VFs reprovisioning to worker") Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://lore.kernel.org/r/20250801142822.180530-2-michal.wajdeczko@intel.com (cherry picked from commit a424353937c24554bb242a6582ed8f018b4a411c) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/gpu/drm/xe/xe_gt_sriov_pf.c | 32 ++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/xe_gt_sriov_pf.c b/drivers/gpu/drm/xe/xe_gt_sriov_pf.c index 35489fa81825..2ea81d81c0ae 100644 --- a/drivers/gpu/drm/xe/xe_gt_sriov_pf.c +++ b/drivers/gpu/drm/xe/xe_gt_sriov_pf.c @@ -47,9 +47,16 @@ static int pf_alloc_metadata(struct xe_gt *gt) static void pf_init_workers(struct xe_gt *gt) { + xe_gt_assert(gt, IS_SRIOV_PF(gt_to_xe(gt))); INIT_WORK(>->sriov.pf.workers.restart, pf_worker_restart_func); } +static void pf_fini_workers(struct xe_gt *gt) +{ + xe_gt_assert(gt, IS_SRIOV_PF(gt_to_xe(gt))); + disable_work_sync(>->sriov.pf.workers.restart); +} + /** * xe_gt_sriov_pf_init_early - Prepare SR-IOV PF data structures on PF. * @gt: the &xe_gt to initialize @@ -79,6 +86,21 @@ int xe_gt_sriov_pf_init_early(struct xe_gt *gt) return 0; } +static void pf_fini_action(void *arg) +{ + struct xe_gt *gt = arg; + + pf_fini_workers(gt); +} + +static int pf_init_late(struct xe_gt *gt) +{ + struct xe_device *xe = gt_to_xe(gt); + + xe_gt_assert(gt, IS_SRIOV_PF(xe)); + return devm_add_action_or_reset(xe->drm.dev, pf_fini_action, gt); +} + /** * xe_gt_sriov_pf_init - Prepare SR-IOV PF data structures on PF. * @gt: the &xe_gt to initialize @@ -95,7 +117,15 @@ int xe_gt_sriov_pf_init(struct xe_gt *gt) if (err) return err; - return xe_gt_sriov_pf_migration_init(gt); + err = xe_gt_sriov_pf_migration_init(gt); + if (err) + return err; + + err = pf_init_late(gt); + if (err) + return err; + + return 0; } static bool pf_needs_enable_ggtt_guest_update(struct xe_device *xe) -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 405/480] x86/irq: Plug vector setup race 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (403 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 404/480] drm/xe/pf: Disable PF restart worker on device removal Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 406/480] eth: fbnic: unlink NAPIs from queues on error to open Greg Kroah-Hartman ` (86 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Hogan Wang, Thomas Gleixner, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Gleixner <tglx@linutronix.de> [ Upstream commit ce0b5eedcb753697d43f61dd2e27d68eb5d3150f ] Hogan reported a vector setup race, which overwrites the interrupt descriptor in the per CPU vector array resulting in a disfunctional device. CPU0 CPU1 interrupt is raised in APIC IRR but not handled free_irq() per_cpu(vector_irq, CPU1)[vector] = VECTOR_SHUTDOWN; request_irq() common_interrupt() d = this_cpu_read(vector_irq[vector]); per_cpu(vector_irq, CPU1)[vector] = desc; if (d == VECTOR_SHUTDOWN) this_cpu_write(vector_irq[vector], VECTOR_UNUSED); free_irq() cannot observe the pending vector in the CPU1 APIC as there is no way to query the remote CPUs APIC IRR. This requires that request_irq() uses the same vector/CPU as the one which was freed, but this also can be triggered by a spurious interrupt. Interestingly enough this problem managed to be hidden for more than a decade. Prevent this by reevaluating vector_irq under the vector lock, which is held by the interrupt activation code when vector_irq is updated. To avoid ifdeffery or IS_ENABLED() nonsense, move the [un]lock_vector_lock() declarations out under the CONFIG_IRQ_DOMAIN_HIERARCHY guard as it's only provided when CONFIG_X86_LOCAL_APIC=y. The current CONFIG_IRQ_DOMAIN_HIERARCHY guard is selected by CONFIG_X86_LOCAL_APIC, but can also be selected by other parts of the Kconfig system, which makes 32-bit UP builds with CONFIG_X86_LOCAL_APIC=n fail. Can we just get rid of this !APIC nonsense once and forever? Fixes: 9345005f4eed ("x86/irq: Fix do_IRQ() interrupt warning for cpu hotplug retriggered irqs") Reported-by: Hogan Wang <hogan.wang@huawei.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Hogan Wang <hogan.wang@huawei.com> Link: https://lore.kernel.org/all/draft-87ikjhrhhh.ffs@tglx Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/x86/include/asm/hw_irq.h | 12 ++++--- arch/x86/kernel/irq.c | 63 ++++++++++++++++++++++++++--------- 2 files changed, 55 insertions(+), 20 deletions(-) diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h index 162ebd73a698..cbe19e669080 100644 --- a/arch/x86/include/asm/hw_irq.h +++ b/arch/x86/include/asm/hw_irq.h @@ -92,8 +92,6 @@ struct irq_cfg { extern struct irq_cfg *irq_cfg(unsigned int irq); extern struct irq_cfg *irqd_cfg(struct irq_data *irq_data); -extern void lock_vector_lock(void); -extern void unlock_vector_lock(void); #ifdef CONFIG_SMP extern void vector_schedule_cleanup(struct irq_cfg *); extern void irq_complete_move(struct irq_cfg *cfg); @@ -101,12 +99,16 @@ extern void irq_complete_move(struct irq_cfg *cfg); static inline void vector_schedule_cleanup(struct irq_cfg *c) { } static inline void irq_complete_move(struct irq_cfg *c) { } #endif - extern void apic_ack_edge(struct irq_data *data); -#else /* CONFIG_IRQ_DOMAIN_HIERARCHY */ +#endif /* CONFIG_IRQ_DOMAIN_HIERARCHY */ + +#ifdef CONFIG_X86_LOCAL_APIC +extern void lock_vector_lock(void); +extern void unlock_vector_lock(void); +#else static inline void lock_vector_lock(void) {} static inline void unlock_vector_lock(void) {} -#endif /* CONFIG_IRQ_DOMAIN_HIERARCHY */ +#endif /* Statistics */ extern atomic_t irq_err_count; diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c index 6cd5d2d6c58a..3bdf9f9003c7 100644 --- a/arch/x86/kernel/irq.c +++ b/arch/x86/kernel/irq.c @@ -256,26 +256,59 @@ static __always_inline void handle_irq(struct irq_desc *desc, __handle_irq(desc, regs); } -static __always_inline int call_irq_handler(int vector, struct pt_regs *regs) +static struct irq_desc *reevaluate_vector(int vector) { - struct irq_desc *desc; - int ret = 0; + struct irq_desc *desc = __this_cpu_read(vector_irq[vector]); + + if (!IS_ERR_OR_NULL(desc)) + return desc; + + if (desc == VECTOR_UNUSED) + pr_emerg_ratelimited("No irq handler for %d.%u\n", smp_processor_id(), vector); + else + __this_cpu_write(vector_irq[vector], VECTOR_UNUSED); + return NULL; +} + +static __always_inline bool call_irq_handler(int vector, struct pt_regs *regs) +{ + struct irq_desc *desc = __this_cpu_read(vector_irq[vector]); - desc = __this_cpu_read(vector_irq[vector]); if (likely(!IS_ERR_OR_NULL(desc))) { handle_irq(desc, regs); - } else { - ret = -EINVAL; - if (desc == VECTOR_UNUSED) { - pr_emerg_ratelimited("%s: %d.%u No irq handler for vector\n", - __func__, smp_processor_id(), - vector); - } else { - __this_cpu_write(vector_irq[vector], VECTOR_UNUSED); - } + return true; } - return ret; + /* + * Reevaluate with vector_lock held to prevent a race against + * request_irq() setting up the vector: + * + * CPU0 CPU1 + * interrupt is raised in APIC IRR + * but not handled + * free_irq() + * per_cpu(vector_irq, CPU1)[vector] = VECTOR_SHUTDOWN; + * + * request_irq() common_interrupt() + * d = this_cpu_read(vector_irq[vector]); + * + * per_cpu(vector_irq, CPU1)[vector] = desc; + * + * if (d == VECTOR_SHUTDOWN) + * this_cpu_write(vector_irq[vector], VECTOR_UNUSED); + * + * This requires that the same vector on the same target CPU is + * handed out or that a spurious interrupt hits that CPU/vector. + */ + lock_vector_lock(); + desc = reevaluate_vector(vector); + unlock_vector_lock(); + + if (!desc) + return false; + + handle_irq(desc, regs); + return true; } /* @@ -289,7 +322,7 @@ DEFINE_IDTENTRY_IRQ(common_interrupt) /* entry code tells RCU that we're not quiescent. Check it. */ RCU_LOCKDEP_WARN(!rcu_is_watching(), "IRQ failed to wake up RCU"); - if (unlikely(call_irq_handler(vector, regs))) + if (unlikely(!call_irq_handler(vector, regs))) apic_eoi(); set_irq_regs(old_regs); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 406/480] eth: fbnic: unlink NAPIs from queues on error to open 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (404 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 405/480] x86/irq: Plug vector setup race Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 407/480] net: airoha: npu: Add missing MODULE_FIRMWARE macros Greg Kroah-Hartman ` (85 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Alexander Duyck, Simon Horman, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jakub Kicinski <kuba@kernel.org> [ Upstream commit 4b31bcb025cb497da2b01f87173108ff32d350d2 ] CI hit a UaF in fbnic in the AF_XDP portion of the queues.py test. The UaF is in the __sk_mark_napi_id_once() call in xsk_bind(), NAPI has been freed. Looks like the device failed to open earlier, and we lack clearing the NAPI pointer from the queue. Fixes: 557d02238e05 ("eth: fbnic: centralize the queue count and NAPI<>queue setting") Reviewed-by: Alexander Duyck <alexanderduyck@fb.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250728163129.117360-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/ethernet/meta/fbnic/fbnic_netdev.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c b/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c index 2524d9b88d59..34c00c67006f 100644 --- a/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c +++ b/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c @@ -33,7 +33,7 @@ int __fbnic_open(struct fbnic_net *fbn) dev_warn(fbd->dev, "Error %d sending host ownership message to the firmware\n", err); - goto free_resources; + goto err_reset_queues; } err = fbnic_time_start(fbn); @@ -57,6 +57,8 @@ int __fbnic_open(struct fbnic_net *fbn) fbnic_time_stop(fbn); release_ownership: fbnic_fw_xmit_ownership_msg(fbn->fbd, false); +err_reset_queues: + fbnic_reset_netif_queues(fbn); free_resources: fbnic_free_resources(fbn); free_napi_vectors: -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 407/480] net: airoha: npu: Add missing MODULE_FIRMWARE macros 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (405 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 406/480] eth: fbnic: unlink NAPIs from queues on error to open Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 408/480] benet: fix BUG when creating VFs Greg Kroah-Hartman ` (84 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Lorenzo Bianconi, Andrew Lunn, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Lorenzo Bianconi <lorenzo@kernel.org> [ Upstream commit 4e7e471e2e3f9085fe1dbe821c4dd904a917c66a ] Introduce missing MODULE_FIRMWARE definitions for firmware autoload. Fixes: 23290c7bc190d ("net: airoha: Introduce Airoha NPU support") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250801-airoha-npu-missing-module-firmware-v2-1-e860c824d515@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/ethernet/airoha/airoha_npu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ethernet/airoha/airoha_npu.c b/drivers/net/ethernet/airoha/airoha_npu.c index 760367c2c033..cfd540c93dc8 100644 --- a/drivers/net/ethernet/airoha/airoha_npu.c +++ b/drivers/net/ethernet/airoha/airoha_npu.c @@ -518,6 +518,8 @@ static struct platform_driver airoha_npu_driver = { }; module_platform_driver(airoha_npu_driver); +MODULE_FIRMWARE(NPU_EN7581_FIRMWARE_DATA); +MODULE_FIRMWARE(NPU_EN7581_FIRMWARE_RV32); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Lorenzo Bianconi <lorenzo@kernel.org>"); MODULE_DESCRIPTION("Airoha Network Processor Unit driver"); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 408/480] benet: fix BUG when creating VFs 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (406 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 407/480] net: airoha: npu: Add missing MODULE_FIRMWARE macros Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 409/480] net/sched: mqprio: fix stack out-of-bounds write in tc entry parsing Greg Kroah-Hartman ` (83 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Michal Schmidt, Nikolay Aleksandrov, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Michal Schmidt <mschmidt@redhat.com> [ Upstream commit 5a40f8af2ba1b9bdf46e2db10e8c9710538fbc63 ] benet crashes as soon as SRIOV VFs are created: kernel BUG at mm/vmalloc.c:3457! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 4 UID: 0 PID: 7408 Comm: test.sh Kdump: loaded Not tainted 6.16.0+ #1 PREEMPT(voluntary) [...] RIP: 0010:vunmap+0x5f/0x70 [...] Call Trace: <TASK> __iommu_dma_free+0xe8/0x1c0 be_cmd_set_mac_list+0x3fe/0x640 [be2net] be_cmd_set_mac+0xaf/0x110 [be2net] be_vf_eth_addr_config+0x19f/0x330 [be2net] be_vf_setup+0x4f7/0x990 [be2net] be_pci_sriov_configure+0x3a1/0x470 [be2net] sriov_numvfs_store+0x20b/0x380 kernfs_fop_write_iter+0x354/0x530 vfs_write+0x9b9/0xf60 ksys_write+0xf3/0x1d0 do_syscall_64+0x8c/0x3d0 be_cmd_set_mac_list() calls dma_free_coherent() under a spin_lock_bh. Fix it by freeing only after the lock has been released. Fixes: 1a82d19ca2d6 ("be2net: fix sleeping while atomic bugs in be_ndo_bridge_getlink") Signed-off-by: Michal Schmidt <mschmidt@redhat.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://patch.msgid.link/20250801101338.72502-1-mschmidt@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/ethernet/emulex/benet/be_cmds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c index a89aa4ac0a06..779f1324bb5f 100644 --- a/drivers/net/ethernet/emulex/benet/be_cmds.c +++ b/drivers/net/ethernet/emulex/benet/be_cmds.c @@ -3852,8 +3852,8 @@ int be_cmd_set_mac_list(struct be_adapter *adapter, u8 *mac_array, status = be_mcc_notify_wait(adapter); err: - dma_free_coherent(&adapter->pdev->dev, cmd.size, cmd.va, cmd.dma); spin_unlock_bh(&adapter->mcc_lock); + dma_free_coherent(&adapter->pdev->dev, cmd.size, cmd.va, cmd.dma); return status; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 409/480] net/sched: mqprio: fix stack out-of-bounds write in tc entry parsing 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (407 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 408/480] benet: fix BUG when creating VFs Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 410/480] s390/mm: Allocate page table with PAGE_SIZE granularity Greg Kroah-Hartman ` (82 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Eric Dumazet, Maher Azzouzi, Vladimir Oltean, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Maher Azzouzi <maherazz04@gmail.com> [ Upstream commit ffd2dc4c6c49ff4f1e5d34e454a6a55608104c17 ] TCA_MQPRIO_TC_ENTRY_INDEX is validated using NLA_POLICY_MAX(NLA_U32, TC_QOPT_MAX_QUEUE), which allows the value TC_QOPT_MAX_QUEUE (16). This leads to a 4-byte out-of-bounds stack write in the fp[] array, which only has room for 16 elements (0–15). Fix this by changing the policy to allow only up to TC_QOPT_MAX_QUEUE - 1. Fixes: f62af20bed2d ("net/sched: mqprio: allow per-TC user input of FP adminStatus") Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Maher Azzouzi <maherazz04@gmail.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20250802001857.2702497-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/sched/sch_mqprio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/sched/sch_mqprio.c b/net/sched/sch_mqprio.c index 51d4013b6121..f3e5ef9a9592 100644 --- a/net/sched/sch_mqprio.c +++ b/net/sched/sch_mqprio.c @@ -152,7 +152,7 @@ static int mqprio_parse_opt(struct net_device *dev, struct tc_mqprio_qopt *qopt, static const struct nla_policy mqprio_tc_entry_policy[TCA_MQPRIO_TC_ENTRY_MAX + 1] = { [TCA_MQPRIO_TC_ENTRY_INDEX] = NLA_POLICY_MAX(NLA_U32, - TC_QOPT_MAX_QUEUE), + TC_QOPT_MAX_QUEUE - 1), [TCA_MQPRIO_TC_ENTRY_FP] = NLA_POLICY_RANGE(NLA_U32, TC_FP_EXPRESS, TC_FP_PREEMPTIBLE), -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 410/480] s390/mm: Allocate page table with PAGE_SIZE granularity 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (408 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 409/480] net/sched: mqprio: fix stack out-of-bounds write in tc entry parsing Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 411/480] eth: fbnic: remove the debugging trick of super high page bias Greg Kroah-Hartman ` (81 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Heiko Carstens, Alexander Gordeev, Sumanth Korikkar, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Sumanth Korikkar <sumanthk@linux.ibm.com> [ Upstream commit daa8af80d283ee9a7d42dd6f164a65036665b9d4 ] Make vmem_pte_alloc() consistent by always allocating page table of PAGE_SIZE granularity, regardless of whether page_table_alloc() (with slab) or memblock_alloc() is used. This ensures page table can be fully freed when the corresponding page table entries are removed. Fixes: d08d4e7cd6bf ("s390/mm: use full 4KB page for 2KB PTE") Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/s390/mm/vmem.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/s390/mm/vmem.c b/arch/s390/mm/vmem.c index 448dd6ed1069..f48ef361bc83 100644 --- a/arch/s390/mm/vmem.c +++ b/arch/s390/mm/vmem.c @@ -64,13 +64,12 @@ void *vmem_crst_alloc(unsigned long val) pte_t __ref *vmem_pte_alloc(void) { - unsigned long size = PTRS_PER_PTE * sizeof(pte_t); pte_t *pte; if (slab_is_available()) - pte = (pte_t *) page_table_alloc(&init_mm); + pte = (pte_t *)page_table_alloc(&init_mm); else - pte = (pte_t *) memblock_alloc(size, size); + pte = (pte_t *)memblock_alloc(PAGE_SIZE, PAGE_SIZE); if (!pte) return NULL; memset64((u64 *)pte, _PAGE_INVALID, PTRS_PER_PTE); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 411/480] eth: fbnic: remove the debugging trick of super high page bias 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (409 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 410/480] s390/mm: Allocate page table with PAGE_SIZE granularity Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 412/480] NFS/localio: nfs_close_local_fh() fix check for file closed Greg Kroah-Hartman ` (80 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jakub Kicinski <kuba@kernel.org> [ Upstream commit e407fceeaf1b2959892b4fc9b584843d3f2bfc05 ] Alex added page bias of LONG_MAX, which is admittedly quite a clever way of catching overflows of the pp ref count. The page pool code was "optimized" to leave the ref at 1 for freed pages so it can't catch basic bugs by itself any more. (Something we should probably address under DEBUG_NET...) Unfortunately for fbnic since commit f7dc3248dcfb ("skbuff: Optimization of SKB coalescing for page pool") core _may_ actually take two extra pp refcounts, if one of them is returned before driver gives up the bias the ret < 0 check in page_pool_unref_netmem() will trigger. While at it add a FBNIC_ to the name of the driver constant. Fixes: 0cb4c0a13723 ("eth: fbnic: Implement Rx queue alloc/start/stop/free") Link: https://patch.msgid.link/20250801170754.2439577-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/ethernet/meta/fbnic/fbnic_txrx.c | 4 ++-- drivers/net/ethernet/meta/fbnic/fbnic_txrx.h | 6 ++---- 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_txrx.c b/drivers/net/ethernet/meta/fbnic/fbnic_txrx.c index ac11389a764c..f9543d03485f 100644 --- a/drivers/net/ethernet/meta/fbnic/fbnic_txrx.c +++ b/drivers/net/ethernet/meta/fbnic/fbnic_txrx.c @@ -661,8 +661,8 @@ static void fbnic_page_pool_init(struct fbnic_ring *ring, unsigned int idx, { struct fbnic_rx_buf *rx_buf = &ring->rx_buf[idx]; - page_pool_fragment_page(page, PAGECNT_BIAS_MAX); - rx_buf->pagecnt_bias = PAGECNT_BIAS_MAX; + page_pool_fragment_page(page, FBNIC_PAGECNT_BIAS_MAX); + rx_buf->pagecnt_bias = FBNIC_PAGECNT_BIAS_MAX; rx_buf->page = page; } diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_txrx.h b/drivers/net/ethernet/meta/fbnic/fbnic_txrx.h index f46616af41ea..37b4dadbfc6c 100644 --- a/drivers/net/ethernet/meta/fbnic/fbnic_txrx.h +++ b/drivers/net/ethernet/meta/fbnic/fbnic_txrx.h @@ -91,10 +91,8 @@ struct fbnic_queue_stats { struct u64_stats_sync syncp; }; -/* Pagecnt bias is long max to reserve the last bit to catch overflow - * cases where if we overcharge the bias it will flip over to be negative. - */ -#define PAGECNT_BIAS_MAX LONG_MAX +#define FBNIC_PAGECNT_BIAS_MAX PAGE_SIZE + struct fbnic_rx_buf { struct page *page; long pagecnt_bias; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 412/480] NFS/localio: nfs_close_local_fh() fix check for file closed 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (410 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 411/480] eth: fbnic: remove the debugging trick of super high page bias Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 413/480] NFS/localio: nfs_uuid_put() fix races with nfs_open/close_local_fh() Greg Kroah-Hartman ` (79 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Mike Snitzer, NeilBrown, Trond Myklebust, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Trond Myklebust <trond.myklebust@hammerspace.com> [ Upstream commit e144d53cf21fb9d02626c669533788c6bdc61ce3 ] If the struct nfs_file_localio is closed, its list entry will be empty, but the nfs_uuid->files list might still contain other entries. Acked-by: Mike Snitzer <snitzer@kernel.org> Tested-by: Mike Snitzer <snitzer@kernel.org> Reviewed-by: NeilBrown <neil@brown.name> Fixes: 21fb44034695 ("nfs_localio: protect race between nfs_uuid_put() and nfs_close_local_fh()") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/nfs_common/nfslocalio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfs_common/nfslocalio.c b/fs/nfs_common/nfslocalio.c index 05c7c16e37ab..64949c46c174 100644 --- a/fs/nfs_common/nfslocalio.c +++ b/fs/nfs_common/nfslocalio.c @@ -314,7 +314,7 @@ void nfs_close_local_fh(struct nfs_file_localio *nfl) rcu_read_unlock(); return; } - if (list_empty(&nfs_uuid->files)) { + if (list_empty(&nfl->list)) { /* nfs_uuid_put() has started closing files, wait for it * to finished */ -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 413/480] NFS/localio: nfs_uuid_put() fix races with nfs_open/close_local_fh() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (411 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 412/480] NFS/localio: nfs_close_local_fh() fix check for file closed Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 414/480] NFS/localio: nfs_uuid_put() fix the wake up after unlinking the file Greg Kroah-Hartman ` (78 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Mike Snitzer, Trond Myklebust, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Trond Myklebust <trond.myklebust@hammerspace.com> [ Upstream commit fdd015de767977f21892329af5e12276eb80375f ] In order for the wait in nfs_uuid_put() to be safe, it is necessary to ensure that nfs_uuid_add_file() doesn't add a new entry once the nfs_uuid->net has been NULLed out. Also fix up the wake_up_var_locked() / wait_var_event_spinlock() to both use the nfs_uuid address, since nfl, and &nfl->uuid could be used elsewhere. Acked-by: Mike Snitzer <snitzer@kernel.org> Tested-by: Mike Snitzer <snitzer@kernel.org> Link: https://lore.kernel.org/all/175262893035.2234665.1735173020338594784@noble.neil.brown.name/ Fixes: 21fb44034695 ("nfs_localio: protect race between nfs_uuid_put() and nfs_close_local_fh()") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/nfs_common/nfslocalio.c | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/fs/nfs_common/nfslocalio.c b/fs/nfs_common/nfslocalio.c index 64949c46c174..f1f1592ac134 100644 --- a/fs/nfs_common/nfslocalio.c +++ b/fs/nfs_common/nfslocalio.c @@ -177,7 +177,7 @@ static bool nfs_uuid_put(nfs_uuid_t *nfs_uuid) /* nfs_close_local_fh() is doing the * close and we must wait. until it unlinks */ - wait_var_event_spinlock(nfl, + wait_var_event_spinlock(nfs_uuid, list_first_entry_or_null( &nfs_uuid->files, struct nfs_file_localio, @@ -243,15 +243,20 @@ void nfs_localio_invalidate_clients(struct list_head *nn_local_clients, } EXPORT_SYMBOL_GPL(nfs_localio_invalidate_clients); -static void nfs_uuid_add_file(nfs_uuid_t *nfs_uuid, struct nfs_file_localio *nfl) +static int nfs_uuid_add_file(nfs_uuid_t *nfs_uuid, struct nfs_file_localio *nfl) { + int ret = 0; + /* Add nfl to nfs_uuid->files if it isn't already */ spin_lock(&nfs_uuid->lock); - if (list_empty(&nfl->list)) { + if (rcu_access_pointer(nfs_uuid->net) == NULL) { + ret = -ENXIO; + } else if (list_empty(&nfl->list)) { rcu_assign_pointer(nfl->nfs_uuid, nfs_uuid); list_add_tail(&nfl->list, &nfs_uuid->files); } spin_unlock(&nfs_uuid->lock); + return ret; } /* @@ -285,11 +290,13 @@ struct nfsd_file *nfs_open_local_fh(nfs_uuid_t *uuid, } rcu_read_unlock(); /* We have an implied reference to net thanks to nfsd_net_try_get */ - localio = nfs_to->nfsd_open_local_fh(net, uuid->dom, rpc_clnt, - cred, nfs_fh, pnf, fmode); + localio = nfs_to->nfsd_open_local_fh(net, uuid->dom, rpc_clnt, cred, + nfs_fh, pnf, fmode); + if (!IS_ERR(localio) && nfs_uuid_add_file(uuid, nfl) < 0) { + /* Delete the cached file when racing with nfs_uuid_put() */ + nfs_to_nfsd_file_put_local(pnf); + } nfs_to_nfsd_net_put(net); - if (!IS_ERR(localio)) - nfs_uuid_add_file(uuid, nfl); return localio; } @@ -338,7 +345,7 @@ void nfs_close_local_fh(struct nfs_file_localio *nfl) */ spin_lock(&nfs_uuid->lock); list_del_init(&nfl->list); - wake_up_var_locked(&nfl->nfs_uuid, &nfs_uuid->lock); + wake_up_var_locked(nfs_uuid, &nfs_uuid->lock); spin_unlock(&nfs_uuid->lock); } EXPORT_SYMBOL_GPL(nfs_close_local_fh); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 414/480] NFS/localio: nfs_uuid_put() fix the wake up after unlinking the file 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (412 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 413/480] NFS/localio: nfs_uuid_put() fix races with nfs_open/close_local_fh() Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 415/480] net: ti: icssg-prueth: Fix skb handling for XDP_PASS Greg Kroah-Hartman ` (77 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Mike Snitzer, NeilBrown, Trond Myklebust, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Trond Myklebust <trond.myklebust@hammerspace.com> [ Upstream commit 4ec752ce6debd5a0e7e0febf6bcf780ccda6ab5e ] Use store_release_wake_up() instead of wake_up_var_locked(), because the waiter cannot retake the nfs_uuid->lock. Acked-by: Mike Snitzer <snitzer@kernel.org> Tested-by: Mike Snitzer <snitzer@kernel.org> Suggested-by: NeilBrown <neil@brown.name> Link: https://lore.kernel.org/all/175262948827.2234665.1891349021754495573@noble.neil.brown.name/ Fixes: 21fb44034695 ("nfs_localio: protect race between nfs_uuid_put() and nfs_close_local_fh()") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/nfs_common/nfslocalio.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/nfs_common/nfslocalio.c b/fs/nfs_common/nfslocalio.c index f1f1592ac134..dd715cdb6c04 100644 --- a/fs/nfs_common/nfslocalio.c +++ b/fs/nfs_common/nfslocalio.c @@ -198,8 +198,7 @@ static bool nfs_uuid_put(nfs_uuid_t *nfs_uuid) /* Now we can allow racing nfs_close_local_fh() to * skip the locking. */ - RCU_INIT_POINTER(nfl->nfs_uuid, NULL); - wake_up_var_locked(&nfl->nfs_uuid, &nfs_uuid->lock); + store_release_wake_up(&nfl->nfs_uuid, RCU_INITIALIZER(NULL)); } /* Remove client from nn->local_clients */ -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 415/480] net: ti: icssg-prueth: Fix skb handling for XDP_PASS 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (413 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 414/480] NFS/localio: nfs_uuid_put() fix the wake up after unlinking the file Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 416/480] irqchip: Build IMX_MU_MSI only on ARM Greg Kroah-Hartman ` (76 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Meghana Malladi, Jacob Keller, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Meghana Malladi <m-malladi@ti.com> [ Upstream commit d942fe13f72bec92f6c689fbd74c5ec38228c16a ] emac_rx_packet() is a common function for handling traffic for both xdp and non-xdp use cases. Use common logic for handling skb with or without xdp to prevent any incorrect packet processing. This patch fixes ping working with XDP_PASS for icssg driver. Fixes: 62aa3246f4623 ("net: ti: icssg-prueth: Add XDP support") Signed-off-by: Meghana Malladi <m-malladi@ti.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20250803180216.3569139-1-m-malladi@ti.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/ethernet/ti/icssg/icssg_common.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/ti/icssg/icssg_common.c b/drivers/net/ethernet/ti/icssg/icssg_common.c index 7ae069e7af92..3579e07be3da 100644 --- a/drivers/net/ethernet/ti/icssg/icssg_common.c +++ b/drivers/net/ethernet/ti/icssg/icssg_common.c @@ -706,9 +706,9 @@ static int emac_rx_packet(struct prueth_emac *emac, u32 flow_id, u32 *xdp_state) struct page_pool *pool; struct sk_buff *skb; struct xdp_buff xdp; + int headroom, ret; u32 *psdata; void *pa; - int ret; *xdp_state = 0; pool = rx_chn->pg_pool; @@ -757,22 +757,23 @@ static int emac_rx_packet(struct prueth_emac *emac, u32 flow_id, u32 *xdp_state) xdp_prepare_buff(&xdp, pa, PRUETH_HEADROOM, pkt_len, false); *xdp_state = emac_run_xdp(emac, &xdp, page, &pkt_len); - if (*xdp_state == ICSSG_XDP_PASS) - skb = xdp_build_skb_from_buff(&xdp); - else + if (*xdp_state != ICSSG_XDP_PASS) goto requeue; + headroom = xdp.data - xdp.data_hard_start; + pkt_len = xdp.data_end - xdp.data; } else { - /* prepare skb and send to n/w stack */ - skb = napi_build_skb(pa, PAGE_SIZE); + headroom = PRUETH_HEADROOM; } + /* prepare skb and send to n/w stack */ + skb = napi_build_skb(pa, PAGE_SIZE); if (!skb) { ndev->stats.rx_dropped++; page_pool_recycle_direct(pool, page); goto requeue; } - skb_reserve(skb, PRUETH_HEADROOM); + skb_reserve(skb, headroom); skb_put(skb, pkt_len); skb->dev = ndev; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 416/480] irqchip: Build IMX_MU_MSI only on ARM 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (414 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 415/480] net: ti: icssg-prueth: Fix skb handling for XDP_PASS Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 417/480] ASoC: SOF: Intel: hda-sdw-bpt: fix SND_SOF_SOF_HDA_SDW_BPT dependencies Greg Kroah-Hartman ` (75 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Arnd Bergmann, Thomas Gleixner, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Arnd Bergmann <arnd@arndb.de> [ Upstream commit 3b6a18f0da8720d612d8a682ea5c55870da068e0 ] Compile-testing IMX_MU_MSI on x86 without PCI_MSI support results in a build failure: drivers/gpio/gpio-sprd.c:8: include/linux/gpio/driver.h:41:33: error: field 'msiinfo' has incomplete type drivers/iommu/iommufd/viommu.c:4: include/linux/msi.h:528:33: error: field 'alloc_info' has incomplete type Tighten the dependency further to only allow compile testing on Arm. This could be refined further to allow certain x86 configs. This was submitted before to address a different build failure, which was fixed differently, but the problem has now returned in a different form. Fixes: 70afdab904d2d1e6 ("irqchip: Add IMX MU MSI controller driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20250805160952.4006075-1-arnd@kernel.org Link: https://lore.kernel.org/all/20221215164109.761427-1-arnd@kernel.org/ Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/irqchip/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig index 6539869759b9..087e30bab758 100644 --- a/drivers/irqchip/Kconfig +++ b/drivers/irqchip/Kconfig @@ -534,6 +534,7 @@ config IMX_MU_MSI tristate "i.MX MU used as MSI controller" depends on OF && HAS_IOMEM depends on ARCH_MXC || COMPILE_TEST + depends on ARM || ARM64 default m if ARCH_MXC select IRQ_DOMAIN select IRQ_DOMAIN_HIERARCHY -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 417/480] ASoC: SOF: Intel: hda-sdw-bpt: fix SND_SOF_SOF_HDA_SDW_BPT dependencies 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (415 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 416/480] irqchip: Build IMX_MU_MSI only on ARM Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 418/480] ALSA: hda/ca0132: Fix missing error handling in ca0132_alt_select_out() Greg Kroah-Hartman ` (74 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Arnd Bergmann, Bard Liao, Mark Brown, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Arnd Bergmann <arnd@arndb.de> [ Upstream commit 614d416dd8aee2675fb591c598308a901a660db8 ] The hda-sdw-bpt code links against the soundwire driver, but that fails when trying to link from built-in code into loadable module: x86_64-linux-ld: vmlinux.o: in function `intel_ace2x_bpt_close_stream.isra.0': intel_ace2x.c:(.text+0x137a531): undefined reference to `hda_sdw_bpt_close' x86_64-linux-ld: vmlinux.o: in function `intel_ace2x_bpt_send_async': intel_ace2x.c:(.text+0x137aa45): undefined reference to `hda_sdw_bpt_open' x86_64-linux-ld: intel_ace2x.c:(.text+0x137ab67): undefined reference to `hda_sdw_bpt_close' x86_64-linux-ld: intel_ace2x.c:(.text+0x137ac30): undefined reference to `hda_sdw_bpt_send_async' x86_64-linux-ld: vmlinux.o: in function `intel_ace2x_bpt_wait': intel_ace2x.c:(.text+0x137aced): undefined reference to `hda_sdw_bpt_wait' Ensure that both SOUNDWIRE_INTEL and SND_SOF_SOF_HDA_SDW_BPT are selected at the same time by SND_SOC_SOF_INTEL_LNL, and that this happens even if SND_SOC_SOF_INTEL_SOUNDWIRE is a loadable module but SND_SOC_SOF_INTEL_LNL is built-in. This follows the same logic as commit c5a61db9bf89 ("ASoC: SOF: fix intel-soundwire link failure"). Fixes: 5d5cb86fb46e ("ASoC: SOF: Intel: hda-sdw-bpt: add helpers for SoundWire BPT DMA") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://patch.msgid.link/20250805160451.4004602-1-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- sound/soc/sof/intel/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/soc/sof/intel/Kconfig b/sound/soc/sof/intel/Kconfig index dc1d21de4ab7..4f27f8c8debf 100644 --- a/sound/soc/sof/intel/Kconfig +++ b/sound/soc/sof/intel/Kconfig @@ -266,9 +266,10 @@ config SND_SOC_SOF_METEORLAKE config SND_SOC_SOF_INTEL_LNL tristate + select SOUNDWIRE_INTEL if SND_SOC_SOF_INTEL_SOUNDWIRE != n select SND_SOC_SOF_HDA_GENERIC select SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE - select SND_SOF_SOF_HDA_SDW_BPT if SND_SOC_SOF_INTEL_SOUNDWIRE + select SND_SOF_SOF_HDA_SDW_BPT if SND_SOC_SOF_INTEL_SOUNDWIRE != n select SND_SOC_SOF_IPC4 select SND_SOC_SOF_INTEL_MTL -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 418/480] ALSA: hda/ca0132: Fix missing error handling in ca0132_alt_select_out() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (416 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 417/480] ASoC: SOF: Intel: hda-sdw-bpt: fix SND_SOF_SOF_HDA_SDW_BPT dependencies Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 419/480] s390/boot: Fix startup debugging log Greg Kroah-Hartman ` (73 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Takashi Iwai, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Takashi Iwai <tiwai@suse.de> [ Upstream commit 9f320dfb0ffc555aa2eac8331dee0c2c16f67633 ] There are a couple of cases where the error is ignored or the error code isn't propagated in ca0132_alt_select_out(). Fix those. Fixes: def3f0a5c700 ("ALSA: hda/ca0132 - Add quirk output selection structures.") Link: https://patch.msgid.link/20250806094423.8843-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org> --- sound/pci/hda/patch_ca0132.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c index d40197fb5fbd..77432e06f3e3 100644 --- a/sound/pci/hda/patch_ca0132.c +++ b/sound/pci/hda/patch_ca0132.c @@ -4802,7 +4802,8 @@ static int ca0132_alt_select_out(struct hda_codec *codec) if (err < 0) goto exit; - if (ca0132_alt_select_out_quirk_set(codec) < 0) + err = ca0132_alt_select_out_quirk_set(codec); + if (err < 0) goto exit; switch (spec->cur_out_type) { @@ -4892,6 +4893,8 @@ static int ca0132_alt_select_out(struct hda_codec *codec) spec->bass_redirection_val); else err = ca0132_alt_surround_set_bass_redirection(codec, 0); + if (err < 0) + goto exit; /* Unmute DSP now that we're done with output selection. */ err = dspio_set_uint_param(codec, 0x96, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 419/480] s390/boot: Fix startup debugging log 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (417 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 418/480] ALSA: hda/ca0132: Fix missing error handling in ca0132_alt_select_out() Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 420/480] smb: server: remove separate empty_recvmsg_queue Greg Kroah-Hartman ` (72 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Alexander Gordeev, Mikhail Zaslonko, Heiko Carstens, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Mikhail Zaslonko <zaslonko@linux.ibm.com> [ Upstream commit e29409faec87ffd2de2ed20b6109f303f129281b ] Fix 'kernel image' end address for kaslr case. Fixes: ec6f9f7e5bbf ("s390/boot: Add startup debugging support") Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Mikhail Zaslonko <zaslonko@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/s390/boot/startup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/s390/boot/startup.c b/arch/s390/boot/startup.c index 06316fb8e0fa..6d4357441897 100644 --- a/arch/s390/boot/startup.c +++ b/arch/s390/boot/startup.c @@ -369,7 +369,7 @@ static unsigned long setup_kernel_memory_layout(unsigned long kernel_size) kernel_start = round_down(kernel_end - kernel_size, THREAD_SIZE); boot_debug("Randomization range: 0x%016lx-0x%016lx\n", vmax - kaslr_len, vmax); boot_debug("kernel image: 0x%016lx-0x%016lx (kaslr)\n", kernel_start, - kernel_size + kernel_size); + kernel_start + kernel_size); } else if (vmax < __NO_KASLR_END_KERNEL || vsize > __NO_KASLR_END_KERNEL) { kernel_start = round_down(vmax - kernel_size, THREAD_SIZE); boot_debug("kernel image: 0x%016lx-0x%016lx (constrained)\n", kernel_start, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 420/480] smb: server: remove separate empty_recvmsg_queue 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (418 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 419/480] s390/boot: Fix startup debugging log Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 421/480] smb: server: make sure we call ib_dma_unmap_single() only if we called ib_dma_map_single already Greg Kroah-Hartman ` (71 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Steve French, Tom Talpey, linux-cifs, samba-technical, Stefan Metzmacher, Namjae Jeon, Steve French, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Stefan Metzmacher <metze@samba.org> [ Upstream commit 01027a62b508c48c762096f347de925eedcbd008 ] There's no need to maintain two lists, we can just have a single list of receive buffers, which are free to use. Cc: Steve French <smfrench@gmail.com> Cc: Tom Talpey <tom@talpey.com> Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") Signed-off-by: Stefan Metzmacher <metze@samba.org> Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/smb/server/transport_rdma.c | 60 +++++----------------------------- 1 file changed, 8 insertions(+), 52 deletions(-) diff --git a/fs/smb/server/transport_rdma.c b/fs/smb/server/transport_rdma.c index c6cbe0d56e32..393254109fc4 100644 --- a/fs/smb/server/transport_rdma.c +++ b/fs/smb/server/transport_rdma.c @@ -129,9 +129,6 @@ struct smb_direct_transport { spinlock_t recvmsg_queue_lock; struct list_head recvmsg_queue; - spinlock_t empty_recvmsg_queue_lock; - struct list_head empty_recvmsg_queue; - int send_credit_target; atomic_t send_credits; spinlock_t lock_new_recv_credits; @@ -276,32 +273,6 @@ static void put_recvmsg(struct smb_direct_transport *t, spin_unlock(&t->recvmsg_queue_lock); } -static struct -smb_direct_recvmsg *get_empty_recvmsg(struct smb_direct_transport *t) -{ - struct smb_direct_recvmsg *recvmsg = NULL; - - spin_lock(&t->empty_recvmsg_queue_lock); - if (!list_empty(&t->empty_recvmsg_queue)) { - recvmsg = list_first_entry(&t->empty_recvmsg_queue, - struct smb_direct_recvmsg, list); - list_del(&recvmsg->list); - } - spin_unlock(&t->empty_recvmsg_queue_lock); - return recvmsg; -} - -static void put_empty_recvmsg(struct smb_direct_transport *t, - struct smb_direct_recvmsg *recvmsg) -{ - ib_dma_unmap_single(t->cm_id->device, recvmsg->sge.addr, - recvmsg->sge.length, DMA_FROM_DEVICE); - - spin_lock(&t->empty_recvmsg_queue_lock); - list_add_tail(&recvmsg->list, &t->empty_recvmsg_queue); - spin_unlock(&t->empty_recvmsg_queue_lock); -} - static void enqueue_reassembly(struct smb_direct_transport *t, struct smb_direct_recvmsg *recvmsg, int data_length) @@ -386,9 +357,6 @@ static struct smb_direct_transport *alloc_transport(struct rdma_cm_id *cm_id) spin_lock_init(&t->recvmsg_queue_lock); INIT_LIST_HEAD(&t->recvmsg_queue); - spin_lock_init(&t->empty_recvmsg_queue_lock); - INIT_LIST_HEAD(&t->empty_recvmsg_queue); - init_waitqueue_head(&t->wait_send_pending); atomic_set(&t->send_pending, 0); @@ -554,7 +522,7 @@ static void recv_done(struct ib_cq *cq, struct ib_wc *wc) wc->opcode); smb_direct_disconnect_rdma_connection(t); } - put_empty_recvmsg(t, recvmsg); + put_recvmsg(t, recvmsg); return; } @@ -568,7 +536,7 @@ static void recv_done(struct ib_cq *cq, struct ib_wc *wc) switch (recvmsg->type) { case SMB_DIRECT_MSG_NEGOTIATE_REQ: if (wc->byte_len < sizeof(struct smb_direct_negotiate_req)) { - put_empty_recvmsg(t, recvmsg); + put_recvmsg(t, recvmsg); return; } t->negotiation_requested = true; @@ -585,7 +553,7 @@ static void recv_done(struct ib_cq *cq, struct ib_wc *wc) if (wc->byte_len < offsetof(struct smb_direct_data_transfer, padding)) { - put_empty_recvmsg(t, recvmsg); + put_recvmsg(t, recvmsg); return; } @@ -593,7 +561,7 @@ static void recv_done(struct ib_cq *cq, struct ib_wc *wc) if (data_length) { if (wc->byte_len < sizeof(struct smb_direct_data_transfer) + (u64)data_length) { - put_empty_recvmsg(t, recvmsg); + put_recvmsg(t, recvmsg); return; } @@ -613,7 +581,7 @@ static void recv_done(struct ib_cq *cq, struct ib_wc *wc) avail_recvmsg_count = t->count_avail_recvmsg; spin_unlock(&t->receive_credit_lock); } else { - put_empty_recvmsg(t, recvmsg); + put_recvmsg(t, recvmsg); spin_lock(&t->receive_credit_lock); receive_credits = --(t->recv_credits); @@ -811,7 +779,6 @@ static void smb_direct_post_recv_credits(struct work_struct *work) struct smb_direct_recvmsg *recvmsg; int receive_credits, credits = 0; int ret; - int use_free = 1; spin_lock(&t->receive_credit_lock); receive_credits = t->recv_credits; @@ -819,18 +786,9 @@ static void smb_direct_post_recv_credits(struct work_struct *work) if (receive_credits < t->recv_credit_target) { while (true) { - if (use_free) - recvmsg = get_free_recvmsg(t); - else - recvmsg = get_empty_recvmsg(t); - if (!recvmsg) { - if (use_free) { - use_free = 0; - continue; - } else { - break; - } - } + recvmsg = get_free_recvmsg(t); + if (!recvmsg) + break; recvmsg->type = SMB_DIRECT_MSG_DATA_TRANSFER; recvmsg->first_segment = false; @@ -1806,8 +1764,6 @@ static void smb_direct_destroy_pools(struct smb_direct_transport *t) while ((recvmsg = get_free_recvmsg(t))) mempool_free(recvmsg, t->recvmsg_mempool); - while ((recvmsg = get_empty_recvmsg(t))) - mempool_free(recvmsg, t->recvmsg_mempool); mempool_destroy(t->recvmsg_mempool); t->recvmsg_mempool = NULL; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 421/480] smb: server: make sure we call ib_dma_unmap_single() only if we called ib_dma_map_single already 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (419 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 420/480] smb: server: remove separate empty_recvmsg_queue Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 422/480] smb: server: let recv_done() consistently call put_recvmsg/smb_direct_disconnect_rdma_connection Greg Kroah-Hartman ` (70 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Namjae Jeon, Steve French, Tom Talpey, linux-cifs, samba-technical, Stefan Metzmacher, Steve French, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Stefan Metzmacher <metze@samba.org> [ Upstream commit afb4108c92898350e66b9a009692230bcdd2ac73 ] In case of failures either ib_dma_map_single() might not be called yet or ib_dma_unmap_single() was already called. We should make sure put_recvmsg() only calls ib_dma_unmap_single() if needed. Cc: Namjae Jeon <linkinjeon@kernel.org> Cc: Steve French <smfrench@gmail.com> Cc: Tom Talpey <tom@talpey.com> Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") Signed-off-by: Stefan Metzmacher <metze@samba.org> Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/smb/server/transport_rdma.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/fs/smb/server/transport_rdma.c b/fs/smb/server/transport_rdma.c index 393254109fc4..fac82e60ff80 100644 --- a/fs/smb/server/transport_rdma.c +++ b/fs/smb/server/transport_rdma.c @@ -265,8 +265,13 @@ smb_direct_recvmsg *get_free_recvmsg(struct smb_direct_transport *t) static void put_recvmsg(struct smb_direct_transport *t, struct smb_direct_recvmsg *recvmsg) { - ib_dma_unmap_single(t->cm_id->device, recvmsg->sge.addr, - recvmsg->sge.length, DMA_FROM_DEVICE); + if (likely(recvmsg->sge.length != 0)) { + ib_dma_unmap_single(t->cm_id->device, + recvmsg->sge.addr, + recvmsg->sge.length, + DMA_FROM_DEVICE); + recvmsg->sge.length = 0; + } spin_lock(&t->recvmsg_queue_lock); list_add(&recvmsg->list, &t->recvmsg_queue); @@ -638,6 +643,7 @@ static int smb_direct_post_recv(struct smb_direct_transport *t, ib_dma_unmap_single(t->cm_id->device, recvmsg->sge.addr, recvmsg->sge.length, DMA_FROM_DEVICE); + recvmsg->sge.length = 0; smb_direct_disconnect_rdma_connection(t); return ret; } @@ -1819,6 +1825,7 @@ static int smb_direct_create_pools(struct smb_direct_transport *t) if (!recvmsg) goto err; recvmsg->transport = t; + recvmsg->sge.length = 0; list_add(&recvmsg->list, &t->recvmsg_queue); } t->count_avail_recvmsg = t->recv_credit_max; -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 422/480] smb: server: let recv_done() consistently call put_recvmsg/smb_direct_disconnect_rdma_connection 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (420 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 421/480] smb: server: make sure we call ib_dma_unmap_single() only if we called ib_dma_map_single already Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 423/480] smb: server: let recv_done() avoid touching data_transfer after cleanup/move Greg Kroah-Hartman ` (69 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Namjae Jeon, Steve French, Tom Talpey, linux-cifs, samba-technical, Stefan Metzmacher, Steve French, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Stefan Metzmacher <metze@samba.org> [ Upstream commit cfe76fdbb9729c650f3505d9cfb2f70ddda2dbdc ] We should call put_recvmsg() before smb_direct_disconnect_rdma_connection() in order to call it before waking up the callers. In all error cases we should call smb_direct_disconnect_rdma_connection() in order to avoid stale connections. Cc: Namjae Jeon <linkinjeon@kernel.org> Cc: Steve French <smfrench@gmail.com> Cc: Tom Talpey <tom@talpey.com> Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") Signed-off-by: Stefan Metzmacher <metze@samba.org> Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/smb/server/transport_rdma.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/fs/smb/server/transport_rdma.c b/fs/smb/server/transport_rdma.c index fac82e60ff80..cd8a92fe372b 100644 --- a/fs/smb/server/transport_rdma.c +++ b/fs/smb/server/transport_rdma.c @@ -521,13 +521,13 @@ static void recv_done(struct ib_cq *cq, struct ib_wc *wc) t = recvmsg->transport; if (wc->status != IB_WC_SUCCESS || wc->opcode != IB_WC_RECV) { + put_recvmsg(t, recvmsg); if (wc->status != IB_WC_WR_FLUSH_ERR) { pr_err("Recv error. status='%s (%d)' opcode=%d\n", ib_wc_status_msg(wc->status), wc->status, wc->opcode); smb_direct_disconnect_rdma_connection(t); } - put_recvmsg(t, recvmsg); return; } @@ -542,6 +542,7 @@ static void recv_done(struct ib_cq *cq, struct ib_wc *wc) case SMB_DIRECT_MSG_NEGOTIATE_REQ: if (wc->byte_len < sizeof(struct smb_direct_negotiate_req)) { put_recvmsg(t, recvmsg); + smb_direct_disconnect_rdma_connection(t); return; } t->negotiation_requested = true; @@ -549,7 +550,7 @@ static void recv_done(struct ib_cq *cq, struct ib_wc *wc) t->status = SMB_DIRECT_CS_CONNECTED; enqueue_reassembly(t, recvmsg, 0); wake_up_interruptible(&t->wait_status); - break; + return; case SMB_DIRECT_MSG_DATA_TRANSFER: { struct smb_direct_data_transfer *data_transfer = (struct smb_direct_data_transfer *)recvmsg->packet; @@ -559,6 +560,7 @@ static void recv_done(struct ib_cq *cq, struct ib_wc *wc) if (wc->byte_len < offsetof(struct smb_direct_data_transfer, padding)) { put_recvmsg(t, recvmsg); + smb_direct_disconnect_rdma_connection(t); return; } @@ -567,6 +569,7 @@ static void recv_done(struct ib_cq *cq, struct ib_wc *wc) if (wc->byte_len < sizeof(struct smb_direct_data_transfer) + (u64)data_length) { put_recvmsg(t, recvmsg); + smb_direct_disconnect_rdma_connection(t); return; } @@ -609,11 +612,16 @@ static void recv_done(struct ib_cq *cq, struct ib_wc *wc) if (is_receive_credit_post_required(receive_credits, avail_recvmsg_count)) mod_delayed_work(smb_direct_wq, &t->post_recv_credits_work, 0); - break; + return; } - default: - break; } + + /* + * This is an internal error! + */ + WARN_ON_ONCE(recvmsg->type != SMB_DIRECT_MSG_DATA_TRANSFER); + put_recvmsg(t, recvmsg); + smb_direct_disconnect_rdma_connection(t); } static int smb_direct_post_recv(struct smb_direct_transport *t, -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 423/480] smb: server: let recv_done() avoid touching data_transfer after cleanup/move 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (421 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 422/480] smb: server: let recv_done() consistently call put_recvmsg/smb_direct_disconnect_rdma_connection Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 424/480] smb: client: let send_done() cleanup before calling smbd_disconnect_rdma_connection() Greg Kroah-Hartman ` (68 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Namjae Jeon, Steve French, Tom Talpey, linux-cifs, samba-technical, Stefan Metzmacher, Steve French, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Stefan Metzmacher <metze@samba.org> [ Upstream commit a6c015b7ac2d8c5233337e5793f50d04fac17669 ] Calling enqueue_reassembly() and wake_up_interruptible(&t->wait_reassembly_queue) or put_receive_buffer() means the recvmsg/data_transfer pointer might get re-used by another thread, which means these should be the last operations before calling return. Cc: Namjae Jeon <linkinjeon@kernel.org> Cc: Steve French <smfrench@gmail.com> Cc: Tom Talpey <tom@talpey.com> Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") Signed-off-by: Stefan Metzmacher <metze@samba.org> Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/smb/server/transport_rdma.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/fs/smb/server/transport_rdma.c b/fs/smb/server/transport_rdma.c index cd8a92fe372b..8d366db5f605 100644 --- a/fs/smb/server/transport_rdma.c +++ b/fs/smb/server/transport_rdma.c @@ -581,16 +581,11 @@ static void recv_done(struct ib_cq *cq, struct ib_wc *wc) else t->full_packet_received = true; - enqueue_reassembly(t, recvmsg, (int)data_length); - wake_up_interruptible(&t->wait_reassembly_queue); - spin_lock(&t->receive_credit_lock); receive_credits = --(t->recv_credits); avail_recvmsg_count = t->count_avail_recvmsg; spin_unlock(&t->receive_credit_lock); } else { - put_recvmsg(t, recvmsg); - spin_lock(&t->receive_credit_lock); receive_credits = --(t->recv_credits); avail_recvmsg_count = ++(t->count_avail_recvmsg); @@ -612,6 +607,13 @@ static void recv_done(struct ib_cq *cq, struct ib_wc *wc) if (is_receive_credit_post_required(receive_credits, avail_recvmsg_count)) mod_delayed_work(smb_direct_wq, &t->post_recv_credits_work, 0); + + if (data_length) { + enqueue_reassembly(t, recvmsg, (int)data_length); + wake_up_interruptible(&t->wait_reassembly_queue); + } else + put_recvmsg(t, recvmsg); + return; } } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 424/480] smb: client: let send_done() cleanup before calling smbd_disconnect_rdma_connection() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (422 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 423/480] smb: server: let recv_done() avoid touching data_transfer after cleanup/move Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 425/480] smb: client: remove separate empty_packet_queue Greg Kroah-Hartman ` (67 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Steve French, Tom Talpey, Long Li, linux-cifs, samba-technical, Stefan Metzmacher, Steve French, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Stefan Metzmacher <metze@samba.org> [ Upstream commit 5349ae5e05fa37409fd48a1eb483b199c32c889b ] We should call ib_dma_unmap_single() and mempool_free() before calling smbd_disconnect_rdma_connection(). And smbd_disconnect_rdma_connection() needs to be the last function to call as all other state might already be gone after it returns. Cc: Steve French <smfrench@gmail.com> Cc: Tom Talpey <tom@talpey.com> Cc: Long Li <longli@microsoft.com> Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection") Signed-off-by: Stefan Metzmacher <metze@samba.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/smb/client/smbdirect.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/fs/smb/client/smbdirect.c b/fs/smb/client/smbdirect.c index 754e94a0e07f..e99e783f1b0e 100644 --- a/fs/smb/client/smbdirect.c +++ b/fs/smb/client/smbdirect.c @@ -281,18 +281,20 @@ static void send_done(struct ib_cq *cq, struct ib_wc *wc) log_rdma_send(INFO, "smbd_request 0x%p completed wc->status=%d\n", request, wc->status); - if (wc->status != IB_WC_SUCCESS || wc->opcode != IB_WC_SEND) { - log_rdma_send(ERR, "wc->status=%d wc->opcode=%d\n", - wc->status, wc->opcode); - smbd_disconnect_rdma_connection(request->info); - } - for (i = 0; i < request->num_sge; i++) ib_dma_unmap_single(sc->ib.dev, request->sge[i].addr, request->sge[i].length, DMA_TO_DEVICE); + if (wc->status != IB_WC_SUCCESS || wc->opcode != IB_WC_SEND) { + log_rdma_send(ERR, "wc->status=%d wc->opcode=%d\n", + wc->status, wc->opcode); + mempool_free(request, info->request_mempool); + smbd_disconnect_rdma_connection(info); + return; + } + if (atomic_dec_and_test(&request->info->send_pending)) wake_up(&request->info->wait_send_pending); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 425/480] smb: client: remove separate empty_packet_queue 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (423 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 424/480] smb: client: let send_done() cleanup before calling smbd_disconnect_rdma_connection() Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 426/480] smb: client: make sure we call ib_dma_unmap_single() only if we called ib_dma_map_single already Greg Kroah-Hartman ` (66 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Steve French, Tom Talpey, Long Li, linux-cifs, samba-technical, Stefan Metzmacher, Steve French, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Stefan Metzmacher <metze@samba.org> [ Upstream commit 24b6afc36db748467e853e166a385df07e443859 ] There's no need to maintain two lists, we can just have a single list of receive buffers, which are free to use. It just added unneeded complexity and resulted in ib_dma_unmap_single() not being called from recv_done() for empty keepalive packets. Cc: Steve French <smfrench@gmail.com> Cc: Tom Talpey <tom@talpey.com> Cc: Long Li <longli@microsoft.com> Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection") Signed-off-by: Stefan Metzmacher <metze@samba.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/smb/client/cifs_debug.c | 6 ++-- fs/smb/client/smbdirect.c | 62 +++----------------------------------- fs/smb/client/smbdirect.h | 4 --- 3 files changed, 7 insertions(+), 65 deletions(-) diff --git a/fs/smb/client/cifs_debug.c b/fs/smb/client/cifs_debug.c index c0196be0e65f..9092051776fc 100644 --- a/fs/smb/client/cifs_debug.c +++ b/fs/smb/client/cifs_debug.c @@ -432,10 +432,8 @@ static int cifs_debug_data_proc_show(struct seq_file *m, void *v) server->smbd_conn->receive_credit_target); seq_printf(m, "\nPending send_pending: %x ", atomic_read(&server->smbd_conn->send_pending)); - seq_printf(m, "\nReceive buffers count_receive_queue: %x " - "count_empty_packet_queue: %x", - server->smbd_conn->count_receive_queue, - server->smbd_conn->count_empty_packet_queue); + seq_printf(m, "\nReceive buffers count_receive_queue: %x ", + server->smbd_conn->count_receive_queue); seq_printf(m, "\nMR responder_resources: %x " "max_frmr_depth: %x mr_type: %x", server->smbd_conn->responder_resources, diff --git a/fs/smb/client/smbdirect.c b/fs/smb/client/smbdirect.c index e99e783f1b0e..0ab490c0a9b0 100644 --- a/fs/smb/client/smbdirect.c +++ b/fs/smb/client/smbdirect.c @@ -13,8 +13,6 @@ #include "cifsproto.h" #include "smb2proto.h" -static struct smbd_response *get_empty_queue_buffer( - struct smbd_connection *info); static struct smbd_response *get_receive_buffer( struct smbd_connection *info); static void put_receive_buffer( @@ -23,8 +21,6 @@ static void put_receive_buffer( static int allocate_receive_buffers(struct smbd_connection *info, int num_buf); static void destroy_receive_buffers(struct smbd_connection *info); -static void put_empty_packet( - struct smbd_connection *info, struct smbd_response *response); static void enqueue_reassembly( struct smbd_connection *info, struct smbd_response *response, int data_length); @@ -393,7 +389,6 @@ static bool process_negotiation_response( static void smbd_post_send_credits(struct work_struct *work) { int ret = 0; - int use_receive_queue = 1; int rc; struct smbd_response *response; struct smbd_connection *info = @@ -409,18 +404,9 @@ static void smbd_post_send_credits(struct work_struct *work) if (info->receive_credit_target > atomic_read(&info->receive_credits)) { while (true) { - if (use_receive_queue) - response = get_receive_buffer(info); - else - response = get_empty_queue_buffer(info); - if (!response) { - /* now switch to empty packet queue */ - if (use_receive_queue) { - use_receive_queue = 0; - continue; - } else - break; - } + response = get_receive_buffer(info); + if (!response) + break; response->type = SMBD_TRANSFER_DATA; response->first_segment = false; @@ -511,7 +497,7 @@ static void recv_done(struct ib_cq *cq, struct ib_wc *wc) response, data_length); } else - put_empty_packet(info, response); + put_receive_buffer(info, response); if (data_length) wake_up_interruptible(&info->wait_reassembly_queue); @@ -1115,17 +1101,6 @@ static int smbd_negotiate(struct smbd_connection *info) return rc; } -static void put_empty_packet( - struct smbd_connection *info, struct smbd_response *response) -{ - spin_lock(&info->empty_packet_queue_lock); - list_add_tail(&response->list, &info->empty_packet_queue); - info->count_empty_packet_queue++; - spin_unlock(&info->empty_packet_queue_lock); - - queue_work(info->workqueue, &info->post_send_credits_work); -} - /* * Implement Connection.FragmentReassemblyBuffer defined in [MS-SMBD] 3.1.1.1 * This is a queue for reassembling upper layer payload and present to upper @@ -1174,25 +1149,6 @@ static struct smbd_response *_get_first_reassembly(struct smbd_connection *info) return ret; } -static struct smbd_response *get_empty_queue_buffer( - struct smbd_connection *info) -{ - struct smbd_response *ret = NULL; - unsigned long flags; - - spin_lock_irqsave(&info->empty_packet_queue_lock, flags); - if (!list_empty(&info->empty_packet_queue)) { - ret = list_first_entry( - &info->empty_packet_queue, - struct smbd_response, list); - list_del(&ret->list); - info->count_empty_packet_queue--; - } - spin_unlock_irqrestore(&info->empty_packet_queue_lock, flags); - - return ret; -} - /* * Get a receive buffer * For each remote send, we need to post a receive. The receive buffers are @@ -1257,10 +1213,6 @@ static int allocate_receive_buffers(struct smbd_connection *info, int num_buf) spin_lock_init(&info->receive_queue_lock); info->count_receive_queue = 0; - INIT_LIST_HEAD(&info->empty_packet_queue); - spin_lock_init(&info->empty_packet_queue_lock); - info->count_empty_packet_queue = 0; - init_waitqueue_head(&info->wait_receive_queues); for (i = 0; i < num_buf; i++) { @@ -1294,9 +1246,6 @@ static void destroy_receive_buffers(struct smbd_connection *info) while ((response = get_receive_buffer(info))) mempool_free(response, info->response_mempool); - - while ((response = get_empty_queue_buffer(info))) - mempool_free(response, info->response_mempool); } /* Implement idle connection timer [MS-SMBD] 3.1.6.2 */ @@ -1383,8 +1332,7 @@ void smbd_destroy(struct TCP_Server_Info *server) log_rdma_event(INFO, "free receive buffers\n"); wait_event(info->wait_receive_queues, - info->count_receive_queue + info->count_empty_packet_queue - == sp->recv_credit_max); + info->count_receive_queue == sp->recv_credit_max); destroy_receive_buffers(info); /* diff --git a/fs/smb/client/smbdirect.h b/fs/smb/client/smbdirect.h index 3d552ab27e0f..fb8db71735f3 100644 --- a/fs/smb/client/smbdirect.h +++ b/fs/smb/client/smbdirect.h @@ -110,10 +110,6 @@ struct smbd_connection { int count_receive_queue; spinlock_t receive_queue_lock; - struct list_head empty_packet_queue; - int count_empty_packet_queue; - spinlock_t empty_packet_queue_lock; - wait_queue_head_t wait_receive_queues; /* Reassembly queue */ -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 426/480] smb: client: make sure we call ib_dma_unmap_single() only if we called ib_dma_map_single already 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (424 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 425/480] smb: client: remove separate empty_packet_queue Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 427/480] smb: client: let recv_done() cleanup before notifying the callers Greg Kroah-Hartman ` (65 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Steve French, Tom Talpey, Long Li, linux-cifs, samba-technical, Stefan Metzmacher, Steve French, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Stefan Metzmacher <metze@samba.org> [ Upstream commit 047682c370b6f18fec818b57b0ed8b501bdb79f8 ] In case of failures either ib_dma_map_single() might not be called yet or ib_dma_unmap_single() was already called. We should make sure put_receive_buffer() only calls ib_dma_unmap_single() if needed. Cc: Steve French <smfrench@gmail.com> Cc: Tom Talpey <tom@talpey.com> Cc: Long Li <longli@microsoft.com> Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection") Signed-off-by: Stefan Metzmacher <metze@samba.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/smb/client/smbdirect.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/fs/smb/client/smbdirect.c b/fs/smb/client/smbdirect.c index 0ab490c0a9b0..5690e8b3d101 100644 --- a/fs/smb/client/smbdirect.c +++ b/fs/smb/client/smbdirect.c @@ -1057,6 +1057,7 @@ static int smbd_post_recv( if (rc) { ib_dma_unmap_single(sc->ib.dev, response->sge.addr, response->sge.length, DMA_FROM_DEVICE); + response->sge.length = 0; smbd_disconnect_rdma_connection(info); log_rdma_recv(ERR, "ib_post_recv failed rc=%d\n", rc); } @@ -1186,8 +1187,13 @@ static void put_receive_buffer( struct smbdirect_socket *sc = &info->socket; unsigned long flags; - ib_dma_unmap_single(sc->ib.dev, response->sge.addr, - response->sge.length, DMA_FROM_DEVICE); + if (likely(response->sge.length != 0)) { + ib_dma_unmap_single(sc->ib.dev, + response->sge.addr, + response->sge.length, + DMA_FROM_DEVICE); + response->sge.length = 0; + } spin_lock_irqsave(&info->receive_queue_lock, flags); list_add_tail(&response->list, &info->receive_queue); @@ -1221,6 +1227,7 @@ static int allocate_receive_buffers(struct smbd_connection *info, int num_buf) goto allocate_failed; response->info = info; + response->sge.length = 0; list_add_tail(&response->list, &info->receive_queue); info->count_receive_queue++; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 427/480] smb: client: let recv_done() cleanup before notifying the callers. 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (425 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 426/480] smb: client: make sure we call ib_dma_unmap_single() only if we called ib_dma_map_single already Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 428/480] smb: client: let recv_done() avoid touching data_transfer after cleanup/move Greg Kroah-Hartman ` (64 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Steve French, Tom Talpey, Long Li, linux-cifs, samba-technical, Stefan Metzmacher, Steve French, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Stefan Metzmacher <metze@samba.org> [ Upstream commit bdd7afc6dca5e0ebbb75583484aa6ea9e03fbb13 ] We should call put_receive_buffer() before waking up the callers. For the internal error case of response->type being unexpected, we now also call smbd_disconnect_rdma_connection() instead of not waking up the callers at all. Note that the SMBD_TRANSFER_DATA case still has problems, which will be addressed in the next commit in order to make it easier to review this one. Cc: Steve French <smfrench@gmail.com> Cc: Tom Talpey <tom@talpey.com> Cc: Long Li <longli@microsoft.com> Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection") Signed-off-by: Stefan Metzmacher <metze@samba.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/smb/client/smbdirect.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/fs/smb/client/smbdirect.c b/fs/smb/client/smbdirect.c index 5690e8b3d101..d26b8cef82d6 100644 --- a/fs/smb/client/smbdirect.c +++ b/fs/smb/client/smbdirect.c @@ -454,7 +454,6 @@ static void recv_done(struct ib_cq *cq, struct ib_wc *wc) if (wc->status != IB_WC_SUCCESS || wc->opcode != IB_WC_RECV) { log_rdma_recv(INFO, "wc->status=%d opcode=%d\n", wc->status, wc->opcode); - smbd_disconnect_rdma_connection(info); goto error; } @@ -471,8 +470,9 @@ static void recv_done(struct ib_cq *cq, struct ib_wc *wc) info->full_packet_received = true; info->negotiate_done = process_negotiation_response(response, wc->byte_len); + put_receive_buffer(info, response); complete(&info->negotiate_completion); - break; + return; /* SMBD data transfer packet */ case SMBD_TRANSFER_DATA: @@ -529,14 +529,16 @@ static void recv_done(struct ib_cq *cq, struct ib_wc *wc) } return; - - default: - log_rdma_recv(ERR, - "unexpected response type=%d\n", response->type); } + /* + * This is an internal error! + */ + log_rdma_recv(ERR, "unexpected response type=%d\n", response->type); + WARN_ON_ONCE(response->type != SMBD_TRANSFER_DATA); error: put_receive_buffer(info, response); + smbd_disconnect_rdma_connection(info); } static struct rdma_cm_id *smbd_create_id( -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 428/480] smb: client: let recv_done() avoid touching data_transfer after cleanup/move 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (426 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 427/480] smb: client: let recv_done() cleanup before notifying the callers Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 429/480] nvmet: exit debugfs after discovery subsystem exits Greg Kroah-Hartman ` (63 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Steve French, Tom Talpey, Long Li, linux-cifs, samba-technical, Stefan Metzmacher, Steve French, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Stefan Metzmacher <metze@samba.org> [ Upstream commit 24eff17887cb45c25a427e662dda352973c5c171 ] Calling enqueue_reassembly() and wake_up_interruptible(&info->wait_reassembly_queue) or put_receive_buffer() means the response/data_transfer pointer might get re-used by another thread, which means these should be the last operations before calling return. Cc: Steve French <smfrench@gmail.com> Cc: Tom Talpey <tom@talpey.com> Cc: Long Li <longli@microsoft.com> Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection") Signed-off-by: Stefan Metzmacher <metze@samba.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/smb/client/smbdirect.c | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-) diff --git a/fs/smb/client/smbdirect.c b/fs/smb/client/smbdirect.c index d26b8cef82d6..47f2a6cc1c0c 100644 --- a/fs/smb/client/smbdirect.c +++ b/fs/smb/client/smbdirect.c @@ -479,10 +479,6 @@ static void recv_done(struct ib_cq *cq, struct ib_wc *wc) data_transfer = smbd_response_payload(response); data_length = le32_to_cpu(data_transfer->data_length); - /* - * If this is a packet with data playload place the data in - * reassembly queue and wake up the reading thread - */ if (data_length) { if (info->full_packet_received) response->first_segment = true; @@ -491,16 +487,7 @@ static void recv_done(struct ib_cq *cq, struct ib_wc *wc) info->full_packet_received = false; else info->full_packet_received = true; - - enqueue_reassembly( - info, - response, - data_length); - } else - put_receive_buffer(info, response); - - if (data_length) - wake_up_interruptible(&info->wait_reassembly_queue); + } atomic_dec(&info->receive_credits); info->receive_credit_target = @@ -528,6 +515,16 @@ static void recv_done(struct ib_cq *cq, struct ib_wc *wc) info->keep_alive_requested = KEEP_ALIVE_PENDING; } + /* + * If this is a packet with data playload place the data in + * reassembly queue and wake up the reading thread + */ + if (data_length) { + enqueue_reassembly(info, response, data_length); + wake_up_interruptible(&info->wait_reassembly_queue); + } else + put_receive_buffer(info, response); + return; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 429/480] nvmet: exit debugfs after discovery subsystem exits 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (427 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 428/480] smb: client: let recv_done() avoid touching data_transfer after cleanup/move Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 430/480] pptp: fix pptp_xmit() error path Greg Kroah-Hartman ` (62 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Yi Zhang, Mohamed Khalfella, Hannes Reinecke, Daniel Wagner, Jens Axboe, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Mohamed Khalfella <mkhalfella@purestorage.com> [ Upstream commit 80f21806b8e34ae1e24c0fc6a0f0dfd9b055e130 ] Commit 528589947c180 ("nvmet: initialize discovery subsys after debugfs is initialized") changed nvmet_init() to initialize nvme discovery after "nvmet" debugfs directory is initialized. The change broke nvmet_exit() because discovery subsystem now depends on debugfs. Debugfs should be destroyed after discovery subsystem. Fix nvmet_exit() to do that. Reported-by: Yi Zhang <yi.zhang@redhat.com> Closes: https://lore.kernel.org/all/CAHj4cs96AfFQpyDKF_MdfJsnOEo=2V7dQgqjFv+k3t7H-=yGhA@mail.gmail.com/ Fixes: 528589947c180 ("nvmet: initialize discovery subsys after debugfs is initialized") Signed-off-by: Mohamed Khalfella <mkhalfella@purestorage.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Daniel Wagner <dwagner@suse.de> Link: https://lore.kernel.org/r/20250807053507.2794335-1-mkhalfella@purestorage.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/nvme/target/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nvme/target/core.c b/drivers/nvme/target/core.c index 82d0a0fdf912..90abc5c01377 100644 --- a/drivers/nvme/target/core.c +++ b/drivers/nvme/target/core.c @@ -1938,8 +1938,8 @@ static int __init nvmet_init(void) static void __exit nvmet_exit(void) { nvmet_exit_configfs(); - nvmet_exit_debugfs(); nvmet_exit_discovery(); + nvmet_exit_debugfs(); ida_destroy(&cntlid_ida); destroy_workqueue(nvmet_wq); destroy_workqueue(buffered_io_wq); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 430/480] pptp: fix pptp_xmit() error path 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (428 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 429/480] nvmet: exit debugfs after discovery subsystem exits Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 431/480] smb: client: return an error if rdma_connect does not return within 5 seconds Greg Kroah-Hartman ` (61 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, syzbot+27d7cfbc93457e472e00, Eric Dumazet, Jakub Kicinski, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Eric Dumazet <edumazet@google.com> [ Upstream commit ae633388cae349886f1a3cfb27aa092854b24c1b ] I accidentally added a bug in pptp_xmit() that syzbot caught for us. Only call ip_rt_put() if a route has been allocated. BUG: unable to handle page fault for address: ffffffffffffffdb PGD df3b067 P4D df3b067 PUD df3d067 PMD 0 Oops: Oops: 0002 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 6346 Comm: syz.0.336 Not tainted 6.16.0-next-20250804-syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:arch_atomic_add_return arch/x86/include/asm/atomic.h:85 [inline] RIP: 0010:raw_atomic_sub_return_release include/linux/atomic/atomic-arch-fallback.h:846 [inline] RIP: 0010:atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:327 [inline] RIP: 0010:__rcuref_put include/linux/rcuref.h:109 [inline] RIP: 0010:rcuref_put+0x172/0x210 include/linux/rcuref.h:173 Call Trace: <TASK> dst_release+0x24/0x1b0 net/core/dst.c:167 ip_rt_put include/net/route.h:285 [inline] pptp_xmit+0x14b/0x1a90 drivers/net/ppp/pptp.c:267 __ppp_channel_push+0xf2/0x1c0 drivers/net/ppp/ppp_generic.c:2166 ppp_channel_push+0x123/0x660 drivers/net/ppp/ppp_generic.c:2198 ppp_write+0x2b0/0x400 drivers/net/ppp/ppp_generic.c:544 vfs_write+0x27b/0xb30 fs/read_write.c:684 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: de9c4861fb42 ("pptp: ensure minimal skb length in pptp_xmit()") Reported-by: syzbot+27d7cfbc93457e472e00@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/689095a5.050a0220.1fc43d.0009.GAE@google.com/ Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20250807142146.2877060-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/net/ppp/pptp.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/net/ppp/pptp.c b/drivers/net/ppp/pptp.c index 4cd6f67bd5d3..90737cb71892 100644 --- a/drivers/net/ppp/pptp.c +++ b/drivers/net/ppp/pptp.c @@ -159,17 +159,17 @@ static int pptp_xmit(struct ppp_channel *chan, struct sk_buff *skb) int len; unsigned char *data; __u32 seq_recv; - struct rtable *rt = NULL; + struct rtable *rt; struct net_device *tdev; struct iphdr *iph; int max_headroom; if (sk_pppox(po)->sk_state & PPPOX_DEAD) - goto tx_error; + goto tx_drop; rt = pptp_route_output(po, &fl4); if (IS_ERR(rt)) - goto tx_error; + goto tx_drop; tdev = rt->dst.dev; @@ -265,6 +265,7 @@ static int pptp_xmit(struct ppp_channel *chan, struct sk_buff *skb) tx_error: ip_rt_put(rt); +tx_drop: kfree_skb(skb); return 1; } -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 431/480] smb: client: return an error if rdma_connect does not return within 5 seconds 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (429 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 430/480] pptp: fix pptp_xmit() error path Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 432/480] tools/power turbostat: Fix bogus SysWatt for forked program Greg Kroah-Hartman ` (60 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Steve French, Tom Talpey, Long Li, linux-cifs, samba-technical, Stefan Metzmacher, Steve French, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Stefan Metzmacher <metze@samba.org> [ Upstream commit 03537826f77f1c829d0593d211b38b9c876c1722 ] This matches the timeout for tcp connections. Cc: Steve French <smfrench@gmail.com> Cc: Tom Talpey <tom@talpey.com> Cc: Long Li <longli@microsoft.com> Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection") Signed-off-by: Stefan Metzmacher <metze@samba.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/smb/client/smbdirect.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/smb/client/smbdirect.c b/fs/smb/client/smbdirect.c index 47f2a6cc1c0c..60b160219f0a 100644 --- a/fs/smb/client/smbdirect.c +++ b/fs/smb/client/smbdirect.c @@ -1636,8 +1636,10 @@ static struct smbd_connection *_smbd_get_connection( goto rdma_connect_failed; } - wait_event_interruptible( - info->conn_wait, sc->status != SMBDIRECT_SOCKET_CONNECTING); + wait_event_interruptible_timeout( + info->conn_wait, + sc->status != SMBDIRECT_SOCKET_CONNECTING, + msecs_to_jiffies(RDMA_RESOLVE_TIMEOUT)); if (sc->status != SMBDIRECT_SOCKET_CONNECTED) { log_rdma_event(ERR, "rdma_connect failed port=%d\n", port); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 432/480] tools/power turbostat: Fix bogus SysWatt for forked program 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (430 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 431/480] smb: client: return an error if rdma_connect does not return within 5 seconds Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 433/480] nfsd: dont set the ctime on delegated atime updates Greg Kroah-Hartman ` (59 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Zhang Rui, Len Brown, Sasha Levin 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Zhang Rui <rui.zhang@intel.com> [ Upstream commit 44207567fa64e995d4f2ec2d45af4c947cb1a465 ] Similar to delta_cpu(), delta_platform() is called in turbostat main loop. This ensures accurate SysWatt readings in periodic monitoring mode $ sudo turbostat -S -q --show power -i 1 CoreTmp PkgTmp PkgWatt CorWatt GFXWatt RAMWatt PKG_% RAM_% SysWatt 60 61 6.21 1.13 0.16 0.00 0.00 0.00 13.07 58 61 6.00 1.07 0.18 0.00 0.00 0.00 12.75 58 61 5.74 1.05 0.17 0.00 0.00 0.00 12.22 58 60 6.27 1.11 0.24 0.00 0.00 0.00 13.55 However, delta_platform() is missing for forked program and causes bogus SysWatt reporting, $ sudo turbostat -S -q --show power sleep 1 1.004736 sec CoreTmp PkgTmp PkgWatt CorWatt GFXWatt RAMWatt PKG_% RAM_% SysWatt 57 58 6.05 1.02 0.16 0.00 0.00 0.00 0.03 Add missing delta_platform() for forked program. Fixes: e5f687b89bc2 ("tools/power turbostat: Add RAPL psys as a built-in counter") Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- tools/power/x86/turbostat/turbostat.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/power/x86/turbostat/turbostat.c b/tools/power/x86/turbostat/turbostat.c index 7a407694d221..444b6bfb4683 100644 --- a/tools/power/x86/turbostat/turbostat.c +++ b/tools/power/x86/turbostat/turbostat.c @@ -9593,6 +9593,7 @@ int fork_it(char **argv) timersub(&tv_odd, &tv_even, &tv_delta); if (for_all_cpus_2(delta_cpu, ODD_COUNTERS, EVEN_COUNTERS)) fprintf(outf, "%s: Counter reset detected\n", progname); + delta_platform(&platform_counters_odd, &platform_counters_even); compute_average(EVEN_COUNTERS); format_all_counters(EVEN_COUNTERS); -- 2.39.5 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 433/480] nfsd: dont set the ctime on delegated atime updates 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (431 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 432/480] tools/power turbostat: Fix bogus SysWatt for forked program Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 434/480] nfsd: avoid ref leak in nfsd_open_local_fh() Greg Kroah-Hartman ` (58 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Jeff Layton, Chuck Lever 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jeff Layton <jlayton@kernel.org> commit f9a348e0de19226fc3c7e81de7677d3fa2c4b2d8 upstream. Clients will typically precede a DELEGRETURN for a delegation with delegated timestamp with a SETATTR to set the timestamps on the server to match what the client has. knfsd implements this by using the nfsd_setattr() infrastructure, which will set ATTR_CTIME on any update that goes to notify_change(). This is problematic as it means that the client will get a spurious ctime update when updating the atime. POSIX unfortunately doesn't phrase it succinctly, but updating the atime due to reads should not update the ctime. In this case, the client is sending a SETATTR to update the atime on the server to match its latest value. The ctime should not be advanced in this case as that would incorrectly indicate a change to the inode. Fix this by not implicitly setting ATTR_CTIME when ATTR_DELEG is set in __nfsd_setattr(). The decoder for FATTR4_WORD2_TIME_DELEG_MODIFY already sets ATTR_CTIME, so this is sufficient to make it skip setting the ctime on atime-only updates. Fixes: 7e13f4f8d27d ("nfsd: handle delegated timestamps in SETATTR") Cc: stable@vger.kernel.org Signed-off-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- fs/nfsd/vfs.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/fs/nfsd/vfs.c +++ b/fs/nfsd/vfs.c @@ -466,7 +466,15 @@ static int __nfsd_setattr(struct dentry if (!iap->ia_valid) return 0; - iap->ia_valid |= ATTR_CTIME; + /* + * If ATTR_DELEG is set, then this is an update from a client that + * holds a delegation. If this is an update for only the atime, the + * ctime should not be changed. If the update contains the mtime + * too, then ATTR_CTIME should already be set. + */ + if (!(iap->ia_valid & ATTR_DELEG)) + iap->ia_valid |= ATTR_CTIME; + return notify_change(&nop_mnt_idmap, dentry, iap, NULL); } ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 434/480] nfsd: avoid ref leak in nfsd_open_local_fh() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (432 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 433/480] nfsd: dont set the ctime on delegated atime updates Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 435/480] sunrpc: fix handling of server side tls alerts Greg Kroah-Hartman ` (57 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Mike Snitzer, NeilBrown, Jeff Layton, Chuck Lever 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: NeilBrown <neil@brown.name> commit e5a73150776f18547ee685c9f6bfafe549714899 upstream. If two calls to nfsd_open_local_fh() race and both successfully call nfsd_file_acquire_local(), they will both get an extra reference to the net to accompany the file reference stored in *pnf. One of them will fail to store (using xchg()) the file reference in *pnf and will drop that reference but WON'T drop the accompanying reference to the net. This leak means that when the nfs server is shut down it will hang in nfsd_shutdown_net() waiting for &nn->nfsd_net_free_done. This patch adds the missing nfsd_net_put(). Reported-by: Mike Snitzer <snitzer@kernel.org> Fixes: e6f7e1487ab5 ("nfs_localio: simplify interface to nfsd for getting nfsd_file") Cc: stable@vger.kernel.org Signed-off-by: NeilBrown <neil@brown.name> Tested-by: Mike Snitzer <snitzer@kernel.org> Reviewed-by: Mike Snitzer <snitzer@kernel.org> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- fs/nfsd/localio.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/nfsd/localio.c b/fs/nfsd/localio.c index 4f6468eb2adf..cb237f1b902a 100644 --- a/fs/nfsd/localio.c +++ b/fs/nfsd/localio.c @@ -103,10 +103,11 @@ nfsd_open_local_fh(struct net *net, struct auth_domain *dom, if (nfsd_file_get(new) == NULL) goto again; /* - * Drop the ref we were going to install and the - * one we were going to return. + * Drop the ref we were going to install (both file and + * net) and the one we were going to return (only file). */ nfsd_file_put(localio); + nfsd_net_put(net); nfsd_file_put(localio); localio = new; } -- 2.50.1 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH 6.15 435/480] sunrpc: fix handling of server side tls alerts 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (433 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 434/480] nfsd: avoid ref leak in nfsd_open_local_fh() Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 436/480] perf/core: Preserve AUX buffer allocation failure result Greg Kroah-Hartman ` (56 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Scott Mayhew, Trond Myklebust, Olga Kornievskaia, Chuck Lever 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Olga Kornievskaia <okorniev@redhat.com> commit bee47cb026e762841f3faece47b51f985e215edb upstream. Scott Mayhew discovered a security exploit in NFS over TLS in tls_alert_recv() due to its assumption it can read data from the msg iterator's kvec.. kTLS implementation splits TLS non-data record payload between the control message buffer (which includes the type such as TLS aler or TLS cipher change) and the rest of the payload (say TLS alert's level/description) which goes into the msg payload buffer. This patch proposes to rework how control messages are setup and used by sock_recvmsg(). If no control message structure is setup, kTLS layer will read and process TLS data record types. As soon as it encounters a TLS control message, it would return an error. At that point, NFS can setup a kvec backed msg buffer and read in the control message such as a TLS alert. Msg iterator can advance the kvec pointer as a part of the copy process thus we need to revert the iterator before calling into the tls_alert_recv. Reported-by: Scott Mayhew <smayhew@redhat.com> Fixes: 5e052dda121e ("SUNRPC: Recognize control messages in server-side TCP socket code") Suggested-by: Trond Myklebust <trondmy@hammerspace.com> Cc: stable@vger.kernel.org Signed-off-by: Olga Kornievskaia <okorniev@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- net/sunrpc/svcsock.c | 43 +++++++++++++++++++++++++++++++++++-------- 1 file changed, 35 insertions(+), 8 deletions(-) --- a/net/sunrpc/svcsock.c +++ b/net/sunrpc/svcsock.c @@ -257,20 +257,47 @@ svc_tcp_sock_process_cmsg(struct socket } static int -svc_tcp_sock_recv_cmsg(struct svc_sock *svsk, struct msghdr *msg) +svc_tcp_sock_recv_cmsg(struct socket *sock, unsigned int *msg_flags) { union { struct cmsghdr cmsg; u8 buf[CMSG_SPACE(sizeof(u8))]; } u; - struct socket *sock = svsk->sk_sock; + u8 alert[2]; + struct kvec alert_kvec = { + .iov_base = alert, + .iov_len = sizeof(alert), + }; + struct msghdr msg = { + .msg_flags = *msg_flags, + .msg_control = &u, + .msg_controllen = sizeof(u), + }; + int ret; + + iov_iter_kvec(&msg.msg_iter, ITER_DEST, &alert_kvec, 1, + alert_kvec.iov_len); + ret = sock_recvmsg(sock, &msg, MSG_DONTWAIT); + if (ret > 0 && + tls_get_record_type(sock->sk, &u.cmsg) == TLS_RECORD_TYPE_ALERT) { + iov_iter_revert(&msg.msg_iter, ret); + ret = svc_tcp_sock_process_cmsg(sock, &msg, &u.cmsg, -EAGAIN); + } + return ret; +} + +static int +svc_tcp_sock_recvmsg(struct svc_sock *svsk, struct msghdr *msg) +{ int ret; + struct socket *sock = svsk->sk_sock; - msg->msg_control = &u; - msg->msg_controllen = sizeof(u); ret = sock_recvmsg(sock, msg, MSG_DONTWAIT); - if (unlikely(msg->msg_controllen != sizeof(u))) - ret = svc_tcp_sock_process_cmsg(sock, msg, &u.cmsg, ret); + if (msg->msg_flags & MSG_CTRUNC) { + msg->msg_flags &= ~(MSG_CTRUNC | MSG_EOR); + if (ret == 0 || ret == -EIO) + ret = svc_tcp_sock_recv_cmsg(sock, &msg->msg_flags); + } return ret; } @@ -321,7 +348,7 @@ static ssize_t svc_tcp_read_msg(struct s iov_iter_advance(&msg.msg_iter, seek); buflen -= seek; } - len = svc_tcp_sock_recv_cmsg(svsk, &msg); + len = svc_tcp_sock_recvmsg(svsk, &msg); if (len > 0) svc_flush_bvec(bvec, len, seek); @@ -1019,7 +1046,7 @@ static ssize_t svc_tcp_read_marker(struc iov.iov_base = ((char *)&svsk->sk_marker) + svsk->sk_tcplen; iov.iov_len = want; iov_iter_kvec(&msg.msg_iter, ITER_DEST, &iov, 1, want); - len = svc_tcp_sock_recv_cmsg(svsk, &msg); + len = svc_tcp_sock_recvmsg(svsk, &msg); if (len < 0) return len; svsk->sk_tcplen += len; ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 436/480] perf/core: Preserve AUX buffer allocation failure result 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (434 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 435/480] sunrpc: fix handling of server side tls alerts Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 437/480] perf/core: Dont leak AUX buffer refcount on allocation failure Greg Kroah-Hartman ` (55 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Thomas Gleixner, Lorenzo Stoakes 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Gleixner <tglx@linutronix.de> commit 54473e0ef849f44e5ee43e6d6746c27030c3825b upstream. A recent overhaul sets the return value to 0 unconditionally after the allocations, which causes reference count leaks and corrupts the user->vm accounting. Preserve the AUX buffer allocation failure return value, so that the subsequent code works correctly. Fixes: 0983593f32c4 ("perf/core: Lift event->mmap_mutex in perf_mmap()") Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- kernel/events/core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -7052,6 +7052,7 @@ static int perf_mmap(struct file *file, perf_event_update_time(event); perf_event_init_userpage(event); perf_event_update_userpage(event); + ret = 0; } else { ret = rb_alloc_aux(rb, event, vma->vm_pgoff, nr_pages, event->attr.aux_watermark, flags); @@ -7059,8 +7060,6 @@ static int perf_mmap(struct file *file, rb->aux_mmap_locked = extra; } - ret = 0; - unlock: if (!ret) { atomic_long_add(user_extra, &user->locked_vm); ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 437/480] perf/core: Dont leak AUX buffer refcount on allocation failure 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (435 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 436/480] perf/core: Preserve AUX buffer allocation failure result Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 438/480] perf/core: Exit early on perf_mmap() fail Greg Kroah-Hartman ` (54 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Thomas Gleixner, Lorenzo Stoakes 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Gleixner <tglx@linutronix.de> commit 5468c0fbccbb9d156522c50832244a8b722374fb upstream. Failure of the AUX buffer allocation leaks the reference count. Set the reference count to 1 only when the allocation succeeds. Fixes: 45bfb2e50471 ("perf/core: Add AUX area to ring buffer for raw data streams") Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- kernel/events/core.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -6988,8 +6988,6 @@ static int perf_mmap(struct file *file, ret = 0; goto unlock; } - - atomic_set(&rb->aux_mmap_count, 1); } user_lock_limit = sysctl_perf_event_mlock >> (PAGE_SHIFT - 10); @@ -7056,8 +7054,10 @@ static int perf_mmap(struct file *file, } else { ret = rb_alloc_aux(rb, event, vma->vm_pgoff, nr_pages, event->attr.aux_watermark, flags); - if (!ret) + if (!ret) { + atomic_set(&rb->aux_mmap_count, 1); rb->aux_mmap_locked = extra; + } } unlock: @@ -7067,6 +7067,7 @@ unlock: atomic_inc(&event->mmap_count); } else if (rb) { + /* AUX allocation failed */ atomic_dec(&rb->mmap_count); } aux_unlock: ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 438/480] perf/core: Exit early on perf_mmap() fail 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (436 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 437/480] perf/core: Dont leak AUX buffer refcount on allocation failure Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 439/480] perf/core: Handle buffer mapping fail correctly in perf_mmap() Greg Kroah-Hartman ` (53 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Thomas Gleixner, Lorenzo Stoakes 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Gleixner <tglx@linutronix.de> commit 07091aade394f690e7b655578140ef84d0e8d7b0 upstream. When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak. Return early on failure to prevent that. Fixes: 1e0fb9ec679c ("perf/core: Add pmu callbacks to track event mapping and unmapping") Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- kernel/events/core.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -7075,6 +7075,9 @@ aux_unlock: mutex_unlock(aux_mutex); mutex_unlock(&event->mmap_mutex); + if (ret) + return ret; + /* * Since pinned accounting is per vm we cannot allow fork() to copy our * vma. @@ -7082,8 +7085,7 @@ aux_unlock: vm_flags_set(vma, VM_DONTCOPY | VM_DONTEXPAND | VM_DONTDUMP); vma->vm_ops = &perf_mmap_vmops; - if (!ret) - ret = map_range(rb, vma); + ret = map_range(rb, vma); if (!ret && event->pmu->event_mapped) event->pmu->event_mapped(event, vma->vm_mm); ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 439/480] perf/core: Handle buffer mapping fail correctly in perf_mmap() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (437 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 438/480] perf/core: Exit early on perf_mmap() fail Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 440/480] perf/core: Prevent VMA split of buffer mappings Greg Kroah-Hartman ` (52 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Thomas Gleixner, Lorenzo Stoakes 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Gleixner <tglx@linutronix.de> commit f74b9f4ba63ffdf597aaaa6cad7e284cb8e04820 upstream. After successful allocation of a buffer or a successful attachment to an existing buffer perf_mmap() tries to map the buffer read only into the page table. If that fails, the already set up page table entries are zapped, but the other perf specific side effects of that failure are not handled. The calling code just cleans up the VMA and does not invoke perf_mmap_close(). This leaks reference counts, corrupts user->vm accounting and also results in an unbalanced invocation of event::event_mapped(). Cure this by moving the event::event_mapped() invocation before the map_range() call so that on map_range() failure perf_mmap_close() can be invoked without causing an unbalanced event::event_unmapped() call. perf_mmap_close() undoes the reference counts and eventually frees buffers. Fixes: b709eb872e19 ("perf/core: map pages in advance") Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- kernel/events/core.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -7085,11 +7085,19 @@ aux_unlock: vm_flags_set(vma, VM_DONTCOPY | VM_DONTEXPAND | VM_DONTDUMP); vma->vm_ops = &perf_mmap_vmops; - ret = map_range(rb, vma); - - if (!ret && event->pmu->event_mapped) + if (event->pmu->event_mapped) event->pmu->event_mapped(event, vma->vm_mm); + /* + * Try to map it into the page table. On fail, invoke + * perf_mmap_close() to undo the above, as the callsite expects + * full cleanup in this case and therefore does not invoke + * vmops::close(). + */ + ret = map_range(rb, vma); + if (ret) + perf_mmap_close(vma); + return ret; } ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 440/480] perf/core: Prevent VMA split of buffer mappings 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (438 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 439/480] perf/core: Handle buffer mapping fail correctly in perf_mmap() Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 441/480] selftests/perf_events: Add a mmap() correctness test Greg Kroah-Hartman ` (51 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Thomas Gleixner, Lorenzo Stoakes, Arnaldo Carvalho de Melo, Vlastimil Babka, zdi-disclosures 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Gleixner <tglx@linutronix.de> commit b024d7b56c77191cde544f838debb7f8451cd0d6 upstream. The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct. Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks. As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented. Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL. That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping. Fixes: 45bfb2e50471 ("perf/core: Add AUX area to ring buffer for raw data streams") Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-27504 Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- kernel/events/core.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -6790,10 +6790,20 @@ static vm_fault_t perf_mmap_pfn_mkwrite( return vmf->pgoff == 0 ? 0 : VM_FAULT_SIGBUS; } +static int perf_mmap_may_split(struct vm_area_struct *vma, unsigned long addr) +{ + /* + * Forbid splitting perf mappings to prevent refcount leaks due to + * the resulting non-matching offsets and sizes. See open()/close(). + */ + return -EINVAL; +} + static const struct vm_operations_struct perf_mmap_vmops = { .open = perf_mmap_open, .close = perf_mmap_close, /* non mergeable */ .pfn_mkwrite = perf_mmap_pfn_mkwrite, + .may_split = perf_mmap_may_split, }; static int map_range(struct perf_buffer *rb, struct vm_area_struct *vma) ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 441/480] selftests/perf_events: Add a mmap() correctness test 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (439 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 440/480] perf/core: Prevent VMA split of buffer mappings Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 442/480] net/packet: fix a race in packet_set_ring() and packet_notifier() Greg Kroah-Hartman ` (50 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Lorenzo Stoakes, Thomas Gleixner 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> commit 084d2ac4030c5919e85bba1f4af26e33491469cb upstream. Exercise various mmap(), munmap() and mremap() invocations, which might cause a perf buffer mapping to be split or truncated. To avoid hard coding the perf event and having dependencies on architectures and configuration options, scan through event types in sysfs and try to open them. On success, try to mmap() and if that succeeds try to mmap() the AUX buffer. In case that no AUX buffer supporting event is found, only test the base buffer mapping. If no mappable event is found or permissions are not sufficient, skip the tests. Reserve a PROT_NONE region for both rb and aux tests to allow testing the case where mremap unmaps beyond the end of a mapped VMA to prevent it from unmapping unrelated mappings. Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Co-developed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- tools/testing/selftests/perf_events/.gitignore | 1 tools/testing/selftests/perf_events/Makefile | 2 tools/testing/selftests/perf_events/mmap.c | 236 +++++++++++++++++++++++++ 3 files changed, 238 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/perf_events/mmap.c --- a/tools/testing/selftests/perf_events/.gitignore +++ b/tools/testing/selftests/perf_events/.gitignore @@ -2,3 +2,4 @@ sigtrap_threads remove_on_exec watermark_signal +mmap --- a/tools/testing/selftests/perf_events/Makefile +++ b/tools/testing/selftests/perf_events/Makefile @@ -2,5 +2,5 @@ CFLAGS += -Wl,-no-as-needed -Wall $(KHDR_INCLUDES) LDFLAGS += -lpthread -TEST_GEN_PROGS := sigtrap_threads remove_on_exec watermark_signal +TEST_GEN_PROGS := sigtrap_threads remove_on_exec watermark_signal mmap include ../lib.mk --- /dev/null +++ b/tools/testing/selftests/perf_events/mmap.c @@ -0,0 +1,236 @@ +// SPDX-License-Identifier: GPL-2.0-only +#define _GNU_SOURCE + +#include <dirent.h> +#include <sched.h> +#include <stdbool.h> +#include <stdio.h> +#include <unistd.h> + +#include <sys/ioctl.h> +#include <sys/mman.h> +#include <sys/syscall.h> +#include <sys/types.h> + +#include <linux/perf_event.h> + +#include "../kselftest_harness.h" + +#define RB_SIZE 0x3000 +#define AUX_SIZE 0x10000 +#define AUX_OFFS 0x4000 + +#define HOLE_SIZE 0x1000 + +/* Reserve space for rb, aux with space for shrink-beyond-vma testing. */ +#define REGION_SIZE (2 * RB_SIZE + 2 * AUX_SIZE) +#define REGION_AUX_OFFS (2 * RB_SIZE) + +#define MAP_BASE 1 +#define MAP_AUX 2 + +#define EVENT_SRC_DIR "/sys/bus/event_source/devices" + +FIXTURE(perf_mmap) +{ + int fd; + void *ptr; + void *region; +}; + +FIXTURE_VARIANT(perf_mmap) +{ + bool aux; + unsigned long ptr_size; +}; + +FIXTURE_VARIANT_ADD(perf_mmap, rb) +{ + .aux = false, + .ptr_size = RB_SIZE, +}; + +FIXTURE_VARIANT_ADD(perf_mmap, aux) +{ + .aux = true, + .ptr_size = AUX_SIZE, +}; + +static bool read_event_type(struct dirent *dent, __u32 *type) +{ + char typefn[512]; + FILE *fp; + int res; + + snprintf(typefn, sizeof(typefn), "%s/%s/type", EVENT_SRC_DIR, dent->d_name); + fp = fopen(typefn, "r"); + if (!fp) + return false; + + res = fscanf(fp, "%u", type); + fclose(fp); + return res > 0; +} + +FIXTURE_SETUP(perf_mmap) +{ + struct perf_event_attr attr = { + .size = sizeof(attr), + .disabled = 1, + .exclude_kernel = 1, + .exclude_hv = 1, + }; + struct perf_event_attr attr_ok = {}; + unsigned int eacces = 0, map = 0; + struct perf_event_mmap_page *rb; + struct dirent *dent; + void *aux, *region; + DIR *dir; + + self->ptr = NULL; + + dir = opendir(EVENT_SRC_DIR); + if (!dir) + SKIP(return, "perf not available."); + + region = mmap(NULL, REGION_SIZE, PROT_NONE, MAP_ANON | MAP_PRIVATE, -1, 0); + ASSERT_NE(region, MAP_FAILED); + self->region = region; + + // Try to find a suitable event on this system + while ((dent = readdir(dir))) { + int fd; + + if (!read_event_type(dent, &attr.type)) + continue; + + fd = syscall(SYS_perf_event_open, &attr, 0, -1, -1, 0); + if (fd < 0) { + if (errno == EACCES) + eacces++; + continue; + } + + // Check whether the event supports mmap() + rb = mmap(region, RB_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_FIXED, fd, 0); + if (rb == MAP_FAILED) { + close(fd); + continue; + } + + if (!map) { + // Save the event in case that no AUX capable event is found + attr_ok = attr; + map = MAP_BASE; + } + + if (!variant->aux) + continue; + + rb->aux_offset = AUX_OFFS; + rb->aux_size = AUX_SIZE; + + // Check whether it supports a AUX buffer + aux = mmap(region + REGION_AUX_OFFS, AUX_SIZE, PROT_READ | PROT_WRITE, + MAP_SHARED | MAP_FIXED, fd, AUX_OFFS); + if (aux == MAP_FAILED) { + munmap(rb, RB_SIZE); + close(fd); + continue; + } + + attr_ok = attr; + map = MAP_AUX; + munmap(aux, AUX_SIZE); + munmap(rb, RB_SIZE); + close(fd); + break; + } + closedir(dir); + + if (!map) { + if (!eacces) + SKIP(return, "No mappable perf event found."); + else + SKIP(return, "No permissions for perf_event_open()"); + } + + self->fd = syscall(SYS_perf_event_open, &attr_ok, 0, -1, -1, 0); + ASSERT_NE(self->fd, -1); + + rb = mmap(region, RB_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_FIXED, self->fd, 0); + ASSERT_NE(rb, MAP_FAILED); + + if (!variant->aux) { + self->ptr = rb; + return; + } + + if (map != MAP_AUX) + SKIP(return, "No AUX event found."); + + rb->aux_offset = AUX_OFFS; + rb->aux_size = AUX_SIZE; + aux = mmap(region + REGION_AUX_OFFS, AUX_SIZE, PROT_READ | PROT_WRITE, + MAP_SHARED | MAP_FIXED, self->fd, AUX_OFFS); + ASSERT_NE(aux, MAP_FAILED); + self->ptr = aux; +} + +FIXTURE_TEARDOWN(perf_mmap) +{ + ASSERT_EQ(munmap(self->region, REGION_SIZE), 0); + if (self->fd != -1) + ASSERT_EQ(close(self->fd), 0); +} + +TEST_F(perf_mmap, remap) +{ + void *tmp, *ptr = self->ptr; + unsigned long size = variant->ptr_size; + + // Test the invalid remaps + ASSERT_EQ(mremap(ptr, size, HOLE_SIZE, MREMAP_MAYMOVE), MAP_FAILED); + ASSERT_EQ(mremap(ptr + HOLE_SIZE, size, HOLE_SIZE, MREMAP_MAYMOVE), MAP_FAILED); + ASSERT_EQ(mremap(ptr + size - HOLE_SIZE, HOLE_SIZE, size, MREMAP_MAYMOVE), MAP_FAILED); + // Shrink the end of the mapping such that we only unmap past end of the VMA, + // which should succeed and poke a hole into the PROT_NONE region + ASSERT_NE(mremap(ptr + size - HOLE_SIZE, size, HOLE_SIZE, MREMAP_MAYMOVE), MAP_FAILED); + + // Remap the whole buffer to a new address + tmp = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS, -1, 0); + ASSERT_NE(tmp, MAP_FAILED); + + // Try splitting offset 1 hole size into VMA, this should fail + ASSERT_EQ(mremap(ptr + HOLE_SIZE, size - HOLE_SIZE, size - HOLE_SIZE, + MREMAP_MAYMOVE | MREMAP_FIXED, tmp), MAP_FAILED); + // Remapping the whole thing should succeed fine + ptr = mremap(ptr, size, size, MREMAP_MAYMOVE | MREMAP_FIXED, tmp); + ASSERT_EQ(ptr, tmp); + ASSERT_EQ(munmap(tmp, size), 0); +} + +TEST_F(perf_mmap, unmap) +{ + unsigned long size = variant->ptr_size; + + // Try to poke holes into the mappings + ASSERT_NE(munmap(self->ptr, HOLE_SIZE), 0); + ASSERT_NE(munmap(self->ptr + HOLE_SIZE, HOLE_SIZE), 0); + ASSERT_NE(munmap(self->ptr + size - HOLE_SIZE, HOLE_SIZE), 0); +} + +TEST_F(perf_mmap, map) +{ + unsigned long size = variant->ptr_size; + + // Try to poke holes into the mappings by mapping anonymous memory over it + ASSERT_EQ(mmap(self->ptr, HOLE_SIZE, PROT_READ | PROT_WRITE, + MAP_PRIVATE | MAP_ANON | MAP_FIXED, -1, 0), MAP_FAILED); + ASSERT_EQ(mmap(self->ptr + HOLE_SIZE, HOLE_SIZE, PROT_READ | PROT_WRITE, + MAP_PRIVATE | MAP_ANON | MAP_FIXED, -1, 0), MAP_FAILED); + ASSERT_EQ(mmap(self->ptr + size - HOLE_SIZE, HOLE_SIZE, PROT_READ | PROT_WRITE, + MAP_PRIVATE | MAP_ANON | MAP_FIXED, -1, 0), MAP_FAILED); +} + +TEST_HARNESS_MAIN ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 442/480] net/packet: fix a race in packet_set_ring() and packet_notifier() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (440 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 441/480] selftests/perf_events: Add a mmap() correctness test Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 443/480] vsock: Do not allow binding to VMADDR_PORT_ANY Greg Kroah-Hartman ` (49 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Quang Le, Willem de Bruijn, Jakub Kicinski 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Quang Le <quanglex97@gmail.com> commit 01d3c8417b9c1b884a8a981a3b886da556512f36 upstream. When packet_set_ring() releases po->bind_lock, another thread can run packet_notifier() and process an NETDEV_UP event. This race and the fix are both similar to that of commit 15fe076edea7 ("net/packet: fix a race in packet_bind() and packet_notifier()"). There too the packet_notifier NETDEV_UP event managed to run while a po->bind_lock critical section had to be temporarily released. And the fix was similarly to temporarily set po->num to zero to keep the socket unhooked until the lock is retaken. The po->bind_lock in packet_set_ring and packet_notifier precede the introduction of git history. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Quang Le <quanglex97@gmail.com> Signed-off-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20250801175423.2970334-1-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- net/packet/af_packet.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -4573,10 +4573,10 @@ static int packet_set_ring(struct sock * spin_lock(&po->bind_lock); was_running = packet_sock_flag(po, PACKET_SOCK_RUNNING); num = po->num; - if (was_running) { - WRITE_ONCE(po->num, 0); + WRITE_ONCE(po->num, 0); + if (was_running) __unregister_prot_hook(sk, false); - } + spin_unlock(&po->bind_lock); synchronize_net(); @@ -4608,10 +4608,10 @@ static int packet_set_ring(struct sock * mutex_unlock(&po->pg_vec_lock); spin_lock(&po->bind_lock); - if (was_running) { - WRITE_ONCE(po->num, num); + WRITE_ONCE(po->num, num); + if (was_running) register_prot_hook(sk); - } + spin_unlock(&po->bind_lock); if (pg_vec && (po->tp_version > TPACKET_V2)) { /* Because we don't support block-based V3 on tx-ring */ ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 443/480] vsock: Do not allow binding to VMADDR_PORT_ANY 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (441 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 442/480] net/packet: fix a race in packet_set_ring() and packet_notifier() Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 444/480] ksmbd: fix null pointer dereference error in generate_encryptionkey Greg Kroah-Hartman ` (48 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Budimir Markovic, Stefano Garzarella, Jakub Kicinski 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Budimir Markovic <markovicbudimir@gmail.com> commit aba0c94f61ec05315fa7815d21aefa4c87f6a9f4 upstream. It is possible for a vsock to autobind to VMADDR_PORT_ANY. This can cause a use-after-free when a connection is made to the bound socket. The socket returned by accept() also has port VMADDR_PORT_ANY but is not on the list of unbound sockets. Binding it will result in an extra refcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keep the binding until socket destruction). Modify the check in __vsock_bind_connectible() to also prevent binding to VMADDR_PORT_ANY. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Reported-by: Budimir Markovic <markovicbudimir@gmail.com> Signed-off-by: Budimir Markovic <markovicbudimir@gmail.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Link: https://patch.msgid.link/20250807041811.678-1-markovicbudimir@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- net/vmw_vsock/af_vsock.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/net/vmw_vsock/af_vsock.c +++ b/net/vmw_vsock/af_vsock.c @@ -689,7 +689,8 @@ static int __vsock_bind_connectible(stru unsigned int i; for (i = 0; i < MAX_PORT_RETRIES; i++) { - if (port <= LAST_RESERVED_PORT) + if (port == VMADDR_PORT_ANY || + port <= LAST_RESERVED_PORT) port = LAST_RESERVED_PORT + 1; new_addr.svm_port = port++; ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 444/480] ksmbd: fix null pointer dereference error in generate_encryptionkey 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (442 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 443/480] vsock: Do not allow binding to VMADDR_PORT_ANY Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 445/480] ksmbd: fix Preauh_HashValue race condition Greg Kroah-Hartman ` (47 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Namjae Jeon, Steve French, zdi-disclosures 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Namjae Jeon <linkinjeon@kernel.org> commit 9b493ab6f35178afd8d619800df9071992f715de upstream. If client send two session setups with krb5 authenticate to ksmbd, null pointer dereference error in generate_encryptionkey could happen. sess->Preauth_HashValue is set to NULL if session is valid. So this patch skip generate encryption key if session is valid. Cc: stable@vger.kernel.org Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-27654 Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- fs/smb/server/smb2pdu.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -1621,11 +1621,24 @@ static int krb5_authenticate(struct ksmb rsp->SecurityBufferLength = cpu_to_le16(out_len); - if ((conn->sign || server_conf.enforced_signing) || + /* + * If session state is SMB2_SESSION_VALID, We can assume + * that it is reauthentication. And the user/password + * has been verified, so return it here. + */ + if (sess->state == SMB2_SESSION_VALID) { + if (conn->binding) + goto binding_session; + return 0; + } + + if ((rsp->SessionFlags != SMB2_SESSION_FLAG_IS_GUEST_LE && + (conn->sign || server_conf.enforced_signing)) || (req->SecurityMode & SMB2_NEGOTIATE_SIGNING_REQUIRED)) sess->sign = true; - if (smb3_encryption_negotiated(conn)) { + if (smb3_encryption_negotiated(conn) && + !(req->Flags & SMB2_SESSION_REQ_FLAG_BINDING)) { retval = conn->ops->generate_encryptionkey(conn, sess); if (retval) { ksmbd_debug(SMB, @@ -1638,6 +1651,7 @@ static int krb5_authenticate(struct ksmb sess->sign = false; } +binding_session: if (conn->dialect >= SMB30_PROT_ID) { chann = lookup_chann_list(sess, conn); if (!chann) { ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 445/480] ksmbd: fix Preauh_HashValue race condition 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (443 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 444/480] ksmbd: fix null pointer dereference error in generate_encryptionkey Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 446/480] ksmbd: fix corrupted mtime and ctime in smb2_open Greg Kroah-Hartman ` (46 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Namjae Jeon, Steve French, zdi-disclosures 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Namjae Jeon <linkinjeon@kernel.org> commit 44a3059c4c8cc635a1fb2afd692d0730ca1ba4b6 upstream. If client send multiple session setup requests to ksmbd, Preauh_HashValue race condition could happen. There is no need to free sess->Preauh_HashValue at session setup phase. It can be freed together with session at connection termination phase. Cc: stable@vger.kernel.org Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-27661 Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- fs/smb/server/smb2pdu.c | 4 ---- 1 file changed, 4 deletions(-) --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -1847,8 +1847,6 @@ int smb2_sess_setup(struct ksmbd_work *w ksmbd_conn_set_good(conn); sess->state = SMB2_SESSION_VALID; } - kfree(sess->Preauth_HashValue); - sess->Preauth_HashValue = NULL; } else if (conn->preferred_auth_mech == KSMBD_AUTH_NTLMSSP) { if (negblob->MessageType == NtLmNegotiate) { rc = ntlm_negotiate(work, negblob, negblob_len, rsp); @@ -1875,8 +1873,6 @@ int smb2_sess_setup(struct ksmbd_work *w kfree(preauth_sess); } } - kfree(sess->Preauth_HashValue); - sess->Preauth_HashValue = NULL; } else { pr_info_ratelimited("Unknown NTLMSSP message type : 0x%x\n", le32_to_cpu(negblob->MessageType)); ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 446/480] ksmbd: fix corrupted mtime and ctime in smb2_open 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (444 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 445/480] ksmbd: fix Preauh_HashValue race condition Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 447/480] smb: client: fix netns refcount leak after net_passive changes Greg Kroah-Hartman ` (45 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, David Howells, Namjae Jeon, Steve French 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Namjae Jeon <linkinjeon@kernel.org> commit 4f8ff9486fd94b9d6a4932f2aefb9f2fc3bd0cf6 upstream. If STATX_BASIC_STATS flags are not given as an argument to vfs_getattr, It can not get ctime and mtime in kstat. This causes a problem showing mtime and ctime outdated from cifs.ko. File: /xfstest.test/foo Size: 4096 Blocks: 8 IO Block: 1048576 regular file Device: 0,65 Inode: 2033391 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:cifs_t:s0 Access: 2025-07-23 22:15:30.136051900 +0100 Modify: 1970-01-01 01:00:00.000000000 +0100 Change: 1970-01-01 01:00:00.000000000 +0100 Birth: 2025-07-23 22:15:30.136051900 +0100 Cc: stable@vger.kernel.org Reported-by: David Howells <dhowells@redhat.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- fs/smb/server/vfs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/smb/server/vfs.c +++ b/fs/smb/server/vfs.c @@ -546,7 +546,8 @@ int ksmbd_vfs_getattr(const struct path { int err; - err = vfs_getattr(path, stat, STATX_BTIME, AT_STATX_SYNC_AS_STAT); + err = vfs_getattr(path, stat, STATX_BASIC_STATS | STATX_BTIME, + AT_STATX_SYNC_AS_STAT); if (err) pr_err("getattr failed, err %d\n", err); return err; ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 447/480] smb: client: fix netns refcount leak after net_passive changes 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (445 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 446/480] ksmbd: fix corrupted mtime and ctime in smb2_open Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 448/480] smb: client: set symlink type as native for POSIX mounts Greg Kroah-Hartman ` (44 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Kuniyuki Iwashima, Enzo Matsumiya, Wang Zhaolong, Steve French 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Wang Zhaolong <wangzhaolong@huaweicloud.com> commit 59b33fab4ca4d7dacc03367082777627e05d0323 upstream. After commit 5c70eb5c593d ("net: better track kernel sockets lifetime"), kernel sockets now use net_passive reference counting. However, commit 95d2b9f693ff ("Revert "smb: client: fix TCP timers deadlock after rmmod"") restored the manual socket refcount manipulation without adapting to this new mechanism, causing a memory leak. The issue can be reproduced by[1]: 1. Creating a network namespace 2. Mounting and Unmounting CIFS within the namespace 3. Deleting the namespace Some memory leaks may appear after a period of time following step 3. unreferenced object 0xffff9951419f6b00 (size 256): comm "ip", pid 447, jiffies 4294692389 (age 14.730s) hex dump (first 32 bytes): 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 80 77 c2 44 51 99 ff ff .........w.DQ... backtrace: __kmem_cache_alloc_node+0x30e/0x3d0 __kmalloc+0x52/0x120 net_alloc_generic+0x1d/0x30 copy_net_ns+0x86/0x200 create_new_namespaces+0x117/0x300 unshare_nsproxy_namespaces+0x60/0xa0 ksys_unshare+0x148/0x360 __x64_sys_unshare+0x12/0x20 do_syscall_64+0x59/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ... unreferenced object 0xffff9951442e7500 (size 32): comm "mount.cifs", pid 475, jiffies 4294693782 (age 13.343s) hex dump (first 32 bytes): 40 c5 38 46 51 99 ff ff 18 01 96 42 51 99 ff ff @.8FQ......BQ... 01 00 00 00 6f 00 c5 07 6f 00 d8 07 00 00 00 00 ....o...o....... backtrace: __kmem_cache_alloc_node+0x30e/0x3d0 kmalloc_trace+0x2a/0x90 ref_tracker_alloc+0x8e/0x1d0 sk_alloc+0x18c/0x1c0 inet_create+0xf1/0x370 __sock_create+0xd7/0x1e0 generic_ip_connect+0x1d4/0x5a0 [cifs] cifs_get_tcp_session+0x5d0/0x8a0 [cifs] cifs_mount_get_session+0x47/0x1b0 [cifs] dfs_mount_share+0xfa/0xa10 [cifs] cifs_mount+0x68/0x2b0 [cifs] cifs_smb3_do_mount+0x10b/0x760 [cifs] smb3_get_tree+0x112/0x2e0 [cifs] vfs_get_tree+0x29/0xf0 path_mount+0x2d4/0xa00 __se_sys_mount+0x165/0x1d0 Root cause: When creating kernel sockets, sk_alloc() calls net_passive_inc() for sockets with sk_net_refcnt=0. The CIFS code manually converts kernel sockets to user sockets by setting sk_net_refcnt=1, but doesn't call the corresponding net_passive_dec(). This creates an imbalance in the net_passive counter, which prevents the network namespace from being destroyed when its last user reference is dropped. As a result, the entire namespace and all its associated resources remain allocated. Timeline of patches leading to this issue: - commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") in v6.12 fixed the original netns UAF by manually managing socket refcounts - commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock after rmmod") in v6.13 attempted to use kernel sockets but introduced TCP timer issues - commit 5c70eb5c593d ("net: better track kernel sockets lifetime") in v6.14-rc5 introduced the net_passive mechanism with sk_net_refcnt_upgrade() for proper socket conversion - commit 95d2b9f693ff ("Revert "smb: client: fix TCP timers deadlock after rmmod"") in v6.15-rc3 reverted to manual refcount management without adapting to the new net_passive changes Fix this by using sk_net_refcnt_upgrade() which properly handles the net_passive counter when converting kernel sockets to user sockets. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220343 [1] Fixes: 95d2b9f693ff ("Revert "smb: client: fix TCP timers deadlock after rmmod"") Cc: stable@vger.kernel.org Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Enzo Matsumiya <ematsumiya@suse.de> Signed-off-by: Wang Zhaolong <wangzhaolong@huaweicloud.com> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- fs/smb/client/connect.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) --- a/fs/smb/client/connect.c +++ b/fs/smb/client/connect.c @@ -3362,18 +3362,15 @@ generic_ip_connect(struct TCP_Server_Inf struct net *net = cifs_net_ns(server); struct sock *sk; - rc = __sock_create(net, sfamily, SOCK_STREAM, - IPPROTO_TCP, &server->ssocket, 1); + rc = sock_create_kern(net, sfamily, SOCK_STREAM, + IPPROTO_TCP, &server->ssocket); if (rc < 0) { cifs_server_dbg(VFS, "Error %d creating socket\n", rc); return rc; } sk = server->ssocket->sk; - __netns_tracker_free(net, &sk->ns_tracker, false); - sk->sk_net_refcnt = 1; - get_net_track(net, &sk->ns_tracker, GFP_KERNEL); - sock_inuse_add(net, 1); + sk_net_refcnt_upgrade(sk); /* BB other socket options to set KEEPALIVE, NODELAY? */ cifs_dbg(FYI, "Socket created\n"); ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 448/480] smb: client: set symlink type as native for POSIX mounts 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (446 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 447/480] smb: client: fix netns refcount leak after net_passive changes Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 449/480] smb: client: default to nonativesocket under " Greg Kroah-Hartman ` (43 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, linux-cifs, Ralph Boehme, David Howells, Matthew Richardson, Paulo Alcantara (Red Hat), Steve French 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Paulo Alcantara <pc@manguebit.org> commit a967e758f8e9d8ce5ef096743393df5e6e51644b upstream. SMB3.1.1 POSIX mounts require symlinks to be created natively with IO_REPARSE_TAG_SYMLINK reparse point. Cc: linux-cifs@vger.kernel.org Cc: Ralph Boehme <slow@samba.org> Cc: David Howells <dhowells@redhat.com> Cc: <stable@vger.kernel.org> Reported-by: Matthew Richardson <m.richardson@ed.ac.uk> Closes: https://marc.info/?i=1124e7cd-6a46-40a6-9f44-b7664a66654b@ed.ac.uk Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- fs/smb/client/cifsfs.c | 2 +- fs/smb/client/fs_context.c | 18 ------------------ fs/smb/client/fs_context.h | 18 +++++++++++++++++- fs/smb/client/link.c | 11 +++-------- fs/smb/client/reparse.c | 2 +- 5 files changed, 22 insertions(+), 29 deletions(-) --- a/fs/smb/client/cifsfs.c +++ b/fs/smb/client/cifsfs.c @@ -724,7 +724,7 @@ cifs_show_options(struct seq_file *s, st else seq_puts(s, ",nativesocket"); seq_show_option(s, "symlink", - cifs_symlink_type_str(get_cifs_symlink_type(cifs_sb))); + cifs_symlink_type_str(cifs_symlink_type(cifs_sb))); seq_printf(s, ",rsize=%u", cifs_sb->ctx->rsize); seq_printf(s, ",wsize=%u", cifs_sb->ctx->wsize); --- a/fs/smb/client/fs_context.c +++ b/fs/smb/client/fs_context.c @@ -1851,24 +1851,6 @@ static int smb3_fs_context_parse_param(s return -EINVAL; } -enum cifs_symlink_type get_cifs_symlink_type(struct cifs_sb_info *cifs_sb) -{ - if (cifs_sb->ctx->symlink_type == CIFS_SYMLINK_TYPE_DEFAULT) { - if (cifs_sb->ctx->mfsymlinks) - return CIFS_SYMLINK_TYPE_MFSYMLINKS; - else if (cifs_sb->ctx->sfu_emul) - return CIFS_SYMLINK_TYPE_SFU; - else if (cifs_sb->ctx->linux_ext && !cifs_sb->ctx->no_linux_ext) - return CIFS_SYMLINK_TYPE_UNIX; - else if (cifs_sb->ctx->reparse_type != CIFS_REPARSE_TYPE_NONE) - return CIFS_SYMLINK_TYPE_NATIVE; - else - return CIFS_SYMLINK_TYPE_NONE; - } else { - return cifs_sb->ctx->symlink_type; - } -} - int smb3_init_fs_context(struct fs_context *fc) { struct smb3_fs_context *ctx; --- a/fs/smb/client/fs_context.h +++ b/fs/smb/client/fs_context.h @@ -341,7 +341,23 @@ struct smb3_fs_context { extern const struct fs_parameter_spec smb3_fs_parameters[]; -extern enum cifs_symlink_type get_cifs_symlink_type(struct cifs_sb_info *cifs_sb); +static inline enum cifs_symlink_type cifs_symlink_type(struct cifs_sb_info *cifs_sb) +{ + bool posix = cifs_sb_master_tcon(cifs_sb)->posix_extensions; + + if (cifs_sb->ctx->symlink_type != CIFS_SYMLINK_TYPE_DEFAULT) + return cifs_sb->ctx->symlink_type; + + if (cifs_sb->ctx->mfsymlinks) + return CIFS_SYMLINK_TYPE_MFSYMLINKS; + else if (cifs_sb->ctx->sfu_emul) + return CIFS_SYMLINK_TYPE_SFU; + else if (cifs_sb->ctx->linux_ext && !cifs_sb->ctx->no_linux_ext) + return posix ? CIFS_SYMLINK_TYPE_NATIVE : CIFS_SYMLINK_TYPE_UNIX; + else if (cifs_sb->ctx->reparse_type != CIFS_REPARSE_TYPE_NONE) + return CIFS_SYMLINK_TYPE_NATIVE; + return CIFS_SYMLINK_TYPE_NONE; +} extern int smb3_init_fs_context(struct fs_context *fc); extern void smb3_cleanup_fs_context_contents(struct smb3_fs_context *ctx); --- a/fs/smb/client/link.c +++ b/fs/smb/client/link.c @@ -606,14 +606,7 @@ cifs_symlink(struct mnt_idmap *idmap, st /* BB what if DFS and this volume is on different share? BB */ rc = -EOPNOTSUPP; - switch (get_cifs_symlink_type(cifs_sb)) { - case CIFS_SYMLINK_TYPE_DEFAULT: - /* should not happen, get_cifs_symlink_type() resolves the default */ - break; - - case CIFS_SYMLINK_TYPE_NONE: - break; - + switch (cifs_symlink_type(cifs_sb)) { case CIFS_SYMLINK_TYPE_UNIX: #ifdef CONFIG_CIFS_ALLOW_INSECURE_LEGACY if (pTcon->unix_ext) { @@ -653,6 +646,8 @@ cifs_symlink(struct mnt_idmap *idmap, st goto symlink_exit; } break; + default: + break; } if (rc == 0) { --- a/fs/smb/client/reparse.c +++ b/fs/smb/client/reparse.c @@ -38,7 +38,7 @@ int smb2_create_reparse_symlink(const un struct dentry *dentry, struct cifs_tcon *tcon, const char *full_path, const char *symname) { - switch (get_cifs_symlink_type(CIFS_SB(inode->i_sb))) { + switch (cifs_symlink_type(CIFS_SB(inode->i_sb))) { case CIFS_SYMLINK_TYPE_NATIVE: return create_native_symlink(xid, inode, dentry, tcon, full_path, symname); case CIFS_SYMLINK_TYPE_NFS: ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 449/480] smb: client: default to nonativesocket under POSIX mounts 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (447 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 448/480] smb: client: set symlink type as native for POSIX mounts Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 450/480] ksmbd: limit repeated connections from clients with the same IP Greg Kroah-Hartman ` (42 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, linux-cifs, Ralph Boehme, David Howells, Matthew Richardson, Paulo Alcantara (Red Hat), Steve French 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Paulo Alcantara <pc@manguebit.org> commit 6b445309eec2bc0594f3e24c7777aeef891d386e upstream. SMB3.1.1 POSIX mounts require sockets to be created with NFS reparse points. Cc: linux-cifs@vger.kernel.org Cc: Ralph Boehme <slow@samba.org> Cc: David Howells <dhowells@redhat.com> Cc: <stable@vger.kernel.org> Reported-by: Matthew Richardson <m.richardson@ed.ac.uk> Closes: https://marc.info/?i=1124e7cd-6a46-40a6-9f44-b7664a66654b@ed.ac.uk Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- fs/smb/client/fs_context.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/smb/client/fs_context.c +++ b/fs/smb/client/fs_context.c @@ -1674,6 +1674,7 @@ static int smb3_fs_context_parse_param(s pr_warn_once("conflicting posix mount options specified\n"); ctx->linux_ext = 1; ctx->no_linux_ext = 0; + ctx->nonativesocket = 1; /* POSIX mounts use NFS style reparse points */ } break; case Opt_nocase: ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 450/480] ksmbd: limit repeated connections from clients with the same IP 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (448 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 449/480] smb: client: default to nonativesocket under " Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:50 ` [PATCH 6.15 451/480] smb: server: Fix extension string in ksmbd_extract_shortname() Greg Kroah-Hartman ` (41 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, tianshuo han, Namjae Jeon, Steve French 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Namjae Jeon <linkinjeon@kernel.org> commit e6bb9193974059ddbb0ce7763fa3882bd60d4dc3 upstream. Repeated connections from clients with the same IP address may exhaust the max connections and prevent other normal client connections. This patch limit repeated connections from clients with the same IP. Reported-by: tianshuo han <hantianshuo233@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- fs/smb/server/connection.h | 1 + fs/smb/server/transport_tcp.c | 17 +++++++++++++++++ 2 files changed, 18 insertions(+) --- a/fs/smb/server/connection.h +++ b/fs/smb/server/connection.h @@ -46,6 +46,7 @@ struct ksmbd_conn { struct mutex srv_mutex; int status; unsigned int cli_cap; + __be32 inet_addr; char *request_buf; struct ksmbd_transport *transport; struct nls_table *local_nls; --- a/fs/smb/server/transport_tcp.c +++ b/fs/smb/server/transport_tcp.c @@ -87,6 +87,7 @@ static struct tcp_transport *alloc_trans return NULL; } + conn->inet_addr = inet_sk(client_sk->sk)->inet_daddr; conn->transport = KSMBD_TRANS(t); KSMBD_TRANS(t)->conn = conn; KSMBD_TRANS(t)->ops = &ksmbd_tcp_transport_ops; @@ -230,6 +231,8 @@ static int ksmbd_kthread_fn(void *p) { struct socket *client_sk = NULL; struct interface *iface = (struct interface *)p; + struct inet_sock *csk_inet; + struct ksmbd_conn *conn; int ret; while (!kthread_should_stop()) { @@ -248,6 +251,20 @@ static int ksmbd_kthread_fn(void *p) continue; } + /* + * Limits repeated connections from clients with the same IP. + */ + csk_inet = inet_sk(client_sk->sk); + down_read(&conn_list_lock); + list_for_each_entry(conn, &conn_list, conns_list) + if (csk_inet->inet_daddr == conn->inet_addr) { + ret = -EAGAIN; + break; + } + up_read(&conn_list_lock); + if (ret == -EAGAIN) + continue; + if (server_conf.max_connections && atomic_inc_return(&active_num_conn) >= server_conf.max_connections) { pr_info_ratelimited("Limit the maximum number of connections(%u)\n", ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 451/480] smb: server: Fix extension string in ksmbd_extract_shortname() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (449 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 450/480] ksmbd: limit repeated connections from clients with the same IP Greg Kroah-Hartman @ 2025-08-12 17:50 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 452/480] USB: serial: option: add Foxconn T99W709 Greg Kroah-Hartman ` (40 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:50 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Thorsten Blum, Namjae Jeon, Steve French 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thorsten Blum <thorsten.blum@linux.dev> commit 8e7d178d06e8937454b6d2f2811fa6a15656a214 upstream. In ksmbd_extract_shortname(), strscpy() is incorrectly called with the length of the source string (excluding the NUL terminator) rather than the size of the destination buffer. This results in "__" being copied to 'extension' rather than "___" (two underscores instead of three). Use the destination buffer size instead to ensure that the string "___" (three underscores) is copied correctly. Cc: stable@vger.kernel.org Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- fs/smb/server/smb_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/smb/server/smb_common.c +++ b/fs/smb/server/smb_common.c @@ -515,7 +515,7 @@ int ksmbd_extract_shortname(struct ksmbd p = strrchr(longname, '.'); if (p == longname) { /*name starts with a dot*/ - strscpy(extension, "___", strlen("___")); + strscpy(extension, "___", sizeof(extension)); } else { if (p) { p++; ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 452/480] USB: serial: option: add Foxconn T99W709 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (450 preceding siblings ...) 2025-08-12 17:50 ` [PATCH 6.15 451/480] smb: server: Fix extension string in ksmbd_extract_shortname() Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 453/480] Bluetooth: btusb: Add USB ID 3625:010b for TP-LINK Archer TX10UB Nano Greg Kroah-Hartman ` (39 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Slark Xiao, Johan Hovold 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Slark Xiao <slark_xiao@163.com> commit ad1244e1ce18f8c1a5ebad8074bfcf10eacb0311 upstream. T99W709 is designed based on MTK T300(5G redcap) chip. There are 7 serial ports to be enumerated: AP_LOG, GNSS, AP_META, AT, MD_META, NPT, DBG. RSVD(5) for ADB port. test evidence as below: T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 7 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e15f Rev=00.01 S: Manufacturer=MediaTek Inc. S: Product=USB DATA CARD S: SerialNumber=355511220000399 C: #Ifs=10 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim I: If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I: If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs I: If#=0x6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x9 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option Signed-off-by: Slark Xiao <slark_xiao@163.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/usb/serial/option.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/usb/serial/option.c +++ b/drivers/usb/serial/option.c @@ -2346,6 +2346,8 @@ static const struct usb_device_id option .driver_info = RSVD(3) }, { USB_DEVICE_INTERFACE_CLASS(0x0489, 0xe145, 0xff), /* Foxconn T99W651 RNDIS */ .driver_info = RSVD(5) | RSVD(6) }, + { USB_DEVICE_INTERFACE_CLASS(0x0489, 0xe15f, 0xff), /* Foxconn T99W709 */ + .driver_info = RSVD(5) }, { USB_DEVICE_INTERFACE_CLASS(0x0489, 0xe167, 0xff), /* Foxconn T99W640 MBIM */ .driver_info = RSVD(3) }, { USB_DEVICE(0x1508, 0x1001), /* Fibocom NL668 (IOT version) */ ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 453/480] Bluetooth: btusb: Add USB ID 3625:010b for TP-LINK Archer TX10UB Nano 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (451 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 452/480] USB: serial: option: add Foxconn T99W709 Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 454/480] net: usbnet: Avoid potential RCU stall on LINK_CHANGE event Greg Kroah-Hartman ` (38 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Zenm Chen, Luiz Augusto von Dentz 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Zenm Chen <zenmchen@gmail.com> commit d9da920233ec85af8b9c87154f2721a7dc4623f5 upstream. Add USB ID 3625:010b for TP-LINK Archer TX10UB Nano which is based on a Realtek RTL8851BU chip. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 9 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=3625 ProdID=010b Rev= 0.00 S: Manufacturer=Realtek S: Product=802.11ax WLAN Adapter S: SerialNumber=00e04c000001 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 8 Cls=ff(vend.) Sub=ff Prot=ff Driver=rtl8851bu E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0c(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Cc: stable@vger.kernel.org Signed-off-by: Zenm Chen <zenmchen@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/bluetooth/btusb.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -516,6 +516,10 @@ static const struct usb_device_id quirks { USB_DEVICE(0x0bda, 0xb850), .driver_info = BTUSB_REALTEK }, { USB_DEVICE(0x13d3, 0x3600), .driver_info = BTUSB_REALTEK }, + /* Realtek 8851BU Bluetooth devices */ + { USB_DEVICE(0x3625, 0x010b), .driver_info = BTUSB_REALTEK | + BTUSB_WIDEBAND_SPEECH }, + /* Realtek 8852AE Bluetooth devices */ { USB_DEVICE(0x0bda, 0x2852), .driver_info = BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 454/480] net: usbnet: Avoid potential RCU stall on LINK_CHANGE event 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (452 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 453/480] Bluetooth: btusb: Add USB ID 3625:010b for TP-LINK Archer TX10UB Nano Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 455/480] net: usbnet: Fix the wrong netif_carrier_on() call Greg Kroah-Hartman ` (37 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, John Ernberg, Jakub Kicinski 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: John Ernberg <john.ernberg@actia.se> commit 0d9cfc9b8cb17dbc29a98792d36ec39a1cf1395f upstream. The Gemalto Cinterion PLS83-W modem (cdc_ether) is emitting confusing link up and down events when the WWAN interface is activated on the modem-side. Interrupt URBs will in consecutive polls grab: * Link Connected * Link Disconnected * Link Connected Where the last Connected is then a stable link state. When the system is under load this may cause the unlink_urbs() work in __handle_link_change() to not complete before the next usbnet_link_change() call turns the carrier on again, allowing rx_submit() to queue new SKBs. In that event the URB queue is filled faster than it can drain, ending up in a RCU stall: rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 0-.... } 33108 jiffies s: 201 root: 0x1/. rcu: blocking rcu_node structures (internal RCU debug): Sending NMI from CPU 1 to CPUs 0: NMI backtrace for cpu 0 Call trace: arch_local_irq_enable+0x4/0x8 local_bh_enable+0x18/0x20 __netdev_alloc_skb+0x18c/0x1cc rx_submit+0x68/0x1f8 [usbnet] rx_alloc_submit+0x4c/0x74 [usbnet] usbnet_bh+0x1d8/0x218 [usbnet] usbnet_bh_tasklet+0x10/0x18 [usbnet] tasklet_action_common+0xa8/0x110 tasklet_action+0x2c/0x34 handle_softirqs+0x2cc/0x3a0 __do_softirq+0x10/0x18 ____do_softirq+0xc/0x14 call_on_irq_stack+0x24/0x34 do_softirq_own_stack+0x18/0x20 __irq_exit_rcu+0xa8/0xb8 irq_exit_rcu+0xc/0x30 el1_interrupt+0x34/0x48 el1h_64_irq_handler+0x14/0x1c el1h_64_irq+0x68/0x6c _raw_spin_unlock_irqrestore+0x38/0x48 xhci_urb_dequeue+0x1ac/0x45c [xhci_hcd] unlink1+0xd4/0xdc [usbcore] usb_hcd_unlink_urb+0x70/0xb0 [usbcore] usb_unlink_urb+0x24/0x44 [usbcore] unlink_urbs.constprop.0.isra.0+0x64/0xa8 [usbnet] __handle_link_change+0x34/0x70 [usbnet] usbnet_deferred_kevent+0x1c0/0x320 [usbnet] process_scheduled_works+0x2d0/0x48c worker_thread+0x150/0x1dc kthread+0xd8/0xe8 ret_from_fork+0x10/0x20 Get around the problem by delaying the carrier on to the scheduled work. This needs a new flag to keep track of the necessary action. The carrier ok check cannot be removed as it remains required for the LINK_RESET event flow. Fixes: 4b49f58fff00 ("usbnet: handle link change") Cc: stable@vger.kernel.org Signed-off-by: John Ernberg <john.ernberg@actia.se> Link: https://patch.msgid.link/20250723102526.1305339-1-john.ernberg@actia.se Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/net/usb/usbnet.c | 11 ++++++++--- include/linux/usb/usbnet.h | 1 + 2 files changed, 9 insertions(+), 3 deletions(-) --- a/drivers/net/usb/usbnet.c +++ b/drivers/net/usb/usbnet.c @@ -1122,6 +1122,9 @@ static void __handle_link_change(struct * tx queue is stopped by netcore after link becomes off */ } else { + if (test_and_clear_bit(EVENT_LINK_CARRIER_ON, &dev->flags)) + netif_carrier_on(dev->net); + /* submitting URBs for reading packets */ tasklet_schedule(&dev->bh); } @@ -2009,10 +2012,12 @@ EXPORT_SYMBOL(usbnet_manage_power); void usbnet_link_change(struct usbnet *dev, bool link, bool need_reset) { /* update link after link is reseted */ - if (link && !need_reset) - netif_carrier_on(dev->net); - else + if (link && !need_reset) { + set_bit(EVENT_LINK_CARRIER_ON, &dev->flags); + } else { + clear_bit(EVENT_LINK_CARRIER_ON, &dev->flags); netif_carrier_off(dev->net); + } if (need_reset && link) usbnet_defer_kevent(dev, EVENT_LINK_RESET); --- a/include/linux/usb/usbnet.h +++ b/include/linux/usb/usbnet.h @@ -76,6 +76,7 @@ struct usbnet { # define EVENT_LINK_CHANGE 11 # define EVENT_SET_RX_MODE 12 # define EVENT_NO_IP_ALIGN 13 +# define EVENT_LINK_CARRIER_ON 14 /* This one is special, as it indicates that the device is going away * there are cyclic dependencies between tasklet, timer and bh * that must be broken ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 455/480] net: usbnet: Fix the wrong netif_carrier_on() call 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (453 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 454/480] net: usbnet: Avoid potential RCU stall on LINK_CHANGE event Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 456/480] x86/sev: Evict cache lines during SNP memory validation Greg Kroah-Hartman ` (36 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Armando Budianto, Simon Horman, Linus Torvalds, Ammar Faizi 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ammar Faizi <ammarfaizi2@gnuweeb.org> commit 8466d393700f9ccef68134d3349f4e0a087679b9 upstream. The commit referenced in the Fixes tag causes usbnet to malfunction (identified via git bisect). Post-commit, my external RJ45 LAN cable fails to connect. Linus also reported the same issue after pulling that commit. The code has a logic error: netif_carrier_on() is only called when the link is already on. Fix this by moving the netif_carrier_on() call outside the if-statement entirely. This ensures it is always called when EVENT_LINK_CARRIER_ON is set and properly clears it regardless of the link state. Cc: stable@vger.kernel.org Cc: Armando Budianto <sprite@gnuweeb.org> Reviewed-by: Simon Horman <horms@kernel.org> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/all/CAHk-=wjqL4uF0MG_c8+xHX1Vv8==sPYQrtzbdA3kzi96284nuQ@mail.gmail.com Closes: https://lore.kernel.org/netdev/CAHk-=wjKh8X4PT_mU1kD4GQrbjivMfPn-_hXa6han_BTDcXddw@mail.gmail.com Closes: https://lore.kernel.org/netdev/0752dee6-43d6-4e1f-81d2-4248142cccd2@gnuweeb.org Fixes: 0d9cfc9b8cb1 ("net: usbnet: Avoid potential RCU stall on LINK_CHANGE event") Signed-off-by: Ammar Faizi <ammarfaizi2@gnuweeb.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/net/usb/usbnet.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/net/usb/usbnet.c +++ b/drivers/net/usb/usbnet.c @@ -1113,6 +1113,9 @@ static void __handle_link_change(struct if (!test_bit(EVENT_DEV_OPEN, &dev->flags)) return; + if (test_and_clear_bit(EVENT_LINK_CARRIER_ON, &dev->flags)) + netif_carrier_on(dev->net); + if (!netif_carrier_ok(dev->net)) { /* kill URBs for reading packets to save bus bandwidth */ unlink_urbs(dev, &dev->rxq); @@ -1122,9 +1125,6 @@ static void __handle_link_change(struct * tx queue is stopped by netcore after link becomes off */ } else { - if (test_and_clear_bit(EVENT_LINK_CARRIER_ON, &dev->flags)) - netif_carrier_on(dev->net); - /* submitting URBs for reading packets */ tasklet_schedule(&dev->bh); } ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 456/480] x86/sev: Evict cache lines during SNP memory validation 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (454 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 455/480] net: usbnet: Fix the wrong netif_carrier_on() call Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 457/480] ALSA: intel_hdmi: Fix off-by-one error in __hdmi_lpe_audio_probe() Greg Kroah-Hartman ` (35 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Michael Roth, Tom Lendacky, Borislav Petkov (AMD), Thomas Gleixner 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Tom Lendacky <thomas.lendacky@amd.com> Commit 7b306dfa326f70114312b320d083b21fa9481e1e upstream. An SNP cache coherency vulnerability requires a cache line eviction mitigation when validating memory after a page state change to private. The specific mitigation is to touch the first and last byte of each 4K page that is being validated. There is no need to perform the mitigation when performing a page state change to shared and rescinding validation. CPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit that, when set, indicates that the software mitigation for this vulnerability is not needed. Implement the mitigation and invoke it when validating memory (making it private) and the COHERENCY_SFW_NO bit is not set, indicating the SNP guest is vulnerable. Co-developed-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- arch/x86/boot/cpuflags.c | 13 ++++++++++ arch/x86/coco/sev/shared.c | 46 +++++++++++++++++++++++++++++++++++++ arch/x86/include/asm/cpufeatures.h | 1 arch/x86/kernel/cpu/scattered.c | 1 4 files changed, 61 insertions(+) --- a/arch/x86/boot/cpuflags.c +++ b/arch/x86/boot/cpuflags.c @@ -106,5 +106,18 @@ void get_cpuflags(void) cpuid(0x80000001, &ignored, &ignored, &cpu.flags[6], &cpu.flags[1]); } + + if (max_amd_level >= 0x8000001f) { + u32 ebx; + + /* + * The X86_FEATURE_COHERENCY_SFW_NO feature bit is in + * the virtualization flags entry (word 8) and set by + * scattered.c, so the bit needs to be explicitly set. + */ + cpuid(0x8000001f, &ignored, &ebx, &ignored, &ignored); + if (ebx & BIT(31)) + set_bit(X86_FEATURE_COHERENCY_SFW_NO, cpu.flags); + } } } --- a/arch/x86/coco/sev/shared.c +++ b/arch/x86/coco/sev/shared.c @@ -1254,6 +1254,24 @@ static void svsm_pval_terminate(struct s __pval_terminate(pfn, action, page_size, ret, svsm_ret); } +static inline void sev_evict_cache(void *va, int npages) +{ + volatile u8 val __always_unused; + u8 *bytes = va; + int page_idx; + + /* + * For SEV guests, a read from the first/last cache-lines of a 4K page + * using the guest key is sufficient to cause a flush of all cache-lines + * associated with that 4K page without incurring all the overhead of a + * full CLFLUSH sequence. + */ + for (page_idx = 0; page_idx < npages; page_idx++) { + val = bytes[page_idx * PAGE_SIZE]; + val = bytes[page_idx * PAGE_SIZE + PAGE_SIZE - 1]; + } +} + static void __head svsm_pval_4k_page(unsigned long paddr, bool validate) { struct svsm_pvalidate_call *pc; @@ -1307,6 +1325,13 @@ static void __head pvalidate_4k_page(uns if (ret) sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_PVALIDATE); } + + /* + * If validating memory (making it private) and affected by the + * cache-coherency vulnerability, perform the cache eviction mitigation. + */ + if (validate && !has_cpuflag(X86_FEATURE_COHERENCY_SFW_NO)) + sev_evict_cache((void *)vaddr, 1); } static void pval_pages(struct snp_psc_desc *desc) @@ -1491,10 +1516,31 @@ static void svsm_pval_pages(struct snp_p static void pvalidate_pages(struct snp_psc_desc *desc) { + struct psc_entry *e; + unsigned int i; + if (snp_vmpl) svsm_pval_pages(desc); else pval_pages(desc); + + /* + * If not affected by the cache-coherency vulnerability there is no need + * to perform the cache eviction mitigation. + */ + if (cpu_feature_enabled(X86_FEATURE_COHERENCY_SFW_NO)) + return; + + for (i = 0; i <= desc->hdr.end_entry; i++) { + e = &desc->entries[i]; + + /* + * If validating memory (making it private) perform the cache + * eviction mitigation. + */ + if (e->operation == SNP_PAGE_STATE_PRIVATE) + sev_evict_cache(pfn_to_kaddr(e->gfn), e->pagesize ? 512 : 1); + } } static int vmgexit_psc(struct ghcb *ghcb, struct snp_psc_desc *desc) --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -218,6 +218,7 @@ #define X86_FEATURE_FLEXPRIORITY ( 8*32+ 1) /* "flexpriority" Intel FlexPriority */ #define X86_FEATURE_EPT ( 8*32+ 2) /* "ept" Intel Extended Page Table */ #define X86_FEATURE_VPID ( 8*32+ 3) /* "vpid" Intel Virtual Processor ID */ +#define X86_FEATURE_COHERENCY_SFW_NO ( 8*32+ 4) /* SNP cache coherency software work around not needed */ #define X86_FEATURE_VMMCALL ( 8*32+15) /* "vmmcall" Prefer VMMCALL to VMCALL */ #define X86_FEATURE_XENPV ( 8*32+16) /* Xen paravirtual guest */ --- a/arch/x86/kernel/cpu/scattered.c +++ b/arch/x86/kernel/cpu/scattered.c @@ -47,6 +47,7 @@ static const struct cpuid_bit cpuid_bits { X86_FEATURE_PROC_FEEDBACK, CPUID_EDX, 11, 0x80000007, 0 }, { X86_FEATURE_AMD_FAST_CPPC, CPUID_EDX, 15, 0x80000007, 0 }, { X86_FEATURE_MBA, CPUID_EBX, 6, 0x80000008, 0 }, + { X86_FEATURE_COHERENCY_SFW_NO, CPUID_EBX, 31, 0x8000001f, 0 }, { X86_FEATURE_SMBA, CPUID_EBX, 2, 0x80000020, 0 }, { X86_FEATURE_BMEC, CPUID_EBX, 3, 0x80000020, 0 }, { X86_FEATURE_TSA_SQ_NO, CPUID_ECX, 1, 0x80000021, 0 }, ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 457/480] ALSA: intel_hdmi: Fix off-by-one error in __hdmi_lpe_audio_probe() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (455 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 456/480] x86/sev: Evict cache lines during SNP memory validation Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 458/480] ALSA: scarlett2: Add retry on -EPROTO from scarlett2_usb_tx() Greg Kroah-Hartman ` (34 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Thorsten Blum, Takashi Iwai 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thorsten Blum <thorsten.blum@linux.dev> commit 8cbe564974248ee980562be02f2b1912769562c7 upstream. In __hdmi_lpe_audio_probe(), strscpy() is incorrectly called with the length of the source string (excluding the NUL terminator) rather than the size of the destination buffer. This results in one character less being copied from 'card->shortname' to 'pcm->name'. Use the destination buffer size instead to ensure the card name is copied correctly. Cc: stable@vger.kernel.org Fixes: 75b1a8f9d62e ("ALSA: Convert strlcpy to strscpy when return value is unused") Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20250805234156.60294-1-thorsten.blum@linux.dev Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- sound/x86/intel_hdmi_audio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/sound/x86/intel_hdmi_audio.c +++ b/sound/x86/intel_hdmi_audio.c @@ -1767,7 +1767,7 @@ static int __hdmi_lpe_audio_probe(struct /* setup private data which can be retrieved when required */ pcm->private_data = ctx; pcm->info_flags = 0; - strscpy(pcm->name, card->shortname, strlen(card->shortname)); + strscpy(pcm->name, card->shortname, sizeof(pcm->name)); /* setup the ops for playback */ snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, &had_pcm_ops); ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 458/480] ALSA: scarlett2: Add retry on -EPROTO from scarlett2_usb_tx() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (456 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 457/480] ALSA: intel_hdmi: Fix off-by-one error in __hdmi_lpe_audio_probe() Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 459/480] ALSA: hda/realtek - Fix mute LED for HP Victus 16-r1xxx Greg Kroah-Hartman ` (33 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Geoffrey D. Bennett, Takashi Iwai 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Geoffrey D. Bennett <g@b4.vu> commit 8a15ca0ca51399b652b1bbb23b590b220cf03d62 upstream. During communication with Focusrite Scarlett Gen 2/3/4 USB audio interfaces, -EPROTO is sometimes returned from scarlett2_usb_tx(), snd_usb_ctl_msg() which can cause initialisation and control operations to fail intermittently. This patch adds up to 5 retries in scarlett2_usb(), with a delay starting at 5ms and doubling each time. This follows the same approach as the fix for usb_set_interface() in endpoint.c (commit f406005e162b ("ALSA: usb-audio: Add retry on -EPROTO from usb_set_interface()")), which resolved similar -EPROTO issues during device initialisation, and is the same approach as in fcp.c:fcp_usb(). Fixes: 9e4d5c1be21f ("ALSA: usb-audio: Scarlett Gen 2 mixer interface") Closes: https://github.com/geoffreybennett/linux-fcp/issues/41 Cc: stable@vger.kernel.org Signed-off-by: Geoffrey D. Bennett <g@b4.vu> Link: https://patch.msgid.link/aIdDO6ld50WQwNim@m.b4.vu Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- sound/usb/mixer_scarlett2.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/sound/usb/mixer_scarlett2.c +++ b/sound/usb/mixer_scarlett2.c @@ -2351,6 +2351,8 @@ static int scarlett2_usb( struct scarlett2_usb_packet *req, *resp = NULL; size_t req_buf_size = struct_size(req, data, req_size); size_t resp_buf_size = struct_size(resp, data, resp_size); + int retries = 0; + const int max_retries = 5; int err; req = kmalloc(req_buf_size, GFP_KERNEL); @@ -2374,10 +2376,15 @@ static int scarlett2_usb( if (req_size) memcpy(req->data, req_data, req_size); +retry: err = scarlett2_usb_tx(dev, private->bInterfaceNumber, req, req_buf_size); if (err != req_buf_size) { + if (err == -EPROTO && ++retries <= max_retries) { + msleep(5 * (1 << (retries - 1))); + goto retry; + } usb_audio_err( mixer->chip, "%s USB request result cmd %x was %d\n", ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 459/480] ALSA: hda/realtek - Fix mute LED for HP Victus 16-r1xxx 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (457 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 458/480] ALSA: scarlett2: Add retry on -EPROTO from scarlett2_usb_tx() Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 460/480] ALSA: hda/realtek - Fix mute LED for HP Victus 16-s0xxx Greg Kroah-Hartman ` (32 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Edip Hazuri, Takashi Iwai 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Edip Hazuri <edip@medip.dev> commit bd7814a4c0fd883894bdf9fe5eda24c9df826e4c upstream. The mute led on this laptop is using ALC245 but requires a quirk to work This patch enables the existing quirk for the device. Tested on Victus 16-r1xxx Laptop. The LED behaviour works as intended. Cc: <stable@vger.kernel.org> Signed-off-by: Edip Hazuri <edip@medip.dev> Link: https://patch.msgid.link/20250725151436.51543-2-edip@medip.dev Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -10851,6 +10851,7 @@ static const struct hda_quirk alc269_fix SND_PCI_QUIRK(0x103c, 0x8c91, "HP EliteBook 660", ALC236_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8c96, "HP", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), SND_PCI_QUIRK(0x103c, 0x8c97, "HP ZBook", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), + SND_PCI_QUIRK(0x103c, 0x8c99, "HP Victus 16-r1xxx (MB 8C99)", ALC245_FIXUP_HP_MUTE_LED_COEFBIT), SND_PCI_QUIRK(0x103c, 0x8c9c, "HP Victus 16-s1xxx (MB 8C9C)", ALC245_FIXUP_HP_MUTE_LED_COEFBIT), SND_PCI_QUIRK(0x103c, 0x8ca1, "HP ZBook Power", ALC236_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8ca2, "HP ZBook Power", ALC236_FIXUP_HP_GPIO_LED), ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 460/480] ALSA: hda/realtek - Fix mute LED for HP Victus 16-s0xxx 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (458 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 459/480] ALSA: hda/realtek - Fix mute LED for HP Victus 16-r1xxx Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 461/480] ALSA: hda/realtek - Fix mute LED for HP Victus 16-d1xxx (MB 8A26) Greg Kroah-Hartman ` (31 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Edip Hazuri, Takashi Iwai 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Edip Hazuri <edip@medip.dev> commit 956048a3cd9d2575032e2c7ca62803677357ae18 upstream. The mute led on this laptop is using ALC245 but requires a quirk to work This patch enables the existing quirk for the device. Tested on Victus 16-S0063NT Laptop. The LED behaviour works as intended. Cc: <stable@vger.kernel.org> Signed-off-by: Edip Hazuri <edip@medip.dev> Link: https://patch.msgid.link/20250729181848.24432-2-edip@medip.dev Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -10799,6 +10799,7 @@ static const struct hda_quirk alc269_fix SND_PCI_QUIRK(0x103c, 0x8bbe, "HP Victus 16-r0xxx (MB 8BBE)", ALC245_FIXUP_HP_MUTE_LED_COEFBIT), SND_PCI_QUIRK(0x103c, 0x8bc8, "HP Victus 15-fa1xxx", ALC245_FIXUP_HP_MUTE_LED_COEFBIT), SND_PCI_QUIRK(0x103c, 0x8bcd, "HP Omen 16-xd0xxx", ALC245_FIXUP_HP_MUTE_LED_V1_COEFBIT), + SND_PCI_QUIRK(0x103c, 0x8bd4, "HP Victus 16-s0xxx (MB 8BD4)", ALC245_FIXUP_HP_MUTE_LED_COEFBIT), SND_PCI_QUIRK(0x103c, 0x8bdd, "HP Envy 17", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x103c, 0x8bde, "HP Envy 17", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x103c, 0x8bdf, "HP Envy 15", ALC287_FIXUP_CS35L41_I2C_2), ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 461/480] ALSA: hda/realtek - Fix mute LED for HP Victus 16-d1xxx (MB 8A26) 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (459 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 460/480] ALSA: hda/realtek - Fix mute LED for HP Victus 16-s0xxx Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 462/480] platform/x86/intel/pmt: fix a crashlog NULL pointer access Greg Kroah-Hartman ` (30 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Edip Hazuri, Takashi Iwai 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Edip Hazuri <edip@medip.dev> commit a9dec0963187d05725369156a5e0e14cd3487bfb upstream. My friend have Victus 16-d1xxx with board ID 8A26, the existing quirk for Victus 16-d1xxx wasn't working because of different board ID Tested on Victus 16-d1015nt Laptop. The LED behaviour works as intended. Cc: <stable@vger.kernel.org> Signed-off-by: Edip Hazuri <edip@medip.dev> Link: https://patch.msgid.link/20250729181848.24432-4-edip@medip.dev Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -10741,6 +10741,7 @@ static const struct hda_quirk alc269_fix SND_PCI_QUIRK(0x103c, 0x8a0f, "HP Pavilion 14-ec1xxx", ALC287_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8a20, "HP Laptop 15s-fq5xxx", ALC236_FIXUP_HP_MUTE_LED_COEFBIT2), SND_PCI_QUIRK(0x103c, 0x8a25, "HP Victus 16-d1xxx (MB 8A25)", ALC245_FIXUP_HP_MUTE_LED_COEFBIT), + SND_PCI_QUIRK(0x103c, 0x8a26, "HP Victus 16-d1xxx (MB 8A26)", ALC245_FIXUP_HP_MUTE_LED_COEFBIT), SND_PCI_QUIRK(0x103c, 0x8a28, "HP Envy 13", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x103c, 0x8a29, "HP Envy 15", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x103c, 0x8a2a, "HP Envy 15", ALC287_FIXUP_CS35L41_I2C_2), ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 462/480] platform/x86/intel/pmt: fix a crashlog NULL pointer access 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (460 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 461/480] ALSA: hda/realtek - Fix mute LED for HP Victus 16-d1xxx (MB 8A26) Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 463/480] x86/fpu: Delay instruction pointer fixup until after warning Greg Kroah-Hartman ` (29 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, David E. Box, Tejas Upadhyay, Michael J. Ruhl, Ilpo Järvinen 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Michael J. Ruhl <michael.j.ruhl@intel.com> commit 54d5cd4719c5e87f33d271c9ac2e393147d934f8 upstream. Usage of the intel_pmt_read() for binary sysfs, requires a pcidev. The current use of the endpoint value is only valid for telemetry endpoint usage. Without the ep, the crashlog usage causes the following NULL pointer exception: BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:intel_pmt_read+0x3b/0x70 [pmt_class] Code: Call Trace: <TASK> ? sysfs_kf_bin_read+0xc0/0xe0 kernfs_fop_read_iter+0xac/0x1a0 vfs_read+0x26d/0x350 ksys_read+0x6b/0xe0 __x64_sys_read+0x1d/0x30 x64_sys_call+0x1bc8/0x1d70 do_syscall_64+0x6d/0x110 Augment struct intel_pmt_entry with a pointer to the pcidev to avoid the NULL pointer exception. Fixes: 045a513040cc ("platform/x86/intel/pmt: Use PMT callbacks") Cc: stable@vger.kernel.org Reviewed-by: David E. Box <david.e.box@linux.intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Link: https://lore.kernel.org/r/20250713172943.7335-2-michael.j.ruhl@intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/platform/x86/intel/pmt/class.c | 3 ++- drivers/platform/x86/intel/pmt/class.h | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) --- a/drivers/platform/x86/intel/pmt/class.c +++ b/drivers/platform/x86/intel/pmt/class.c @@ -97,7 +97,7 @@ intel_pmt_read(struct file *filp, struct if (count > entry->size - off) count = entry->size - off; - count = pmt_telem_read_mmio(entry->ep->pcidev, entry->cb, entry->header.guid, buf, + count = pmt_telem_read_mmio(entry->pcidev, entry->cb, entry->header.guid, buf, entry->base, off, count); return count; @@ -252,6 +252,7 @@ static int intel_pmt_populate_entry(stru return -EINVAL; } + entry->pcidev = pci_dev; entry->guid = header->guid; entry->size = header->size; entry->cb = ivdev->priv_data; --- a/drivers/platform/x86/intel/pmt/class.h +++ b/drivers/platform/x86/intel/pmt/class.h @@ -39,6 +39,7 @@ struct intel_pmt_header { struct intel_pmt_entry { struct telem_endpoint *ep; + struct pci_dev *pcidev; struct intel_pmt_header header; struct bin_attribute pmt_bin_attr; struct kobject *kobj; ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 463/480] x86/fpu: Delay instruction pointer fixup until after warning 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (461 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 462/480] platform/x86/intel/pmt: fix a crashlog NULL pointer access Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 464/480] KVM: VMX: Allow guest to set DEBUGCTL.RTM_DEBUG if RTM is supported Greg Kroah-Hartman ` (28 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Dave Hansen, Chao Gao, Alison Schofield, Peter Zijlstra (Intel) 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Dave Hansen <dave.hansen@linux.intel.com> commit 1cec9ac2d071cfd2da562241aab0ef701355762a upstream. Right now, if XRSTOR fails a console message like this is be printed: Bad FPU state detected at restore_fpregs_from_fpstate+0x9a/0x170, reinitializing FPU registers. However, the text location (...+0x9a in this case) is the instruction *AFTER* the XRSTOR. The highlighted instruction in the "Code:" dump also points one instruction late. The reason is that the "fixup" moves RIP up to pass the bad XRSTOR and keep on running after returning from the #GP handler. But it does this fixup before warning. The resulting warning output is nonsensical because it looks like the non-FPU-related instruction is #GP'ing. Do not fix up RIP until after printing the warning. Do this by using the more generic and standard ex_handler_default(). Fixes: d5c8028b4788 ("x86/fpu: Reinitialize FPU registers if restoring FPU state fails") Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Chao Gao <chao.gao@intel.com> Acked-by: Alison Schofield <alison.schofield@intel.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc:stable@vger.kernel.org Link: https://lore.kernel.org/all/20250624210148.97126F9E%40davehans-spike.ostc.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- arch/x86/mm/extable.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) --- a/arch/x86/mm/extable.c +++ b/arch/x86/mm/extable.c @@ -122,13 +122,12 @@ static bool ex_handler_sgx(const struct static bool ex_handler_fprestore(const struct exception_table_entry *fixup, struct pt_regs *regs) { - regs->ip = ex_fixup_addr(fixup); - WARN_ONCE(1, "Bad FPU state detected at %pB, reinitializing FPU registers.", (void *)instruction_pointer(regs)); fpu_reset_from_exception_fixup(); - return true; + + return ex_handler_default(fixup, regs); } /* ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 464/480] KVM: VMX: Allow guest to set DEBUGCTL.RTM_DEBUG if RTM is supported 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (462 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 463/480] x86/fpu: Delay instruction pointer fixup until after warning Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 465/480] s390/mm: Remove possible false-positive warning in pte_free_defer() Greg Kroah-Hartman ` (27 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Sean Christopherson 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Sean Christopherson <seanjc@google.com> commit 17ec2f965344ee3fd6620bef7ef68792f4ac3af0 upstream. Let the guest set DEBUGCTL.RTM_DEBUG if RTM is supported according to the guest CPUID model, as debug support is supposed to be available if RTM is supported, and there are no known downsides to letting the guest debug RTM aborts. Note, there are no known bug reports related to RTM_DEBUG, the primary motivation is to reduce the probability of breaking existing guests when a future change adds a missing consistency check on vmcs12.GUEST_DEBUGCTL (KVM currently lets L2 run with whatever hardware supports; whoops). Note #2, KVM already emulates DR6.RTM, and doesn't restrict access to DR7.RTM. Fixes: 83c529151ab0 ("KVM: x86: expose Intel cpu new features (HLE, RTM) to guest") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250610232010.162191-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- arch/x86/include/asm/msr-index.h | 1 + arch/x86/kvm/vmx/vmx.c | 4 ++++ 2 files changed, 5 insertions(+) --- a/arch/x86/include/asm/msr-index.h +++ b/arch/x86/include/asm/msr-index.h @@ -419,6 +419,7 @@ #define DEBUGCTLMSR_FREEZE_PERFMON_ON_PMI (1UL << 12) #define DEBUGCTLMSR_FREEZE_IN_SMM_BIT 14 #define DEBUGCTLMSR_FREEZE_IN_SMM (1UL << DEBUGCTLMSR_FREEZE_IN_SMM_BIT) +#define DEBUGCTLMSR_RTM_DEBUG BIT(15) #define MSR_PEBS_FRONTEND 0x000003f7 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -2192,6 +2192,10 @@ static u64 vmx_get_supported_debugctl(st (host_initiated || intel_pmu_lbr_is_enabled(vcpu))) debugctl |= DEBUGCTLMSR_LBR | DEBUGCTLMSR_FREEZE_LBRS_ON_PMI; + if (boot_cpu_has(X86_FEATURE_RTM) && + (host_initiated || guest_cpu_cap_has(vcpu, X86_FEATURE_RTM))) + debugctl |= DEBUGCTLMSR_RTM_DEBUG; + return debugctl; } ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 465/480] s390/mm: Remove possible false-positive warning in pte_free_defer() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (463 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 464/480] KVM: VMX: Allow guest to set DEBUGCTL.RTM_DEBUG if RTM is supported Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 466/480] MIPS: mm: tlb-r4k: Uniquify TLB entries on init Greg Kroah-Hartman ` (26 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Alexander Gordeev, Claudio Imbrenda, Gerald Schaefer 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Gerald Schaefer <gerald.schaefer@linux.ibm.com> commit 5647f61ad9171e8f025558ed6dc5702c56a33ba3 upstream. Commit 8211dad627981 ("s390: add pte_free_defer() for pgtables sharing page") added a warning to pte_free_defer(), on our request. It was meant to warn if this would ever be reached for KVM guest mappings, because the page table would be freed w/o a gmap_unlink(). THP mappings are not allowed for KVM guests on s390, so this should never happen. However, it is possible that the warning is triggered in a valid case as false-positive. s390_enable_sie() takes the mmap_lock, marks all VMAs as VM_NOHUGEPAGE and splits possibly existing THP guest mappings. mm->context.has_pgste is set to 1 before that, to prevent races with the mm_has_pgste() check in MADV_HUGEPAGE. khugepaged drops the mmap_lock for file mappings and might run in parallel, before a vma is marked VM_NOHUGEPAGE, but after mm->context.has_pgste was set to 1. If it finds file mappings to collapse, it will eventually call pte_free_defer(). This will trigger the warning, but it is a valid case because gmap is not yet set up, and the THP mappings will be split again. Therefore, remove the warning and the comment. Fixes: 8211dad627981 ("s390: add pte_free_defer() for pgtables sharing page") Cc: <stable@vger.kernel.org> # 6.6+ Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- arch/s390/mm/pgalloc.c | 5 ----- 1 file changed, 5 deletions(-) --- a/arch/s390/mm/pgalloc.c +++ b/arch/s390/mm/pgalloc.c @@ -176,11 +176,6 @@ void pte_free_defer(struct mm_struct *mm struct ptdesc *ptdesc = virt_to_ptdesc(pgtable); call_rcu(&ptdesc->pt_rcu_head, pte_free_now); - /* - * THPs are not allowed for KVM guests. Warn if pgste ever reaches here. - * Turn to the generic pte_free_defer() version once gmap is removed. - */ - WARN_ON_ONCE(mm_has_pgste(mm)); } #endif /* CONFIG_TRANSPARENT_HUGEPAGE */ ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 466/480] MIPS: mm: tlb-r4k: Uniquify TLB entries on init 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (464 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 465/480] s390/mm: Remove possible false-positive warning in pte_free_defer() Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 467/480] mm/hmm: move pmd_to_hmm_pfn_flags() to the respective #ifdeffery Greg Kroah-Hartman ` (25 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, stable, Jiaxun Yang, Thomas Bogendoerfer 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jiaxun Yang <jiaxun.yang@flygoat.com> commit 35ad7e181541aa5757f9f316768d3e64403ec843 upstream. Hardware or bootloader will initialize TLB entries to any value, which may collide with kernel's UNIQUE_ENTRYHI value. On MIPS microAptiv/M5150 family of cores this will trigger machine check exception and cause boot failure. On M5150 simulation this could happen 7 times out of 1000 boots. Replace local_flush_tlb_all() with r4k_tlb_uniquify() which probes each TLB ENTRIHI unique value for collisions before it's written, and in case of collision try a different ASID. Cc: stable@kernel.org Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- arch/mips/mm/tlb-r4k.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 55 insertions(+), 1 deletion(-) --- a/arch/mips/mm/tlb-r4k.c +++ b/arch/mips/mm/tlb-r4k.c @@ -508,6 +508,60 @@ static int __init set_ntlb(char *str) __setup("ntlb=", set_ntlb); +/* Initialise all TLB entries with unique values */ +static void r4k_tlb_uniquify(void) +{ + int entry = num_wired_entries(); + + htw_stop(); + write_c0_entrylo0(0); + write_c0_entrylo1(0); + + while (entry < current_cpu_data.tlbsize) { + unsigned long asid_mask = cpu_asid_mask(¤t_cpu_data); + unsigned long asid = 0; + int idx; + + /* Skip wired MMID to make ginvt_mmid work */ + if (cpu_has_mmid) + asid = MMID_KERNEL_WIRED + 1; + + /* Check for match before using UNIQUE_ENTRYHI */ + do { + if (cpu_has_mmid) { + write_c0_memorymapid(asid); + write_c0_entryhi(UNIQUE_ENTRYHI(entry)); + } else { + write_c0_entryhi(UNIQUE_ENTRYHI(entry) | asid); + } + mtc0_tlbw_hazard(); + tlb_probe(); + tlb_probe_hazard(); + idx = read_c0_index(); + /* No match or match is on current entry */ + if (idx < 0 || idx == entry) + break; + /* + * If we hit a match, we need to try again with + * a different ASID. + */ + asid++; + } while (asid < asid_mask); + + if (idx >= 0 && idx != entry) + panic("Unable to uniquify TLB entry %d", idx); + + write_c0_index(entry); + mtc0_tlbw_hazard(); + tlb_write_indexed(); + entry++; + } + + tlbw_use_hazard(); + htw_start(); + flush_micro_tlb(); +} + /* * Configure TLB (for init or after a CPU has been powered off). */ @@ -547,7 +601,7 @@ static void r4k_tlb_configure(void) temp_tlb_entry = current_cpu_data.tlbsize - 1; /* From this point on the ARC firmware is dead. */ - local_flush_tlb_all(); + r4k_tlb_uniquify(); /* Did I tell you that ARC SUCKS? */ } ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 467/480] mm/hmm: move pmd_to_hmm_pfn_flags() to the respective #ifdeffery 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (465 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 466/480] MIPS: mm: tlb-r4k: Uniquify TLB entries on init Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 468/480] mm: swap: correctly use maxpages in swapon syscall to avoid potential deadloop Greg Kroah-Hartman ` (24 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Andy Shevchenko, Leon Romanovsky, Alistair Popple, Bill Wendling, Jerome Glisse, Justin Stitt, Nathan Chancellor, Andrew Morton 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> commit 188cb385bbf04d486df3e52f28c47b3961f5f0c0 upstream. When pmd_to_hmm_pfn_flags() is unused, it prevents kernel builds with clang, `make W=1` and CONFIG_TRANSPARENT_HUGEPAGE=n: mm/hmm.c:186:29: warning: unused function 'pmd_to_hmm_pfn_flags' [-Wunused-function] Fix this by moving the function to the respective existing ifdeffery for its the only user. See also: 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build") Link: https://lkml.kernel.org/r/20250710082403.664093-1-andriy.shevchenko@linux.intel.com Fixes: 992de9a8b751 ("mm/hmm: allow to mirror vma of a file on a DAX backed filesystem") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Alistair Popple <apopple@nvidia.com> Cc: Andriy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Bill Wendling <morbo@google.com> Cc: Jerome Glisse <jglisse@redhat.com> Cc: Justin Stitt <justinstitt@google.com> Cc: Nathan Chancellor <nathan@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- mm/hmm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/hmm.c +++ b/mm/hmm.c @@ -173,6 +173,7 @@ static inline unsigned long hmm_pfn_flag return order << HMM_PFN_ORDER_SHIFT; } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE static inline unsigned long pmd_to_hmm_pfn_flags(struct hmm_range *range, pmd_t pmd) { @@ -183,7 +184,6 @@ static inline unsigned long pmd_to_hmm_p hmm_pfn_flags_order(PMD_SHIFT - PAGE_SHIFT); } -#ifdef CONFIG_TRANSPARENT_HUGEPAGE static int hmm_vma_handle_pmd(struct mm_walk *walk, unsigned long addr, unsigned long end, unsigned long hmm_pfns[], pmd_t pmd) ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 468/480] mm: swap: correctly use maxpages in swapon syscall to avoid potential deadloop 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (466 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 467/480] mm/hmm: move pmd_to_hmm_pfn_flags() to the respective #ifdeffery Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 469/480] mm: swap: fix potential buffer overflow in setup_clusters() Greg Kroah-Hartman ` (23 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Kemeng Shi, Baoquan He, Johannes Weiner, Kairui Song, Andrew Morton 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Kemeng Shi <shikemeng@huaweicloud.com> commit 255116c5b0fa2145ede28c2f7b248df5e73834d1 upstream. We use maxpages from read_swap_header() to initialize swap_info_struct, however the maxpages might be reduced in setup_swap_extents() and the si->max is assigned with the reduced maxpages from the setup_swap_extents(). Obviously, this could lead to memory waste as we allocated memory based on larger maxpages, besides, this could lead to a potential deadloop as following: 1) When calling setup_clusters() with larger maxpages, unavailable pages within range [si->max, larger maxpages) are not accounted with inc_cluster_info_page(). As a result, these pages are assumed available but can not be allocated. The cluster contains these pages can be moved to frag_clusters list after it's all available pages were allocated. 2) When the cluster mentioned in 1) is the only cluster in frag_clusters list, cluster_alloc_swap_entry() assume order 0 allocation will never failed and will enter a deadloop by keep trying to allocate page from the only cluster in frag_clusters which contains no actually available page. Call setup_swap_extents() to get the final maxpages before swap_info_struct initialization to fix the issue. After this change, span will include badblocks and will become large value which I think is correct value: In summary, there are two kinds of swapfile_activate operations. 1. Filesystem style: Treat all blocks logical continuity and find usable physical extents in logical range. In this way, si->pages will be actual usable physical blocks and span will be "1 + highest_block - lowest_block". 2. Block device style: Treat all blocks physically continue and only one single extent is added. In this way, si->pages will be si->max and span will be "si->pages - 1". Actually, si->pages and si->max is only used in block device style and span value is set with si->pages. As a result, span value in block device style will become a larger value as you mentioned. I think larger value is correct based on: 1. Span value in filesystem style is "1 + highest_block - lowest_block" which is the range cover all possible phisical blocks including the badblocks. 2. For block device style, si->pages is the actual usable block number and is already in pr_info. The original span value before this patch is also refer to usable block number which is redundant in pr_info. [shikemeng@huaweicloud.com: ensure si->pages == si->max - 1 after setup_swap_extents()] Link: https://lkml.kernel.org/r/20250522122554.12209-3-shikemeng@huaweicloud.com Link: https://lkml.kernel.org/r/20250718065139.61989-1-shikemeng@huaweicloud.com Link: https://lkml.kernel.org/r/20250522122554.12209-3-shikemeng@huaweicloud.com Fixes: 661383c6111a ("mm: swap: relaim the cached parts that got scanned") Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com> Reviewed-by: Baoquan He <bhe@redhat.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Kairui Song <kasong@tencent.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- mm/swapfile.c | 53 ++++++++++++++++++++++++++--------------------------- 1 file changed, 26 insertions(+), 27 deletions(-) --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -3138,43 +3138,30 @@ static unsigned long read_swap_header(st return maxpages; } -static int setup_swap_map_and_extents(struct swap_info_struct *si, - union swap_header *swap_header, - unsigned char *swap_map, - unsigned long maxpages, - sector_t *span) +static int setup_swap_map(struct swap_info_struct *si, + union swap_header *swap_header, + unsigned char *swap_map, + unsigned long maxpages) { - unsigned int nr_good_pages; unsigned long i; - int nr_extents; - - nr_good_pages = maxpages - 1; /* omit header page */ + swap_map[0] = SWAP_MAP_BAD; /* omit header page */ for (i = 0; i < swap_header->info.nr_badpages; i++) { unsigned int page_nr = swap_header->info.badpages[i]; if (page_nr == 0 || page_nr > swap_header->info.last_page) return -EINVAL; if (page_nr < maxpages) { swap_map[page_nr] = SWAP_MAP_BAD; - nr_good_pages--; + si->pages--; } } - if (nr_good_pages) { - swap_map[0] = SWAP_MAP_BAD; - si->max = maxpages; - si->pages = nr_good_pages; - nr_extents = setup_swap_extents(si, span); - if (nr_extents < 0) - return nr_extents; - nr_good_pages = si->pages; - } - if (!nr_good_pages) { + if (!si->pages) { pr_warn("Empty swap-file\n"); return -EINVAL; } - return nr_extents; + return 0; } #define SWAP_CLUSTER_INFO_COLS \ @@ -3214,7 +3201,7 @@ static struct swap_cluster_info *setup_c * Mark unusable pages as unavailable. The clusters aren't * marked free yet, so no list operations are involved yet. * - * See setup_swap_map_and_extents(): header page, bad pages, + * See setup_swap_map(): header page, bad pages, * and the EOF part of the last cluster. */ inc_cluster_info_page(si, cluster_info, 0); @@ -3360,6 +3347,21 @@ SYSCALL_DEFINE2(swapon, const char __use goto bad_swap_unlock_inode; } + si->max = maxpages; + si->pages = maxpages - 1; + nr_extents = setup_swap_extents(si, &span); + if (nr_extents < 0) { + error = nr_extents; + goto bad_swap_unlock_inode; + } + if (si->pages != si->max - 1) { + pr_err("swap:%u != (max:%u - 1)\n", si->pages, si->max); + error = -EINVAL; + goto bad_swap_unlock_inode; + } + + maxpages = si->max; + /* OK, set up the swap map and apply the bad block list */ swap_map = vzalloc(maxpages); if (!swap_map) { @@ -3371,12 +3373,9 @@ SYSCALL_DEFINE2(swapon, const char __use if (error) goto bad_swap_unlock_inode; - nr_extents = setup_swap_map_and_extents(si, swap_header, swap_map, - maxpages, &span); - if (unlikely(nr_extents < 0)) { - error = nr_extents; + error = setup_swap_map(si, swap_header, swap_map, maxpages); + if (error) goto bad_swap_unlock_inode; - } /* * Use kvmalloc_array instead of bitmap_zalloc as the allocation order might ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 469/480] mm: swap: fix potential buffer overflow in setup_clusters() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (467 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 468/480] mm: swap: correctly use maxpages in swapon syscall to avoid potential deadloop Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 470/480] mm: swap: move nr_swap_pages counter decrement from folio_alloc_swap() to swap_range_alloc() Greg Kroah-Hartman ` (22 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Kemeng Shi, Baoquan He, Johannes Weiner, Kairui Song, Andrew Morton 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Kemeng Shi <shikemeng@huaweicloud.com> commit 152c1339dc13ad46f1b136e8693de15980750835 upstream. In setup_swap_map(), we only ensure badpages are in range (0, last_page]. As maxpages might be < last_page, setup_clusters() will encounter a buffer overflow when a badpage is >= maxpages. Only call inc_cluster_info_page() for badpage which is < maxpages to fix the issue. Link: https://lkml.kernel.org/r/20250522122554.12209-4-shikemeng@huaweicloud.com Fixes: b843786b0bd0 ("mm: swapfile: fix SSD detection with swapfile on btrfs") Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com> Reviewed-by: Baoquan He <bhe@redhat.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Kairui Song <kasong@tencent.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- mm/swapfile.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -3205,9 +3205,13 @@ static struct swap_cluster_info *setup_c * and the EOF part of the last cluster. */ inc_cluster_info_page(si, cluster_info, 0); - for (i = 0; i < swap_header->info.nr_badpages; i++) - inc_cluster_info_page(si, cluster_info, - swap_header->info.badpages[i]); + for (i = 0; i < swap_header->info.nr_badpages; i++) { + unsigned int page_nr = swap_header->info.badpages[i]; + + if (page_nr >= maxpages) + continue; + inc_cluster_info_page(si, cluster_info, page_nr); + } for (i = maxpages; i < round_up(maxpages, SWAPFILE_CLUSTER); i++) inc_cluster_info_page(si, cluster_info, i); ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 470/480] mm: swap: move nr_swap_pages counter decrement from folio_alloc_swap() to swap_range_alloc() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (468 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 469/480] mm: swap: fix potential buffer overflow in setup_clusters() Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 471/480] mm: shmem: fix the shmem large folio allocation for the i915 driver Greg Kroah-Hartman ` (21 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Kemeng Shi, Kairui Song, Baoquan He, Johannes Weiner, Andrew Morton 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Kemeng Shi <shikemeng@huaweicloud.com> commit 4f78252da887ee7e9d1875dd6e07d9baa936c04f upstream. Patch series "Some randome fixes and cleanups to swapfile". Patch 0-3 are some random fixes. Patch 4 is a cleanup. More details can be found in respective patches. This patch (of 4): When folio_alloc_swap() encounters a failure in either mem_cgroup_try_charge_swap() or add_to_swap_cache(), nr_swap_pages counter is not decremented for allocated entry. However, the following put_swap_folio() will increase nr_swap_pages counter unpairly and lead to an imbalance. Move nr_swap_pages decrement from folio_alloc_swap() to swap_range_alloc() to pair the nr_swap_pages counting. Link: https://lkml.kernel.org/r/20250522122554.12209-1-shikemeng@huaweicloud.com Link: https://lkml.kernel.org/r/20250522122554.12209-2-shikemeng@huaweicloud.com Fixes: 0ff67f990bd4 ("mm, swap: remove swap slot cache") Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com> Reviewed-by: Kairui Song <kasong@tencent.com> Reviewed-by: Baoquan He <bhe@redhat.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- mm/swapfile.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -1115,6 +1115,7 @@ static void swap_range_alloc(struct swap if (vm_swap_full()) schedule_work(&si->reclaim_work); } + atomic_long_sub(nr_entries, &nr_swap_pages); } static void swap_range_free(struct swap_info_struct *si, unsigned long offset, @@ -1313,7 +1314,6 @@ int folio_alloc_swap(struct folio *folio if (add_to_swap_cache(folio, entry, gfp | __GFP_NOMEMALLOC, NULL)) goto out_free; - atomic_long_sub(size, &nr_swap_pages); return 0; out_free: ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 471/480] mm: shmem: fix the shmem large folio allocation for the i915 driver 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (469 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 470/480] mm: swap: move nr_swap_pages counter decrement from folio_alloc_swap() to swap_range_alloc() Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 472/480] usb: gadget: uvc: Initialize frame-based format color matching descriptor Greg Kroah-Hartman ` (20 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Baolin Wang, Patryk Kowalczyk, Ville Syrjälä, Hugh Dickins, Andrew Morton 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Baolin Wang <baolin.wang@linux.alibaba.com> commit 8d58d65621118fdca3ed6a0b3d658ba7e0e5153c upstream. After commit acd7ccb284b8 ("mm: shmem: add large folio support for tmpfs"), we extend the 'huge=' option to allow any sized large folios for tmpfs, which means tmpfs will allow getting a highest order hint based on the size of write() and fallocate() paths, and then will try each allowable large order. However, when the i915 driver allocates shmem memory, it doesn't provide hint information about the size of the large folio to be allocated, resulting in the inability to allocate PMD-sized shmem, which in turn affects GPU performance. Patryk added: : In my tests, the performance drop ranges from a few percent up to 13% : in Unigine Superposition under heavy memory usage on the CPU Core Ultra : 155H with the Xe 128 EU GPU. Other users have reported performance : impact up to 30% on certain workloads. Please find more in the : regressions reports: : https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14645 : https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13845 : : I believe the change should be backported to all active kernel branches : after version 6.12. To fix this issue, we can use the inode's size as a write size hint in shmem_read_folio_gfp() to help allocate PMD-sized large folios. Link: https://lkml.kernel.org/r/f7e64e99a3a87a8144cc6b2f1dddf7a89c12ce44.1753926601.git.baolin.wang@linux.alibaba.com Fixes: acd7ccb284b8 ("mm: shmem: add large folio support for tmpfs") Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com> Reported-by: Patryk Kowalczyk <patryk@kowalczyk.ws> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Patryk Kowalczyk <patryk@kowalczyk.ws> Suggested-by: Hugh Dickins <hughd@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- mm/shmem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/mm/shmem.c +++ b/mm/shmem.c @@ -5930,8 +5930,8 @@ struct folio *shmem_read_folio_gfp(struc struct folio *folio; int error; - error = shmem_get_folio_gfp(inode, index, 0, &folio, SGP_CACHE, - gfp, NULL, NULL); + error = shmem_get_folio_gfp(inode, index, i_size_read(inode), + &folio, SGP_CACHE, gfp, NULL, NULL); if (error) return ERR_PTR(error); ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 472/480] usb: gadget: uvc: Initialize frame-based format color matching descriptor 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (470 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 471/480] mm: shmem: fix the shmem large folio allocation for the i915 driver Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 473/480] perf/arm-ni: Set initial IRQ affinity Greg Kroah-Hartman ` (19 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, stable, Akash Kumar 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Akash Kumar <quic_akakum@quicinc.com> commit 323a80a1a5ace319a722909c006d5bdb2a35d273 upstream. Fix NULL pointer crash in uvcg_framebased_make due to uninitialized color matching descriptor for frame-based format which was added in commit f5e7bdd34aca ("usb: gadget: uvc: Allow creating new color matching descriptors") that added handling for uncompressed and mjpeg format. Crash is seen when userspace configuration (via configfs) does not explicitly define the color matching descriptor. If color_matching is not found, config_group_find_item() returns NULL. The code then jumps to out_put_cm, where it calls config_item_put(color_matching);. If color_matching is NULL, this will dereference a null pointer, leading to a crash. [ 2.746440] Unable to handle kernel NULL pointer dereference at virtual address 000000000000008c [ 2.756273] Mem abort info: [ 2.760080] ESR = 0x0000000096000005 [ 2.764872] EC = 0x25: DABT (current EL), IL = 32 bits [ 2.771068] SET = 0, FnV = 0 [ 2.771069] EA = 0, S1PTW = 0 [ 2.771070] FSC = 0x05: level 1 translation fault [ 2.771071] Data abort info: [ 2.771072] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 2.771073] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 2.771074] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 2.771075] user pgtable: 4k pages, 39-bit VAs, pgdp=00000000a3e59000 [ 2.771077] [000000000000008c] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 2.771081] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 2.771084] Dumping ftrace buffer: [ 2.771085] (ftrace buffer empty) [ 2.771138] CPU: 7 PID: 486 Comm: ln Tainted: G W E 6.6.58-android15 [ 2.771139] Hardware name: Qualcomm Technologies, Inc. SunP QRD HDK (DT) [ 2.771140] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2.771141] pc : __uvcg_fill_strm+0x198/0x2cc [ 2.771145] lr : __uvcg_iter_strm_cls+0xc8/0x17c [ 2.771146] sp : ffffffc08140bbb0 [ 2.771146] x29: ffffffc08140bbb0 x28: ffffff803bc81380 x27: ffffff8023bbd250 [ 2.771147] x26: ffffff8023bbd250 x25: ffffff803c361348 x24: ffffff803d8e6768 [ 2.771148] x23: 0000000000000004 x22: 0000000000000003 x21: ffffffc08140bc48 [ 2.771149] x20: 0000000000000000 x19: ffffffc08140bc48 x18: ffffffe9f8cf4a00 [ 2.771150] x17: 000000001bf64ec3 x16: 000000001bf64ec3 x15: ffffff8023bbd250 [ 2.771151] x14: 000000000000000f x13: 004c4b40000f4240 x12: 000a2c2a00051615 [ 2.771152] x11: 000000000000004f x10: ffffffe9f76b40ec x9 : ffffffe9f7e389d0 [ 2.771153] x8 : ffffff803d0d31ce x7 : 000f4240000a2c2a x6 : 0005161500028b0a [ 2.771154] x5 : ffffff803d0d31ce x4 : 0000000000000003 x3 : 0000000000000000 [ 2.771155] x2 : ffffffc08140bc50 x1 : ffffffc08140bc48 x0 : 0000000000000000 [ 2.771156] Call trace: [ 2.771157] __uvcg_fill_strm+0x198/0x2cc [ 2.771157] __uvcg_iter_strm_cls+0xc8/0x17c [ 2.771158] uvcg_streaming_class_allow_link+0x240/0x290 [ 2.771159] configfs_symlink+0x1f8/0x630 [ 2.771161] vfs_symlink+0x114/0x1a0 [ 2.771163] do_symlinkat+0x94/0x28c [ 2.771164] __arm64_sys_symlinkat+0x54/0x70 [ 2.771164] invoke_syscall+0x58/0x114 [ 2.771166] el0_svc_common+0x80/0xe0 [ 2.771168] do_el0_svc+0x1c/0x28 [ 2.771169] el0_svc+0x3c/0x70 [ 2.771172] el0t_64_sync_handler+0x68/0xbc [ 2.771173] el0t_64_sync+0x1a8/0x1ac Initialize color matching descriptor for frame-based format to prevent NULL pointer crash by mirroring the handling done for uncompressed and mjpeg formats. Fixes: 7b5a58952fc3 ("usb: gadget: uvc: configfs: Add frame-based frame format support") Cc: stable <stable@kernel.org> Signed-off-by: Akash Kumar <quic_akakum@quicinc.com> Link: https://lore.kernel.org/r/20250718085138.1118788-1-quic_akakum@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/usb/gadget/function/uvc_configfs.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/drivers/usb/gadget/function/uvc_configfs.c +++ b/drivers/usb/gadget/function/uvc_configfs.c @@ -2916,8 +2916,15 @@ static struct config_group *uvcg_frameba 'H', '2', '6', '4', 0x00, 0x00, 0x10, 0x00, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71 }; + struct uvcg_color_matching *color_match; + struct config_item *streaming; struct uvcg_framebased *h; + streaming = group->cg_item.ci_parent; + color_match = uvcg_format_get_default_color_match(streaming); + if (!color_match) + return ERR_PTR(-EINVAL); + h = kzalloc(sizeof(*h), GFP_KERNEL); if (!h) return ERR_PTR(-ENOMEM); @@ -2936,6 +2943,9 @@ static struct config_group *uvcg_frameba INIT_LIST_HEAD(&h->fmt.frames); h->fmt.type = UVCG_FRAMEBASED; + + h->fmt.color_matching = color_match; + color_match->refcnt++; config_group_init_type_name(&h->fmt.group, name, &uvcg_framebased_type); ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 473/480] perf/arm-ni: Set initial IRQ affinity 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (471 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 472/480] usb: gadget: uvc: Initialize frame-based format color matching descriptor Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 474/480] media: ti: j721e-csi2rx: fix list_del corruption Greg Kroah-Hartman ` (18 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Robin Murphy, Shouping Wang, Will Deacon 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Robin Murphy <robin.murphy@arm.com> commit c872d7c837382517c51a76dfdcf550332cfab231 upstream. While we do request our IRQs with the right flags to stop their affinity changing unexpectedly, we forgot to actually set it to start with. Oops. Cc: stable@vger.kernel.org Fixes: 4d5a7680f2b4 ("perf: Add driver for Arm NI-700 interconnect PMU") Signed-off-by: Robin Murphy <robin.murphy@arm.com> Tested-by: Shouping Wang <allen.wang@hj-micro.com> Link: https://lore.kernel.org/r/614ced9149ee8324e58930862bd82cbf46228d27.1747149165.git.robin.murphy@arm.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/perf/arm-ni.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/perf/arm-ni.c +++ b/drivers/perf/arm-ni.c @@ -544,6 +544,8 @@ static int arm_ni_init_cd(struct arm_ni return err; cd->cpu = cpumask_local_spread(0, dev_to_node(ni->dev)); + irq_set_affinity(cd->irq, cpumask_of(cd->cpu)); + cd->pmu = (struct pmu) { .module = THIS_MODULE, .parent = ni->dev, ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 474/480] media: ti: j721e-csi2rx: fix list_del corruption 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (472 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 473/480] perf/arm-ni: Set initial IRQ affinity Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 475/480] HID: apple: validate feature-report field count to prevent NULL pointer dereference Greg Kroah-Hartman ` (17 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Sjoerd Simons, Julien Massot, Jai Luthra, Dirk Behme, Sakari Ailus, Hans Verkuil 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Julien Massot <julien.massot@collabora.com> commit ae42c6fe531425ef2f47e82f96851427d24bbf6b upstream. If ti_csi2rx_start_dma() fails in ti_csi2rx_dma_callback(), the buffer is marked done with VB2_BUF_STATE_ERROR but is not removed from the DMA queue. This causes the same buffer to be retried in the next iteration, resulting in a double list_del() and eventual list corruption. Fix this by removing the buffer from the queue before calling vb2_buffer_done() on error. This resolves a crash due to list_del corruption: [ 37.811243] j721e-csi2rx 30102000.ticsi2rx: Failed to queue the next buffer for DMA [ 37.832187] slab kmalloc-2k start ffff00000255b000 pointer offset 1064 size 2048 [ 37.839761] list_del corruption. next->prev should be ffff00000255bc28, but was ffff00000255d428. (next=ffff00000255b428) [ 37.850799] ------------[ cut here ]------------ [ 37.855424] kernel BUG at lib/list_debug.c:65! [ 37.859876] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 37.866061] Modules linked in: i2c_dev usb_f_rndis u_ether libcomposite dwc3 udc_core usb_common aes_ce_blk aes_ce_cipher ghash_ce gf128mul sha1_ce cpufreq_dt dwc3_am62 phy_gmii_sel sa2ul [ 37.882830] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.16.0-rc3+ #28 VOLUNTARY [ 37.890851] Hardware name: Bosch STLA-GSRV2-B0 (DT) [ 37.895737] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 37.902703] pc : __list_del_entry_valid_or_report+0xdc/0x114 [ 37.908390] lr : __list_del_entry_valid_or_report+0xdc/0x114 [ 37.914059] sp : ffff800080003db0 [ 37.917375] x29: ffff800080003db0 x28: 0000000000000007 x27: ffff800080e50000 [ 37.924521] x26: 0000000000000000 x25: ffff0000016abb50 x24: dead000000000122 [ 37.931666] x23: ffff0000016abb78 x22: ffff0000016ab080 x21: ffff800080003de0 [ 37.938810] x20: ffff00000255bc00 x19: ffff00000255b800 x18: 000000000000000a [ 37.945956] x17: 20747562202c3832 x16: 6362353532303030 x15: 0720072007200720 [ 37.953101] x14: 0720072007200720 x13: 0720072007200720 x12: 00000000ffffffea [ 37.960248] x11: ffff800080003b18 x10: 00000000ffffefff x9 : ffff800080f5b568 [ 37.967396] x8 : ffff800080f5b5c0 x7 : 0000000000017fe8 x6 : c0000000ffffefff [ 37.974542] x5 : ffff00000fea6688 x4 : 0000000000000000 x3 : 0000000000000000 [ 37.981686] x2 : 0000000000000000 x1 : ffff800080ef2b40 x0 : 000000000000006d [ 37.988832] Call trace: [ 37.991281] __list_del_entry_valid_or_report+0xdc/0x114 (P) [ 37.996959] ti_csi2rx_dma_callback+0x84/0x1c4 [ 38.001419] udma_vchan_complete+0x1e0/0x344 [ 38.005705] tasklet_action_common+0x118/0x310 [ 38.010163] tasklet_action+0x30/0x3c [ 38.013832] handle_softirqs+0x10c/0x2e0 [ 38.017761] __do_softirq+0x14/0x20 [ 38.021256] ____do_softirq+0x10/0x20 [ 38.024931] call_on_irq_stack+0x24/0x60 [ 38.028873] do_softirq_own_stack+0x1c/0x40 [ 38.033064] __irq_exit_rcu+0x130/0x15c [ 38.036909] irq_exit_rcu+0x10/0x20 [ 38.040403] el1_interrupt+0x38/0x60 [ 38.043987] el1h_64_irq_handler+0x18/0x24 [ 38.048091] el1h_64_irq+0x6c/0x70 [ 38.051501] default_idle_call+0x34/0xe0 (P) [ 38.055783] do_idle+0x1f8/0x250 [ 38.059021] cpu_startup_entry+0x34/0x3c [ 38.062951] rest_init+0xb4/0xc0 [ 38.066186] console_on_rootfs+0x0/0x6c [ 38.070031] __primary_switched+0x88/0x90 [ 38.074059] Code: b00037e0 91378000 f9400462 97e9bf49 (d4210000) [ 38.080168] ---[ end trace 0000000000000000 ]--- [ 38.084795] Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt [ 38.092197] SMP: stopping secondary CPUs [ 38.096139] Kernel Offset: disabled [ 38.099631] CPU features: 0x0000,00002000,02000801,0400420b [ 38.105202] Memory Limit: none [ 38.108260] ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt ]--- Fixes: b4a3d877dc92 ("media: ti: Add CSI2RX support for J721E") Cc: stable@vger.kernel.org Suggested-by: Sjoerd Simons <sjoerd@collabora.com> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com> Signed-off-by: Julien Massot <julien.massot@collabora.com> Reviewed-by: Jai Luthra <jai.luthra@linux.dev> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/media/platform/ti/j721e-csi2rx/j721e-csi2rx.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/media/platform/ti/j721e-csi2rx/j721e-csi2rx.c +++ b/drivers/media/platform/ti/j721e-csi2rx/j721e-csi2rx.c @@ -619,6 +619,7 @@ static void ti_csi2rx_dma_callback(void if (ti_csi2rx_start_dma(csi, buf)) { dev_err(csi->dev, "Failed to queue the next buffer for DMA\n"); + list_del(&buf->list); vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_ERROR); } else { list_move_tail(&buf->list, &dma->submitted); ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 475/480] HID: apple: validate feature-report field count to prevent NULL pointer dereference 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (473 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 474/480] media: ti: j721e-csi2rx: fix list_del corruption Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 476/480] USB: gadget: f_hid: Fix memory leak in hidg_bind error path Greg Kroah-Hartman ` (16 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Qasim Ijaz, Orlando Chamberlain, Aditya Garg, Benjamin Tissoires 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Qasim Ijaz <qasdev00@gmail.com> commit 1bb3363da862e0464ec050eea2fb5472a36ad86b upstream. A malicious HID device with quirk APPLE_MAGIC_BACKLIGHT can trigger a NULL pointer dereference whilst the power feature-report is toggled and sent to the device in apple_magic_backlight_report_set(). The power feature-report is expected to have two data fields, but if the descriptor declares one field then accessing field[1] and dereferencing it in apple_magic_backlight_report_set() becomes invalid since field[1] will be NULL. An example of a minimal descriptor which can cause the crash is something like the following where the report with ID 3 (power report) only references a single 1-byte field. When hid core parses the descriptor it will encounter the final feature tag, allocate a hid_report (all members of field[] will be zeroed out), create field structure and populate it, increasing the maxfield to 1. The subsequent field[1] access and dereference causes the crash. Usage Page (Vendor Defined 0xFF00) Usage (0x0F) Collection (Application) Report ID (1) Usage (0x01) Logical Minimum (0) Logical Maximum (255) Report Size (8) Report Count (1) Feature (Data,Var,Abs) Usage (0x02) Logical Maximum (32767) Report Size (16) Report Count (1) Feature (Data,Var,Abs) Report ID (3) Usage (0x03) Logical Minimum (0) Logical Maximum (1) Report Size (8) Report Count (1) Feature (Data,Var,Abs) End Collection Here we see the KASAN splat when the kernel dereferences the NULL pointer and crashes: [ 15.164723] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN NOPTI [ 15.165691] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 15.165691] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0 #31 PREEMPT(voluntary) [ 15.165691] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 15.165691] RIP: 0010:apple_magic_backlight_report_set+0xbf/0x210 [ 15.165691] Call Trace: [ 15.165691] <TASK> [ 15.165691] apple_probe+0x571/0xa20 [ 15.165691] hid_device_probe+0x2e2/0x6f0 [ 15.165691] really_probe+0x1ca/0x5c0 [ 15.165691] __driver_probe_device+0x24f/0x310 [ 15.165691] driver_probe_device+0x4a/0xd0 [ 15.165691] __device_attach_driver+0x169/0x220 [ 15.165691] bus_for_each_drv+0x118/0x1b0 [ 15.165691] __device_attach+0x1d5/0x380 [ 15.165691] device_initial_probe+0x12/0x20 [ 15.165691] bus_probe_device+0x13d/0x180 [ 15.165691] device_add+0xd87/0x1510 [...] To fix this issue we should validate the number of fields that the backlight and power reports have and if they do not have the required number of fields then bail. Fixes: 394ba612f941 ("HID: apple: Add support for magic keyboard backlight on T2 Macs") Cc: stable@vger.kernel.org Signed-off-by: Qasim Ijaz <qasdev00@gmail.com> Reviewed-by: Orlando Chamberlain <orlandoch.dev@gmail.com> Tested-by: Aditya Garg <gargaditya08@live.com> Link: https://patch.msgid.link/20250713233008.15131-1-qasdev00@gmail.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/hid/hid-apple.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/hid/hid-apple.c +++ b/drivers/hid/hid-apple.c @@ -890,7 +890,8 @@ static int apple_magic_backlight_init(st backlight->brightness = report_enum->report_id_hash[APPLE_MAGIC_REPORT_ID_BRIGHTNESS]; backlight->power = report_enum->report_id_hash[APPLE_MAGIC_REPORT_ID_POWER]; - if (!backlight->brightness || !backlight->power) + if (!backlight->brightness || backlight->brightness->maxfield < 2 || + !backlight->power || backlight->power->maxfield < 2) return -ENODEV; backlight->cdev.name = ":white:" LED_FUNCTION_KBD_BACKLIGHT; ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 476/480] USB: gadget: f_hid: Fix memory leak in hidg_bind error path 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (474 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 475/480] HID: apple: validate feature-report field count to prevent NULL pointer dereference Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 477/480] HID: core: Harden s32ton() against conversion to 0 bits Greg Kroah-Hartman ` (15 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Yuhao Jiang 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Yuhao Jiang <danisjiang@gmail.com> commit 62783c30d78aecf9810dae46fd4d11420ad38b74 upstream. In hidg_bind(), if alloc_workqueue() fails after usb_assign_descriptors() has successfully allocated the USB descriptors, the current error handling does not call usb_free_all_descriptors() to free the allocated descriptors, resulting in a memory leak. Restructure the error handling by adding proper cleanup labels: - fail_free_all: cleans up workqueue and descriptors - fail_free_descs: cleans up descriptors only - fail: original cleanup for earlier failures This ensures that allocated resources are properly freed in reverse order of their allocation, preventing the memory leak when alloc_workqueue() fails. Fixes: a139c98f760ef ("USB: gadget: f_hid: Add GET_REPORT via userspace IOCTL") Cc: stable@vger.kernel.org Signed-off-by: Yuhao Jiang <danisjiang@gmail.com> Link: https://lore.kernel.org/r/20250623094844.244977-1-danisjiang@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/usb/gadget/function/f_hid.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/drivers/usb/gadget/function/f_hid.c +++ b/drivers/usb/gadget/function/f_hid.c @@ -1275,18 +1275,19 @@ static int hidg_bind(struct usb_configur if (!hidg->workqueue) { status = -ENOMEM; - goto fail; + goto fail_free_descs; } /* create char device */ cdev_init(&hidg->cdev, &f_hidg_fops); status = cdev_device_add(&hidg->cdev, &hidg->dev); if (status) - goto fail_free_descs; + goto fail_free_all; return 0; -fail_free_descs: +fail_free_all: destroy_workqueue(hidg->workqueue); +fail_free_descs: usb_free_all_descriptors(f); fail: ERROR(f->config->cdev, "hidg_bind FAILED\n"); ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 477/480] HID: core: Harden s32ton() against conversion to 0 bits 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (475 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 476/480] USB: gadget: f_hid: Fix memory leak in hidg_bind error path Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 478/480] HID: apple: avoid setting up battery timer for devices without battery Greg Kroah-Hartman ` (14 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Alan Stern, syzbot+b63d677d63bcac06cf90, Benjamin Tissoires 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Alan Stern <stern@rowland.harvard.edu> commit a6b87bfc2ab5bccb7ad953693c85d9062aef3fdd upstream. Testing by the syzbot fuzzer showed that the HID core gets a shift-out-of-bounds exception when it tries to convert a 32-bit quantity to a 0-bit quantity. Ideally this should never occur, but there are buggy devices and some might have a report field with size set to zero; we shouldn't reject the report or the device just because of that. Instead, harden the s32ton() routine so that it returns a reasonable result instead of crashing when it is called with the number of bits set to 0 -- the same as what snto32() does. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/68753a08.050a0220.33d347.0008.GAE@google.com/ Tested-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/613a66cd-4309-4bce-a4f7-2905f9bce0c9@rowland.harvard.edu Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/hid/hid-core.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -66,8 +66,12 @@ static s32 snto32(__u32 value, unsigned static u32 s32ton(__s32 value, unsigned int n) { - s32 a = value >> (n - 1); + s32 a; + if (!value || !n) + return 0; + + a = value >> (n - 1); if (a && a != -1) return value < 0 ? 1 << (n - 1) : (1 << (n - 1)) - 1; return value & ((1 << n) - 1); ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 478/480] HID: apple: avoid setting up battery timer for devices without battery 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (476 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 477/480] HID: core: Harden s32ton() against conversion to 0 bits Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 479/480] usb: gadget : fix use-after-free in composite_dev_cleanup() Greg Kroah-Hartman ` (13 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, Aditya Garg, Jiri Kosina 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Aditya Garg <gargaditya08@live.com> commit c061046fe9ce3ff31fb9a807144a2630ad349c17 upstream. Currently, the battery timer is set up for all devices using hid-apple, irrespective of whether they actually have a battery or not. APPLE_RDESC_BATTERY is a quirk that indicates the device has a battery and needs the battery timer. This patch checks for this quirk before setting up the timer, ensuring that only devices with a battery will have the timer set up. Fixes: 6e143293e17a ("HID: apple: Report Magic Keyboard battery over USB") Cc: stable@vger.kernel.org Signed-off-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Jiri Kosina <jkosina@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/hid/hid-apple.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) --- a/drivers/hid/hid-apple.c +++ b/drivers/hid/hid-apple.c @@ -934,10 +934,12 @@ static int apple_probe(struct hid_device return ret; } - timer_setup(&asc->battery_timer, apple_battery_timer_tick, 0); - mod_timer(&asc->battery_timer, - jiffies + msecs_to_jiffies(APPLE_BATTERY_TIMEOUT_MS)); - apple_fetch_battery(hdev); + if (quirks & APPLE_RDESC_BATTERY) { + timer_setup(&asc->battery_timer, apple_battery_timer_tick, 0); + mod_timer(&asc->battery_timer, + jiffies + msecs_to_jiffies(APPLE_BATTERY_TIMEOUT_MS)); + apple_fetch_battery(hdev); + } if (quirks & APPLE_BACKLIGHT_CTL) apple_backlight_init(hdev); @@ -951,7 +953,9 @@ static int apple_probe(struct hid_device return 0; out_err: - timer_delete_sync(&asc->battery_timer); + if (quirks & APPLE_RDESC_BATTERY) + timer_delete_sync(&asc->battery_timer); + hid_hw_stop(hdev); return ret; } @@ -960,7 +964,8 @@ static void apple_remove(struct hid_devi { struct apple_sc *asc = hid_get_drvdata(hdev); - timer_delete_sync(&asc->battery_timer); + if (asc->quirks & APPLE_RDESC_BATTERY) + timer_delete_sync(&asc->battery_timer); hid_hw_stop(hdev); } ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 479/480] usb: gadget : fix use-after-free in composite_dev_cleanup() 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (477 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 478/480] HID: apple: avoid setting up battery timer for devices without battery Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 17:51 ` [PATCH 6.15 480/480] mm: fix a UAF when vma->mm is freed after vma->vm_refcnt got dropped Greg Kroah-Hartman ` (12 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable; +Cc: Greg Kroah-Hartman, patches, stable, Tao Xue 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Tao Xue <xuetao09@huawei.com> commit 151c0aa896c47a4459e07fee7d4843f44c1bb18e upstream. 1. In func configfs_composite_bind() -> composite_os_desc_req_prepare(): if kmalloc fails, the pointer cdev->os_desc_req will be freed but not set to NULL. Then it will return a failure to the upper-level function. 2. in func configfs_composite_bind() -> composite_dev_cleanup(): it will checks whether cdev->os_desc_req is NULL. If it is not NULL, it will attempt to use it.This will lead to a use-after-free issue. BUG: KASAN: use-after-free in composite_dev_cleanup+0xf4/0x2c0 Read of size 8 at addr 0000004827837a00 by task init/1 CPU: 10 PID: 1 Comm: init Tainted: G O 5.10.97-oh #1 kasan_report+0x188/0x1cc __asan_load8+0xb4/0xbc composite_dev_cleanup+0xf4/0x2c0 configfs_composite_bind+0x210/0x7ac udc_bind_to_driver+0xb4/0x1ec usb_gadget_probe_driver+0xec/0x21c gadget_dev_desc_UDC_store+0x264/0x27c Fixes: 37a3a533429e ("usb: gadget: OS Feature Descriptors support") Cc: stable <stable@kernel.org> Signed-off-by: Tao Xue <xuetao09@huawei.com> Link: https://lore.kernel.org/r/20250721093908.14967-1-xuetao09@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/usb/gadget/composite.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/usb/gadget/composite.c +++ b/drivers/usb/gadget/composite.c @@ -2489,6 +2489,11 @@ int composite_os_desc_req_prepare(struct if (!cdev->os_desc_req->buf) { ret = -ENOMEM; usb_ep_free_request(ep0, cdev->os_desc_req); + /* + * Set os_desc_req to NULL so that composite_dev_cleanup() + * will not try to free it again. + */ + cdev->os_desc_req = NULL; goto end; } cdev->os_desc_req->context = cdev; ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH 6.15 480/480] mm: fix a UAF when vma->mm is freed after vma->vm_refcnt got dropped 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (478 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 479/480] usb: gadget : fix use-after-free in composite_dev_cleanup() Greg Kroah-Hartman @ 2025-08-12 17:51 ` Greg Kroah-Hartman 2025-08-12 19:57 ` [PATCH 6.15 000/480] 6.15.10-rc1 review Brett A C Sheffield ` (11 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2025-08-12 17:51 UTC (permalink / raw) To: stable Cc: Greg Kroah-Hartman, patches, Suren Baghdasaryan, Jann Horn, Vlastimil Babka, Lorenzo Stoakes, Liam Howlett, Andrew Morton 6.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Suren Baghdasaryan <surenb@google.com> commit 9bbffee67ffd16360179327b57f3b1245579ef08 upstream. By inducing delays in the right places, Jann Horn created a reproducer for a hard to hit UAF issue that became possible after VMAs were allowed to be recycled by adding SLAB_TYPESAFE_BY_RCU to their cache. Race description is borrowed from Jann's discovery report: lock_vma_under_rcu() looks up a VMA locklessly with mas_walk() under rcu_read_lock(). At that point, the VMA may be concurrently freed, and it can be recycled by another process. vma_start_read() then increments the vma->vm_refcnt (if it is in an acceptable range), and if this succeeds, vma_start_read() can return a recycled VMA. In this scenario where the VMA has been recycled, lock_vma_under_rcu() will then detect the mismatching ->vm_mm pointer and drop the VMA through vma_end_read(), which calls vma_refcount_put(). vma_refcount_put() drops the refcount and then calls rcuwait_wake_up() using a copy of vma->vm_mm. This is wrong: It implicitly assumes that the caller is keeping the VMA's mm alive, but in this scenario the caller has no relation to the VMA's mm, so the rcuwait_wake_up() can cause UAF. The diagram depicting the race: T1 T2 T3 == == == lock_vma_under_rcu mas_walk <VMA gets removed from mm> mmap <the same VMA is reallocated> vma_start_read __refcount_inc_not_zero_limited_acquire munmap __vma_enter_locked refcount_add_not_zero vma_end_read vma_refcount_put __refcount_dec_and_test rcuwait_wait_event <finish operation> rcuwait_wake_up [UAF] Note that rcuwait_wait_event() in T3 does not block because refcount was already dropped by T1. At this point T3 can exit and free the mm causing UAF in T1. To avoid this we move vma->vm_mm verification into vma_start_read() and grab vma->vm_mm to stabilize it before vma_refcount_put() operation. [surenb@google.com: v3] Link: https://lkml.kernel.org/r/20250729145709.2731370-1-surenb@google.com Link: https://lkml.kernel.org/r/20250728175355.2282375-1-surenb@google.com Fixes: 3104138517fc ("mm: make vma cache SLAB_TYPESAFE_BY_RCU") Signed-off-by: Suren Baghdasaryan <surenb@google.com> Reported-by: Jann Horn <jannh@google.com> Closes: https://lore.kernel.org/all/CAG48ez0-deFbVH=E3jbkWx=X3uVbd8nWeo6kbJPQ0KoUD+m2tA@mail.gmail.com/ Reviewed-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: Jann Horn <jannh@google.com> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Suren Baghdasaryan <surenb@google.com> --- include/linux/mm.h | 30 ++++++++++++++++++++++++++++++ mm/memory.c | 3 +-- 2 files changed, 31 insertions(+), 2 deletions(-) --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -33,6 +33,7 @@ #include <linux/slab.h> #include <linux/cacheinfo.h> #include <linux/rcuwait.h> +#include <linux/sched/mm.h> struct mempolicy; struct anon_vma; @@ -716,6 +717,10 @@ static inline void vma_refcount_put(stru * reused and attached to a different mm before we lock it. * Returns the vma on success, NULL on failure to lock and EAGAIN if vma got * detached. + * + * WARNING! The vma passed to this function cannot be used if the function + * fails to lock it because in certain cases RCU lock is dropped and then + * reacquired. Once RCU lock is dropped the vma can be concurently freed. */ static inline struct vm_area_struct *vma_start_read(struct mm_struct *mm, struct vm_area_struct *vma) @@ -745,6 +750,31 @@ static inline struct vm_area_struct *vma } rwsem_acquire_read(&vma->vmlock_dep_map, 0, 1, _RET_IP_); + + /* + * If vma got attached to another mm from under us, that mm is not + * stable and can be freed in the narrow window after vma->vm_refcnt + * is dropped and before rcuwait_wake_up(mm) is called. Grab it before + * releasing vma->vm_refcnt. + */ + if (unlikely(vma->vm_mm != mm)) { + /* Use a copy of vm_mm in case vma is freed after we drop vm_refcnt */ + struct mm_struct *other_mm = vma->vm_mm; + + /* + * __mmdrop() is a heavy operation and we don't need RCU + * protection here. Release RCU lock during these operations. + * We reinstate the RCU read lock as the caller expects it to + * be held when this function returns even on error. + */ + rcu_read_unlock(); + mmgrab(other_mm); + vma_refcount_put(vma); + mmdrop(other_mm); + rcu_read_lock(); + return NULL; + } + /* * Overflow of vm_lock_seq/mm_lock_seq might produce false locked result. * False unlocked result is impossible because we modify and check --- a/mm/memory.c +++ b/mm/memory.c @@ -6554,8 +6554,7 @@ retry: */ /* Check if the vma we locked is the right one. */ - if (unlikely(vma->vm_mm != mm || - address < vma->vm_start || address >= vma->vm_end)) + if (unlikely(address < vma->vm_start || address >= vma->vm_end)) goto inval_end_read; rcu_read_unlock(); ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 6.15 000/480] 6.15.10-rc1 review 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (479 preceding siblings ...) 2025-08-12 17:51 ` [PATCH 6.15 480/480] mm: fix a UAF when vma->mm is freed after vma->vm_refcnt got dropped Greg Kroah-Hartman @ 2025-08-12 19:57 ` Brett A C Sheffield 2025-08-12 20:22 ` Pavel Machek ` (10 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Brett A C Sheffield @ 2025-08-12 19:57 UTC (permalink / raw) To: gregkh Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie, achill, Brett A C Sheffield # Librecast Test Results 010/010 [ OK ] libmld 120/120 [ OK ] liblibrecast CPU/kernel: Linux auntie 6.15.10-rc1-g2510f67e2e34 #40 SMP PREEMPT_DYNAMIC Tue Aug 12 19:15:00 -00 2025 x86_64 AMD Ryzen 9 9950X 16-Core Processor AuthenticAMD GNU/Linux Tested-by: Brett A C Sheffield <bacs@librecast.net> ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 6.15 000/480] 6.15.10-rc1 review 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (480 preceding siblings ...) 2025-08-12 19:57 ` [PATCH 6.15 000/480] 6.15.10-rc1 review Brett A C Sheffield @ 2025-08-12 20:22 ` Pavel Machek 2025-08-12 21:09 ` Achill Gilgenast ` (9 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Pavel Machek @ 2025-08-12 20:22 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage, jonathanh, f.fainelli, sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie, achill [-- Attachment #1: Type: text/plain, Size: 885 bytes --] Hi! > This is the start of the stable review cycle for the 6.15.10 release. > There are 480 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, 14 Aug 2025 17:42:20 +0000. > Anything received after that time might be too late. CIP testing did not find any problems here: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.15.y 6.6 passes our testing, too: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.6.y Tested-by: Pavel Machek (CIP) <pavel@denx.de> Best regards, Pavel -- In cooperation with DENX Software Engineering GmbH, HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 6.15 000/480] 6.15.10-rc1 review 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (481 preceding siblings ...) 2025-08-12 20:22 ` Pavel Machek @ 2025-08-12 21:09 ` Achill Gilgenast 2025-08-12 21:47 ` Florian Fainelli ` (8 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Achill Gilgenast @ 2025-08-12 21:09 UTC (permalink / raw) To: Greg Kroah-Hartman, stable Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie On Tue Aug 12, 2025 at 7:43 PM CEST, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 6.15.10 release. > There are 480 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, 14 Aug 2025 17:42:20 +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/v6.x/stable-review/patch-6.15.10-rc1.gz > or in the git tree and branch at: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.15.y > and the diffstat can be found below. > > thanks, > > greg k-h Thanks, build-tested on all Alpine architectures and boot-tested on x86_64. Tested-By: Achill Gilgenast <achill@achill.org> ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 6.15 000/480] 6.15.10-rc1 review 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (482 preceding siblings ...) 2025-08-12 21:09 ` Achill Gilgenast @ 2025-08-12 21:47 ` Florian Fainelli 2025-08-13 3:48 ` Peter Schneider ` (7 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Florian Fainelli @ 2025-08-12 21:47 UTC (permalink / raw) To: Greg Kroah-Hartman, stable Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage, pavel, jonathanh, sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie, achill On 8/12/2025 10:43 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 6.15.10 release. > There are 480 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, 14 Aug 2025 17:42:20 +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/v6.x/stable-review/patch-6.15.10-rc1.gz > or in the git tree and branch at: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.15.y > and the diffstat can be found below. > > thanks, > > greg k-h On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC: Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> -- Florian ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 6.15 000/480] 6.15.10-rc1 review 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (483 preceding siblings ...) 2025-08-12 21:47 ` Florian Fainelli @ 2025-08-13 3:48 ` Peter Schneider 2025-08-13 13:57 ` Mark Brown ` (6 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Peter Schneider @ 2025-08-13 3:48 UTC (permalink / raw) To: Greg Kroah-Hartman, stable Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie, achill Am 12.08.2025 um 19:43 schrieb Greg Kroah-Hartman: > This is the start of the stable review cycle for the 6.15.10 release. > There are 480 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. Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. Built with GCC 14.2 on Debian Trixie. No dmesg oddities or regressions found. I did not see any of the Python warning messages here which I did see in the 6.1.148-rc1 build. Tested-by: Peter Schneider <pschneider1968@googlemail.com> Beste Grüße, Peter Schneider -- Climb the mountain not to plant your flag, but to embrace the challenge, enjoy the air and behold the view. Climb it so you can see the world, not so the world can see you. -- David McCullough Jr. OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244 Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc https://keys.mailvelope.com/pks/lookup?op=get&search=pschneider1968@googlemail.com https://keys.mailvelope.com/pks/lookup?op=get&search=pschneider1968@gmail.com ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 6.15 000/480] 6.15.10-rc1 review 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (484 preceding siblings ...) 2025-08-13 3:48 ` Peter Schneider @ 2025-08-13 13:57 ` Mark Brown 2025-08-13 15:07 ` Shuah Khan ` (5 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Mark Brown @ 2025-08-13 13:57 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw, rwarsow, conor, hargar, achill [-- Attachment #1: Type: text/plain, Size: 346 bytes --] On Tue, Aug 12, 2025 at 07:43:28PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 6.15.10 release. > There are 480 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. Tested-by: Mark Brown <broonie@kernel.org> [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 6.15 000/480] 6.15.10-rc1 review 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (485 preceding siblings ...) 2025-08-13 13:57 ` Mark Brown @ 2025-08-13 15:07 ` Shuah Khan 2025-08-13 15:48 ` Jon Hunter ` (4 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Shuah Khan @ 2025-08-13 15:07 UTC (permalink / raw) To: Greg Kroah-Hartman, stable Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie, achill, Shuah Khan On 8/12/25 11:43, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 6.15.10 release. > There are 480 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, 14 Aug 2025 17:42:20 +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/v6.x/stable-review/patch-6.15.10-rc1.gz > or in the git tree and branch at: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.15.y > and the diffstat can be found below. > > thanks, > > greg k-h > Compiled and booted on my test system. No dmesg regressions. Tested-by: Shuah Khan <skhan@linuxfoundation.org> thanks, -- Shuah ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 6.15 000/480] 6.15.10-rc1 review 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (486 preceding siblings ...) 2025-08-13 15:07 ` Shuah Khan @ 2025-08-13 15:48 ` Jon Hunter 2025-08-13 17:25 ` Jon Hunter 2025-08-13 20:15 ` [PATCH 6.15 000/480] 6.15.10-rc1 review Justin Forbes ` (3 subsequent siblings) 491 siblings, 1 reply; 1767+ messages in thread From: Jon Hunter @ 2025-08-13 15:48 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Greg Kroah-Hartman, patches, linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie, achill, linux-tegra, stable On Tue, 12 Aug 2025 19:43:28 +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 6.15.10 release. > There are 480 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, 14 Aug 2025 17:42:20 +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/v6.x/stable-review/patch-6.15.10-rc1.gz > or in the git tree and branch at: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.15.y > and the diffstat can be found below. > > thanks, > > greg k-h Failures detected for Tegra ... Test results for stable-v6.15: 10 builds: 10 pass, 0 fail 28 boots: 28 pass, 0 fail 120 tests: 119 pass, 1 fail Linux version: 6.15.10-rc1-g2510f67e2e34 Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000, tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000, tegra20-ventana, tegra210-p2371-2180, tegra210-p3450-0000, tegra30-cardhu-a04 Test failures: tegra194-p2972-0000: boot.py Jon ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) 2025-08-13 15:48 ` Jon Hunter @ 2025-08-13 17:25 ` Jon Hunter 2025-08-13 22:07 ` [PATCH 6.15 000/480] 6.15.10-rc1 review Ron Economos 2025-08-14 15:36 ` Greg KH 0 siblings, 2 replies; 1767+ messages in thread From: Jon Hunter @ 2025-08-13 17:25 UTC (permalink / raw) To: jonathanh Cc: achill, akpm, broonie, conor, f.fainelli, gregkh, hargar, linux-kernel, linux-tegra, linux, lkft-triage, patches, patches, pavel, rwarsow, shuah, srw, stable, sudipm.mukherjee, torvalds [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="y", Size: 1971 bytes --] From: Jon Hunter <jonathanh@nvidia.com> Date: Wed, 13 Aug 2025 18:18:01 +0100 Subject: Re: [PATCH 6.15 000/480] 6.15.10-rc1 review X-NVConfidentiality: public On Wed, Aug 13, 2025 at 08:48:28AM -0700, Jon Hunter wrote: > On Tue, 12 Aug 2025 19:43:28 +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 6.15.10 release. > > There are 480 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, 14 Aug 2025 17:42:20 +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/v6.x/stable-review/patch-6.15.10-rc1.gz > > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.15.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > Failures detected for Tegra ... > > Test results for stable-v6.15: > 10 builds: 10 pass, 0 fail > 28 boots: 28 pass, 0 fail > 120 tests: 119 pass, 1 fail > > Linux version: 6.15.10-rc1-g2510f67e2e34 > Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000, > tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000, > tegra194-p3509-0000+p3668-0000, tegra20-ventana, > tegra210-p2371-2180, tegra210-p3450-0000, > tegra30-cardhu-a04 > > Test failures: tegra194-p2972-0000: boot.py I am seeing the following kernel warning for both linux-6.15.y and linux-6.16.y … WARNING KERN sched: DL replenish lagged too much I believe that this is introduced by … Peter Zijlstra <peterz@infradead.org> sched/deadline: Less agressive dl_server handling This has been reported here: https://lore.kernel.org/all/CAMuHMdXn4z1pioTtBGMfQM0jsLviqS2jwysaWXpoLxWYoGa82w@mail.gmail.com/ Jon ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 6.15 000/480] 6.15.10-rc1 review 2025-08-13 17:25 ` Jon Hunter @ 2025-08-13 22:07 ` Ron Economos 2025-08-14 15:36 ` Greg KH 1 sibling, 0 replies; 1767+ messages in thread From: Ron Economos @ 2025-08-13 22:07 UTC (permalink / raw) To: Jon Hunter Cc: achill, akpm, broonie, conor, f.fainelli, gregkh, hargar, linux-kernel, linux-tegra, linux, lkft-triage, patches, patches, pavel, rwarsow, shuah, srw, stable, sudipm.mukherjee, torvalds On 8/13/25 10:25, Jon Hunter wrote: > On Wed, Aug 13, 2025 at 08:48:28AM -0700, Jon Hunter wrote: >> On Tue, 12 Aug 2025 19:43:28 +0200, Greg Kroah-Hartman wrote: >>> This is the start of the stable review cycle for the 6.15.10 release. >>> There are 480 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, 14 Aug 2025 17:42:20 +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/v6.x/stable-review/patch-6.15.10-rc1.gz >>> or in the git tree and branch at: >>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.15.y >>> and the diffstat can be found below. >>> >>> thanks, >>> >>> greg k-h >> Failures detected for Tegra ... >> >> Test results for stable-v6.15: >> 10 builds: 10 pass, 0 fail >> 28 boots: 28 pass, 0 fail >> 120 tests: 119 pass, 1 fail >> >> Linux version: 6.15.10-rc1-g2510f67e2e34 >> Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000, >> tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000, >> tegra194-p3509-0000+p3668-0000, tegra20-ventana, >> tegra210-p2371-2180, tegra210-p3450-0000, >> tegra30-cardhu-a04 >> >> Test failures: tegra194-p2972-0000: boot.py > I am seeing the following kernel warning for both linux-6.15.y and linux-6.16.y … > > WARNING KERN sched: DL replenish lagged too much > > I believe that this is introduced by … > > Peter Zijlstra <peterz@infradead.org> > sched/deadline: Less agressive dl_server handling > > This has been reported here: https://lore.kernel.org/all/CAMuHMdXn4z1pioTtBGMfQM0jsLviqS2jwysaWXpoLxWYoGa82w@mail.gmail.com/ > > Jon Seeing this kernel warning on RISC-V also. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-08-13 17:25 ` Jon Hunter 2025-08-13 22:07 ` [PATCH 6.15 000/480] 6.15.10-rc1 review Ron Economos @ 2025-08-14 15:36 ` Greg KH 2025-08-15 16:20 ` Re: Jon Hunter 1 sibling, 1 reply; 1767+ messages in thread From: Greg KH @ 2025-08-14 15:36 UTC (permalink / raw) To: Jon Hunter Cc: achill, akpm, broonie, conor, f.fainelli, hargar, linux-kernel, linux-tegra, linux, lkft-triage, patches, patches, pavel, rwarsow, shuah, srw, stable, sudipm.mukherjee, torvalds On Wed, Aug 13, 2025 at 06:25:32PM +0100, Jon Hunter wrote: > On Wed, Aug 13, 2025 at 08:48:28AM -0700, Jon Hunter wrote: > > On Tue, 12 Aug 2025 19:43:28 +0200, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 6.15.10 release. > > > There are 480 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, 14 Aug 2025 17:42:20 +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/v6.x/stable-review/patch-6.15.10-rc1.gz > > > or in the git tree and branch at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.15.y > > > and the diffstat can be found below. > > > > > > thanks, > > > > > > greg k-h > > > > Failures detected for Tegra ... > > > > Test results for stable-v6.15: > > 10 builds: 10 pass, 0 fail > > 28 boots: 28 pass, 0 fail > > 120 tests: 119 pass, 1 fail > > > > Linux version: 6.15.10-rc1-g2510f67e2e34 > > Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000, > > tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000, > > tegra194-p3509-0000+p3668-0000, tegra20-ventana, > > tegra210-p2371-2180, tegra210-p3450-0000, > > tegra30-cardhu-a04 > > > > Test failures: tegra194-p2972-0000: boot.py > > I am seeing the following kernel warning for both linux-6.15.y and linux-6.16.y … > > WARNING KERN sched: DL replenish lagged too much > > I believe that this is introduced by … > > Peter Zijlstra <peterz@infradead.org> > sched/deadline: Less agressive dl_server handling > > This has been reported here: https://lore.kernel.org/all/CAMuHMdXn4z1pioTtBGMfQM0jsLviqS2jwysaWXpoLxWYoGa82w@mail.gmail.com/ I've now dropped this. Is that causing the test failure for you? thanks, greg k-h ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-08-14 15:36 ` Greg KH @ 2025-08-15 16:20 ` Jon Hunter 2025-08-15 16:53 ` Re: Greg KH 0 siblings, 1 reply; 1767+ messages in thread From: Jon Hunter @ 2025-08-15 16:20 UTC (permalink / raw) To: Greg KH Cc: achill, akpm, broonie, conor, f.fainelli, hargar, linux-kernel, linux-tegra, linux, lkft-triage, patches, patches, pavel, rwarsow, shuah, srw, stable, sudipm.mukherjee, torvalds On 14/08/2025 16:36, Greg KH wrote: > On Wed, Aug 13, 2025 at 06:25:32PM +0100, Jon Hunter wrote: >> On Wed, Aug 13, 2025 at 08:48:28AM -0700, Jon Hunter wrote: >>> On Tue, 12 Aug 2025 19:43:28 +0200, Greg Kroah-Hartman wrote: >>>> This is the start of the stable review cycle for the 6.15.10 release. >>>> There are 480 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, 14 Aug 2025 17:42:20 +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/v6.x/stable-review/patch-6.15.10-rc1.gz >>>> or in the git tree and branch at: >>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.15.y >>>> and the diffstat can be found below. >>>> >>>> thanks, >>>> >>>> greg k-h >>> >>> Failures detected for Tegra ... >>> >>> Test results for stable-v6.15: >>> 10 builds: 10 pass, 0 fail >>> 28 boots: 28 pass, 0 fail >>> 120 tests: 119 pass, 1 fail >>> >>> Linux version: 6.15.10-rc1-g2510f67e2e34 >>> Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000, >>> tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000, >>> tegra194-p3509-0000+p3668-0000, tegra20-ventana, >>> tegra210-p2371-2180, tegra210-p3450-0000, >>> tegra30-cardhu-a04 >>> >>> Test failures: tegra194-p2972-0000: boot.py >> >> I am seeing the following kernel warning for both linux-6.15.y and linux-6.16.y … >> >> WARNING KERN sched: DL replenish lagged too much >> >> I believe that this is introduced by … >> >> Peter Zijlstra <peterz@infradead.org> >> sched/deadline: Less agressive dl_server handling >> >> This has been reported here: https://lore.kernel.org/all/CAMuHMdXn4z1pioTtBGMfQM0jsLviqS2jwysaWXpoLxWYoGa82w@mail.gmail.com/ > > I've now dropped this. > > Is that causing the test failure for you? Yes that is causing the test failure. Thanks! Jon -- nvpublic ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-08-15 16:20 ` Re: Jon Hunter @ 2025-08-15 16:53 ` Greg KH 0 siblings, 0 replies; 1767+ messages in thread From: Greg KH @ 2025-08-15 16:53 UTC (permalink / raw) To: Jon Hunter Cc: achill, akpm, broonie, conor, f.fainelli, hargar, linux-kernel, linux-tegra, linux, lkft-triage, patches, patches, pavel, rwarsow, shuah, srw, stable, sudipm.mukherjee, torvalds On Fri, Aug 15, 2025 at 05:20:34PM +0100, Jon Hunter wrote: > On 14/08/2025 16:36, Greg KH wrote: > > On Wed, Aug 13, 2025 at 06:25:32PM +0100, Jon Hunter wrote: > > > On Wed, Aug 13, 2025 at 08:48:28AM -0700, Jon Hunter wrote: > > > > On Tue, 12 Aug 2025 19:43:28 +0200, Greg Kroah-Hartman wrote: > > > > > This is the start of the stable review cycle for the 6.15.10 release. > > > > > There are 480 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, 14 Aug 2025 17:42:20 +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/v6.x/stable-review/patch-6.15.10-rc1.gz > > > > > or in the git tree and branch at: > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.15.y > > > > > and the diffstat can be found below. > > > > > > > > > > thanks, > > > > > > > > > > greg k-h > > > > > > > > Failures detected for Tegra ... > > > > > > > > Test results for stable-v6.15: > > > > 10 builds: 10 pass, 0 fail > > > > 28 boots: 28 pass, 0 fail > > > > 120 tests: 119 pass, 1 fail > > > > > > > > Linux version: 6.15.10-rc1-g2510f67e2e34 > > > > Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000, > > > > tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000, > > > > tegra194-p3509-0000+p3668-0000, tegra20-ventana, > > > > tegra210-p2371-2180, tegra210-p3450-0000, > > > > tegra30-cardhu-a04 > > > > > > > > Test failures: tegra194-p2972-0000: boot.py > > > > > > I am seeing the following kernel warning for both linux-6.15.y and linux-6.16.y … > > > > > > WARNING KERN sched: DL replenish lagged too much > > > > > > I believe that this is introduced by … > > > > > > Peter Zijlstra <peterz@infradead.org> > > > sched/deadline: Less agressive dl_server handling > > > > > > This has been reported here: https://lore.kernel.org/all/CAMuHMdXn4z1pioTtBGMfQM0jsLviqS2jwysaWXpoLxWYoGa82w@mail.gmail.com/ > > > > I've now dropped this. > > > > Is that causing the test failure for you? > > Yes that is causing the test failure. Thanks! Is the test just noticing the warning message? Or is it a functional failure? Does it also fail on Linus's tree? thanks, greg k-h ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 6.15 000/480] 6.15.10-rc1 review 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (487 preceding siblings ...) 2025-08-13 15:48 ` Jon Hunter @ 2025-08-13 20:15 ` Justin Forbes 2025-08-13 21:33 ` Ron Economos ` (2 subsequent siblings) 491 siblings, 0 replies; 1767+ messages in thread From: Justin Forbes @ 2025-08-13 20:15 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie, achill On Tue, Aug 12, 2025 at 07:43:28PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 6.15.10 release. > There are 480 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, 14 Aug 2025 17:42:20 +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/v6.x/stable-review/patch-6.15.10-rc1.gz > or in the git tree and branch at: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.15.y > and the diffstat can be found below. > > thanks, > > greg k-h Tested rc1 against the Fedora build system (aarch64, ppc64le, s390x, x86_64), and boot tested x86_64. No regressions noted. Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 6.15 000/480] 6.15.10-rc1 review 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (488 preceding siblings ...) 2025-08-13 20:15 ` [PATCH 6.15 000/480] 6.15.10-rc1 review Justin Forbes @ 2025-08-13 21:33 ` Ron Economos 2025-08-14 6:18 ` Naresh Kamboju 2025-08-14 14:50 ` Miguel Ojeda 491 siblings, 0 replies; 1767+ messages in thread From: Ron Economos @ 2025-08-13 21:33 UTC (permalink / raw) To: Greg Kroah-Hartman, stable Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie, achill On 8/12/25 10:43, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 6.15.10 release. > There are 480 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, 14 Aug 2025 17:42:20 +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/v6.x/stable-review/patch-6.15.10-rc1.gz > or in the git tree and branch at: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.15.y > and the diffstat can be found below. > > thanks, > > greg k-h Built and booted successfully on RISC-V RV64 (HiFive Unmatched). Tested-by: Ron Economos <re@w6rz.net> ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 6.15 000/480] 6.15.10-rc1 review 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (489 preceding siblings ...) 2025-08-13 21:33 ` Ron Economos @ 2025-08-14 6:18 ` Naresh Kamboju 2025-08-14 14:50 ` Miguel Ojeda 491 siblings, 0 replies; 1767+ messages in thread From: Naresh Kamboju @ 2025-08-14 6:18 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie, achill On Wed, 13 Aug 2025 at 00:32, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > This is the start of the stable review cycle for the 6.15.10 release. > There are 480 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, 14 Aug 2025 17:42:20 +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/v6.x/stable-review/patch-6.15.10-rc1.gz > or in the git tree and branch at: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.15.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> ## Build * kernel: 6.15.10-rc1 * git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git * git commit: 2510f67e2e346f399c76101231d19be2bc0844da * git describe: v6.15.9-481-g2510f67e2e34 * test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.15.y/build/v6.15.9-481-g2510f67e2e34 ## Test Regressions (compared to v6.15.8-93-gd9420fe2ce8c) ## Metric Regressions (compared to v6.15.8-93-gd9420fe2ce8c) ## Test Fixes (compared to v6.15.8-93-gd9420fe2ce8c) ## Metric Fixes (compared to v6.15.8-93-gd9420fe2ce8c) ## Test result summary total: 328235, pass: 307085, fail: 6419, skip: 14731, xfail: 0 ## Build Summary * arc: 5 total, 5 passed, 0 failed * arm: 139 total, 138 passed, 1 failed * arm64: 57 total, 56 passed, 1 failed * i386: 18 total, 18 passed, 0 failed * mips: 34 total, 27 passed, 7 failed * parisc: 4 total, 4 passed, 0 failed * powerpc: 40 total, 39 passed, 1 failed * riscv: 25 total, 24 passed, 1 failed * s390: 22 total, 22 passed, 0 failed * sh: 5 total, 5 passed, 0 failed * sparc: 4 total, 3 passed, 1 failed * x86_64: 49 total, 48 passed, 1 failed ## Test suites summary * boot * commands * kselftest-arm64 * kselftest-breakpoints * kselftest-capabilities * kselftest-cgroup * kselftest-clone3 * kselftest-core * kselftest-cpu-hotplug * kselftest-cpufreq * kselftest-efivarfs * kselftest-exec * kselftest-fpu * kselftest-ftrace * kselftest-futex * kselftest-gpio * kselftest-intel_pstate * kselftest-ipc * kselftest-kcmp * kselftest-kvm * kselftest-livepatch * kselftest-membarrier * kselftest-memfd * kselftest-mincore * kselftest-mm * kselftest-mqueue * kselftest-net * kselftest-net-mptcp * kselftest-openat2 * kselftest-ptrace * kselftest-rseq * kselftest-rtc * kselftest-rust * kselftest-seccomp * kselftest-sigaltstack * kselftest-size * kselftest-tc-testing * kselftest-timers * kselftest-tmpfs * kselftest-tpm2 * kselftest-user_events * kselftest-vDSO * kselftest-x86 * kunit * kvm-unit-tests * lava * libgpiod * libhugetlbfs * log-parser-boot * log-parser-build-clang * log-parser-build-gcc * log-parser-test * ltp-capability * ltp-commands * ltp-containers * ltp-controllers * ltp-cpuhotplug * ltp-crypto * ltp-cve * ltp-dio * ltp-fcntl-locktests * ltp-fs * ltp-fs_bind * ltp-fs_perms_simple * ltp-hugetlb * ltp-math * ltp-mm * ltp-nptl * ltp-pty * ltp-sched * ltp-smoke * ltp-syscalls * ltp-tracing * modules * perf * rcutorture * rt-tests-cyclicdeadline * rt-tests-pi-stress * rt-tests-pmqtest * rt-tests-rt-migrate-test * rt-tests-signaltest -- Linaro LKFT https://lkft.linaro.org ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 6.15 000/480] 6.15.10-rc1 review 2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman ` (490 preceding siblings ...) 2025-08-14 6:18 ` Naresh Kamboju @ 2025-08-14 14:50 ` Miguel Ojeda 491 siblings, 0 replies; 1767+ messages in thread From: Miguel Ojeda @ 2025-08-14 14:50 UTC (permalink / raw) To: gregkh Cc: achill, akpm, broonie, conor, f.fainelli, hargar, jonathanh, linux-kernel, linux, lkft-triage, patches, patches, pavel, rwarsow, shuah, srw, stable, sudipm.mukherjee, torvalds, Miguel Ojeda On Tue, 12 Aug 2025 19:43:28 +0200 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > This is the start of the stable review cycle for the 6.15.10 release. > There are 480 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, 14 Aug 2025 17:42:20 +0000. > Anything received after that time might be too late. Boot-tested under QEMU for Rust x86_64, arm64 and riscv64; built-tested for loongarch64: Tested-by: Miguel Ojeda <ojeda@kernel.org> Thanks! Cheers, Miguel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2026-05-09 18:01 Andrea Righi
2026-05-09 18:07 ` Andrea Righi
0 siblings, 1 reply; 1767+ messages in thread
From: Andrea Righi @ 2026-05-09 18:01 UTC (permalink / raw)
To: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot
Cc: Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, K Prateek Nayak, Christian Loehle, Phil Auld,
Koba Ko, Felix Abecassis, Balbir Singh, Joel Fernandes,
Shrikanth Hegde, linux-kernel
This series attempts to improve SD_ASYM_CPUCAPACITY scheduling by introducing
SMT awareness.
= Problem =
Nominal per-logical-CPU capacity can overstate usable compute when an SMT
sibling is busy, because the physical core doesn't deliver its full nominal
capacity. So, several asym-cpu-capacity paths may pick high capacity idle CPUs
that are not actually good destinations.
= Solution =
This patch set aligns those paths with a simple rule already used elsewhere:
when SMT is active, prefer fully idle cores and avoid treating partially idle
SMT siblings as full-capacity targets where that would mislead load balance.
Patch set summary:
- Attach sched_domain_shared to sd_asym_cpucapacity in SD_ASYM_CPUCAPACITY to
use has_idle_cores hint consistently in the wakeup idle scan and rename
sd_llc_shared -> sd_balance_shared.
- Prefer fully-idle SMT cores in asym-capacity idle selection: in the wakeup
fast path, extend select_idle_capacity() / asym_fits_cpu() so idle
selection can prefer CPUs on fully idle cores.
- Reject misfit pulls onto busy SMT siblings on SD_ASYM_CPUCAPACITY.
- Add SIS_UTIL support to select_idle_capacity(): add to select_idle_capacity()
the same SIS_UTIL-controlled idle-scan mechanism, already used by
select_idle_cpu().
This patch set has been tested on the new NVIDIA Vera Rubin platform, where SMT
is enabled and the firmware exposes small frequency variations (+/-~5%) as
differences in CPU capacity, resulting in SD_ASYM_CPUCAPACITY being set.
Without these patches, performance can drop by up to ~2x with CPU-intensive
workloads, because the SD_ASYM_CPUCAPACITY idle selection policy does not
account for busy SMT siblings.
Alternative approaches have been evaluated, such as equalizing CPU capacities,
either by exposing uniform values via firmware or normalizing them in the kernel
by grouping CPUs within a small capacity window (+-5%).
However, the SMT-aware SD_ASYM_CPUCAPACITY approach has shown better results so
far. Improving this policy also seems worthwhile in general, as future platforms
may enable SMT with asymmetric CPU topologies.
Performance results on Vera Rubin with SD_ASYM_CPUCAPACITY (mainline) vs
SD_ASYM_CPUCAPACITY + SMT
- NVBLAS benchblas (one task / SMT core):
+---------------------------------+--------+
| Configuration | gflops |
+---------------------------------+--------+
| ASYM (mainline) + SIS_UTIL | 5478 |
| ASYM (mainline) + NO_SIS_UTIL | 5491 |
| | |
| NO ASYM + SIS_UTIL | 8912 |
| NO ASYM + NO_SIS_UTIL | 8978 |
| | |
| ASYM + SMT + SIS_UTIL | 9259 |
| ASYM + SMT + NO_SIS_UTIL | 9291 |
+---------------------------------+--------+
- DCPerf MediaWiki (all CPUs):
+---------------------------------+--------+--------+--------+--------+
| Configuration | rps | p50 | p95 | p99 |
+---------------------------------+--------+--------+--------+--------+
| ASYM (mainline) + SIS_UTIL | 7994 | 0.052 | 0.223 | 0.246 |
| ASYM (mainline) + NO_SIS_UTIL | 7993 | 0.052 | 0.221 | 0.245 |
| | | | | |
| NO ASYM + SIS_UTIL | 8113 | 0.067 | 0.184 | 0.225 |
| NO ASYM + NO_SIS_UTIL | 8093 | 0.068 | 0.184 | 0.223 |
| | | | | |
| ASYM + SMT + SIS_UTIL | 8129 | 0.076 | 0.149 | 0.188 |
| ASYM + SMT + NO_SIS_UTIL | 8138 | 0.076 | 0.148 | 0.186 |
+---------------------------------+--------+--------+--------+--------+
In the MediaWiki case SMT awareness is less impactful, because for the majority
of the run all CPUs are used, but it still seems to provide some benefits at
reducing tail latency.
Tests have also been conducted on NVIDIA Grace (which does not support SMT) to
ensure that SIS_UTIL support in select_idle_capacity() does not introduce
regressions and results show slight improvements under the same workloads.
See also:
- https://lore.kernel.org/lkml/20260324005509.1134981-1-arighi@nvidia.com
- https://lore.kernel.org/lkml/20260318092214.130908-1-arighi@nvidia.com
Changes in v6:
- Simplify the SIS_UTIL early-exit in select_idle_capacity(): drop the
best_fits == ASYM_IDLE_CORE_UCLAMP_MISFIT guard and exit once the scan
budget is exhausted, matching select_idle_cpu() (Dietmar Eggemann)
- Move the sd_llc_shared -> sd_balance_shared rename in nohz_balancer_kick()
from the NOHZ RCU cleanup patch into the sd_asym_cpucapacity attach patch,
where it logically belongs (Dietmar Eggemann)
- Rename prefers_idle_core to has_idle_core in select_idle_capacity()
(Dietmar Eggemann)
- Use ASYM_IDLE_CORE_COMPLETE_MISFIT instead of ASYM_IDLE_CORE_BIAS in the
select_idle_capacity() comments (Vincent Guittot)
- Expand the asym_fits_state docstring with a per-rank table and an
explanation of ASYM_IDLE_CORE_BIAS as an offset rather than a state
- Small code comment adjustments based on previous reviews
- Link to v5: https://lore.kernel.org/all/20260428144352.3575863-1-arighi@nvidia.com
Changes in v5:
- Drop redundant RCU protection in nohz_balancer_kick() (Prateek Nayak)
- Do not remove CPU capacity asymmetry / SMT warning (Prateek Nayak)
- Link to v4: https://lore.kernel.org/all/20260428051720.3180182-1-arighi@nvidia.com
Changes in v4:
- Rename sd_llc_shared -> sd_balance_shared
- Add preliminary cleanup patch to use guard(rcu)() for sched_domain RCU
(Prateek Nayak)
- Apply SIS_UTIL scan cap only with !prefers_idle_core, matching
select_idle_cpu() / has_idle_core logic (Vincent Guittot)
- Cache env->dst_cpu idle state to reduce is_core_idle() calls (Prateek Nayak)
- Remove warning about CPU capacity asymmetry not supporting SMT
- Link to v3: https://lore.kernel.org/all/20260423074135.380390-1-arighi@nvidia.com
Changes in v3:
- Add SIS_UTIL support to select_idle_capacity() (K Prateek Nayak)
- Attach sched_domain_shared to sd_asym_cpucapacity (K Prateek Nayak)
- Add enum for the different fit state (K Prateek Nayak)
- Update has_idle_cores hint (Vincent Guittot)
- Link to v2: https://lore.kernel.org/all/20260403053654.1559142-1-arighi@nvidia.com
Changes in v2:
- Rework SMT awareness logic in select_idle_capacity() (K Prateek Nayak)
- Drop EAS and find_new_ilb() changes for now
- Link to v1: https://lore.kernel.org/all/20260326151211.1862600-1-arighi@nvidia.com
Git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arighi/linux.git sched-asym-smt-v6
Andrea Righi (3):
sched/fair: Drop redundant RCU read lock in NOHZ kick path
sched/fair: Prefer fully-idle SMT cores in asym-capacity idle selection
sched/fair: Reject misfit pulls onto busy SMT siblings on asym-capacity
K Prateek Nayak (2):
sched/fair: Attach sched_domain_shared to sd_asym_cpucapacity
sched/fair: Add SIS_UTIL support to select_idle_capacity()
kernel/sched/fair.c | 206 ++++++++++++++++++++++++++++++++++++++----------
kernel/sched/sched.h | 2 +-
kernel/sched/topology.c | 95 +++++++++++++++++++---
3 files changed, 248 insertions(+), 55 deletions(-)
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2026-05-09 18:01 Andrea Righi @ 2026-05-09 18:07 ` Andrea Righi 0 siblings, 0 replies; 1767+ messages in thread From: Andrea Righi @ 2026-05-09 18:07 UTC (permalink / raw) To: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot Cc: Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman, Valentin Schneider, K Prateek Nayak, Christian Loehle, Phil Auld, Koba Ko, Felix Abecassis, Balbir Singh, Joel Fernandes, Shrikanth Hegde, linux-kernel On Sat, May 09, 2026 at 08:01:20PM +0200, Andrea Righi wrote: > This series attempts to improve SD_ASYM_CPUCAPACITY scheduling by introducing > SMT awareness. Somehow I messed up the subject in the cover letter, I'll re-send. Ignore this one and sorry for the noise. -Andrea ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2026-04-28 18:24 Fabio M. De Francesco 2026-05-01 22:01 ` Dave Jiang 0 siblings, 1 reply; 1767+ messages in thread From: Fabio M. De Francesco @ 2026-04-28 18:24 UTC (permalink / raw) To: linux-cxl Cc: Davidlohr Bueso, Jonathan Cameron, Dave Jiang, Alison Schofield, Vishal Verma, Ira Weiny, Dan Williams, Bjorn Helgaas, linux-kernel, linux-pci, Fabio M. De Francesco Subject: [PATCH 0/2] PCI/CXL: Recover CXL Downstream Ports from PM Init failure CXL r4.0 sec 8.1.5.1 Implementation Note describes a scenario in which a Secondary Bus Reset, a Link Down, or Downstream Port Containment on a CXL Downstream Port prevents Port PM Init from completing when ACS Source Validation is enabled on the Downstream Port. The spec states that another SBR alone does not recover the port and describes a software recovery sequence. Patch 1 extends cxl_reset_bus_function(), the helper backing the cxl_bus PCI/CXL reset method exposed to userspace via sysfs. It saves, clears, and restores ACS Source Validation and Bus Master Enable on the CXL Downstream Port around the SBR it issues. This keeps the userspace cxl_bus reset path from leaving the port unable to complete PM Init. Patch 2 adds a recovery pass during CXL enumeration. For each CXL Downstream Port in a memdev's ancestry, the CXL core checks whether PM Init has completed. If it has not, regardless of what caused the failure, it invokes cxl_reset_bus_function() on the child below the port in the hope of restoring the port to a usable state. CXL enumeration re-runs after events that tear down and re-probe the memdev, including DPC, AER, and Link Down, so those paths reach this recovery. This small series is developed from an old RFC v3: https://lore.kernel.org/linux-cxl/20260330193347.25072-1-fabio.m.de.francesco@linux.intel.com/ Fabio M. De Francesco (2): PCI/CXL: Allow PM Init to complete on cxl_bus reset if ACS SV enabled cxl/core: Recover from PM Init failure via cxl_reset_bus_function() drivers/cxl/core/pci.c | 30 ++++++++++++++++++++ drivers/cxl/core/port.c | 22 +++++++++++++++ drivers/cxl/cxlpci.h | 3 ++ drivers/pci/pci.c | 52 ++++++++++++++++++++++++++++++++++- include/linux/pci.h | 1 + include/uapi/linux/pci_regs.h | 2 ++ 6 files changed, 109 insertions(+), 1 deletion(-) -- 2.53.0 ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2026-04-28 18:24 Fabio M. De Francesco @ 2026-05-01 22:01 ` Dave Jiang 0 siblings, 0 replies; 1767+ messages in thread From: Dave Jiang @ 2026-05-01 22:01 UTC (permalink / raw) To: Fabio M. De Francesco, linux-cxl Cc: Davidlohr Bueso, Jonathan Cameron, Alison Schofield, Vishal Verma, Ira Weiny, Dan Williams, Bjorn Helgaas, linux-kernel, linux-pci On 4/28/26 11:24 AM, Fabio M. De Francesco wrote: > Subject: [PATCH 0/2] PCI/CXL: Recover CXL Downstream Ports from PM Init failure > > CXL r4.0 sec 8.1.5.1 Implementation Note describes a scenario in which a > Secondary Bus Reset, a Link Down, or Downstream Port Containment on a I'm not sure if this series covers a Link Down event (i.e. hotplug). As I recall, cxl_reset_bus_function() only happens via sysfs trigger. DJ > CXL Downstream Port prevents Port PM Init from completing when ACS > Source Validation is enabled on the Downstream Port. The spec states > that another SBR alone does not recover the port and describes a > software recovery sequence. > > Patch 1 extends cxl_reset_bus_function(), the helper backing the cxl_bus > PCI/CXL reset method exposed to userspace via sysfs. It saves, clears, > and restores ACS Source Validation and Bus Master Enable on the CXL > Downstream Port around the SBR it issues. This keeps the userspace > cxl_bus reset path from leaving the port unable to complete PM Init. > > Patch 2 adds a recovery pass during CXL enumeration. For each CXL > Downstream Port in a memdev's ancestry, the CXL core checks whether PM > Init has completed. If it has not, regardless of what caused the > failure, it invokes cxl_reset_bus_function() on the child below the port > in the hope of restoring the port to a usable state. CXL enumeration > re-runs after events that tear down and re-probe the memdev, including > DPC, AER, and Link Down, so those paths reach this recovery. > > This small series is developed from an old RFC v3: > https://lore.kernel.org/linux-cxl/20260330193347.25072-1-fabio.m.de.francesco@linux.intel.com/ > > Fabio M. De Francesco (2): > PCI/CXL: Allow PM Init to complete on cxl_bus reset if ACS SV enabled > cxl/core: Recover from PM Init failure via cxl_reset_bus_function() > > drivers/cxl/core/pci.c | 30 ++++++++++++++++++++ > drivers/cxl/core/port.c | 22 +++++++++++++++ > drivers/cxl/cxlpci.h | 3 ++ > drivers/pci/pci.c | 52 ++++++++++++++++++++++++++++++++++- > include/linux/pci.h | 1 + > include/uapi/linux/pci_regs.h | 2 ++ > 6 files changed, 109 insertions(+), 1 deletion(-) > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH] usb: cdns3: gadget: fix request skipping after clearing halt
@ 2026-04-23 16:06 Yongchao Wu
2026-04-27 1:22 ` Peter Chen (CIX)
0 siblings, 1 reply; 1767+ messages in thread
From: Yongchao Wu @ 2026-04-23 16:06 UTC (permalink / raw)
To: peter.chen, pawell; +Cc: rogerq, gregkh, linux-usb, stable, Yongchao Wu
According to the cdns3 datasheet, the EPRST (Endpoint Reset) command
causes the DMA engine to reposition its internal pointer to the next
Transfer Descriptor (TD) if it was already processing one.
This issue is consistently observed during the ADB identification
process on macOS hosts, where the host issues a Clear_Halt. Although
commit 4bf2dd65135a ("usb: cdns3: gadget: toggle cycle bit before reset
endpoint") attempted to avoid DMA advance by toggling the cycle bit,
trace logs show that on certain hosts like macOS, the DMA pointer
(EP_TRADDR) still shifts after EPRST:
cdns3_ctrl_req: Clear Endpoint Feature(Halt ep1out)
cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04030 <-- Should be f9c04000
cdns3_gadget_giveback: ep1out: req: ... length: 16384/16384
As shown above, the DMA pointer jumped to index 3 (offset 0x30), causing
the controller to skip the initial TRBs of the request. This leads to
data misalignment and ADB protocol hangs on macOS.
Fix this by manually restoring the EP_TRADDR register to the starting
physical address of the current request after the EPRST operation is
complete.
Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
Cc: stable@vger.kernel.org
Cc: Peter Chen <peter.chen@kernel.org>
Signed-off-by: Yongchao Wu <yongchao.wu@autochips.com>
---
drivers/usb/cdns3/cdns3-gadget.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/cdns3/cdns3-gadget.c b/drivers/usb/cdns3/cdns3-gadget.c
index d59a60a16ec77..96653c7d18f20 100644
--- a/drivers/usb/cdns3/cdns3-gadget.c
+++ b/drivers/usb/cdns3/cdns3-gadget.c
@@ -2814,9 +2814,19 @@ int __cdns3_gadget_ep_clear_halt(struct cdns3_endpoint *priv_ep)
priv_ep->flags &= ~(EP_STALLED | EP_STALL_PENDING);
if (request) {
- if (trb)
+ if (trb) {
*trb = trb_tmp;
+ /*
+ * Per datasheet, EPRST causes DMA to reposition to the next TD.
+ * Manually reset EP_TRADDR to the current TRB to prevent
+ * the hardware from skipping the interrupted request.
+ */
+ writel(EP_TRADDR_TRADDR(priv_ep->trb_pool_dma +
+ priv_req->start_trb * TRB_SIZE),
+ &priv_dev->regs->ep_traddr);
+ }
+
cdns3_rearm_transfer(priv_ep, 1);
}
base-commit: 46b513250491a7bfc97d98791dbe6a10bcc8129d
--
2.43.0
^ permalink raw reply related [flat|nested] 1767+ messages in thread* Re: [PATCH] usb: cdns3: gadget: fix request skipping after clearing halt 2026-04-23 16:06 [PATCH] usb: cdns3: gadget: fix request skipping after clearing halt Yongchao Wu @ 2026-04-27 1:22 ` Peter Chen (CIX) 2026-04-27 9:01 ` Pawel Laszczak 0 siblings, 1 reply; 1767+ messages in thread From: Peter Chen (CIX) @ 2026-04-27 1:22 UTC (permalink / raw) To: Yongchao Wu, pawell; +Cc: rogerq, gregkh, linux-usb, stable On 26-04-24 00:06:01, Yongchao Wu wrote: > According to the cdns3 datasheet, the EPRST (Endpoint Reset) command > causes the DMA engine to reposition its internal pointer to the next > Transfer Descriptor (TD) if it was already processing one. > > This issue is consistently observed during the ADB identification > process on macOS hosts, where the host issues a Clear_Halt. Although > commit 4bf2dd65135a ("usb: cdns3: gadget: toggle cycle bit before reset > endpoint") attempted to avoid DMA advance by toggling the cycle bit, > trace logs show that on certain hosts like macOS, the DMA pointer > (EP_TRADDR) still shifts after EPRST: > > cdns3_ctrl_req: Clear Endpoint Feature(Halt ep1out) > cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04030 <-- Should be f9c04000 > cdns3_gadget_giveback: ep1out: req: ... length: 16384/16384 > > As shown above, the DMA pointer jumped to index 3 (offset 0x30), causing > the controller to skip the initial TRBs of the request. This leads to > data misalignment and ADB protocol hangs on macOS. Pawel, Is it a hardware issue? The cycle bit has already been toggled before the endpoint has been reset, why the DMA pointer still advances? Peter > > Fix this by manually restoring the EP_TRADDR register to the starting > physical address of the current request after the EPRST operation is > complete. > > Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") > Cc: stable@vger.kernel.org > Cc: Peter Chen <peter.chen@kernel.org> > Signed-off-by: Yongchao Wu <yongchao.wu@autochips.com> > --- > drivers/usb/cdns3/cdns3-gadget.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/cdns3/cdns3-gadget.c b/drivers/usb/cdns3/cdns3-gadget.c > index d59a60a16ec77..96653c7d18f20 100644 > --- a/drivers/usb/cdns3/cdns3-gadget.c > +++ b/drivers/usb/cdns3/cdns3-gadget.c > @@ -2814,9 +2814,19 @@ int __cdns3_gadget_ep_clear_halt(struct cdns3_endpoint *priv_ep) > priv_ep->flags &= ~(EP_STALLED | EP_STALL_PENDING); > > if (request) { > - if (trb) > + if (trb) { > *trb = trb_tmp; > > + /* > + * Per datasheet, EPRST causes DMA to reposition to the next TD. > + * Manually reset EP_TRADDR to the current TRB to prevent > + * the hardware from skipping the interrupted request. > + */ > + writel(EP_TRADDR_TRADDR(priv_ep->trb_pool_dma + > + priv_req->start_trb * TRB_SIZE), > + &priv_dev->regs->ep_traddr); > + } > + > cdns3_rearm_transfer(priv_ep, 1); > } > > > base-commit: 46b513250491a7bfc97d98791dbe6a10bcc8129d > -- > 2.43.0 > > -- Best regards, Peter ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: [PATCH] usb: cdns3: gadget: fix request skipping after clearing halt 2026-04-27 1:22 ` Peter Chen (CIX) @ 2026-04-27 9:01 ` Pawel Laszczak 2026-04-27 22:59 ` Peter Chen (CIX) 0 siblings, 1 reply; 1767+ messages in thread From: Pawel Laszczak @ 2026-04-27 9:01 UTC (permalink / raw) To: Peter Chen (CIX), Yongchao Wu Cc: rogerq@kernel.org, gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, stable@vger.kernel.org > > >On 26-04-24 00:06:01, Yongchao Wu wrote: >> According to the cdns3 datasheet, the EPRST (Endpoint Reset) command >> causes the DMA engine to reposition its internal pointer to the next >> Transfer Descriptor (TD) if it was already processing one. >> >> This issue is consistently observed during the ADB identification >> process on macOS hosts, where the host issues a Clear_Halt. Although >> commit 4bf2dd65135a ("usb: cdns3: gadget: toggle cycle bit before >> reset >> endpoint") attempted to avoid DMA advance by toggling the cycle bit, >> trace logs show that on certain hosts like macOS, the DMA pointer >> (EP_TRADDR) still shifts after EPRST: >> >> cdns3_ctrl_req: Clear Endpoint Feature(Halt ep1out) >> cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04030 <-- Should be f9c04000 >> cdns3_gadget_giveback: ep1out: req: ... length: 16384/16384 >> >> As shown above, the DMA pointer jumped to index 3 (offset 0x30), >> causing the controller to skip the initial TRBs of the request. This >> leads to data misalignment and ADB protocol hangs on macOS. > >Pawel, Is it a hardware issue? The cycle bit has already been toggled before the >endpoint has been reset, why the DMA pointer still advances? Peter, do you remember what the TD looked like in your case? Maybe that’s where the difference lies. The patch description states that it jumps from 0xf9c04000 to 0xf9c04030, which would suggest that the TD consists of three TRBs. The driver only changes the cycle bit on the first one. I’m not entirely sure how the controller assembles this TD. I need some time to try explain the controller's behavior in this case. Yongchao, could you confirm if the TD consists of three TRBs? Pawel > >Peter > >> >> Fix this by manually restoring the EP_TRADDR register to the starting >> physical address of the current request after the EPRST operation is >> complete. >> >> Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") >> Cc: stable@vger.kernel.org >> Cc: Peter Chen <peter.chen@kernel.org> >> Signed-off-by: Yongchao Wu <yongchao.wu@autochips.com> >> --- >> drivers/usb/cdns3/cdns3-gadget.c | 12 +++++++++++- >> 1 file changed, 11 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/usb/cdns3/cdns3-gadget.c >> b/drivers/usb/cdns3/cdns3-gadget.c >> index d59a60a16ec77..96653c7d18f20 100644 >> --- a/drivers/usb/cdns3/cdns3-gadget.c >> +++ b/drivers/usb/cdns3/cdns3-gadget.c >> @@ -2814,9 +2814,19 @@ int __cdns3_gadget_ep_clear_halt(struct >cdns3_endpoint *priv_ep) >> priv_ep->flags &= ~(EP_STALLED | EP_STALL_PENDING); >> >> if (request) { >> - if (trb) >> + if (trb) { >> *trb = trb_tmp; >> >> + /* >> + * Per datasheet, EPRST causes DMA to reposition to the >next TD. >> + * Manually reset EP_TRADDR to the current TRB to >prevent >> + * the hardware from skipping the interrupted request. >> + */ >> + writel(EP_TRADDR_TRADDR(priv_ep->trb_pool_dma + >> + priv_req->start_trb * >TRB_SIZE), >> + &priv_dev->regs->ep_traddr); >> + } >> + >> cdns3_rearm_transfer(priv_ep, 1); >> } >> >> >> base-commit: 46b513250491a7bfc97d98791dbe6a10bcc8129d >> -- >> 2.43.0 >> >> > >-- > >Best regards, >Peter ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH] usb: cdns3: gadget: fix request skipping after clearing halt 2026-04-27 9:01 ` Pawel Laszczak @ 2026-04-27 22:59 ` Peter Chen (CIX) 2026-04-27 23:59 ` Yongchao Wu 0 siblings, 1 reply; 1767+ messages in thread From: Peter Chen (CIX) @ 2026-04-27 22:59 UTC (permalink / raw) To: Pawel Laszczak Cc: Yongchao Wu, rogerq@kernel.org, gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, stable@vger.kernel.org On 26-04-27 09:01:47, Pawel Laszczak wrote: > > > > > >On 26-04-24 00:06:01, Yongchao Wu wrote: > >> According to the cdns3 datasheet, the EPRST (Endpoint Reset) command > >> causes the DMA engine to reposition its internal pointer to the next > >> Transfer Descriptor (TD) if it was already processing one. > >> > >> This issue is consistently observed during the ADB identification > >> process on macOS hosts, where the host issues a Clear_Halt. Although > >> commit 4bf2dd65135a ("usb: cdns3: gadget: toggle cycle bit before > >> reset > >> endpoint") attempted to avoid DMA advance by toggling the cycle bit, > >> trace logs show that on certain hosts like macOS, the DMA pointer > >> (EP_TRADDR) still shifts after EPRST: > >> > >> cdns3_ctrl_req: Clear Endpoint Feature(Halt ep1out) > >> cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04030 <-- Should be f9c04000 > >> cdns3_gadget_giveback: ep1out: req: ... length: 16384/16384 > >> > >> As shown above, the DMA pointer jumped to index 3 (offset 0x30), > >> causing the controller to skip the initial TRBs of the request. This > >> leads to data misalignment and ADB protocol hangs on macOS. > > > >Pawel, Is it a hardware issue? The cycle bit has already been toggled before the > >endpoint has been reset, why the DMA pointer still advances? > > Peter, do you remember what the TD looked like in your case? Sorry, it was almost 6 years ago, I could not remember it well. > Maybe that’s where the difference lies. The patch description states that > it jumps from 0xf9c04000 to 0xf9c04030, which would suggest that the TD > consists of three TRBs. The driver only changes the cycle bit on the > first one. According to Yongchao's statement: According to the cdns3 datasheet, the EPRST (Endpoint Reset) command causes the DMA engine to reposition its internal pointer to the next Transfer Descriptor (TD) if it was already processing one. My points are the cycle bit has toggled by SW before EPRST command, and EPRST command would reset DMA pointer to the 1st TRB within TD, and it is executed later than cycle bit toggles, why hardware could go on handling TRBs even the first TRB's cycle bit is for software? Peter > I’m not entirely sure how the controller assembles this TD. > I need some time to try explain the controller's behavior in this case. > > Yongchao, could you confirm if the TD consists of three TRBs? > > Pawel -- Best regards, Peter ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH] usb: cdns3: gadget: fix request skipping after clearing halt 2026-04-27 22:59 ` Peter Chen (CIX) @ 2026-04-27 23:59 ` Yongchao Wu 2026-04-28 9:58 ` Pawel Laszczak 0 siblings, 1 reply; 1767+ messages in thread From: Yongchao Wu @ 2026-04-27 23:59 UTC (permalink / raw) To: Peter Chen (CIX), Pawel Laszczak Cc: rogerq@kernel.org, gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, stable@vger.kernel.org On 26-04-27 09:01:47, Pawel Laszczak wrote: >> >> >> On 26-04-24 00:06:01, Yongchao Wu wrote: >>> According to the cdns3 datasheet, the EPRST (Endpoint Reset) command >>> causes the DMA engine to reposition its internal pointer to the next >>> Transfer Descriptor (TD) if it was already processing one. >>> >>> This issue is consistently observed during the ADB identification >>> process on macOS hosts, where the host issues a Clear_Halt. Although >>> commit 4bf2dd65135a ("usb: cdns3: gadget: toggle cycle bit before >>> reset >>> endpoint") attempted to avoid DMA advance by toggling the cycle bit, >>> trace logs show that on certain hosts like macOS, the DMA pointer >>> (EP_TRADDR) still shifts after EPRST: >>> >>> cdns3_ctrl_req: Clear Endpoint Feature(Halt ep1out) >>> cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04030 <- Should be f9c04000 >>> cdns3_gadget_giveback: ep1out: req: ... length: 16384/16384 >>> >>> As shown above, the DMA pointer jumped to index 3 (offset 0x30), >>> causing the controller to skip the initial TRBs of the request. This >>> leads to data misalignment and ADB protocol hangs on macOS. >> >> Pawel, Is it a hardware issue? The cycle bit has already been toggled before the >> endpoint has been reset, why the DMA pointer still advances? > > Yongchao, could you confirm if the TD consists of three TRBs? In our case, each TD consists of 4 TRBs. The DMA pointer appears to advance within the same TD after EPRST. Each 16KB request is split into 4 TRBs (4KB each): - TRB0 - TRB2: CHAIN - TRB3: IOC (last TRB of the TD) After enqueue, the initial EP_TRADDR points to the first TRB: EP_TRADDR = 0xf9c04000 (TRB0) After Clear_Halt (EPRST), it becomes: EP_TRADDR = 0xf9c04030 (TRB3) Since each TRB is 12 bytes, the offset 0x30 corresponds to 4 TRBs. This indicates that after EPRST, the DMA pointer skipped the entire current Request and jumped directly to the start of the next Request at 0xf9c04030 Below is the relevant trace (trimmed): // enqueue request (16KB -> 4 TRBs) cdns3_prepare_trb: dma buf: 0xf7abc000, size: 4096, ctrl: 0x00200415 cdns3_prepare_trb: dma buf: 0xf7abd000, size: 4096, ctrl: 0x00000415 cdns3_prepare_trb: dma buf: 0xf7abe000, size: 4096, ctrl: 0x00000415 cdns3_prepare_trb: dma buf: 0xf7abf000, size: 4096, ctrl: 0x00000425 cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04000 // Clear_Halt cdns3_ctrl_req: Clear Endpoint Feature(Halt ep1out) cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04030 This behavior is consistently observed on macOS hosts during ADB enumeration. So even though the cycle bit is toggled on the first TRB, the controller still appears to advance the DMA pointer within the same TD after EPRST. Please let me know if you need more detailed logs or a full TRB ring dump. I'd also appreciate any insight into how the controller determines the next position after EPRST in this case. Best regards, Yongchao ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: [PATCH] usb: cdns3: gadget: fix request skipping after clearing halt 2026-04-27 23:59 ` Yongchao Wu @ 2026-04-28 9:58 ` Pawel Laszczak 2026-04-28 14:48 ` Yongchao Wu 0 siblings, 1 reply; 1767+ messages in thread From: Pawel Laszczak @ 2026-04-28 9:58 UTC (permalink / raw) To: Yongchao Wu, Peter Chen (CIX) Cc: rogerq@kernel.org, gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, stable@vger.kernel.org > >On 26-04-27 09:01:47, Pawel Laszczak wrote: > >> > >> > >> On 26-04-24 00:06:01, Yongchao Wu wrote: > >>> According to the cdns3 datasheet, the EPRST (Endpoint Reset) command >>>> causes the DMA engine to reposition its internal pointer to the next >>> >Transfer Descriptor (TD) if it was already processing one. > >>> > >>> This issue is consistently observed during the ADB identification >>> >process on macOS hosts, where the host issues a Clear_Halt. Although >>> >commit 4bf2dd65135a ("usb: cdns3: gadget: toggle cycle bit before >>> reset >>>> endpoint") attempted to avoid DMA advance by toggling the cycle bit, >>>> trace logs show that on certain hosts like macOS, the DMA pointer >>> >(EP_TRADDR) still shifts after EPRST: > >>> > >>> cdns3_ctrl_req: Clear Endpoint Feature(Halt ep1out) > >>> cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04030 <- Should be >f9c04000 > >>> cdns3_gadget_giveback: ep1out: req: ... length: 16384/16384 > >>> > >>> As shown above, the DMA pointer jumped to index 3 (offset 0x30), >>> >causing the controller to skip the initial TRBs of the request. This >>> leads to >data misalignment and ADB protocol hangs on macOS. > >> > >> Pawel, Is it a hardware issue? The cycle bit has already been toggled before >the >> endpoint has been reset, why the DMA pointer still advances? > > > > Yongchao, could you confirm if the TD consists of three TRBs? >In our case, each TD consists of 4 TRBs. >The DMA pointer appears to advance within the same TD after EPRST. > >Each 16KB request is split into 4 TRBs (4KB each): >- TRB0 - TRB2: CHAIN >- TRB3: IOC (last TRB of the TD) > >After enqueue, the initial EP_TRADDR points to the first TRB: > EP_TRADDR = 0xf9c04000 (TRB0) > >After Clear_Halt (EPRST), it becomes: > EP_TRADDR = 0xf9c04030 (TRB3) > >Since each TRB is 12 bytes, the offset 0x30 corresponds to 4 TRBs. >This indicates that after EPRST, the DMA pointer skipped the entire current >Request and jumped directly to the start of the next Request at 0xf9c04030 > >Below is the relevant trace (trimmed): > >// enqueue request (16KB -> 4 TRBs) >cdns3_prepare_trb: dma buf: 0xf7abc000, size: 4096, ctrl: 0x00200415 >cdns3_prepare_trb: dma buf: 0xf7abd000, size: 4096, ctrl: 0x00000415 >cdns3_prepare_trb: dma buf: 0xf7abe000, size: 4096, ctrl: 0x00000415 >cdns3_prepare_trb: dma buf: 0xf7abf000, size: 4096, ctrl: 0x00000425 > >cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04000 > >// Clear_Halt >cdns3_ctrl_req: Clear Endpoint Feature(Halt ep1out) >cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04030 > >This behavior is consistently observed on macOS hosts during ADB >enumeration. > >So even though the cycle bit is toggled on the first TRB, the controller still >appears to advance the DMA pointer within the same TD after EPRST. > >Please let me know if you need more detailed logs or a full TRB ring dump. I'd >also appreciate any insight into how the controller determines the next >position after EPRST in this case. > Can you confirm whether the host had already sent some data for this TD prior to the endpoint reset operation? Pawel >Best regards, >Yongchao ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH] usb: cdns3: gadget: fix request skipping after clearing halt 2026-04-28 9:58 ` Pawel Laszczak @ 2026-04-28 14:48 ` Yongchao Wu 2026-05-04 9:15 ` Pawel Laszczak 0 siblings, 1 reply; 1767+ messages in thread From: Yongchao Wu @ 2026-04-28 14:48 UTC (permalink / raw) To: Pawel Laszczak, Peter Chen (CIX) Cc: rogerq@kernel.org, gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, stable@vger.kernel.org On 4/28/2026 5:58 PM, Pawel Laszczak wrote: > >> >> On 26-04-27 09:01:47, Pawel Laszczak wrote: >>>> >>>> >>>> On 26-04-24 00:06:01, Yongchao Wu wrote: >>>>> According to the cdns3 datasheet, the EPRST (Endpoint Reset) command >>>>> causes the DMA engine to reposition its internal pointer to the next >>>>> Transfer Descriptor (TD) if it was already processing one. >>>>> >>>>> This issue is consistently observed during the ADB identification >>>>> process on macOS hosts, where the host issues a Clear_Halt. Although >>>>> commit 4bf2dd65135a ("usb: cdns3: gadget: toggle cycle bit before reset >>>>> reset endpoint") attempted to avoid DMA advance by toggling the cycle bit, >>>>> trace logs show that on certain hosts like macOS, the DMA pointer >>>>> (EP_TRADDR) still shifts after EPRST: >>>>> >>>>> cdns3_ctrl_req: Clear Endpoint Feature(Halt ep1out) >>>>> cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04030 <- Should be f9c04000 >>>>> cdns3_gadget_giveback: ep1out: req: ... length: 16384/16384 >>>>> >>>>> As shown above, the DMA pointer jumped to index 3 (offset 0x30), >>>>> causing the controller to skip the initial TRBs of the request. This >>>>> leads to data misalignment and ADB protocol hangs on macOS. >>>> >>>> Pawel, Is it a hardware issue? The cycle bit has already been toggled before the >>>> endpoint has been reset, why the DMA pointer still advances? >>> >>> Yongchao, could you confirm if the TD consists of three TRBs? >> In our case, each TD consists of 4 TRBs. >> The DMA pointer appears to advance within the same TD after EPRST. >> >> Each 16KB request is split into 4 TRBs (4KB each): >> - TRB0 - TRB2: CHAIN >> - TRB3: IOC (last TRB of the TD) >> >> After enqueue, the initial EP_TRADDR points to the first TRB: >> EP_TRADDR = 0xf9c04000 (TRB0) >> >> After Clear_Halt (EPRST), it becomes: >> EP_TRADDR = 0xf9c04030 (TRB3) >> >> Since each TRB is 12 bytes, the offset 0x30 corresponds to 4 TRBs. >> This indicates that after EPRST, the DMA pointer skipped the entire current >> Request and jumped directly to the start of the next Request at 0xf9c04030 >> >> Below is the relevant trace (trimmed): >> >> // enqueue request (16KB -> 4 TRBs) >> cdns3_prepare_trb: dma buf: 0xf7abc000, size: 4096, ctrl: 0x00200415 >> cdns3_prepare_trb: dma buf: 0xf7abd000, size: 4096, ctrl: 0x00000415 >> cdns3_prepare_trb: dma buf: 0xf7abe000, size: 4096, ctrl: 0x00000415 >> cdns3_prepare_trb: dma buf: 0xf7abf000, size: 4096, ctrl: 0x00000425 >> >> cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04000 >> >> // Clear_Halt >> cdns3_ctrl_req: Clear Endpoint Feature(Halt ep1out) >> cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04030 >> > > Can you confirm whether the host had already sent some data for this TD > prior to the endpoint reset operation? > I confirm that the host sent no data prior to or during the EPRST operation. TotalPhase Trace: 0,HS,2700,0:06.078.671,2.057.666 ms,0 B,,13,00,Set Configuration,Configuration=1 0,HS,2710,0:06.080.811,1.125.266 ms,,,,,[10 SOF],[Frames: 1243.7 - 1245.0] 0,HS,2711,0:06.080.955,992.550 us,2 B,,13,00,Get String Descriptor,Index=5 Length=2 0,HS,2733,0:06.082.061,125.083 us,,,,,[2 SOF],[Frames: 1245.1 - 1245.2] 0,HS,2734,0:06.082.119,104.566 us,28 B,,13,00,Get String Descriptor,Index=5 Length=28 0,HS,2756,0:06.082.311,355.935.283 ms,,,,,[2848 SOF],[Frames: 1245.3 - 1601.2] 0,HS,2757,0:06.438.196,105.033 us,4 B,,13,00,Get String Descriptor,Index=0 Length=256 0,HS,2778,0:06.438.371,875.233 us,,,,,[8 SOF],[Frames: 1601.3 - 1602.2] //1. Host issues Clear_Halt 0,HS,2779,0:06.439.278,51.433 us,0 B,,13,00,Clear Endpoint Feature,Halt Endpoint 01 OUT 0,HS,2789,0:06.439.371,500.150 us,,,,,[5 SOF],[Frames: 1602.3 - 1602.7] 0,HS,2790,0:06.439.874,51.416 us,0 B,,13,00,Clear Endpoint Feature,Halt Endpoint 01 IN 0,HS,2800,0:06.439.996,250.116 us,,,,,[3 SOF],[Frames: 1603.0 - 1603.2] //2. First OUT transaction happens 0,HS,2801,0:06.440.350,1.066 us,24 B,,13,01,OUT txn,43 4E 58 4E 01 00 00 01 00 00 10 00.. 0,HS,2805,0:06.440.371,66 ns,,,,,[1 SOF],[Frame: 1603.3] 0,HS,2806,0:06.440.453,4.283 us,218 B,,13,01,OUT txn,68 6F 73 74 3A 3A 66 65 61 74 75 72.. > Pawel > >> Best regards, >> Yongchao >> Best regards, >> Yongchao ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: 2026-04-28 14:48 ` Yongchao Wu @ 2026-05-04 9:15 ` Pawel Laszczak 0 siblings, 0 replies; 1767+ messages in thread From: Pawel Laszczak @ 2026-05-04 9:15 UTC (permalink / raw) To: Yongchao Wu, Peter Chen (CIX) Cc: rogerq@kernel.org, gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, stable@vger.kernel.org >> >>> >>> On 26-04-27 09:01:47, Pawel Laszczak wrote: >>>>> >>>>> >>>>> On 26-04-24 00:06:01, Yongchao Wu wrote: >>>>>> According to the cdns3 datasheet, the EPRST (Endpoint Reset) >>>>>> command causes the DMA engine to reposition its internal pointer >>>>>> to the next Transfer Descriptor (TD) if it was already processing one. >>>>>> >>>>>> This issue is consistently observed during the ADB identification >>>>>> process on macOS hosts, where the host issues a Clear_Halt. Although >>>>>> commit 4bf2dd65135a ("usb: cdns3: gadget: toggle cycle bit before >reset >>>>>> reset endpoint") attempted to avoid DMA advance by toggling the >>>>>> cycle bit, trace logs show that on certain hosts like macOS, the >>>>>> DMA pointer >>>>>> (EP_TRADDR) still shifts after EPRST: >>>>>> >>>>>> cdns3_ctrl_req: Clear Endpoint Feature(Halt ep1out) >>>>>> cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04030 <- Should be >f9c04000 >>>>>> cdns3_gadget_giveback: ep1out: req: ... length: 16384/16384 >>>>>> >>>>>> As shown above, the DMA pointer jumped to index 3 (offset 0x30), >>>>>> causing the controller to skip the initial TRBs of the request. >>>>>> This leads to data misalignment and ADB protocol hangs on macOS. >>>>> >>>>> Pawel, Is it a hardware issue? The cycle bit has already been >>>>> toggled before the endpoint has been reset, why the DMA pointer still >advances? >>>> >>>> Yongchao, could you confirm if the TD consists of three TRBs? >>> In our case, each TD consists of 4 TRBs. >>> The DMA pointer appears to advance within the same TD after EPRST. >>> >>> Each 16KB request is split into 4 TRBs (4KB each): >>> - TRB0 - TRB2: CHAIN >>> - TRB3: IOC (last TRB of the TD) >>> >>> After enqueue, the initial EP_TRADDR points to the first TRB: >>> EP_TRADDR = 0xf9c04000 (TRB0) >>> >>> After Clear_Halt (EPRST), it becomes: >>> EP_TRADDR = 0xf9c04030 (TRB3) >>> >>> Since each TRB is 12 bytes, the offset 0x30 corresponds to 4 TRBs. >>> This indicates that after EPRST, the DMA pointer skipped the entire >>> current Request and jumped directly to the start of the next Request >>> at 0xf9c04030 >>> >>> Below is the relevant trace (trimmed): >>> >>> // enqueue request (16KB -> 4 TRBs) >>> cdns3_prepare_trb: dma buf: 0xf7abc000, size: 4096, ctrl: 0x00200415 >>> cdns3_prepare_trb: dma buf: 0xf7abd000, size: 4096, ctrl: 0x00000415 >>> cdns3_prepare_trb: dma buf: 0xf7abe000, size: 4096, ctrl: 0x00000415 >>> cdns3_prepare_trb: dma buf: 0xf7abf000, size: 4096, ctrl: 0x00000425 >>> >>> cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04000 >>> >>> // Clear_Halt >>> cdns3_ctrl_req: Clear Endpoint Feature(Halt ep1out) >>> cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04030 >>> >> >> Can you confirm whether the host had already sent some data for this >> TD prior to the endpoint reset operation? >> > >I confirm that the host sent no data prior to or during the EPRST operation. According to the specification, the controller may fetch TRB descriptors after the endpoint has been initialized. In complex Transfer Descriptors (TDs) consisting of several TRBs with the CH=1 bit set, the controller may fetch additional TRBs because it treats them as a single logical entity. I have not been able to determine exactly how many TRBs can be prefetched in such a situation. According to the description of the EPRST bit: After endpoint reset the software is responsible for it to re-set the Endpoint TRADDR. This fix looks correct to me, Can you confirm which version of controller do you have in usb_cap6 register? Pawel > >TotalPhase Trace: >0,HS,2700,0:06.078.671,2.057.666 ms,0 B,,13,00,Set >Configuration,Configuration=1 >0,HS,2710,0:06.080.811,1.125.266 ms,,,,,[10 SOF],[Frames: 1243.7 - 1245.0] >0,HS,2711,0:06.080.955,992.550 us,2 B,,13,00,Get String Descriptor,Index=5 >Length=2 >0,HS,2733,0:06.082.061,125.083 us,,,,,[2 SOF],[Frames: 1245.1 - 1245.2] >0,HS,2734,0:06.082.119,104.566 us,28 B,,13,00,Get String Descriptor,Index=5 >Length=28 >0,HS,2756,0:06.082.311,355.935.283 ms,,,,,[2848 SOF],[Frames: 1245.3 - >1601.2] >0,HS,2757,0:06.438.196,105.033 us,4 B,,13,00,Get String Descriptor,Index=0 >Length=256 >0,HS,2778,0:06.438.371,875.233 us,,,,,[8 SOF],[Frames: 1601.3 - 1602.2] //1. >Host issues Clear_Halt >0,HS,2779,0:06.439.278,51.433 us,0 B,,13,00,Clear Endpoint Feature,Halt >Endpoint 01 OUT >0,HS,2789,0:06.439.371,500.150 us,,,,,[5 SOF],[Frames: 1602.3 - 1602.7] >0,HS,2790,0:06.439.874,51.416 us,0 B,,13,00,Clear Endpoint Feature,Halt >Endpoint 01 IN >0,HS,2800,0:06.439.996,250.116 us,,,,,[3 SOF],[Frames: 1603.0 - 1603.2] //2. >First OUT transaction happens >0,HS,2801,0:06.440.350,1.066 us,24 B,,13,01,OUT txn,43 4E 58 4E 01 00 00 01 >00 00 10 00.. >0,HS,2805,0:06.440.371,66 ns,,,,,[1 SOF],[Frame: 1603.3] >0,HS,2806,0:06.440.453,4.283 us,218 B,,13,01,OUT txn,68 6F 73 74 3A 3A 66 65 >61 74 75 72.. > >> Pawel >> >>> Best regards, >>> Yongchao >>> Best regards, >>> Yongchao ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re; @ 2026-04-12 13:42 Erick Lorch 0 siblings, 0 replies; 1767+ messages in thread From: Erick Lorch @ 2026-04-12 13:42 UTC (permalink / raw) To: bridge Good day I reviewed your reputable profile which gives me the intuition that you will be a potential business partner in a crude oil venture with my company worth two Million (2,000 000) barrels monthly involving the NATIONAL OIL CORPORATION OF LIBYA (NOC) and our Oil Refinery Company. This crude oil venture will gain commissions value in revenue approximately per trade with the NOC; REPLY IF YOU ARE INTERESTED Regards, Erick Lorch Procurement Supervisor ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re; @ 2026-04-12 10:09 Erick Lorch 0 siblings, 0 replies; 1767+ messages in thread From: Erick Lorch @ 2026-04-12 10:09 UTC (permalink / raw) To: bridge Good day I reviewed your reputable profile which gives me the intuition that you will be a potential business partner in a crude oil venture with my company worth two Million (2,000 000) barrels monthly involving the NATIONAL OIL CORPORATION OF LIBYA (NOC) and our Oil Refinery Company. This crude oil venture will gain commissions value in revenue approximately per trade with the NOC; REPLY IF YOU ARE INTERESTED Regards, Erick Lorch Procurement Supervisor ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re; @ 2026-04-12 6:24 Erick Lorch 0 siblings, 0 replies; 1767+ messages in thread From: Erick Lorch @ 2026-04-12 6:24 UTC (permalink / raw) To: bridge Good day I reviewed your reputable profile which gives me the intuition that you will be a potential business partner in a crude oil venture with my company worth two Million (2,000 000) barrels monthly involving the NATIONAL OIL CORPORATION OF LIBYA (NOC) and our Oil Refinery Company. This crude oil venture will gain commissions value in revenue approximately per trade with the NOC; REPLY IF YOU ARE INTERESTED Regards, Erick Lorch Procurement Supervisor ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH] net: ns83820: check DMA mapping errors in hard_start_xmit @ 2026-03-31 10:05 Paolo Abeni 2026-03-31 11:14 ` Wang Jun 0 siblings, 1 reply; 1767+ messages in thread From: Paolo Abeni @ 2026-03-31 10:05 UTC (permalink / raw) To: Wang Jun, kuba Cc: andrew+netdev, davem, edumazet, simon.horman, netdev, linux-kernel, gszhai, 25125332, 25125283, 23120469, stable On 3/27/26 2:16 AM, Wang Jun wrote: > The ns83820 driver currently ignores the return values of dma_map_single() > and skb_frag_dma_map() in the transmit path. If DMA mapping fails due to > IOMMU exhaustion or SWIOTLB pressure, the driver may proceed with invalid > DMA addresses, potentially causing hardware errors, data corruption, or > system instability. > > Additionally, if mapping fails midway through processing fragmented > packets,previously mapped DMA resources are not released, leading > to DMA resource leaks. > > Fix this by: > 1. Checking dma_mapping_error() after each DMA mapping call. > 2. Implementing an error handling path to unmap successfully > mapped buffers(both linear and fragments) using > dma_unmap_single(). > 3. Freeing the skb using dev_kfree_skb_any() to safely handle > both process and softirq contexts, as hard_start_xmit may be > called with IRQs enabled. > 4. Returning NETDEV_TX_OK to drop the packet gracefully and > prevent TX queue stagnation. > > This ensures compliance with the DMA API guidelines and > improves driver stability under memory pressure. > > Fixes: fd9e4d6fec15 ("natsemi: switch from 'pci_' to 'dma_' API") The fix tag looks wrong, as the above just to mechanical substitution of used APIs. The issue is pre-existent > Cc: stable@vger.kernel.org > Signed-off-by: Wang Jun <1742789905@qq.com> > --- > drivers/net/ethernet/natsemi/ns83820.c | 32 ++++++++++++++++++++++++++ > 1 file changed, 32 insertions(+) > > diff --git a/drivers/net/ethernet/natsemi/ns83820.c b/drivers/net/ethernet/natsemi/ns83820.c > index cdbf82affa7b..90465e4977c3 100644 > --- a/drivers/net/ethernet/natsemi/ns83820.c > +++ b/drivers/net/ethernet/natsemi/ns83820.c > @@ -1051,6 +1051,12 @@ static netdev_tx_t ns83820_hard_start_xmit(struct sk_buff *skb, > int stopped = 0; > int do_intr = 0; > volatile __le32 *first_desc; > + dma_addr_t frag_dma_addr[MAX_SKB_FRAGS]; > + unsigned int frag_dma_len[MAX_SKB_FRAGS]; > + int frag_mapped_count = 0; > + dma_addr_t main_buf = 0; > + unsigned int main_len = 0; > + int i; Please respect the reverse christmas tree order above. > dprintk("ns83820_hard_start_xmit\n"); > > @@ -1121,6 +1127,13 @@ static netdev_tx_t ns83820_hard_start_xmit(struct sk_buff *skb, > buf = dma_map_single(&dev->pci_dev->dev, skb->data, len, > DMA_TO_DEVICE); > > + if (dma_mapping_error(&dev->pci_dev->dev, buf)) { > + dev_kfree_skb_any(skb); > + return NETDEV_TX_OK; > + } > + main_buf = buf; > + main_len = len; > + > first_desc = dev->tx_descs + (free_idx * DESC_SIZE); > > for (;;) { > @@ -1144,6 +1157,15 @@ static netdev_tx_t ns83820_hard_start_xmit(struct sk_buff *skb, > > buf = skb_frag_dma_map(&dev->pci_dev->dev, frag, 0, > skb_frag_size(frag), DMA_TO_DEVICE); > + if (dma_mapping_error(&dev->pci_dev->dev, buf)) > + goto dma_map_error; > + > + if (frag_mapped_count < MAX_SKB_FRAGS) { > + frag_dma_addr[frag_mapped_count] = buf; > + frag_dma_len[frag_mapped_count] = skb_frag_size(frag); > + frag_mapped_count++; > + } > + > dprintk("frag: buf=%08Lx page=%08lx offset=%08lx\n", > (long long)buf, (long) page_to_pfn(frag->page), > frag->page_offset); > @@ -1166,6 +1188,16 @@ static netdev_tx_t ns83820_hard_start_xmit(struct sk_buff *skb, > if (stopped && (dev->tx_done_idx != tx_done_idx) && start_tx_okay(dev)) > netif_start_queue(ndev); > > + return NETDEV_TX_OK; > +dma_map_error: > + dma_unmap_single(&dev->pci_dev->dev, main_buf, main_len, DMA_TO_DEVICE); > + for (i = 0; i < frag_mapped_count; i++) { > + dma_unmap_single(&dev->pci_dev->dev, frag_dma_addr[i], frag_dma_len[i], > + DMA_TO_DEVICE); > + } > + > + dev_kfree_skb_any(skb); AI review says: If nr_free < MIN_TX_DESC_FREE earlier in the function, netif_stop_queue is called and the stopped flag is set to 1. By returning NETDEV_TX_OK directly from the error path, we skip the race check at the end of the normal flow: if (stopped && (dev->tx_done_idx != tx_done_idx) && start_tx_okay(dev)) netif_start_queue(ndev); If all pending packets completed concurrently right before the queue was stopped, could this cause the TX queue to stall indefinitely until the tx watchdog fires? ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) 2026-03-31 10:05 [PATCH] net: ns83820: check DMA mapping errors in hard_start_xmit Paolo Abeni @ 2026-03-31 11:14 ` Wang Jun 2026-03-31 12:09 ` Eric Dumazet 0 siblings, 1 reply; 1767+ messages in thread From: Wang Jun @ 2026-03-31 11:14 UTC (permalink / raw) To: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni Cc: netdev, linux-kernel, gszhai, 25125332, 25125283, 23120469, Wang Jun Hi Paolo Abeni, This is v2 of the DMA mapping error handling fix for ns83820. Changes since v1: - Added queue restart check in error path to avoid potential TX queue stall (as pointed out by the AI review) - Adjusted variable declarations to follow reverse christmas tree order - Switched from dma_unmap_single to dma_unmap_page for fragments Thanks to reviewers for the feedback. Subject: [PATCH v2] net: ns83820: fix DMA mapping error handling in hard_start_xmit The ns83820 driver currently ignores the return values of dma_map_single() and skb_frag_dma_map() in the transmit path. If DMA mapping fails due to IOMMU exhaustion or SWIOTLB pressure, the driver may proceed with invalid DMA addresses, potentially causing hardware errors, data corruption, or system instability. Additionally, if mapping fails midway through processing fragmented packets, previously mapped DMA resources are not released, leading to DMA resource leaks. Fix this by: 1. Checking dma_mapping_error() after each DMA mapping call. 2. Implementing an error handling path to unmap successfully mapped buffers (both linear and fragments) using dma_unmap_single() / dma_unmap_page(). 3. Freeing the skb using dev_kfree_skb_any() to safely handle both process and softirq contexts. 4. Returning NETDEV_TX_OK to drop the packet gracefully and prevent TX queue stagnation. 5. Moving the queue restart check (for race conditions when the queue was stopped) into a common label, so that the error path also executes it, avoiding a possible permanent TX queue stall. This ensures compliance with the DMA API guidelines and improves driver stability under memory pressure. Signed-off-by: Wang Jun <1742789905@qq.com> --- drivers/net/ethernet/natsemi/ns83820.c | 31 +++++++++++++++++++++++++- 1 file changed, 30 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/natsemi/ns83820.c b/drivers/net/ethernet/natsemi/ns83820.c index cdbf82affa7b..f8d037db4ffb 100644 --- a/drivers/net/ethernet/natsemi/ns83820.c +++ b/drivers/net/ethernet/natsemi/ns83820.c @@ -1051,6 +1051,12 @@ static netdev_tx_t ns83820_hard_start_xmit(struct sk_buff *skb, int stopped = 0; int do_intr = 0; volatile __le32 *first_desc; + int i; + int frag_mapped_count = 0; + unsigned int main_len = 0; + unsigned int frag_dma_len[MAX_SKB_FRAGS]; + dma_addr_t main_buf = 0; + dma_addr_t frag_dma_addr[MAX_SKB_FRAGS]; dprintk("ns83820_hard_start_xmit\n"); @@ -1120,6 +1126,12 @@ static netdev_tx_t ns83820_hard_start_xmit(struct sk_buff *skb, len -= skb->data_len; buf = dma_map_single(&dev->pci_dev->dev, skb->data, len, DMA_TO_DEVICE); + if (dma_mapping_error(&dev->pci_dev->dev, buf)) { + dev_kfree_skb_any(skb); + goto check_queue_and_return; + } + main_buf = buf; + main_len = len; first_desc = dev->tx_descs + (free_idx * DESC_SIZE); @@ -1144,6 +1156,15 @@ static netdev_tx_t ns83820_hard_start_xmit(struct sk_buff *skb, buf = skb_frag_dma_map(&dev->pci_dev->dev, frag, 0, skb_frag_size(frag), DMA_TO_DEVICE); + if (dma_mapping_error(&dev->pci_dev->dev, buf)) + goto dma_map_error; + + if (frag_mapped_count < MAX_SKB_FRAGS) { + frag_dma_addr[frag_mapped_count] = buf; + frag_dma_len[frag_mapped_count] = skb_frag_size(frag); + frag_mapped_count++; + } + dprintk("frag: buf=%08Lx page=%08lx offset=%08lx\n", (long long)buf, (long) page_to_pfn(frag->page), frag->page_offset); @@ -1161,12 +1182,20 @@ static netdev_tx_t ns83820_hard_start_xmit(struct sk_buff *skb, spin_unlock_irq(&dev->tx_lock); kick_tx(dev); - +check_queue_and_return: /* Check again: we may have raced with a tx done irq */ if (stopped && (dev->tx_done_idx != tx_done_idx) && start_tx_okay(dev)) netif_start_queue(ndev); return NETDEV_TX_OK; +dma_map_error: + dma_unmap_single(&dev->pci_dev->dev, main_buf, main_len, DMA_TO_DEVICE); + for (i = 0; i < frag_mapped_count; i++) { + dma_unmap_page(&dev->pci_dev->dev, frag_dma_addr[i], + frag_dma_len[i], DMA_TO_DEVICE); + } + dev_kfree_skb_any(skb); + goto check_queue_and_return; } static void ns83820_update_stats(struct ns83820 *dev) -- 2.43.0 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2026-03-31 11:14 ` Wang Jun @ 2026-03-31 12:09 ` Eric Dumazet 0 siblings, 0 replies; 1767+ messages in thread From: Eric Dumazet @ 2026-03-31 12:09 UTC (permalink / raw) To: Wang Jun Cc: Andrew Lunn, David S . Miller, Jakub Kicinski, Paolo Abeni, netdev, linux-kernel, gszhai, 25125332, 25125283, 23120469 On Tue, Mar 31, 2026 at 4:15 AM Wang Jun <1742789905@qq.com> wrote: > > Hi Paolo Abeni, > > This is v2 of the DMA mapping error handling fix for ns83820. Changes since v1: > > - Added queue restart check in error path to avoid potential TX queue stall > (as pointed out by the AI review) > - Adjusted variable declarations to follow reverse christmas tree order > - Switched from dma_unmap_single to dma_unmap_page for fragments > > Thanks to reviewers for the feedback. > > Subject: [PATCH v2] net: ns83820: fix DMA mapping error handling in > hard_start_xmit > This is not how a new version of a patch needs to be submitted. Look at https://patchwork.kernel.org/project/netdevbpf/list/ and compare your patch with others... Thanks. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: ezcap401 needs USB_QUIRK_NO_BOS to function on 10gbs usb speed @ 2026-03-13 10:11 Greg KH 2026-03-13 11:01 ` Vyacheslav Vahnenko 0 siblings, 1 reply; 1767+ messages in thread From: Greg KH @ 2026-03-13 10:11 UTC (permalink / raw) To: CaTaTo; +Cc: linux-usb On Fri, Mar 13, 2026 at 12:54:35PM +0300, CaTaTo wrote: > Sorry again, last message went probably to Greg's address rather than this > topic. I managed to make a patch, hopefully I didn't miss anything critical. No need to attach it, just use 'git send-email' to send it directly. Also, some comments on the patch: > From 1ad243ebd0211a591665383d1382615bb9e3dc3a Mon Sep 17 00:00:00 2001 > From: Vyacheslav Vahnenko <vahnenko2003@gmail.com> > Date: Fri, 13 Mar 2026 12:12:26 +0300 > Subject: [PATCH] Add USB_QUIRK_NO_BOS for ezcap401 usb capture card > > Signed-off-by: Vyacheslav Vahnenko <vahnenko2003@gmail.com> You need to have some changelog text, we can't take it without any wording. > --- > drivers/usb/core/quirks.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c > index 9e7e49712..8ef876315 100644 > --- a/drivers/usb/core/quirks.c > +++ b/drivers/usb/core/quirks.c > @@ -583,6 +583,9 @@ static const struct usb_device_id usb_quirk_list[] = { > /* INTEL VALUE SSD */ > { USB_DEVICE(0x8086, 0xf1a5), .driver_info = USB_QUIRK_RESET_RESUME }, > > + /* ezcap401 - BOS descriptor fetch hangs at SuperSpeed Plus */ > + { USB_DEVICE(0x32ed, 0x0401), .driver_info = USB_QUIRK_NO_BOS }, The list should be sorted by id. Please put this in the proper place in the list. thanks, greg k-h ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) 2026-03-13 10:11 ezcap401 needs USB_QUIRK_NO_BOS to function on 10gbs usb speed Greg KH @ 2026-03-13 11:01 ` Vyacheslav Vahnenko 2026-03-13 12:04 ` Greg KH 0 siblings, 1 reply; 1767+ messages in thread From: Vyacheslav Vahnenko @ 2026-03-13 11:01 UTC (permalink / raw) To: gregkh; +Cc: linux-usb, vahnenko2003 Add USB_QUIRK_NO_BOS for ezcap401 capture card, without it dmesg will show "unable to get BOS descriptor or descriptor too short" and "unable to read config index 0 descriptor/start: -71" errors and device will not able to work at full speed at 10gbs Subject: ezcap401 needs USB_QUIRK_NO_BOS to function on 10gbs usb speed Signed-off-by: Vyacheslav Vahnenko <vahnenko2003@gmail.com> --- drivers/usb/core/quirks.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c index 9e7e49712..0010f41a3 100644 --- a/drivers/usb/core/quirks.c +++ b/drivers/usb/core/quirks.c @@ -574,6 +574,9 @@ static const struct usb_device_id usb_quirk_list[] = { /* Alcor Link AK9563 SC Reader used in 2022 Lenovo ThinkPads */ { USB_DEVICE(0x2ce3, 0x9563), .driver_info = USB_QUIRK_NO_LPM }, + /* ezcap401 - BOS descriptor fetch hangs at SuperSpeed Plus */ + { USB_DEVICE(0x32ed, 0x0401), .driver_info = USB_QUIRK_NO_BOS }, + /* DELL USB GEN2 */ { USB_DEVICE(0x413c, 0xb062), .driver_info = USB_QUIRK_NO_LPM | USB_QUIRK_RESET_RESUME }, -- 2.53.0 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2026-03-13 11:01 ` Vyacheslav Vahnenko @ 2026-03-13 12:04 ` Greg KH 0 siblings, 0 replies; 1767+ messages in thread From: Greg KH @ 2026-03-13 12:04 UTC (permalink / raw) To: Vyacheslav Vahnenko; +Cc: linux-usb On Fri, Mar 13, 2026 at 02:01:41PM +0300, Vyacheslav Vahnenko wrote: > Add USB_QUIRK_NO_BOS for ezcap401 capture card, without it dmesg will show "unable to get BOS descriptor or descriptor too short" > and "unable to read config index 0 descriptor/start: -71" errors and device will not able to work at full speed at 10gbs > > Subject: ezcap401 needs USB_QUIRK_NO_BOS to function on 10gbs usb speed Close, this should actually be the subject line, you forgot to have one entirely in your email :) And can you wrap the changelog text at 72 columns, like your editor should have asked you to when making this change? If you run your patch through scripts/checkpatch.pl before sending it, it should tell you about these types of things. > Signed-off-by: Vyacheslav Vahnenko <vahnenko2003@gmail.com> > --- > drivers/usb/core/quirks.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c > index 9e7e49712..0010f41a3 100644 > --- a/drivers/usb/core/quirks.c > +++ b/drivers/usb/core/quirks.c > @@ -574,6 +574,9 @@ static const struct usb_device_id usb_quirk_list[] = { > /* Alcor Link AK9563 SC Reader used in 2022 Lenovo ThinkPads */ > { USB_DEVICE(0x2ce3, 0x9563), .driver_info = USB_QUIRK_NO_LPM }, > > + /* ezcap401 - BOS descriptor fetch hangs at SuperSpeed Plus */ > + { USB_DEVICE(0x32ed, 0x0401), .driver_info = USB_QUIRK_NO_BOS }, This looks good, thanks for putting it in the right place. Almost there! greg k-h ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH v5 0/3] iio: frequency: ad9523: fix checkpatch warnings
@ 2026-02-25 19:40 Bhargav Joshi
2026-02-25 19:40 ` Bhargav Joshi
0 siblings, 1 reply; 1767+ messages in thread
From: Bhargav Joshi @ 2026-02-25 19:40 UTC (permalink / raw)
To: lars, Michael.Hennerich, jic23
Cc: dlechner, nuno.sa, andy, linux-iio, linux-kernel, rougueprince47
These patches address several checkpatch warnings in the ad9523 driver.
Patch 1: Updated the macros to properly use their argument x.
Patch 2: Fixed the multi-line pointer dereferences.
Patch 3: Updated symbolic permissions to octal (0444/0200).
Changes in v5:
- Reflowed all commit messages to properly wrap near 72 characters as
requested.
- Collected Reviewed-by tags for patches 1 and 3.
Changes in v4:
- Used full name for SoB
Changes in v3:
- Patch 1: updated macros to use '(x)' instead of 'x'.
- Patch 2: collected reviewed-by (no code changes).
- Patch 3: fixed vertical spacing and broken indentation.
bhargav (3):
iio: frequency: ad9523: fix implicit variable usage in macros
iio: frequency: ad9523: avoid multiple line dereferences for pdata
iio: frequency: ad9523: fix checkpatch warnings for symbolic
permissions
drivers/iio/frequency/ad9523.c | 88 +++++++++++++---------------------
1 file changed, 33 insertions(+), 55 deletions(-)
--
2.53.0
^ permalink raw reply [flat|nested] 1767+ messages in thread* (no subject) 2026-02-25 19:40 [PATCH v5 0/3] iio: frequency: ad9523: fix checkpatch warnings Bhargav Joshi @ 2026-02-25 19:40 ` Bhargav Joshi 2026-02-25 19:43 ` Andy Shevchenko 0 siblings, 1 reply; 1767+ messages in thread From: Bhargav Joshi @ 2026-02-25 19:40 UTC (permalink / raw) To: lars, Michael.Hennerich, jic23 Cc: dlechner, nuno.sa, andy, linux-iio, linux-kernel, rougueprince47, Andy Shevchenko Subject: [PATCH v5 3/3] iio: frequency: ad9523: fix checkpatch warnings for symbolic permissions The driver currently defines device attributes using symbolic permission flags (S_IRUGO and S_IWUSR). Update these to use octal permissions (0444 and 0200) to resolve checkpatch warnings. Signed-off-by: Bhargav Joshi <rougueprince47@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> --- Changes in v5: - Reflowed all commit messages to properly wrap near 72 characters as requested. - Collected Reviewed-by tag. Changes in v4: - Used full name for SoB Changes in v3: - Fixed vertical spacing and broken indentation. drivers/iio/frequency/ad9523.c | 78 +++++++++++++--------------------- 1 file changed, 29 insertions(+), 49 deletions(-) diff --git a/drivers/iio/frequency/ad9523.c b/drivers/iio/frequency/ad9523.c index 6daa2ea354a8..ad32eb66edca 100644 --- a/drivers/iio/frequency/ad9523.c +++ b/drivers/iio/frequency/ad9523.c @@ -558,55 +558,35 @@ static ssize_t ad9523_show(struct device *dev, return ret; } -static IIO_DEVICE_ATTR(pll1_locked, S_IRUGO, - ad9523_show, - NULL, - AD9523_STAT_PLL1_LD); - -static IIO_DEVICE_ATTR(pll2_locked, S_IRUGO, - ad9523_show, - NULL, - AD9523_STAT_PLL2_LD); - -static IIO_DEVICE_ATTR(pll1_reference_clk_a_present, S_IRUGO, - ad9523_show, - NULL, - AD9523_STAT_REFA); - -static IIO_DEVICE_ATTR(pll1_reference_clk_b_present, S_IRUGO, - ad9523_show, - NULL, - AD9523_STAT_REFB); - -static IIO_DEVICE_ATTR(pll1_reference_clk_test_present, S_IRUGO, - ad9523_show, - NULL, - AD9523_STAT_REF_TEST); - -static IIO_DEVICE_ATTR(vcxo_clk_present, S_IRUGO, - ad9523_show, - NULL, - AD9523_STAT_VCXO); - -static IIO_DEVICE_ATTR(pll2_feedback_clk_present, S_IRUGO, - ad9523_show, - NULL, - AD9523_STAT_PLL2_FB_CLK); - -static IIO_DEVICE_ATTR(pll2_reference_clk_present, S_IRUGO, - ad9523_show, - NULL, - AD9523_STAT_PLL2_REF_CLK); - -static IIO_DEVICE_ATTR(sync_dividers, S_IWUSR, - NULL, - ad9523_store, - AD9523_SYNC); - -static IIO_DEVICE_ATTR(store_eeprom, S_IWUSR, - NULL, - ad9523_store, - AD9523_EEPROM); +static IIO_DEVICE_ATTR(pll1_locked, 0444, ad9523_show, NULL, + AD9523_STAT_PLL1_LD); + +static IIO_DEVICE_ATTR(pll2_locked, 0444, ad9523_show, NULL, + AD9523_STAT_PLL2_LD); + +static IIO_DEVICE_ATTR(pll1_reference_clk_a_present, 0444, ad9523_show, NULL, + AD9523_STAT_REFA); + +static IIO_DEVICE_ATTR(pll1_reference_clk_b_present, 0444, ad9523_show, NULL, + AD9523_STAT_REFB); + +static IIO_DEVICE_ATTR(pll1_reference_clk_test_present, 0444, ad9523_show, NULL, + AD9523_STAT_REF_TEST); + +static IIO_DEVICE_ATTR(vcxo_clk_present, 0444, ad9523_show, NULL, + AD9523_STAT_VCXO); + +static IIO_DEVICE_ATTR(pll2_feedback_clk_present, 0444, ad9523_show, NULL, + AD9523_STAT_PLL2_FB_CLK); + +static IIO_DEVICE_ATTR(pll2_reference_clk_present, 0444, ad9523_show, NULL, + AD9523_STAT_PLL2_REF_CLK); + +static IIO_DEVICE_ATTR(sync_dividers, 0200, NULL, ad9523_store, + AD9523_SYNC); + +static IIO_DEVICE_ATTR(store_eeprom, 0200, NULL, ad9523_store, + AD9523_EEPROM); static struct attribute *ad9523_attributes[] = { &iio_dev_attr_sync_dividers.dev_attr.attr, -- 2.53.0 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2026-02-25 19:40 ` Bhargav Joshi @ 2026-02-25 19:43 ` Andy Shevchenko 0 siblings, 0 replies; 1767+ messages in thread From: Andy Shevchenko @ 2026-02-25 19:43 UTC (permalink / raw) To: Bhargav Joshi Cc: lars, Michael.Hennerich, jic23, dlechner, nuno.sa, andy, linux-iio, linux-kernel, Andy Shevchenko On Wed, Feb 25, 2026 at 9:42 PM Bhargav Joshi <rougueprince47@gmail.com> wrote: > > Subject: [PATCH v5 3/3] iio: frequency: ad9523: fix checkpatch warnings > for symbolic permissions Something went wrong... -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2026-02-02 10:53 Anshumali Gaur 2026-02-03 0:34 ` Jacob Keller 0 siblings, 1 reply; 1767+ messages in thread From: Anshumali Gaur @ 2026-02-02 10:53 UTC (permalink / raw) To: Jacob Keller Cc: netdev, linux-kernel, Sunil Goutham, Linu Cherian, Geetha sowjanya, Jerin Jacob, hariprasad, Subbaraya Sundeep, Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni On 2026-01-29 at 23:02:43, Jacob Keller (jacob.e.keller@intel.com) wrote: > > > On 1/29/2026 1:19 AM, Anshumali Gaur wrote: > > When both AF and PF drivers are built as modules, the PF driver in the > > kexec kernel may probe before the AF driver is ready. This leads to > > a crash due to uninitialized hardware state. > > > > This patch ensures the PF driver properly detects and waits for AF > > driver readiness before proceeding with initialization. > > > > To me, the patch description is not sufficient to describe the what and why > of this change. > > Could you please provide a better explanation of how the addition of the > provided shutdown handler fixes initialization? > Hi Jacob, The issue being addressed here is specific to kexec and persistent AF hardware state across kernel transitions. When both AF and PF drivers are built as modules and a kexec kernel is performed, the PF driver in the new kernel may probe before the AF driver has completed probing and reinitializing the RVU hardware. In this scenario, the hardware state left behind by the AF driver in the old kernel is still visible to the PF driver in the new kernel resulting in crash due to stale state. > > Fixes: 54494aa5d1e6 ("octeontx2-af: Add Marvell OcteonTX2 RVU AF driver") > > Signed-off-by: Anshumali Gaur <agaur@marvell.com> > > --- > > drivers/net/ethernet/marvell/octeontx2/af/rvu.c | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c > > index 747fbdf2a908..8530df8b3fda 100644 > > --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c > > +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c > > @@ -3632,11 +3632,22 @@ static void rvu_remove(struct pci_dev *pdev) > > devm_kfree(&pdev->dev, rvu); > > } > > +static void rvu_shutdown(struct pci_dev *pdev) > > +{ > > + struct rvu *rvu = pci_get_drvdata(pdev); > > + > > + if (!rvu) > > + return; > > + > > + rvu_clear_rvum_blk_revid(rvu); > > Here, I guess you are clearing some data about the device status. Does that > mean that when you initialize later you will wait for the AF driver to > finish probing and configure this? It would be nice to explain how this > change fixes initialization. > The RVUM block revision field acts as an implicit indication that the AF driver has completed its initialization. If this value is left uncleared during kexec kernel booting, the PF driver may observe a non-zero/valid RVUM block revision and incorrectly assume that the AF is already initialized and ready, even though the AF driver in the kexec kernel has not yet probed. This leads to PF initialization proceeding against partially initialized hardware, resulting in a crash. > > +} > > + > > static struct pci_driver rvu_driver = { > > .name = DRV_NAME, > > .id_table = rvu_id_table, > > .probe = rvu_probe, > > .remove = rvu_remove, > > + .shutdown = rvu_shutdown, > > This is the shutdown handler: > > > > * @shutdown: Hook into reboot_notifier_list (kernel/sys.c). > > * Intended to stop any idling DMA operations. > > * Useful for enabling wake-on-lan (NIC) or changing > > * the power state of a device before reboot. > > * e.g. drivers/net/e100.c. > > How does this have anything to do with initialization? > > > }; > > static int __init rvu_init_module(void) > > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2026-02-02 10:53 Anshumali Gaur @ 2026-02-03 0:34 ` Jacob Keller 0 siblings, 0 replies; 1767+ messages in thread From: Jacob Keller @ 2026-02-03 0:34 UTC (permalink / raw) To: Anshumali Gaur Cc: netdev, linux-kernel, Sunil Goutham, Linu Cherian, Geetha sowjanya, Jerin Jacob, hariprasad, Subbaraya Sundeep, Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni On 2/2/2026 2:53 AM, Anshumali Gaur wrote: > On 2026-01-29 at 23:02:43, Jacob Keller (jacob.e.keller@intel.com) wrote: >> >> >> On 1/29/2026 1:19 AM, Anshumali Gaur wrote: >>> When both AF and PF drivers are built as modules, the PF driver in the >>> kexec kernel may probe before the AF driver is ready. This leads to >>> a crash due to uninitialized hardware state. >>> >>> This patch ensures the PF driver properly detects and waits for AF >>> driver readiness before proceeding with initialization. >>> >> >> To me, the patch description is not sufficient to describe the what and why >> of this change. >> >> Could you please provide a better explanation of how the addition of the >> provided shutdown handler fixes initialization? >> > Hi Jacob, > The issue being addressed here is specific to kexec and persistent AF > hardware state across kernel transitions. When both AF and PF drivers > are built as modules and a kexec kernel is performed, the PF driver in > the new kernel may probe before the AF driver has completed probing and > reinitializing the RVU hardware. In this scenario, the hardware state > left behind by the AF driver in the old kernel is still visible to the > PF driver in the new kernel resulting in crash due to stale state. >>> Fixes: 54494aa5d1e6 ("octeontx2-af: Add Marvell OcteonTX2 RVU AF driver") >>> Signed-off-by: Anshumali Gaur <agaur@marvell.com> >>> --- >>> drivers/net/ethernet/marvell/octeontx2/af/rvu.c | 11 +++++++++++ >>> 1 file changed, 11 insertions(+) >>> >>> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c >>> index 747fbdf2a908..8530df8b3fda 100644 >>> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c >>> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c >>> @@ -3632,11 +3632,22 @@ static void rvu_remove(struct pci_dev *pdev) >>> devm_kfree(&pdev->dev, rvu); >>> } >>> +static void rvu_shutdown(struct pci_dev *pdev) >>> +{ >>> + struct rvu *rvu = pci_get_drvdata(pdev); >>> + >>> + if (!rvu) >>> + return; >>> + >>> + rvu_clear_rvum_blk_revid(rvu); >> >> Here, I guess you are clearing some data about the device status. Does that >> mean that when you initialize later you will wait for the AF driver to >> finish probing and configure this? It would be nice to explain how this >> change fixes initialization. >> > The RVUM block revision field acts as an implicit indication that the AF > driver has completed its initialization. If this value is left uncleared > during kexec kernel booting, the PF driver may observe a non-zero/valid > RVUM block revision and incorrectly assume that the AF is already > initialized and ready, even though the AF driver in the kexec kernel has > not yet probed. This leads to PF initialization proceeding against > partially initialized hardware, resulting in a crash. Makes sense. When shutting down you need to explicitly clear the stale data so that booting up (without a powercycle as in the kexec case) does not lead to stale data. I'd appreciate a little more of this detail in the commit message personally. However, functionally it makes sense, so: Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2026-01-11 21:10 Wesley B 2026-01-12 13:28 ` Miguel Ojeda 0 siblings, 1 reply; 1767+ messages in thread From: Wesley B @ 2026-01-11 21:10 UTC (permalink / raw) To: rust-for-linux From 71c099600448cdb639136bb15bdd40767dbfc0fd Mon Sep 17 00:00:00 2001 From: Wesley Bott <atticusfinch570@gmail.com> Date: Sat, 10 Jan 2026 18:26:47 -0700 Subject: [PATCH] rust: Restore __new INVARIANT comment, updated docs as needed Add back the //INVARIANT: comment in __new to reflect the precondition that VALUE must fit within N bits. Updated docs to reflect INVARIANT comment. Link: https://github.com/Rust-for-Linux/linux/issues/1217 Suggested-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Wesley Bott <atticusfinch570@gmail.com> --- rust/kernel/num/bounded.rs | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/rust/kernel/num/bounded.rs b/rust/kernel/num/bounded.rs index f870080af8ac..07ce6a1dd6e3 100644 --- a/rust/kernel/num/bounded.rs +++ b/rust/kernel/num/bounded.rs @@ -282,10 +282,11 @@ impl<T, const N: u32> Bounded<T, N> /// All instances of [`Bounded`] must be created through this method as it enforces most of the /// type invariants. /// - /// The caller remains responsible for checking, either statically or dynamically, that `value` - /// can be represented as a `T` using at most `N` bits. + /// The caller must ensure checking, either statically or dynamically, that `value` + /// can be represented as a `T` using at most `N` bits (0 < N <= T::BITS). const fn __new(value: T) -> Self { // Enforce the type invariants. + // INVARIANT: 'value' T can be represented using at most N bits (0 < N <= T::BITS) const { // `N` cannot be zero. assert!(N != 0); -- 2.43.0 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2026-01-11 21:10 Wesley B @ 2026-01-12 13:28 ` Miguel Ojeda 0 siblings, 0 replies; 1767+ messages in thread From: Miguel Ojeda @ 2026-01-12 13:28 UTC (permalink / raw) To: Wesley B; +Cc: rust-for-linux On Sun, Jan 11, 2026 at 10:10 PM Wesley B <atticusfinch570@gmail.com> wrote: > > From 71c099600448cdb639136bb15bdd40767dbfc0fd Mon Sep 17 00:00:00 2001 > From: Wesley Bott <atticusfinch570@gmail.com> > Date: Sat, 10 Jan 2026 18:26:47 -0700 > Subject: [PATCH] rust: Restore __new INVARIANT comment, updated docs as needed These headers should be used to send an email with that subject etc., rather than embedding it. I would suggest trying to use `git send-email` or `b4`. > Link: https://github.com/Rust-for-Linux/linux/issues/1217 > Suggested-by: Miguel Ojeda <ojeda@kernel.org> The suggestion was to remove a paragraph, not to edit it. Perhaps the confusion is that the suggestion goes on top of the `rust-fixes` branch, not mainline. Thanks! Cheers, Miguel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2025-11-05 3:38 niklaus.liu 2025-11-05 8:56 ` AngeloGioacchino Del Regno 0 siblings, 1 reply; 1767+ messages in thread From: niklaus.liu @ 2025-11-05 3:38 UTC (permalink / raw) To: Matthias Brugger, AngeloGioacchino Del Regno Cc: linux-kernel, linux-arm-kernel, linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang, vince-wl.liu, jh.hsu, zhigang.qin, sen.chu, Niklaus Liu, niklaus.liu Refer to the discussion in the link: v3: https://patchwork.kernel.org/project/linux-mediatek/patch/20251104071252.12539-2-Niklaus.Liu@mediatek.com/ Subject: [PATCH v4 0/1] soc: mediatek: mtk-regulator-coupler: Add support for MT8189 changes in v4: - reply comment: 1. MTK hardware requires that vsram_gpu must be higher than vgpu; this rule must be satisfied. 2. When the GPU powers on, the mtcmos driver first calls regulator_enable to turn on vgpu, then calls regulator_enable to turn on vsram_gpu. When enabling vgpu, mediatek_regulator_balance_voltage sets the voltages for both vgpu and vsram_gpu. However, when enabling vsram_gpu, mediatek_regulator_balance_voltage is also executed, and at this time, the vsram_gpu voltage is set to the minimum voltage specified in the DTS, which does not comply with the requirement that vsram_gpu must be higher than vgpu. 3.During suspend, the voltages of vgpu and vsram_gpu should remain unchanged, and when resuming, vgpu and vsram_gpu should be restored to their previous voltages. When the vgpu voltage is adjusted, mediatek_regulator_balance_voltage already synchronizes the adjustment of vsram_gpu voltage. Therefore, adjusting the vsram_gpu voltage again in mediatek_regulator_balance_voltage is redundant. changes in v3: - modify for comment[add the new entry by alphabetical order] changes in v2: - change title for patch - reply comment: This is a software regulator coupler mechanism, and the regulator-coupled-with configuration has been added in the MT8189 device tree. This patchaddresses an issue reported by a Chromebook customer. When the GPU regulator is turned on, mediatek_regulator_balance_voltage already sets both the GPU and GPU_SRAM voltages at the same time, so there is no need to adjust the GPU_SRAM voltage again in a second round. Therefore, a return is set for MT8189. If the user calls mediatek_regulator_balance_voltage again for GPU_SRAM, it may cause abnormal behavior of GPU_SRAM. changes in v1: - mediatek-regulator-coupler mechanism for platform MT8189 *** BLURB HERE *** Niklaus Liu (1): soc: mediatek: mtk-regulator-coupler: Add support for MT8189 drivers/soc/mediatek/mtk-regulator-coupler.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) -- 2.46.0 ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-11-05 3:38 niklaus.liu @ 2025-11-05 8:56 ` AngeloGioacchino Del Regno 0 siblings, 0 replies; 1767+ messages in thread From: AngeloGioacchino Del Regno @ 2025-11-05 8:56 UTC (permalink / raw) To: niklaus.liu, Matthias Brugger Cc: linux-kernel, linux-arm-kernel, linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang, vince-wl.liu, jh.hsu, zhigang.qin, sen.chu Il 05/11/25 04:38, niklaus.liu ha scritto: > Refer to the discussion in the link: > v3: https://patchwork.kernel.org/project/linux-mediatek/patch/20251104071252.12539-2-Niklaus.Liu@mediatek.com/ > > Subject: [PATCH v4 0/1] soc: mediatek: mtk-regulator-coupler: Add support for MT8189 The subject of this email is .. empty. That's really bad, and it's the second time that it happens. Please make sure that you're sending emails the right way, and/or fix your client. While at it, please also fix your name, as it should appear as "Niklaus Liu" and not as "niklaus.liu". > > changes in v4: > - reply comment: Niklaus, please just reply inline to the emails instead of sending an entirely new version just for a reply: it's easier for everyone to follow, and it's also easier for me to read, and for you to send a reply by clicking one button :-) > 1. MTK hardware requires that vsram_gpu must be higher than vgpu; this rule must be satisfied. > > 2. When the GPU powers on, the mtcmos driver first calls regulator_enable to turn on vgpu, then calls regulator_enable to > turn on vsram_gpu. When enabling vgpu, mediatek_regulator_balance_voltage sets the voltages for both vgpu and vsram_gpu. > However, when enabling vsram_gpu, mediatek_regulator_balance_voltage is also executed, and at this time, the vsram_gpu voltage > is set to the minimum voltage specified in the DTS, which does not comply with the requirement that vsram_gpu must be higher than vgpu. > 2. -> There's your problem! VSRAM_GPU has to be turned on *first*, VGPU has to be turned on *last* instead. Logically, you need SRAM up before the GPU is up as if the GPU tries to use SRAM it'll produce unpowered access issues: even though it's *very* unlikely for that to happen on older Mali, it's still a logical mistake that might, one day, come back at us and create instabilities. Now, the easy fix is to just invert the regulators in MFG nodes. As I explained *multiple* times, you have a misconfiguration in your DT. GPU subsystem main MFG -> VSRAM GPU core complex MFG -> VGPU GPU per-core MFG -> nothing > 3.During suspend, the voltages of vgpu and vsram_gpu should remain unchanged, and when resuming, vgpu and vsram_gpu should be > restored to their previous voltages. When the vgpu voltage is adjusted, mediatek_regulator_balance_voltage already synchronizes the > adjustment of vsram_gpu voltage. Therefore, adjusting the vsram_gpu voltage again in mediatek_regulator_balance_voltage is redundant. If you fix your DT, N.3 won't happen. Regards, Angelo > > > changes in v3: > - modify for comment[add the new entry by alphabetical order] > > changes in v2: > - change title for patch > - reply comment: This is a software regulator coupler mechanism, and the regulator-coupled-with > configuration has been added in the MT8189 device tree. This patchaddresses an issue reported by a > Chromebook customer. When the GPU regulator is turned on, mediatek_regulator_balance_voltage already > sets both the GPU and GPU_SRAM voltages at the same time, so there is no need to adjust the GPU_SRAM > voltage again in a second round. Therefore, a return is set for MT8189. > If the user calls mediatek_regulator_balance_voltage again for GPU_SRAM, it may cause abnormal behavior of GPU_SRAM. > > > changes in v1: > - mediatek-regulator-coupler mechanism for platform MT8189 > > *** BLURB HERE *** > > Niklaus Liu (1): > soc: mediatek: mtk-regulator-coupler: Add support for MT8189 > > drivers/soc/mediatek/mtk-regulator-coupler.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2025-11-04 9:22 Michael Roach 2025-11-04 10:24 ` Kristoffer Haugsbakk 0 siblings, 1 reply; 1767+ messages in thread From: Michael Roach @ 2025-11-04 9:22 UTC (permalink / raw) To: git Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue. What did you do before the bug happened? (Steps to reproduce your issue) I ran: $ git grep -rl --color=never '#!/.*/env ruby' What did you expect to happen? (Expected behavior) Get a list of filenames where the contents matched the regex What happened instead? (Actual behavior) For one of my files named `ensure-string-env.rb` was printed with part of the path in colour, and the first dash of the filename replaced with a colon. What's different between what you expected and what actually happened? I expected: images/deploy_tools/scripts/ensure-string-env.rb I got: images/deploy_tools/scripts/ensure:string-env.rb The string up to the colon was printed in pink Anything else you want to add: I tested with both zsh and bash with the same result. I teested with git 2.47.3 and 2.49.1 everything worked correctly. I also tried other terminals to rule that out. 2.51.1 is the current version on Fedora 42 I was able to reproduce this with: $ echo foo > test-one $ git add test-one $ git grep -l foo test:one This seems to be reproducible with any filename containing a dash [System Info] git version: git version 2.51.1 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh libcurl: 8.11.1 OpenSSL: OpenSSL 3.2.6 30 Sep 2025 zlib-ng: 2.2.5 SHA-1: SHA1_DC SHA-256: SHA256_BLK default-ref-format: files default-hash: sha1 uname: Linux 6.17.5-200.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Oct 24 14:10:01 UTC 2025 x86_64 compiler info: gnuc: 15.2 libc info: glibc: 2.41 $SHELL (typically, interactive shell): /bin/zsh [Enabled Hooks] pre-commit ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-11-04 9:22 Michael Roach @ 2025-11-04 10:24 ` Kristoffer Haugsbakk 2025-11-05 14:55 ` Re: Lucas Seiki Oshiro 0 siblings, 1 reply; 1767+ messages in thread From: Kristoffer Haugsbakk @ 2025-11-04 10:24 UTC (permalink / raw) To: Michael Roach, git On Tue, Nov 4, 2025, at 10:22, Michael Roach wrote: >[snip] > For one of my files named `ensure-string-env.rb` was printed with part > of the path in colour, > and the first dash of the filename replaced with a colon. I have seen something similar when using the Delta pager. I’m pretty sure that it replaced a hyphen with a colon. https://github.com/dandavison/delta I don’t think I’ve seen this behavior with `git --no-pager`. Don’t know about the coloring part (despite `--color=never`). >[snip] ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-11-04 10:24 ` Kristoffer Haugsbakk @ 2025-11-05 14:55 ` Lucas Seiki Oshiro 2025-11-05 15:01 ` Re: Kristoffer Haugsbakk 0 siblings, 1 reply; 1767+ messages in thread From: Lucas Seiki Oshiro @ 2025-11-05 14:55 UTC (permalink / raw) To: Kristoffer Haugsbakk, Michael Roach; +Cc: git > I have seen something similar when using the Delta pager. I’m pretty > sure that it replaced a hyphen with a colon. It's a known bug in Delta: https://github.com/dandavison/delta/issues/1259 > I don’t think I’ve seen this behavior with `git --no-pager`. I think it is a good idea to also see what happens when using another pager, for example, less (`git -c core.pager=less ...`) or cat (`git -c core.pager=cat ...`). Michael, can you run with those three mentioned options and see what happens? Last year I spent some hours trying to find the cause of the same bug in Git but then I found out that it was actually a bug in Delta. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-11-05 14:55 ` Re: Lucas Seiki Oshiro @ 2025-11-05 15:01 ` Kristoffer Haugsbakk 2025-11-06 0:05 ` Re: Lucas Seiki Oshiro 0 siblings, 1 reply; 1767+ messages in thread From: Kristoffer Haugsbakk @ 2025-11-05 15:01 UTC (permalink / raw) To: Lucas Seiki Oshiro, Michael Roach; +Cc: git On Wed, Nov 5, 2025, at 15:55, Lucas Seiki Oshiro wrote: >> I have seen something similar when using the Delta pager. I’m pretty >> sure that it replaced a hyphen with a colon. > > It's a known bug in Delta: > > https://github.com/dandavison/delta/issues/1259 > >> I don’t think I’ve seen this behavior with `git --no-pager`. > > I think it is a good idea to also see what happens when using another > pager, for example, less (`git -c core.pager=less ...`) or cat > (`git -c core.pager=cat ...`). > > Michael, can you run with those three mentioned options and see what > happens? Last year I spent some hours trying to find the cause of the > same bug in Git but then I found out that it was actually a bug in > Delta. Sorry, I didn’t see that he only replied to me previously: On Tue, Nov 4, 2025, at 12:15, Michael Roach wrote: > Just when I thought I had considered all the factors before reporting > this, you got it. > I am using Delta as my pager. My tests with other git versions were via > Docker, so there was no pager. > > I confirmed that using `git --no-pager grep` doesn't have this issue. > > Sorry for the bug report noise and thanks for figuring that out. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-11-05 15:01 ` Re: Kristoffer Haugsbakk @ 2025-11-06 0:05 ` Lucas Seiki Oshiro 2025-11-06 8:09 ` Re: Michael Roach 0 siblings, 1 reply; 1767+ messages in thread From: Lucas Seiki Oshiro @ 2025-11-06 0:05 UTC (permalink / raw) To: Kristoffer Haugsbakk; +Cc: Michael Roach, git > Sorry, I didn’t see that he only replied to me previously: Thanks for forwarding that! ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-11-06 0:05 ` Re: Lucas Seiki Oshiro @ 2025-11-06 8:09 ` Michael Roach 0 siblings, 0 replies; 1767+ messages in thread From: Michael Roach @ 2025-11-06 8:09 UTC (permalink / raw) To: Lucas Seiki Oshiro, Kristoffer Haugsbakk; +Cc: git Sorry I didn't do a reply to all on Kristoffer's response. Can you tell it's my first time here? Thank you both for your time on this! November 6, 2025 at 01:05, "Lucas Seiki Oshiro" <lucasseikioshiro@gmail.com mailto:lucasseikioshiro@gmail.com?to=%22Lucas%20Seiki%20Oshiro%22%20%3Clucasseikioshiro%40gmail.com%3E > wrote: > > > > > Sorry, I didn’t see that he only replied to me previously: > > > Thanks for forwarding that! > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH] counter: microchip-tcb-capture: Allow shared IRQ for multi-channel TCBs
@ 2025-10-06 10:51 Dharma Balasubiramani
2025-10-08 7:06 ` Kamel Bouhara
0 siblings, 1 reply; 1767+ messages in thread
From: Dharma Balasubiramani @ 2025-10-06 10:51 UTC (permalink / raw)
To: Kamel Bouhara, William Breathitt Gray, Bence Csókás
Cc: linux-arm-kernel, linux-iio, linux-kernel, Dharma Balasubiramani
Mark the interrupt as IRQF_SHARED to permit multiple counter channels to
share the same TCB IRQ line.
Each Timer/Counter Block (TCB) instance shares a single IRQ line among its
three internal channels. When multiple counter channels (e.g., counter@0
and counter@1) within the same TCB are enabled, the second call to
devm_request_irq() fails because the IRQ line is already requested by the
first channel.
Fixes: e5d581396821 ("counter: microchip-tcb-capture: Add IRQ handling")
Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com>
---
drivers/counter/microchip-tcb-capture.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/counter/microchip-tcb-capture.c b/drivers/counter/microchip-tcb-capture.c
index 1a299d1f350b..19d457ae4c3b 100644
--- a/drivers/counter/microchip-tcb-capture.c
+++ b/drivers/counter/microchip-tcb-capture.c
@@ -451,7 +451,7 @@ static void mchp_tc_irq_remove(void *ptr)
static int mchp_tc_irq_enable(struct counter_device *const counter, int irq)
{
struct mchp_tc_data *const priv = counter_priv(counter);
- int ret = devm_request_irq(counter->parent, irq, mchp_tc_isr, 0,
+ int ret = devm_request_irq(counter->parent, irq, mchp_tc_isr, IRQF_SHARED,
dev_name(counter->parent), counter);
if (ret < 0)
---
base-commit: fd94619c43360eb44d28bd3ef326a4f85c600a07
change-id: 20251006-microchip-tcb-edd8aeae36c4
Best regards,
--
Dharma Balasubiramani <dharma.b@microchip.com>
^ permalink raw reply related [flat|nested] 1767+ messages in thread* Re: [PATCH] counter: microchip-tcb-capture: Allow shared IRQ for multi-channel TCBs 2025-10-06 10:51 [PATCH] counter: microchip-tcb-capture: Allow shared IRQ for multi-channel TCBs Dharma Balasubiramani @ 2025-10-08 7:06 ` Kamel Bouhara 2025-10-08 20:46 ` Bence Csókás 0 siblings, 1 reply; 1767+ messages in thread From: Kamel Bouhara @ 2025-10-08 7:06 UTC (permalink / raw) To: Dharma Balasubiramani, g Cc: William Breathitt Gray, Bence Csókás, linux-arm-kernel, linux-iio, linux-kernel On Mon, Oct 06, 2025 at 04:21:50PM +0530, Dharma Balasubiramani wrote: Hello Dharma, > Mark the interrupt as IRQF_SHARED to permit multiple counter channels to > share the same TCB IRQ line. > > Each Timer/Counter Block (TCB) instance shares a single IRQ line among its > three internal channels. When multiple counter channels (e.g., counter@0 > and counter@1) within the same TCB are enabled, the second call to > devm_request_irq() fails because the IRQ line is already requested by the > first channel. > > Fixes: e5d581396821 ("counter: microchip-tcb-capture: Add IRQ handling") > Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com> > --- > drivers/counter/microchip-tcb-capture.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/counter/microchip-tcb-capture.c b/drivers/counter/microchip-tcb-capture.c > index 1a299d1f350b..19d457ae4c3b 100644 > --- a/drivers/counter/microchip-tcb-capture.c > +++ b/drivers/counter/microchip-tcb-capture.c > @@ -451,7 +451,7 @@ static void mchp_tc_irq_remove(void *ptr) > static int mchp_tc_irq_enable(struct counter_device *const counter, int irq) > { > struct mchp_tc_data *const priv = counter_priv(counter); > - int ret = devm_request_irq(counter->parent, irq, mchp_tc_isr, 0, > + int ret = devm_request_irq(counter->parent, irq, mchp_tc_isr, IRQF_SHARED, > dev_name(counter->parent), counter); > > if (ret < 0) > > --- > base-commit: fd94619c43360eb44d28bd3ef326a4f85c600a07 > change-id: 20251006-microchip-tcb-edd8aeae36c4 > This change makes sense, thanks ! Reviewed-by: Kamel Bouhara <kamel.bouhara@bootlin.com> > Best regards, > -- > Dharma Balasubiramani <dharma.b@microchip.com> > -- Kamel Bouhara, Bootlin Embedded Linux and kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-10-08 7:06 ` Kamel Bouhara @ 2025-10-08 20:46 ` Bence Csókás 0 siblings, 0 replies; 1767+ messages in thread From: Bence Csókás @ 2025-10-08 20:46 UTC (permalink / raw) To: Kamel Bouhara, Dharma Balasubiramani, g Cc: William Breathitt Gray, Bence Csókás, linux-arm-kernel, linux-iio, linux-kernel Hi, > On Mon, Oct 06, 2025 at 04:21:50PM +0530, Dharma Balasubiramani wrote: > > Hello Dharma, > >> Mark the interrupt as IRQF_SHARED to permit multiple counter channels to >> share the same TCB IRQ line. >> >> Each Timer/Counter Block (TCB) instance shares a single IRQ line among its >> three internal channels. When multiple counter channels (e.g., counter@0 >> and counter@1) within the same TCB are enabled, the second call to >> devm_request_irq() fails because the IRQ line is already requested by the >> first channel. >> >> Fixes: e5d581396821 ("counter: microchip-tcb-capture: Add IRQ handling") >> Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com> >> --- >> drivers/counter/microchip-tcb-capture.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/counter/microchip-tcb-capture.c b/drivers/counter/microchip-tcb-capture.c >> index 1a299d1f350b..19d457ae4c3b 100644 >> --- a/drivers/counter/microchip-tcb-capture.c >> +++ b/drivers/counter/microchip-tcb-capture.c >> @@ -451,7 +451,7 @@ static void mchp_tc_irq_remove(void *ptr) >> static int mchp_tc_irq_enable(struct counter_device *const counter, int irq) >> { >> struct mchp_tc_data *const priv = counter_priv(counter); >> - int ret = devm_request_irq(counter->parent, irq, mchp_tc_isr, 0, >> + int ret = devm_request_irq(counter->parent, irq, mchp_tc_isr, IRQF_SHARED, >> dev_name(counter->parent), counter); >> >> if (ret < 0) >> >> --- >> base-commit: fd94619c43360eb44d28bd3ef326a4f85c600a07 >> change-id: 20251006-microchip-tcb-edd8aeae36c4 >> > > This change makes sense, thanks ! > > Reviewed-by: Kamel Bouhara <kamel.bouhara@bootlin.com> > >> Best regards, >> -- >> Dharma Balasubiramani <dharma.b@microchip.com> >> > > -- > Kamel Bouhara, Bootlin > Embedded Linux and kernel engineering > https://bootlin.com Looks reasonable to me as well. Reviewed-by: Bence Csókás <bence98@sch.bme.hu> ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2025-10-05 14:16 ssrane_b23 2025-10-05 14:16 ` syzbot 0 siblings, 1 reply; 1767+ messages in thread From: ssrane_b23 @ 2025-10-05 14:16 UTC (permalink / raw) To: Steven Rostedt Cc: Masami Hiramatsu, Mathieu Desnoyers, linux-kernel, linux-trace-kernel, syzbot+c530b4d95ec5cd4f33a7 #syz test on: linux-next ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-10-05 14:16 ssrane_b23 @ 2025-10-05 14:16 ` syzbot 0 siblings, 0 replies; 1767+ messages in thread From: syzbot @ 2025-10-05 14:16 UTC (permalink / raw) To: ssrane_b23 Cc: linux-kernel, linux-trace-kernel, mathieu.desnoyers, mhiramat, rostedt, ssrane_b23, syzkaller-bugs > #syz test on: linux-next This crash does not have a reproducer. I cannot test it. > > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2025-09-16 21:23 Jay Vosburgh
2025-09-16 21:56 ` Jay Vosburgh
0 siblings, 1 reply; 1767+ messages in thread
From: Jay Vosburgh @ 2025-09-16 21:23 UTC (permalink / raw)
To: netdev; +Cc: Jamal Hadi Salim, Stephen Hemminger, David Ahern
Subject: [PATCH v2 0/4 iproute2-next] tc/police: Allow 64 bit burst size
In summary, this patchset changes the user space handling of the
tc police burst parameter to permit burst sizes that exceed 4 GB when the
specified rate is high enough that the kernel API for burst can accomodate
such.
Additionally, if the burst exceeds the upper limit of the kernel
API, this is now flagged as an error. The existing behavior silently
overflows, resulting in arbitrary values passed to the kernel.
In detail, as presently implemented, the tc police burst option
limits the size of the burst to to 4 GB, i.e., UINT_MAX for a 32 bit
unsigned int. This is a reasonable limit for the low rates common when
this was developed. However, the underlying implementation of burst is
computed as "time at the specified rate," and for higher rates, a burst
size exceeding 4 GB is feasible without modification to the kernel.
The burst size provided on the command line is translated into a
duration, representing how much time is required at the specified rate to
transmit the given burst size.
This time is calculated in units of "psched ticks," each of which
is 64 nsec[0]. The computed number of psched ticks is sent to the kernel
as a __u32 value.
Because burst is ultimately calculated as a time duration, the
real upper limit for a burst is UINT_MAX psched ticks, i.e.,
UINT_MAX * psched tick duration / NSEC_PER_SEC
(2^32-1) * 64 / 1E9
which is roughly 274.88 seconds (274.8779...).
At low rates, e.g., 5 Mbit/sec, UINT_MAX psched ticks does not
correspond to a burst size in excess of 4 GB, so the above is moot, e.g.,
5Mbit/sec / 8 = 625000 MBytes/sec
625000 * ~274.88 seconds = ~171800000 max burst size, below UINT_MAX
Thus, the burst size at 5Mbit/sec is limited by the __u32 size of
the psched tick field in the kernel API, not the 4 GB limit of the tc
police burst user space API.
However, at higher rates, e.g., 10 Gbit/sec, the burst size is
currently limited by the 4 GB maximum for the burst command line parameter
value, rather than UINT_MAX psched ticks:
10 Gbit/sec / 8 = 1250000000 MBbytes/sec
1250000000 * ~274.88 seconds = ~343600000000, more than UINT_MAX
Here, the maximum duration of a burst the kernel can handle
exceeds 4 GB of burst size.
While the above maximum may be an excessively large burst value,
at 10 Gbit/sec, a 4 GB burst size corresponds to just under 3.5 seconds in
duration:
2^32 bytes / 10 Gbit/sec
2^32 bytes / 1250000000 bytes/sec
equals ~3.43 sec
So, at higher rates, burst sizes exceeding 4 GB are both
reasonable and feasible, up to the UINT_MAX limit for psched ticks.
Enabling this requires changes only to the user space processing of the
burst size parameter in tc.
In principle, the other packet schedulers utilizing psched ticks
for burst sizing, htb and tbf, could be similarly changed to permit larger
burst sizes, but this patch set does not do so.
Separately, for the burst duration calculation overflow (i.e.,
that the number of psched ticks exceeds UINT_MAX), under the current
implementation, one example of overflow is as follows:
# /sbin/tc filter add dev eth0 protocol ip prio 1 parent ffff: handle 1 fw police rate 1Mbit peakrate 10Gbit burst 34375000 mtu 64Kb conform-exceed reclassify
# /sbin/tc -raw filter get dev eth0 ingress protocol ip pref 1 handle 1 fw
filter ingress protocol ip pref 1 fw chain 0 handle 0x1 police 0x1 rate 1Mbit burst 15261b mtu 64Kb [001d1bf8] peakrate 10Gbit action reclassify overhead 0b
ref 1 bind 1
Note that the returned burst value is 15261b, which does not match
the supplied value of 34375000. With this patch set applied, this
situation is flagged as an error.
[0] psched ticks are defined in the kernel in include/net/pkt_sched.h:
#define PSCHED_SHIFT 6
#define PSCHED_TICKS2NS(x) ((s64)(x) << PSCHED_SHIFT)
#define PSCHED_NS2TICKS(x) ((x) >> PSCHED_SHIFT)
#define PSCHED_TICKS_PER_SEC PSCHED_NS2TICKS(NSEC_PER_SEC)
where PSCHED_TICKS_PER_SEC is 15625000.
These values are exported to user space via /proc/net/psched, the
second field being PSCHED_TICKS2NS(1), which at present is 64 (0x40). tc
uses this value to compute its internal "tick_in_usec" variable containing
the number of psched ticks per usec (15.625) used for the psched tick
computations.
Lastly, note that PSCHED_SHIFT was previously 10, and changed to 6
in commit a4a710c4a7490 in 2009. I have not tested backwards
compatibility of these changes with kernels of that era.
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2025-09-16 21:23 Jay Vosburgh @ 2025-09-16 21:56 ` Jay Vosburgh 0 siblings, 0 replies; 1767+ messages in thread From: Jay Vosburgh @ 2025-09-16 21:56 UTC (permalink / raw) Cc: netdev, Jamal Hadi Salim, Stephen Hemminger, David Ahern Jay Vosburgh <jay.vosburgh@canonical.com> wrote: > > >Subject: [PATCH v2 0/4 iproute2-next] tc/police: Allow 64 bit burst size > > In summary, this patchset changes the user space handling of the >tc police burst parameter to permit burst sizes that exceed 4 GB when the >specified rate is high enough that the kernel API for burst can accomodate >such. Ignore this, will fix and repost. -J --- -Jay Vosburgh, jay.vosburgh@canonical.com ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2025-09-15 19:52 Yury Norov (NVIDIA) 2025-09-16 14:48 ` Simon Horman 0 siblings, 1 reply; 1767+ messages in thread From: Yury Norov (NVIDIA) @ 2025-09-15 19:52 UTC (permalink / raw) To: Yoshihiro Shimoda, Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Nikita Yushchenko, Michal Swiatkowski, Geert Uytterhoeven, Uwe Kleine-König, Yury Norov (NVIDIA), Simon Horman Cc: netdev, linux-renesas-soc, linux-kernel Subject: [PATCH net-next v2] net: renesas: rswitch: simplify rswitch_stop() rswitch_stop() opencodes for_each_set_bit(). CC: Simon Horman <horms@kernel.org> Reviewed-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com> --- v1: https://lore.kernel.org/all/20250913181345.204344-1-yury.norov@gmail.com/ v2: Rebase on top of net-next/main drivers/net/ethernet/renesas/rswitch_main.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/ethernet/renesas/rswitch_main.c b/drivers/net/ethernet/renesas/rswitch_main.c index ff5f966c98a9..69676db20fec 100644 --- a/drivers/net/ethernet/renesas/rswitch_main.c +++ b/drivers/net/ethernet/renesas/rswitch_main.c @@ -1656,9 +1656,7 @@ static int rswitch_stop(struct net_device *ndev) if (bitmap_empty(rdev->priv->opened_ports, RSWITCH_NUM_PORTS)) iowrite32(GWCA_TS_IRQ_BIT, rdev->priv->addr + GWTSDID); - for (tag = find_first_bit(rdev->ts_skb_used, TS_TAGS_PER_PORT); - tag < TS_TAGS_PER_PORT; - tag = find_next_bit(rdev->ts_skb_used, TS_TAGS_PER_PORT, tag + 1)) { + for_each_set_bit(tag, rdev->ts_skb_used, TS_TAGS_PER_PORT) { ts_skb = xchg(&rdev->ts_skb[tag], NULL); clear_bit(tag, rdev->ts_skb_used); if (ts_skb) -- 2.43.0 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2025-09-15 19:52 Yury Norov (NVIDIA) @ 2025-09-16 14:48 ` Simon Horman 2025-09-16 15:22 ` Re: Yury Norov 0 siblings, 1 reply; 1767+ messages in thread From: Simon Horman @ 2025-09-16 14:48 UTC (permalink / raw) To: Yury Norov (NVIDIA) Cc: Yoshihiro Shimoda, Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Nikita Yushchenko, Michal Swiatkowski, Geert Uytterhoeven, Uwe Kleine-König, netdev, linux-renesas-soc, linux-kernel On Mon, Sep 15, 2025 at 03:52:31PM -0400, Yury Norov (NVIDIA) wrote: > Subject: [PATCH net-next v2] net: renesas: rswitch: simplify rswitch_stop() > > rswitch_stop() opencodes for_each_set_bit(). > > CC: Simon Horman <horms@kernel.org> > Reviewed-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com> > Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com> > --- > v1: https://lore.kernel.org/all/20250913181345.204344-1-yury.norov@gmail.com/ > v2: Rebase on top of net-next/main > > drivers/net/ethernet/renesas/rswitch_main.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) Hi Yury, I see this marked as Changes Requested in Patchwork. But no response on the netdev ML. So I'll provide one. Unfortunately it seems that the posting is slightly mangled, there was no Subject in the header (or an empty one), and what was supposed to be the Subject ended up at the top of the body. I'm wondering if you could repost with that addressed, being sure to observe the 24h delay between postings. Thanks! ... ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-09-16 14:48 ` Simon Horman @ 2025-09-16 15:22 ` Yury Norov 0 siblings, 0 replies; 1767+ messages in thread From: Yury Norov @ 2025-09-16 15:22 UTC (permalink / raw) To: Simon Horman Cc: Yoshihiro Shimoda, Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Nikita Yushchenko, Michal Swiatkowski, Geert Uytterhoeven, Uwe Kleine-König, netdev, linux-renesas-soc, linux-kernel On Tue, Sep 16, 2025 at 03:48:13PM +0100, Simon Horman wrote: > On Mon, Sep 15, 2025 at 03:52:31PM -0400, Yury Norov (NVIDIA) wrote: > > Subject: [PATCH net-next v2] net: renesas: rswitch: simplify rswitch_stop() > > > > rswitch_stop() opencodes for_each_set_bit(). > > > > CC: Simon Horman <horms@kernel.org> > > Reviewed-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com> > > Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com> > > --- > > v1: https://lore.kernel.org/all/20250913181345.204344-1-yury.norov@gmail.com/ > > v2: Rebase on top of net-next/main > > > > drivers/net/ethernet/renesas/rswitch_main.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > Hi Yury, > > I see this marked as Changes Requested in Patchwork. > But no response on the netdev ML. So I'll provide one. > > Unfortunately it seems that the posting is slightly mangled, Yeah, bad luck. > there was no Subject in the header (or an empty one), and what > was supposed to be the Subject ended up at the top of the body. > > I'm wondering if you could repost with that addressed, > being sure to observe the 24h delay between postings. Sure, will do shortly. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2025-08-29 2:01 xinpeng.wang 2025-08-29 2:42 ` bluez.test.bot 0 siblings, 1 reply; 1767+ messages in thread From: xinpeng.wang @ 2025-08-29 2:01 UTC (permalink / raw) To: linux-bluetooth; +Cc: xinpeng . wang From d364976e93e23f5defbbf711dcda4787bdad3beb Mon Sep 17 00:00:00 2001 From: xinpeng wang <wangxinpeng@uniontech.com> Date: Thu, 28 Aug 2025 21:31:31 +0800 Subject: [PATCH] device: Recreate paired device from storage if previous restoration failed When a USB Bluetooth adapter is resumed from S4 suspend, the kernel may trigger an "index remove" followed by an "index add". BlueZ responds by removing all devices and attempting to recreate them from stored configuration (storage). However, if a connected A2DP device disconnects just before suspend, BlueZ may have started a disconnect timer (via set_disconnect_timer) but not yet freed the session. During this period: - The session pointer is set to NULL and becomes inaccessible. - The session still holds a reference to the device, preventing it from being freed. - As a result, the "index add" event fails to recreate the device from storage (due to D-Bus path conflict or incomplete cleanup). - Later, when the timer expires, a new device is created from discovery data, bypassing storage and causing it to appear as unpaired. This leads to loss of pairing information and confuses desktop applications that rely on paired/unpaired state. This patch improves the device creation logic during discovery: when creating a device from scan data, it checks whether the remote address corresponds to a known paired device in storage. If so, and if no valid device instance exists, it forces recreation from storage to restore the correct paired state. This ensures that devices are properly restored after suspend/resume cycles, even in race conditions involving delayed session cleanup. Signed-off-by: xinpeng.wang <wangxinpeng@uniontech.com> --- src/adapter.c | 111 ++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 99 insertions(+), 12 deletions(-) diff --git a/src/adapter.c b/src/adapter.c index 549a6c0b8..c2ac19f32 100644 --- a/src/adapter.c +++ b/src/adapter.c @@ -342,6 +342,8 @@ struct btd_adapter { struct queue *exp_pending; struct queue *exps; + + GSList *pending_restore_device_addrs; }; static char *adapter_power_state_str(uint32_t power_state) @@ -1400,17 +1402,7 @@ static void adapter_add_device(struct btd_adapter *adapter, static struct btd_device *adapter_create_device(struct btd_adapter *adapter, const bdaddr_t *bdaddr, - uint8_t bdaddr_type) -{ - struct btd_device *device; - - device = device_create(adapter, bdaddr, bdaddr_type); - if (!device) - return NULL; - - adapter_add_device(adapter, device); - return device; -} + uint8_t bdaddr_type); static void service_auth_cancel(struct service_auth *auth) { @@ -4969,6 +4961,95 @@ done: mgmt_tlv_list_free(list); } +static struct btd_device *adapter_create_device(struct btd_adapter *adapter, + const bdaddr_t *bdaddr, + uint8_t bdaddr_type) +{ + struct btd_device *device; + char addr[18]; + GSList *l; + GKeyFile *key_file = NULL; + + ba2str(bdaddr, addr); + + l = g_slist_find_custom(adapter->pending_restore_device_addrs, addr, + (GCompareFunc)strcasecmp); + if (l != NULL) { + char filename[PATH_MAX]; + GError *gerr = NULL; + + create_filename(filename, PATH_MAX, "/%s/%s/info", + btd_adapter_get_storage_dir(adapter), + addr); + + key_file = g_key_file_new(); + if (!g_key_file_load_from_file(key_file, filename, 0, &gerr)) { + error("Unable to load key file from %s: (%s)", filename, + gerr->message); + g_clear_error(&gerr); + adapter->pending_restore_device_addrs = + g_slist_delete_link(adapter->pending_restore_device_addrs, l); + g_free(l->data); + key_file = NULL; + } + } + + if (key_file != NULL) { + struct link_key_info *key_info; + struct smp_ltk_info *ltk_info; + struct smp_ltk_info *peripheral_ltk_info; + struct irk_info *irk_info; + + DBG("Found device %s but restoring from storage", addr); + device = device_create_from_storage(adapter, addr, key_file); + if (!device) { + g_key_file_free(key_file); + return NULL; + } + adapter->pending_restore_device_addrs = + g_slist_delete_link(adapter->pending_restore_device_addrs, l); + g_free(l->data); + + if (bdaddr_type == BDADDR_BREDR) + device_set_bredr_support(device); + else + device_set_le_support(device, bdaddr_type); + + key_info = get_key_info(key_file, addr, bdaddr_type); + ltk_info = get_ltk_info(key_file, addr, bdaddr_type); + peripheral_ltk_info = get_peripheral_ltk_info(key_file, + addr, bdaddr_type); + irk_info = get_irk_info(key_file, addr, bdaddr_type); + if (key_info) { + device_set_paired(device, BDADDR_BREDR); + device_set_bonded(device, BDADDR_BREDR); + } + if (ltk_info || peripheral_ltk_info) { + struct smp_ltk_info *info = ltk_info ? ltk_info : peripheral_ltk_info; + device_set_paired(device, ltk_info->bdaddr_type); + device_set_bonded(device, ltk_info->bdaddr_type); + + device_set_ltk(device, info->val, info->central, + info->enc_size); + } + if (irk_info) + device_set_rpa(device, true); + + btd_device_set_temporary(device, false); + g_free(key_info); + g_free(ltk_info); + g_free(peripheral_ltk_info); + g_free(irk_info); + } else { + device = device_create(adapter, bdaddr, bdaddr_type); + if (!device) + return NULL; + } + + adapter_add_device(adapter, device); + return device; +} + static void load_devices(struct btd_adapter *adapter) { char dirname[PATH_MAX]; @@ -5087,8 +5168,11 @@ static void load_devices(struct btd_adapter *adapter) device = device_create_from_storage(adapter, entry->d_name, key_file); - if (!device) + if (!device) { + char *addr_copy = g_strdup(entry->d_name); + adapter->pending_restore_device_addrs = g_slist_append(adapter->pending_restore_device_addrs,addr_copy); goto free; + } if (irk_info) device_set_rpa(device, true); @@ -7085,6 +7169,9 @@ static void adapter_remove(struct btd_adapter *adapter) adapter->msd_callbacks = NULL; queue_remove_all(adapter->exp_pending, NULL, NULL, cancel_exp_pending); + + g_slist_free_full(adapter->pending_restore_device_addrs,g_free); + adapter->pending_restore_device_addrs = NULL; } const char *adapter_get_path(struct btd_adapter *adapter) -- 2.20.1 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* RE: 2025-08-29 2:01 xinpeng.wang @ 2025-08-29 2:42 ` bluez.test.bot 0 siblings, 0 replies; 1767+ messages in thread From: bluez.test.bot @ 2025-08-29 2:42 UTC (permalink / raw) To: linux-bluetooth, wangxinpeng [-- Attachment #1: Type: text/plain, Size: 382 bytes --] This is an automated email and please do not reply to this email. Dear Submitter, Thank you for submitting the patches to the linux bluetooth mailing list. While preparing the CI tests, the patches you submitted couldn't be applied to the current HEAD of the repository. ----- Output ----- Please resolve the issue and submit the patches again. --- Regards, Linux Bluetooth ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH] net/netfilter/ipvs: Fix data-race in ip_vs_add_service / ip_vs_out_hook @ 2025-08-27 6:48 Julian Anastasov 2025-08-27 14:43 ` Zhang Tengfei 0 siblings, 1 reply; 1767+ messages in thread From: Julian Anastasov @ 2025-08-27 6:48 UTC (permalink / raw) To: Zhang Tengfei Cc: Simon Horman, lvs-devel, netfilter-devel, Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal, David S . Miller, David Ahern, Eric Dumazet, Jakub Kicinski, Paolo Abeni, coreteam, syzbot+1651b5234028c294c339 Hello, On Tue, 26 Aug 2025, Zhang Tengfei wrote: > A data-race was detected by KCSAN between ip_vs_add_service() which > acts as a writer, and ip_vs_out_hook() which acts as a reader. This > can lead to unpredictable behavior and crashes. One observed symptom > is the "no destination available" error when processing packets. > > The race occurs on the `enable` flag within the `netns_ipvs` > struct. This flag was being written in the configuration path without > any protection, while concurrently being read in the packet processing > path. This lack of synchronization means a reader on one CPU could see a > partially initialized service, leading to incorrect behavior. > > To fix this, convert the `enable` flag from a plain integer to an > atomic_t. This ensures that all reads and writes to the flag are atomic. > More importantly, using atomic_set() and atomic_read() provides the > necessary memory barriers to guarantee that changes to other fields of > the service are visible to the reader CPU before the service is marked > as enabled. > > Reported-by: syzbot+1651b5234028c294c339@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=1651b5234028c294c339 > Signed-off-by: Zhang Tengfei <zhtfdev@gmail.com> > --- > include/net/ip_vs.h | 2 +- > net/netfilter/ipvs/ip_vs_conn.c | 4 ++-- > net/netfilter/ipvs/ip_vs_core.c | 10 +++++----- > net/netfilter/ipvs/ip_vs_ctl.c | 6 +++--- > net/netfilter/ipvs/ip_vs_est.c | 16 ++++++++-------- > 5 files changed, 19 insertions(+), 19 deletions(-) > > diff --git a/net/netfilter/ipvs/ip_vs_est.c b/net/netfilter/ipvs/ip_vs_est.c > index 15049b826732..c5aa2660de92 100644 > --- a/net/netfilter/ipvs/ip_vs_est.c > +++ b/net/netfilter/ipvs/ip_vs_est.c ... > @@ -757,7 +757,7 @@ static void ip_vs_est_calc_phase(struct netns_ipvs *ipvs) > mutex_lock(&ipvs->est_mutex); > for (id = 1; id < ipvs->est_kt_count; id++) { > /* netns clean up started, abort */ > - if (!ipvs->enable) > + if (!atomic_read(&ipvs->enable)) > goto unlock2; It is a simple flag but as it is checked in loops in a few places in ip_vs_est.c, lets use READ_ONCE/WRITE_ONCE as suggested by Florian and Eric. The 3 checks in hooks in ip_vs_core.c can be simply removed: in ip_vs_out_hook, ip_vs_in_hook and ip_vs_forward_icmp. We can see enable=0 in rare cases which is not fatal. It is a flying packet in two possible cases: 1. after hooks are registered but before the flag is set 2. after the hooks are unregistered on cleanup_net Regards -- Julian Anastasov <ja@ssi.bg> ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) 2025-08-27 6:48 [PATCH] net/netfilter/ipvs: Fix data-race in ip_vs_add_service / ip_vs_out_hook Julian Anastasov @ 2025-08-27 14:43 ` Zhang Tengfei 2025-08-27 21:37 ` Pablo Neira Ayuso 0 siblings, 1 reply; 1767+ messages in thread From: Zhang Tengfei @ 2025-08-27 14:43 UTC (permalink / raw) To: ja Cc: coreteam, davem, dsahern, edumazet, fw, horms, kadlec, kuba, lvs-devel, netfilter-devel, pabeni, pablo, syzbot+1651b5234028c294c339, zhtfdev Hi everyone, Here is the v2 patch that incorporates the feedback. Many thanks to Julian for his thorough review and for providing the detailed plan for this new version, and thanks to Florian and Eric for suggestions. Subject: [PATCH v2] net/netfilter/ipvs: Use READ_ONCE/WRITE_ONCE for ipvs->enable KCSAN reported a data-race on the `ipvs->enable` flag, which is written in the control path and read concurrently from many other contexts. Following a suggestion by Julian, this patch fixes the race by converting all accesses to use `WRITE_ONCE()/READ_ONCE()`. This lightweight approach ensures atomic access and acts as a compiler barrier, preventing unsafe optimizations where the flag is checked in loops (e.g., in ip_vs_est.c). Additionally, the now-obsolete `enable` checks in the fast path hooks (`ip_vs_in_hook`, `ip_vs_out_hook`, `ip_vs_forward_icmp`) are removed. These are unnecessary since commit 857ca89711de ("ipvs: register hooks only with services"). Reported-by: syzbot+1651b5234028c294c339@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1651b5234028c294c339 Suggested-by: Julian Anastasov <ja@ssi.bg> Link: https://lore.kernel.org/lvs-devel/2189fc62-e51e-78c9-d1de-d35b8e3657e3@ssi.bg/ Signed-off-by: Zhang Tengfei <zhtfdev@gmail.com> --- v2: - Switched from atomic_t to the suggested READ_ONCE()/WRITE_ONCE(). - Removed obsolete checks from the packet processing hooks. - Polished commit message based on feedback. --- net/netfilter/ipvs/ip_vs_conn.c | 4 ++-- net/netfilter/ipvs/ip_vs_core.c | 11 ++++------- net/netfilter/ipvs/ip_vs_ctl.c | 6 +++--- net/netfilter/ipvs/ip_vs_est.c | 16 ++++++++-------- 4 files changed, 17 insertions(+), 20 deletions(-) diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c index 965f3c8e5..37ebb0cb6 100644 --- a/net/netfilter/ipvs/ip_vs_conn.c +++ b/net/netfilter/ipvs/ip_vs_conn.c @@ -885,7 +885,7 @@ static void ip_vs_conn_expire(struct timer_list *t) * conntrack cleanup for the net. */ smp_rmb(); - if (ipvs->enable) + if (READ_ONCE(ipvs->enable)) ip_vs_conn_drop_conntrack(cp); } @@ -1439,7 +1439,7 @@ void ip_vs_expire_nodest_conn_flush(struct netns_ipvs *ipvs) cond_resched_rcu(); /* netns clean up started, abort delayed work */ - if (!ipvs->enable) + if (!READ_ONCE(ipvs->enable)) break; } rcu_read_unlock(); diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c index c7a8a08b7..5ea7ab8bf 100644 --- a/net/netfilter/ipvs/ip_vs_core.c +++ b/net/netfilter/ipvs/ip_vs_core.c @@ -1353,9 +1353,6 @@ ip_vs_out_hook(void *priv, struct sk_buff *skb, const struct nf_hook_state *stat if (unlikely(!skb_dst(skb))) return NF_ACCEPT; - if (!ipvs->enable) - return NF_ACCEPT; - ip_vs_fill_iph_skb(af, skb, false, &iph); #ifdef CONFIG_IP_VS_IPV6 if (af == AF_INET6) { @@ -1940,7 +1937,7 @@ ip_vs_in_hook(void *priv, struct sk_buff *skb, const struct nf_hook_state *state return NF_ACCEPT; } /* ipvs enabled in this netns ? */ - if (unlikely(sysctl_backup_only(ipvs) || !ipvs->enable)) + if (unlikely(sysctl_backup_only(ipvs))) return NF_ACCEPT; ip_vs_fill_iph_skb(af, skb, false, &iph); @@ -2108,7 +2105,7 @@ ip_vs_forward_icmp(void *priv, struct sk_buff *skb, int r; /* ipvs enabled in this netns ? */ - if (unlikely(sysctl_backup_only(ipvs) || !ipvs->enable)) + if (unlikely(sysctl_backup_only(ipvs))) return NF_ACCEPT; if (state->pf == NFPROTO_IPV4) { @@ -2295,7 +2292,7 @@ static int __net_init __ip_vs_init(struct net *net) return -ENOMEM; /* Hold the beast until a service is registered */ - ipvs->enable = 0; + WRITE_ONCE(ipvs->enable, 0); ipvs->net = net; /* Counters used for creating unique names */ ipvs->gen = atomic_read(&ipvs_netns_cnt); @@ -2367,7 +2364,7 @@ static void __net_exit __ip_vs_dev_cleanup_batch(struct list_head *net_list) ipvs = net_ipvs(net); ip_vs_unregister_hooks(ipvs, AF_INET); ip_vs_unregister_hooks(ipvs, AF_INET6); - ipvs->enable = 0; /* Disable packet reception */ + WRITE_ONCE(ipvs->enable, 0); /* Disable packet reception */ smp_wmb(); ip_vs_sync_net_cleanup(ipvs); } diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c index 6a6fc4478..4c8fa22be 100644 --- a/net/netfilter/ipvs/ip_vs_ctl.c +++ b/net/netfilter/ipvs/ip_vs_ctl.c @@ -256,7 +256,7 @@ static void est_reload_work_handler(struct work_struct *work) struct ip_vs_est_kt_data *kd = ipvs->est_kt_arr[id]; /* netns clean up started, abort delayed work */ - if (!ipvs->enable) + if (!READ_ONCE(ipvs->enable)) goto unlock; if (!kd) continue; @@ -1483,9 +1483,9 @@ ip_vs_add_service(struct netns_ipvs *ipvs, struct ip_vs_service_user_kern *u, *svc_p = svc; - if (!ipvs->enable) { + if (!READ_ONCE(ipvs->enable)) { /* Now there is a service - full throttle */ - ipvs->enable = 1; + WRITE_ONCE(ipvs->enable, 1); /* Start estimation for first time */ ip_vs_est_reload_start(ipvs); diff --git a/net/netfilter/ipvs/ip_vs_est.c b/net/netfilter/ipvs/ip_vs_est.c index 15049b826..93a925f1e 100644 --- a/net/netfilter/ipvs/ip_vs_est.c +++ b/net/netfilter/ipvs/ip_vs_est.c @@ -231,7 +231,7 @@ static int ip_vs_estimation_kthread(void *data) void ip_vs_est_reload_start(struct netns_ipvs *ipvs) { /* Ignore reloads before first service is added */ - if (!ipvs->enable) + if (!READ_ONCE(ipvs->enable)) return; ip_vs_est_stopped_recalc(ipvs); /* Bump the kthread configuration genid */ @@ -306,7 +306,7 @@ static int ip_vs_est_add_kthread(struct netns_ipvs *ipvs) int i; if ((unsigned long)ipvs->est_kt_count >= ipvs->est_max_threads && - ipvs->enable && ipvs->est_max_threads) + READ_ONCE(ipvs->enable) && ipvs->est_max_threads) return -EINVAL; mutex_lock(&ipvs->est_mutex); @@ -343,7 +343,7 @@ static int ip_vs_est_add_kthread(struct netns_ipvs *ipvs) } /* Start kthread tasks only when services are present */ - if (ipvs->enable && !ip_vs_est_stopped(ipvs)) { + if (READ_ONCE(ipvs->enable) && !ip_vs_est_stopped(ipvs)) { ret = ip_vs_est_kthread_start(ipvs, kd); if (ret < 0) goto out; @@ -486,7 +486,7 @@ int ip_vs_start_estimator(struct netns_ipvs *ipvs, struct ip_vs_stats *stats) struct ip_vs_estimator *est = &stats->est; int ret; - if (!ipvs->est_max_threads && ipvs->enable) + if (!ipvs->est_max_threads && READ_ONCE(ipvs->enable)) ipvs->est_max_threads = ip_vs_est_max_threads(ipvs); est->ktid = -1; @@ -663,7 +663,7 @@ static int ip_vs_est_calc_limits(struct netns_ipvs *ipvs, int *chain_max) /* Wait for cpufreq frequency transition */ wait_event_idle_timeout(wq, kthread_should_stop(), HZ / 50); - if (!ipvs->enable || kthread_should_stop()) + if (!READ_ONCE(ipvs->enable) || kthread_should_stop()) goto stop; } @@ -681,7 +681,7 @@ static int ip_vs_est_calc_limits(struct netns_ipvs *ipvs, int *chain_max) rcu_read_unlock(); local_bh_enable(); - if (!ipvs->enable || kthread_should_stop()) + if (!READ_ONCE(ipvs->enable) || kthread_should_stop()) goto stop; cond_resched(); @@ -757,7 +757,7 @@ static void ip_vs_est_calc_phase(struct netns_ipvs *ipvs) mutex_lock(&ipvs->est_mutex); for (id = 1; id < ipvs->est_kt_count; id++) { /* netns clean up started, abort */ - if (!ipvs->enable) + if (!READ_ONCE(ipvs->enable)) goto unlock2; kd = ipvs->est_kt_arr[id]; if (!kd) @@ -787,7 +787,7 @@ static void ip_vs_est_calc_phase(struct netns_ipvs *ipvs) id = ipvs->est_kt_count; next_kt: - if (!ipvs->enable || kthread_should_stop()) + if (!READ_ONCE(ipvs->enable) || kthread_should_stop()) goto unlock; id--; if (id < 0) -- 2.34.1 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2025-08-27 14:43 ` Zhang Tengfei @ 2025-08-27 21:37 ` Pablo Neira Ayuso 0 siblings, 0 replies; 1767+ messages in thread From: Pablo Neira Ayuso @ 2025-08-27 21:37 UTC (permalink / raw) To: Zhang Tengfei Cc: ja, coreteam, davem, dsahern, edumazet, fw, horms, kadlec, kuba, lvs-devel, netfilter-devel, pabeni, syzbot+1651b5234028c294c339 On Wed, Aug 27, 2025 at 10:43:42PM +0800, Zhang Tengfei wrote: > Hi everyone, > > Here is the v2 patch that incorporates the feedback. Patch without subject will not fly too far, I'm afraid you will have to resubmit. One more comment below. > Many thanks to Julian for his thorough review and for providing > the detailed plan for this new version, and thanks to Florian > and Eric for suggestions. > > Subject: [PATCH v2] net/netfilter/ipvs: Use READ_ONCE/WRITE_ONCE for > ipvs->enable > > KCSAN reported a data-race on the `ipvs->enable` flag, which is > written in the control path and read concurrently from many other > contexts. > > Following a suggestion by Julian, this patch fixes the race by > converting all accesses to use `WRITE_ONCE()/READ_ONCE()`. > This lightweight approach ensures atomic access and acts as a > compiler barrier, preventing unsafe optimizations where the flag > is checked in loops (e.g., in ip_vs_est.c). > > Additionally, the now-obsolete `enable` checks in the fast path > hooks (`ip_vs_in_hook`, `ip_vs_out_hook`, `ip_vs_forward_icmp`) > are removed. These are unnecessary since commit 857ca89711de > ("ipvs: register hooks only with services"). > > Reported-by: syzbot+1651b5234028c294c339@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=1651b5234028c294c339 > Suggested-by: Julian Anastasov <ja@ssi.bg> > Link: https://lore.kernel.org/lvs-devel/2189fc62-e51e-78c9-d1de-d35b8e3657e3@ssi.bg/ > Signed-off-by: Zhang Tengfei <zhtfdev@gmail.com> > > --- > v2: > - Switched from atomic_t to the suggested READ_ONCE()/WRITE_ONCE(). > - Removed obsolete checks from the packet processing hooks. > - Polished commit message based on feedback. > --- > net/netfilter/ipvs/ip_vs_conn.c | 4 ++-- > net/netfilter/ipvs/ip_vs_core.c | 11 ++++------- > net/netfilter/ipvs/ip_vs_ctl.c | 6 +++--- > net/netfilter/ipvs/ip_vs_est.c | 16 ++++++++-------- > 4 files changed, 17 insertions(+), 20 deletions(-) [...] > diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c > index c7a8a08b7..5ea7ab8bf 100644 > --- a/net/netfilter/ipvs/ip_vs_core.c > +++ b/net/netfilter/ipvs/ip_vs_core.c > @@ -1353,9 +1353,6 @@ ip_vs_out_hook(void *priv, struct sk_buff *skb, const struct nf_hook_state *stat > if (unlikely(!skb_dst(skb))) > return NF_ACCEPT; > > - if (!ipvs->enable) > - return NF_ACCEPT; Patch does say why is this going away? If you think this is not necessary, then make a separated patch and example why this is needed? Thanks > ip_vs_fill_iph_skb(af, skb, false, &iph); > #ifdef CONFIG_IP_VS_IPV6 > if (af == AF_INET6) { ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [RFC PATCH] time: introduce BOOT_TIME_TRACKER and minimal boot timestamp @ 2025-08-23 22:53 Thomas Gleixner 2025-09-01 4:05 ` Kaiwan N Billimoria 0 siblings, 1 reply; 1767+ messages in thread From: Thomas Gleixner @ 2025-08-23 22:53 UTC (permalink / raw) To: vishnu singh, mark.rutland, maz, catalin.marinas, will, jstultz, sboyd, akpm, chenhuacai, pmladek, agordeev, bigeasy, urezki, Llillian, francesco, guoweikang.kernel, alexander.shishkin, rrangel, kpsingh, anna-maria, mingo, frederic, linux-kernel, linux-arm-kernel On Sat, Aug 23 2025 at 9:49, vishnu singh wrote: On Sat, Aug 23 2025 at 10:10, vishnu singh wrote: Why are you sending the same thing twice within 20 minutes? > From: Vishnu Singh <v-singh1@ti.com> > > Part of BOOT SIG Initiative, What the heck is BOOT SIG Initiative? Are you seriously expecting me to look this up? Please don't provide me a random link to it because it's not relevant to the rest of what I have to say about this. > , This patch adds a tiny,opt-in facility to help measure kernel boot > duration without full tracing: 1) Any spell checker would have pointed out to you that 'This' after a comma is not a proper sentence and neither is 'tiny,opt-in facility' 2) You failed to read documentation: # git grep "This patch" Documentation/process/ 3) This change log starts with the WHAT and fails completely to explain the WHY. See: https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#changelog > New CONFIG_BOOT_TIME_TRACKER in kernel/time/Kconfig. > When enabled, the kernel logs two boot markers: > 1. kernel entry in start_kernel() > 2. first userspace start in kernel_init() before run_init_process() > > These markers are intended for post-boot parsers to compute coarse > kernel boot time and to merge with bootloader/MCU/DSP records into > a unified timeline. > > Core helper u64 boot_time_now() in kernel/time/boot_time_now.c, > exporting a counter‑derived timestamp via small per-arch primitives. > This series includes an initial arm64 primitive that uses CNTVCT_EL0 > as the source, other architectures can wire up equivalents. > > Files touched: > kernel/time/Kconfig, kernel/time/Makefile > kernel/time/boot_time_now.c (new core helper) > arch/arm64/include/asm/boot_time_primitives.h (arm64 primitive) > include/linux/boot_time_now.h (public API + IDs) > init/main.c (print two markers) Seriously? This can be seen from the diffstat and the patch itself. You still fail to explain the problem you are trying to solve and instead babble about WHAT you are doing, which means you never read the documentation of the project which you are trying to contribute to. Do you really think that the people who spent time on writing it, did so just to be ignored? > This complements U-Boot’s stashed bootstage records so a userspace tool > can build a system-wide boot timeline across SPL, U-Boot, kernel and other > subsystems. > > Reference boot-time parser utility: > https://github.com/v-singh1/boot-time-parser > > Sample boot time report: > +--------------------------------------------------------------------+ > am62xx-evm Boot Time Report > +--------------------------------------------------------------------+ > Device Power On : 0 ms <SNIP> > IPC_SYNC_ALL = 6787 ms (+151 ms) > +--------------------------------------------------------------------+ How are these 30 lines of useless information helpful to understand the underlying problem? That's what cover letters are for. > MAINTAINERS | 3 +++ > arch/arm64/include/asm/boot_time_primitives.h | 14 ++++++++++++++ > include/linux/boot_time_now.h | 16 ++++++++++++++++ > init/main.c | 13 +++++++++++++ > kernel/time/Kconfig | 10 ++++++++++ > kernel/time/Makefile | 1 + > kernel/time/boot_time_now.c | 13 +++++++++++++ This does too many things at once. See Documentation. One patch for creating the infrastructure with a proper rationale and then one which hooks it up. Again: Documentation has not been written to be ignored. RFC patches are not exempt from that. > +static inline u64 arch_boot_counter_now(void) > +{ > + return ((arch_timer_read_cntvct_el0() * 1000000) / arch_timer_get_cntfrq()); > +} Q: What guarantees that this timer is available and functional at this point? A: Nothing > +++ b/include/linux/boot_time_now.h What means boot_time_now? You couldn't come up with a less non-descriptive name, right? > +enum kernel_bootstage_id { > + BOOTSTAGE_ID_KERNEL_START = 300, > + BOOTSTAGE_ID_KERNEL_END = 301, Aside of the formatting (See Documentation), these are random numbers pulled out of thin air without any explanation why they need to start at 300. > +}; > + > +/* Return boot time in nanoseconds using hardware counter */ > +u64 boot_time_now(void); That's a function name which is as bad as is can be. This is about getting an early time stamp and that needs to be properly named _AND_ encapsulated so it works universally without some magic hardware dependency. If at all, see below. > #include <kunit/test.h> > > +#ifdef CONFIG_BOOT_TIME_TRACKER > +#include <linux/boot_time_now.h> > +#endif What's this ifdeffery for? Headers have to be written in a way that they can be unconditionally included. IOW, put the ifdeffery into the header. > @@ -929,6 +933,11 @@ void start_kernel(void) > page_address_init(); > pr_notice("%s", linux_banner); > setup_arch(&command_line); > + > +#ifdef CONFIG_BOOT_TIME_TRACKER > + pr_info("[BOOT TRACKER] - ID:%d, %s = %llu\n", > + BOOTSTAGE_ID_KERNEL_START, __func__, boot_time_now()); > +#endif Seriously? Have you looked at all the functions invoked in this file? Those which depend on a config have: #ifdef CONFIG_FOO void foo_init(void); #else static inline void foo_init(void) { } #endif in the headers to avoid this horrible #ifdef maze. No? > diff --git a/kernel/time/boot_time_now.c b/kernel/time/boot_time_now.c > new file mode 100644 > index 000000000000..6dc12d454be0 > --- /dev/null > +++ b/kernel/time/boot_time_now.c > @@ -0,0 +1,13 @@ > +// SPDX-License-Identifier: LGPL-2.0 > + > +#include <linux/boot_time_now.h> > +#include <asm/boot_time_primitives.h> > + > +u64 boot_time_now(void) > +{ > + return arch_boot_counter_now(); > +} > +EXPORT_SYMBOL_GPL(boot_time_now); Why does this need to exported for modules when the only users are always built in? > + > +MODULE_DESCRIPTION("boot time tracker"); > +MODULE_LICENSE("GPL"); Why needs this a module description? This has always to be built in, no? Copy and pasta from some boilerplate template is fine, but using brain on what to paste is not optional. But that's all irrelevant, because none of this is actually required in the first place as there is existing infrastructure, which allows you to gather most of that information already today. Extending it to gain what you really want to achieve is trivial enough when you actually start to look at the existing infrastructure instead of blindly hacking some ill-defined mechanism into the kernel, which relies on the assumption that a particular piece of hardware is available and functional. That assumption is not even true for ARM64 under all circumstances. dmesg already exposes time stamps and while they might be coarse grained until a sched clock is registered, you still can utilize that registration: --- a/kernel/time/sched_clock.c +++ b/kernel/time/sched_clock.c @@ -236,16 +236,14 @@ sched_clock_register(u64 (*read)(void), /* Calculate the ns resolution of this counter */ res = cyc_to_ns(1ULL, new_mult, new_shift); - pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns, wraps every %lluns\n", - bits, r, r_unit, res, wrap); + pr_info("sched_clock: %pS: %u bits at %lu%cHz, resolution %lluns, wraps every %lluns hwcnt: %llu\n", + read, bits, r, r_unit, res, wrap, read()); /* Enable IRQ time accounting if we have a fast enough sched_clock() */ if (irqtime > 0 || (irqtime == -1 && rate >= 1000000)) enable_sched_clock_irqtime(); local_irq_restore(flags); - - pr_debug("Registered %pS as sched_clock source\n", read); } void __init generic_sched_clock_init(void) That message provides you all the information you need for your pretty printed postprocessing results by re-calculating all the other coarse grained dmesg timestamps from there, no? That obviously does not work on architectures which do no use the sched_clock infrastructure. Some of them do not for a good reason, but emitting the same information for them if anyone is interested is trivial enough. And that's none of your problems. If you really need some not yet existing dedicated time stamp in the maze of dmesg, then add it unconditionlly and without introducing an artifical subsystem which is of no value at all. But I tell you that's not necessary at all. The points in dmesg are well defined. Here is the relevant output on a arm64 machine: [ 0.000000] Linux version 6.17.0-rc1 ... ... [ 0.000008] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 3579139424256ns which is missing the actual hardware value, but see above... So let's assume this give you [ 0.000008] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 3579139424256ns hwcnt: 19000000 Which means that the counter accumulated 19000000 increments since the hardware was powered up, no? So the [0.000008] timestamp happens exactly 1.0 seconds after power on. At least to my understanding of basic math, but your favourite AI bot might disagree with that. So anything you need for your pretty printing boot record can be retrieved from there without any magic 300 and 301 numbers. Because there is another printk() which has been there forever: [ 11.651192] Run /init as init process No? Thanks, tglx ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) 2025-08-23 22:53 [RFC PATCH] time: introduce BOOT_TIME_TRACKER and minimal boot timestamp Thomas Gleixner @ 2025-09-01 4:05 ` Kaiwan N Billimoria 2025-09-01 5:57 ` Kaiwan N Billimoria 0 siblings, 1 reply; 1767+ messages in thread From: Kaiwan N Billimoria @ 2025-09-01 4:05 UTC (permalink / raw) To: tglx Cc: Llillian, agordeev, akpm, alexander.shishkin, anna-maria, bigeasy, catalin.marinas, chenhuacai, francesco, frederic, guoweikang.kernel, jstultz, kpsingh, linux-arm-kernel, linux-kernel, mark.rutland, maz, mingo, pmladek, rrangel, sboyd, urezki, v-singh1, will, Kaiwan N Billimoria > What the heck is BOOT SIG Initiative? Very, very briefly: it's an initiative that plans to measure the complete or unified boot time, i.e., the time it takes to boot the system completely. This includes (or plans to) track the time taken for: - Boot from CPU power-on, ROM code execution - 1st, 2nd, (and possibly) 3rd stage bootloader(s) - Linux kernel upto running the PID 1 process - Include time taken for onboard MCUs (and their apps to come up). The plan is to be able to show the cumulative and individual times taken across all of these. Then report it via ASCII text and a GUI system (as of now, a HTML file). For anyone interested, here's the PDF of a super presentation on this topic by Vishnu P Singh (OP) this August at the OSS EU: https://static.sched.com/hosted_files/osseu2025/a2/EOSS_2025_Unified%20Boot%20Time%20log%20based%20measurement.pdf As mentioned by Vishnu, the work is in the very early dev stages. > - pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns, wraps every %lluns\n", > - bits, r, r_unit, res, wrap); > + pr_info("sched_clock: %pS: %u bits at %lu%cHz, resolution %lluns, wraps every %lluns hwcnt: %llu\n", > + read, bits, r, r_unit, res, wrap, read()); --snip-- > So let's assume this give you > > [ 0.000008] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps > every 3579139424256ns hwcnt: 19000000 > > Which means that the counter accumulated 19000000 increments since the > hardware was powered up, no? I agree with your approach Thomas (tglx)! (eye-roll)... So, following this approach, here's the resulting tiny patch: From 1e687ab12269f5f129b17eb7e9c3c5c2cec441b7 Mon Sep 17 00:00:00 2001 From: Kaiwan N Billimoria <kaiwan.billimoria@gmail.com> Date: Mon, 1 Sep 2025 09:17:57 +0530 Subject: [PATCH] [sched-clock] Extend printk to show h/w counter in a parseable manner Signed-off-by: Kaiwan N Billimoria <kaiwan.billimoria@gmail.com> --- kernel/time/sched_clock.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c index cc15fe293719..e4fe900d6b60 100644 --- a/kernel/time/sched_clock.c +++ b/kernel/time/sched_clock.c @@ -236,16 +236,14 @@ sched_clock_register(u64 (*read)(void), int bits, unsigned long rate) /* Calculate the ns resolution of this counter */ res = cyc_to_ns(1ULL, new_mult, new_shift); - pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns, wraps every %lluns\n", - bits, r, r_unit, res, wrap); + pr_info("sched_clock: %pS: bits=%u,freq=%lu %cHz,resolution=%llu ns,wraps every=%llu ns,hwcnt=%llu\n", + read, bits, r, r_unit, res, wrap, read()); /* Enable IRQ time accounting if we have a fast enough sched_clock() */ if (irqtime > 0 || (irqtime == -1 && rate >= 1000000)) enable_sched_clock_irqtime(); local_irq_restore(flags); - - pr_debug("Registered %pS as sched_clock source\n", read); } void __init generic_sched_clock_init(void) -- 2.43.0 Of course, this is almost identical to what Thomas has already shown. I've added some formatting to make for easier parsing. A sample output obtained with this code on a patched kernel for the BeaglePlay k3 am625 board: [ 0.000001] sched_clock: arch_counter_get_cntpct+0x0/0x18: bits=58,freq=200 MHz,resolution=5 ns,wraps every=4398046511102 ns,hwcnt=1409443611 This printk format allows us to easily parse it; f.e. to obtain the hwcnt value: debian@BeagleBone:~$ dmesg |grep sched_clock |awk -F, '{print $5}' hwcnt=1409443611 So, just confirming: here 1409443611 divided by 200 MHz gives us 7.047218055s since boot, and thus the actual timestamp here is that plus 0.000001s yes? (Over 7s here? yes, it's just that I haven't yet setup U-Boot properly for uSD card boot, thus am manually loading commands in U-Boot to boot up, that's all). A question (perhaps very stupid): will the hwcnt - the output of the read() - be guaranteed to be (close to) the number of increments since processor power-up (or reset)? Meaning, it's simply a hardware feature and agnostic to what code the core was executing (ROM/BL/kernel), yes? If so, I guess we can move forward with this approach... Else, or otherwise, suggestions are welcome, Regards, Kaiwan. ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2025-09-01 4:05 ` Kaiwan N Billimoria @ 2025-09-01 5:57 ` Kaiwan N Billimoria 0 siblings, 0 replies; 1767+ messages in thread From: Kaiwan N Billimoria @ 2025-09-01 5:57 UTC (permalink / raw) To: tglx Cc: Llillian, agordeev, akpm, alexander.shishkin, anna-maria, bigeasy, catalin.marinas, chenhuacai, francesco, frederic, guoweikang.kernel, jstultz, kpsingh, linux-arm-kernel, linux-kernel, mark.rutland, maz, mingo, pmladek, rrangel, sboyd, urezki, v-singh1, will Apologies, subject missing; it's: time: introduce BOOT_TIME_TRACKER and minimal boot timestamp On Mon, Sep 1, 2025 at 9:36 AM Kaiwan N Billimoria <kaiwan.billimoria@gmail.com> wrote: > > > What the heck is BOOT SIG Initiative? > Very, very briefly: it's an initiative that plans to measure the complete or > unified boot time, i.e., the time it takes to boot the system completely. This > includes (or plans to) track the time taken for: > - Boot from CPU power-on, ROM code execution > - 1st, 2nd, (and possibly) 3rd stage bootloader(s) > - Linux kernel upto running the PID 1 process > - Include time taken for onboard MCUs (and their apps to come up). > > The plan is to be able to show the cumulative and individual times taken across > all of these. Then report it via ASCII text and a GUI system (as of now, a HTML > file). > For anyone interested, here's the PDF of a super presentation on this topic by > Vishnu P Singh (OP) this August at the OSS EU: > https://static.sched.com/hosted_files/osseu2025/a2/EOSS_2025_Unified%20Boot%20Time%20log%20based%20measurement.pdf > As mentioned by Vishnu, the work is in the very early dev stages. > > > - pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns, wraps every %lluns\n", > > - bits, r, r_unit, res, wrap); > > + pr_info("sched_clock: %pS: %u bits at %lu%cHz, resolution %lluns, wraps every %lluns hwcnt: %llu\n", > > + read, bits, r, r_unit, res, wrap, read()); > --snip-- > > So let's assume this give you > > > > [ 0.000008] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps > > every 3579139424256ns hwcnt: 19000000 > > > > Which means that the counter accumulated 19000000 increments since the > > hardware was powered up, no? > I agree with your approach Thomas (tglx)! (eye-roll)... So, following this > approach, here's the resulting tiny patch: > > From 1e687ab12269f5f129b17eb7e9c3c5c2cec441b7 Mon Sep 17 00:00:00 2001 > From: Kaiwan N Billimoria <kaiwan.billimoria@gmail.com> > Date: Mon, 1 Sep 2025 09:17:57 +0530 > Subject: [PATCH] [sched-clock] Extend printk to show h/w counter in a > parseable manner > > Signed-off-by: Kaiwan N Billimoria <kaiwan.billimoria@gmail.com> > --- > kernel/time/sched_clock.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c > index cc15fe293719..e4fe900d6b60 100644 > --- a/kernel/time/sched_clock.c > +++ b/kernel/time/sched_clock.c > @@ -236,16 +236,14 @@ sched_clock_register(u64 (*read)(void), int bits, unsigned long rate) > /* Calculate the ns resolution of this counter */ > res = cyc_to_ns(1ULL, new_mult, new_shift); > > - pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns, wraps every %lluns\n", > - bits, r, r_unit, res, wrap); > + pr_info("sched_clock: %pS: bits=%u,freq=%lu %cHz,resolution=%llu ns,wraps every=%llu ns,hwcnt=%llu\n", > + read, bits, r, r_unit, res, wrap, read()); > > /* Enable IRQ time accounting if we have a fast enough sched_clock() */ > if (irqtime > 0 || (irqtime == -1 && rate >= 1000000)) > enable_sched_clock_irqtime(); > > local_irq_restore(flags); > - > - pr_debug("Registered %pS as sched_clock source\n", read); > } > > void __init generic_sched_clock_init(void) > -- > 2.43.0 > > Of course, this is almost identical to what Thomas has already shown. I've > added some formatting to make for easier parsing. A sample output obtained with > this code on a patched kernel for the BeaglePlay k3 am625 board: > [ 0.000001] sched_clock: arch_counter_get_cntpct+0x0/0x18: bits=58,freq=200 MHz,resolution=5 ns,wraps every=4398046511102 ns,hwcnt=1409443611 > > This printk format allows us to easily parse it; f.e. to obtain the hwcnt value: > debian@BeagleBone:~$ dmesg |grep sched_clock |awk -F, '{print $5}' > hwcnt=1409443611 > > So, just confirming: here 1409443611 divided by 200 MHz gives us 7.047218055s > since boot, and thus the actual timestamp here is that plus 0.000001s yes? > (Over 7s here? yes, it's just that I haven't yet setup U-Boot properly for uSD > card boot, thus am manually loading commands in U-Boot to boot up, that's all). > > A question (perhaps very stupid): will the hwcnt - the output of the read() - > be guaranteed to be (close to) the number of increments since processor > power-up (or reset)? Meaning, it's simply a hardware feature and agnostic to > what code the core was executing (ROM/BL/kernel), yes? > If so, I guess we can move forward with this approach... Else, or otherwise, > suggestions are welcome, > > Regards, > Kaiwan. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2025-08-20 14:33 Christian König 2025-08-20 15:23 ` David Hildenbrand 0 siblings, 1 reply; 1767+ messages in thread From: Christian König @ 2025-08-20 14:33 UTC (permalink / raw) To: intel-xe, intel-gfx, dri-devel, amd-gfx, x86 Cc: airlied, thomas.hellstrom, matthew.brost, david, dave.hansen, luto, peterz Hi everyone, sorry for CCing so many people, but that rabbit hole turned out to be deeper than originally thought. TTM always had problems with UC/WC mappings on 32bit systems and drivers often had to revert to hacks like using GFP_DMA32 to get things working while having no rational explanation why that helped (see the TTM AGP, radeon and nouveau driver code for that). It turned out that the PAT implementation we use on x86 not only enforces the same caching attributes for pages in the linear kernel mapping, but also for highmem pages through a separate R/B tree. That was unexpected and TTM never updated that R/B tree for highmem pages, so the function pgprot_set_cachemode() just overwrote the caching attributes drivers passed in to vmf_insert_pfn_prot() and that essentially caused all kind of random trouble. An R/B tree is potentially not a good data structure to hold thousands if not millions of different attributes for each page, so updating that is probably not the way to solve this issue. Thomas pointed out that the i915 driver is using apply_page_range() instead of vmf_insert_pfn_prot() to circumvent the PAT implementation and just fill in the page tables with what the driver things is the right caching attribute. This patch set here implements this and it turns out to much *faster* than the old implementation. Together with another change on my test system mapping 1GiB of memory through TTM improved nearly by a factor of 10 (197ms -> 20ms)! Please review the general idea and/or comment on the patches. Thanks, Christian. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-08-20 14:33 Christian König @ 2025-08-20 15:23 ` David Hildenbrand 2025-08-21 8:10 ` Re: Christian König 0 siblings, 1 reply; 1767+ messages in thread From: David Hildenbrand @ 2025-08-20 15:23 UTC (permalink / raw) To: Christian König, intel-xe, intel-gfx, dri-devel, amd-gfx, x86 Cc: airlied, thomas.hellstrom, matthew.brost, dave.hansen, luto, peterz, Lorenzo Stoakes CCing Lorenzo On 20.08.25 16:33, Christian König wrote: > Hi everyone, > > sorry for CCing so many people, but that rabbit hole turned out to be > deeper than originally thought. > > TTM always had problems with UC/WC mappings on 32bit systems and drivers > often had to revert to hacks like using GFP_DMA32 to get things working > while having no rational explanation why that helped (see the TTM AGP, > radeon and nouveau driver code for that). > > It turned out that the PAT implementation we use on x86 not only enforces > the same caching attributes for pages in the linear kernel mapping, but > also for highmem pages through a separate R/B tree. > > That was unexpected and TTM never updated that R/B tree for highmem pages, > so the function pgprot_set_cachemode() just overwrote the caching > attributes drivers passed in to vmf_insert_pfn_prot() and that essentially > caused all kind of random trouble. > > An R/B tree is potentially not a good data structure to hold thousands if > not millions of different attributes for each page, so updating that is > probably not the way to solve this issue. > > Thomas pointed out that the i915 driver is using apply_page_range() > instead of vmf_insert_pfn_prot() to circumvent the PAT implementation and > just fill in the page tables with what the driver things is the right > caching attribute. I assume you mean apply_to_page_range() -- same issue in patch subjects. Oh this sounds horrible. Why oh why do we have these hacks in core-mm and have drivers abuse them :( Honestly, apply_to_pte_range() is just the entry in doing all kinds of weird crap to page tables because "you know better". All the sanity checks from vmf_insert_pfn(), gone. Can we please fix the underlying issue properly? -- Cheers David / dhildenb ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-08-20 15:23 ` David Hildenbrand @ 2025-08-21 8:10 ` Christian König 2025-08-25 19:10 ` Re: David Hildenbrand 0 siblings, 1 reply; 1767+ messages in thread From: Christian König @ 2025-08-21 8:10 UTC (permalink / raw) To: David Hildenbrand, intel-xe, intel-gfx, dri-devel, amd-gfx, x86 Cc: airlied, thomas.hellstrom, matthew.brost, dave.hansen, luto, peterz, Lorenzo Stoakes On 20.08.25 17:23, David Hildenbrand wrote: > CCing Lorenzo > > On 20.08.25 16:33, Christian König wrote: >> Hi everyone, >> >> sorry for CCing so many people, but that rabbit hole turned out to be >> deeper than originally thought. >> >> TTM always had problems with UC/WC mappings on 32bit systems and drivers >> often had to revert to hacks like using GFP_DMA32 to get things working >> while having no rational explanation why that helped (see the TTM AGP, >> radeon and nouveau driver code for that). >> >> It turned out that the PAT implementation we use on x86 not only enforces >> the same caching attributes for pages in the linear kernel mapping, but >> also for highmem pages through a separate R/B tree. >> >> That was unexpected and TTM never updated that R/B tree for highmem pages, >> so the function pgprot_set_cachemode() just overwrote the caching >> attributes drivers passed in to vmf_insert_pfn_prot() and that essentially >> caused all kind of random trouble. >> >> An R/B tree is potentially not a good data structure to hold thousands if >> not millions of different attributes for each page, so updating that is >> probably not the way to solve this issue. >> >> Thomas pointed out that the i915 driver is using apply_page_range() >> instead of vmf_insert_pfn_prot() to circumvent the PAT implementation and >> just fill in the page tables with what the driver things is the right >> caching attribute. > > I assume you mean apply_to_page_range() -- same issue in patch subjects. Oh yes, of course. Sorry. > Oh this sounds horrible. Why oh why do we have these hacks in core-mm and have drivers abuse them :( Yeah I was also a bit hesitated to use that, but the performance advantage is so high that we probably can't avoid the general approach. > Honestly, apply_to_pte_range() is just the entry in doing all kinds of weird crap to page tables because "you know better". Exactly that's the problem I'm pointing out, drivers *do* know it better. The core memory management has applied incorrect values which caused all kind of the trouble. The problem is not a bug in PAT nor TTM/drivers but rather how they interact with each other. What I don't understand is why do we have the PAT in the first place? No other architecture does it this way. Is that because of the of x86 CPUs which have problems when different page tables contain different caching attributes for the same physical memory? > All the sanity checks from vmf_insert_pfn(), gone. > > Can we please fix the underlying issue properly? I'm happy to implement anything advised, my question is what should we solve this issue? Regards, Christian. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-08-21 8:10 ` Re: Christian König @ 2025-08-25 19:10 ` David Hildenbrand 2025-08-26 8:38 ` Re: Christian König 0 siblings, 1 reply; 1767+ messages in thread From: David Hildenbrand @ 2025-08-25 19:10 UTC (permalink / raw) To: Christian König, intel-xe, intel-gfx, dri-devel, amd-gfx, x86 Cc: airlied, thomas.hellstrom, matthew.brost, dave.hansen, luto, peterz, Lorenzo Stoakes On 21.08.25 10:10, Christian König wrote: > On 20.08.25 17:23, David Hildenbrand wrote: >> CCing Lorenzo >> >> On 20.08.25 16:33, Christian König wrote: >>> Hi everyone, >>> >>> sorry for CCing so many people, but that rabbit hole turned out to be >>> deeper than originally thought. >>> >>> TTM always had problems with UC/WC mappings on 32bit systems and drivers >>> often had to revert to hacks like using GFP_DMA32 to get things working >>> while having no rational explanation why that helped (see the TTM AGP, >>> radeon and nouveau driver code for that). >>> >>> It turned out that the PAT implementation we use on x86 not only enforces >>> the same caching attributes for pages in the linear kernel mapping, but >>> also for highmem pages through a separate R/B tree. >>> >>> That was unexpected and TTM never updated that R/B tree for highmem pages, >>> so the function pgprot_set_cachemode() just overwrote the caching >>> attributes drivers passed in to vmf_insert_pfn_prot() and that essentially >>> caused all kind of random trouble. >>> >>> An R/B tree is potentially not a good data structure to hold thousands if >>> not millions of different attributes for each page, so updating that is >>> probably not the way to solve this issue. >>> >>> Thomas pointed out that the i915 driver is using apply_page_range() >>> instead of vmf_insert_pfn_prot() to circumvent the PAT implementation and >>> just fill in the page tables with what the driver things is the right >>> caching attribute. >> >> I assume you mean apply_to_page_range() -- same issue in patch subjects. > > Oh yes, of course. Sorry. > >> Oh this sounds horrible. Why oh why do we have these hacks in core-mm and have drivers abuse them :( > > Yeah I was also a bit hesitated to use that, but the performance advantage is so high that we probably can't avoid the general approach. > >> Honestly, apply_to_pte_range() is just the entry in doing all kinds of weird crap to page tables because "you know better". > > Exactly that's the problem I'm pointing out, drivers *do* know it better. The core memory management has applied incorrect values which caused all kind of the trouble. > > The problem is not a bug in PAT nor TTM/drivers but rather how they interact with each other. > > What I don't understand is why do we have the PAT in the first place? No other architecture does it this way. Probably because no other architecture has these weird glitches I assume ... skimming over memtype_reserve() and friends there are quite some corner cases the code is handling (BIOS, ACPI, low ISA, system RAM, ...) I did a lot of work on the higher PAT level functions, but I am no expert on the lower level management functions, and in particular all the special cases with different memory types. IIRC, the goal of the PAT subsystem is to make sure that no two page tables map the same PFN with different caching attributes. It treats ordinary system RAM (IORESOURCE_SYSTEM_RAM) usually in a special way: no special caching mode. For everything else, it expects that someone first reserves a memory range for a specific caching mode. For example, remap_pfn_range()...->pfnmap_track()->memtype_reserve() will make sure that there are no conflicts, to the call memtype_kernel_map_sync() to make sure the identity mapping is updated to the new type. In case someone ends up calling pfnmap_setup_cachemode(), the expectation is that there was a previous call to memtype_reserve_io() or similar, such that pfnmap_setup_cachemode() will find that caching mode. So my assumption would be that that is missing for the drivers here? Last time I asked where this reservation is done, Peter Xu explained [1] it at least for VFIO: vfio_pci_core_mmap pci_iomap pci_iomap_range ... __ioremap_caller memtype_reserve Now, could it be that something like that is missing in these drivers (ioremap etc)? [1] https://lkml.kernel.org/r/aBDXr-Qp4z0tS50P@x1.local > > Is that because of the of x86 CPUs which have problems when different page tables contain different caching attributes for the same physical memory? Yes, but I don't think x86 is special here. -- Cheers David / dhildenb ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-08-25 19:10 ` Re: David Hildenbrand @ 2025-08-26 8:38 ` Christian König 2025-08-26 8:46 ` Re: David Hildenbrand 2025-08-26 12:37 ` Re: David Hildenbrand 0 siblings, 2 replies; 1767+ messages in thread From: Christian König @ 2025-08-26 8:38 UTC (permalink / raw) To: David Hildenbrand, intel-xe, intel-gfx, dri-devel, amd-gfx, x86 Cc: airlied, thomas.hellstrom, matthew.brost, dave.hansen, luto, peterz, Lorenzo Stoakes On 25.08.25 21:10, David Hildenbrand wrote: > On 21.08.25 10:10, Christian König wrote: >> On 20.08.25 17:23, David Hildenbrand wrote: >>> CCing Lorenzo >>> >>> On 20.08.25 16:33, Christian König wrote: >>>> Hi everyone, >>>> >>>> sorry for CCing so many people, but that rabbit hole turned out to be >>>> deeper than originally thought. >>>> >>>> TTM always had problems with UC/WC mappings on 32bit systems and drivers >>>> often had to revert to hacks like using GFP_DMA32 to get things working >>>> while having no rational explanation why that helped (see the TTM AGP, >>>> radeon and nouveau driver code for that). >>>> >>>> It turned out that the PAT implementation we use on x86 not only enforces >>>> the same caching attributes for pages in the linear kernel mapping, but >>>> also for highmem pages through a separate R/B tree. >>>> >>>> That was unexpected and TTM never updated that R/B tree for highmem pages, >>>> so the function pgprot_set_cachemode() just overwrote the caching >>>> attributes drivers passed in to vmf_insert_pfn_prot() and that essentially >>>> caused all kind of random trouble. >>>> >>>> An R/B tree is potentially not a good data structure to hold thousands if >>>> not millions of different attributes for each page, so updating that is >>>> probably not the way to solve this issue. >>>> >>>> Thomas pointed out that the i915 driver is using apply_page_range() >>>> instead of vmf_insert_pfn_prot() to circumvent the PAT implementation and >>>> just fill in the page tables with what the driver things is the right >>>> caching attribute. >>> >>> I assume you mean apply_to_page_range() -- same issue in patch subjects. >> >> Oh yes, of course. Sorry. >> >>> Oh this sounds horrible. Why oh why do we have these hacks in core-mm and have drivers abuse them :( >> >> Yeah I was also a bit hesitated to use that, but the performance advantage is so high that we probably can't avoid the general approach. >> >>> Honestly, apply_to_pte_range() is just the entry in doing all kinds of weird crap to page tables because "you know better". >> >> Exactly that's the problem I'm pointing out, drivers *do* know it better. The core memory management has applied incorrect values which caused all kind of the trouble. >> >> The problem is not a bug in PAT nor TTM/drivers but rather how they interact with each other. >> >> What I don't understand is why do we have the PAT in the first place? No other architecture does it this way. > > Probably because no other architecture has these weird glitches I assume ... skimming over memtype_reserve() and friends there are quite some corner cases the code is handling (BIOS, ACPI, low ISA, system RAM, ...) > > > I did a lot of work on the higher PAT level functions, but I am no expert on the lower level management functions, and in particular all the special cases with different memory types. > > IIRC, the goal of the PAT subsystem is to make sure that no two page tables map the same PFN with different caching attributes. Yeah, that actually makes sense. Thomas from Intel recently explained the technical background to me: Some x86 CPUs write back cache lines even if they aren't dirty and what can happen is that because of the linear mapping the CPU speculatively loads a cache line which is elsewhere mapped uncached. So the end result is that the writeback of not dirty cache lines potentially corrupts the data in the otherwise uncached system memory. But that a) only applies to memory in the linear mapping and b) only to a handful of x86 CPU types (e.g. recently Intels Luna Lake, AMD Athlons produced before 2004, maybe others). > It treats ordinary system RAM (IORESOURCE_SYSTEM_RAM) usually in a special way: no special caching mode. > > For everything else, it expects that someone first reserves a memory range for a specific caching mode. > > For example, remap_pfn_range()...->pfnmap_track()->memtype_reserve() will make sure that there are no conflicts, to the call memtype_kernel_map_sync() to make sure the identity mapping is updated to the new type. > > In case someone ends up calling pfnmap_setup_cachemode(), the expectation is that there was a previous call to memtype_reserve_io() or similar, such that pfnmap_setup_cachemode() will find that caching mode. > > > So my assumption would be that that is missing for the drivers here? Well yes and no. See the PAT is optimized for applying specific caching attributes to ranges [A..B] (e.g. it uses an R/B tree). But what drivers do here is that they have single pages (usually for get_free_page or similar) and want to apply a certain caching attribute to it. So what would happen is that we completely clutter the R/B tree used by the PAT with thousands if not millions of entries. > > Last time I asked where this reservation is done, Peter Xu explained [1] it at least for VFIO: > > vfio_pci_core_mmap > pci_iomap > pci_iomap_range > ... > __ioremap_caller > memtype_reserve > > > Now, could it be that something like that is missing in these drivers (ioremap etc)? Well that would solve the issue temporary, but I'm pretty sure that will just go boom at a different place then :( One possibility would be to say that the PAT only overrides the attributes if they aren't normal cached and leaves everything else alone. What do you think? Thanks, Christian. > > > > [1] https://lkml.kernel.org/r/aBDXr-Qp4z0tS50P@x1.local > > >> >> Is that because of the of x86 CPUs which have problems when different page tables contain different caching attributes for the same physical memory? > > Yes, but I don't think x86 is special here. > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-08-26 8:38 ` Re: Christian König @ 2025-08-26 8:46 ` David Hildenbrand 2025-08-26 9:00 ` Re: Christian König 2025-08-26 12:37 ` Re: David Hildenbrand 1 sibling, 1 reply; 1767+ messages in thread From: David Hildenbrand @ 2025-08-26 8:46 UTC (permalink / raw) To: Christian König, intel-xe, intel-gfx, dri-devel, amd-gfx, x86 Cc: airlied, thomas.hellstrom, matthew.brost, dave.hansen, luto, peterz, Lorenzo Stoakes On 26.08.25 10:38, Christian König wrote: > On 25.08.25 21:10, David Hildenbrand wrote: >> On 21.08.25 10:10, Christian König wrote: >>> On 20.08.25 17:23, David Hildenbrand wrote: >>>> CCing Lorenzo >>>> >>>> On 20.08.25 16:33, Christian König wrote: >>>>> Hi everyone, >>>>> >>>>> sorry for CCing so many people, but that rabbit hole turned out to be >>>>> deeper than originally thought. >>>>> >>>>> TTM always had problems with UC/WC mappings on 32bit systems and drivers >>>>> often had to revert to hacks like using GFP_DMA32 to get things working >>>>> while having no rational explanation why that helped (see the TTM AGP, >>>>> radeon and nouveau driver code for that). >>>>> >>>>> It turned out that the PAT implementation we use on x86 not only enforces >>>>> the same caching attributes for pages in the linear kernel mapping, but >>>>> also for highmem pages through a separate R/B tree. >>>>> >>>>> That was unexpected and TTM never updated that R/B tree for highmem pages, >>>>> so the function pgprot_set_cachemode() just overwrote the caching >>>>> attributes drivers passed in to vmf_insert_pfn_prot() and that essentially >>>>> caused all kind of random trouble. >>>>> >>>>> An R/B tree is potentially not a good data structure to hold thousands if >>>>> not millions of different attributes for each page, so updating that is >>>>> probably not the way to solve this issue. >>>>> >>>>> Thomas pointed out that the i915 driver is using apply_page_range() >>>>> instead of vmf_insert_pfn_prot() to circumvent the PAT implementation and >>>>> just fill in the page tables with what the driver things is the right >>>>> caching attribute. >>>> >>>> I assume you mean apply_to_page_range() -- same issue in patch subjects. >>> >>> Oh yes, of course. Sorry. >>> >>>> Oh this sounds horrible. Why oh why do we have these hacks in core-mm and have drivers abuse them :( >>> >>> Yeah I was also a bit hesitated to use that, but the performance advantage is so high that we probably can't avoid the general approach. >>> >>>> Honestly, apply_to_pte_range() is just the entry in doing all kinds of weird crap to page tables because "you know better". >>> >>> Exactly that's the problem I'm pointing out, drivers *do* know it better. The core memory management has applied incorrect values which caused all kind of the trouble. >>> >>> The problem is not a bug in PAT nor TTM/drivers but rather how they interact with each other. >>> >>> What I don't understand is why do we have the PAT in the first place? No other architecture does it this way. >> >> Probably because no other architecture has these weird glitches I assume ... skimming over memtype_reserve() and friends there are quite some corner cases the code is handling (BIOS, ACPI, low ISA, system RAM, ...) >> >> >> I did a lot of work on the higher PAT level functions, but I am no expert on the lower level management functions, and in particular all the special cases with different memory types. >> >> IIRC, the goal of the PAT subsystem is to make sure that no two page tables map the same PFN with different caching attributes. > > Yeah, that actually makes sense. Thomas from Intel recently explained the technical background to me: > > Some x86 CPUs write back cache lines even if they aren't dirty and what can happen is that because of the linear mapping the CPU speculatively loads a cache line which is elsewhere mapped uncached. > > So the end result is that the writeback of not dirty cache lines potentially corrupts the data in the otherwise uncached system memory. > > But that a) only applies to memory in the linear mapping and b) only to a handful of x86 CPU types (e.g. recently Intels Luna Lake, AMD Athlons produced before 2004, maybe others). > >> It treats ordinary system RAM (IORESOURCE_SYSTEM_RAM) usually in a special way: no special caching mode. >> >> For everything else, it expects that someone first reserves a memory range for a specific caching mode. >> >> For example, remap_pfn_range()...->pfnmap_track()->memtype_reserve() will make sure that there are no conflicts, to the call memtype_kernel_map_sync() to make sure the identity mapping is updated to the new type. >> >> In case someone ends up calling pfnmap_setup_cachemode(), the expectation is that there was a previous call to memtype_reserve_io() or similar, such that pfnmap_setup_cachemode() will find that caching mode. >> >> >> So my assumption would be that that is missing for the drivers here? > > Well yes and no. > > See the PAT is optimized for applying specific caching attributes to ranges [A..B] (e.g. it uses an R/B tree). But what drivers do here is that they have single pages (usually for get_free_page or similar) and want to apply a certain caching attribute to it. > > So what would happen is that we completely clutter the R/B tree used by the PAT with thousands if not millions of entries. > Hm, above you're saying that there is no direct map, but now you are saying that the pages were obtained through get_free_page()? I agree that what you describe here sounds suboptimal. But if the pages where obtained from the buddy, there surely is a direct map -- unless we explicitly remove it :( If we're talking about individual pages without a directmap, I would wonder if they are actually part of a bigger memory region that can just be reserved in one go (similar to how remap_pfn_range()) would handle it. Can you briefly describe how your use case obtains these PFNs, and how scattered tehy + their caching attributes might be? -- Cheers David / dhildenb ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-08-26 8:46 ` Re: David Hildenbrand @ 2025-08-26 9:00 ` Christian König 2025-08-26 9:17 ` Re: David Hildenbrand 0 siblings, 1 reply; 1767+ messages in thread From: Christian König @ 2025-08-26 9:00 UTC (permalink / raw) To: David Hildenbrand, intel-xe, intel-gfx, dri-devel, amd-gfx, x86 Cc: airlied, thomas.hellstrom, matthew.brost, dave.hansen, luto, peterz, Lorenzo Stoakes On 26.08.25 10:46, David Hildenbrand wrote: >>> So my assumption would be that that is missing for the drivers here? >> >> Well yes and no. >> >> See the PAT is optimized for applying specific caching attributes to ranges [A..B] (e.g. it uses an R/B tree). But what drivers do here is that they have single pages (usually for get_free_page or similar) and want to apply a certain caching attribute to it. >> >> So what would happen is that we completely clutter the R/B tree used by the PAT with thousands if not millions of entries. >> > > Hm, above you're saying that there is no direct map, but now you are saying that the pages were obtained through get_free_page()? The problem only happens with highmem pages on 32bit kernels. Those pages are not in the linear mapping. > I agree that what you describe here sounds suboptimal. But if the pages where obtained from the buddy, there surely is a direct map -- unless we explicitly remove it :( > > If we're talking about individual pages without a directmap, I would wonder if they are actually part of a bigger memory region that can just be reserved in one go (similar to how remap_pfn_range()) would handle it. > > Can you briefly describe how your use case obtains these PFNs, and how scattered tehy + their caching attributes might be? What drivers do is to call get_free_page() or alloc_pages_node() with the GFP_HIGHUSER flag set. For non highmem pages drivers then calls set_pages_wc/uc() which changes the caching of the linear mapping, but for highmem pages there is no linear mapping so set_pages_wc() or set_pages_uc() doesn't work and drivers avoid calling it. Those are basically just random system memory pages. So they are potentially scattered over the whole memory address space. Regards, Christian. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-08-26 9:00 ` Re: Christian König @ 2025-08-26 9:17 ` David Hildenbrand 2025-08-26 9:56 ` Re: Christian König 0 siblings, 1 reply; 1767+ messages in thread From: David Hildenbrand @ 2025-08-26 9:17 UTC (permalink / raw) To: Christian König, intel-xe, intel-gfx, dri-devel, amd-gfx, x86 Cc: airlied, thomas.hellstrom, matthew.brost, dave.hansen, luto, peterz, Lorenzo Stoakes On 26.08.25 11:00, Christian König wrote: > On 26.08.25 10:46, David Hildenbrand wrote: >>>> So my assumption would be that that is missing for the drivers here? >>> >>> Well yes and no. >>> >>> See the PAT is optimized for applying specific caching attributes to ranges [A..B] (e.g. it uses an R/B tree). But what drivers do here is that they have single pages (usually for get_free_page or similar) and want to apply a certain caching attribute to it. >>> >>> So what would happen is that we completely clutter the R/B tree used by the PAT with thousands if not millions of entries. >>> >> >> Hm, above you're saying that there is no direct map, but now you are saying that the pages were obtained through get_free_page()? > > The problem only happens with highmem pages on 32bit kernels. Those pages are not in the linear mapping. Right, in the common case there is a direct map. > >> I agree that what you describe here sounds suboptimal. But if the pages where obtained from the buddy, there surely is a direct map -- unless we explicitly remove it :( >> >> If we're talking about individual pages without a directmap, I would wonder if they are actually part of a bigger memory region that can just be reserved in one go (similar to how remap_pfn_range()) would handle it. >> >> Can you briefly describe how your use case obtains these PFNs, and how scattered tehy + their caching attributes might be? > > What drivers do is to call get_free_page() or alloc_pages_node() with the GFP_HIGHUSER flag set. > > For non highmem pages drivers then calls set_pages_wc/uc() which changes the caching of the linear mapping, but for highmem pages there is no linear mapping so set_pages_wc() or set_pages_uc() doesn't work and drivers avoid calling it. > > Those are basically just random system memory pages. So they are potentially scattered over the whole memory address space. Thanks, that's valuable information. So essentially these drivers maintain their own consistency and PAT is not aware of that. And the real problem is ordinary system RAM. There are various ways forward. 1) We use another interface that consumes pages instead of PFNs, like a vm_insert_pages_pgprot() we would be adding. Is there any strong requirement for inserting non-refcounted PFNs? 2) We add another interface that consumes PFNs, but explicitly states that it is only for ordinary system RAM, and that the user is required for updating the direct map. We could sanity-check the direct map in debug kernels. 3) We teach PAT code in pfnmap_setup_cachemode_pfn() about treating this system RAM differently. There is also the option for a mixture between 1 and 2, where we get pages, but we map them non-refcounted in a VM_PFNMAP. In general, having pages makes it easier to assert that they are likely ordinary system ram pages, and that the interface is not getting abused for something else. We could also perform the set_pages_wc/uc() from inside that function, but maybe it depends on the use case whether we want to do that whenever we map them into a process? -- Cheers David / dhildenb ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-08-26 9:17 ` Re: David Hildenbrand @ 2025-08-26 9:56 ` Christian König 2025-08-26 12:07 ` Re: David Hildenbrand 2025-08-26 14:27 ` Re: Thomas Hellström 0 siblings, 2 replies; 1767+ messages in thread From: Christian König @ 2025-08-26 9:56 UTC (permalink / raw) To: David Hildenbrand, intel-xe, intel-gfx, dri-devel, amd-gfx, x86 Cc: airlied, thomas.hellstrom, matthew.brost, dave.hansen, luto, peterz, Lorenzo Stoakes On 26.08.25 11:17, David Hildenbrand wrote: > On 26.08.25 11:00, Christian König wrote: >> On 26.08.25 10:46, David Hildenbrand wrote: >>>>> So my assumption would be that that is missing for the drivers here? >>>> >>>> Well yes and no. >>>> >>>> See the PAT is optimized for applying specific caching attributes to ranges [A..B] (e.g. it uses an R/B tree). But what drivers do here is that they have single pages (usually for get_free_page or similar) and want to apply a certain caching attribute to it. >>>> >>>> So what would happen is that we completely clutter the R/B tree used by the PAT with thousands if not millions of entries. >>>> >>> >>> Hm, above you're saying that there is no direct map, but now you are saying that the pages were obtained through get_free_page()? >> >> The problem only happens with highmem pages on 32bit kernels. Those pages are not in the linear mapping. > > Right, in the common case there is a direct map. > >> >>> I agree that what you describe here sounds suboptimal. But if the pages where obtained from the buddy, there surely is a direct map -- unless we explicitly remove it :( >>> >>> If we're talking about individual pages without a directmap, I would wonder if they are actually part of a bigger memory region that can just be reserved in one go (similar to how remap_pfn_range()) would handle it. >>> >>> Can you briefly describe how your use case obtains these PFNs, and how scattered tehy + their caching attributes might be? >> >> What drivers do is to call get_free_page() or alloc_pages_node() with the GFP_HIGHUSER flag set. >> >> For non highmem pages drivers then calls set_pages_wc/uc() which changes the caching of the linear mapping, but for highmem pages there is no linear mapping so set_pages_wc() or set_pages_uc() doesn't work and drivers avoid calling it. >> >> Those are basically just random system memory pages. So they are potentially scattered over the whole memory address space. > > Thanks, that's valuable information. > > So essentially these drivers maintain their own consistency and PAT is not aware of that. > > And the real problem is ordinary system RAM. > > There are various ways forward. > > 1) We use another interface that consumes pages instead of PFNs, like a > vm_insert_pages_pgprot() we would be adding. > > Is there any strong requirement for inserting non-refcounted PFNs? Yes, there is a strong requirement to insert non-refcounted PFNs. We had a lot of trouble with KVM people trying to grab a reference to those pages even if the VMA had the VM_PFNMAP flag set. > 2) We add another interface that consumes PFNs, but explicitly states > that it is only for ordinary system RAM, and that the user is > required for updating the direct map. > > We could sanity-check the direct map in debug kernels. I would rather like to see vmf_insert_pfn_prot() fixed instead. That function was explicitly added to insert the PFN with the given attributes and as far as I can see all users of that function expect exactly that. > > 3) We teach PAT code in pfnmap_setup_cachemode_pfn() about treating this > system RAM differently. > > > There is also the option for a mixture between 1 and 2, where we get pages, but we map them non-refcounted in a VM_PFNMAP. > > In general, having pages makes it easier to assert that they are likely ordinary system ram pages, and that the interface is not getting abused for something else. Well, exactly that's the use case here and that is not abusive at all as far as I can see. What drivers want is to insert a PFN with a certain set of caching attributes regardless if it's system memory or iomem. That's why vmf_insert_pfn_prot() was created in the first place. That drivers need to call set_pages_wc/uc() for the linear mapping on x86 manually is correct and checking that is clearly a good idea for debug kernels. > We could also perform the set_pages_wc/uc() from inside that function, but maybe it depends on the use case whether we want to do that whenever we map them into a process? It sounds like a good idea in theory, but I think it is potentially to much overhead to be applicable. Thanks, Christian. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-08-26 9:56 ` Re: Christian König @ 2025-08-26 12:07 ` David Hildenbrand 2025-08-26 16:09 ` Re: Christian König 2025-08-26 14:27 ` Re: Thomas Hellström 1 sibling, 1 reply; 1767+ messages in thread From: David Hildenbrand @ 2025-08-26 12:07 UTC (permalink / raw) To: Christian König, intel-xe, intel-gfx, dri-devel, amd-gfx, x86 Cc: airlied, thomas.hellstrom, matthew.brost, dave.hansen, luto, peterz, Lorenzo Stoakes >> >> 1) We use another interface that consumes pages instead of PFNs, like a >> vm_insert_pages_pgprot() we would be adding. >> >> Is there any strong requirement for inserting non-refcounted PFNs? > > Yes, there is a strong requirement to insert non-refcounted PFNs. > > We had a lot of trouble with KVM people trying to grab a reference to those pages even if the VMA had the VM_PFNMAP flag set. Yes, KVM ignored (and maybe still does) VM_PFNMAP to some degree, which is rather nasty. > >> 2) We add another interface that consumes PFNs, but explicitly states >> that it is only for ordinary system RAM, and that the user is >> required for updating the direct map. >> >> We could sanity-check the direct map in debug kernels. > > I would rather like to see vmf_insert_pfn_prot() fixed instead. > > That function was explicitly added to insert the PFN with the given attributes and as far as I can see all users of that function expect exactly that. It's all a bit tricky :( > >> >> 3) We teach PAT code in pfnmap_setup_cachemode_pfn() about treating this >> system RAM differently. >> >> >> There is also the option for a mixture between 1 and 2, where we get pages, but we map them non-refcounted in a VM_PFNMAP. >> >> In general, having pages makes it easier to assert that they are likely ordinary system ram pages, and that the interface is not getting abused for something else. > > Well, exactly that's the use case here and that is not abusive at all as far as I can see. > > What drivers want is to insert a PFN with a certain set of caching attributes regardless if it's system memory or iomem. That's why vmf_insert_pfn_prot() was created in the first place. I mean, the use case of "allocate pages from the buddy and fixup the linear map" sounds perfectly reasonable to me. Absolutely no reason to get PAT involved. Nobody else should be messing with that memory after all. As soon as we are talking about other memory ranges (iomem) that are not from the buddy, it gets weird to bypass PAT, and the question I am asking myself is, when is it okay, and when not. > > That drivers need to call set_pages_wc/uc() for the linear mapping on x86 manually is correct and checking that is clearly a good idea for debug kernels. I'll have to think about this a bit: assuming only vmf_insert_pfn() calls pfnmap_setup_cachemode_pfn() but vmf_insert_pfn_prot() doesn't, how could we sanity check that somebody is doing something against the will of PAT. -- Cheers David / dhildenb ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-08-26 12:07 ` Re: David Hildenbrand @ 2025-08-26 16:09 ` Christian König 0 siblings, 0 replies; 1767+ messages in thread From: Christian König @ 2025-08-26 16:09 UTC (permalink / raw) To: David Hildenbrand, intel-xe, intel-gfx, dri-devel, amd-gfx, x86 Cc: airlied, thomas.hellstrom, matthew.brost, dave.hansen, luto, peterz, Lorenzo Stoakes On 26.08.25 14:07, David Hildenbrand wrote: >> >>> 2) We add another interface that consumes PFNs, but explicitly states >>> that it is only for ordinary system RAM, and that the user is >>> required for updating the direct map. >>> >>> We could sanity-check the direct map in debug kernels. >> >> I would rather like to see vmf_insert_pfn_prot() fixed instead. >> >> That function was explicitly added to insert the PFN with the given attributes and as far as I can see all users of that function expect exactly that. > > It's all a bit tricky :( I would rather say horrible complicated :( >>> >>> 3) We teach PAT code in pfnmap_setup_cachemode_pfn() about treating this >>> system RAM differently. >>> >>> >>> There is also the option for a mixture between 1 and 2, where we get pages, but we map them non-refcounted in a VM_PFNMAP. >>> >>> In general, having pages makes it easier to assert that they are likely ordinary system ram pages, and that the interface is not getting abused for something else. >> >> Well, exactly that's the use case here and that is not abusive at all as far as I can see. >> >> What drivers want is to insert a PFN with a certain set of caching attributes regardless if it's system memory or iomem. That's why vmf_insert_pfn_prot() was created in the first place. > > I mean, the use case of "allocate pages from the buddy and fixup the linear map" sounds perfectly reasonable to me. Absolutely no reason to get PAT involved. Nobody else should be messing with that memory after all. > > As soon as we are talking about other memory ranges (iomem) that are not from the buddy, it gets weird to bypass PAT, and the question I am asking myself is, when is it okay, and when not. Ok let me try to explain parts of the history and the big picture for at least the graphics use case on x86. In 1996/97 Intel came up with the idea of AGP: https://en.wikipedia.org/wiki/Accelerated_Graphics_Port At that time the CPUs, PCI bus and system memory were all connected together through the north bridge: https://en.wikipedia.org/wiki/Northbridge_(computing) The problem was that AGP also introduced the concept of putting large amounts of data for the video controller (PCI device) into system memory when you don't have enough local device memory (VRAM). But that meant when that memory is cached that the north bridge always had to snoop the CPU cache over the front side bus for every access the video controller made. This meant a huge performance bottleneck, so the idea was born to access that data uncached. Well that was nearly 30years ago, PCI, AGP and front side bus are long gone, but the concept of putting video controller (GPU) stuff into uncached system memory has prevailed. So for example even modern AMD CPU based laptops need uncached system memory if their local memory is not large enough to contain the picture to display on the monitor. And with modern 8k monitors that can actually happen quite fast... What drivers do today is to call vmf_insert_pfn_prot() either with the PFN of their local memory (iomem) or uncached/wc system memory. To summarize that we have an interface to fill in the page tables with either iomem or system memory is actually part of the design. That's how the HW driver is expected to work. >> That drivers need to call set_pages_wc/uc() for the linear mapping on x86 manually is correct and checking that is clearly a good idea for debug kernels. > > I'll have to think about this a bit: assuming only vmf_insert_pfn() calls pfnmap_setup_cachemode_pfn() but vmf_insert_pfn_prot() doesn't, how could we sanity check that somebody is doing something against the will of PAT. I think the most defensive approach for a quick fix is this change here: static inline void pgprot_set_cachemode(pgprot_t *prot, enum page_cache_mode pcm) { - *prot = __pgprot((pgprot_val(*prot) & ~_PAGE_CACHE_MASK) | - cachemode2protval(pcm)); + if (pcm != _PAGE_CACHE_MODE_WB) + *prot = __pgprot((pgprot_val(*prot) & ~_PAGE_CACHE_MASK) | + cachemode2protval(pcm)); } This applies the PAT value if it's anything else than _PAGE_CACHE_MODE_WB but still allows callers to use something different on normal WB system memory. What do you think? Regards, Christian ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-08-26 9:56 ` Re: Christian König 2025-08-26 12:07 ` Re: David Hildenbrand @ 2025-08-26 14:27 ` Thomas Hellström 1 sibling, 0 replies; 1767+ messages in thread From: Thomas Hellström @ 2025-08-26 14:27 UTC (permalink / raw) To: Christian König, David Hildenbrand, intel-xe, intel-gfx, dri-devel, amd-gfx, x86 Cc: airlied, matthew.brost, dave.hansen, luto, peterz, Lorenzo Stoakes Hi, Christian, On Tue, 2025-08-26 at 11:56 +0200, Christian König wrote: > On 26.08.25 11:17, David Hildenbrand wrote: > > On 26.08.25 11:00, Christian König wrote: > > > On 26.08.25 10:46, David Hildenbrand wrote: > > > > > > So my assumption would be that that is missing for the > > > > > > drivers here? > > > > > > > > > > Well yes and no. > > > > > > > > > > See the PAT is optimized for applying specific caching > > > > > attributes to ranges [A..B] (e.g. it uses an R/B tree). But > > > > > what drivers do here is that they have single pages (usually > > > > > for get_free_page or similar) and want to apply a certain > > > > > caching attribute to it. > > > > > > > > > > So what would happen is that we completely clutter the R/B > > > > > tree used by the PAT with thousands if not millions of > > > > > entries. > > > > > > > > > > > > > Hm, above you're saying that there is no direct map, but now > > > > you are saying that the pages were obtained through > > > > get_free_page()? > > > > > > The problem only happens with highmem pages on 32bit kernels. > > > Those pages are not in the linear mapping. > > > > Right, in the common case there is a direct map. > > > > > > > > > I agree that what you describe here sounds suboptimal. But if > > > > the pages where obtained from the buddy, there surely is a > > > > direct map -- unless we explicitly remove it :( > > > > > > > > If we're talking about individual pages without a directmap, I > > > > would wonder if they are actually part of a bigger memory > > > > region that can just be reserved in one go (similar to how > > > > remap_pfn_range()) would handle it. > > > > > > > > Can you briefly describe how your use case obtains these PFNs, > > > > and how scattered tehy + their caching attributes might be? > > > > > > What drivers do is to call get_free_page() or alloc_pages_node() > > > with the GFP_HIGHUSER flag set. > > > > > > For non highmem pages drivers then calls set_pages_wc/uc() which > > > changes the caching of the linear mapping, but for highmem pages > > > there is no linear mapping so set_pages_wc() or set_pages_uc() > > > doesn't work and drivers avoid calling it. > > > > > > Those are basically just random system memory pages. So they are > > > potentially scattered over the whole memory address space. > > > > Thanks, that's valuable information. > > > > So essentially these drivers maintain their own consistency and PAT > > is not aware of that. > > > > And the real problem is ordinary system RAM. > > > > There are various ways forward. > > > > 1) We use another interface that consumes pages instead of PFNs, > > like a > > vm_insert_pages_pgprot() we would be adding. > > > > Is there any strong requirement for inserting non-refcounted > > PFNs? > > Yes, there is a strong requirement to insert non-refcounted PFNs. > > We had a lot of trouble with KVM people trying to grab a reference to > those pages even if the VMA had the VM_PFNMAP flag set. > > > 2) We add another interface that consumes PFNs, but explicitly > > states > > that it is only for ordinary system RAM, and that the user is > > required for updating the direct map. > > > > We could sanity-check the direct map in debug kernels. > > I would rather like to see vmf_insert_pfn_prot() fixed instead. > > That function was explicitly added to insert the PFN with the given > attributes and as far as I can see all users of that function expect > exactly that. > > > > > 3) We teach PAT code in pfnmap_setup_cachemode_pfn() about treating > > this > > system RAM differently. > > > > > > There is also the option for a mixture between 1 and 2, where we > > get pages, but we map them non-refcounted in a VM_PFNMAP. > > > > In general, having pages makes it easier to assert that they are > > likely ordinary system ram pages, and that the interface is not > > getting abused for something else. > > Well, exactly that's the use case here and that is not abusive at all > as far as I can see. > > What drivers want is to insert a PFN with a certain set of caching > attributes regardless if it's system memory or iomem. That's why > vmf_insert_pfn_prot() was created in the first place. > > That drivers need to call set_pages_wc/uc() for the linear mapping on > x86 manually is correct and checking that is clearly a good idea for > debug kernels. So where is this trending? Is the current suggestion to continue disallowing aliased mappings with conflicting caching modes and enforce checks in debug kernels? /Thomas > > > We could also perform the set_pages_wc/uc() from inside that > > function, but maybe it depends on the use case whether we want to > > do that whenever we map them into a process? > > It sounds like a good idea in theory, but I think it is potentially > to much overhead to be applicable. > > Thanks, > Christian. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-08-26 8:38 ` Re: Christian König 2025-08-26 8:46 ` Re: David Hildenbrand @ 2025-08-26 12:37 ` David Hildenbrand 1 sibling, 0 replies; 1767+ messages in thread From: David Hildenbrand @ 2025-08-26 12:37 UTC (permalink / raw) To: Christian König, intel-xe, intel-gfx, dri-devel, amd-gfx, x86 Cc: airlied, thomas.hellstrom, matthew.brost, dave.hansen, luto, peterz, Lorenzo Stoakes On 26.08.25 10:38, Christian König wrote: > On 25.08.25 21:10, David Hildenbrand wrote: >> On 21.08.25 10:10, Christian König wrote: >>> On 20.08.25 17:23, David Hildenbrand wrote: >>>> CCing Lorenzo >>>> >>>> On 20.08.25 16:33, Christian König wrote: >>>>> Hi everyone, >>>>> >>>>> sorry for CCing so many people, but that rabbit hole turned out to be >>>>> deeper than originally thought. >>>>> >>>>> TTM always had problems with UC/WC mappings on 32bit systems and drivers >>>>> often had to revert to hacks like using GFP_DMA32 to get things working >>>>> while having no rational explanation why that helped (see the TTM AGP, >>>>> radeon and nouveau driver code for that). >>>>> >>>>> It turned out that the PAT implementation we use on x86 not only enforces >>>>> the same caching attributes for pages in the linear kernel mapping, but >>>>> also for highmem pages through a separate R/B tree. >>>>> >>>>> That was unexpected and TTM never updated that R/B tree for highmem pages, >>>>> so the function pgprot_set_cachemode() just overwrote the caching >>>>> attributes drivers passed in to vmf_insert_pfn_prot() and that essentially >>>>> caused all kind of random trouble. >>>>> >>>>> An R/B tree is potentially not a good data structure to hold thousands if >>>>> not millions of different attributes for each page, so updating that is >>>>> probably not the way to solve this issue. >>>>> >>>>> Thomas pointed out that the i915 driver is using apply_page_range() >>>>> instead of vmf_insert_pfn_prot() to circumvent the PAT implementation and >>>>> just fill in the page tables with what the driver things is the right >>>>> caching attribute. >>>> >>>> I assume you mean apply_to_page_range() -- same issue in patch subjects. >>> >>> Oh yes, of course. Sorry. >>> >>>> Oh this sounds horrible. Why oh why do we have these hacks in core-mm and have drivers abuse them :( >>> >>> Yeah I was also a bit hesitated to use that, but the performance advantage is so high that we probably can't avoid the general approach. >>> >>>> Honestly, apply_to_pte_range() is just the entry in doing all kinds of weird crap to page tables because "you know better". >>> >>> Exactly that's the problem I'm pointing out, drivers *do* know it better. The core memory management has applied incorrect values which caused all kind of the trouble. >>> >>> The problem is not a bug in PAT nor TTM/drivers but rather how they interact with each other. >>> >>> What I don't understand is why do we have the PAT in the first place? No other architecture does it this way. >> >> Probably because no other architecture has these weird glitches I assume ... skimming over memtype_reserve() and friends there are quite some corner cases the code is handling (BIOS, ACPI, low ISA, system RAM, ...) >> >> >> I did a lot of work on the higher PAT level functions, but I am no expert on the lower level management functions, and in particular all the special cases with different memory types. >> >> IIRC, the goal of the PAT subsystem is to make sure that no two page tables map the same PFN with different caching attributes. > > Yeah, that actually makes sense. Thomas from Intel recently explained the technical background to me: > > Some x86 CPUs write back cache lines even if they aren't dirty and what can happen is that because of the linear mapping the CPU speculatively loads a cache line which is elsewhere mapped uncached. > > So the end result is that the writeback of not dirty cache lines potentially corrupts the data in the otherwise uncached system memory. > > But that a) only applies to memory in the linear mapping and b) only to a handful of x86 CPU types (e.g. recently Intels Luna Lake, AMD Athlons produced before 2004, maybe others). > >> It treats ordinary system RAM (IORESOURCE_SYSTEM_RAM) usually in a special way: no special caching mode. >> >> For everything else, it expects that someone first reserves a memory range for a specific caching mode. >> >> For example, remap_pfn_range()...->pfnmap_track()->memtype_reserve() will make sure that there are no conflicts, to the call memtype_kernel_map_sync() to make sure the identity mapping is updated to the new type. >> >> In case someone ends up calling pfnmap_setup_cachemode(), the expectation is that there was a previous call to memtype_reserve_io() or similar, such that pfnmap_setup_cachemode() will find that caching mode. >> >> >> So my assumption would be that that is missing for the drivers here? > > Well yes and no. > > See the PAT is optimized for applying specific caching attributes to ranges [A..B] (e.g. it uses an R/B tree). But what drivers do here is that they have single pages (usually for get_free_page or similar) and want to apply a certain caching attribute to it. One clarification after staring at PAT code once again: for pages (RAM), the caching attribute is stored in the page flags, not in the R/B tree. If nothing was set, it defaults to _PAGE_CACHE_MODE_WB AFAIKs. -- Cheers David / dhildenb ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH] documentation/arm64 : kdump fixed typo errors
@ 2025-08-18 16:08 Jonathan Corbet
2025-09-08 9:54 ` hariconscious
0 siblings, 1 reply; 1767+ messages in thread
From: Jonathan Corbet @ 2025-08-18 16:08 UTC (permalink / raw)
To: hariconscious, shuah, catalin.marinas, will, linux-arm-kernel,
linux-doc, linux-kernel
Cc: HariKrishna
hariconscious@gmail.com writes:
> From: HariKrishna <hariconscious@gmail.com>
>
> kdump.rst documentation typos corrected
>
> Signed-off-by: HariKrishna <hariconscious@gmail.com>
> ---
> Documentation/arch/arm64/kdump.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/arch/arm64/kdump.rst b/Documentation/arch/arm64/kdump.rst
> index 56a89f45df28..d3195a93a066 100644
> --- a/Documentation/arch/arm64/kdump.rst
> +++ b/Documentation/arch/arm64/kdump.rst
> @@ -5,7 +5,7 @@ crashkernel memory reservation on arm64
> Author: Baoquan He <bhe@redhat.com>
>
> Kdump mechanism is used to capture a corrupted kernel vmcore so that
> -it can be subsequently analyzed. In order to do this, a preliminarily
> +it can be subsequently analyzed. In order to do this, a preliminary
> reserved memory is needed to pre-load the kdump kernel and boot such
> kernel if corruption happens.
I don't think this is right. While reserving judgment on
"preliminarily" as a word, the intended use is adverbial, so this change
does not make things better. The better fix, perhaps, is to say
"previously" instead.
Should you choose to resubmit this, we'll need your real name in the
Signed-off-by tag, please.
Thanks,
jon
^ permalink raw reply [flat|nested] 1767+ messages in thread* (no subject) 2025-08-18 16:08 [PATCH] documentation/arm64 : kdump fixed typo errors Jonathan Corbet @ 2025-09-08 9:54 ` hariconscious 2025-09-08 13:23 ` Jonathan Corbet 0 siblings, 1 reply; 1767+ messages in thread From: hariconscious @ 2025-09-08 9:54 UTC (permalink / raw) To: corbet Cc: catalin.marinas, hariconscious, linux-arm-kernel, linux-doc, linux-kernel, shuah, will m mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ms.lwn.net (ms.lwn.net [45.79.88.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 286623770B; Mon, 18 Aug 2025 16:08:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.79.88.28 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755533304; cv=none; b=uzqxObiUW0V5/KwDbGE974y+FjJSI5MFNyebWi2+5q0TOrcLDMz7UaGA7zz0rM3Untp7AnczUbPlO0EA7ijp4VWjKvA/jRHEa1WGY2xCRbl7sgaCW2Jjds9q0+1gZLf0j/daCCEppHrPUjZ8YflPc2iu9lSvMSpKu47NIakpBUE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755533304; c=relaxed/simple; bh=ou2NodSL61SjBBx3oNoEL8d9FXu/qhf54SYinlYpEpw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=ZgMDNRzIMf6C1EvsD5ClxxovJPOa43e4oQ6VSmdSN6I7NCnbnvwlTuhLwbC7PoGla8+5kqNNoHprCsJFKlmaUz88nO4IC+USEYcRtm/2Bcyxy5Vkovozj6Qt8dT+KI2+uNMueCPw97mRWW184W5bNT6MZmCp0bCVjUVZaMhgFsI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lwn.net; spf=pass smtp.mailfrom=lwn.net; dkim=pass (2048-bit key) header.d=lwn.net header.i=@lwn.net header.b=FS1soXLa; arc=none smtp.client-ip=45.79.88.28 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lwn.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lwn.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lwn.net header.i=@lwn.net header.b="FS1soXLa" DKIM-Filter: OpenDKIM Filter v2.11.0 ms.lwn.net 5CE0F40AB4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lwn.net; s=20201203; t=1755533302; bh=PgKB2qnc/bRPAL5RwjdygVePDYnntw4ZWdIavREWLBQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=FS1soXLa521ujJUbl/402whSSESTHg9tMk1J4yJXD61Dfi279n3ZYdXUxCAqBrXbP 7uzuyvggLkYoXlerUj63roxK9vLzAUnVybiJ8ADgblvGi5LkC02Rne6uNwELG05I+6 k7OuwJQBxt+73WjptP+fON5qK+HI/wyJ2vePn9MgKDmwsi+JYLLCa/Ou+Yk0IU287M 3Bs39RXJcFhH8aA2anPFcTcN3lReE6Ci8Tc22FjnWBpnYKR6l1Y7r40THAF4d2OISs tpNV3csYjY/jWhXXQNvQZbmv84TtmdKAC3lrG0p2OxW0RInDuM1q8EFkKH6kheFgli bhQXe4L9M8KpA== Received: from localhost (unknown [IPv6:2601:280:4600:2da9::1fe]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id 5CE0F40AB4; Mon, 18 Aug 2025 16:08:22 +0000 (UTC) From: Jonathan Corbet <corbet@lwn.net> To: hariconscious@gmail.com, shuah@kernel.org, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Cc: HariKrishna <hariconscious@gmail.com> Subject: Re: [PATCH] documentation/arm64 : kdump fixed typo errors In-Reply-To: <20250816120731.24508-1-hariconscious@gmail.com> References: <20250816120731.24508-1-hariconscious@gmail.com> Date: Mon, 18 Aug 2025 10:08:21 -0600 Message-ID: <871pp8a9ze.fsf@trenco.lwn.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain hariconscious@gmail.com writes: > From: HariKrishna <hariconscious@gmail.com> > > kdump.rst documentation typos corrected > > Signed-off-by: HariKrishna <hariconscious@gmail.com> > --- > Documentation/arch/arm64/kdump.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/arch/arm64/kdump.rst b/Documentation/arch/arm64/kdump.rst > index 56a89f45df28..d3195a93a066 100644 > --- a/Documentation/arch/arm64/kdump.rst > +++ b/Documentation/arch/arm64/kdump.rst > @@ -5,7 +5,7 @@ crashkernel memory reservation on arm64 > Author: Baoquan He <bhe@redhat.com> > > Kdump mechanism is used to capture a corrupted kernel vmcore so that > -it can be subsequently analyzed. In order to do this, a preliminarily > +it can be subsequently analyzed. In order to do this, a preliminary > reserved memory is needed to pre-load the kdump kernel and boot such > kernel if corruption happens. I don't think this is right. While reserving judgment on "preliminarily" as a word, the intended use is adverbial, so this change does not make things better. The better fix, perhaps, is to say "previously" instead. Should you choose to resubmit this, we'll need your real name in the Signed-off-by tag, please. Thanks, jon Hi Jon, Good day. Thanks for the suggestion, will correct and send the patch again. And my real name is "HariKrishna" and see that it is mentioned in Signed-off-by tag. Do I need to add surname as well ? Please let me know. Thank you. HariKrishna. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-09-08 9:54 ` hariconscious @ 2025-09-08 13:23 ` Jonathan Corbet 0 siblings, 0 replies; 1767+ messages in thread From: Jonathan Corbet @ 2025-09-08 13:23 UTC (permalink / raw) To: hariconscious Cc: catalin.marinas, hariconscious, linux-arm-kernel, linux-doc, linux-kernel, shuah, will hariconscious@gmail.com writes: > Thanks for the suggestion, will correct and send the patch again. > And my real name is "HariKrishna" and see that it is mentioned in Signed-off-by tag. > Do I need to add surname as well ? Please let me know. Yes, signoffs should give your full name. Thanks, jon ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2025-08-12 13:34 Baoquan He
2025-08-12 13:49 ` Baoquan He
0 siblings, 1 reply; 1767+ messages in thread
From: Baoquan He @ 2025-08-12 13:34 UTC (permalink / raw)
To: linux-mm, christophe.leroy
alexghiti@rivosinc.com, agordeev@linux.ibm.com, linux@armlinux.org.uk,
linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
x86@kernel.org, chris@zankel.net, jcmvbkbc@gmail.com, linux-um@lists.infradead.org
Cc: ryabinin.a.a@gmail.com, glider@google.com, andreyknvl@gmail.com,
dvyukov@google.com, vincenzo.frascino@arm.com,
akpm@linux-foundation.org, kasan-dev@googlegroups.com,
linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
sj@kernel.org, lorenzo.stoakes@oracle.com, elver@google.com,
snovitoll@gmail.com
Bcc: bhe@redhat.com
Subject: Re: [PATCH v2 00/12] mm/kasan: make kasan=on|off work for all three
modes
Reply-To:
In-Reply-To: <20250812124941.69508-1-bhe@redhat.com>
Forgot adding related ARCH mailing list or people to CC, add them.
On 08/12/25 at 08:49pm, Baoquan He wrote:
> Currently only hw_tags mode of kasan can be enabled or disabled with
> kernel parameter kasan=on|off for built kernel. For kasan generic and
> sw_tags mode, there's no way to disable them once kernel is built.
> This is not convenient sometime, e.g in system kdump is configured.
> When the 1st kernel has KASAN enabled and crash triggered to switch to
> kdump kernel, the generic or sw_tags mode will cost much extra memory
> for kasan shadow while in fact it's meaningless to have kasan in kdump
> kernel.
>
> So this patchset moves the kasan=on|off out of hw_tags scope and into
> common code to make it visible in generic and sw_tags mode too. Then we
> can add kasan=off in kdump kernel to reduce the unneeded meomry cost for
> kasan.
>
> Changelog:
> ====
> v1->v2:
> - Add __ro_after_init for __ro_after_init, and remove redundant blank
> lines in mm/kasan/common.c. Thanks to Marco.
> - Fix a code bug in <linux/kasan-enabled.h> when CONFIG_KASAN is unset,
> this is found out by SeongJae and Lorenzo, and also reported by LKP
> report, thanks to them.
> - Add a missing kasan_enabled() checking in kasan_report(). This will
> cause below KASAN report info even though kasan=off is set:
> ==================================================================
> BUG: KASAN: stack-out-of-bounds in tick_program_event+0x130/0x150
> Read of size 4 at addr ffff00005f747778 by task swapper/0/1
>
> CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0+ #8 PREEMPT(voluntary)
> Hardware name: GIGABYTE R272-P30-JG/MP32-AR0-JG, BIOS F31n (SCP: 2.10.20220810) 09/30/2022
> Call trace:
> show_stack+0x30/0x90 (C)
> dump_stack_lvl+0x7c/0xa0
> print_address_description.constprop.0+0x90/0x310
> print_report+0x104/0x1f0
> kasan_report+0xc8/0x110
> __asan_report_load4_noabort+0x20/0x30
> tick_program_event+0x130/0x150
> ......snip...
> ==================================================================
>
> - Add jump_label_init() calling before kasan_init() in setup_arch() in these
> architectures: xtensa, arm. Because they currenly rely on
> jump_label_init() in main() which is a little late. Then the early static
> key kasan_flag_enabled in kasan_init() won't work.
>
> - In UML architecture, change to enable kasan_flag_enabled in arch_mm_preinit()
> because kasan_init() is enabled before main(), there's no chance to operate
> on static key in kasan_init().
>
> Test:
> =====
> In v1, I took test on x86_64 for generic mode, and on arm64 for
> generic, sw_tags and hw_tags mode. All of them works well.
>
> In v2, I only tested on arm64 for generic, sw_tags and hw_tags mode, it
> works. For powerpc, I got a BOOK3S/64 machine, while it says
> 'KASAN not enabled as it requires radix' and KASAN is disabled. Will
> look for other POWER machine to test this.
> ====
>
> Baoquan He (12):
> mm/kasan: add conditional checks in functions to return directly if
> kasan is disabled
> mm/kasan: move kasan= code to common place
> mm/kasan/sw_tags: don't initialize kasan if it's disabled
> arch/arm: don't initialize kasan if it's disabled
> arch/arm64: don't initialize kasan if it's disabled
> arch/loongarch: don't initialize kasan if it's disabled
> arch/powerpc: don't initialize kasan if it's disabled
> arch/riscv: don't initialize kasan if it's disabled
> arch/x86: don't initialize kasan if it's disabled
> arch/xtensa: don't initialize kasan if it's disabled
> arch/um: don't initialize kasan if it's disabled
> mm/kasan: make kasan=on|off take effect for all three modes
>
> arch/arm/kernel/setup.c | 6 +++++
> arch/arm/mm/kasan_init.c | 6 +++++
> arch/arm64/mm/kasan_init.c | 7 ++++++
> arch/loongarch/mm/kasan_init.c | 5 ++++
> arch/powerpc/mm/kasan/init_32.c | 8 +++++-
> arch/powerpc/mm/kasan/init_book3e_64.c | 6 +++++
> arch/powerpc/mm/kasan/init_book3s_64.c | 6 +++++
> arch/riscv/mm/kasan_init.c | 6 +++++
> arch/um/kernel/mem.c | 6 +++++
> arch/x86/mm/kasan_init_64.c | 6 +++++
> arch/xtensa/kernel/setup.c | 1 +
> arch/xtensa/mm/kasan_init.c | 6 +++++
> include/linux/kasan-enabled.h | 18 ++++++-------
> mm/kasan/common.c | 25 ++++++++++++++++++
> mm/kasan/generic.c | 20 +++++++++++++--
> mm/kasan/hw_tags.c | 35 ++------------------------
> mm/kasan/init.c | 6 +++++
> mm/kasan/quarantine.c | 3 +++
> mm/kasan/report.c | 4 ++-
> mm/kasan/shadow.c | 23 ++++++++++++++++-
> mm/kasan/sw_tags.c | 9 +++++++
> 21 files changed, 165 insertions(+), 47 deletions(-)
>
> --
> 2.41.0
>
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2025-08-12 13:34 Baoquan He @ 2025-08-12 13:49 ` Baoquan He 0 siblings, 0 replies; 1767+ messages in thread From: Baoquan He @ 2025-08-12 13:49 UTC (permalink / raw) To: linux-mm, christophe.leroy On 08/12/25 at 09:34pm, Baoquan He wrote: > alexghiti@rivosinc.com, agordeev@linux.ibm.com, linux@armlinux.org.uk, > linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, > linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, > x86@kernel.org, chris@zankel.net, jcmvbkbc@gmail.com, linux-um@lists.infradead.org > Cc: ryabinin.a.a@gmail.com, glider@google.com, andreyknvl@gmail.com, > dvyukov@google.com, vincenzo.frascino@arm.com, > akpm@linux-foundation.org, kasan-dev@googlegroups.com, > linux-kernel@vger.kernel.org, kexec@lists.infradead.org, > sj@kernel.org, lorenzo.stoakes@oracle.com, elver@google.com, > snovitoll@gmail.com > Bcc: bhe@redhat.com > Subject: Re: [PATCH v2 00/12] mm/kasan: make kasan=on|off work for all three > modes > Reply-To: > In-Reply-To: <20250812124941.69508-1-bhe@redhat.com> > > Forgot adding related ARCH mailing list or people to CC, add them. Sorry for the noise, I made mistake on mail format when adding people to CC. > > On 08/12/25 at 08:49pm, Baoquan He wrote: > > Currently only hw_tags mode of kasan can be enabled or disabled with > > kernel parameter kasan=on|off for built kernel. For kasan generic and > > sw_tags mode, there's no way to disable them once kernel is built. > > This is not convenient sometime, e.g in system kdump is configured. > > When the 1st kernel has KASAN enabled and crash triggered to switch to > > kdump kernel, the generic or sw_tags mode will cost much extra memory > > for kasan shadow while in fact it's meaningless to have kasan in kdump > > kernel. > > > > So this patchset moves the kasan=on|off out of hw_tags scope and into > > common code to make it visible in generic and sw_tags mode too. Then we > > can add kasan=off in kdump kernel to reduce the unneeded meomry cost for > > kasan. > > > > Changelog: > > ==== > > v1->v2: > > - Add __ro_after_init for __ro_after_init, and remove redundant blank > > lines in mm/kasan/common.c. Thanks to Marco. > > - Fix a code bug in <linux/kasan-enabled.h> when CONFIG_KASAN is unset, > > this is found out by SeongJae and Lorenzo, and also reported by LKP > > report, thanks to them. > > - Add a missing kasan_enabled() checking in kasan_report(). This will > > cause below KASAN report info even though kasan=off is set: > > ================================================================== > > BUG: KASAN: stack-out-of-bounds in tick_program_event+0x130/0x150 > > Read of size 4 at addr ffff00005f747778 by task swapper/0/1 > > > > CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0+ #8 PREEMPT(voluntary) > > Hardware name: GIGABYTE R272-P30-JG/MP32-AR0-JG, BIOS F31n (SCP: 2.10.20220810) 09/30/2022 > > Call trace: > > show_stack+0x30/0x90 (C) > > dump_stack_lvl+0x7c/0xa0 > > print_address_description.constprop.0+0x90/0x310 > > print_report+0x104/0x1f0 > > kasan_report+0xc8/0x110 > > __asan_report_load4_noabort+0x20/0x30 > > tick_program_event+0x130/0x150 > > ......snip... > > ================================================================== > > > > - Add jump_label_init() calling before kasan_init() in setup_arch() in these > > architectures: xtensa, arm. Because they currenly rely on > > jump_label_init() in main() which is a little late. Then the early static > > key kasan_flag_enabled in kasan_init() won't work. > > > > - In UML architecture, change to enable kasan_flag_enabled in arch_mm_preinit() > > because kasan_init() is enabled before main(), there's no chance to operate > > on static key in kasan_init(). > > > > Test: > > ===== > > In v1, I took test on x86_64 for generic mode, and on arm64 for > > generic, sw_tags and hw_tags mode. All of them works well. > > > > In v2, I only tested on arm64 for generic, sw_tags and hw_tags mode, it > > works. For powerpc, I got a BOOK3S/64 machine, while it says > > 'KASAN not enabled as it requires radix' and KASAN is disabled. Will > > look for other POWER machine to test this. > > ==== > > > > Baoquan He (12): > > mm/kasan: add conditional checks in functions to return directly if > > kasan is disabled > > mm/kasan: move kasan= code to common place > > mm/kasan/sw_tags: don't initialize kasan if it's disabled > > arch/arm: don't initialize kasan if it's disabled > > arch/arm64: don't initialize kasan if it's disabled > > arch/loongarch: don't initialize kasan if it's disabled > > arch/powerpc: don't initialize kasan if it's disabled > > arch/riscv: don't initialize kasan if it's disabled > > arch/x86: don't initialize kasan if it's disabled > > arch/xtensa: don't initialize kasan if it's disabled > > arch/um: don't initialize kasan if it's disabled > > mm/kasan: make kasan=on|off take effect for all three modes > > > > arch/arm/kernel/setup.c | 6 +++++ > > arch/arm/mm/kasan_init.c | 6 +++++ > > arch/arm64/mm/kasan_init.c | 7 ++++++ > > arch/loongarch/mm/kasan_init.c | 5 ++++ > > arch/powerpc/mm/kasan/init_32.c | 8 +++++- > > arch/powerpc/mm/kasan/init_book3e_64.c | 6 +++++ > > arch/powerpc/mm/kasan/init_book3s_64.c | 6 +++++ > > arch/riscv/mm/kasan_init.c | 6 +++++ > > arch/um/kernel/mem.c | 6 +++++ > > arch/x86/mm/kasan_init_64.c | 6 +++++ > > arch/xtensa/kernel/setup.c | 1 + > > arch/xtensa/mm/kasan_init.c | 6 +++++ > > include/linux/kasan-enabled.h | 18 ++++++------- > > mm/kasan/common.c | 25 ++++++++++++++++++ > > mm/kasan/generic.c | 20 +++++++++++++-- > > mm/kasan/hw_tags.c | 35 ++------------------------ > > mm/kasan/init.c | 6 +++++ > > mm/kasan/quarantine.c | 3 +++ > > mm/kasan/report.c | 4 ++- > > mm/kasan/shadow.c | 23 ++++++++++++++++- > > mm/kasan/sw_tags.c | 9 +++++++ > > 21 files changed, 165 insertions(+), 47 deletions(-) > > > > -- > > 2.41.0 > > > > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2025-08-06 3:34 Sang-Heon Jeon 2025-08-06 3:44 ` Sang-Heon Jeon 0 siblings, 1 reply; 1767+ messages in thread From: Sang-Heon Jeon @ 2025-08-06 3:34 UTC (permalink / raw) To: damon subscribe damon mailing list ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-08-06 3:34 Sang-Heon Jeon @ 2025-08-06 3:44 ` Sang-Heon Jeon 0 siblings, 0 replies; 1767+ messages in thread From: Sang-Heon Jeon @ 2025-08-06 3:44 UTC (permalink / raw) To: damon Because of my lack of knowledge, the above mail is just a mistake. Just Ignore plz. Sorry for being annoying. PS) Unfortunately, I found this thread [1] after I sent unnecessary mail to others. [1] https://lore.kernel.org/damon/20240926213942.17022-1-sj@kernel.org/ On Wed, Aug 6, 2025 at 12:34 PM Sang-Heon Jeon <ekffu200098@gmail.com> wrote: > > subscribe damon mailing list ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <CADU64hCr7mshqfBRE2Wp8zf4BHBdJoLLH=VJt2MrHeR+zHOV4w@mail.gmail.com>]
* (no subject) [not found] <CADU64hCr7mshqfBRE2Wp8zf4BHBdJoLLH=VJt2MrHeR+zHOV4w@mail.gmail.com> @ 2025-07-20 18:26 ` > 2025-07-20 19:30 ` Re: David Lechner 2025-07-21 7:52 ` Re: Andy Shevchenko 0 siblings, 2 replies; 1767+ messages in thread From: > @ 2025-07-20 18:26 UTC (permalink / raw) To: linux-kernel, devicetree, linux-iio, netdev, linux-arm-kernel, linux-amlogic Cc: ribalda, jic23, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt, andrew+netdev, davem, edumazet, kuba, pabeni, neil.armstrong, khilman, jbrunet, martin.blumenstingl, sanjay suthar Changes in v2: - Fixed commit message grammar - Fixed subject line style as per DT convention - Added missing reviewers/maintainers in CC From 5c00524cbb47e30ee04223fe9502af2eb003ddf1 Mon Sep 17 00:00:00 2001 From: sanjay suthar <sanjaysuthar661996@gmail.com> Date: Sun, 20 Jul 2025 01:11:00 +0530 Subject: [PATCH v2] dt-bindings: cleanup: fix duplicated 'is is' in YAML docs Fix minor grammatical issues by removing duplicated "is" in two devicetree binding documents: - net/amlogic,meson-dwmac.yaml - iio/dac/ti,dac7612.yaml Signed-off-by: sanjay suthar <sanjaysuthar661996@gmail.com> --- Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml | 2 +- Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml index 20dd1370660d..624c640be4c8 100644 --- a/Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml +++ b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml @@ -9,7 +9,7 @@ title: Texas Instruments DAC7612 family of DACs description: The DAC7612 is a dual, 12-bit digital-to-analog converter (DAC) with guaranteed 12-bit monotonicity performance over the industrial temperature - range. Is is programmable through an SPI interface. + range. It is programmable through an SPI interface. maintainers: - Ricardo Ribalda Delgado <ricardo@ribalda.com> diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml index 0cd78d71768c..5c91716d1f21 100644 --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml @@ -149,7 +149,7 @@ properties: - description: The first register range should be the one of the DWMAC controller - description: - The second range is is for the Amlogic specific configuration + The second range is for the Amlogic specific configuration (for example the PRG_ETHERNET register range on Meson8b and newer) interrupts: -- 2.34.1 _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2025-07-20 18:26 ` > @ 2025-07-20 19:30 ` David Lechner 2025-07-21 7:52 ` Re: Andy Shevchenko 1 sibling, 0 replies; 1767+ messages in thread From: David Lechner @ 2025-07-20 19:30 UTC (permalink / raw) To: >, linux-kernel, devicetree, linux-iio, netdev, linux-arm-kernel, linux-amlogic Cc: ribalda, jic23, nuno.sa, andy, robh, krzk+dt, conor+dt, andrew+netdev, davem, edumazet, kuba, pabeni, neil.armstrong, khilman, jbrunet, martin.blumenstingl On 7/20/25 1:26 PM, > wrote: > Changes in v2: > - Fixed commit message grammar > - Fixed subject line style as per DT convention > - Added missing reviewers/maintainers in CC > By placing this before the headers, our email clients think this message doesn't have a subject. It should go after the ---. > From 5c00524cbb47e30ee04223fe9502af2eb003ddf1 Mon Sep 17 00:00:00 2001 > From: sanjay suthar <sanjaysuthar661996@gmail.com> > Date: Sun, 20 Jul 2025 01:11:00 +0530 > Subject: [PATCH v2] dt-bindings: cleanup: fix duplicated 'is is' in YAML docs > > Fix minor grammatical issues by removing duplicated "is" in two devicetree > binding documents: > > - net/amlogic,meson-dwmac.yaml > - iio/dac/ti,dac7612.yaml > > Signed-off-by: sanjay suthar <sanjaysuthar661996@gmail.com> > --- This is where the changelog belongs. > Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml | 2 +- > Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml > index 20dd1370660d..624c640be4c8 100644 > --- a/Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml > +++ b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml > @@ -9,7 +9,7 @@ title: Texas Instruments DAC7612 family of DACs > description: > The DAC7612 is a dual, 12-bit digital-to-analog converter (DAC) with > guaranteed 12-bit monotonicity performance over the industrial temperature > - range. Is is programmable through an SPI interface. > + range. It is programmable through an SPI interface. > > maintainers: > - Ricardo Ribalda Delgado <ricardo@ribalda.com> > diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml > index 0cd78d71768c..5c91716d1f21 100644 > --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml > +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml > @@ -149,7 +149,7 @@ properties: > - description: > The first register range should be the one of the DWMAC controller > - description: > - The second range is is for the Amlogic specific configuration > + The second range is for the Amlogic specific configuration > (for example the PRG_ETHERNET register range on Meson8b and newer) > > interrupts: I would be tempted to split this into two patches. It's a bit odd to have a single patch touching two unrelated bindings. _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2025-07-20 19:30 ` David Lechner 0 siblings, 0 replies; 1767+ messages in thread From: David Lechner @ 2025-07-20 19:30 UTC (permalink / raw) To: >, linux-kernel, devicetree, linux-iio, netdev, linux-arm-kernel, linux-amlogic Cc: ribalda, jic23, nuno.sa, andy, robh, krzk+dt, conor+dt, andrew+netdev, davem, edumazet, kuba, pabeni, neil.armstrong, khilman, jbrunet, martin.blumenstingl On 7/20/25 1:26 PM, > wrote: > Changes in v2: > - Fixed commit message grammar > - Fixed subject line style as per DT convention > - Added missing reviewers/maintainers in CC > By placing this before the headers, our email clients think this message doesn't have a subject. It should go after the ---. > From 5c00524cbb47e30ee04223fe9502af2eb003ddf1 Mon Sep 17 00:00:00 2001 > From: sanjay suthar <sanjaysuthar661996@gmail.com> > Date: Sun, 20 Jul 2025 01:11:00 +0530 > Subject: [PATCH v2] dt-bindings: cleanup: fix duplicated 'is is' in YAML docs > > Fix minor grammatical issues by removing duplicated "is" in two devicetree > binding documents: > > - net/amlogic,meson-dwmac.yaml > - iio/dac/ti,dac7612.yaml > > Signed-off-by: sanjay suthar <sanjaysuthar661996@gmail.com> > --- This is where the changelog belongs. > Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml | 2 +- > Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml > index 20dd1370660d..624c640be4c8 100644 > --- a/Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml > +++ b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml > @@ -9,7 +9,7 @@ title: Texas Instruments DAC7612 family of DACs > description: > The DAC7612 is a dual, 12-bit digital-to-analog converter (DAC) with > guaranteed 12-bit monotonicity performance over the industrial temperature > - range. Is is programmable through an SPI interface. > + range. It is programmable through an SPI interface. > > maintainers: > - Ricardo Ribalda Delgado <ricardo@ribalda.com> > diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml > index 0cd78d71768c..5c91716d1f21 100644 > --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml > +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml > @@ -149,7 +149,7 @@ properties: > - description: > The first register range should be the one of the DWMAC controller > - description: > - The second range is is for the Amlogic specific configuration > + The second range is for the Amlogic specific configuration > (for example the PRG_ETHERNET register range on Meson8b and newer) > > interrupts: I would be tempted to split this into two patches. It's a bit odd to have a single patch touching two unrelated bindings. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-07-20 19:30 ` Re: David Lechner @ 2025-07-21 6:52 ` Krzysztof Kozlowski -1 siblings, 0 replies; 1767+ messages in thread From: Krzysztof Kozlowski @ 2025-07-21 6:52 UTC (permalink / raw) To: David Lechner, >, linux-kernel, devicetree, linux-iio, netdev, linux-arm-kernel, linux-amlogic Cc: ribalda, jic23, nuno.sa, andy, robh, krzk+dt, conor+dt, andrew+netdev, davem, edumazet, kuba, pabeni, neil.armstrong, khilman, jbrunet, martin.blumenstingl On 20/07/2025 21:30, David Lechner wrote: >> - Ricardo Ribalda Delgado <ricardo@ribalda.com> >> diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml >> index 0cd78d71768c..5c91716d1f21 100644 >> --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml >> +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml >> @@ -149,7 +149,7 @@ properties: >> - description: >> The first register range should be the one of the DWMAC controller >> - description: >> - The second range is is for the Amlogic specific configuration >> + The second range is for the Amlogic specific configuration >> (for example the PRG_ETHERNET register range on Meson8b and newer) >> >> interrupts: > > I would be tempted to split this into two patches. It's a bit odd to have No, it's a churn to split this into more than one patch. > a single patch touching two unrelated bindings. Best regards, Krzysztof _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2025-07-21 6:52 ` Krzysztof Kozlowski 0 siblings, 0 replies; 1767+ messages in thread From: Krzysztof Kozlowski @ 2025-07-21 6:52 UTC (permalink / raw) To: David Lechner, >, linux-kernel, devicetree, linux-iio, netdev, linux-arm-kernel, linux-amlogic Cc: ribalda, jic23, nuno.sa, andy, robh, krzk+dt, conor+dt, andrew+netdev, davem, edumazet, kuba, pabeni, neil.armstrong, khilman, jbrunet, martin.blumenstingl On 20/07/2025 21:30, David Lechner wrote: >> - Ricardo Ribalda Delgado <ricardo@ribalda.com> >> diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml >> index 0cd78d71768c..5c91716d1f21 100644 >> --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml >> +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml >> @@ -149,7 +149,7 @@ properties: >> - description: >> The first register range should be the one of the DWMAC controller >> - description: >> - The second range is is for the Amlogic specific configuration >> + The second range is for the Amlogic specific configuration >> (for example the PRG_ETHERNET register range on Meson8b and newer) >> >> interrupts: > > I would be tempted to split this into two patches. It's a bit odd to have No, it's a churn to split this into more than one patch. > a single patch touching two unrelated bindings. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <CADU64hDZeyaCpHXBmSG1rtHjpxmjejT7asK9oGBUMF55eYeh4w@mail.gmail.com>]
* Re: [not found] ` <CADU64hDZeyaCpHXBmSG1rtHjpxmjejT7asK9oGBUMF55eYeh4w@mail.gmail.com> @ 2025-07-21 14:09 ` David Lechner 0 siblings, 0 replies; 1767+ messages in thread From: David Lechner @ 2025-07-21 14:09 UTC (permalink / raw) To: Sanjay Suthar, Krzysztof Kozlowski Cc: linux-kernel, devicetree, linux-iio, netdev, linux-arm-kernel, linux-amlogic, ribalda, jic23, nuno.sa, andy, robh, krzk+dt, conor+dt, andrew+netdev, davem, edumazet, kuba, pabeni, neil.armstrong, khilman, jbrunet, martin.blumenstingl On 7/21/25 5:15 AM, Sanjay Suthar wrote: > On Mon, Jul 21, 2025 at 12:22 PM Krzysztof Kozlowski <krzk@kernel.org <mailto:krzk@kernel.org>> wrote: >> >> On 20/07/2025 21:30, David Lechner wrote: >> >> - Ricardo Ribalda Delgado <ricardo@ribalda.com <mailto:ricardo@ribalda.com>> >> >> diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml >> >> index 0cd78d71768c..5c91716d1f21 100644 >> >> --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml >> >> +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml >> >> @@ -149,7 +149,7 @@ properties: >> >> - description: >> >> The first register range should be the one of the DWMAC controller >> >> - description: >> >> - The second range is is for the Amlogic specific configuration >> >> + The second range is for the Amlogic specific configuration >> >> (for example the PRG_ETHERNET register range on Meson8b and newer) >> >> >> >> interrupts: >> > >> > I would be tempted to split this into two patches. It's a bit odd to have >> >> >> No, it's a churn to split this into more than one patch. >> > > Thanks for the reply. Since there are suggestions on patch split as it is touching different subsystems, still not clear if I should split the patch or single patch is fine. I would appreciate if you can guide on the next steps to be taken > > Best Regards, > Sanjay Suthar Krzysztof is one of the devicetree maintainers and I am not, so you should do what Krzysztof says - leave it as one patch. :-) _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2025-07-21 14:09 ` David Lechner 0 siblings, 0 replies; 1767+ messages in thread From: David Lechner @ 2025-07-21 14:09 UTC (permalink / raw) To: Sanjay Suthar, Krzysztof Kozlowski Cc: linux-kernel, devicetree, linux-iio, netdev, linux-arm-kernel, linux-amlogic, ribalda, jic23, nuno.sa, andy, robh, krzk+dt, conor+dt, andrew+netdev, davem, edumazet, kuba, pabeni, neil.armstrong, khilman, jbrunet, martin.blumenstingl On 7/21/25 5:15 AM, Sanjay Suthar wrote: > On Mon, Jul 21, 2025 at 12:22 PM Krzysztof Kozlowski <krzk@kernel.org <mailto:krzk@kernel.org>> wrote: >> >> On 20/07/2025 21:30, David Lechner wrote: >> >> - Ricardo Ribalda Delgado <ricardo@ribalda.com <mailto:ricardo@ribalda.com>> >> >> diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml >> >> index 0cd78d71768c..5c91716d1f21 100644 >> >> --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml >> >> +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml >> >> @@ -149,7 +149,7 @@ properties: >> >> - description: >> >> The first register range should be the one of the DWMAC controller >> >> - description: >> >> - The second range is is for the Amlogic specific configuration >> >> + The second range is for the Amlogic specific configuration >> >> (for example the PRG_ETHERNET register range on Meson8b and newer) >> >> >> >> interrupts: >> > >> > I would be tempted to split this into two patches. It's a bit odd to have >> >> >> No, it's a churn to split this into more than one patch. >> > > Thanks for the reply. Since there are suggestions on patch split as it is touching different subsystems, still not clear if I should split the patch or single patch is fine. I would appreciate if you can guide on the next steps to be taken > > Best Regards, > Sanjay Suthar Krzysztof is one of the devicetree maintainers and I am not, so you should do what Krzysztof says - leave it as one patch. :-) ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-07-20 18:26 ` > @ 2025-07-21 7:52 ` Andy Shevchenko 2025-07-21 7:52 ` Re: Andy Shevchenko 1 sibling, 0 replies; 1767+ messages in thread From: Andy Shevchenko @ 2025-07-21 7:52 UTC (permalink / raw) To: > Cc: linux-kernel, devicetree, linux-iio, netdev, linux-arm-kernel, linux-amlogic, ribalda, jic23, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt, andrew+netdev, davem, edumazet, kuba, pabeni, neil.armstrong, khilman, jbrunet, martin.blumenstingl On Sun, Jul 20, 2025 at 11:56:27PM +0530, > wrote: > Changes in v2: > - Fixed commit message grammar > - Fixed subject line style as per DT convention > - Added missing reviewers/maintainers in CC > > From 5c00524cbb47e30ee04223fe9502af2eb003ddf1 Mon Sep 17 00:00:00 2001 > From: sanjay suthar <sanjaysuthar661996@gmail.com> > Date: Sun, 20 Jul 2025 01:11:00 +0530 > Subject: [PATCH v2] dt-bindings: cleanup: fix duplicated 'is is' in YAML docs > > Fix minor grammatical issues by removing duplicated "is" in two devicetree > binding documents: > > - net/amlogic,meson-dwmac.yaml > - iio/dac/ti,dac7612.yaml This mail is b0rken. -- With Best Regards, Andy Shevchenko _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2025-07-21 7:52 ` Andy Shevchenko 0 siblings, 0 replies; 1767+ messages in thread From: Andy Shevchenko @ 2025-07-21 7:52 UTC (permalink / raw) To: > Cc: linux-kernel, devicetree, linux-iio, netdev, linux-arm-kernel, linux-amlogic, ribalda, jic23, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt, andrew+netdev, davem, edumazet, kuba, pabeni, neil.armstrong, khilman, jbrunet, martin.blumenstingl On Sun, Jul 20, 2025 at 11:56:27PM +0530, > wrote: > Changes in v2: > - Fixed commit message grammar > - Fixed subject line style as per DT convention > - Added missing reviewers/maintainers in CC > > From 5c00524cbb47e30ee04223fe9502af2eb003ddf1 Mon Sep 17 00:00:00 2001 > From: sanjay suthar <sanjaysuthar661996@gmail.com> > Date: Sun, 20 Jul 2025 01:11:00 +0530 > Subject: [PATCH v2] dt-bindings: cleanup: fix duplicated 'is is' in YAML docs > > Fix minor grammatical issues by removing duplicated "is" in two devicetree > binding documents: > > - net/amlogic,meson-dwmac.yaml > - iio/dac/ti,dac7612.yaml This mail is b0rken. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2025-07-01 13:44 Emanuele Ghidoli 2025-07-11 2:21 ` Fabio Estevam 0 siblings, 1 reply; 1767+ messages in thread From: Emanuele Ghidoli @ 2025-07-01 13:44 UTC (permalink / raw) To: Francesco Dolcini, Tom Rini, Fabio Estevam; +Cc: Emanuele Ghidoli, u-boot From: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Subject: [PATCH v1 0/5] Enable RNG support for KASLR on Toradex arm64 i.MX SoMs This patch series enables RNG support to automatically populate /chosen/kaslr-seed on the following Toradex arm64 i.MX System on Modules (SoMs): - Verdin iMX8MM - Verdin iMX8MP - Toradex SMARC iMX8MP - Apalis iMX8 - Colibri iMX8X This improves kernel security by supporting Kernel Address Space Layout Randomization (KASLR) using a runtime-provided seed from the hardware RNG. Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> --- Emanuele Ghidoli (5): configs: verdin-imx8mm: enable RNG support for KASLR configs: verdin-imx8mp: enable RNG support for KASLR configs: toradex-smarc-imx8mp: enable RNG support for KASLR configs: apalis-imx8: enable RNG support for KASLR configs: colibri-imx8x: enable RNG support for KASLR configs/apalis-imx8_defconfig | 5 ++++- configs/colibri-imx8x_defconfig | 5 ++++- configs/toradex-smarc-imx8mp_defconfig | 1 + configs/verdin-imx8mm_defconfig | 5 ++++- configs/verdin-imx8mp_defconfig | 1 + 5 files changed, 14 insertions(+), 3 deletions(-) -- 2.43.0 ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-07-01 13:44 Emanuele Ghidoli @ 2025-07-11 2:21 ` Fabio Estevam 0 siblings, 0 replies; 1767+ messages in thread From: Fabio Estevam @ 2025-07-11 2:21 UTC (permalink / raw) To: Emanuele Ghidoli; +Cc: Francesco Dolcini, Tom Rini, Emanuele Ghidoli, u-boot On Tue, Jul 1, 2025 at 10:45 AM Emanuele Ghidoli <ghidoliemanuele@gmail.com> wrote: > > From: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> > > Subject: [PATCH v1 0/5] Enable RNG support for KASLR on Toradex arm64 i.MX SoMs > > This patch series enables RNG support to automatically populate /chosen/kaslr-seed on the following Toradex arm64 i.MX System on Modules (SoMs): > - Verdin iMX8MM > - Verdin iMX8MP > - Toradex SMARC iMX8MP > - Apalis iMX8 > - Colibri iMX8X > > This improves kernel security by supporting Kernel Address Space Layout Randomization (KASLR) using a runtime-provided seed from the hardware RNG. > > Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Applied the series, thanks. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2025-05-14 20:21 Nicolas Pitre
2025-05-15 8:33 ` Jiri Slaby
0 siblings, 1 reply; 1767+ messages in thread
From: Nicolas Pitre @ 2025-05-14 20:21 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby; +Cc: npitre, linux-serial, linux-kernel
From 28043dec8352fd857c6878c2ee568620a124b855 Mon Sep 17 00:00:00 2001
From: Nicolas Pitre <nico@fluxnic.net>
Date: Wed, 14 May 2025 15:58:22 -0400
Subject: [PATCH] vt: remove VT_RESIZE and VT_RESIZEX from vt_compat_ioctl()
From: Nicolas Pitre <npitre@baylibre.com>
They are listed amon those cmd values that "treat 'arg' as an integer"
which is wrong. They should instead fall into the default case. Probably
nobody ever exercized that code since 2009 but still.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Fixes: e92166517e3c ("tty: handle VT specific compat ioctls in vt driver")
diff --git a/drivers/tty/vt/vt_ioctl.c b/drivers/tty/vt/vt_ioctl.c
index 83a3d49535e5..61342e06970a 100644
--- a/drivers/tty/vt/vt_ioctl.c
+++ b/drivers/tty/vt/vt_ioctl.c
@@ -1119,8 +1119,6 @@ long vt_compat_ioctl(struct tty_struct *tty,
case VT_WAITACTIVE:
case VT_RELDISP:
case VT_DISALLOCATE:
- case VT_RESIZE:
- case VT_RESIZEX:
return vt_ioctl(tty, cmd, arg);
/*
^ permalink raw reply related [flat|nested] 1767+ messages in thread* Re: 2025-05-14 20:21 Nicolas Pitre @ 2025-05-15 8:33 ` Jiri Slaby 0 siblings, 0 replies; 1767+ messages in thread From: Jiri Slaby @ 2025-05-15 8:33 UTC (permalink / raw) To: Nicolas Pitre, Greg Kroah-Hartman; +Cc: npitre, linux-serial, linux-kernel On 14. 05. 25, 22:21, Nicolas Pitre wrote: > From 28043dec8352fd857c6878c2ee568620a124b855 Mon Sep 17 00:00:00 2001 > From: Nicolas Pitre <nico@fluxnic.net> > Date: Wed, 14 May 2025 15:58:22 -0400 > Subject: [PATCH] vt: remove VT_RESIZE and VT_RESIZEX from vt_compat_ioctl() > From: Nicolas Pitre <npitre@baylibre.com> > > They are listed amon those cmd values that "treat 'arg' as an integer" > which is wrong. They should instead fall into the default case. Probably > nobody ever exercized that code since 2009 but still. AFAICS in the debian code search, exactly noone (except sanitizers, strace, fuzzers, valgrind, ...) uses VT_RESIZEX. VT_RESIZE is used by kbd's resizecons -- and there it's the sole purpose to call this ioctl. I wonder how comes noone using 32bit of resizecons on 64bit noticed? Thinking... Actually, on x86, it doesn't matter if it takes arg (case VT_RESIZE) or compat_ptr() (default label) path as both are given the same user pointer... It matters on s390x, but noone cares about the 32--64bit mix in there, apparently. > Signed-off-by: Nicolas Pitre <npitre@baylibre.com> > Fixes: e92166517e3c ("tty: handle VT specific compat ioctls in vt driver") FWIW, the e-mail's Subject is empty. Reviewed-by: Jiri Slaby <jirislaby@kernel.org> > diff --git a/drivers/tty/vt/vt_ioctl.c b/drivers/tty/vt/vt_ioctl.c > index 83a3d49535e5..61342e06970a 100644 > --- a/drivers/tty/vt/vt_ioctl.c > +++ b/drivers/tty/vt/vt_ioctl.c > @@ -1119,8 +1119,6 @@ long vt_compat_ioctl(struct tty_struct *tty, > case VT_WAITACTIVE: > case VT_RELDISP: > case VT_DISALLOCATE: > - case VT_RESIZE: > - case VT_RESIZEX: > return vt_ioctl(tty, cmd, arg); > > /* -- js suse labs ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2025-05-09 17:38 Shawn Anastasio
2025-05-10 19:50 ` Trilok Soni
0 siblings, 1 reply; 1767+ messages in thread
From: Shawn Anastasio @ 2025-05-09 17:38 UTC (permalink / raw)
To: linux-pci, Lukas Wunner, Krishna Chaitanya Chundru
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, chaitanya chundru, Bjorn Andersson, Konrad Dybcio,
cros-qcom-dts-watchers, Jingoo Han, Bartosz Golaszewski,
quic_vbadigan, amitk, devicetree, linux-kernel, linux-arm-msm,
jorge.ramirez, Dmitry Baryshkov, Timothy Pearson, Shawn Anastasio
From: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Date: Sat, 12 Apr 2025 07:19:56 +0530
Subject: [PATCH v6] PCI: PCI: Add pcie_link_is_active() to determine if the
PCIe link is active
Introduce a common API to check if the PCIe link is active, replacing
duplicate code in multiple locations.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Shawn Anastasio <sanastasio@raptorengineering.com>
---
This is an updated patch pulled from Krishna's v5 series:
https://patchwork.kernel.org/project/linux-pci/list/?series=952665
The following changes to Krishna's v5 were made by me:
- Revert pcie_link_is_active return type back to int per Lukas' review
comments
- Handle non-zero error returns at call site of the new function in
pci.c/pci_bridge_wait_for_secondary_bus
drivers/pci/hotplug/pciehp.h | 1 -
drivers/pci/hotplug/pciehp_ctrl.c | 2 +-
drivers/pci/hotplug/pciehp_hpc.c | 33 +++----------------------------
drivers/pci/pci.c | 26 +++++++++++++++++++++---
include/linux/pci.h | 4 ++++
5 files changed, 31 insertions(+), 35 deletions(-)
diff --git a/drivers/pci/hotplug/pciehp.h b/drivers/pci/hotplug/pciehp.h
index 273dd8c66f4e..acef728530e3 100644
--- a/drivers/pci/hotplug/pciehp.h
+++ b/drivers/pci/hotplug/pciehp.h
@@ -186,7 +186,6 @@ int pciehp_query_power_fault(struct controller *ctrl);
int pciehp_card_present(struct controller *ctrl);
int pciehp_card_present_or_link_active(struct controller *ctrl);
int pciehp_check_link_status(struct controller *ctrl);
-int pciehp_check_link_active(struct controller *ctrl);
void pciehp_release_ctrl(struct controller *ctrl);
int pciehp_sysfs_enable_slot(struct hotplug_slot *hotplug_slot);
diff --git a/drivers/pci/hotplug/pciehp_ctrl.c b/drivers/pci/hotplug/pciehp_ctrl.c
index d603a7aa7483..4bb58ba1c766 100644
--- a/drivers/pci/hotplug/pciehp_ctrl.c
+++ b/drivers/pci/hotplug/pciehp_ctrl.c
@@ -260,7 +260,7 @@ void pciehp_handle_presence_or_link_change(struct controller *ctrl, u32 events)
/* Turn the slot on if it's occupied or link is up */
mutex_lock(&ctrl->state_lock);
present = pciehp_card_present(ctrl);
- link_active = pciehp_check_link_active(ctrl);
+ link_active = pcie_link_is_active(ctrl->pcie->port);
if (present <= 0 && link_active <= 0) {
if (ctrl->state == BLINKINGON_STATE) {
ctrl->state = OFF_STATE;
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index 8a09fb6083e2..278bc21d531d 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -221,33 +221,6 @@ static void pcie_write_cmd_nowait(struct controller *ctrl, u16 cmd, u16 mask)
pcie_do_write_cmd(ctrl, cmd, mask, false);
}
-/**
- * pciehp_check_link_active() - Is the link active
- * @ctrl: PCIe hotplug controller
- *
- * Check whether the downstream link is currently active. Note it is
- * possible that the card is removed immediately after this so the
- * caller may need to take it into account.
- *
- * If the hotplug controller itself is not available anymore returns
- * %-ENODEV.
- */
-int pciehp_check_link_active(struct controller *ctrl)
-{
- struct pci_dev *pdev = ctrl_dev(ctrl);
- u16 lnk_status;
- int ret;
-
- ret = pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, &lnk_status);
- if (ret == PCIBIOS_DEVICE_NOT_FOUND || PCI_POSSIBLE_ERROR(lnk_status))
- return -ENODEV;
-
- ret = !!(lnk_status & PCI_EXP_LNKSTA_DLLLA);
- ctrl_dbg(ctrl, "%s: lnk_status = %x\n", __func__, lnk_status);
-
- return ret;
-}
-
static bool pci_bus_check_dev(struct pci_bus *bus, int devfn)
{
u32 l;
@@ -467,7 +440,7 @@ int pciehp_card_present_or_link_active(struct controller *ctrl)
if (ret)
return ret;
- return pciehp_check_link_active(ctrl);
+ return pcie_link_is_active(ctrl_dev(ctrl));
}
int pciehp_query_power_fault(struct controller *ctrl)
@@ -584,7 +557,7 @@ static void pciehp_ignore_dpc_link_change(struct controller *ctrl,
* Synthesize it to ensure that it is acted on.
*/
down_read_nested(&ctrl->reset_lock, ctrl->depth);
- if (!pciehp_check_link_active(ctrl))
+ if (!pcie_link_is_active(ctrl_dev(ctrl)))
pciehp_request(ctrl, PCI_EXP_SLTSTA_DLLSC);
up_read(&ctrl->reset_lock);
}
@@ -884,7 +857,7 @@ int pciehp_slot_reset(struct pcie_device *dev)
pcie_capability_write_word(dev->port, PCI_EXP_SLTSTA,
PCI_EXP_SLTSTA_DLLSC);
- if (!pciehp_check_link_active(ctrl))
+ if (!pcie_link_is_active(ctrl_dev(ctrl)))
pciehp_request(ctrl, PCI_EXP_SLTSTA_DLLSC);
return 0;
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index e77d5b53c0ce..3bb8354b14bf 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4926,7 +4926,6 @@ int pci_bridge_wait_for_secondary_bus(struct pci_dev *dev, char *reset_type)
return 0;
if (pcie_get_speed_cap(dev) <= PCIE_SPEED_5_0GT) {
- u16 status;
pci_dbg(dev, "waiting %d ms for downstream link\n", delay);
msleep(delay);
@@ -4942,8 +4941,7 @@ int pci_bridge_wait_for_secondary_bus(struct pci_dev *dev, char *reset_type)
if (!dev->link_active_reporting)
return -ENOTTY;
- pcie_capability_read_word(dev, PCI_EXP_LNKSTA, &status);
- if (!(status & PCI_EXP_LNKSTA_DLLLA))
+ if (pcie_link_is_active(dev) <= 0)
return -ENOTTY;
return pci_dev_wait(child, reset_type,
@@ -6247,6 +6245,28 @@ void pcie_print_link_status(struct pci_dev *dev)
}
EXPORT_SYMBOL(pcie_print_link_status);
+/**
+ * pcie_link_is_active() - Checks if the link is active or not
+ * @pdev: PCI device to query
+ *
+ * Check whether the link is active or not.
+ *
+ * Return: link state, or -ENODEV if the config read failes.
+ */
+int pcie_link_is_active(struct pci_dev *pdev)
+{
+ u16 lnk_status;
+ int ret;
+
+ ret = pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, &lnk_status);
+ if (ret == PCIBIOS_DEVICE_NOT_FOUND || PCI_POSSIBLE_ERROR(lnk_status))
+ return -ENODEV;
+
+ pci_dbg(pdev, "lnk_status = %x\n", lnk_status);
+ return !!(lnk_status & PCI_EXP_LNKSTA_DLLLA);
+}
+EXPORT_SYMBOL(pcie_link_is_active);
+
/**
* pci_select_bars - Make BAR mask from the type of resource
* @dev: the PCI device for which BAR mask is made
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 51e2bd6405cd..a79a9919320c 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1945,6 +1945,7 @@ pci_release_mem_regions(struct pci_dev *pdev)
pci_select_bars(pdev, IORESOURCE_MEM));
}
+int pcie_link_is_active(struct pci_dev *dev);
#else /* CONFIG_PCI is not enabled */
static inline void pci_set_flags(int flags) { }
@@ -2093,6 +2094,9 @@ pci_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,
{
return -ENOSPC;
}
+
+static inline bool pcie_link_is_active(struct pci_dev *dev)
+{ return false; }
#endif /* CONFIG_PCI */
/* Include architecture-dependent settings and functions */
--
2.30.2
^ permalink raw reply related [flat|nested] 1767+ messages in thread* Re: 2025-05-09 17:38 Shawn Anastasio @ 2025-05-10 19:50 ` Trilok Soni 0 siblings, 0 replies; 1767+ messages in thread From: Trilok Soni @ 2025-05-10 19:50 UTC (permalink / raw) To: Shawn Anastasio, linux-pci, Lukas Wunner, Krishna Chaitanya Chundru Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski, Conor Dooley, chaitanya chundru, Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers, Jingoo Han, Bartosz Golaszewski, quic_vbadigan, amitk, devicetree, linux-kernel, linux-arm-msm, jorge.ramirez, Dmitry Baryshkov, Timothy Pearson On 5/9/2025 10:38 AM, Shawn Anastasio wrote: > From: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> > > Date: Sat, 12 Apr 2025 07:19:56 +0530 > Subject: [PATCH v6] PCI: PCI: Add pcie_link_is_active() to determine if the > PCIe link is active I don't understand this patch and it doesn't have any subject in email. Please fix. > > Introduce a common API to check if the PCIe link is active, replacing > duplicate code in multiple locations. > > Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> > Signed-off-by: Shawn Anastasio <sanastasio@raptorengineering.com> > --- > This is an updated patch pulled from Krishna's v5 series: > https://patchwork.kernel.org/project/linux-pci/list/?series=952665 > > The following changes to Krishna's v5 were made by me: > - Revert pcie_link_is_active return type back to int per Lukas' review > comments > - Handle non-zero error returns at call site of the new function in > pci.c/pci_bridge_wait_for_secondary_bus > > drivers/pci/hotplug/pciehp.h | 1 - > drivers/pci/hotplug/pciehp_ctrl.c | 2 +- > drivers/pci/hotplug/pciehp_hpc.c | 33 +++---------------------------- > drivers/pci/pci.c | 26 +++++++++++++++++++++--- > include/linux/pci.h | 4 ++++ > 5 files changed, 31 insertions(+), 35 deletions(-) > > diff --git a/drivers/pci/hotplug/pciehp.h b/drivers/pci/hotplug/pciehp.h > index 273dd8c66f4e..acef728530e3 100644 > --- a/drivers/pci/hotplug/pciehp.h > +++ b/drivers/pci/hotplug/pciehp.h > @@ -186,7 +186,6 @@ int pciehp_query_power_fault(struct controller *ctrl); > int pciehp_card_present(struct controller *ctrl); > int pciehp_card_present_or_link_active(struct controller *ctrl); > int pciehp_check_link_status(struct controller *ctrl); > -int pciehp_check_link_active(struct controller *ctrl); > void pciehp_release_ctrl(struct controller *ctrl); > > int pciehp_sysfs_enable_slot(struct hotplug_slot *hotplug_slot); > diff --git a/drivers/pci/hotplug/pciehp_ctrl.c b/drivers/pci/hotplug/pciehp_ctrl.c > index d603a7aa7483..4bb58ba1c766 100644 > --- a/drivers/pci/hotplug/pciehp_ctrl.c > +++ b/drivers/pci/hotplug/pciehp_ctrl.c > @@ -260,7 +260,7 @@ void pciehp_handle_presence_or_link_change(struct controller *ctrl, u32 events) > /* Turn the slot on if it's occupied or link is up */ > mutex_lock(&ctrl->state_lock); > present = pciehp_card_present(ctrl); > - link_active = pciehp_check_link_active(ctrl); > + link_active = pcie_link_is_active(ctrl->pcie->port); > if (present <= 0 && link_active <= 0) { > if (ctrl->state == BLINKINGON_STATE) { > ctrl->state = OFF_STATE; > diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c > index 8a09fb6083e2..278bc21d531d 100644 > --- a/drivers/pci/hotplug/pciehp_hpc.c > +++ b/drivers/pci/hotplug/pciehp_hpc.c > @@ -221,33 +221,6 @@ static void pcie_write_cmd_nowait(struct controller *ctrl, u16 cmd, u16 mask) > pcie_do_write_cmd(ctrl, cmd, mask, false); > } > > -/** > - * pciehp_check_link_active() - Is the link active > - * @ctrl: PCIe hotplug controller > - * > - * Check whether the downstream link is currently active. Note it is > - * possible that the card is removed immediately after this so the > - * caller may need to take it into account. > - * > - * If the hotplug controller itself is not available anymore returns > - * %-ENODEV. > - */ > -int pciehp_check_link_active(struct controller *ctrl) > -{ > - struct pci_dev *pdev = ctrl_dev(ctrl); > - u16 lnk_status; > - int ret; > - > - ret = pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, &lnk_status); > - if (ret == PCIBIOS_DEVICE_NOT_FOUND || PCI_POSSIBLE_ERROR(lnk_status)) > - return -ENODEV; > - > - ret = !!(lnk_status & PCI_EXP_LNKSTA_DLLLA); > - ctrl_dbg(ctrl, "%s: lnk_status = %x\n", __func__, lnk_status); > - > - return ret; > -} > - > static bool pci_bus_check_dev(struct pci_bus *bus, int devfn) > { > u32 l; > @@ -467,7 +440,7 @@ int pciehp_card_present_or_link_active(struct controller *ctrl) > if (ret) > return ret; > > - return pciehp_check_link_active(ctrl); > + return pcie_link_is_active(ctrl_dev(ctrl)); > } > > int pciehp_query_power_fault(struct controller *ctrl) > @@ -584,7 +557,7 @@ static void pciehp_ignore_dpc_link_change(struct controller *ctrl, > * Synthesize it to ensure that it is acted on. > */ > down_read_nested(&ctrl->reset_lock, ctrl->depth); > - if (!pciehp_check_link_active(ctrl)) > + if (!pcie_link_is_active(ctrl_dev(ctrl))) > pciehp_request(ctrl, PCI_EXP_SLTSTA_DLLSC); > up_read(&ctrl->reset_lock); > } > @@ -884,7 +857,7 @@ int pciehp_slot_reset(struct pcie_device *dev) > pcie_capability_write_word(dev->port, PCI_EXP_SLTSTA, > PCI_EXP_SLTSTA_DLLSC); > > - if (!pciehp_check_link_active(ctrl)) > + if (!pcie_link_is_active(ctrl_dev(ctrl))) > pciehp_request(ctrl, PCI_EXP_SLTSTA_DLLSC); > > return 0; > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > index e77d5b53c0ce..3bb8354b14bf 100644 > --- a/drivers/pci/pci.c > +++ b/drivers/pci/pci.c > @@ -4926,7 +4926,6 @@ int pci_bridge_wait_for_secondary_bus(struct pci_dev *dev, char *reset_type) > return 0; > > if (pcie_get_speed_cap(dev) <= PCIE_SPEED_5_0GT) { > - u16 status; > > pci_dbg(dev, "waiting %d ms for downstream link\n", delay); > msleep(delay); > @@ -4942,8 +4941,7 @@ int pci_bridge_wait_for_secondary_bus(struct pci_dev *dev, char *reset_type) > if (!dev->link_active_reporting) > return -ENOTTY; > > - pcie_capability_read_word(dev, PCI_EXP_LNKSTA, &status); > - if (!(status & PCI_EXP_LNKSTA_DLLLA)) > + if (pcie_link_is_active(dev) <= 0) > return -ENOTTY; > > return pci_dev_wait(child, reset_type, > @@ -6247,6 +6245,28 @@ void pcie_print_link_status(struct pci_dev *dev) > } > EXPORT_SYMBOL(pcie_print_link_status); > > +/** > + * pcie_link_is_active() - Checks if the link is active or not > + * @pdev: PCI device to query > + * > + * Check whether the link is active or not. > + * > + * Return: link state, or -ENODEV if the config read failes. > + */ > +int pcie_link_is_active(struct pci_dev *pdev) > +{ > + u16 lnk_status; > + int ret; > + > + ret = pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, &lnk_status); > + if (ret == PCIBIOS_DEVICE_NOT_FOUND || PCI_POSSIBLE_ERROR(lnk_status)) > + return -ENODEV; > + > + pci_dbg(pdev, "lnk_status = %x\n", lnk_status); > + return !!(lnk_status & PCI_EXP_LNKSTA_DLLLA); > +} > +EXPORT_SYMBOL(pcie_link_is_active); > + > /** > * pci_select_bars - Make BAR mask from the type of resource > * @dev: the PCI device for which BAR mask is made > diff --git a/include/linux/pci.h b/include/linux/pci.h > index 51e2bd6405cd..a79a9919320c 100644 > --- a/include/linux/pci.h > +++ b/include/linux/pci.h > @@ -1945,6 +1945,7 @@ pci_release_mem_regions(struct pci_dev *pdev) > pci_select_bars(pdev, IORESOURCE_MEM)); > } > > +int pcie_link_is_active(struct pci_dev *dev); > #else /* CONFIG_PCI is not enabled */ > > static inline void pci_set_flags(int flags) { } > @@ -2093,6 +2094,9 @@ pci_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs, > { > return -ENOSPC; > } > + > +static inline bool pcie_link_is_active(struct pci_dev *dev) > +{ return false; } > #endif /* CONFIG_PCI */ > > /* Include architecture-dependent settings and functions */ > -- > 2.30.2 > > -- ---Trilok Soni ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2025-04-24 0:40 Cong Wang 2025-04-24 0:59 ` Jiayuan Chen 0 siblings, 1 reply; 1767+ messages in thread From: Cong Wang @ 2025-04-24 0:40 UTC (permalink / raw) To: jiayuan.chen; +Cc: john.fastabend, jakub, netdev, bpf netdev@vger.kernel.org, bpf@vger.kernel.org Bcc: Subject: test_sockmap failures on the latest bpf-next Reply-To: Hi all, The latest bpf-next failed on test_sockmap tests, I got the following failures (including 1 kernel warning). It is 100% reproducible here. I don't have time to look into them, a quick glance at the changelog shows quite some changes from Jiayuan. So please take a look, Jiayuan. Meanwhile, please let me know if you need more information from me. Thanks! ---------------> [root@localhost bpf]# ./test_sockmap # 1/ 6 sockmap::txmsg test passthrough:OK # 2/ 6 sockmap::txmsg test redirect:OK # 3/ 2 sockmap::txmsg test redirect wait send mem:OK # 4/ 6 sockmap::txmsg test drop:OK [ 182.498017] perf: interrupt took too long (3406 > 3238), lowering kernel.perf_event_max_sample_rate to 58500 # 5/ 6 sockmap::txmsg test ingress redirect:OK # 6/ 7 sockmap::txmsg test skb:OK # 7/12 sockmap::txmsg test apply:OK # 8/12 sockmap::txmsg test cork:OK # 9/ 3 sockmap::txmsg test hanging corks:OK #10/11 sockmap::txmsg test push_data:OK #11/17 sockmap::txmsg test pull-data:OK #12/ 9 sockmap::txmsg test pop-data:OK #13/ 6 sockmap::txmsg test push/pop data:OK #14/ 1 sockmap::txmsg test ingress parser:OK #15/ 1 sockmap::txmsg test ingress parser2:OK #16/ 6 sockhash::txmsg test passthrough:OK #17/ 6 sockhash::txmsg test redirect:OK #18/ 2 sockhash::txmsg test redirect wait send mem:OK #19/ 6 sockhash::txmsg test drop:OK #20/ 6 sockhash::txmsg test ingress redirect:OK #21/ 7 sockhash::txmsg test skb:OK #22/12 sockhash::txmsg test apply:OK #23/12 sockhash::txmsg test cork:OK #24/ 3 sockhash::txmsg test hanging corks:OK #25/11 sockhash::txmsg test push_data:OK #26/17 sockhash::txmsg test pull-data:OK #27/ 9 sockhash::txmsg test pop-data:OK #28/ 6 sockhash::txmsg test push/pop data:OK #29/ 1 sockhash::txmsg test ingress parser:OK #30/ 1 sockhash::txmsg test ingress parser2:OK #31/ 6 sockhash:ktls:txmsg test passthrough:OK #32/ 6 sockhash:ktls:txmsg test redirect:OK #33/ 2 sockhash:ktls:txmsg test redirect wait send mem:OK [ 263.509707] ------------[ cut here ]------------ [ 263.510439] WARNING: CPU: 1 PID: 40 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x173/0x1d5 [ 263.511450] CPU: 1 UID: 0 PID: 40 Comm: kworker/1:1 Tainted: G W 6.15.0-rc3+ #238 PREEMPT(voluntary) [ 263.512683] Tainted: [W]=WARN [ 263.513062] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 263.514763] Workqueue: events sk_psock_destroy [ 263.515332] RIP: 0010:inet_sock_destruct+0x173/0x1d5 [ 263.515916] Code: e8 dc dc 3f ff 41 83 bc 24 c0 02 00 00 00 74 02 0f 0b 49 8d bc 24 ac 02 00 00 e8 c2 dc 3f ff 41 83 bc 24 ac 02 00 00 00 74 02 <0f> 0b e8 c7 95 3d 00 49 8d bc 24 b0 05 00 00 e8 c0 dd 3f ff 49 8b [ 263.518899] RSP: 0018:ffff8880085cfc18 EFLAGS: 00010202 [ 263.519596] RAX: 1ffff11003dbfc00 RBX: ffff88801edfe3e8 RCX: ffffffff822f5af4 [ 263.520502] RDX: 0000000000000007 RSI: dffffc0000000000 RDI: ffff88801edfe16c [ 263.522128] RBP: ffff88801edfe184 R08: ffffed1003dbfc31 R09: 0000000000000000 [ 263.523008] R10: ffffffff822f5ab7 R11: ffff88801edfe187 R12: ffff88801edfdec0 [ 263.523822] R13: ffff888020376ac0 R14: ffff888020376ac0 R15: ffff888020376a60 [ 263.524682] FS: 0000000000000000(0000) GS:ffff8880b0e88000(0000) knlGS:0000000000000000 [ 263.525999] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 263.526765] CR2: 0000556365155830 CR3: 000000001d6aa000 CR4: 0000000000350ef0 [ 263.527700] Call Trace: [ 263.528037] <TASK> [ 263.528339] __sk_destruct+0x46/0x222 [ 263.528856] sk_psock_destroy+0x22f/0x242 [ 263.529471] process_one_work+0x504/0x8a8 [ 263.530029] ? process_one_work+0x39d/0x8a8 [ 263.530587] ? __pfx_process_one_work+0x10/0x10 [ 263.531195] ? worker_thread+0x44/0x2ae [ 263.531721] ? __list_add_valid_or_report+0x83/0xea [ 263.532395] ? srso_return_thunk+0x5/0x5f [ 263.532929] ? __list_add+0x45/0x52 [ 263.533482] process_scheduled_works+0x73/0x82 [ 263.534079] worker_thread+0x1ce/0x2ae [ 263.534582] ? _raw_spin_unlock_irqrestore+0x2e/0x44 [ 263.535243] ? __pfx_worker_thread+0x10/0x10 [ 263.535822] kthread+0x32a/0x33c [ 263.536278] ? kthread+0x13c/0x33c [ 263.536724] ? __pfx_kthread+0x10/0x10 [ 263.537225] ? srso_return_thunk+0x5/0x5f [ 263.537869] ? find_held_lock+0x2b/0x75 [ 263.538388] ? __pfx_kthread+0x10/0x10 [ 263.538866] ? srso_return_thunk+0x5/0x5f [ 263.539523] ? local_clock_noinstr+0x32/0x9c [ 263.540128] ? srso_return_thunk+0x5/0x5f [ 263.540677] ? srso_return_thunk+0x5/0x5f [ 263.541228] ? __lock_release+0xd3/0x1ad [ 263.541890] ? srso_return_thunk+0x5/0x5f [ 263.542442] ? tracer_hardirqs_on+0x17/0x149 [ 263.543047] ? _raw_spin_unlock_irq+0x24/0x39 [ 263.543589] ? __pfx_kthread+0x10/0x10 [ 263.544069] ? __pfx_kthread+0x10/0x10 [ 263.544543] ret_from_fork+0x21/0x41 [ 263.545000] ? __pfx_kthread+0x10/0x10 [ 263.545557] ret_from_fork_asm+0x1a/0x30 [ 263.546095] </TASK> [ 263.546374] irq event stamp: 1094079 [ 263.546798] hardirqs last enabled at (1094089): [<ffffffff813be0f6>] __up_console_sem+0x47/0x4e [ 263.547762] hardirqs last disabled at (1094098): [<ffffffff813be0d6>] __up_console_sem+0x27/0x4e [ 263.548817] softirqs last enabled at (1093692): [<ffffffff812f2906>] handle_softirqs+0x48c/0x4de [ 263.550127] softirqs last disabled at (1094117): [<ffffffff812f29b3>] __irq_exit_rcu+0x4b/0xc3 [ 263.551104] ---[ end trace 0000000000000000 ]--- #34/ 6 sockhash:ktls:txmsg test drop:OK #35/ 6 sockhash:ktls:txmsg test ingress redirect:OK #36/ 7 sockhash:ktls:txmsg test skb:OK #37/12 sockhash:ktls:txmsg test apply:OK [ 278.915147] perf: interrupt took too long (4331 > 4257), lowering kernel.perf_event_max_sample_rate to 46000 [ 282.974989] test_sockmap (1077) used greatest stack depth: 25072 bytes left #38/12 sockhash:ktls:txmsg test cork:OK #39/ 3 sockhash:ktls:txmsg test hanging corks:OK #40/11 sockhash:ktls:txmsg test push_data:OK #41/17 sockhash:ktls:txmsg test pull-data:OK recv failed(): Invalid argument rx thread exited with err 1. recv failed(): Invalid argument rx thread exited with err 1. recv failed(): Bad message rx thread exited with err 1. #42/ 9 sockhash:ktls:txmsg test pop-data:FAIL recv failed(): Bad message rx thread exited with err 1. recv failed(): Message too long rx thread exited with err 1. #43/ 6 sockhash:ktls:txmsg test push/pop data:FAIL #44/ 1 sockhash:ktls:txmsg test ingress parser:OK #45/ 0 sockhash:ktls:txmsg test ingress parser2:OK Pass: 43 Fail: 5 ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-04-24 0:40 Cong Wang @ 2025-04-24 0:59 ` Jiayuan Chen 2025-04-24 9:19 ` Re: Jiayuan Chen 0 siblings, 1 reply; 1767+ messages in thread From: Jiayuan Chen @ 2025-04-24 0:59 UTC (permalink / raw) To: Cong Wang; +Cc: john.fastabend, jakub, netdev, bpf April 24, 2025 at 08:40, "Cong Wang" <xiyou.wangcong@gmail.com> wrote: > > netdev@vger.kernel.org, bpf@vger.kernel.org > > Bcc: > > Subject: test_sockmap failures on the latest bpf-next > > Reply-To: > > Hi all, > > The latest bpf-next failed on test_sockmap tests, I got the following > > failures (including 1 kernel warning). It is 100% reproducible here. > > I don't have time to look into them, a quick glance at the changelog > > shows quite some changes from Jiayuan. So please take a look, Jiayuan. > > Meanwhile, please let me know if you need more information from me. > > Thanks! > > ---------------> Thanks, I'm working on it. > > [root@localhost bpf]# ./test_sockmap > > # 1/ 6 sockmap::txmsg test passthrough:OK > > # 2/ 6 sockmap::txmsg test redirect:OK > > # 3/ 2 sockmap::txmsg test redirect wait send mem:OK > > # 4/ 6 sockmap::txmsg test drop:OK > > [ 182.498017] perf: interrupt took too long (3406 > 3238), lowering kernel.perf_event_max_sample_rate to 58500 > > # 5/ 6 sockmap::txmsg test ingress redirect:OK > > # 6/ 7 sockmap::txmsg test skb:OK > > # 7/12 sockmap::txmsg test apply:OK > > # 8/12 sockmap::txmsg test cork:OK > > # 9/ 3 sockmap::txmsg test hanging corks:OK > > #10/11 sockmap::txmsg test push_data:OK > > #11/17 sockmap::txmsg test pull-data:OK > > #12/ 9 sockmap::txmsg test pop-data:OK > > #13/ 6 sockmap::txmsg test push/pop data:OK > > #14/ 1 sockmap::txmsg test ingress parser:OK > > #15/ 1 sockmap::txmsg test ingress parser2:OK > > #16/ 6 sockhash::txmsg test passthrough:OK > > #17/ 6 sockhash::txmsg test redirect:OK > > #18/ 2 sockhash::txmsg test redirect wait send mem:OK > > #19/ 6 sockhash::txmsg test drop:OK > > #20/ 6 sockhash::txmsg test ingress redirect:OK > > #21/ 7 sockhash::txmsg test skb:OK > > #22/12 sockhash::txmsg test apply:OK > > #23/12 sockhash::txmsg test cork:OK > > #24/ 3 sockhash::txmsg test hanging corks:OK > > #25/11 sockhash::txmsg test push_data:OK > > #26/17 sockhash::txmsg test pull-data:OK > > #27/ 9 sockhash::txmsg test pop-data:OK > > #28/ 6 sockhash::txmsg test push/pop data:OK > > #29/ 1 sockhash::txmsg test ingress parser:OK > > #30/ 1 sockhash::txmsg test ingress parser2:OK > > #31/ 6 sockhash:ktls:txmsg test passthrough:OK > > #32/ 6 sockhash:ktls:txmsg test redirect:OK > > #33/ 2 sockhash:ktls:txmsg test redirect wait send mem:OK > > [ 263.509707] ------------[ cut here ]------------ > > [ 263.510439] WARNING: CPU: 1 PID: 40 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x173/0x1d5 > > [ 263.511450] CPU: 1 UID: 0 PID: 40 Comm: kworker/1:1 Tainted: G W 6.15.0-rc3+ #238 PREEMPT(voluntary) > > [ 263.512683] Tainted: [W]=WARN > > [ 263.513062] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 > > [ 263.514763] Workqueue: events sk_psock_destroy > > [ 263.515332] RIP: 0010:inet_sock_destruct+0x173/0x1d5 > > [ 263.515916] Code: e8 dc dc 3f ff 41 83 bc 24 c0 02 00 00 00 74 02 0f 0b 49 8d bc 24 ac 02 00 00 e8 c2 dc 3f ff 41 83 bc 24 ac 02 00 00 00 74 02 <0f> 0b e8 c7 95 3d 00 49 8d bc 24 b0 05 00 00 e8 c0 dd 3f ff 49 8b > > [ 263.518899] RSP: 0018:ffff8880085cfc18 EFLAGS: 00010202 > > [ 263.519596] RAX: 1ffff11003dbfc00 RBX: ffff88801edfe3e8 RCX: ffffffff822f5af4 > > [ 263.520502] RDX: 0000000000000007 RSI: dffffc0000000000 RDI: ffff88801edfe16c > > [ 263.522128] RBP: ffff88801edfe184 R08: ffffed1003dbfc31 R09: 0000000000000000 > > [ 263.523008] R10: ffffffff822f5ab7 R11: ffff88801edfe187 R12: ffff88801edfdec0 > > [ 263.523822] R13: ffff888020376ac0 R14: ffff888020376ac0 R15: ffff888020376a60 > > [ 263.524682] FS: 0000000000000000(0000) GS:ffff8880b0e88000(0000) knlGS:0000000000000000 > > [ 263.525999] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > [ 263.526765] CR2: 0000556365155830 CR3: 000000001d6aa000 CR4: 0000000000350ef0 > > [ 263.527700] Call Trace: > > [ 263.528037] <TASK> > > [ 263.528339] __sk_destruct+0x46/0x222 > > [ 263.528856] sk_psock_destroy+0x22f/0x242 > > [ 263.529471] process_one_work+0x504/0x8a8 > > [ 263.530029] ? process_one_work+0x39d/0x8a8 > > [ 263.530587] ? __pfx_process_one_work+0x10/0x10 > > [ 263.531195] ? worker_thread+0x44/0x2ae > > [ 263.531721] ? __list_add_valid_or_report+0x83/0xea > > [ 263.532395] ? srso_return_thunk+0x5/0x5f > > [ 263.532929] ? __list_add+0x45/0x52 > > [ 263.533482] process_scheduled_works+0x73/0x82 > > [ 263.534079] worker_thread+0x1ce/0x2ae > > [ 263.534582] ? _raw_spin_unlock_irqrestore+0x2e/0x44 > > [ 263.535243] ? __pfx_worker_thread+0x10/0x10 > > [ 263.535822] kthread+0x32a/0x33c > > [ 263.536278] ? kthread+0x13c/0x33c > > [ 263.536724] ? __pfx_kthread+0x10/0x10 > > [ 263.537225] ? srso_return_thunk+0x5/0x5f > > [ 263.537869] ? find_held_lock+0x2b/0x75 > > [ 263.538388] ? __pfx_kthread+0x10/0x10 > > [ 263.538866] ? srso_return_thunk+0x5/0x5f > > [ 263.539523] ? local_clock_noinstr+0x32/0x9c > > [ 263.540128] ? srso_return_thunk+0x5/0x5f > > [ 263.540677] ? srso_return_thunk+0x5/0x5f > > [ 263.541228] ? __lock_release+0xd3/0x1ad > > [ 263.541890] ? srso_return_thunk+0x5/0x5f > > [ 263.542442] ? tracer_hardirqs_on+0x17/0x149 > > [ 263.543047] ? _raw_spin_unlock_irq+0x24/0x39 > > [ 263.543589] ? __pfx_kthread+0x10/0x10 > > [ 263.544069] ? __pfx_kthread+0x10/0x10 > > [ 263.544543] ret_from_fork+0x21/0x41 > > [ 263.545000] ? __pfx_kthread+0x10/0x10 > > [ 263.545557] ret_from_fork_asm+0x1a/0x30 > > [ 263.546095] </TASK> > > [ 263.546374] irq event stamp: 1094079 > > [ 263.546798] hardirqs last enabled at (1094089): [<ffffffff813be0f6>] __up_console_sem+0x47/0x4e > > [ 263.547762] hardirqs last disabled at (1094098): [<ffffffff813be0d6>] __up_console_sem+0x27/0x4e > > [ 263.548817] softirqs last enabled at (1093692): [<ffffffff812f2906>] handle_softirqs+0x48c/0x4de > > [ 263.550127] softirqs last disabled at (1094117): [<ffffffff812f29b3>] __irq_exit_rcu+0x4b/0xc3 > > [ 263.551104] ---[ end trace 0000000000000000 ]--- > > #34/ 6 sockhash:ktls:txmsg test drop:OK > > #35/ 6 sockhash:ktls:txmsg test ingress redirect:OK > > #36/ 7 sockhash:ktls:txmsg test skb:OK > > #37/12 sockhash:ktls:txmsg test apply:OK > > [ 278.915147] perf: interrupt took too long (4331 > 4257), lowering kernel.perf_event_max_sample_rate to 46000 > > [ 282.974989] test_sockmap (1077) used greatest stack depth: 25072 bytes left > > #38/12 sockhash:ktls:txmsg test cork:OK > > #39/ 3 sockhash:ktls:txmsg test hanging corks:OK > > #40/11 sockhash:ktls:txmsg test push_data:OK > > #41/17 sockhash:ktls:txmsg test pull-data:OK > > recv failed(): Invalid argument > > rx thread exited with err 1. > > recv failed(): Invalid argument > > rx thread exited with err 1. > > recv failed(): Bad message > > rx thread exited with err 1. > > #42/ 9 sockhash:ktls:txmsg test pop-data:FAIL > > recv failed(): Bad message > > rx thread exited with err 1. > > recv failed(): Message too long > > rx thread exited with err 1. > > #43/ 6 sockhash:ktls:txmsg test push/pop data:FAIL > > #44/ 1 sockhash:ktls:txmsg test ingress parser:OK > > #45/ 0 sockhash:ktls:txmsg test ingress parser2:OK > > Pass: 43 Fail: 5 > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-04-24 0:59 ` Jiayuan Chen @ 2025-04-24 9:19 ` Jiayuan Chen 0 siblings, 0 replies; 1767+ messages in thread From: Jiayuan Chen @ 2025-04-24 9:19 UTC (permalink / raw) To: Cong Wang; +Cc: john.fastabend, jakub, netdev, bpf April 24, 2025 at 08:59, "Jiayuan Chen" <jiayuan.chen@linux.dev> wrote: > > April 24, 2025 at 08:40, "Cong Wang" <xiyou.wangcong@gmail.com> wrote: > > > > > netdev@vger.kernel.org, bpf@vger.kernel.org > > > > Bcc: > > > > > > Subject: test_sockmap failures on the latest bpf-next > > > > Reply-To: > > > > > > > > Hi all, > > > > > > > > The latest bpf-next failed on test_sockmap tests, I got the following > > > > failures (including 1 kernel warning). It is 100% reproducible here. > > > > I don't have time to look into them, a quick glance at the changelog > > > > shows quite some changes from Jiayuan. So please take a look, Jiayuan. > > > > Meanwhile, please let me know if you need more information from me. > > > > Thanks! > > > > > > > > ---------------> > > > > Thanks, I'm working on it. > After resetting my commit to 0bb2f7a1ad1f, which is before my changes, the warning still exists. The warning originates from test_txmsg_redir_wait_sndmem(), which performs 'KTLS + sockmap with redir EGRESS and limited receive buffer'. The memory charge/uncharge logic is problematic, I need some time to investigate and fix it. Thanks. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH bpf-next] bpf: Remove bpf_get_smp_processor_id_proto
@ 2025-04-22 1:53 Alexei Starovoitov
2025-04-22 8:04 ` Feng Yang
0 siblings, 1 reply; 1767+ messages in thread
From: Alexei Starovoitov @ 2025-04-22 1:53 UTC (permalink / raw)
To: Feng Yang
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard, Song Liu, Yonghong Song, bpf, LKML,
linux-trace-kernel, Network Development, Feng Yang
On Thu, Apr 17, 2025 at 8:41 PM Feng Yang <yangfeng59949@163.com> wrote:
>
> From: Feng Yang <yangfeng@kylinos.cn>
>
> All BPF programs either disable CPU preemption or CPU migration,
> so the bpf_get_smp_processor_id_proto can be safely removed,
> and the bpf_get_raw_smp_processor_id_proto in bpf_base_func_proto works perfectly.
>
> Suggested-by: Andrii Nakryiko <andrii.nakryiko@gmail.com>
> Signed-off-by: Feng Yang <yangfeng@kylinos.cn>
> ---
> include/linux/bpf.h | 1 -
> kernel/bpf/core.c | 1 -
> kernel/bpf/helpers.c | 12 ------------
> kernel/trace/bpf_trace.c | 2 --
> net/core/filter.c | 6 ------
> 5 files changed, 22 deletions(-)
>
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 3f0cc89c0622..36e525141556 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -3316,7 +3316,6 @@ extern const struct bpf_func_proto bpf_map_peek_elem_proto;
> extern const struct bpf_func_proto bpf_map_lookup_percpu_elem_proto;
>
> extern const struct bpf_func_proto bpf_get_prandom_u32_proto;
> -extern const struct bpf_func_proto bpf_get_smp_processor_id_proto;
> extern const struct bpf_func_proto bpf_get_numa_node_id_proto;
> extern const struct bpf_func_proto bpf_tail_call_proto;
> extern const struct bpf_func_proto bpf_ktime_get_ns_proto;
> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index ba6b6118cf50..1ad41a16b86e 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -2943,7 +2943,6 @@ const struct bpf_func_proto bpf_spin_unlock_proto __weak;
> const struct bpf_func_proto bpf_jiffies64_proto __weak;
>
> const struct bpf_func_proto bpf_get_prandom_u32_proto __weak;
> -const struct bpf_func_proto bpf_get_smp_processor_id_proto __weak;
> const struct bpf_func_proto bpf_get_numa_node_id_proto __weak;
> const struct bpf_func_proto bpf_ktime_get_ns_proto __weak;
> const struct bpf_func_proto bpf_ktime_get_boot_ns_proto __weak;
> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index e3a2662f4e33..2d2bfb2911f8 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -149,18 +149,6 @@ const struct bpf_func_proto bpf_get_prandom_u32_proto = {
> .ret_type = RET_INTEGER,
> };
>
> -BPF_CALL_0(bpf_get_smp_processor_id)
> -{
> - return smp_processor_id();
> -}
> -
> -const struct bpf_func_proto bpf_get_smp_processor_id_proto = {
> - .func = bpf_get_smp_processor_id,
> - .gpl_only = false,
> - .ret_type = RET_INTEGER,
> - .allow_fastcall = true,
> -};
> -
bpf_get_raw_smp_processor_id_proto doesn't have
allow_fastcall = true
so this breaks tests.
Instead of removing BPF_CALL_0(bpf_get_smp_processor_id)
we should probably remove BPF_CALL_0(bpf_get_raw_cpu_id)
and adjust SKF_AD_OFF + SKF_AD_CPU case.
I don't recall why raw_ version was used back in 2014.
pw-bot: cr
^ permalink raw reply [flat|nested] 1767+ messages in thread* (no subject) 2025-04-22 1:53 [PATCH bpf-next] bpf: Remove bpf_get_smp_processor_id_proto Alexei Starovoitov @ 2025-04-22 8:04 ` Feng Yang 2025-04-22 14:37 ` Alexei Starovoitov 0 siblings, 1 reply; 1767+ messages in thread From: Feng Yang @ 2025-04-22 8:04 UTC (permalink / raw) To: alexei.starovoitov Cc: andrii, ast, bpf, daniel, eddyz87, linux-kernel, linux-trace-kernel, martin.lau, netdev, song, yangfeng59949, yangfeng, yonghong.song Subject: Re: [PATCH bpf-next] bpf: Remove bpf_get_smp_processor_id_proto On Mon, 21 Apr 2025 18:53:07 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > On Thu, Apr 17, 2025 at 8:41 PM Feng Yang <yangfeng59949@163.com> wrote: > > > > From: Feng Yang <yangfeng@kylinos.cn> > > > > All BPF programs either disable CPU preemption or CPU migration, > > so the bpf_get_smp_processor_id_proto can be safely removed, > > and the bpf_get_raw_smp_processor_id_proto in bpf_base_func_proto works perfectly. > > > > Suggested-by: Andrii Nakryiko <andrii.nakryiko@gmail.com> > > Signed-off-by: Feng Yang <yangfeng@kylinos.cn> > > --- > > include/linux/bpf.h | 1 - > > kernel/bpf/core.c | 1 - > > kernel/bpf/helpers.c | 12 ------------ > > kernel/trace/bpf_trace.c | 2 -- > > net/core/filter.c | 6 ------ > > 5 files changed, 22 deletions(-) > > > > diff --git a/include/linux/bpf.h b/include/linux/bpf.h > > index 3f0cc89c0622..36e525141556 100644 > > --- a/include/linux/bpf.h > > +++ b/include/linux/bpf.h > > @@ -3316,7 +3316,6 @@ extern const struct bpf_func_proto bpf_map_peek_elem_proto; > > extern const struct bpf_func_proto bpf_map_lookup_percpu_elem_proto; > > > > extern const struct bpf_func_proto bpf_get_prandom_u32_proto; > > -extern const struct bpf_func_proto bpf_get_smp_processor_id_proto; > > extern const struct bpf_func_proto bpf_get_numa_node_id_proto; > > extern const struct bpf_func_proto bpf_tail_call_proto; > > extern const struct bpf_func_proto bpf_ktime_get_ns_proto; > > diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c > > index ba6b6118cf50..1ad41a16b86e 100644 > > --- a/kernel/bpf/core.c > > +++ b/kernel/bpf/core.c > > @@ -2943,7 +2943,6 @@ const struct bpf_func_proto bpf_spin_unlock_proto __weak; > > const struct bpf_func_proto bpf_jiffies64_proto __weak; > > > > const struct bpf_func_proto bpf_get_prandom_u32_proto __weak; > > -const struct bpf_func_proto bpf_get_smp_processor_id_proto __weak; > > const struct bpf_func_proto bpf_get_numa_node_id_proto __weak; > > const struct bpf_func_proto bpf_ktime_get_ns_proto __weak; > > const struct bpf_func_proto bpf_ktime_get_boot_ns_proto __weak; > > diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c > > index e3a2662f4e33..2d2bfb2911f8 100644 > > --- a/kernel/bpf/helpers.c > > +++ b/kernel/bpf/helpers.c > > @@ -149,18 +149,6 @@ const struct bpf_func_proto bpf_get_prandom_u32_proto = { > > .ret_type = RET_INTEGER, > > }; > > > > -BPF_CALL_0(bpf_get_smp_processor_id) > > -{ > > - return smp_processor_id(); > > -} > > - > > -const struct bpf_func_proto bpf_get_smp_processor_id_proto = { > > - .func = bpf_get_smp_processor_id, > > - .gpl_only = false, > > - .ret_type = RET_INTEGER, > > - .allow_fastcall = true, > > -}; > > - > > bpf_get_raw_smp_processor_id_proto doesn't have > allow_fastcall = true > > so this breaks tests. > > Instead of removing BPF_CALL_0(bpf_get_smp_processor_id) > we should probably remove BPF_CALL_0(bpf_get_raw_cpu_id) > and adjust SKF_AD_OFF + SKF_AD_CPU case. > I don't recall why raw_ version was used back in 2014. > The following two seem to explain the reason: https://lore.kernel.org/all/7103e2085afa29c006cd5b94a6e4a2ac83efc30d.1467106475.git.daniel@iogearbox.net/ https://lore.kernel.org/all/02fa71ebe1c560cad489967aa29c653b48932596.1474586162.git.daniel@iogearbox.net/ ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-04-22 8:04 ` Feng Yang @ 2025-04-22 14:37 ` Alexei Starovoitov 0 siblings, 0 replies; 1767+ messages in thread From: Alexei Starovoitov @ 2025-04-22 14:37 UTC (permalink / raw) To: Feng Yang Cc: Andrii Nakryiko, Alexei Starovoitov, bpf, Daniel Borkmann, Eduard, LKML, linux-trace-kernel, Martin KaFai Lau, Network Development, Song Liu, Feng Yang, Yonghong Song On Tue, Apr 22, 2025 at 1:04 AM Feng Yang <yangfeng59949@163.com> wrote: > > Subject: Re: [PATCH bpf-next] bpf: Remove bpf_get_smp_processor_id_proto > > On Mon, 21 Apr 2025 18:53:07 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > > > On Thu, Apr 17, 2025 at 8:41 PM Feng Yang <yangfeng59949@163.com> wrote: > > > > > > From: Feng Yang <yangfeng@kylinos.cn> > > > > > > All BPF programs either disable CPU preemption or CPU migration, > > > so the bpf_get_smp_processor_id_proto can be safely removed, > > > and the bpf_get_raw_smp_processor_id_proto in bpf_base_func_proto works perfectly. > > > > > > Suggested-by: Andrii Nakryiko <andrii.nakryiko@gmail.com> > > > Signed-off-by: Feng Yang <yangfeng@kylinos.cn> > > > --- > > > include/linux/bpf.h | 1 - > > > kernel/bpf/core.c | 1 - > > > kernel/bpf/helpers.c | 12 ------------ > > > kernel/trace/bpf_trace.c | 2 -- > > > net/core/filter.c | 6 ------ > > > 5 files changed, 22 deletions(-) > > > > > > diff --git a/include/linux/bpf.h b/include/linux/bpf.h > > > index 3f0cc89c0622..36e525141556 100644 > > > --- a/include/linux/bpf.h > > > +++ b/include/linux/bpf.h > > > @@ -3316,7 +3316,6 @@ extern const struct bpf_func_proto bpf_map_peek_elem_proto; > > > extern const struct bpf_func_proto bpf_map_lookup_percpu_elem_proto; > > > > > > extern const struct bpf_func_proto bpf_get_prandom_u32_proto; > > > -extern const struct bpf_func_proto bpf_get_smp_processor_id_proto; > > > extern const struct bpf_func_proto bpf_get_numa_node_id_proto; > > > extern const struct bpf_func_proto bpf_tail_call_proto; > > > extern const struct bpf_func_proto bpf_ktime_get_ns_proto; > > > diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c > > > index ba6b6118cf50..1ad41a16b86e 100644 > > > --- a/kernel/bpf/core.c > > > +++ b/kernel/bpf/core.c > > > @@ -2943,7 +2943,6 @@ const struct bpf_func_proto bpf_spin_unlock_proto __weak; > > > const struct bpf_func_proto bpf_jiffies64_proto __weak; > > > > > > const struct bpf_func_proto bpf_get_prandom_u32_proto __weak; > > > -const struct bpf_func_proto bpf_get_smp_processor_id_proto __weak; > > > const struct bpf_func_proto bpf_get_numa_node_id_proto __weak; > > > const struct bpf_func_proto bpf_ktime_get_ns_proto __weak; > > > const struct bpf_func_proto bpf_ktime_get_boot_ns_proto __weak; > > > diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c > > > index e3a2662f4e33..2d2bfb2911f8 100644 > > > --- a/kernel/bpf/helpers.c > > > +++ b/kernel/bpf/helpers.c > > > @@ -149,18 +149,6 @@ const struct bpf_func_proto bpf_get_prandom_u32_proto = { > > > .ret_type = RET_INTEGER, > > > }; > > > > > > -BPF_CALL_0(bpf_get_smp_processor_id) > > > -{ > > > - return smp_processor_id(); > > > -} > > > - > > > -const struct bpf_func_proto bpf_get_smp_processor_id_proto = { > > > - .func = bpf_get_smp_processor_id, > > > - .gpl_only = false, > > > - .ret_type = RET_INTEGER, > > > - .allow_fastcall = true, > > > -}; > > > - > > > > bpf_get_raw_smp_processor_id_proto doesn't have > > allow_fastcall = true > > > > so this breaks tests. > > > > Instead of removing BPF_CALL_0(bpf_get_smp_processor_id) > > we should probably remove BPF_CALL_0(bpf_get_raw_cpu_id) > > and adjust SKF_AD_OFF + SKF_AD_CPU case. > > I don't recall why raw_ version was used back in 2014. > > > > The following two seem to explain the reason: > https://lore.kernel.org/all/7103e2085afa29c006cd5b94a6e4a2ac83efc30d.1467106475.git.daniel@iogearbox.net/ > https://lore.kernel.org/all/02fa71ebe1c560cad489967aa29c653b48932596.1474586162.git.daniel@iogearbox.net/ > Ahh. socket filters run in RCU CS. They don't disable preemption or migration. Then let's keep things as-is. We still want debugging provided by smp_processor_id(). If we switch everything to raw_ may miss things. Like this example with socket filters. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2025-04-18 7:46 Shung-Hsi Yu 2025-04-18 7:49 ` Shung-Hsi Yu 2025-04-23 17:30 ` Re: patchwork-bot+netdevbpf 0 siblings, 2 replies; 1767+ messages in thread From: Shung-Hsi Yu @ 2025-04-18 7:46 UTC (permalink / raw) To: bpf Cc: Martin KaFai Lau, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Kumar Kartikeya Dwivedi, Dan Carpenter, Shung-Hsi Yu From bda8bb8011d865cebf066350c8625e8be1625656 Mon Sep 17 00:00:00 2001 From: Shung-Hsi Yu <shung-hsi.yu@suse.com> Date: Fri, 18 Apr 2025 15:22:00 +0800 Subject: [PATCH bpf-next 1/1] bpf: use proper type to calculate bpf_raw_tp_null_args.mask index The calculation of the index used to access the mask field in 'struct bpf_raw_tp_null_args' is done with 'int' type, which could overflow when the tracepoint being attached has more than 8 arguments. While none of the tracepoints mentioned in raw_tp_null_args[] currently have more than 8 arguments, there do exist tracepoints that had more than 8 arguments (e.g. iocost_iocg_forgive_debt), so use the correct type for calculation and avoid Smatch static checker warning. Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/843a3b94-d53d-42db-93d4-be10a4090146@stanley.mountain/ Signed-off-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> --- kernel/bpf/btf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c index 16ba36f34dfa..656ee11aff67 100644 --- a/kernel/bpf/btf.c +++ b/kernel/bpf/btf.c @@ -6829,10 +6829,10 @@ bool btf_ctx_access(int off, int size, enum bpf_access_type type, /* Is this a func with potential NULL args? */ if (strcmp(tname, raw_tp_null_args[i].func)) continue; - if (raw_tp_null_args[i].mask & (0x1 << (arg * 4))) + if (raw_tp_null_args[i].mask & (0x1ULL << (arg * 4))) info->reg_type |= PTR_MAYBE_NULL; /* Is the current arg IS_ERR? */ - if (raw_tp_null_args[i].mask & (0x2 << (arg * 4))) + if (raw_tp_null_args[i].mask & (0x2ULL << (arg * 4))) ptr_err_raw_tp = true; break; } -- 2.49.0 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2025-04-18 7:46 Shung-Hsi Yu @ 2025-04-18 7:49 ` Shung-Hsi Yu 2025-04-23 17:30 ` Re: patchwork-bot+netdevbpf 1 sibling, 0 replies; 1767+ messages in thread From: Shung-Hsi Yu @ 2025-04-18 7:49 UTC (permalink / raw) To: bpf Cc: Martin KaFai Lau, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Kumar Kartikeya Dwivedi, Dan Carpenter On Fri, Apr 18, 2025 at 3:46 PM Shung-Hsi Yu <shung-hsi.yu@suse.com> wrote: > From bda8bb8011d865cebf066350c8625e8be1625656 Mon Sep 17 00:00:00 2001 > From: Shung-Hsi Yu <shung-hsi.yu@suse.com> > Date: Fri, 18 Apr 2025 15:22:00 +0800 > Subject: [PATCH bpf-next 1/1] bpf: use proper type to calculate > bpf_raw_tp_null_args.mask index ... Email headers are off, hence no subject. WIll resend. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-04-18 7:46 Shung-Hsi Yu 2025-04-18 7:49 ` Shung-Hsi Yu @ 2025-04-23 17:30 ` patchwork-bot+netdevbpf 1 sibling, 0 replies; 1767+ messages in thread From: patchwork-bot+netdevbpf @ 2025-04-23 17:30 UTC (permalink / raw) To: Shung-Hsi Yu Cc: bpf, martin.lau, ast, daniel, andrii, eddyz87, song, yonghong.song, john.fastabend, kpsingh, sdf, haoluo, jolsa, memxor, dan.carpenter Hello: This patch was applied to bpf/bpf-next.git (master) by Andrii Nakryiko <andrii@kernel.org>: On Fri, 18 Apr 2025 15:46:31 +0800 you wrote: > >From bda8bb8011d865cebf066350c8625e8be1625656 Mon Sep 17 00:00:00 2001 > From: Shung-Hsi Yu <shung-hsi.yu@suse.com> > Date: Fri, 18 Apr 2025 15:22:00 +0800 > Subject: [PATCH bpf-next 1/1] bpf: use proper type to calculate > bpf_raw_tp_null_args.mask index > > The calculation of the index used to access the mask field in 'struct > bpf_raw_tp_null_args' is done with 'int' type, which could overflow when > the tracepoint being attached has more than 8 arguments. > > [...] Here is the summary with links: - https://git.kernel.org/bpf/bpf-next/c/53ebef53a657 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2025-01-08 13:59 Jiang Liu
2025-01-08 14:10 ` Christian König
2025-01-08 16:33 ` Re: Mario Limonciello
0 siblings, 2 replies; 1767+ messages in thread
From: Jiang Liu @ 2025-01-08 13:59 UTC (permalink / raw)
To: alexander.deucher, christian.koenig, Xinhui.Pan, airlied, simona,
sunil.khatri, lijo.lazar, Hawking.Zhang, mario.limonciello,
Jun.Ma2, xiaogang.chen, Kent.Russell, shuox.liu, amd-gfx
Cc: Jiang Liu
Subject: [RFC PATCH 00/13] Enhance device state machine to better support suspend/resume
Recently we were testing suspend/resume functionality with AMD GPUs,
we have encountered several resource tracking related bugs, such as
double buffer free, use after free and unbalanced irq reference count.
We have tried to solve these issues case by case, but found that may
not be the right way. Especially about the unbalanced irq reference
count, there will be new issues appear once we fixed the current known
issues. After analyzing related source code, we found that there may be
some fundamental implementaion flaws behind these resource tracking
issues.
The amdgpu driver has two major state machines to driver the device
management flow, one is for ip blocks, the other is for ras blocks.
The hook points defined in struct amd_ip_funcs for device setup/teardown
are symmetric, but the implementation is asymmetric, sometime even
ambiguous. The most obvious two issues we noticed are:
1) amdgpu_irq_get() are called from .late_init() but amdgpu_irq_put()
are called from .hw_fini() instead of .early_fini().
2) the way to reset ip_bloc.status.valid/sw/hw/late_initialized doesn't
match the way to set those flags.
When taking device suspend/resume into account, in addition to device
probe/remove, things get much more complex. Some issues arise because
many suspend/resume implementations directly reuse .hw_init/.hw_fini/
.late_init hook points.
So we try to fix those issues by two enhancements/refinements to current
device management state machines.
The first change is to make the ip block state machine and associated
status flags work in stack-like way as below:
Callback Status Flags
early_init: valid = true
sw_init: sw = true
hw_init: hw = true
late_init: late_initialized = true
early_fini: late_initialized = false
hw_fini: hw = false
sw_fini: sw = false
late_fini: valid = false
Also do the same thing for ras block state machine, though it's much
more simpler.
The second change is fine tune the overall device management work
flow as below:
1. amdgpu_driver_load_kms()
amdgpu_device_init()
amdgpu_device_ip_early_init()
ip_blocks[i].early_init()
ip_blocks[i].status.valid = true
amdgpu_device_ip_init()
amdgpu_ras_init()
ip_blocks[i].sw_init()
ip_blocks[i].status.sw = true
ip_blocks[i].hw_init()
ip_blocks[i].status.hw = true
amdgpu_device_ip_late_init()
ip_blocks[i].late_init()
ip_blocks[i].status.late_initialized = true
amdgpu_ras_late_init()
ras_blocks[i].ras_late_init()
amdgpu_ras_feature_enable_on_boot()
2. amdgpu_pmops_suspend()/amdgpu_pmops_freeze()/amdgpu_pmops_poweroff()
amdgpu_device_suspend()
amdgpu_ras_early_fini()
ras_blocks[i].ras_early_fini()
amdgpu_ras_feature_disable()
amdgpu_ras_suspend()
amdgpu_ras_disable_all_features()
+++ ip_blocks[i].early_fini()
+++ ip_blocks[i].status.late_initialized = false
ip_blocks[i].suspend()
3. amdgpu_pmops_resume()/amdgpu_pmops_thaw()/amdgpu_pmops_restore()
amdgpu_device_resume()
amdgpu_device_ip_resume()
ip_blocks[i].resume()
amdgpu_device_ip_late_init()
ip_blocks[i].late_init()
ip_blocks[i].status.late_initialized = true
amdgpu_ras_late_init()
ras_blocks[i].ras_late_init()
amdgpu_ras_feature_enable_on_boot()
amdgpu_ras_resume()
amdgpu_ras_enable_all_features()
4. amdgpu_driver_unload_kms()
amdgpu_device_fini_hw()
amdgpu_ras_early_fini()
ras_blocks[i].ras_early_fini()
+++ ip_blocks[i].early_fini()
+++ ip_blocks[i].status.late_initialized = false
ip_blocks[i].hw_fini()
ip_blocks[i].status.hw = false
5. amdgpu_driver_release_kms()
amdgpu_device_fini_sw()
amdgpu_device_ip_fini()
ip_blocks[i].sw_fini()
ip_blocks[i].status.sw = false
--- ip_blocks[i].status.valid = false
+++ amdgpu_ras_fini()
ip_blocks[i].late_fini()
+++ ip_blocks[i].status.valid = false
--- ip_blocks[i].status.late_initialized = false
--- amdgpu_ras_fini()
The main changes include:
1) invoke ip_blocks[i].early_fini in amdgpu_pmops_suspend().
Currently there's only one ip block which provides `early_fini`
callback. We have add a check of `in_s3` to keep current behavior in
function amdgpu_dm_early_fini(). So there should be no functional
changes.
2) set ip_blocks[i].status.late_initialized to false after calling
callback `early_fini`. We have auditted all usages of the
late_initialized flag and no functional changes found.
3) only set ip_blocks[i].status.valid = false after calling the
`late_fini` callback.
4) call amdgpu_ras_fini() before invoking ip_blocks[i].late_fini.
Then we try to refine each subsystem, such as nbio, asic, gfx, gmc,
ras etc, to follow the new design. Currently we have only taken the
nbio and asic as examples to show the proposed changes. Once we have
confirmed that's the right way to go, we will handle the lefting
subsystems.
This is in early stage and requesting for comments, any comments and
suggestions are welcomed!
Jiang Liu (13):
amdgpu: wrong array index to get ip block for PSP
drm/admgpu: add helper functions to track status for ras manager
drm/amdgpu: add a flag to track ras debugfs creation status
drm/amdgpu: free all resources on error recovery path of
amdgpu_ras_init()
drm/amdgpu: introduce a flag to track refcount held for features
drm/amdgpu: enhance amdgpu_ras_block_late_fini()
drm/amdgpu: enhance amdgpu_ras_pre_fini() to better support SR
drm/admgpu: rename amdgpu_ras_pre_fini() to amdgpu_ras_early_fini()
drm/amdgpu: make IP block state machine works in stack like way
drm/admgpu: make device state machine work in stack like way
drm/amdgpu/sdma: improve the way to manage irq reference count
drm/amdgpu/nbio: improve the way to manage irq reference count
drm/amdgpu/asic: make ip block operations symmetric by .early_fini()
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 40 +++++
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 37 ++++-
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.c | 16 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 8 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 144 +++++++++++++-----
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h | 16 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c | 26 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h | 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_umc.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c | 2 +-
drivers/gpu/drm/amd/amdgpu/mmhub_v1_8.c | 2 +-
drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c | 1 +
drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c | 1 +
drivers/gpu/drm/amd/amdgpu/nv.c | 14 +-
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 8 -
drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c | 23 +--
drivers/gpu/drm/amd/amdgpu/soc15.c | 38 ++---
drivers/gpu/drm/amd/amdgpu/soc21.c | 35 +++--
drivers/gpu/drm/amd/amdgpu/soc24.c | 17 ++-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +
25 files changed, 326 insertions(+), 118 deletions(-)
--
2.43.5
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2025-01-08 13:59 Jiang Liu @ 2025-01-08 14:10 ` Christian König 2025-01-08 16:33 ` Re: Mario Limonciello 1 sibling, 0 replies; 1767+ messages in thread From: Christian König @ 2025-01-08 14:10 UTC (permalink / raw) To: Jiang Liu, alexander.deucher, Xinhui.Pan, airlied, simona, sunil.khatri, lijo.lazar, Hawking.Zhang, mario.limonciello, Jun.Ma2, xiaogang.chen, Kent.Russell, shuox.liu, amd-gfx Am 08.01.25 um 14:59 schrieb Jiang Liu: > Subject: [RFC PATCH 00/13] Enhance device state machine to better support suspend/resume > > Recently we were testing suspend/resume functionality with AMD GPUs, > we have encountered several resource tracking related bugs, such as > double buffer free, use after free and unbalanced irq reference count. > > We have tried to solve these issues case by case, but found that may > not be the right way. Especially about the unbalanced irq reference > count, there will be new issues appear once we fixed the current known > issues. After analyzing related source code, we found that there may be > some fundamental implementaion flaws behind these resource tracking > issues. In general please run your patches through checkpatch.pl. There are quite a number of style issues with those code changes. > > The amdgpu driver has two major state machines to driver the device > management flow, one is for ip blocks, the other is for ras blocks. > The hook points defined in struct amd_ip_funcs for device setup/teardown > are symmetric, but the implementation is asymmetric, sometime even > ambiguous. The most obvious two issues we noticed are: > 1) amdgpu_irq_get() are called from .late_init() but amdgpu_irq_put() > are called from .hw_fini() instead of .early_fini(). Yes and if I remember correctly that is absolutely intentional. IRQs can't be enabled unless all IP blocks are up and running because otherwise the IRQ handler sometimes doesn't have the necessary functionality at hand. But for HW fini we only disable IRQs before we actually tear down the HW state because we need them for operation feedback. E.g. for example ring buffer completion interrupts for tear down commands. Regards, Christian. > 2) the way to reset ip_bloc.status.valid/sw/hw/late_initialized doesn't > match the way to set those flags. > > When taking device suspend/resume into account, in addition to device > probe/remove, things get much more complex. Some issues arise because > many suspend/resume implementations directly reuse .hw_init/.hw_fini/ > .late_init hook points. > > So we try to fix those issues by two enhancements/refinements to current > device management state machines. > > The first change is to make the ip block state machine and associated > status flags work in stack-like way as below: > Callback Status Flags > early_init: valid = true > sw_init: sw = true > hw_init: hw = true > late_init: late_initialized = true > early_fini: late_initialized = false > hw_fini: hw = false > sw_fini: sw = false > late_fini: valid = false > > Also do the same thing for ras block state machine, though it's much > more simpler. > > The second change is fine tune the overall device management work > flow as below: > 1. amdgpu_driver_load_kms() > amdgpu_device_init() > amdgpu_device_ip_early_init() > ip_blocks[i].early_init() > ip_blocks[i].status.valid = true > amdgpu_device_ip_init() > amdgpu_ras_init() > ip_blocks[i].sw_init() > ip_blocks[i].status.sw = true > ip_blocks[i].hw_init() > ip_blocks[i].status.hw = true > amdgpu_device_ip_late_init() > ip_blocks[i].late_init() > ip_blocks[i].status.late_initialized = true > amdgpu_ras_late_init() > ras_blocks[i].ras_late_init() > amdgpu_ras_feature_enable_on_boot() > > 2. amdgpu_pmops_suspend()/amdgpu_pmops_freeze()/amdgpu_pmops_poweroff() > amdgpu_device_suspend() > amdgpu_ras_early_fini() > ras_blocks[i].ras_early_fini() > amdgpu_ras_feature_disable() > amdgpu_ras_suspend() > amdgpu_ras_disable_all_features() > +++ ip_blocks[i].early_fini() > +++ ip_blocks[i].status.late_initialized = false > ip_blocks[i].suspend() > > 3. amdgpu_pmops_resume()/amdgpu_pmops_thaw()/amdgpu_pmops_restore() > amdgpu_device_resume() > amdgpu_device_ip_resume() > ip_blocks[i].resume() > amdgpu_device_ip_late_init() > ip_blocks[i].late_init() > ip_blocks[i].status.late_initialized = true > amdgpu_ras_late_init() > ras_blocks[i].ras_late_init() > amdgpu_ras_feature_enable_on_boot() > amdgpu_ras_resume() > amdgpu_ras_enable_all_features() > > 4. amdgpu_driver_unload_kms() > amdgpu_device_fini_hw() > amdgpu_ras_early_fini() > ras_blocks[i].ras_early_fini() > +++ ip_blocks[i].early_fini() > +++ ip_blocks[i].status.late_initialized = false > ip_blocks[i].hw_fini() > ip_blocks[i].status.hw = false > > 5. amdgpu_driver_release_kms() > amdgpu_device_fini_sw() > amdgpu_device_ip_fini() > ip_blocks[i].sw_fini() > ip_blocks[i].status.sw = false > --- ip_blocks[i].status.valid = false > +++ amdgpu_ras_fini() > ip_blocks[i].late_fini() > +++ ip_blocks[i].status.valid = false > --- ip_blocks[i].status.late_initialized = false > --- amdgpu_ras_fini() > > The main changes include: > 1) invoke ip_blocks[i].early_fini in amdgpu_pmops_suspend(). > Currently there's only one ip block which provides `early_fini` > callback. We have add a check of `in_s3` to keep current behavior in > function amdgpu_dm_early_fini(). So there should be no functional > changes. > 2) set ip_blocks[i].status.late_initialized to false after calling > callback `early_fini`. We have auditted all usages of the > late_initialized flag and no functional changes found. > 3) only set ip_blocks[i].status.valid = false after calling the > `late_fini` callback. > 4) call amdgpu_ras_fini() before invoking ip_blocks[i].late_fini. > > Then we try to refine each subsystem, such as nbio, asic, gfx, gmc, > ras etc, to follow the new design. Currently we have only taken the > nbio and asic as examples to show the proposed changes. Once we have > confirmed that's the right way to go, we will handle the lefting > subsystems. > > This is in early stage and requesting for comments, any comments and > suggestions are welcomed! > Jiang Liu (13): > amdgpu: wrong array index to get ip block for PSP > drm/admgpu: add helper functions to track status for ras manager > drm/amdgpu: add a flag to track ras debugfs creation status > drm/amdgpu: free all resources on error recovery path of > amdgpu_ras_init() > drm/amdgpu: introduce a flag to track refcount held for features > drm/amdgpu: enhance amdgpu_ras_block_late_fini() > drm/amdgpu: enhance amdgpu_ras_pre_fini() to better support SR > drm/admgpu: rename amdgpu_ras_pre_fini() to amdgpu_ras_early_fini() > drm/amdgpu: make IP block state machine works in stack like way > drm/admgpu: make device state machine work in stack like way > drm/amdgpu/sdma: improve the way to manage irq reference count > drm/amdgpu/nbio: improve the way to manage irq reference count > drm/amdgpu/asic: make ip block operations symmetric by .early_fini() > > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 40 +++++ > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 37 ++++- > drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.c | 16 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h | 1 + > drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 8 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 144 +++++++++++++----- > drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h | 16 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c | 26 +++- > drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h | 2 + > drivers/gpu/drm/amd/amdgpu/amdgpu_umc.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 2 +- > drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c | 2 +- > drivers/gpu/drm/amd/amdgpu/mmhub_v1_8.c | 2 +- > drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c | 1 + > drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c | 1 + > drivers/gpu/drm/amd/amdgpu/nv.c | 14 +- > drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 8 - > drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c | 23 +-- > drivers/gpu/drm/amd/amdgpu/soc15.c | 38 ++--- > drivers/gpu/drm/amd/amdgpu/soc21.c | 35 +++-- > drivers/gpu/drm/amd/amdgpu/soc24.c | 17 ++- > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 + > 25 files changed, 326 insertions(+), 118 deletions(-) > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-01-08 13:59 Jiang Liu 2025-01-08 14:10 ` Christian König @ 2025-01-08 16:33 ` Mario Limonciello 2025-01-09 5:34 ` Re: Gerry Liu 1 sibling, 1 reply; 1767+ messages in thread From: Mario Limonciello @ 2025-01-08 16:33 UTC (permalink / raw) To: Jiang Liu, alexander.deucher, christian.koenig, Xinhui.Pan, airlied, simona, sunil.khatri, lijo.lazar, Hawking.Zhang, Jun.Ma2, xiaogang.chen, Kent.Russell, shuox.liu, amd-gfx On 1/8/2025 07:59, Jiang Liu wrote: > Subject: [RFC PATCH 00/13] Enhance device state machine to better support suspend/resume I'm not sure how this happened, but your subject didn't end up in the subject of the thread on patch 0 so the thread just looks like an unsubjected thread. > > Recently we were testing suspend/resume functionality with AMD GPUs, > we have encountered several resource tracking related bugs, such as > double buffer free, use after free and unbalanced irq reference count. Can you share more aobut how you were hitting these issues? Are they specific to S3 or to s2idle flows? dGPU or APU? Are they only with SRIOV? Is there anything to do with the host influencing the failures to happen, or are you contriving the failures to find the bugs? I know we've had some reports about resource tracking warnings on the reset flows, but I haven't heard much about suspend/resume. > > We have tried to solve these issues case by case, but found that may > not be the right way. Especially about the unbalanced irq reference > count, there will be new issues appear once we fixed the current known > issues. After analyzing related source code, we found that there may be > some fundamental implementaion flaws behind these resource tracking implementation > issues. > > The amdgpu driver has two major state machines to driver the device > management flow, one is for ip blocks, the other is for ras blocks. > The hook points defined in struct amd_ip_funcs for device setup/teardown > are symmetric, but the implementation is asymmetric, sometime even > ambiguous. The most obvious two issues we noticed are: > 1) amdgpu_irq_get() are called from .late_init() but amdgpu_irq_put() > are called from .hw_fini() instead of .early_fini(). > 2) the way to reset ip_bloc.status.valid/sw/hw/late_initialized doesn't > match the way to set those flags. > > When taking device suspend/resume into account, in addition to device > probe/remove, things get much more complex. Some issues arise because > many suspend/resume implementations directly reuse .hw_init/.hw_fini/ > .late_init hook points. > > So we try to fix those issues by two enhancements/refinements to current > device management state machines. > > The first change is to make the ip block state machine and associated > status flags work in stack-like way as below: > Callback Status Flags > early_init: valid = true > sw_init: sw = true > hw_init: hw = true > late_init: late_initialized = true > early_fini: late_initialized = false > hw_fini: hw = false > sw_fini: sw = false > late_fini: valid = false At a high level this makes sense to me, but I'd just call 'late' or 'late_init'. Another idea if you make it stack like is to do it as a true enum for the state machine and store it all in one variable. > > Also do the same thing for ras block state machine, though it's much > more simpler. > > The second change is fine tune the overall device management work > flow as below: > 1. amdgpu_driver_load_kms() > amdgpu_device_init() > amdgpu_device_ip_early_init() > ip_blocks[i].early_init() > ip_blocks[i].status.valid = true > amdgpu_device_ip_init() > amdgpu_ras_init() > ip_blocks[i].sw_init() > ip_blocks[i].status.sw = true > ip_blocks[i].hw_init() > ip_blocks[i].status.hw = true > amdgpu_device_ip_late_init() > ip_blocks[i].late_init() > ip_blocks[i].status.late_initialized = true > amdgpu_ras_late_init() > ras_blocks[i].ras_late_init() > amdgpu_ras_feature_enable_on_boot() > > 2. amdgpu_pmops_suspend()/amdgpu_pmops_freeze()/amdgpu_pmops_poweroff() > amdgpu_device_suspend() > amdgpu_ras_early_fini() > ras_blocks[i].ras_early_fini() > amdgpu_ras_feature_disable() > amdgpu_ras_suspend() > amdgpu_ras_disable_all_features() > +++ ip_blocks[i].early_fini() > +++ ip_blocks[i].status.late_initialized = false > ip_blocks[i].suspend() > > 3. amdgpu_pmops_resume()/amdgpu_pmops_thaw()/amdgpu_pmops_restore() > amdgpu_device_resume() > amdgpu_device_ip_resume() > ip_blocks[i].resume() > amdgpu_device_ip_late_init() > ip_blocks[i].late_init() > ip_blocks[i].status.late_initialized = true > amdgpu_ras_late_init() > ras_blocks[i].ras_late_init() > amdgpu_ras_feature_enable_on_boot() > amdgpu_ras_resume() > amdgpu_ras_enable_all_features() > > 4. amdgpu_driver_unload_kms() > amdgpu_device_fini_hw() > amdgpu_ras_early_fini() > ras_blocks[i].ras_early_fini() > +++ ip_blocks[i].early_fini() > +++ ip_blocks[i].status.late_initialized = false > ip_blocks[i].hw_fini() > ip_blocks[i].status.hw = false > > 5. amdgpu_driver_release_kms() > amdgpu_device_fini_sw() > amdgpu_device_ip_fini() > ip_blocks[i].sw_fini() > ip_blocks[i].status.sw = false > --- ip_blocks[i].status.valid = false > +++ amdgpu_ras_fini() > ip_blocks[i].late_fini() > +++ ip_blocks[i].status.valid = false > --- ip_blocks[i].status.late_initialized = false > --- amdgpu_ras_fini() > > The main changes include: > 1) invoke ip_blocks[i].early_fini in amdgpu_pmops_suspend(). > Currently there's only one ip block which provides `early_fini` > callback. We have add a check of `in_s3` to keep current behavior in > function amdgpu_dm_early_fini(). So there should be no functional > changes. > 2) set ip_blocks[i].status.late_initialized to false after calling > callback `early_fini`. We have auditted all usages of the > late_initialized flag and no functional changes found. > 3) only set ip_blocks[i].status.valid = false after calling the > `late_fini` callback. > 4) call amdgpu_ras_fini() before invoking ip_blocks[i].late_fini. > > Then we try to refine each subsystem, such as nbio, asic, gfx, gmc, > ras etc, to follow the new design. Currently we have only taken the > nbio and asic as examples to show the proposed changes. Once we have > confirmed that's the right way to go, we will handle the lefting > subsystems. > > This is in early stage and requesting for comments, any comments and > suggestions are welcomed! > Jiang Liu (13): > amdgpu: wrong array index to get ip block for PSP > drm/admgpu: add helper functions to track status for ras manager > drm/amdgpu: add a flag to track ras debugfs creation status > drm/amdgpu: free all resources on error recovery path of > amdgpu_ras_init() > drm/amdgpu: introduce a flag to track refcount held for features > drm/amdgpu: enhance amdgpu_ras_block_late_fini() > drm/amdgpu: enhance amdgpu_ras_pre_fini() to better support SR > drm/admgpu: rename amdgpu_ras_pre_fini() to amdgpu_ras_early_fini() > drm/amdgpu: make IP block state machine works in stack like way > drm/admgpu: make device state machine work in stack like way > drm/amdgpu/sdma: improve the way to manage irq reference count > drm/amdgpu/nbio: improve the way to manage irq reference count > drm/amdgpu/asic: make ip block operations symmetric by .early_fini() > > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 40 +++++ > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 37 ++++- > drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.c | 16 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h | 1 + > drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 8 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 144 +++++++++++++----- > drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h | 16 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c | 26 +++- > drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h | 2 + > drivers/gpu/drm/amd/amdgpu/amdgpu_umc.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 2 +- > drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c | 2 +- > drivers/gpu/drm/amd/amdgpu/mmhub_v1_8.c | 2 +- > drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c | 1 + > drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c | 1 + > drivers/gpu/drm/amd/amdgpu/nv.c | 14 +- > drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 8 - > drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c | 23 +-- > drivers/gpu/drm/amd/amdgpu/soc15.c | 38 ++--- > drivers/gpu/drm/amd/amdgpu/soc21.c | 35 +++-- > drivers/gpu/drm/amd/amdgpu/soc24.c | 17 ++- > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 + > 25 files changed, 326 insertions(+), 118 deletions(-) > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-01-08 16:33 ` Re: Mario Limonciello @ 2025-01-09 5:34 ` Gerry Liu 2025-01-09 17:10 ` Re: Mario Limonciello 0 siblings, 1 reply; 1767+ messages in thread From: Gerry Liu @ 2025-01-09 5:34 UTC (permalink / raw) To: Mario Limonciello Cc: alexander.deucher, christian.koenig, Xinhui.Pan, airlied, simona, sunil.khatri, Lazar, Lijo, Hawking.Zhang, Chen, Xiaogang, Kent.Russell, Shuo Liu, amd-gfx [-- Attachment #1: Type: text/plain, Size: 10505 bytes --] > 2025年1月9日 00:33，Mario Limonciello <mario.limonciello@amd.com> 写道： > > On 1/8/2025 07:59, Jiang Liu wrote: >> Subject: [RFC PATCH 00/13] Enhance device state machine to better support suspend/resume > > I'm not sure how this happened, but your subject didn't end up in the subject of the thread on patch 0 so the thread just looks like an unsubjected thread. Maybe it’s caused by one extra blank line at the header. > >> Recently we were testing suspend/resume functionality with AMD GPUs, >> we have encountered several resource tracking related bugs, such as >> double buffer free, use after free and unbalanced irq reference count. > > Can you share more aobut how you were hitting these issues? Are they specific to S3 or to s2idle flows? dGPU or APU? > Are they only with SRIOV? > > Is there anything to do with the host influencing the failures to happen, or are you contriving the failures to find the bugs? > > I know we've had some reports about resource tracking warnings on the reset flows, but I haven't heard much about suspend/resume. We are investigating to develop some advanced product features based on amdgpu suspend/resume. So we started by tested the suspend/resume functionality of AMD 308x GPUs with the following simple script: ``` echo platform > /sys/power/pm_test i=0 while true; do echo mem > /sys/power/state let i=i+1 echo $i sleep 1 done ``` It succeeds with the first and second iteration but always fails on following iterations on a bare metal servers with eight MI308X GPUs. With some investigation we found that the gpu asic should be reset during the test, so we submitted a patch to fix the failure (https://github.com/ROCm/ROCK-Kernel-Driver/pull/181 <https://github.com/ROCm/ROCK-Kernel-Driver/pull/181>) During analyze and root-cause the failure, we have encountered several crashes, resource leakages and false alarms. So I have worked out patch sets to solve issues we encountered. The other patch set is https://lists.freedesktop.org/archives/amd-gfx/2025-January/118484.html <https://lists.freedesktop.org/archives/amd-gfx/2025-January/118484.html> With sriov in single VF mode, resume always fails. Seems some contexts/vram buffers get lost during suspend and haven’t be restored on resume, so cause failure. We haven’t tested sriov in multiple VFs mode yet. We need more help from AMD side to make SR work for SRIOV:) > >> We have tried to solve these issues case by case, but found that may >> not be the right way. Especially about the unbalanced irq reference >> count, there will be new issues appear once we fixed the current known >> issues. After analyzing related source code, we found that there may be >> some fundamental implementaion flaws behind these resource tracking > > implementation > >> issues. >> The amdgpu driver has two major state machines to driver the device >> management flow, one is for ip blocks, the other is for ras blocks. >> The hook points defined in struct amd_ip_funcs for device setup/teardown >> are symmetric, but the implementation is asymmetric, sometime even >> ambiguous. The most obvious two issues we noticed are: >> 1) amdgpu_irq_get() are called from .late_init() but amdgpu_irq_put() >> are called from .hw_fini() instead of .early_fini(). >> 2) the way to reset ip_bloc.status.valid/sw/hw/late_initialized doesn't >> match the way to set those flags. >> When taking device suspend/resume into account, in addition to device >> probe/remove, things get much more complex. Some issues arise because >> many suspend/resume implementations directly reuse .hw_init/.hw_fini/ >> .late_init hook points. >> >> So we try to fix those issues by two enhancements/refinements to current >> device management state machines. >> The first change is to make the ip block state machine and associated >> status flags work in stack-like way as below: >> Callback Status Flags >> early_init: valid = true >> sw_init: sw = true >> hw_init: hw = true >> late_init: late_initialized = true >> early_fini: late_initialized = false >> hw_fini: hw = false >> sw_fini: sw = false >> late_fini: valid = false > > At a high level this makes sense to me, but I'd just call 'late' or 'late_init'. > > Another idea if you make it stack like is to do it as a true enum for the state machine and store it all in one variable. I will add a patch to convert those bool flags into an enum. Thanks, Gerry > >> Also do the same thing for ras block state machine, though it's much >> more simpler. >> The second change is fine tune the overall device management work >> flow as below: >> 1. amdgpu_driver_load_kms() >> amdgpu_device_init() >> amdgpu_device_ip_early_init() >> ip_blocks[i].early_init() >> ip_blocks[i].status.valid = true >> amdgpu_device_ip_init() >> amdgpu_ras_init() >> ip_blocks[i].sw_init() >> ip_blocks[i].status.sw = true >> ip_blocks[i].hw_init() >> ip_blocks[i].status.hw = true >> amdgpu_device_ip_late_init() >> ip_blocks[i].late_init() >> ip_blocks[i].status.late_initialized = true >> amdgpu_ras_late_init() >> ras_blocks[i].ras_late_init() >> amdgpu_ras_feature_enable_on_boot() >> 2. amdgpu_pmops_suspend()/amdgpu_pmops_freeze()/amdgpu_pmops_poweroff() >> amdgpu_device_suspend() >> amdgpu_ras_early_fini() >> ras_blocks[i].ras_early_fini() >> amdgpu_ras_feature_disable() >> amdgpu_ras_suspend() >> amdgpu_ras_disable_all_features() >> +++ ip_blocks[i].early_fini() >> +++ ip_blocks[i].status.late_initialized = false >> ip_blocks[i].suspend() >> 3. amdgpu_pmops_resume()/amdgpu_pmops_thaw()/amdgpu_pmops_restore() >> amdgpu_device_resume() >> amdgpu_device_ip_resume() >> ip_blocks[i].resume() >> amdgpu_device_ip_late_init() >> ip_blocks[i].late_init() >> ip_blocks[i].status.late_initialized = true >> amdgpu_ras_late_init() >> ras_blocks[i].ras_late_init() >> amdgpu_ras_feature_enable_on_boot() >> amdgpu_ras_resume() >> amdgpu_ras_enable_all_features() >> 4. amdgpu_driver_unload_kms() >> amdgpu_device_fini_hw() >> amdgpu_ras_early_fini() >> ras_blocks[i].ras_early_fini() >> +++ ip_blocks[i].early_fini() >> +++ ip_blocks[i].status.late_initialized = false >> ip_blocks[i].hw_fini() >> ip_blocks[i].status.hw = false >> 5. amdgpu_driver_release_kms() >> amdgpu_device_fini_sw() >> amdgpu_device_ip_fini() >> ip_blocks[i].sw_fini() >> ip_blocks[i].status.sw = false >> --- ip_blocks[i].status.valid = false >> +++ amdgpu_ras_fini() >> ip_blocks[i].late_fini() >> +++ ip_blocks[i].status.valid = false >> --- ip_blocks[i].status.late_initialized = false >> --- amdgpu_ras_fini() >> The main changes include: >> 1) invoke ip_blocks[i].early_fini in amdgpu_pmops_suspend(). >> Currently there's only one ip block which provides `early_fini` >> callback. We have add a check of `in_s3` to keep current behavior in >> function amdgpu_dm_early_fini(). So there should be no functional >> changes. >> 2) set ip_blocks[i].status.late_initialized to false after calling >> callback `early_fini`. We have auditted all usages of the >> late_initialized flag and no functional changes found. >> 3) only set ip_blocks[i].status.valid = false after calling the >> `late_fini` callback. >> 4) call amdgpu_ras_fini() before invoking ip_blocks[i].late_fini. >> Then we try to refine each subsystem, such as nbio, asic, gfx, gmc, >> ras etc, to follow the new design. Currently we have only taken the >> nbio and asic as examples to show the proposed changes. Once we have >> confirmed that's the right way to go, we will handle the lefting >> subsystems. >> This is in early stage and requesting for comments, any comments and >> suggestions are welcomed! >> Jiang Liu (13): >> amdgpu: wrong array index to get ip block for PSP >> drm/admgpu: add helper functions to track status for ras manager >> drm/amdgpu: add a flag to track ras debugfs creation status >> drm/amdgpu: free all resources on error recovery path of >> amdgpu_ras_init() >> drm/amdgpu: introduce a flag to track refcount held for features >> drm/amdgpu: enhance amdgpu_ras_block_late_fini() >> drm/amdgpu: enhance amdgpu_ras_pre_fini() to better support SR >> drm/admgpu: rename amdgpu_ras_pre_fini() to amdgpu_ras_early_fini() >> drm/amdgpu: make IP block state machine works in stack like way >> drm/admgpu: make device state machine work in stack like way >> drm/amdgpu/sdma: improve the way to manage irq reference count >> drm/amdgpu/nbio: improve the way to manage irq reference count >> drm/amdgpu/asic: make ip block operations symmetric by .early_fini() >> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 40 +++++ >> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 37 ++++- >> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 2 +- >> drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c | 2 +- >> drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.c | 16 +- >> drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h | 1 + >> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 8 +- >> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 144 +++++++++++++----- >> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h | 16 +- >> drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c | 26 +++- >> drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h | 2 + >> drivers/gpu/drm/amd/amdgpu/amdgpu_umc.c | 2 +- >> drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 2 +- >> drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 2 +- >> drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c | 2 +- >> drivers/gpu/drm/amd/amdgpu/mmhub_v1_8.c | 2 +- >> drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c | 1 + >> drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c | 1 + >> drivers/gpu/drm/amd/amdgpu/nv.c | 14 +- >> drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 8 - >> drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c | 23 +-- >> drivers/gpu/drm/amd/amdgpu/soc15.c | 38 ++--- >> drivers/gpu/drm/amd/amdgpu/soc21.c | 35 +++-- >> drivers/gpu/drm/amd/amdgpu/soc24.c | 17 ++- >> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 + >> 25 files changed, 326 insertions(+), 118 deletions(-) [-- Attachment #2: Type: text/html, Size: 38668 bytes --] ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-01-09 5:34 ` Re: Gerry Liu @ 2025-01-09 17:10 ` Mario Limonciello 2025-01-13 1:19 ` Re: Gerry Liu 0 siblings, 1 reply; 1767+ messages in thread From: Mario Limonciello @ 2025-01-09 17:10 UTC (permalink / raw) To: Gerry Liu Cc: alexander.deucher, christian.koenig, Xinhui.Pan, airlied, simona, sunil.khatri, Lazar, Lijo, Hawking.Zhang, Chen, Xiaogang, Kent.Russell, Shuo Liu, amd-gfx General note - don't use HTML for mailing list communication. I'm not sure if Apple Mail lets you switch this around. If not, you might try using Thunderbird instead. You can pick to reply in plain text or HTML by holding shift when you hit "reply all" For my reply I'll convert my reply to plain text, please see inline below. On 1/8/2025 23:34, Gerry Liu wrote: > > >> 2025年1月9日 00:33，Mario Limonciello <mario.limonciello@amd.com >> <mailto:mario.limonciello@amd.com>> 写道： >> >> On 1/8/2025 07:59, Jiang Liu wrote: >>> Subject: [RFC PATCH 00/13] Enhance device state machine to better >>> support suspend/resume >> >> I'm not sure how this happened, but your subject didn't end up in the >> subject of the thread on patch 0 so the thread just looks like an >> unsubjected thread. > Maybe it’s caused by one extra blank line at the header. Yeah that might be it. Hopefully it doesn't happen on v2. > >> >>> Recently we were testing suspend/resume functionality with AMD GPUs, >>> we have encountered several resource tracking related bugs, such as >>> double buffer free, use after free and unbalanced irq reference count. >> >> Can you share more aobut how you were hitting these issues? Are they >> specific to S3 or to s2idle flows? dGPU or APU? >> Are they only with SRIOV? >> >> Is there anything to do with the host influencing the failures to >> happen, or are you contriving the failures to find the bugs? >> >> I know we've had some reports about resource tracking warnings on the >> reset flows, but I haven't heard much about suspend/resume. > We are investigating to develop some advanced product features based on > amdgpu suspend/resume. > So we started by tested the suspend/resume functionality of AMD 308x > GPUs with the following simple script: > ``` > echoplatform >/sys/power/pm_test > i=0 > while true; do > echomem >/sys/power/state > leti=i+1 > echo$i > sleep1 > done > ``` > > It succeeds with the first and second iteration but always fails on > following iterations on a bare metal servers with eight MI308X GPUs. Can you share more about this server? Does it support suspend to ram or a hardware backed suspend to idle? If you don't know, you can check like this: ❯ cat /sys/power/mem_sleep s2idle [deep] If it's suspend to idle, what does the FACP indicate? You can do this check to find out if you don't know. ❯ sudo cp /sys/firmware/acpi/tables/FACP /tmp ❯ sudo iasl -d /tmp/FACP ❯ grep "idle" -i /tmp/FACP.dsl Low Power S0 Idle (V5) : 0 > With some investigation we found that the gpu asic should be reset > during the test, Yeah; but this comes back to my above questions. Typically there is an assumption that the power rails are going to be cut in system suspend. If that doesn't hold true, then you're doing a pure software suspend and have found a series of issues in the driver with how that's handled. > so we submitted a patch to fix the failure (https:// > github.com/ROCm/ROCK-Kernel-Driver/pull/181 <https://github.com/ROCm/ > ROCK-Kernel-Driver/pull/181>) Typically kernel patches don't go through that repo, they're discussed on the mailing lists. Can you bring this patch for discussion on amd-gfx? > > During analyze and root-cause the failure, we have encountered several > crashes, resource leakages and false alarms. Yeah; I think you found some real issues. > So I have worked out patch sets to solve issues we encountered. The > other patch set is https://lists.freedesktop.org/archives/amd-gfx/2025- > January/118484.html <https://lists.freedesktop.org/archives/amd- > gfx/2025-January/118484.html> Thanks! > > With sriov in single VF mode, resume always fails. Seems some contexts/ > vram buffers get lost during suspend and haven’t be restored on resume, > so cause failure. > We haven’t tested sriov in multiple VFs mode yet. We need more help from > AMD side to make SR work for SRIOV:) > >> >>> We have tried to solve these issues case by case, but found that may >>> not be the right way. Especially about the unbalanced irq reference >>> count, there will be new issues appear once we fixed the current known >>> issues. After analyzing related source code, we found that there may be >>> some fundamental implementaion flaws behind these resource tracking >> >> implementation >> >>> issues. >>> The amdgpu driver has two major state machines to driver the device >>> management flow, one is for ip blocks, the other is for ras blocks. >>> The hook points defined in struct amd_ip_funcs for device setup/teardown >>> are symmetric, but the implementation is asymmetric, sometime even >>> ambiguous. The most obvious two issues we noticed are: >>> 1) amdgpu_irq_get() are called from .late_init() but amdgpu_irq_put() >>> are called from .hw_fini() instead of .early_fini(). >>> 2) the way to reset ip_bloc.status.valid/sw/hw/late_initialized doesn't >>> match the way to set those flags. >>> When taking device suspend/resume into account, in addition to device >>> probe/remove, things get much more complex. Some issues arise because >>> many suspend/resume implementations directly reuse .hw_init/.hw_fini/ >>> .late_init hook points. >>> >>> So we try to fix those issues by two enhancements/refinements to current >>> device management state machines. >>> The first change is to make the ip block state machine and associated >>> status flags work in stack-like way as below: >>> Callback Status Flags >>> early_init: valid = true >>> sw_init: sw = true >>> hw_init: hw = true >>> late_init: late_initialized = true >>> early_fini: late_initialized = false >>> hw_fini: hw = false >>> sw_fini: sw = false >>> late_fini: valid = false >> >> At a high level this makes sense to me, but I'd just call 'late' or >> 'late_init'. >> >> Another idea if you make it stack like is to do it as a true enum for >> the state machine and store it all in one variable. > I will add a patch to convert those bool flags into an enum. Thanks! ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-01-09 17:10 ` Re: Mario Limonciello @ 2025-01-13 1:19 ` Gerry Liu 2025-01-13 21:59 ` Re: Mario Limonciello 0 siblings, 1 reply; 1767+ messages in thread From: Gerry Liu @ 2025-01-13 1:19 UTC (permalink / raw) To: Mario Limonciello Cc: alexander.deucher, christian.koenig, Xinhui.Pan, airlied, simona, sunil.khatri, Lazar, Lijo, Hawking.Zhang, Chen, Xiaogang, Kent.Russell, Shuo Liu, amd-gfx > 2025年1月10日 01:10，Mario Limonciello <mario.limonciello@amd.com> 写道： > > General note - don't use HTML for mailing list communication. > > I'm not sure if Apple Mail lets you switch this around. > > If not, you might try using Thunderbird instead. You can pick to reply in plain text or HTML by holding shift when you hit "reply all" > > For my reply I'll convert my reply to plain text, please see inline below. > > On 1/8/2025 23:34, Gerry Liu wrote: >>> 2025年1月9日 00:33，Mario Limonciello <mario.limonciello@amd.com <mailto:mario.limonciello@amd.com>> 写道： >>> >>> On 1/8/2025 07:59, Jiang Liu wrote: >>>> Subject: [RFC PATCH 00/13] Enhance device state machine to better support suspend/resume >>> >>> I'm not sure how this happened, but your subject didn't end up in the subject of the thread on patch 0 so the thread just looks like an unsubjected thread. >> Maybe it’s caused by one extra blank line at the header. > > Yeah that might be it. Hopefully it doesn't happen on v2. > >>> >>>> Recently we were testing suspend/resume functionality with AMD GPUs, >>>> we have encountered several resource tracking related bugs, such as >>>> double buffer free, use after free and unbalanced irq reference count. >>> >>> Can you share more aobut how you were hitting these issues? Are they specific to S3 or to s2idle flows? dGPU or APU? >>> Are they only with SRIOV? >>> >>> Is there anything to do with the host influencing the failures to happen, or are you contriving the failures to find the bugs? >>> >>> I know we've had some reports about resource tracking warnings on the reset flows, but I haven't heard much about suspend/resume. >> We are investigating to develop some advanced product features based on amdgpu suspend/resume. >> So we started by tested the suspend/resume functionality of AMD 308x GPUs with the following simple script: >> ``` >> echoplatform >/sys/power/pm_test >> i=0 >> while true; do >> echomem >/sys/power/state >> leti=i+1 >> echo$i >> sleep1 >> done >> ``` >> It succeeds with the first and second iteration but always fails on following iterations on a bare metal servers with eight MI308X GPUs. > > Can you share more about this server? Does it support suspend to ram or a hardware backed suspend to idle? If you don't know, you can check like this: > > ❯ cat /sys/power/mem_sleep > s2idle [deep] # cat /sys/power/mem_sleep [s2idle] > > If it's suspend to idle, what does the FACP indicate? You can do this check to find out if you don't know. > > ❯ sudo cp /sys/firmware/acpi/tables/FACP /tmp > ❯ sudo iasl -d /tmp/FACP > ❯ grep "idle" -i /tmp/FACP.dsl > Low Power S0 Idle (V5) : 0 > With acpidump and `iasl -d facp.data`, we got: [070h 0112 4] Flags (decoded below) : 000084A5 WBINVD instruction is operational (V1) : 1 WBINVD flushes all caches (V1) : 0 All CPUs support C1 (V1) : 1 C2 works on MP system (V1) : 0 Control Method Power Button (V1) : 0 Control Method Sleep Button (V1) : 1 RTC wake not in fixed reg space (V1) : 0 RTC can wake system from S4 (V1) : 1 32-bit PM Timer (V1) : 0 Docking Supported (V1) : 0 Reset Register Supported (V2) : 1 Sealed Case (V3) : 0 Headless - No Video (V3) : 0 Use native instr after SLP_TYPx (V3) : 0 PCIEXP_WAK Bits Supported (V4) : 0 Use Platform Timer (V4) : 1 RTC_STS valid on S4 wake (V4) : 0 Remote Power-on capable (V4) : 0 Use APIC Cluster Model (V4) : 0 Use APIC Physical Destination Mode (V4) : 0 Hardware Reduced (V5) : 0 Low Power S0 Idle (V5) : 0 >> With some investigation we found that the gpu asic should be reset during the test, > > Yeah; but this comes back to my above questions. Typically there is an assumption that the power rails are going to be cut in system suspend. > > If that doesn't hold true, then you're doing a pure software suspend and have found a series of issues in the driver with how that's handled. Yeah, we are trying to do a `pure software suspend`, letting hypervisor to save/restore system images instead of guest OS. And during the suspend process, we hope we can cancel the suspend request at any later stage. We cancel suspend at late stages, it does behave like a pure software suspend. > >> so we submitted a patch to fix the failure (https:// github.com/ROCm/ROCK-Kernel-Driver/pull/181 <https://github.com/ROCm/ ROCK-Kernel-Driver/pull/181>) > > Typically kernel patches don't go through that repo, they're discussed on the mailing lists. Can you bring this patch for discussion on amd-gfx? Will post to amd-gfx after solving the conflicts. Regards, Gerry > >> During analyze and root-cause the failure, we have encountered several crashes, resource leakages and false alarms. > > Yeah; I think you found some real issues. > >> So I have worked out patch sets to solve issues we encountered. The other patch set is https://lists.freedesktop.org/archives/amd-gfx/2025- January/118484.html <https://lists.freedesktop.org/archives/amd- gfx/2025-January/118484.html> > > Thanks! > >> With sriov in single VF mode, resume always fails. Seems some contexts/ vram buffers get lost during suspend and haven’t be restored on resume, so cause failure. >> We haven’t tested sriov in multiple VFs mode yet. We need more help from AMD side to make SR work for SRIOV:) >>> >>>> We have tried to solve these issues case by case, but found that may >>>> not be the right way. Especially about the unbalanced irq reference >>>> count, there will be new issues appear once we fixed the current known >>>> issues. After analyzing related source code, we found that there may be >>>> some fundamental implementaion flaws behind these resource tracking >>> >>> implementation >>> >>>> issues. >>>> The amdgpu driver has two major state machines to driver the device >>>> management flow, one is for ip blocks, the other is for ras blocks. >>>> The hook points defined in struct amd_ip_funcs for device setup/teardown >>>> are symmetric, but the implementation is asymmetric, sometime even >>>> ambiguous. The most obvious two issues we noticed are: >>>> 1) amdgpu_irq_get() are called from .late_init() but amdgpu_irq_put() >>>> are called from .hw_fini() instead of .early_fini(). >>>> 2) the way to reset ip_bloc.status.valid/sw/hw/late_initialized doesn't >>>> match the way to set those flags. >>>> When taking device suspend/resume into account, in addition to device >>>> probe/remove, things get much more complex. Some issues arise because >>>> many suspend/resume implementations directly reuse .hw_init/.hw_fini/ >>>> .late_init hook points. >>>> >>>> So we try to fix those issues by two enhancements/refinements to current >>>> device management state machines. >>>> The first change is to make the ip block state machine and associated >>>> status flags work in stack-like way as below: >>>> Callback Status Flags >>>> early_init: valid = true >>>> sw_init: sw = true >>>> hw_init: hw = true >>>> late_init: late_initialized = true >>>> early_fini: late_initialized = false >>>> hw_fini: hw = false >>>> sw_fini: sw = false >>>> late_fini: valid = false >>> >>> At a high level this makes sense to me, but I'd just call 'late' or 'late_init'. >>> >>> Another idea if you make it stack like is to do it as a true enum for the state machine and store it all in one variable. >> I will add a patch to convert those bool flags into an enum. > > Thanks! ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2025-01-13 1:19 ` Re: Gerry Liu @ 2025-01-13 21:59 ` Mario Limonciello 0 siblings, 0 replies; 1767+ messages in thread From: Mario Limonciello @ 2025-01-13 21:59 UTC (permalink / raw) To: Gerry Liu Cc: alexander.deucher, christian.koenig, Xinhui.Pan, airlied, simona, sunil.khatri, Lazar, Lijo, Hawking.Zhang, Chen, Xiaogang, Kent.Russell, Shuo Liu, amd-gfx On 1/12/2025 19:19, Gerry Liu wrote: > > >> 2025年1月10日 01:10，Mario Limonciello <mario.limonciello@amd.com> 写道： >> >> General note - don't use HTML for mailing list communication. >> >> I'm not sure if Apple Mail lets you switch this around. >> >> If not, you might try using Thunderbird instead. You can pick to reply in plain text or HTML by holding shift when you hit "reply all" >> >> For my reply I'll convert my reply to plain text, please see inline below. >> >> On 1/8/2025 23:34, Gerry Liu wrote: >>>> 2025年1月9日 00:33，Mario Limonciello <mario.limonciello@amd.com <mailto:mario.limonciello@amd.com>> 写道： >>>> >>>> On 1/8/2025 07:59, Jiang Liu wrote: >>>>> Subject: [RFC PATCH 00/13] Enhance device state machine to better support suspend/resume >>>> >>>> I'm not sure how this happened, but your subject didn't end up in the subject of the thread on patch 0 so the thread just looks like an unsubjected thread. >>> Maybe it’s caused by one extra blank line at the header. >> >> Yeah that might be it. Hopefully it doesn't happen on v2. >> >>>> >>>>> Recently we were testing suspend/resume functionality with AMD GPUs, >>>>> we have encountered several resource tracking related bugs, such as >>>>> double buffer free, use after free and unbalanced irq reference count. >>>> >>>> Can you share more aobut how you were hitting these issues? Are they specific to S3 or to s2idle flows? dGPU or APU? >>>> Are they only with SRIOV? >>>> >>>> Is there anything to do with the host influencing the failures to happen, or are you contriving the failures to find the bugs? >>>> >>>> I know we've had some reports about resource tracking warnings on the reset flows, but I haven't heard much about suspend/resume. >>> We are investigating to develop some advanced product features based on amdgpu suspend/resume. >>> So we started by tested the suspend/resume functionality of AMD 308x GPUs with the following simple script: >>> ``` >>> echoplatform >/sys/power/pm_test >>> i=0 >>> while true; do >>> echomem >/sys/power/state >>> leti=i+1 >>> echo$i >>> sleep1 >>> done >>> ``` >>> It succeeds with the first and second iteration but always fails on following iterations on a bare metal servers with eight MI308X GPUs. >> >> Can you share more about this server? Does it support suspend to ram or a hardware backed suspend to idle? If you don't know, you can check like this: >> >> ❯ cat /sys/power/mem_sleep >> s2idle [deep] > # cat /sys/power/mem_sleep > [s2idle] > >> >> If it's suspend to idle, what does the FACP indicate? You can do this check to find out if you don't know. >> >> ❯ sudo cp /sys/firmware/acpi/tables/FACP /tmp >> ❯ sudo iasl -d /tmp/FACP >> ❯ grep "idle" -i /tmp/FACP.dsl >> Low Power S0 Idle (V5) : 0 >> > With acpidump and `iasl -d facp.data`, we got: > [070h 0112 4] Flags (decoded below) : 000084A5 > WBINVD instruction is operational (V1) : 1 > WBINVD flushes all caches (V1) : 0 > All CPUs support C1 (V1) : 1 > C2 works on MP system (V1) : 0 > Control Method Power Button (V1) : 0 > Control Method Sleep Button (V1) : 1 > RTC wake not in fixed reg space (V1) : 0 > RTC can wake system from S4 (V1) : 1 > 32-bit PM Timer (V1) : 0 > Docking Supported (V1) : 0 > Reset Register Supported (V2) : 1 > Sealed Case (V3) : 0 > Headless - No Video (V3) : 0 > Use native instr after SLP_TYPx (V3) : 0 > PCIEXP_WAK Bits Supported (V4) : 0 > Use Platform Timer (V4) : 1 > RTC_STS valid on S4 wake (V4) : 0 > Remote Power-on capable (V4) : 0 > Use APIC Cluster Model (V4) : 0 > Use APIC Physical Destination Mode (V4) : 0 > Hardware Reduced (V5) : 0 > Low Power S0 Idle (V5) : 0 > >>> With some investigation we found that the gpu asic should be reset during the test, >> >> Yeah; but this comes back to my above questions. Typically there is an assumption that the power rails are going to be cut in system suspend. >> >> If that doesn't hold true, then you're doing a pure software suspend and have found a series of issues in the driver with how that's handled. > Yeah, we are trying to do a `pure software suspend`, letting hypervisor to save/restore system images instead of guest OS. > And during the suspend process, we hope we can cancel the suspend request at any later stage. > We cancel suspend at late stages, it does behave like a pure software suspend. > Thanks; this all makes a lot more sense now. This isn't an area that has a lot of coverage right now. Most suspend testing happens with the power being cut and coming back fresh. Will keep this in mind as reviewing your future iterations of your patches. >> >>> so we submitted a patch to fix the failure (https:// github.com/ROCm/ROCK-Kernel-Driver/pull/181 <https://github.com/ROCm/ ROCK-Kernel-Driver/pull/181>) >> >> Typically kernel patches don't go through that repo, they're discussed on the mailing lists. Can you bring this patch for discussion on amd-gfx? > Will post to amd-gfx after solving the conflicts. Thx! > > Regards, > Gerry > >> >>> During analyze and root-cause the failure, we have encountered several crashes, resource leakages and false alarms. >> >> Yeah; I think you found some real issues. >> >>> So I have worked out patch sets to solve issues we encountered. The other patch set is https://lists.freedesktop.org/archives/amd-gfx/2025- January/118484.html <https://lists.freedesktop.org/archives/amd- gfx/2025-January/118484.html> >> >> Thanks! >> >>> With sriov in single VF mode, resume always fails. Seems some contexts/ vram buffers get lost during suspend and haven’t be restored on resume, so cause failure. >>> We haven’t tested sriov in multiple VFs mode yet. We need more help from AMD side to make SR work for SRIOV:) >>>> >>>>> We have tried to solve these issues case by case, but found that may >>>>> not be the right way. Especially about the unbalanced irq reference >>>>> count, there will be new issues appear once we fixed the current known >>>>> issues. After analyzing related source code, we found that there may be >>>>> some fundamental implementaion flaws behind these resource tracking >>>> >>>> implementation >>>> >>>>> issues. >>>>> The amdgpu driver has two major state machines to driver the device >>>>> management flow, one is for ip blocks, the other is for ras blocks. >>>>> The hook points defined in struct amd_ip_funcs for device setup/teardown >>>>> are symmetric, but the implementation is asymmetric, sometime even >>>>> ambiguous. The most obvious two issues we noticed are: >>>>> 1) amdgpu_irq_get() are called from .late_init() but amdgpu_irq_put() >>>>> are called from .hw_fini() instead of .early_fini(). >>>>> 2) the way to reset ip_bloc.status.valid/sw/hw/late_initialized doesn't >>>>> match the way to set those flags. >>>>> When taking device suspend/resume into account, in addition to device >>>>> probe/remove, things get much more complex. Some issues arise because >>>>> many suspend/resume implementations directly reuse .hw_init/.hw_fini/ >>>>> .late_init hook points. >>>>> >>>>> So we try to fix those issues by two enhancements/refinements to current >>>>> device management state machines. >>>>> The first change is to make the ip block state machine and associated >>>>> status flags work in stack-like way as below: >>>>> Callback Status Flags >>>>> early_init: valid = true >>>>> sw_init: sw = true >>>>> hw_init: hw = true >>>>> late_init: late_initialized = true >>>>> early_fini: late_initialized = false >>>>> hw_fini: hw = false >>>>> sw_fini: sw = false >>>>> late_fini: valid = false >>>> >>>> At a high level this makes sense to me, but I'd just call 'late' or 'late_init'. >>>> >>>> Another idea if you make it stack like is to do it as a true enum for the state machine and store it all in one variable. >>> I will add a patch to convert those bool flags into an enum. >> >> Thanks! > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2024-11-25 20:13 Robert Harewood 0 siblings, 0 replies; 1767+ messages in thread From: Robert Harewood @ 2024-11-25 20:13 UTC (permalink / raw) To: llvm Dear CEO, I hope this message finds you safe and well. I have a team of investors who are interested in providing capital to your business operations and projects without any upfront costs from you. I'd love to have the chance to discuss the details with you further. Please let me know if this is something that you would be interested in, and we can schedule a call to further evaluate the details. Thank you for your time and consideration. Warm regards, Robert Harewood, Robert Harewood Advisory The Broadgate Tower 20 Primrose St, London, United Kingdom, EC2A 2EW. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2024-11-25 19:23 Robert Harewood 0 siblings, 0 replies; 1767+ messages in thread From: Robert Harewood @ 2024-11-25 19:23 UTC (permalink / raw) To: v9fs Dear CEO, I hope this message finds you safe and well. I have a team of investors who are interested in providing capital to your business operations and projects without any upfront costs from you. I'd love to have the chance to discuss the details with you further. Please let me know if this is something that you would be interested in, and we can schedule a call to further evaluate the details. Thank you for your time and consideration. Warm regards, Robert Harewood, Robert Harewood Advisory The Broadgate Tower 20 Primrose St, London, United Kingdom, EC2A 2EW. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2024-11-23 1:39 the Hide 2024-11-23 7:32 ` Christoph Biedl 0 siblings, 1 reply; 1767+ messages in thread From: the Hide @ 2024-11-23 1:39 UTC (permalink / raw) To: stable Who should I contact regarding the following error E: Malformed entry 5 in list file /etc/apt/sources.list.d/additional-repositories.list (Component) E: The list of sources could not be read. E: _cache->open() failed, please report. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-11-23 1:39 the Hide @ 2024-11-23 7:32 ` Christoph Biedl 0 siblings, 0 replies; 1767+ messages in thread From: Christoph Biedl @ 2024-11-23 7:32 UTC (permalink / raw) To: the Hide; +Cc: stable [-- Attachment #1: Type: text/plain, Size: 828 bytes --] the Hide wrote... > Who should I contact regarding the following error > > > E: Malformed entry 5 in list file > /etc/apt/sources.list.d/additional-repositories.list (Component) > E: The list of sources could not be read. > E: _cache->open() failed, please report. Assuming you're using Debian and not some derivatve: Some Debian users mailing list, like <https://lists.debian.org/debian-user/> From the above error message I assume there's a format error in /etc/apt/sources.list.d/additional-repositories.list - so it was wise to include the content of that file in a message to that list. If it's actually a bug in apt, the Debian bug tracker was the place to go. This list here however is about development of the Linux kernel, the stable releases, so not quite the right place. Christoph [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2024-10-17 9:09 Paulo Miguel Almeida 2024-10-17 9:12 ` Paulo Miguel Almeida 0 siblings, 1 reply; 1767+ messages in thread From: Paulo Miguel Almeida @ 2024-10-17 9:09 UTC (permalink / raw) To: tsbogend, bvanassche, gregkh, ricardo, zhanggenjian, linux-mips, linux-kernel Cc: paulo.miguel.almeida.rodenas linux-hardening@vger.kernel.org Bcc: Subject: [PATCH v2][next] mips: sgi-ip22: Replace "s[n]?printf" with sysfs_emit in sysfs callbacks Reply-To: Replace open-coded pieces with sysfs_emit() helper in sysfs .show() callbacks. Signed-off-by: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com> --- Changelog: - v2: amend commit message (Req: Maciej W. Rozycki) - v1: https://lore.kernel.org/lkml/Zw2GRQkbx8Z8DlcS@mail.google.com/ --- arch/mips/sgi-ip22/ip22-gio.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/mips/sgi-ip22/ip22-gio.c b/arch/mips/sgi-ip22/ip22-gio.c index d20eec742bfa..5893ea4e382c 100644 --- a/arch/mips/sgi-ip22/ip22-gio.c +++ b/arch/mips/sgi-ip22/ip22-gio.c @@ -165,9 +165,8 @@ static ssize_t modalias_show(struct device *dev, struct device_attribute *a, char *buf) { struct gio_device *gio_dev = to_gio_device(dev); - int len = snprintf(buf, PAGE_SIZE, "gio:%x\n", gio_dev->id.id); - return (len >= PAGE_SIZE) ? (PAGE_SIZE - 1) : len; + return sysfs_emit(buf, "gio:%x\n", gio_dev->id.id); } static DEVICE_ATTR_RO(modalias); @@ -177,7 +176,7 @@ static ssize_t name_show(struct device *dev, struct gio_device *giodev; giodev = to_gio_device(dev); - return sprintf(buf, "%s", giodev->name); + return sysfs_emit(buf, "%s\n", giodev->name); } static DEVICE_ATTR_RO(name); @@ -187,7 +186,7 @@ static ssize_t id_show(struct device *dev, struct gio_device *giodev; giodev = to_gio_device(dev); - return sprintf(buf, "%x", giodev->id.id); + return sysfs_emit(buf, "%x\n", giodev->id.id); } static DEVICE_ATTR_RO(id); -- 2.47.0 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2024-10-17 9:09 Paulo Miguel Almeida @ 2024-10-17 9:12 ` Paulo Miguel Almeida 0 siblings, 0 replies; 1767+ messages in thread From: Paulo Miguel Almeida @ 2024-10-17 9:12 UTC (permalink / raw) To: tsbogend, bvanassche, gregkh, ricardo, zhanggenjian, linux-mips, linux-kernel On Thu, Oct 17, 2024 at 10:09:26PM +1300, Paulo Miguel Almeida wrote: > linux-hardening@vger.kernel.org > Bcc: > Subject: [PATCH v2][next] mips: sgi-ip22: Replace "s[n]?printf" with > sysfs_emit in sysfs callbacks > Reply-To: > > Replace open-coded pieces with sysfs_emit() helper in sysfs .show() > callbacks. > > Signed-off-by: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com> > --- > Changelog: > - v2: amend commit message (Req: Maciej W. Rozycki) > - v1: https://lore.kernel.org/lkml/Zw2GRQkbx8Z8DlcS@mail.google.com/ > --- > Apologies to you all. Fat finger from my part (and a little of mutt's fault too) Will submit the patch shortly - Paulo A. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2024-10-15 22:48 Daniel Yang 2024-10-16 1:27 ` Jakub Kicinski 0 siblings, 1 reply; 1767+ messages in thread From: Daniel Yang @ 2024-10-15 22:48 UTC (permalink / raw) To: Wenjia Zhang, Jan Karcher, D. Wythe, Tony Lu, Wen Gu, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, linux-s390, netdev, linux-kernel Cc: danielyangkang Date: Tue, 15 Oct 2024 15:31:12 -0700 Subject: [PATCH v3 0/2 RESEND] resolve gtp possible deadlock warning Fixes deadlock described in this bug: https://syzkaller.appspot.com/bug?extid=e953a8f3071f5c0a28fd. Specific crash report here: https://syzkaller.appspot.com/text?tag=CrashReport&x=14670e07980000. This bug is a false positive lockdep warning since gtp and smc use completely different socket protocols. Lockdep thinks that lock_sock() in smc will deadlock with gtp's lock_sock() acquisition. Adding lockdep annotations on smc socket creation prevents these false positives. Daniel Yang (2): Patch from D. Wythe <alibuda@linux.alibaba.com> Move lockdep annotation to separate function for readability. net/smc/smc_inet.c | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) -- 2.39.2 ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-10-15 22:48 Daniel Yang @ 2024-10-16 1:27 ` Jakub Kicinski 0 siblings, 0 replies; 1767+ messages in thread From: Jakub Kicinski @ 2024-10-16 1:27 UTC (permalink / raw) To: Daniel Yang Cc: Wenjia Zhang, Jan Karcher, D. Wythe, Tony Lu, Wen Gu, David S. Miller, Eric Dumazet, Paolo Abeni, linux-s390, netdev, linux-kernel On Tue, 15 Oct 2024 15:48:03 -0700 Daniel Yang wrote: > Subject: > Date: Tue, 15 Oct 2024 15:48:03 -0700 > X-Mailer: git-send-email 2.39.2 > > Date: Tue, 15 Oct 2024 15:31:12 -0700 > Subject: [PATCH v3 0/2 RESEND] resolve gtp possible deadlock warning This is garbled as well. Before you repost please make sure you take a look at: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#tl-dr -- pw-bot: cr ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2024-10-10 22:44 PRIVATE 0 siblings, 0 replies; 1767+ messages in thread From: PRIVATE @ 2024-10-10 22:44 UTC (permalink / raw) To: kexec I have a viable proposal for you, If You want to know more, get back to me. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2024-09-17 7:10 Akhil P Oommen
2024-09-17 7:24 ` Dmitry Baryshkov
0 siblings, 1 reply; 1767+ messages in thread
From: Akhil P Oommen @ 2024-09-17 7:10 UTC (permalink / raw)
To: GPUfirmwareforSA8775Pchipset, linux-firmware
Cc: dmitry.baryshkov, quic_rajeshk
The following changes since commit 6c88d9b8253b8ec6df701a551a56438ea2e5bacf:
Merge branch 'amd-staging' into 'main' (2024-09-13 20:28:50 +0000)
are available in the Git repository at:
https://git.codelinaro.org/clo/linux-kernel/linux-firmware.git gpu-fw-SA8775p
for you to fetch changes up to 43c971bcd74d9793140a8fbbcc805204cb797f96:
qcom: add gpu firmwares for sa8775p chipset (2024-09-17 11:57:51 +0530)
----------------------------------------------------------------
Akhil P Oommen (1):
qcom: add gpu firmwares for sa8775p chipset
WHENCE | 2 ++
qcom/a663_gmu.bin | Bin 0 -> 55892 bytes
qcom/sa8775p/a663_zap.mbn | Bin 0 -> 1054680 bytes
3 files changed, 2 insertions(+)
create mode 100644 qcom/a663_gmu.bin
create mode 100644 qcom/sa8775p/a663_zap.mbn
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2024-09-17 7:10 Akhil P Oommen @ 2024-09-17 7:24 ` Dmitry Baryshkov 0 siblings, 0 replies; 1767+ messages in thread From: Dmitry Baryshkov @ 2024-09-17 7:24 UTC (permalink / raw) To: Akhil P Oommen; +Cc: GPUfirmwareforSA8775Pchipset, linux-firmware, quic_rajeshk On Tue, 17 Sept 2024 at 09:10, Akhil P Oommen <quic_akhilpo@quicinc.com> wrote: > > The following changes since commit 6c88d9b8253b8ec6df701a551a56438ea2e5bacf: > > Merge branch 'amd-staging' into 'main' (2024-09-13 20:28:50 +0000) > > are available in the Git repository at: > > https://git.codelinaro.org/clo/linux-kernel/linux-firmware.git gpu-fw-SA8775p > > for you to fetch changes up to 43c971bcd74d9793140a8fbbcc805204cb797f96: > > qcom: add gpu firmwares for sa8775p chipset (2024-09-17 11:57:51 +0530) > > ---------------------------------------------------------------- > Akhil P Oommen (1): > qcom: add gpu firmwares for sa8775p chipset > > WHENCE | 2 ++ > qcom/a663_gmu.bin | Bin 0 -> 55892 bytes > qcom/sa8775p/a663_zap.mbn | Bin 0 -> 1054680 bytes > 3 files changed, 2 insertions(+) > create mode 100644 qcom/a663_gmu.bin > create mode 100644 qcom/sa8775p/a663_zap.mbn Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Thank you! -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2024-09-13 17:11 David Hunter 2024-09-13 20:39 ` Shuah Khan 0 siblings, 1 reply; 1767+ messages in thread From: David Hunter @ 2024-09-13 17:11 UTC (permalink / raw) To: Masahiro Yamada Cc: David Hunter, linux-kbuild, linux-kernel, shuah, javier.carrasco.cruz Date: Fri, 13 Sep 2024 11:52:16 -0400 Subject: [PATCH 0/7] linux-kbuild: fix: process configs set to "y" An assumption made in this script is that the config options do not need to be processed because they will simply be in the new config file. This assumption is incorrect. Process the config entries set to "y" because those config entries might have dependencies set to "m". If a config entry is set to "m" and is not loaded directly into the machine, the script will currently turn off that config entry; however, if that turned off config entry is a dependency for a "y" option. that means the config entry set to "y" will also be turned off later when the conf executive file is called. Here is a model of the problem (arrows show dependency): Original config file Config_1 (m) <-- Config_2 (y) Config_1 is not loaded in this example, so it is turned off. After scripts/kconfig/streamline_config.pl, but before scripts/kconfig/conf Config_1 (n) <-- Config_2 (y) After scripts/kconfig/conf Config_1 (n) <-- Config_2 (n) It should also be noted that any module in the dependency chain will also be turned off, even if that module is loaded directly onto the computer. Here is an example: Original config file Config_1 (m) <-- Config_2 (y) <-- Config_3 (m) Config_3 will be loaded in this example. After scripts/kconfig/streamline_config.pl, but before scripts/kconfig/conf Config_1 (n) <-- Config_2 (y) <-- Config_3 (m) After scripts/kconfig/conf Config_1 (n) <-- Config_2 (n) <-- Config_3 (n) I discovered this problem when I ran "make localmodconfig" on a generic Ubuntu config file. Many hardware devices were not recognized once the kernel was installed and booted. Another way to reproduced the error I had is to run "make localmodconfig" twice. The standard error might display warnings that certain modules should be selected but no config files are turned on that select that module. With the changes in this series patch, all modules are loaded properly and all of the hardware is loaded when the kernel is installed and booted. David Hunter (7): linux-kbuild: fix: config option can be bool linux-kbuild: fix: missing variable operator linux-kbuild: fix: ensure all defaults are tracked linux-kbuild: fix: ensure selected configs were turned on in original linux-kbuild: fix: implement choice for kconfigs linux-kbuild: fix: configs with defaults do not need a prompt linux-kbuild: fix: process config options set to "y" scripts/kconfig/streamline_config.pl | 77 ++++++++++++++++++++++++---- 1 file changed, 66 insertions(+), 11 deletions(-) -- 2.43.0 ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-09-13 17:11 David Hunter @ 2024-09-13 20:39 ` Shuah Khan 0 siblings, 0 replies; 1767+ messages in thread From: Shuah Khan @ 2024-09-13 20:39 UTC (permalink / raw) To: David Hunter, Masahiro Yamada Cc: linux-kbuild, linux-kernel, shuah, javier.carrasco.cruz, Shuah Khan On 9/13/24 11:11, David Hunter wrote: Missing subject line for the cover-letter? > > Date: Fri, 13 Sep 2024 11:52:16 -0400 > Subject: [PATCH 0/7] linux-kbuild: fix: process configs set to "y" > > An assumption made in this script is that the config options do not need > to be processed because they will simply be in the new config file. This > assumption is incorrect. > > Process the config entries set to "y" because those config entries might > have dependencies set to "m". If a config entry is set to "m" and is not > loaded directly into the machine, the script will currently turn off > that config entry; however, if that turned off config entry is a > dependency for a "y" option. that means the config entry set to "y" > will also be turned off later when the conf executive file is called. > > Here is a model of the problem (arrows show dependency): > > Original config file > Config_1 (m) <-- Config_2 (y) > > Config_1 is not loaded in this example, so it is turned off. > After scripts/kconfig/streamline_config.pl, but before scripts/kconfig/conf > Config_1 (n) <-- Config_2 (y) > > After scripts/kconfig/conf > Config_1 (n) <-- Config_2 (n) > > > It should also be noted that any module in the dependency chain will > also be turned off, even if that module is loaded directly onto the > computer. Here is an example: > > Original config file > Config_1 (m) <-- Config_2 (y) <-- Config_3 (m) > > Config_3 will be loaded in this example. > After scripts/kconfig/streamline_config.pl, but before scripts/kconfig/conf > Config_1 (n) <-- Config_2 (y) <-- Config_3 (m) > > After scripts/kconfig/conf > Config_1 (n) <-- Config_2 (n) <-- Config_3 (n) > > > I discovered this problem when I ran "make localmodconfig" on a generic > Ubuntu config file. Many hardware devices were not recognized once the > kernel was installed and booted. Another way to reproduced the error I > had is to run "make localmodconfig" twice. The standard error might display > warnings that certain modules should be selected but no config files are > turned on that select that module. > > With the changes in this series patch, all modules are loaded properly > and all of the hardware is loaded when the kernel is installed and > booted. > > > David Hunter (7): > linux-kbuild: fix: config option can be bool > linux-kbuild: fix: missing variable operator > linux-kbuild: fix: ensure all defaults are tracked > linux-kbuild: fix: ensure selected configs were turned on in original > linux-kbuild: fix: implement choice for kconfigs > linux-kbuild: fix: configs with defaults do not need a prompt > linux-kbuild: fix: process config options set to "y" > > scripts/kconfig/streamline_config.pl | 77 ++++++++++++++++++++++++---- > 1 file changed, 66 insertions(+), 11 deletions(-) > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 2/2] scsi: ufs: core: Fix the code for entering hibernation @ 2024-08-22 20:54 Bao D. Nguyen 2024-08-22 21:08 ` Bart Van Assche 0 siblings, 1 reply; 1767+ messages in thread From: Bao D. Nguyen @ 2024-08-22 20:54 UTC (permalink / raw) To: Bart Van Assche, Martin K . Petersen Cc: linux-scsi, James E.J. Bottomley, Peter Wang, Manivannan Sadhasivam, Avri Altman, Andrew Halaney, Bean Huo, Alim Akhtar, Eric Biggers, Minwoo Im, Maramaina Naresh On 8/22/2024 11:13 AM, Bart Van Assche wrote: > On 8/21/24 6:05 PM, Bao D. Nguyen wrote: >> If I understand correctly, the link is hibernated because we had a >> successful ufshcd_uic_hibern8_enter() earlier. Then the >> ufshcd_uic_pwr_ctrl() is invoked probably from a power mode change >> command? (a callstack would be helpful in this case). > > Hi Bao, > > ufshcd_uic_hibern8_enter() calls ufshcd_uic_pwr_ctrl() directly. The > former function causes the latter to send the UIC_CMD_DME_HIBER_ENTER > command. Although UIC_CMD_DME_HIBER_ENTER causes the link to enter the > hibernation state, the code in ufshcd_uic_pwr_ctrl() for re-enabling > interrupts causes the UFS host controller that I'm testing to exit the > hibernation state. > >> Anyway, accessing the UFSHCI host controller registers space somehow >> affected the M-PHY link state? If my understanding is correct, it >> seems like a hardware issue that we are trying to work around? > > Yes, this is a workaround particular behavior of a particular UFS > controller. Thank you for the clarification, Bart. I am just curious about providing workaround for a hardware issue in the ufs core driver. Sometimes I notice the community is not accepting such a change and push the change to be implemented in the vendor/platform drivers. Now about your workaround, I have the same concern as Bean. For a ufshcd_uic_pwr_ctrl() command, i.e PMC, hibern8_enter/exit() commands, you will get 2 ufshcd_uic_cmd_compl() interrupts or 1 uic completion interrupt with 2 status bits set at once. a. UIC_COMMAND_COMPL is set b. and one of these bits UIC_POWER_MODE || UIC_HIBERNATE_EXIT || UIC_HIBERNATE_ENTER is set, depending on the completed uic command. In your proposed change to ufshcd_uic_cmd_compl(), you are signalling both complete(&cmd->done) and complete(hba->uic_async_done) for a single ufshcd_uic_pwr_ctrl() command which can cause issues. Thanks, Bao > > Thanks, > > Bart. > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 2/2] scsi: ufs: core: Fix the code for entering hibernation 2024-08-22 20:54 [PATCH 2/2] scsi: ufs: core: Fix the code for entering hibernation Bao D. Nguyen @ 2024-08-22 21:08 ` Bart Van Assche 2024-08-23 12:01 ` Manivannan Sadhasivam 0 siblings, 1 reply; 1767+ messages in thread From: Bart Van Assche @ 2024-08-22 21:08 UTC (permalink / raw) To: Bao D. Nguyen, Martin K . Petersen Cc: linux-scsi, James E.J. Bottomley, Peter Wang, Manivannan Sadhasivam, Avri Altman, Andrew Halaney, Bean Huo, Alim Akhtar, Eric Biggers, Minwoo Im, Maramaina Naresh On 8/22/24 1:54 PM, Bao D. Nguyen wrote: > I am just curious about providing workaround for a hardware issue in the > ufs core driver. Sometimes I notice the community is not accepting such > a change and push the change to be implemented in the vendor/platform > drivers. There are two reasons why I propose to implement this workaround as a change for the UFS driver core: - I am not aware of any way to implement the behavior change in a vendor driver without modifying the UFS driver core. - The workaround results in a simplification of the UFS driver core code. More lines are removed from the UFS driver than added. Although it would be possible to select whether the old or the new behavior is selected by introducing yet another host controller quirk, I prefer not to do that because it would make the UFSHCI driver even more complex. > In your proposed change to ufshcd_uic_cmd_compl(), you are signalling > both complete(&cmd->done) and complete(hba->uic_async_done) for a single > ufshcd_uic_pwr_ctrl() command which can cause issues. Please take another look at patch 2/2. With or without this patch applied, only hba->uic_async_done is signaled when a power mode UIC command completes. Thanks, Bart. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 2/2] scsi: ufs: core: Fix the code for entering hibernation 2024-08-22 21:08 ` Bart Van Assche @ 2024-08-23 12:01 ` Manivannan Sadhasivam 2024-08-23 14:23 ` Bart Van Assche 0 siblings, 1 reply; 1767+ messages in thread From: Manivannan Sadhasivam @ 2024-08-23 12:01 UTC (permalink / raw) To: Bart Van Assche Cc: Bao D. Nguyen, Martin K . Petersen, linux-scsi, James E.J. Bottomley, Peter Wang, Avri Altman, Andrew Halaney, Bean Huo, Alim Akhtar, Eric Biggers, Minwoo Im, Maramaina Naresh On Thu, Aug 22, 2024 at 02:08:24PM -0700, Bart Van Assche wrote: > On 8/22/24 1:54 PM, Bao D. Nguyen wrote: > > I am just curious about providing workaround for a hardware issue in the > > ufs core driver. Sometimes I notice the community is not accepting such > > a change and push the change to be implemented in the vendor/platform > > drivers. > > There are two reasons why I propose to implement this workaround as a > change for the UFS driver core: > - I am not aware of any way to implement the behavior change in a vendor > driver without modifying the UFS driver core. Unfortunately you never mentioned which UFS controller this behavior applies to. > - The workaround results in a simplification of the UFS driver core > code. More lines are removed from the UFS driver than added. > This doesn't justify the modification of the UFS code driver for an errantic behavior of a UFS controller. > Although it would be possible to select whether the old or the new > behavior is selected by introducing yet another host controller quirk, I > prefer not to do that because it would make the UFSHCI driver even more > complex. > I strongly believe that using the quirk is the way forward to address this issue. Because this is not a documented behavior to be handled in the core driver and also defeats the purpose of having the quirks in first place. - Mani -- மணிவண்ணன் சதாசிவம் ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 2/2] scsi: ufs: core: Fix the code for entering hibernation 2024-08-23 12:01 ` Manivannan Sadhasivam @ 2024-08-23 14:23 ` Bart Van Assche 2024-08-23 14:58 ` Manivannan Sadhasivam 0 siblings, 1 reply; 1767+ messages in thread From: Bart Van Assche @ 2024-08-23 14:23 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: Bao D. Nguyen, Martin K . Petersen, linux-scsi, James E.J. Bottomley, Peter Wang, Avri Altman, Andrew Halaney, Bean Huo, Alim Akhtar, Eric Biggers, Minwoo Im, Maramaina Naresh On 8/23/24 5:01 AM, Manivannan Sadhasivam wrote: > Unfortunately you never mentioned which UFS controller this behavior applies to. Does your employer allow you to publish detailed information about unreleased SoCs? >> - The workaround results in a simplification of the UFS driver core >> code. More lines are removed from the UFS driver than added. > > This doesn't justify the modification of the UFS code driver for an errantic > behavior of a UFS controller. Patch 2/2 deletes more code than it adds and hence helps to make the UFS driver core easier to maintain. Adding yet another quirk would make the UFS driver core more complicated and hence harder to maintain. >> Although it would be possible to select whether the old or the new >> behavior is selected by introducing yet another host controller quirk, I >> prefer not to do that because it would make the UFSHCI driver even more >> complex. > > I strongly believe that using the quirk is the way forward to address this > issue. Because this is not a documented behavior to be handled in the core > driver and also defeats the purpose of having the quirks in first place. Adding a quirk is not an option in this case because adding a new quirk without code that uses the quirk is not allowed. It may take another year before the code that uses that new quirk is sent upstream because the team that sends Pixel SoC drivers upstream only does this after devices with that SoC are publicly available. Thanks, Bart. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 2/2] scsi: ufs: core: Fix the code for entering hibernation 2024-08-23 14:23 ` Bart Van Assche @ 2024-08-23 14:58 ` Manivannan Sadhasivam 2024-08-23 16:07 ` Bart Van Assche 0 siblings, 1 reply; 1767+ messages in thread From: Manivannan Sadhasivam @ 2024-08-23 14:58 UTC (permalink / raw) To: Bart Van Assche Cc: Bao D. Nguyen, Martin K . Petersen, linux-scsi, James E.J. Bottomley, Peter Wang, Avri Altman, Andrew Halaney, Bean Huo, Alim Akhtar, Eric Biggers, Minwoo Im, Maramaina Naresh On Fri, Aug 23, 2024 at 07:23:57AM -0700, Bart Van Assche wrote: > On 8/23/24 5:01 AM, Manivannan Sadhasivam wrote: > > Unfortunately you never mentioned which UFS controller this behavior applies to. > > Does your employer allow you to publish detailed information about > unreleased SoCs? > Certainly not! But in that case I will explicitly mention that the controller is used in an upcoming SoC or something like that. Otherwise, how can the community know whether you are sending the patch for an existing controller or a secret one? > > > - The workaround results in a simplification of the UFS driver core > > > code. More lines are removed from the UFS driver than added. > > > > This doesn't justify the modification of the UFS code driver for an errantic > > behavior of a UFS controller. > > Patch 2/2 deletes more code than it adds and hence helps to make the UFS > driver core easier to maintain. Adding yet another quirk would make the > UFS driver core more complicated and hence harder to maintain. > IMO nobody can make the UFS driver more complicated. It is complicated at its best :) But you are just applying the plaster in the core code for a quirky behavior of an unreleased SoC. IMO that is not something we would want. Imagine if other vendor also decides to do the same with the argument of removing more lines of code etc... we will end up with a situation where the core code doing something out of the spec for a buggy controller without any mentioning of the quirky behavior. So that will make the code more complex to understand. > > > Although it would be possible to select whether the old or the new > > > behavior is selected by introducing yet another host controller quirk, I > > > prefer not to do that because it would make the UFSHCI driver even more > > > complex. > > > > I strongly believe that using the quirk is the way forward to address this > > issue. Because this is not a documented behavior to be handled in the core > > driver and also defeats the purpose of having the quirks in first place. > > Adding a quirk is not an option in this case because adding a new quirk > without code that uses the quirk is not allowed. It may take another > year before the code that uses that new quirk is sent upstream because > the team that sends Pixel SoC drivers upstream only does this after > devices with that SoC are publicly available. > Then why can't you send the change at that time? We do the same for Qcom SoCs all the time and I'm pretty sure that the Pixel SoCs are no different. At that time, the SoC may get a new revision and we may end up not needing the quirk at all. I'm not saying that it will happen, but that is a common practice among the semiconductor companies. - Mani -- மணிவண்ணன் சதாசிவம் ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 2/2] scsi: ufs: core: Fix the code for entering hibernation 2024-08-23 14:58 ` Manivannan Sadhasivam @ 2024-08-23 16:07 ` Bart Van Assche 2024-08-23 16:48 ` Manivannan Sadhasivam 0 siblings, 1 reply; 1767+ messages in thread From: Bart Van Assche @ 2024-08-23 16:07 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: Bao D. Nguyen, Martin K . Petersen, linux-scsi, James E.J. Bottomley, Peter Wang, Avri Altman, Andrew Halaney, Bean Huo, Alim Akhtar, Eric Biggers, Minwoo Im, Maramaina Naresh On 8/23/24 7:58 AM, Manivannan Sadhasivam wrote: > Then why can't you send the change at that time? We use the Android GKI kernel and any patches must be sent upstream first before these can be considered for inclusion in the GKI kernel. Thanks, Bart. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 2/2] scsi: ufs: core: Fix the code for entering hibernation 2024-08-23 16:07 ` Bart Van Assche @ 2024-08-23 16:48 ` Manivannan Sadhasivam 2024-08-23 18:05 ` Bart Van Assche 0 siblings, 1 reply; 1767+ messages in thread From: Manivannan Sadhasivam @ 2024-08-23 16:48 UTC (permalink / raw) To: Bart Van Assche Cc: Bao D. Nguyen, Martin K . Petersen, linux-scsi, James E.J. Bottomley, Peter Wang, Avri Altman, Andrew Halaney, Bean Huo, Alim Akhtar, Eric Biggers, Minwoo Im, Maramaina Naresh On Fri, Aug 23, 2024 at 09:07:18AM -0700, Bart Van Assche wrote: > On 8/23/24 7:58 AM, Manivannan Sadhasivam wrote: > > Then why can't you send the change at that time? > > We use the Android GKI kernel and any patches must be sent upstream > first before these can be considered for inclusion in the GKI kernel. > But that's the same requirement for other SoC vendors as well. Anyway, these don't justify the fact that the core code should be modified to workaround a controller defect. Please use quirks as like other vendors. - Mani -- மணிவண்ணன் சதாசிவம் ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 2/2] scsi: ufs: core: Fix the code for entering hibernation 2024-08-23 16:48 ` Manivannan Sadhasivam @ 2024-08-23 18:05 ` Bart Van Assche 2024-08-24 2:29 ` Manivannan Sadhasivam 0 siblings, 1 reply; 1767+ messages in thread From: Bart Van Assche @ 2024-08-23 18:05 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: Bao D. Nguyen, Martin K . Petersen, linux-scsi, James E.J. Bottomley, Peter Wang, Avri Altman, Andrew Halaney, Bean Huo, Alim Akhtar, Eric Biggers, Minwoo Im, Maramaina Naresh On 8/23/24 9:48 AM, Manivannan Sadhasivam wrote: > On Fri, Aug 23, 2024 at 09:07:18AM -0700, Bart Van Assche wrote: >> On 8/23/24 7:58 AM, Manivannan Sadhasivam wrote: >>> Then why can't you send the change at that time? >> >> We use the Android GKI kernel and any patches must be sent upstream >> first before these can be considered for inclusion in the GKI kernel. > > But that's the same requirement for other SoC vendors as well. Anyway, these > don't justify the fact that the core code should be modified to workaround a > controller defect. Please use quirks as like other vendors. Let me repeat what I mentioned earlier: * Introducing a new quirk without introducing a user for that quirk is not acceptable because that would involve introducing code that is dead code from the point of view of the upstream kernel. * The UFS driver core is already complicated. If we don't need a new quirk we shouldn't introduce a new quirk. Bart. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 2/2] scsi: ufs: core: Fix the code for entering hibernation 2024-08-23 18:05 ` Bart Van Assche @ 2024-08-24 2:29 ` Manivannan Sadhasivam 2024-08-24 2:48 ` Bart Van Assche 0 siblings, 1 reply; 1767+ messages in thread From: Manivannan Sadhasivam @ 2024-08-24 2:29 UTC (permalink / raw) To: Bart Van Assche Cc: Bao D. Nguyen, Martin K . Petersen, linux-scsi, James E.J. Bottomley, Peter Wang, Avri Altman, Andrew Halaney, Bean Huo, Alim Akhtar, Eric Biggers, Minwoo Im, Maramaina Naresh On Fri, Aug 23, 2024 at 11:05:12AM -0700, Bart Van Assche wrote: > On 8/23/24 9:48 AM, Manivannan Sadhasivam wrote: > > On Fri, Aug 23, 2024 at 09:07:18AM -0700, Bart Van Assche wrote: > > > On 8/23/24 7:58 AM, Manivannan Sadhasivam wrote: > > > > Then why can't you send the change at that time? > > > > > > We use the Android GKI kernel and any patches must be sent upstream > > > first before these can be considered for inclusion in the GKI kernel. > > > > But that's the same requirement for other SoC vendors as well. Anyway, these > > don't justify the fact that the core code should be modified to workaround a > > controller defect. Please use quirks as like other vendors. > > Let me repeat what I mentioned earlier: > * Introducing a new quirk without introducing a user for that quirk is > not acceptable because that would involve introducing code that is > dead code from the point of view of the upstream kernel. As I pointed out earlier, you should just submit the quirk change when you are submitting your driver. But you said that for GKI requirement you are doing the change in core driver. But again, that is applicable for other vendors as well. What if other vendors start adding the workaround in the core driver citing GKI requirement (provided it also removes some code as you justified)? Will it be acceptable? NO. > * The UFS driver core is already complicated. If we don't need a new > quirk we shouldn't introduce a new quirk. > Sorry, the quirk is a quirk. All the existing quirks can be worked around in the core driver in some way. But we have the quirk mechanisms to specifically not to do that to avoid polluting the core code which has to follow the spec. Moreover, this workaround you are adding is not at all common for other controllers. So this definitely doesn't justify modifying the core code. IMO adding more code alone will not make a driver complicated, but changing the logic will. - Mani -- மணிவண்ணன் சதாசிவம் ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 2/2] scsi: ufs: core: Fix the code for entering hibernation 2024-08-24 2:29 ` Manivannan Sadhasivam @ 2024-08-24 2:48 ` Bart Van Assche 2024-08-24 3:03 ` Manivannan Sadhasivam 0 siblings, 1 reply; 1767+ messages in thread From: Bart Van Assche @ 2024-08-24 2:48 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: Bao D. Nguyen, Martin K . Petersen, linux-scsi, James E.J. Bottomley, Peter Wang, Avri Altman, Andrew Halaney, Bean Huo, Alim Akhtar, Eric Biggers, Minwoo Im, Maramaina Naresh On 8/23/24 7:29 PM, Manivannan Sadhasivam wrote: > What if other vendors start adding the workaround in the core driver citing GKI > requirement (provided it also removes some code as you justified)? Will it be > acceptable? NO. It's not up to you to define new rules for upstream kernel development. Anyone is allowed to publish patches that rework kernel code, whether or not the purpose of such a patch is to work around a SoC bug. Additionally, it has already happened that one of your colleagues submitted a workaround for a SoC bug to the UFS core driver. From the description of commit 0f52fcb99ea2 ("scsi: ufs: Try to save power mode change and UIC cmd completion timeout"): "This is to deal with the scenario in which completion has been raised but the one waiting for the completion cannot be awaken in time due to kernel scheduling problem." That description makes zero sense to me. My conclusion from commit 0f52fcb99ea2 is that it is a workaround for a bug in a UFS host controller, namely that a particular UFS host controller not always generates a UIC completion interrupt when it should. Bart. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 2/2] scsi: ufs: core: Fix the code for entering hibernation 2024-08-24 2:48 ` Bart Van Assche @ 2024-08-24 3:03 ` Manivannan Sadhasivam 2024-08-26 6:48 ` Can Guo 0 siblings, 1 reply; 1767+ messages in thread From: Manivannan Sadhasivam @ 2024-08-24 3:03 UTC (permalink / raw) To: Bart Van Assche Cc: Bao D. Nguyen, Martin K . Petersen, linux-scsi, James E.J. Bottomley, Peter Wang, Avri Altman, Andrew Halaney, Bean Huo, Alim Akhtar, Eric Biggers, Minwoo Im, Maramaina Naresh On Fri, Aug 23, 2024 at 07:48:50PM -0700, Bart Van Assche wrote: > On 8/23/24 7:29 PM, Manivannan Sadhasivam wrote: > > What if other vendors start adding the workaround in the core driver citing GKI > > requirement (provided it also removes some code as you justified)? Will it be > > acceptable? NO. > > It's not up to you to define new rules for upstream kernel development. I'm not framing new rules, but just pointing out the common practice. > Anyone is allowed to publish patches that rework kernel code, whether > or not the purpose of such a patch is to work around a SoC bug. > Yes, at the same time if that code deviates from the norm, then anyone can complain. We are all working towards making the code better. > Additionally, it has already happened that one of your colleagues > submitted a workaround for a SoC bug to the UFS core driver. > From the description of commit 0f52fcb99ea2 ("scsi: ufs: Try to save > power mode change and UIC cmd completion timeout"): "This is to deal > with the scenario in which completion has been raised but the one > waiting for the completion cannot be awaken in time due to kernel > scheduling problem." That description makes zero sense to me. My > conclusion from commit 0f52fcb99ea2 is that it is a workaround for a > bug in a UFS host controller, namely that a particular UFS host > controller not always generates a UIC completion interrupt when it > should. > 0f52fcb99ea2 was submitted in 2020 before I started contributing to UFS driver seriously. But the description of that commit never mentioned any issue with the controller. It vaguely mentions 'kernel scheduling problem' which I don't know how to interpret. If I were looking into the code at that time, I would've definitely asked for clarity during the review phase. But there is no need to take it as an example. I can only assert the fact that working around the controller defect in core code when we already have quirks for the same purpose defeats the purpose of quirks. And it will encourage other people to start changing the core code in the future thus bypassing the quirks. But I'm not a maintainer of this part of the code. So I cannot definitely stop you from getting this patch merged. I'll leave it up to Martin to decide. - Mani -- மணிவண்ணன் சதாசிவம் ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-08-24 3:03 ` Manivannan Sadhasivam @ 2024-08-26 6:48 ` Can Guo 0 siblings, 0 replies; 1767+ messages in thread From: Can Guo @ 2024-08-26 6:48 UTC (permalink / raw) To: Manivannan Sadhasivam, Bart Van Assche Cc: Bao D. Nguyen, Martin K . Petersen, linux-scsi, James E.J. Bottomley, Peter Wang, Avri Altman, Andrew Halaney, Bean Huo, Alim Akhtar, Eric Biggers, Minwoo Im, Maramaina Naresh On 1/1/1970 8:00 AM, wrote: > On Fri, Aug 23, 2024 at 07:48:50PM -0700, Bart Van Assche wrote: >> On 8/23/24 7:29 PM, Manivannan Sadhasivam wrote: >>> What if other vendors start adding the workaround in the core driver citing GKI >>> requirement (provided it also removes some code as you justified)? Will it be >>> acceptable? NO. >> It's not up to you to define new rules for upstream kernel development. > I'm not framing new rules, but just pointing out the common practice. > >> Anyone is allowed to publish patches that rework kernel code, whether >> or not the purpose of such a patch is to work around a SoC bug. >> > Yes, at the same time if that code deviates from the norm, then anyone can > complain. We are all working towards making the code better. > >> Additionally, it has already happened that one of your colleagues >> submitted a workaround for a SoC bug to the UFS core driver. >> From the description of commit 0f52fcb99ea2 ("scsi: ufs: Try to save >> power mode change and UIC cmd completion timeout"): "This is to deal >> with the scenario in which completion has been raised but the one >> waiting for the completion cannot be awaken in time due to kernel >> scheduling problem." That description makes zero sense to me. My >> conclusion from commit 0f52fcb99ea2 is that it is a workaround for a >> bug in a UFS host controller, namely that a particular UFS host >> controller not always generates a UIC completion interrupt when it >> should. >> > 0f52fcb99ea2 was submitted in 2020 before I started contributing to UFS driver > seriously. But the description of that commit never mentioned any issue with the > controller. It vaguely mentions 'kernel scheduling problem' which I don't know > how to interpret. If I were looking into the code at that time, I would've > definitely asked for clarity during the review phase. 0f52fcb99ea2 is my commit, apologize for the confusion due to poor commit msg. What we were trying to fix was not a SoC BUG. More background for this change: from our customer side, we used to hit corner cases where the UIC command is sent, UFS host controller generates the UIC command completion interrupt fine, then UIC completion IRQ handler fires and calls the complete(), however the completion timeout error still happens. In this case, UFS, UFS host and UFS driver are the victims. And whatever could cause this scheduling problem should be fixed properly by the right PoC, but we thought making UFS driver robust in this spot would be good for all of the users who may face the similar issue, hence the change. Thanks, Can Guo. > > But there is no need to take it as an example. I can only assert the fact that > working around the controller defect in core code when we already have quirks > for the same purpose defeats the purpose of quirks. And it will encourage other > people to start changing the core code in the future thus bypassing the quirks. > > But I'm not a maintainer of this part of the code. So I cannot definitely stop > you from getting this patch merged. I'll leave it up to Martin to decide. > > - Mani > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2024-08-16 11:07 Xi Ruoyao
2024-08-19 12:40 ` Huacai Chen
2024-08-27 9:45 ` Re: Jason A. Donenfeld
0 siblings, 2 replies; 1767+ messages in thread
From: Xi Ruoyao @ 2024-08-16 11:07 UTC (permalink / raw)
To: Jason A . Donenfeld, Huacai Chen, WANG Xuerui
Cc: Xi Ruoyao, linux-crypto, loongarch, Jinyang He, Tiezhu Yang,
Arnd Bergmann
Subject: [PATCH v3 0/2] LoongArch: Implement getrandom() in vDSO
For the rationale to implement getrandom() in vDSO see [1].
The vDSO getrandom() needs a stack-less ChaCha20 implementation, so we
need to add architecture-specific code and wire it up with the generic
code. Both generic LoongArch implementation and Loongson SIMD eXtension
based implementation are added. To dispatch them at runtime without
invoking cpucfg on each call, the alternative runtime patching mechanism
is extended to cover the vDSO.
The implementation is tested with the kernel selftests added by the last
patch in [1]. I had to make some adjustments to make it work on
LoongArch (see [2], I've not submitted the changes as at now because I'm
unsure about the KHDR_INCLUDES addition). The vdso_test_getrandom
bench-single result:
vdso: 25000000 times in 0.647855257 seconds (generic)
vdso: 25000000 times in 0.601068605 seconds (LSX)
libc: 25000000 times in 6.948168864 seconds
syscall: 25000000 times in 6.990265548 seconds
The vdso_test_getrandom bench-multi result:
vdso: 25000000 x 256 times in 35.322187834 seconds (generic)
vdso: 25000000 x 256 times in 29.183885426 seconds (LSX)
libc: 25000000 x 256 times in 356.628428409 seconds
syscall: 25000000 x 256 times in 334.764602866 seconds
[1]:https://lore.kernel.org/all/20240712014009.281406-1-Jason@zx2c4.com/
[2]:https://github.com/xry111/linux/commits/xry111/la-vdso-v3/
[v2]->v3:
- Add a generic LoongArch implementation for which LSX isn't needed.
v1->v2:
- Properly send the series to the list.
[v2]:https://lore.kernel.org/all/20240815133357.35829-1-xry111@xry111.site/
Xi Ruoyao (3):
LoongArch: vDSO: Wire up getrandom() vDSO implementation
LoongArch: Perform alternative runtime patching on vDSO
LoongArch: vDSO: Add LSX implementation of vDSO getrandom()
arch/loongarch/Kconfig | 1 +
arch/loongarch/include/asm/vdso/getrandom.h | 47 ++++
arch/loongarch/include/asm/vdso/vdso.h | 8 +
arch/loongarch/kernel/asm-offsets.c | 10 +
arch/loongarch/kernel/vdso.c | 14 +-
arch/loongarch/vdso/Makefile | 6 +
arch/loongarch/vdso/memset.S | 24 ++
arch/loongarch/vdso/vdso.lds.S | 7 +
arch/loongarch/vdso/vgetrandom-chacha-lsx.S | 162 +++++++++++++
arch/loongarch/vdso/vgetrandom-chacha.S | 252 ++++++++++++++++++++
arch/loongarch/vdso/vgetrandom.c | 19 ++
11 files changed, 549 insertions(+), 1 deletion(-)
create mode 100644 arch/loongarch/include/asm/vdso/getrandom.h
create mode 100644 arch/loongarch/vdso/memset.S
create mode 100644 arch/loongarch/vdso/vgetrandom-chacha-lsx.S
create mode 100644 arch/loongarch/vdso/vgetrandom-chacha.S
create mode 100644 arch/loongarch/vdso/vgetrandom.c
--
2.46.0
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2024-08-16 11:07 Xi Ruoyao @ 2024-08-19 12:40 ` Huacai Chen 2024-08-19 13:01 ` Re: Jason A. Donenfeld 2024-08-19 15:22 ` Re: Xi Ruoyao 2024-08-27 9:45 ` Re: Jason A. Donenfeld 1 sibling, 2 replies; 1767+ messages in thread From: Huacai Chen @ 2024-08-19 12:40 UTC (permalink / raw) To: Xi Ruoyao Cc: Jason A . Donenfeld, WANG Xuerui, linux-crypto, loongarch, Jinyang He, Tiezhu Yang, Arnd Bergmann Hi, Ruoyao, Why no subject? On Fri, Aug 16, 2024 at 7:07 PM Xi Ruoyao <xry111@xry111.site> wrote: > > Subject: [PATCH v3 0/2] LoongArch: Implement getrandom() in vDSO > > For the rationale to implement getrandom() in vDSO see [1]. > > The vDSO getrandom() needs a stack-less ChaCha20 implementation, so we > need to add architecture-specific code and wire it up with the generic > code. Both generic LoongArch implementation and Loongson SIMD eXtension > based implementation are added. To dispatch them at runtime without > invoking cpucfg on each call, the alternative runtime patching mechanism > is extended to cover the vDSO. > > The implementation is tested with the kernel selftests added by the last > patch in [1]. I had to make some adjustments to make it work on > LoongArch (see [2], I've not submitted the changes as at now because I'm > unsure about the KHDR_INCLUDES addition). The vdso_test_getrandom > bench-single result: > > vdso: 25000000 times in 0.647855257 seconds (generic) > vdso: 25000000 times in 0.601068605 seconds (LSX) > libc: 25000000 times in 6.948168864 seconds > syscall: 25000000 times in 6.990265548 seconds > > The vdso_test_getrandom bench-multi result: > > vdso: 25000000 x 256 times in 35.322187834 seconds (generic) > vdso: 25000000 x 256 times in 29.183885426 seconds (LSX) > libc: 25000000 x 256 times in 356.628428409 seconds > syscall: 25000000 x 256 times in 334.764602866 seconds I don't see significant improvements about LSX here, so I prefer to just use the generic version to avoid complexity (I remember Linus said the whole of __vdso_getrandom is not very useful). Huacai > > [1]:https://lore.kernel.org/all/20240712014009.281406-1-Jason@zx2c4.com/ > [2]:https://github.com/xry111/linux/commits/xry111/la-vdso-v3/ > > [v2]->v3: > - Add a generic LoongArch implementation for which LSX isn't needed. > > v1->v2: > - Properly send the series to the list. > > [v2]:https://lore.kernel.org/all/20240815133357.35829-1-xry111@xry111.site/ > > Xi Ruoyao (3): > LoongArch: vDSO: Wire up getrandom() vDSO implementation > LoongArch: Perform alternative runtime patching on vDSO > LoongArch: vDSO: Add LSX implementation of vDSO getrandom() > > arch/loongarch/Kconfig | 1 + > arch/loongarch/include/asm/vdso/getrandom.h | 47 ++++ > arch/loongarch/include/asm/vdso/vdso.h | 8 + > arch/loongarch/kernel/asm-offsets.c | 10 + > arch/loongarch/kernel/vdso.c | 14 +- > arch/loongarch/vdso/Makefile | 6 + > arch/loongarch/vdso/memset.S | 24 ++ > arch/loongarch/vdso/vdso.lds.S | 7 + > arch/loongarch/vdso/vgetrandom-chacha-lsx.S | 162 +++++++++++++ > arch/loongarch/vdso/vgetrandom-chacha.S | 252 ++++++++++++++++++++ > arch/loongarch/vdso/vgetrandom.c | 19 ++ > 11 files changed, 549 insertions(+), 1 deletion(-) > create mode 100644 arch/loongarch/include/asm/vdso/getrandom.h > create mode 100644 arch/loongarch/vdso/memset.S > create mode 100644 arch/loongarch/vdso/vgetrandom-chacha-lsx.S > create mode 100644 arch/loongarch/vdso/vgetrandom-chacha.S > create mode 100644 arch/loongarch/vdso/vgetrandom.c > > -- > 2.46.0 > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-08-19 12:40 ` Huacai Chen @ 2024-08-19 13:01 ` Jason A. Donenfeld 2024-08-19 15:22 ` Re: Xi Ruoyao 2024-08-19 15:22 ` Re: Xi Ruoyao 1 sibling, 1 reply; 1767+ messages in thread From: Jason A. Donenfeld @ 2024-08-19 13:01 UTC (permalink / raw) To: Huacai Chen Cc: Xi Ruoyao, WANG Xuerui, linux-crypto, loongarch, Jinyang He, Tiezhu Yang, Arnd Bergmann > I don't see significant improvements about LSX here, so I prefer to > just use the generic version to avoid complexity (I remember Linus > said the whole of __vdso_getrandom is not very useful). I'm inclined to feel the same way, at least for now. Let's just go with one implementation -- the generic one -- and then we can see if optimization really makes sense later. I suspect the large speedup we're already getting from being in the vDSO is already sufficient for purposes. Regards, Jason ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-08-19 13:01 ` Re: Jason A. Donenfeld @ 2024-08-19 15:22 ` Xi Ruoyao 2024-08-19 15:54 ` Re: Xi Ruoyao 0 siblings, 1 reply; 1767+ messages in thread From: Xi Ruoyao @ 2024-08-19 15:22 UTC (permalink / raw) To: Jason A. Donenfeld, Huacai Chen Cc: WANG Xuerui, linux-crypto, loongarch, Jinyang He, Tiezhu Yang, Arnd Bergmann On Mon, 2024-08-19 at 13:01 +0000, Jason A. Donenfeld wrote: > > I don't see significant improvements about LSX here, so I prefer to > > just use the generic version to avoid complexity (I remember Linus > > said the whole of __vdso_getrandom is not very useful). > > I'm inclined to feel the same way, at least for now. Let's just go with > one implementation -- the generic one -- and then we can see if > optimization really makes sense later. I suspect the large speedup we're > already getting from being in the vDSO is already sufficient for > purposes. Ok I'll drop the 2nd and 3rd patches in the next version. But I'm puzzled why the LSX implementation isn't much faster, maybe I made some mistake in it? -- Xi Ruoyao <xry111@xry111.site> School of Aerospace Science and Technology, Xidian University ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-08-19 15:22 ` Re: Xi Ruoyao @ 2024-08-19 15:54 ` Xi Ruoyao 0 siblings, 0 replies; 1767+ messages in thread From: Xi Ruoyao @ 2024-08-19 15:54 UTC (permalink / raw) To: Jason A. Donenfeld, Huacai Chen Cc: WANG Xuerui, linux-crypto, loongarch, Jinyang He, Tiezhu Yang, Arnd Bergmann On Mon, 2024-08-19 at 23:22 +0800, Xi Ruoyao wrote: > On Mon, 2024-08-19 at 13:01 +0000, Jason A. Donenfeld wrote: > > > I don't see significant improvements about LSX here, so I prefer to > > > just use the generic version to avoid complexity (I remember Linus > > > said the whole of __vdso_getrandom is not very useful). > > > > I'm inclined to feel the same way, at least for now. Let's just go with > > one implementation -- the generic one -- and then we can see if > > optimization really makes sense later. I suspect the large speedup we're > > already getting from being in the vDSO is already sufficient for > > purposes. > > Ok I'll drop the 2nd and 3rd patches in the next version. But I'm > puzzled why the LSX implementation isn't much faster, maybe I made some > mistake in it? After some thinking this seems making sense: the LoongArch desktop processors have 4 ALUs able to perform the scalar add/rot/xor operations, and the throughput is already maximized for ChaCha20 due to the data dependency. The advantage of LSX seems just to avoid reloading key from the memory (because the register file is large enough to hold a copy of it). Perhaps LSX will be much better on those embedded processors with 2 ALUs and 1 SIMD unit (if they don't downclock with heavy SIMD load), but I don't have one for testing. -- Xi Ruoyao <xry111@xry111.site> School of Aerospace Science and Technology, Xidian University ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-08-19 12:40 ` Huacai Chen 2024-08-19 13:01 ` Re: Jason A. Donenfeld @ 2024-08-19 15:22 ` Xi Ruoyao 1 sibling, 0 replies; 1767+ messages in thread From: Xi Ruoyao @ 2024-08-19 15:22 UTC (permalink / raw) To: Huacai Chen Cc: Jason A . Donenfeld, WANG Xuerui, linux-crypto, loongarch, Jinyang He, Tiezhu Yang, Arnd Bergmann On Mon, 2024-08-19 at 20:40 +0800, Huacai Chen wrote: > Hi, Ruoyao, > > Why no subject? Because I misused git send-email (again) :(. -- Xi Ruoyao <xry111@xry111.site> School of Aerospace Science and Technology, Xidian University ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-08-16 11:07 Xi Ruoyao 2024-08-19 12:40 ` Huacai Chen @ 2024-08-27 9:45 ` Jason A. Donenfeld 1 sibling, 0 replies; 1767+ messages in thread From: Jason A. Donenfeld @ 2024-08-27 9:45 UTC (permalink / raw) To: Xi Ruoyao Cc: Huacai Chen, WANG Xuerui, linux-crypto, loongarch, Jinyang He, Tiezhu Yang, Arnd Bergmann Hey, Per https://lore.kernel.org/all/Zs2c_9Z6sFMNJs1O@zx2c4.com/ , you may want to rebase on random.git and send a v4 series. Hopefully now it's just a single patch. Jason ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2024-08-14 8:03 howard_wang 2024-08-14 15:04 ` Stephen Hemminger 0 siblings, 1 reply; 1767+ messages in thread From: howard_wang @ 2024-08-14 8:03 UTC (permalink / raw) To: dev [-- Attachment #1: 0001-net-r8169-add-PMD-driver-skeleton.patch --] [-- Type: application/octet-stream, Size: 8056 bytes --] From 7e61211f99445dab158fc955b363b5c622a6f0ef Mon Sep 17 00:00:00 2001 From: Howard Wang <howard_wang@realsil.com.cn> Date: Mon, 5 Aug 2024 15:52:04 +0800 Subject: [PATCH] net/r8169: add PMD driver skeleton Meson build infrastructure, r8169_ethdev minimal skeleton, header with Realtek NIC device and vendor IDs. Signed-off-by: Howard Wang <howard_wang@realsil.com.cn> --- MAINTAINERS | 7 ++ drivers/net/meson.build | 1 + drivers/net/r8169/meson.build | 6 ++ drivers/net/r8169/r8169_base.h | 15 +++ drivers/net/r8169/r8169_ethdev.c | 180 +++++++++++++++++++++++++++++++ drivers/net/r8169/r8169_ethdev.h | 40 +++++++ 6 files changed, 249 insertions(+) create mode 100644 drivers/net/r8169/meson.build create mode 100644 drivers/net/r8169/r8169_base.h create mode 100644 drivers/net/r8169/r8169_ethdev.c create mode 100644 drivers/net/r8169/r8169_ethdev.h diff --git a/MAINTAINERS b/MAINTAINERS index c5a703b5c0..5f9eccc43f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1076,6 +1076,13 @@ F: drivers/net/memif/ F: doc/guides/nics/memif.rst F: doc/guides/nics/features/memif.ini +Realtek r8169 +M: Howard Wang <howard_wang@realsil.com.cn> +M: ChunHao Lin <hau@realtek.com> +M: Xing Wang <xing_wang@realsil.com.cn> +M: Realtek NIC SW <pro_nic_dpdk@realtek.com> +F: drivers/net/r8169 + Crypto Drivers -------------- diff --git a/drivers/net/meson.build b/drivers/net/meson.build index fb6d34b782..fddcf39655 100644 --- a/drivers/net/meson.build +++ b/drivers/net/meson.build @@ -53,6 +53,7 @@ drivers = [ 'pfe', 'qede', 'ring', + 'r8169', 'sfc', 'softnic', 'tap', diff --git a/drivers/net/r8169/meson.build b/drivers/net/r8169/meson.build new file mode 100644 index 0000000000..5fcd871787 --- /dev/null +++ b/drivers/net/r8169/meson.build @@ -0,0 +1,6 @@ +# SPDX-License-Identifier: BSD-3-Clause +# Copyright(c) 2024 Realtek Corporation. All rights reserved + +sources = files( + 'r8169_ethdev.c', +) \ No newline at end of file diff --git a/drivers/net/r8169/r8169_base.h b/drivers/net/r8169/r8169_base.h new file mode 100644 index 0000000000..5d219a7966 --- /dev/null +++ b/drivers/net/r8169/r8169_base.h @@ -0,0 +1,15 @@ +/* SPDX-License-Identifier: BSD-3-Clause + * Copyright(c) 2024 Realtek Corporation. All rights reserved + */ + +#ifndef _R8169_BASE_H_ +#define _R8169_BASE_H_ + +typedef uint8_t u8; +typedef uint16_t u16; +typedef uint32_t u32; +typedef uint64_t u64; + +#define PCI_VENDOR_ID_REALTEK 0x10EC + +#endif \ No newline at end of file diff --git a/drivers/net/r8169/r8169_ethdev.c b/drivers/net/r8169/r8169_ethdev.c new file mode 100644 index 0000000000..2288361d0c --- /dev/null +++ b/drivers/net/r8169/r8169_ethdev.c @@ -0,0 +1,180 @@ +/* SPDX-License-Identifier: BSD-3-Clause + * Copyright(c) 2024 Realtek Corporation. All rights reserved + */ + +#include <sys/queue.h> +#include <stdio.h> +#include <errno.h> +#include <stdint.h> +#include <stdarg.h> + +#include <rte_eal.h> + +#include <rte_string_fns.h> +#include <rte_common.h> +#include <rte_interrupts.h> +#include <rte_byteorder.h> +#include <rte_log.h> +#include <rte_debug.h> +#include <rte_pci.h> +#include <bus_pci_driver.h> +#include <rte_ether.h> +#include <ethdev_driver.h> +#include <ethdev_pci.h> +#include <rte_memory.h> +#include <rte_malloc.h> +#include <dev_driver.h> + +#include "r8169_ethdev.h" +#include "r8169_base.h" + +static int rtl_dev_configure(struct rte_eth_dev *dev __rte_unused); +static int rtl_dev_start(struct rte_eth_dev *dev); +static int rtl_dev_stop(struct rte_eth_dev *dev); +static int rtl_dev_reset(struct rte_eth_dev *dev); +static int rtl_dev_close(struct rte_eth_dev *dev); + +/* + * The set of PCI devices this driver supports + */ +static const struct rte_pci_id pci_id_r8169_map[] = { + { RTE_PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8125) }, + { RTE_PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8162) }, + { RTE_PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8126) }, + { RTE_PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x5000) }, + {.vendor_id = 0, /* sentinel */ }, +}; + +static const struct eth_dev_ops rtl_eth_dev_ops = { + .dev_configure = rtl_dev_configure, + .dev_start = rtl_dev_start, + .dev_stop = rtl_dev_stop, + .dev_close = rtl_dev_close, + .dev_reset = rtl_dev_reset, +}; + +static int +rtl_dev_configure(struct rte_eth_dev *dev __rte_unused) +{ + return 0; +} + +/* + * Configure device link speed and setup link. + * It returns 0 on success. + */ +static int +rtl_dev_start(struct rte_eth_dev *dev) +{ + struct rtl_adapter *adapter = RTL_DEV_PRIVATE(dev); + struct rtl_hw *hw = &adapter->hw; + + hw->adapter_stopped = 0; + + return 0; +} + +/* + * Stop device: disable RX and TX functions to allow for reconfiguring. + */ +static int +rtl_dev_stop(struct rte_eth_dev *dev) +{ + struct rtl_adapter *adapter = RTL_DEV_PRIVATE(dev); + struct rtl_hw *hw = &adapter->hw; + + if (hw->adapter_stopped) + return 0; + + hw->adapter_stopped = 1; + dev->data->dev_started = 0; + + return 0; +} + +/* + * Reset and stop device. + */ +static int +rtl_dev_close(struct rte_eth_dev *dev) +{ + int ret_stp; + + if (rte_eal_process_type() != RTE_PROC_PRIMARY) + return 0; + + ret_stp = rtl_dev_stop(dev); + + return ret_stp; +} + +static int +rtl_dev_init(struct rte_eth_dev *dev) +{ + struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev); + struct rte_intr_handle *intr_handle = pci_dev->intr_handle; + struct rtl_adapter *adapter = RTL_DEV_PRIVATE(dev); + struct rtl_hw *hw = &adapter->hw; + + dev->dev_ops = &rtl_eth_dev_ops; + //dev->tx_pkt_burst = &rtl_xmit_pkts; + //dev->rx_pkt_burst = &rtl_recv_pkts; + + /* For secondary processes, the primary process has done all the work */ + if (rte_eal_process_type() != RTE_PROC_PRIMARY) + return 0; + + rte_eth_copy_pci_info(dev, pci_dev); + + return 0; +} + +static int +rtl_dev_uninit(struct rte_eth_dev *dev) +{ + if (rte_eal_process_type() != RTE_PROC_PRIMARY) + return -EPERM; + + rtl_dev_close(dev); + + return 0; +} + +static int +rtl_dev_reset(struct rte_eth_dev *dev) +{ + int ret; + + ret = rtl_dev_uninit(dev); + if (ret) + return ret; + + ret = rtl_dev_init(dev); + + return ret; +} + +static int +rtl_pci_probe(struct rte_pci_driver *pci_drv __rte_unused, + struct rte_pci_device *pci_dev) +{ + return rte_eth_dev_pci_generic_probe(pci_dev, sizeof(struct rtl_adapter), + rtl_dev_init); +} + +static int +rtl_pci_remove(struct rte_pci_device *pci_dev) +{ + return rte_eth_dev_pci_generic_remove(pci_dev, rtl_dev_uninit); +} + +static struct rte_pci_driver rte_r8169_pmd = { + .id_table = pci_id_r8169_map, + .drv_flags = RTE_PCI_DRV_NEED_MAPPING | RTE_PCI_DRV_INTR_LSC, + .probe = rtl_pci_probe, + .remove = rtl_pci_remove, +}; + +RTE_PMD_REGISTER_PCI(net_r8169, rte_r8169_pmd); +RTE_PMD_REGISTER_PCI_TABLE(net_r8169, pci_id_r8169_map); +RTE_PMD_REGISTER_KMOD_DEP(net_r8169, "* igb_uio | uio_pci_generic | vfio-pci"); diff --git a/drivers/net/r8169/r8169_ethdev.h b/drivers/net/r8169/r8169_ethdev.h new file mode 100644 index 0000000000..ab0ad28e28 --- /dev/null +++ b/drivers/net/r8169/r8169_ethdev.h @@ -0,0 +1,40 @@ +/* SPDX-License-Identifier: BSD-3-Clause + * Copyright(c) 2024 Realtek Corporation. All rights reserved + */ + +#ifndef _R8169_ETHDEV_H_ +#define _R8169_ETHDEV_H_ + +#include <stdint.h> +#include <stdbool.h> + +#include <rte_ethdev.h> +#include <rte_ethdev_core.h> + +#include "r8169_base.h" + +struct rtl_hw { + u8 adapter_stopped; +}; + +struct rtl_sw_stats { + u64 tx_packets; + u64 tx_bytes; + u64 tx_errors; + u64 rx_packets; + u64 rx_bytes; + u64 rx_errors; +}; + +struct rtl_adapter { + struct rtl_hw hw; + struct rtl_sw_stats sw_stats; +}; + +#define RTL_DEV_PRIVATE(eth_dev) \ + ((struct rtl_adapter *)((eth_dev)->data->dev_private)) + +uint16_t rtl_xmit_pkts(void *txq, struct rte_mbuf **tx_pkts, uint16_t nb_pkts); +uint16_t rtl_recv_pkts(void *rxq, struct rte_mbuf **rx_pkts, uint16_t nb_pkts); + +#endif \ No newline at end of file -- 2.34.1 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2024-08-14 8:03 howard_wang @ 2024-08-14 15:04 ` Stephen Hemminger 0 siblings, 0 replies; 1767+ messages in thread From: Stephen Hemminger @ 2024-08-14 15:04 UTC (permalink / raw) To: howard_wang; +Cc: dev On Wed, 14 Aug 2024 16:03:41 +0800 <howard_wang@realsil.com.cn> wrote: > iff --git a/drivers/net/r8169/r8169_base.h b/drivers/net/r8169/r8169_base.h > new file mode 100644 > index 0000000000..5d219a7966 > --- /dev/null > +++ b/drivers/net/r8169/r8169_base.h > @@ -0,0 +1,15 @@ > +/* SPDX-License-Identifier: BSD-3-Clause > + * Copyright(c) 2024 Realtek Corporation. All rights reserved > + */ > + > +#ifndef _R8169_BASE_H_ > +#define _R8169_BASE_H_ > + > +typedef uint8_t u8; > +typedef uint16_t u16; > +typedef uint32_t u32; > +typedef uint64_t u64; > + > +#define PCI_VENDOR_ID_REALTEK 0x10EC > + > +#endif > \ No newline at end of file Fix you editor setup, all files should end with newline. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2024-07-15 21:06 Phil Dennis-Jordan
2024-07-16 6:07 ` Akihiko Odaki
0 siblings, 1 reply; 1767+ messages in thread
From: Phil Dennis-Jordan @ 2024-07-15 21:06 UTC (permalink / raw)
To: qemu-devel, pbonzini, agraf, graf, marcandre.lureau, berrange,
thuth, philmd, peter.maydell, akihiko.odaki, phil, lists
Date: Mon, 15 Jul 2024 21:07:12 +0200
Subject: [PATCH 00/26] hw/display/apple-gfx: New macOS PV Graphics device
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This sequence of patches integrates the paravirtualised graphics device
implemented by macOS's ParavirtualizedGraphics.Framework into Qemu.
Combined with the guest drivers which ship with macOS versions 11 and up,
this allows the guest OS to use the host's GPU for hardware accelerated
3D graphics, GPGPU compute (both using the 'Metal' graphics API), and
window compositing.
Some background:
----------------
The device exposed by the ParavirtualizedGraphics.Framework's (henceforth
PVG) public API consists of a PCI device with a single memory-mapped BAR;
the VMM is expected to pass reads and writes through to the framework, and
to forward interrupts emenating from it to the guest VM.
The bulk of data exchange between host and guest occurs via shared memory,
however. For this purpose, PVG makes callbacks to VMM code for allocating,
mapping, unmapping, and deallocating "task" memory ranges. Each task
represents a contiguous host virtual address range, and PVG expects the
VMM to map specific guest system memory ranges to these host addresses via
subsequent map callbacks. Multiple tasks can exist at a time, each with
many mappings.
Data is exchanged via an undocumented, Apple-proprietary protocol. The
PVG API only acts as a facilitator for establishing the communication
mechanism. This is perhaps not ideal, and among other things means it
only works on macOS hosts, but it's the only serious option we've got for
good performance and quality graphics with macOS guests at this time.
The first iterations of this PVG integration into Qemu were developed
by Alexander Graf as part of his "vmapple" machine patch series for
supporting aarch64 macOS guests, and posted to qemu-devel in June and
August 2023:
https://lore.kernel.org/all/20230830161425.91946-1-graf@amazon.com/T/
This integration mimics the "vmapple"/"apple-gfx" variant of the PVG device
used by Apple's own VMM, Virtualization.framework. This variant does not use
PCI but acts as a direct MMIO system device; there are two MMIO ranges, one
behaving identically to the PCI BAR, while the other's functionality is
exposed by private APIs in the PVG framework. It is only available on aarch64
macOS hosts.
I had prior to this simultaneously and independently developed my own PVG
integration for Qemu using the public PCI device APIs, with x86-64 and
corresponding macOS guests and hosts as the target. After some months of
use in production, I was slowly reviewing the code and readying it for
upstreaming around the time Alexander posted his vmapple patches.
I ended up reviewing the vmapple PVG code in detail; I identified a number
of issues with it (mainly thanks to my prior trial-and-error working with
the framework) but overall I thought it a better basis for refinement
than my own version:
- It implemented the vmapple variant of the device. I thought it better to
port the part I understood well (PCI variant) to this than trying to port
the part I didn't understand well (MMIO vmapple variant) to my own code.
- The code was already tidier than my own.
It also became clear in out-of-band communication that Alexander would
probably not end up having the time to see the patch through to inclusion,
and was happy for me to start making changes and to integrate my PCI code.
It's taken a while, but I'm happy with the result and think it will be a
welcome addition for anyone running macOS VMs.
What doesn't work:
------------------
* State (de-)serialisation and thus migration. There is no fundamental
technical obstacle to this. PVG supports saving and loading device state.
I have simply not had the resources to implement (and crucially, test it)
it yet.
* Setting the list of display modes via a property is currently only
implemented on the PCI version, which is the only one readily testable
without the out-of-tree vmapple patches. (See review notes for patch 24)
* End-to-end GPU-only rendering. After the host GPU has rendered the guest's
screen, the framebuffer is copied into a system memory buffer (surface).
When using the Qemu Cocoa UI, this buffer is drawn by the CPU into a GPU
texture used for hardware window compositing. It would be vastly more
efficient to retain the Metal texture and pass it directly through to the
Cocoa window. We currently have no mechanism for doing so; it would need
to be similar to the end-to-end OpenGL rendering support, with the added
complication that Metal textures are Objective-C types and would need to
traverse the plain C code of the Qemu display subsystem.
* Dirty region detection. Similarly, the whole framebuffer is marked modified
even if there has only been a small change. This hurts network data volume
when using VNC.
* Multi-head support. PVG allows "connecting" more than one virtual display.
This integration currently always uses exactly 1 display.
* The vmapple/aarch64 variant of the device is only testable with Alexander's
vmapple machine type patch set. I've been maintaining this out-of-tree and
have made a few improvements, but it doesn't yet run smoothly. (Graphics
work fine with this code, issues are with other devices.) I can push my
current draft to a git forge if anyone wants to test with them. I'm
definitely hoping to eventually resolve the remaining problems and submit
a revised version of that patch set as well.
I think we can live without these for the moment, and I'd prefer to work on
them only if and when the baseline functionality has been merged.
Patch review notes:
-------------------
I have aimed to submit the patches roughly in order of descending importance
and increasing debatability. From patch 18 it becomes usable and useful in
practice without further modification. Patches 19-23 fix issues that only occur
in certain host configurations or that can otherwise be worked around. Patch
24 is more of an RFC; patch 26 is needed if recently submitted Cocoa UI patches
end up being merged.
Brief meta-discussion of specific patches and groups of patches:
01: I have retained Alexander Graf's original patch intact as far as
possible as patch 01. My only modifications are those required for
fixing rebase conflicts.
02: Resolves build errors caused by upstream API changes since original
patch submission.
03: This moves the device code to hw/display from its original hw/vmapple.
With the PCI variant added later, it doesn't make much sense to put
this inside a machine type directory.
04-13: These patches address issues identified during code review in the
original e-mail threads as well as my own review.
14-15: These patches split the monolithic source file into a common core and
vmapple/mmio specific parts.
NOTE: checkpatch.pl complains about #ifdef __OBJC__ in the header file.
This is needed for allowing the file to be #included from pure C.
Ensuring that isn't currently critical, but I expect it to be useful
in future.
16-17: Preparation for x86-64. The x86-64 variant of PVG seems to behave
slightly differently than the aarch64 version in terms of threading
and control flow edge cases. We need to do some things asynchronously
to avoid deadlock and performance problems.
18: The PCI variant. This builds on the split from 14/15 and the async
changes to create the PVG PCI device which works with x86-64 macOS
guests.
19-23: Fixes for various additional problems and limitations. Without these
the PVG device will only work with the Cocoa UI, on Macs which
have an integrated (shared memory) GPU only, and mouse cursors will
be slightly off, for example.
24: QOM property for specifying the display mode list (resolutions) the
device will report to the guest. I checked other display devices and
found none supported this, though I personally find it very useful.
I'm wondering whether this should be a more generic feature optionally
usable by any display device in Qemu?
25: Adding myself as maintainer for the PVG code, and reviewer for HVF.
26: Required if/when Akihiko Odaki's pending patch for removing
dpy_cursor_define_supported is merged.
I don't know if it's useful/wise to keep these all as separate patches.
I'm happy to squash any number or groups of them. Personally, I find
smaller patches easier to review, and the git blame history acts as
a sort of documentation, so I've kept them for now.
Alexander Graf (1):
hw/vmapple/apple-gfx: Introduce ParavirtualizedGraphics.Framework
support
Phil Dennis-Jordan (25):
hw/vmapple/apple-gfx: BQL renaming update
hw/display/apple-gfx: Moved from hw/vmapple/
hw/display/apple-gfx: uses DEFINE_TYPES macro
hw/display/apple-gfx: native -> little endian memory ops
hw/display/apple-gfx: Removes dead/superfluous code
hw/display/apple-gfx: Makes set_mode thread & memory safe
hw/display/apple-gfx: Adds migration blocker
hw/display/apple-gfx: Wraps ObjC autorelease code in pool
hw/display/apple-gfx: Fixes ObjC new/init misuse, plugs leaks
hw/display/apple-gfx: Uses ObjC category extension for private
property
hw/display/apple-gfx: Task memory mapping cleanup
hw/display/apple-gfx: Defines PGTask_s struct instead of casting
hw/display/apple-gfx: Refactoring of realize function
hw/display/apple-gfx: Separates generic & vmapple-specific
functionality
hw/display/apple-gfx: Asynchronous MMIO writes on x86-64
hw/display/apple-gfx: Asynchronous rendering and graphics update
hw/display/apple-gfx: Adds PCI implementation
ui/cocoa: Adds non-app runloop on main thread mode
hw/display/apple-gfx: Fixes cursor hotspot handling
hw/display/apple-gfx: Implements texture syncing for non-UMA GPUs
hw/display/apple-gfx: Replaces magic number with queried MMIO length
hw/display/apple-gfx: Host GPU picking improvements
hw/display/apple-gfx: Adds configurable mode list
MAINTAINERS: Add myself as maintainer for apple-gfx, reviewer for HVF
hw/display/apple-gfx: Removes UI pointer support check
MAINTAINERS | 7 +
hw/display/Kconfig | 13 +
hw/display/apple-gfx-pci.m | 166 +++++++++
hw/display/apple-gfx-vmapple.m | 194 ++++++++++
hw/display/apple-gfx.h | 72 ++++
hw/display/apple-gfx.m | 659 +++++++++++++++++++++++++++++++++
hw/display/meson.build | 3 +
hw/display/trace-events | 26 ++
include/qemu-main.h | 2 +
meson.build | 4 +
ui/cocoa.m | 15 +-
11 files changed, 1159 insertions(+), 2 deletions(-)
create mode 100644 hw/display/apple-gfx-pci.m
create mode 100644 hw/display/apple-gfx-vmapple.m
create mode 100644 hw/display/apple-gfx.h
create mode 100644 hw/display/apple-gfx.m
--
2.39.3 (Apple Git-146)
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2024-07-15 21:06 Phil Dennis-Jordan @ 2024-07-16 6:07 ` Akihiko Odaki 2024-07-17 11:16 ` Re: Phil Dennis-Jordan 0 siblings, 1 reply; 1767+ messages in thread From: Akihiko Odaki @ 2024-07-16 6:07 UTC (permalink / raw) To: Phil Dennis-Jordan, qemu-devel, pbonzini, agraf, graf, marcandre.lureau, berrange, thuth, philmd, peter.maydell, lists On 2024/07/16 6:06, Phil Dennis-Jordan wrote: > Date: Mon, 15 Jul 2024 21:07:12 +0200 > Subject: [PATCH 00/26] hw/display/apple-gfx: New macOS PV Graphics device > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > This sequence of patches integrates the paravirtualised graphics device > implemented by macOS's ParavirtualizedGraphics.Framework into Qemu. > Combined with the guest drivers which ship with macOS versions 11 and up, > this allows the guest OS to use the host's GPU for hardware accelerated > 3D graphics, GPGPU compute (both using the 'Metal' graphics API), and > window compositing. > > Some background: > ---------------- > > The device exposed by the ParavirtualizedGraphics.Framework's (henceforth > PVG) public API consists of a PCI device with a single memory-mapped BAR; > the VMM is expected to pass reads and writes through to the framework, and > to forward interrupts emenating from it to the guest VM. > > The bulk of data exchange between host and guest occurs via shared memory, > however. For this purpose, PVG makes callbacks to VMM code for allocating, > mapping, unmapping, and deallocating "task" memory ranges. Each task > represents a contiguous host virtual address range, and PVG expects the > VMM to map specific guest system memory ranges to these host addresses via > subsequent map callbacks. Multiple tasks can exist at a time, each with > many mappings. > > Data is exchanged via an undocumented, Apple-proprietary protocol. The > PVG API only acts as a facilitator for establishing the communication > mechanism. This is perhaps not ideal, and among other things means it > only works on macOS hosts, but it's the only serious option we've got for > good performance and quality graphics with macOS guests at this time. > > The first iterations of this PVG integration into Qemu were developed > by Alexander Graf as part of his "vmapple" machine patch series for > supporting aarch64 macOS guests, and posted to qemu-devel in June and > August 2023: > > https://lore.kernel.org/all/20230830161425.91946-1-graf@amazon.com/T/ > > This integration mimics the "vmapple"/"apple-gfx" variant of the PVG device > used by Apple's own VMM, Virtualization.framework. This variant does not use > PCI but acts as a direct MMIO system device; there are two MMIO ranges, one > behaving identically to the PCI BAR, while the other's functionality is > exposed by private APIs in the PVG framework. It is only available on aarch64 > macOS hosts. > > I had prior to this simultaneously and independently developed my own PVG > integration for Qemu using the public PCI device APIs, with x86-64 and > corresponding macOS guests and hosts as the target. After some months of > use in production, I was slowly reviewing the code and readying it for > upstreaming around the time Alexander posted his vmapple patches. > > I ended up reviewing the vmapple PVG code in detail; I identified a number > of issues with it (mainly thanks to my prior trial-and-error working with > the framework) but overall I thought it a better basis for refinement > than my own version: > > - It implemented the vmapple variant of the device. I thought it better to > port the part I understood well (PCI variant) to this than trying to port > the part I didn't understand well (MMIO vmapple variant) to my own code. > - The code was already tidier than my own. > > It also became clear in out-of-band communication that Alexander would > probably not end up having the time to see the patch through to inclusion, > and was happy for me to start making changes and to integrate my PCI code. Hi, Thanks for continuing his effort. Please submit a patch series that includes his patches. Please also merge fixes for his patches into them. This saves the effort to review the obsolete code and keeps git bisect working. Regards, Akihiko Odaki ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-07-16 6:07 ` Akihiko Odaki @ 2024-07-17 11:16 ` Phil Dennis-Jordan 0 siblings, 0 replies; 1767+ messages in thread From: Phil Dennis-Jordan @ 2024-07-17 11:16 UTC (permalink / raw) To: Akihiko Odaki Cc: qemu-devel, pbonzini, agraf, graf, marcandre.lureau, berrange, thuth, philmd, peter.maydell, lists [-- Attachment #1: Type: text/plain, Size: 717 bytes --] On Tue, 16 Jul 2024 at 08:07, Akihiko Odaki <akihiko.odaki@daynix.com> wrote: > Hi, > > Thanks for continuing his effort. > > Please submit a patch series that includes his patches. Please also > merge fixes for his patches into them. This saves the effort to review > the obsolete code and keeps git bisect working. > > Sorry about that - it looks like (a) my edits to the cover letter messed something up and (b) patch 1 got email-filtered somewhere along the way for having the "wrong" From: address. I've submitted v2 with most patches squashed into patch 1, whose authorship I've also changed to myself (with Co-authored-by tag for the original code) so hopefully this time around it shows up OK. Thanks, Phil [-- Attachment #2: Type: text/html, Size: 1122 bytes --] ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2024-07-14 19:59 raschupkin.ri
2024-07-15 20:20 ` Joe Lawrence
2024-07-16 17:33 ` Re: Song Liu
0 siblings, 2 replies; 1767+ messages in thread
From: raschupkin.ri @ 2024-07-14 19:59 UTC (permalink / raw)
To: live-patching, joe.lawrence, pmladek, mbenes, jikos, jpoimboe
[PATCH] livepatch: support of modifying refcount_t without underflow after unpatch
CVE fixes sometimes add refcount_inc/dec() pairs to the code with existing refcount_t.
Two problems arise when applying live-patch in this case:
1) After refcount_t is being inc() during system is live-patched, after unpatch the counter value will not be valid, as corresponing dec() would never be called.
2) Underflows are possible in runtime in case dec() is called before corresponding inc() in the live-patched code.
Proposed kprefcount_t functions are using following approach to solve these two problems:
1) In addition to original refcount_t, temporary refcount_t is allocated, and after unpatch it is just removed. This way system is safe with correct refcounting while patch is applied, and no underflow would happend after unpatch.
2) For inc/dec() added by live-patch code, one bit in reference-holder structure is used (unsigned char *ref_holder, kprefholder_flag). In case dec() is called first, it is just ignored as ref_holder bit would still not be initialized.
API is defined include/linux/livepatch_refcount.h:
typedef struct kprefcount_struct {
refcount_t *refcount;
refcount_t kprefcount;
spinlock_t lock;
} kprefcount_t;
kprefcount_t *kprefcount_alloc(refcount_t *refcount, gfp_t flags);
void kprefcount_free(kprefcount_t *kp_ref);
int kprefcount_read(kprefcount_t *kp_ref);
void kprefcount_inc(kprefcount_t *kp_ref, unsigned char *ref_holder, int kprefholder_flag);
void kprefcount_dec(kprefcount_t *kp_ref, unsigned char *ref_holder, int kprefholder_flag);
bool kprefcount_dec_and_test(kprefcount_t *kp_ref, unsigned char *ref_holder, int kprefholder_flag);
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2024-07-14 19:59 raschupkin.ri @ 2024-07-15 20:20 ` Joe Lawrence 2024-07-15 22:45 ` Re: Roman Rashchupkin ` (2 more replies) 2024-07-16 17:33 ` Re: Song Liu 1 sibling, 3 replies; 1767+ messages in thread From: Joe Lawrence @ 2024-07-15 20:20 UTC (permalink / raw) To: raschupkin.ri; +Cc: live-patching, pmladek, mbenes, jikos, jpoimboe On Sun, Jul 14, 2024 at 09:59:32PM +0200, raschupkin.ri@gmail.com wrote: > > [PATCH] livepatch: support of modifying refcount_t without underflow after unpatch > > CVE fixes sometimes add refcount_inc/dec() pairs to the code with existing refcount_t. > Two problems arise when applying live-patch in this case: > 1) After refcount_t is being inc() during system is live-patched, after unpatch the counter value will not be valid, as corresponing dec() would never be called. > 2) Underflows are possible in runtime in case dec() is called before corresponding inc() in the live-patched code. > > Proposed kprefcount_t functions are using following approach to solve these two problems: > 1) In addition to original refcount_t, temporary refcount_t is allocated, and after unpatch it is just removed. This way system is safe with correct refcounting while patch is applied, and no underflow would happend after unpatch. > 2) For inc/dec() added by live-patch code, one bit in reference-holder structure is used (unsigned char *ref_holder, kprefholder_flag). In case dec() is called first, it is just ignored as ref_holder bit would still not be initialized. > > > API is defined include/linux/livepatch_refcount.h: > > typedef struct kprefcount_struct { > refcount_t *refcount; > refcount_t kprefcount; > spinlock_t lock; > } kprefcount_t; > > kprefcount_t *kprefcount_alloc(refcount_t *refcount, gfp_t flags); > void kprefcount_free(kprefcount_t *kp_ref); > int kprefcount_read(kprefcount_t *kp_ref); > void kprefcount_inc(kprefcount_t *kp_ref, unsigned char *ref_holder, int kprefholder_flag); > void kprefcount_dec(kprefcount_t *kp_ref, unsigned char *ref_holder, int kprefholder_flag); > bool kprefcount_dec_and_test(kprefcount_t *kp_ref, unsigned char *ref_holder, int kprefholder_flag); > Hi Roman, Can you point to a specific upstream commit that this API facilitated a livepatch conversion? That would make a good addition to the Documentation/livepatch/ side of a potential v2. But first, let me see if I understand the problem correctly. Let's say points A and A' below represent the original kernel code reference get/put pairing in task execution flow. A livepatch adds a new get/put pair, B and B' in the middle like so: --- execution flow ---> -- A B B' A' --> There are potential issues if the livepatch is (de)activated mid-sequence, between the new pairings: problem 1: -- A . B' A' --> 'B, but no B = extra put! ^ livepatch is activated here problem 2: -- A B . A' --> B, but no B' = extra get! ^ livepatch is deactivated here The first thing that comes to mind is that this might be solved using the existing shadow variable API. When the livepatch takes the new reference (B), it could create a new <struct, NEW_REF> shadow variable instance. The livepatch code to return the reference (B') would then check on the shadow variable existence before doing so. This would solve problem 1. The second problem is a little trickier. Perhaps the shadow variable approach still works as long as a pre-unpatch hook* were to iterate through all the <*, NEW_REF> shadow variable instances and returned their reference before freeing the shadow variable and declaring the livepatch inactive. I believe that would align the reference counts with original kernel code expectations. * note this approach probably requires atomic-replace livepatches, so only a single pre-unpatch hook is ever executed. Also, the proposed patchset looks like it creates a parallel reference counting structure... does this mean that the livepatch will need to update *all* reference counting calls for the API to work (so points A, B, B', and A' in my ascii-art above)? This question loops back to my first point about a real-world example that can be added to Documentation/livepatch/, much like the ones found in the shadow-vars.rst file. Thanks, -- Joe ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-07-15 20:20 ` Joe Lawrence @ 2024-07-15 22:45 ` Roman Rashchupkin 2024-07-16 9:28 ` Re: Nicolai Stange [not found] ` <66963d60.170a0220.70a9a.8866SMTPIN_ADDED_BROKEN@mx.google.com> 2 siblings, 0 replies; 1767+ messages in thread From: Roman Rashchupkin @ 2024-07-15 22:45 UTC (permalink / raw) To: Joe Lawrence Cc: live-patching, pmladek, mbenes, jikos, jpoimboe, quic_jjohnson Hello. About upstream commits creating live-patching for which this API would facilitate, I could reference several CVEs: - CVE-2023-5633 "drm/vmwgfx: Keep a gem reference to user bos in surfaces" https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=91398b413d03660fd5828f7b4abc64e884b98069 drm_gem_object_get(&vbo->tbo.base);/drm_gem_object_put(&tmp_buf->tbo.base); - CVE-2023-6932 "ipv4: igmp: fix refcnt uaf issue when receiving igmp query packet" https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e2b706c69190 refcount_inc_not_zero(&im->refcnt)/ip_ma_put(im); - CVE-2022-20566 "Bluetooth: L2CAP: Fix use-after-free caused by l2cap_chan_put" https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d0be8347c623e0ac4202a1d4e0373882821f56b0 kref_get_unless_zero(&c->kref)/l2cap_chan_put(chan) Only in all of these 3 cases I can remember now, refcount_t is mostly used inside wrapper-functions, and from the top of my head now I don't remember CVEs that plainly add refcount_inc()/dec(). In case the proposed patch is merged, maybe CVE-2023-5633 would be suited best for documentation, or source git could be searched for better example. Two types of problems that you classify, are exactly what I'm attempting to solve for added refcount_inc/dec() in the code that is added by live-patch. Let's continue with your numbering (1) and (2) for simplicity of discussion. Concerning problem (1), shadow variables are certainly could be used instead of my refholder bit in reference-holder structures. That's only my preference for simplicity that live-patches code is so often lacking, to use one bit in existing structures instead of hash-table based shadow variables. But certainly shadow-variables are also a good approach, and could be used instead of mine (unsigned char *ref_holder, int kprefholder_flag) in the kprefcount_t API. About problem (2), iterating through all shadow-variable/refholder instances would also work, but it is just unnecessary processing during unpatch. In my approach the second kprefcount variable with lifetime of live-patch being applied is used, it provides correct refcounting during live-patch, but the main idea is that this variable can be just safely removed at the unpatch. The only complication could be values of refholder bits, that must be reset at live-patch apply, or probably it is more simple to implement at the unpatch, as all kprefcount_t structs are allocated by patch-code. --- Roman Rashchupkin On 7/15/24 22:20, Joe Lawrence wrote: > On Sun, Jul 14, 2024 at 09:59:32PM +0200, raschupkin.ri@gmail.com wrote: >> [PATCH] livepatch: support of modifying refcount_t without underflow after unpatch >> >> CVE fixes sometimes add refcount_inc/dec() pairs to the code with existing refcount_t. >> Two problems arise when applying live-patch in this case: >> 1) After refcount_t is being inc() during system is live-patched, after unpatch the counter value will not be valid, as corresponing dec() would never be called. >> 2) Underflows are possible in runtime in case dec() is called before corresponding inc() in the live-patched code. >> >> Proposed kprefcount_t functions are using following approach to solve these two problems: >> 1) In addition to original refcount_t, temporary refcount_t is allocated, and after unpatch it is just removed. This way system is safe with correct refcounting while patch is applied, and no underflow would happend after unpatch. >> 2) For inc/dec() added by live-patch code, one bit in reference-holder structure is used (unsigned char *ref_holder, kprefholder_flag). In case dec() is called first, it is just ignored as ref_holder bit would still not be initialized. >> >> >> API is defined include/linux/livepatch_refcount.h: >> >> typedef struct kprefcount_struct { >> refcount_t *refcount; >> refcount_t kprefcount; >> spinlock_t lock; >> } kprefcount_t; >> >> kprefcount_t *kprefcount_alloc(refcount_t *refcount, gfp_t flags); >> void kprefcount_free(kprefcount_t *kp_ref); >> int kprefcount_read(kprefcount_t *kp_ref); >> void kprefcount_inc(kprefcount_t *kp_ref, unsigned char *ref_holder, int kprefholder_flag); >> void kprefcount_dec(kprefcount_t *kp_ref, unsigned char *ref_holder, int kprefholder_flag); >> bool kprefcount_dec_and_test(kprefcount_t *kp_ref, unsigned char *ref_holder, int kprefholder_flag); >> > Hi Roman, > > Can you point to a specific upstream commit that this API facilitated a > livepatch conversion? That would make a good addition to the > Documentation/livepatch/ side of a potential v2. > > But first, let me see if I understand the problem correctly. Let's say > points A and A' below represent the original kernel code reference > get/put pairing in task execution flow. A livepatch adds a new get/put > pair, B and B' in the middle like so: > > --- execution flow ---> > -- A B B' A' --> > > There are potential issues if the livepatch is (de)activated > mid-sequence, between the new pairings: > > problem 1: > -- A . B' A' --> 'B, but no B = extra put! > ^ livepatch is activated here > > problem 2: > -- A B . A' --> B, but no B' = extra get! > ^ livepatch is deactivated here > > > The first thing that comes to mind is that this might be solved using > the existing shadow variable API. When the livepatch takes the new > reference (B), it could create a new <struct, NEW_REF> shadow variable > instance. The livepatch code to return the reference (B') would then > check on the shadow variable existence before doing so. This would > solve problem 1. > > The second problem is a little trickier. Perhaps the shadow variable > approach still works as long as a pre-unpatch hook* were to iterate > through all the <*, NEW_REF> shadow variable instances and returned > their reference before freeing the shadow variable and declaring the > livepatch inactive. I believe that would align the reference counts > with original kernel code expectations. > > * note this approach probably requires atomic-replace livepatches, so > only a single pre-unpatch hook is ever executed. > > > Also, the proposed patchset looks like it creates a parallel reference > counting structure... does this mean that the livepatch will need to > update *all* reference counting calls for the API to work (so points A, > B, B', and A' in my ascii-art above)? This question loops back to my > first point about a real-world example that can be added to > Documentation/livepatch/, much like the ones found in the > shadow-vars.rst file. > > Thanks, > > -- > Joe > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-07-15 20:20 ` Joe Lawrence 2024-07-15 22:45 ` Re: Roman Rashchupkin @ 2024-07-16 9:28 ` Nicolai Stange [not found] ` <66963d60.170a0220.70a9a.8866SMTPIN_ADDED_BROKEN@mx.google.com> 2 siblings, 0 replies; 1767+ messages in thread From: Nicolai Stange @ 2024-07-16 9:28 UTC (permalink / raw) To: Joe Lawrence Cc: raschupkin.ri, live-patching, pmladek, mbenes, jikos, jpoimboe Hi all, Joe Lawrence <joe.lawrence@redhat.com> writes: > On Sun, Jul 14, 2024 at 09:59:32PM +0200, raschupkin.ri@gmail.com wrote: >> > But first, let me see if I understand the problem correctly. Let's say > points A and A' below represent the original kernel code reference > get/put pairing in task execution flow. A livepatch adds a new get/put > pair, B and B' in the middle like so: > > --- execution flow ---> > -- A B B' A' --> > > There are potential issues if the livepatch is (de)activated > mid-sequence, between the new pairings: > > problem 1: > -- A . B' A' --> 'B, but no B = extra put! > ^ livepatch is activated here > > problem 2: > -- A B . A' --> B, but no B' = extra get! > ^ livepatch is deactivated here I can confirm that this scenario happens quite often with real world CVE fixes and there's currently no way to implement such changes safely from a livepatch. But I also believe this is an instance of a broader problem class we attempted to solve with that "enhanced" states API proposed and discussed at LPC ([1], there's a link to a recording at the bottom). For reference, see Petr's POC from [2]. > The first thing that comes to mind is that this might be solved using > the existing shadow variable API. Same. > When the livepatch takes the new > reference (B), it could create a new <struct, NEW_REF> shadow variable > instance. The livepatch code to return the reference (B') would then > check on the shadow variable existence before doing so. This would > solve problem 1. > > The second problem is a little trickier. Perhaps the shadow variable > approach still works as long as a pre-unpatch hook* were to iterate > through all the <*, NEW_REF> shadow variable instances and returned > their reference before freeing the shadow variable and declaring the > livepatch inactive. I think the problem of consistently maintaining shadowed reference counts (or anything shadowed for that matter) could be solved with the help of aforementioned states API enhancements, so I would propose to revive Petr's IMO more generic patchset as an alternative. Thoughts? Thanks, Nicolai [1] https://lpc.events/event/17/contributions/1541/ [2] https://lore.kernel.org/r/20231110170428.6664-1-pmladek@suse.com -- SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany GF: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg) ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <66963d60.170a0220.70a9a.8866SMTPIN_ADDED_BROKEN@mx.google.com>]
* Re: [not found] ` <66963d60.170a0220.70a9a.8866SMTPIN_ADDED_BROKEN@mx.google.com> @ 2024-07-16 9:53 ` Roman Rashchupkin 2024-07-25 14:52 ` Re: Joe Lawrence 0 siblings, 1 reply; 1767+ messages in thread From: Roman Rashchupkin @ 2024-07-16 9:53 UTC (permalink / raw) To: Nicolai Stange, Joe Lawrence Cc: live-patching, pmladek, mbenes, jikos, jpoimboe >> The first thing that comes to mind is that this might be solved using >> the existing shadow variable API. > Same. I just don't have enough experience using live-patch shadow-variables, so I agree that probably that's a better general solution for problem (1) of refcount underflow, than mine refholder flags. > I can confirm that this scenario happens quite often with real world CVE > fixes and there's currently no way to implement such changes safely from > a livepatch. But I also believe this is an instance of a broader problem > class we attempted to solve with that "enhanced" states API proposed and > discussed at LPC ([1], there's a link to a recording at the bottom). For > reference, see Petr's POC from [2]. About (2) of incorrect refcount_t value left after unpatch, it seems as a bit different and more special problem with counters, compared to the support of live-patch states, which can be solved for refcount_t in a simpler way. IMHO adding temporary kprefcount_t variable for the time of live-patch being applied, modifying only this kprefcount_t variable by all added in livepatch inc()/dec(), provides correct refcounting during live-patch is applied. Then at the unpatch this temporaray variable can just safely be discarded. This way the only additional code to live-patch would be functions with original refcount_dec_and_test() calls. --- Roman Rashchupkin On 7/16/24 11:28, Nicolai Stange wrote: > Hi all, > > Joe Lawrence <joe.lawrence@redhat.com> writes: > >> On Sun, Jul 14, 2024 at 09:59:32PM +0200, raschupkin.ri@gmail.com wrote: >> But first, let me see if I understand the problem correctly. Let's say >> points A and A' below represent the original kernel code reference >> get/put pairing in task execution flow. A livepatch adds a new get/put >> pair, B and B' in the middle like so: >> >> --- execution flow ---> >> -- A B B' A' --> >> >> There are potential issues if the livepatch is (de)activated >> mid-sequence, between the new pairings: >> >> problem 1: >> -- A . B' A' --> 'B, but no B = extra put! >> ^ livepatch is activated here >> >> problem 2: >> -- A B . A' --> B, but no B' = extra get! >> ^ livepatch is deactivated here > I can confirm that this scenario happens quite often with real world CVE > fixes and there's currently no way to implement such changes safely from > a livepatch. But I also believe this is an instance of a broader problem > class we attempted to solve with that "enhanced" states API proposed and > discussed at LPC ([1], there's a link to a recording at the bottom). For > reference, see Petr's POC from [2]. > > >> The first thing that comes to mind is that this might be solved using >> the existing shadow variable API. > Same. > > >> When the livepatch takes the new >> reference (B), it could create a new <struct, NEW_REF> shadow variable >> instance. The livepatch code to return the reference (B') would then >> check on the shadow variable existence before doing so. This would >> solve problem 1. >> >> The second problem is a little trickier. Perhaps the shadow variable >> approach still works as long as a pre-unpatch hook* were to iterate >> through all the <*, NEW_REF> shadow variable instances and returned >> their reference before freeing the shadow variable and declaring the >> livepatch inactive. > I think the problem of consistently maintaining shadowed reference > counts (or anything shadowed for that matter) could be solved with the > help of aforementioned states API enhancements, so I would propose to > revive Petr's IMO more generic patchset as an alternative. > > Thoughts? > > Thanks, > > Nicolai > > [1] https://lpc.events/event/17/contributions/1541/ > [2] https://lore.kernel.org/r/20231110170428.6664-1-pmladek@suse.com > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-07-16 9:53 ` Re: Roman Rashchupkin @ 2024-07-25 14:52 ` Joe Lawrence 0 siblings, 0 replies; 1767+ messages in thread From: Joe Lawrence @ 2024-07-25 14:52 UTC (permalink / raw) To: Roman Rashchupkin, Nicolai Stange Cc: live-patching, pmladek, mbenes, jikos, jpoimboe On 7/16/24 05:53, Roman Rashchupkin wrote: >>> The first thing that comes to mind is that this might be solved using >>> the existing shadow variable API. > >> Same. > > I just don't have enough experience using live-patch shadow-variables, > so I agree that probably that's a better general solution for problem > (1) of refcount underflow, than mine refholder flags. > Yes, a general solution could cover the same problem but for different datatypes, including locks, mutex, etc. >> I can confirm that this scenario happens quite often with real world CVE >> fixes and there's currently no way to implement such changes safely from >> a livepatch. But I also believe this is an instance of a broader problem >> class we attempted to solve with that "enhanced" states API proposed and >> discussed at LPC ([1], there's a link to a recording at the bottom). For >> reference, see Petr's POC from [2]. Thanks for the link -- I thought of that grand-unified shadow/callback/states patch but couldn't find the latest version. (I see that Miroslav has just resurrected it with a fresh review, too.) >> I think the problem of consistently maintaining shadowed reference >> counts (or anything shadowed for that matter) could be solved with the >> help of aforementioned states API enhancements, so I would propose to >> revive Petr's IMO more generic patchset as an alternative. >> >> Thoughts? >> I definitely think the states API enhancement could be used to handle the cases here via shadow variables. In the meantime, are you using the kprefcount_t API currently via a livepatch support module? i.e. we don't need this in the kernel asap to solve these problems, right? -- Joe ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-07-14 19:59 raschupkin.ri 2024-07-15 20:20 ` Joe Lawrence @ 2024-07-16 17:33 ` Song Liu 1 sibling, 0 replies; 1767+ messages in thread From: Song Liu @ 2024-07-16 17:33 UTC (permalink / raw) To: raschupkin.ri Cc: live-patching, joe.lawrence, pmladek, mbenes, jikos, jpoimboe On Mon, Jul 15, 2024 at 4:00 AM <raschupkin.ri@gmail.com> wrote: > > > [PATCH] livepatch: support of modifying refcount_t without underflow after unpatch > > CVE fixes sometimes add refcount_inc/dec() pairs to the code with existing refcount_t. > Two problems arise when applying live-patch in this case: > 1) After refcount_t is being inc() during system is live-patched, after unpatch the counter value will not be valid, as corresponing dec() would never be called. > 2) Underflows are possible in runtime in case dec() is called before corresponding inc() in the live-patched code. > > Proposed kprefcount_t functions are using following approach to solve these two problems: > 1) In addition to original refcount_t, temporary refcount_t is allocated, and after unpatch it is just removed. This way system is safe with correct refcounting while patch is applied, and no underflow would happend after unpatch. > 2) For inc/dec() added by live-patch code, one bit in reference-holder structure is used (unsigned char *ref_holder, kprefholder_flag). In case dec() is called first, it is just ignored as ref_holder bit would still not be initialized. > > > API is defined include/linux/livepatch_refcount.h: > > typedef struct kprefcount_struct { > refcount_t *refcount; > refcount_t kprefcount; > spinlock_t lock; > } kprefcount_t; > > kprefcount_t *kprefcount_alloc(refcount_t *refcount, gfp_t flags); > void kprefcount_free(kprefcount_t *kp_ref); > int kprefcount_read(kprefcount_t *kp_ref); > void kprefcount_inc(kprefcount_t *kp_ref, unsigned char *ref_holder, int kprefholder_flag); > void kprefcount_dec(kprefcount_t *kp_ref, unsigned char *ref_holder, int kprefholder_flag); > bool kprefcount_dec_and_test(kprefcount_t *kp_ref, unsigned char *ref_holder, int kprefholder_flag); IIUC, kprefcount alone is not enough to solve the two issues. We still need some mechanism to manage the "ref_holder". Shadow variable is probably the best option here. The primary idea here is to enhance the refcount with a map. This may be too expensive in term memory consumption in some use cases. Overall, I don't think this change adds much more value on top of shadow variable. Thanks, Song ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH v2 09/60] i2c: cp2615: reword according to newest specification @ 2024-07-06 11:20 Wolfram Sang 2024-07-10 6:41 ` [PATCH v3] " Wolfram Sang 0 siblings, 1 reply; 1767+ messages in thread From: Wolfram Sang @ 2024-07-06 11:20 UTC (permalink / raw) To: linux-i2c; +Cc: Wolfram Sang, Bence Csókás, Andi Shyti, linux-kernel Change the wording of this driver wrt. the newest I2C v7 and SMBus 3.2 specifications and replace "master/slave" with more appropriate terms. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> --- drivers/i2c/busses/i2c-cp2615.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/i2c/busses/i2c-cp2615.c b/drivers/i2c/busses/i2c-cp2615.c index cf3747d87034..315a37155401 100644 --- a/drivers/i2c/busses/i2c-cp2615.c +++ b/drivers/i2c/busses/i2c-cp2615.c @@ -60,7 +60,7 @@ enum cp2615_i2c_status { CP2615_CFG_LOCKED = -6, /* read_len or write_len out of range */ CP2615_INVALID_PARAM = -4, - /* I2C slave did not ACK in time */ + /* I2C target did not ACK in time */ CP2615_TIMEOUT, /* I2C bus busy */ CP2615_BUS_BUSY, @@ -211,7 +211,7 @@ static int cp2615_check_iop(struct usb_interface *usbif) } static int -cp2615_i2c_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num) +cp2615_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num) { struct usb_interface *usbif = adap->algo_data; int i = 0, ret = 0; @@ -250,8 +250,8 @@ cp2615_i2c_func(struct i2c_adapter *adap) } static const struct i2c_algorithm cp2615_i2c_algo = { - .master_xfer = cp2615_i2c_master_xfer, - .functionality = cp2615_i2c_func, + .xfer = cp2615_i2c_xfer, + .functionality = cp2615_i2c_func, }; /* -- 2.43.0 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* [PATCH v3] i2c: cp2615: reword according to newest specification 2024-07-06 11:20 [PATCH v2 09/60] i2c: cp2615: reword according to newest specification Wolfram Sang @ 2024-07-10 6:41 ` Wolfram Sang 2024-07-10 17:51 ` Bence Csókás 0 siblings, 1 reply; 1767+ messages in thread From: Wolfram Sang @ 2024-07-10 6:41 UTC (permalink / raw) To: linux-i2c; +Cc: Wolfram Sang, Bence Csókás, Andi Shyti, linux-kernel Change the wording of this driver wrt. the newest I2C v7 and SMBus 3.2 specifications and replace "master/slave" with more appropriate terms. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> --- Change since v2: * reworded comment about NAK for consistency as well (Thanks, Bence!) drivers/i2c/busses/i2c-cp2615.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/busses/i2c-cp2615.c b/drivers/i2c/busses/i2c-cp2615.c index cf3747d87034..e7720ea4045e 100644 --- a/drivers/i2c/busses/i2c-cp2615.c +++ b/drivers/i2c/busses/i2c-cp2615.c @@ -60,11 +60,11 @@ enum cp2615_i2c_status { CP2615_CFG_LOCKED = -6, /* read_len or write_len out of range */ CP2615_INVALID_PARAM = -4, - /* I2C slave did not ACK in time */ + /* I2C target did not ACK in time */ CP2615_TIMEOUT, /* I2C bus busy */ CP2615_BUS_BUSY, - /* I2C bus error (ie. device NAK'd the request) */ + /* I2C bus error (ie. target NAK'd the request) */ CP2615_BUS_ERROR, CP2615_SUCCESS }; @@ -211,7 +211,7 @@ static int cp2615_check_iop(struct usb_interface *usbif) } static int -cp2615_i2c_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num) +cp2615_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num) { struct usb_interface *usbif = adap->algo_data; int i = 0, ret = 0; @@ -250,8 +250,8 @@ cp2615_i2c_func(struct i2c_adapter *adap) } static const struct i2c_algorithm cp2615_i2c_algo = { - .master_xfer = cp2615_i2c_master_xfer, - .functionality = cp2615_i2c_func, + .xfer = cp2615_i2c_xfer, + .functionality = cp2615_i2c_func, }; /* -- 2.43.0 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2024-07-10 6:41 ` [PATCH v3] " Wolfram Sang @ 2024-07-10 17:51 ` Bence Csókás 0 siblings, 0 replies; 1767+ messages in thread From: Bence Csókás @ 2024-07-10 17:51 UTC (permalink / raw) To: Wolfram Sang, linux-i2c; +Cc: Bence Csókás, Andi Shyti, linux-kernel Hi! On 1970. 01. 01. 1:00, Wolfram Sang wrote: > Change the wording of this driver wrt. the newest I2C v7 and SMBus 3.2 > specifications and replace "master/slave" with more appropriate terms. > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > --- > > Change since v2: > * reworded comment about NAK for consistency as well (Thanks, Bence!) > > drivers/i2c/busses/i2c-cp2615.c | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) Acked-by: Bence Csókás <bence98@sch.bme.hu> Bence ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2024-06-26 6:11 Totoro W 2024-06-26 7:09 ` Eduard Zingerman 0 siblings, 1 reply; 1767+ messages in thread From: Totoro W @ 2024-06-26 6:11 UTC (permalink / raw) To: bpf Hi folks, This is my first time to ask questions in this mailing list. I'm the author of https://github.com/tw4452852/zbpf which is a framework to write BPF programs with Zig toolchain. During the development, as the BTF is totally generated by the Zig toolchain, some naming conventions will make the BTF verifier refuse to load. Right now I have to patch the libbpf to do some fixup before loading into the kernel (https://github.com/tw4452852/libbpf_zig/blob/main/0001-temporary-WA-for-invalid-BTF-info-generated-by-Zig.patch). Even though this just work-around the issue, I'm still curious about the current naming sanitation, I want to know some background about it. If possible, could we relax this to accept more languages (like Zig) to write BPF programs? Thanks in advance. Regards. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-06-26 6:11 Totoro W @ 2024-06-26 7:09 ` Eduard Zingerman 0 siblings, 0 replies; 1767+ messages in thread From: Eduard Zingerman @ 2024-06-26 7:09 UTC (permalink / raw) To: Totoro W, bpf On Wed, 2024-06-26 at 14:11 +0800, Totoro W wrote: > Hi folks, > > This is my first time to ask questions in this mailing list. I'm the > author of https://github.com/tw4452852/zbpf which is a framework to > write BPF programs with Zig toolchain. > During the development, as the BTF is totally generated by the Zig > toolchain, some naming conventions will make the BTF verifier refuse > to load. > Right now I have to patch the libbpf to do some fixup before loading > into the kernel > (https://github.com/tw4452852/libbpf_zig/blob/main/0001-temporary-WA-for-invalid-BTF-info-generated-by-Zig.patch). > + // https://github.com/tw4452852/zbpf/issues/3 > + else if (btf_is_ptr(t)) { > + t->name_off = 0; As far as I understand, you control BTF generation, why generate names for pointers in a first place? > Even though this just work-around the issue, I'm still curious about > the current naming sanitation, I want to know some background about > it. Doing some git digging shows that name check was first introduced by the following commit: 2667a2626f4d ("bpf: btf: Add BTF_KIND_FUNC and BTF_KIND_FUNC_PROTO") And lived like that afterwards. My guess is that kernel BTF is used to work with kernel functions and data structures. All of which follow C naming convention. > If possible, could we relax this to accept more languages (like Zig) > to write BPF programs? Thanks in advance. Could you please elaborate a bit? Citation from [1]: Identifiers must start with an alphabetic character or underscore and may be followed by any number of alphanumeric characters or underscores. They must not overlap with any keywords. If a name that does not fit these requirements is needed, such as for linking with external libraries, the @"" syntax may be used. Paragraph 1 matches C naming convention and should be accepted by kernel/bpf/btf.c:btf_name_valid_identifier(). Paragraph 2 is basically any string. Which one do you want? [1] https://ziglang.org/documentation/master/#Identifiers ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2024-06-11 16:54 Jacob Pan 2024-06-12 2:04 ` Sean Christopherson 0 siblings, 1 reply; 1767+ messages in thread From: Jacob Pan @ 2024-06-11 16:54 UTC (permalink / raw) To: X86 Kernel, LKML, Thomas Gleixner, Dave Hansen, H. Peter Anvin, Ingo Molnar, Borislav Petkov, linux-perf-users, Peter Zijlstra Cc: Andi Kleen, Xin Li From e52010df700cde894633c45c0b364847e63a9819 Mon Sep 17 00:00:00 2001 From: Jacob Pan <jacob.jun.pan@linux.intel.com> Date: Tue, 11 Jun 2024 09:49:17 -0700 Subject: Subject: [PATCH v2 0/6] Add support for NMI source reporting Hi Thomas and all, Non-Maskable Interrupts (NMIs) are routed to the local Advanced Programmable Interrupt Controller (APIC) using vector #2. Before the advent of the Flexible Return and Event Delivery (FRED)[1], the vector information set by the NMI initiator was disregarded or lost within the hardware, compelling system software to poll every registered NMI handler to pinpoint the source of the NMI[2]. This approach led to several issues: 1. Inefficiency due to the CPU's time spent polling all handlers. 2. Increased latency from the additional time taken to poll all handlers. 3. The occurrence of unnecessary NMIs if they are triggered shortly after being processed by a different source. To tackle these challenges, Intel introduced NMI source reporting as a part of the FRED specification (detailed in Chapter 9). This CPU feature ensures that while all NMI sources are still aggregated into NMI vector (#2) for delivery, the source of the NMI is now conveyed through FRED event data (a 16-bit bitmap on the stack). This allows for the selective dispatch of the NMI source handler based on the bitmap, eliminating the need to invoke all NMI source handlers indiscriminately. In line with the hardware architecture, various interrupt sources can generate NMIs by encoding an NMI delivery mode. However, this patchset activates only the local NMI sources that are currently utilized by the Linux kernel, which includes: 1. Performance monitoring. 2. Inter-Processor Interrupts (IPIs) for functions like CPU backtrace, machine check, Kernel GNU Debugger (KGDB), reboot, panic stop, and self-test. Other NMI sources will continue to be handled as previously when the NMI source is not utilized or remains unidentified. Next steps: 1. KVM support 2. Optimization to reuse IDT NMI vector 2 as NMI source for "known" source. Link:https://lore.kernel.org/lkml/746fecd5-4c79-42f9-919e-912ec415e73f@zytor.com/ [1] https://www.intel.com/content/www/us/en/content-details/779982/flexible-return-and-event-delivery-fred-specification.html [2] https://lore.kernel.org/lkml/171011362209.2468526.15187874627966416701.tglx@xen13/ Thanks, Jacob --- Change logs are in individual patches. Jacob Pan (6): x86/irq: Add enumeration of NMI source reporting CPU feature x86/irq: Extend NMI handler registration interface to include source x86/irq: Factor out common NMI handling code x86/irq: Process nmi sources in NMI handler perf/x86: Enable NMI source reporting for perfmon x86/irq: Enable NMI source on IPIs delivered as NMI arch/x86/Kconfig | 9 +++ arch/x86/events/amd/ibs.c | 2 +- arch/x86/events/core.c | 11 ++- arch/x86/events/intel/core.c | 6 +- arch/x86/include/asm/apic.h | 1 + arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/disabled-features.h | 8 +- arch/x86/include/asm/irq_vectors.h | 38 +++++++++ arch/x86/include/asm/nmi.h | 4 +- arch/x86/kernel/apic/hw_nmi.c | 5 +- arch/x86/kernel/apic/ipi.c | 4 +- arch/x86/kernel/apic/local.h | 18 +++-- arch/x86/kernel/cpu/mce/inject.c | 4 +- arch/x86/kernel/cpu/mshyperv.c | 2 +- arch/x86/kernel/kgdb.c | 6 +- arch/x86/kernel/nmi.c | 99 +++++++++++++++++++++--- arch/x86/kernel/nmi_selftest.c | 7 +- arch/x86/kernel/reboot.c | 4 +- arch/x86/kernel/smp.c | 4 +- arch/x86/kernel/traps.c | 4 +- arch/x86/platform/uv/uv_nmi.c | 4 +- drivers/acpi/apei/ghes.c | 2 +- drivers/char/ipmi/ipmi_watchdog.c | 2 +- drivers/edac/igen6_edac.c | 2 +- drivers/watchdog/hpwdt.c | 6 +- 25 files changed, 200 insertions(+), 53 deletions(-) -- 2.25.1 ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-06-11 16:54 Jacob Pan @ 2024-06-12 2:04 ` Sean Christopherson 2024-06-12 2:55 ` Re: Xin Li 0 siblings, 1 reply; 1767+ messages in thread From: Sean Christopherson @ 2024-06-12 2:04 UTC (permalink / raw) To: Jacob Pan Cc: X86 Kernel, LKML, Thomas Gleixner, Dave Hansen, H. Peter Anvin, Ingo Molnar, Borislav Petkov, linux-perf-users, Peter Zijlstra, Andi Kleen, Xin Li On Tue, Jun 11, 2024, Jacob Pan wrote: > To tackle these challenges, Intel introduced NMI source reporting as a part > of the FRED specification (detailed in Chapter 9). Chapter 9 of the linked spec is "VMX Interactions with FRED Transitions". I spent a minute or so poking around the spec and didn't find anything that describes how "NMI source reporting" works. > 1. Performance monitoring. > 2. Inter-Processor Interrupts (IPIs) for functions like CPU backtrace, > machine check, Kernel GNU Debugger (KGDB), reboot, panic stop, and > self-test. > > Other NMI sources will continue to be handled as previously when the NMI > source is not utilized or remains unidentified. > > Next steps: > 1. KVM support I can't tell for sure since I can't find the relevant spec info, but doesn't KVM support need to land before this gets enabled? Otherwise the source would get lost if the NMI arrived while the CPU was in non-root mode, no? E.g. I don't see any changes to fred_entry_from_kvm() in this series. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-06-12 2:04 ` Sean Christopherson @ 2024-06-12 2:55 ` Xin Li 0 siblings, 0 replies; 1767+ messages in thread From: Xin Li @ 2024-06-12 2:55 UTC (permalink / raw) To: Sean Christopherson, Jacob Pan Cc: X86 Kernel, LKML, Thomas Gleixner, Dave Hansen, H. Peter Anvin, Ingo Molnar, Borislav Petkov, linux-perf-users, Peter Zijlstra, Andi Kleen, Xin Li On 6/11/2024 7:04 PM, Sean Christopherson wrote: > On Tue, Jun 11, 2024, Jacob Pan wrote: >> To tackle these challenges, Intel introduced NMI source reporting as a part >> of the FRED specification (detailed in Chapter 9). > > Chapter 9 of the linked spec is "VMX Interactions with FRED Transitions". I > spent a minute or so poking around the spec and didn't find anything that describes > how "NMI source reporting" works. I did the same thing when I saw NMI source was added to the spec :) > >> 1. Performance monitoring. >> 2. Inter-Processor Interrupts (IPIs) for functions like CPU backtrace, >> machine check, Kernel GNU Debugger (KGDB), reboot, panic stop, and >> self-test. >> >> Other NMI sources will continue to be handled as previously when the NMI >> source is not utilized or remains unidentified. >> >> Next steps: >> 1. KVM support > > I can't tell for sure since I can't find the relevant spec info, but doesn't KVM > support need to land before this gets enabled? Otherwise the source would get > lost if the NMI arrived while the CPU was in non-root mode, no? E.g. I don't > see any changes to fred_entry_from_kvm() in this series. You're absolutely right! There is a patch in NMI source KVM patches for this, but as you mentioned it has to be in this NMI source native patches instead. Thanks! Xin ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <CGME20240520102002epcas2p3d0944968114a664556cbd74d53beddee@epcas2p3.samsung.com>]
* (no subject) [not found] <CGME20240520102002epcas2p3d0944968114a664556cbd74d53beddee@epcas2p3.samsung.com> @ 2024-05-20 10:09 ` Minwoo Im 2024-05-20 13:34 ` Vincent Fu 0 siblings, 1 reply; 1767+ messages in thread From: Minwoo Im @ 2024-05-20 10:09 UTC (permalink / raw) To: fio [-- Attachment #1: Type: text/plain, Size: 14 bytes --] subscribe fio [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-05-20 10:09 ` Minwoo Im @ 2024-05-20 13:34 ` Vincent Fu 2024-05-21 0:00 ` Re: Minwoo Im 0 siblings, 1 reply; 1767+ messages in thread From: Vincent Fu @ 2024-05-20 13:34 UTC (permalink / raw) To: Minwoo Im, fio On 5/20/24 06:09, Minwoo Im wrote: > subscribe fio > > Minwoo, here are instructions for subscribing to this list: http://vger.kernel.org/vger-lists.html#fio Vincent ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-05-20 13:34 ` Vincent Fu @ 2024-05-21 0:00 ` Minwoo Im 0 siblings, 0 replies; 1767+ messages in thread From: Minwoo Im @ 2024-05-21 0:00 UTC (permalink / raw) To: Vincent Fu; +Cc: fio, Minwoo Im [-- Attachment #1: Type: text/plain, Size: 307 bytes --] On 24-05-20 09:34:15, Vincent Fu wrote: > On 5/20/24 06:09, Minwoo Im wrote: > > subscribe fio > > > > > > Minwoo, here are instructions for subscribing to this list: Ah, my bad. I should have sent to majordomo@vger.kernel.org. Thanks! > > http://vger.kernel.org/vger-lists.html#fio > > Vincent > [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH dovetail] x86: irq_pipeline: Add missing definition for !CONFIG_IRQ_PIPELINE
@ 2024-04-23 14:21 Philippe Gerum
2024-04-24 8:58 ` Fabian Scheler
0 siblings, 1 reply; 1767+ messages in thread
From: Philippe Gerum @ 2024-04-23 14:21 UTC (permalink / raw)
To: Florian Bezdeka; +Cc: Fabian Scheler, Roman Hodek, xenomai
Florian Bezdeka <florian.bezdeka@siemens.com> writes:
> On Tue, 2024-04-23 at 14:59 +0200, Philippe Gerum wrote:
>> Merged, thanks.
>
> Don't know if that is important for you Philippe, but the patch was
> missing a proper "From: " tag in the body.
>
> Fabian is now the author, but the signed-off-by tag is from Roman (the
> initial author).
>
> Fabian, when re-sending patches (maybe because the original author has
> no proper mail setup) make sure to add your signed-off-by and a "From:
> " line as first line of the body.
>
> git format-patch --from should do it.
>
> Best regards,
> Florian
>
Let's say that the signed-off-by tag is what matters the most to me
along with a source channel I can trust (in this case siemens.com), but
having a fully consistent information would be better, indeed.
--
Philippe.
^ permalink raw reply [flat|nested] 1767+ messages in thread* (no subject) 2024-04-23 14:21 [PATCH dovetail] x86: irq_pipeline: Add missing definition for !CONFIG_IRQ_PIPELINE Philippe Gerum @ 2024-04-24 8:58 ` Fabian Scheler 2024-04-24 9:02 ` Scheler, Fabian 0 siblings, 1 reply; 1767+ messages in thread From: Fabian Scheler @ 2024-04-24 8:58 UTC (permalink / raw) To: xenomai; +Cc: roman.hodek As suggested by Florian I revised the patch so that the correct author is stated in the commit. Ciao Fabian ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-04-24 8:58 ` Fabian Scheler @ 2024-04-24 9:02 ` Scheler, Fabian 0 siblings, 0 replies; 1767+ messages in thread From: Scheler, Fabian @ 2024-04-24 9:02 UTC (permalink / raw) To: xenomai Am 24.04.2024 um 10:58 schrieb Fabian Scheler: > > As suggested by Florian I revised the patch so that the correct author is stated in the commit. > > Ciao > Fabian OK, something went wrong here - this simply is additional information for the revised patch. Ciao Fabian -- With best regards, Dr. Fabian Scheler Siemens AG T CED EDC-DE Hertha-Sponer-Weg 3 91058 Erlangen, Germany Phone: +49 (1522) 1702973 Mobile: +49 (1522) 1702973 mailto:fabian.scheler@siemens.com www.siemens.com Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Roland Busch, Chairman, President and Chief Executive Officer; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2024-04-19 15:46 George Guo
2024-04-23 16:48 ` Greg KH
0 siblings, 1 reply; 1767+ messages in thread
From: George Guo @ 2024-04-19 15:46 UTC (permalink / raw)
To: gregkh, tom.zanussi; +Cc: stable
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 3602 bytes --]
Subject: [PATCH 4.19.y v6 0/2] Double-free bug discovery on testing trigger-field-variable-support.tc
1) About v4-0001-tracing-Remove-hist-trigger-synth_var_refs.patch:
The reason I am backporting this patch is that no one found the double-free bug
at that time, then later the code was removed on upstream, but
4.19-stable has the bug.
This is tested via "./ftracetest test.d/trigger/inter-event/
trigger-field-variable-support.tc"
==================================================================
BUG: KASAN: use-after-free in destroy_hist_field+0x115/0x140
Read of size 4 at addr ffff888012e95318 by task ftracetest/1858
CPU: 1 PID: 1858 Comm: ftracetest Kdump: loaded Tainted: GE 4.19.90-89 #24
Source Version: Unknown
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0
Call Trace:
dump_stack+0xcb/0x10b
print_address_description.cold+0x54/0x249
kasan_report_error.cold+0x63/0xab
? destroy_hist_field+0x115/0x140
__asan_report_load4_noabort+0x8d/0xa0
? destroy_hist_field+0x115/0x140
destroy_hist_field+0x115/0x140
destroy_hist_data+0x4e4/0x9a0
event_hist_trigger_free+0x212/0x2f0
? update_cond_flag+0x128/0x170
? event_hist_trigger_func+0x2880/0x2880
hist_unregister_trigger+0x2f2/0x4f0
event_hist_trigger_func+0x168c/0x2880
? tracing_map_read_var_once+0xd0/0xd0
? create_key_field+0x520/0x520
? __mutex_lock_slowpath+0x10/0x10
event_trigger_write+0x2f4/0x490
? trigger_start+0x180/0x180
? __fget_light+0x369/0x5d0
? count_memcg_event_mm+0x104/0x2b0
? trigger_start+0x180/0x180
__vfs_write+0x81/0x100
vfs_write+0x1e1/0x540
ksys_write+0x12a/0x290
? __ia32_sys_read+0xb0/0xb0
? __close_fd+0x1d3/0x280
do_syscall_64+0xe3/0x2d0
entry_SYSCALL_64_after_hwframe+0x5c/0xc1
RIP: 0033:0x7efdd342ee04
Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 48
8d 05 39 34 0c 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff
ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5
RSP: 002b:00007ffda01f5e08 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00000000000000b4 RCX: 00007efdd342ee04
RDX: 00000000000000b4 RSI: 000055c5b41b1e90 RDI: 0000000000000001
RBP: 000055c5b41b1e90 R08: 000000000000000a R09: 0000000000000000
R10: 000000000000000a R11: 0000000000000246 R12: 00007efdd34ed5c0
R13: 00000000000000b4 R14: 00007efdd34ed7c0 R15: 00000000000000b4
==================================================================
2) About v4-0002-tracing-Use-var_refs-for-hist-trigger-reference-c.patch:
Only v4-0001-tracing-Remove-hist-trigger-synth_var_refs.patch will lead
to compilation errors:
../kernel/trace/trace_events_hist.c: In function ‘find_var_ref’:
../kernel/trace/trace_events_hist.c:1364:36: error: ‘struct hist_trigger_data’ has no member named ‘n_synth_var_refs’; did you mean ‘n_var_refs’?
1364 | for (i = 0; i < hist_data->n_synth_var_refs; i++) {
| ^~~~~~~~~~~~~~~~
| n_var_refs
../kernel/trace/trace_events_hist.c:1365:41: error: ‘struct hist_trigger_data’ has no member named ‘synth_var_refs’; did you mean ‘n_var_refs’?
1365 | hist_field = hist_data->synth_var_refs[i];
| ^~~~~~~~~~~~~~
| n_var_refs
Tom Zanussi (2):
tracing: Remove hist trigger synth_var_refs
tracing: Use var_refs[] for hist trigger reference checking
kernel/trace/trace_events_hist.c | 86 ++++----------------------------
1 file changed, 11 insertions(+), 75 deletions(-)
--
2.34.1
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2024-04-19 15:46 George Guo @ 2024-04-23 16:48 ` Greg KH 0 siblings, 0 replies; 1767+ messages in thread From: Greg KH @ 2024-04-23 16:48 UTC (permalink / raw) To: George Guo; +Cc: tom.zanussi, stable On Fri, Apr 19, 2024 at 11:46:56PM +0800, George Guo wrote: > Subject: [PATCH 4.19.y v6 0/2] Double-free bug discovery on testing trigger-field-variable-support.tc > > 1) About v4-0001-tracing-Remove-hist-trigger-synth_var_refs.patch: > > The reason I am backporting this patch is that no one found the double-free bug > at that time, then later the code was removed on upstream, but > 4.19-stable has the bug. Both now queued up, thanks greg k-h ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2024-03-07 6:07 KR Kim
2024-03-07 8:01 ` Miquel Raynal
0 siblings, 1 reply; 1767+ messages in thread
From: KR Kim @ 2024-03-07 6:07 UTC (permalink / raw)
To: miquel.raynal, richard, vigneshr, mmkurbanov, ddrokosov,
gch981213
Cc: kr.kim, michael, broonie, mika.westerberg, acelan.kao,
linux-kernel, linux-mtd, moh.sardi, changsub.shim
Feat: Add SkyHigh Memory Patch code
Add SPI Nand Patch code of SkyHigh Memory
- Add company dependent code with 'skyhigh.c'
- Insert into 'core.c' so that 'always ECC on'
commit 6061b97a830af8cb5fd0917e833e779451f9046a (HEAD -> master)
Author: KR Kim <kr.kim@skyhighmemory.com>
Date: Thu Mar 7 13:24:11 2024 +0900
SPI Nand Patch code of SkyHigh Momory
Signed-off-by: KR Kim <kr.kim@skyhighmemory.com>
From 6061b97a830af8cb5fd0917e833e779451f9046a Mon Sep 17 00:00:00 2001
From: KR Kim <kr.kim@skyhighmemory.com>
Date: Thu, 7 Mar 2024 13:24:11 +0900
Subject: [PATCH] SPI Nand Patch code of SkyHigh Memory
---
drivers/mtd/nand/spi/Makefile | 2 +-
drivers/mtd/nand/spi/core.c | 7 +-
drivers/mtd/nand/spi/skyhigh.c | 155 +++++++++++++++++++++++++++++++++
include/linux/mtd/spinand.h | 3 +
4 files changed, 165 insertions(+), 2 deletions(-)
mode change 100644 => 100755 drivers/mtd/nand/spi/Makefile
mode change 100644 => 100755 drivers/mtd/nand/spi/core.c
create mode 100644 drivers/mtd/nand/spi/skyhigh.c
mode change 100644 => 100755 include/linux/mtd/spinand.h
diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
old mode 100644
new mode 100755
index 19cc77288ebb..1e61ab21893a
--- a/drivers/mtd/nand/spi/Makefile
+++ b/drivers/mtd/nand/spi/Makefile
@@ -1,4 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
spinand-objs := core.o alliancememory.o ato.o esmt.o foresee.o gigadevice.o macronix.o
-spinand-objs += micron.o paragon.o toshiba.o winbond.o xtx.o
+spinand-objs += micron.o paragon.o skyhigh.o toshiba.o winbond.o xtx.o
obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
old mode 100644
new mode 100755
index e0b6715e5dfe..e3f0a7544ba4
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -34,7 +34,7 @@ static int spinand_read_reg_op(struct spinand_device *spinand, u8 reg, u8 *val)
return 0;
}
-static int spinand_write_reg_op(struct spinand_device *spinand, u8 reg, u8 val)
+int spinand_write_reg_op(struct spinand_device *spinand, u8 reg, u8 val)
{
struct spi_mem_op op = SPINAND_SET_FEATURE_OP(reg,
spinand->scratchbuf);
@@ -196,6 +196,10 @@ static int spinand_init_quad_enable(struct spinand_device *spinand)
static int spinand_ecc_enable(struct spinand_device *spinand,
bool enable)
{
+ /* SHM : always ECC enable */
+ if (spinand->flags & SPINAND_ON_DIE_ECC_MANDATORY)
+ return 0;
+
return spinand_upd_cfg(spinand, CFG_ECC_ENABLE,
enable ? CFG_ECC_ENABLE : 0);
}
@@ -945,6 +949,7 @@ static const struct spinand_manufacturer *spinand_manufacturers[] = {
¯onix_spinand_manufacturer,
µn_spinand_manufacturer,
¶gon_spinand_manufacturer,
+ &skyhigh_spinand_manufacturer,
&toshiba_spinand_manufacturer,
&winbond_spinand_manufacturer,
&xtx_spinand_manufacturer,
diff --git a/drivers/mtd/nand/spi/skyhigh.c b/drivers/mtd/nand/spi/skyhigh.c
new file mode 100644
index 000000000000..92e7572094ff
--- /dev/null
+++ b/drivers/mtd/nand/spi/skyhigh.c
@@ -0,0 +1,155 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2022 SkyHigh Memory Limited
+ *
+ * Author: Takahiro Kuwano <takahiro.kuwano@infineon.com>
+ */
+
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/mtd/spinand.h>
+
+#define SPINAND_MFR_SKYHIGH 0x01
+
+#define SKYHIGH_STATUS_ECC_1TO2_BITFLIPS (1 << 4)
+#define SKYHIGH_STATUS_ECC_3TO6_BITFLIPS (2 << 4)
+#define SKYHIGH_STATUS_ECC_UNCOR_ERROR (3 << 4)
+
+#define SKYHIGH_CONFIG_PROTECT_EN BIT(1)
+
+static SPINAND_OP_VARIANTS(read_cache_variants,
+ SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 4, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 2, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
+
+static SPINAND_OP_VARIANTS(write_cache_variants,
+ SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
+ SPINAND_PROG_LOAD(true, 0, NULL, 0));
+
+static SPINAND_OP_VARIANTS(update_cache_variants,
+ SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
+ SPINAND_PROG_LOAD(false, 0, NULL, 0));
+
+static int skyhigh_spinand_ooblayout_ecc(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *region)
+{
+ if (section)
+ return -ERANGE;
+
+ /* SkyHigh's ecc parity is stored in the internal hidden area and is not needed for them. */
+ region->length = 0;
+ region->offset = mtd->oobsize;
+
+ return 0;
+}
+
+static int skyhigh_spinand_ooblayout_free(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *region)
+{
+ if (section)
+ return -ERANGE;
+
+ region->length = mtd->oobsize - 2;
+ region->offset = 2;
+
+ return 0;
+}
+
+static const struct mtd_ooblayout_ops skyhigh_spinand_ooblayout = {
+ .ecc = skyhigh_spinand_ooblayout_ecc,
+ .free = skyhigh_spinand_ooblayout_free,
+};
+
+static int skyhigh_spinand_ecc_get_status(struct spinand_device *spinand,
+ u8 status)
+{
+ /* SHM
+ * 00 : No bit-flip
+ * 01 : 1-2 errors corrected
+ * 10 : 3-6 errors corrected
+ * 11 : uncorrectable
+ */
+
+ switch (status & STATUS_ECC_MASK) {
+ case STATUS_ECC_NO_BITFLIPS:
+ return 0;
+
+ case SKYHIGH_STATUS_ECC_1TO2_BITFLIPS:
+ return 2;
+
+ case SKYHIGH_STATUS_ECC_3TO6_BITFLIPS:
+ return 6;
+
+ case SKYHIGH_STATUS_ECC_UNCOR_ERROR:
+ return -EBADMSG;;
+
+ default:
+ break;
+ }
+
+ return -EINVAL;
+}
+
+static const struct spinand_info skyhigh_spinand_table[] = {
+ SPINAND_INFO("S35ML01G301",
+ SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x15),
+ NAND_MEMORG(1, 2048, 64, 64, 1024, 20, 1, 1, 1),
+ NAND_ECCREQ(6, 32),
+ SPINAND_INFO_OP_VARIANTS(&read_cache_variants,
+ &write_cache_variants,
+ &update_cache_variants),
+ SPINAND_ON_DIE_ECC_MANDATORY,
+ SPINAND_ECCINFO(&skyhigh_spinand_ooblayout,
+ skyhigh_spinand_ecc_get_status)),
+ SPINAND_INFO("S35ML01G300",
+ SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x14),
+ NAND_MEMORG(1, 2048, 128, 64, 1024, 20, 1, 1, 1),
+ NAND_ECCREQ(6, 32),
+ SPINAND_INFO_OP_VARIANTS(&read_cache_variants,
+ &write_cache_variants,
+ &update_cache_variants),
+ SPINAND_ON_DIE_ECC_MANDATORY,
+ SPINAND_ECCINFO(&skyhigh_spinand_ooblayout,
+ skyhigh_spinand_ecc_get_status)),
+ SPINAND_INFO("S35ML02G300",
+ SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x25),
+ NAND_MEMORG(1, 2048, 128, 64, 2048, 40, 2, 1, 1),
+ NAND_ECCREQ(6, 32),
+ SPINAND_INFO_OP_VARIANTS(&read_cache_variants,
+ &write_cache_variants,
+ &update_cache_variants),
+ SPINAND_ON_DIE_ECC_MANDATORY,
+ SPINAND_ECCINFO(&skyhigh_spinand_ooblayout,
+ skyhigh_spinand_ecc_get_status)),
+ SPINAND_INFO("S35ML04G300",
+ SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x35),
+ NAND_MEMORG(1, 2048, 128, 64, 4096, 80, 2, 1, 1),
+ NAND_ECCREQ(6, 32),
+ SPINAND_INFO_OP_VARIANTS(&read_cache_variants,
+ &write_cache_variants,
+ &update_cache_variants),
+ SPINAND_ON_DIE_ECC_MANDATORY,
+ SPINAND_ECCINFO(&skyhigh_spinand_ooblayout,
+ skyhigh_spinand_ecc_get_status)),
+};
+
+static int skyhigh_spinand_init(struct spinand_device *spinand)
+{
+ return spinand_write_reg_op(spinand, REG_BLOCK_LOCK,
+ SKYHIGH_CONFIG_PROTECT_EN);
+}
+
+static const struct spinand_manufacturer_ops skyhigh_spinand_manuf_ops = {
+ .init = skyhigh_spinand_init,
+ };
+
+const struct spinand_manufacturer skyhigh_spinand_manufacturer = {
+ .id = SPINAND_MFR_SKYHIGH,
+ .name = "SkyHigh",
+ .chips = skyhigh_spinand_table,
+ .nchips = ARRAY_SIZE(skyhigh_spinand_table),
+ .ops = &skyhigh_spinand_manuf_ops,
+};
diff --git a/include/linux/mtd/spinand.h b/include/linux/mtd/spinand.h
old mode 100644
new mode 100755
index badb4c1ac079..0e135076df24
--- a/include/linux/mtd/spinand.h
+++ b/include/linux/mtd/spinand.h
@@ -268,6 +268,7 @@ extern const struct spinand_manufacturer gigadevice_spinand_manufacturer;
extern const struct spinand_manufacturer macronix_spinand_manufacturer;
extern const struct spinand_manufacturer micron_spinand_manufacturer;
extern const struct spinand_manufacturer paragon_spinand_manufacturer;
+extern const struct spinand_manufacturer skyhigh_spinand_manufacturer;
extern const struct spinand_manufacturer toshiba_spinand_manufacturer;
extern const struct spinand_manufacturer winbond_spinand_manufacturer;
extern const struct spinand_manufacturer xtx_spinand_manufacturer;
@@ -312,6 +313,7 @@ struct spinand_ecc_info {
#define SPINAND_HAS_QE_BIT BIT(0)
#define SPINAND_HAS_CR_FEAT_BIT BIT(1)
+#define SPINAND_ON_DIE_ECC_MANDATORY BIT(2) /* SHM */
/**
* struct spinand_ondie_ecc_conf - private SPI-NAND on-die ECC engine structure
@@ -518,5 +520,6 @@ int spinand_match_and_init(struct spinand_device *spinand,
int spinand_upd_cfg(struct spinand_device *spinand, u8 mask, u8 val);
int spinand_select_target(struct spinand_device *spinand, unsigned int target);
+int spinand_write_reg_op(struct spinand_device *spinand, u8 reg, u8 val);
#endif /* __LINUX_MTD_SPINAND_H */
--
2.34.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 1767+ messages in thread* Re: 2024-03-07 6:07 KR Kim @ 2024-03-07 8:01 ` Miquel Raynal 2024-03-08 1:27 ` Re: Kyeongrho.Kim [not found] ` <SE2P216MB210205B301549661575720CC833A2@SE2P216MB2102.KORP216.PROD.OUTLOOK.COM> 0 siblings, 2 replies; 1767+ messages in thread From: Miquel Raynal @ 2024-03-07 8:01 UTC (permalink / raw) To: KR Kim Cc: richard, vigneshr, mmkurbanov, ddrokosov, gch981213, michael, broonie, mika.westerberg, acelan.kao, linux-kernel, linux-mtd, moh.sardi, changsub.shim Hi, kr.kim@skyhighmemory.com wrote on Thu, 7 Mar 2024 15:07:29 +0900: > Feat: Add SkyHigh Memory Patch code > > Add SPI Nand Patch code of SkyHigh Memory > - Add company dependent code with 'skyhigh.c' > - Insert into 'core.c' so that 'always ECC on' Patch formatting is still messed up. > commit 6061b97a830af8cb5fd0917e833e779451f9046a (HEAD -> master) > Author: KR Kim <kr.kim@skyhighmemory.com> > Date: Thu Mar 7 13:24:11 2024 +0900 > > SPI Nand Patch code of SkyHigh Momory > > Signed-off-by: KR Kim <kr.kim@skyhighmemory.com> > > From 6061b97a830af8cb5fd0917e833e779451f9046a Mon Sep 17 00:00:00 2001 > From: KR Kim <kr.kim@skyhighmemory.com> > Date: Thu, 7 Mar 2024 13:24:11 +0900 > Subject: [PATCH] SPI Nand Patch code of SkyHigh Memory > > --- > drivers/mtd/nand/spi/Makefile | 2 +- > drivers/mtd/nand/spi/core.c | 7 +- > drivers/mtd/nand/spi/skyhigh.c | 155 +++++++++++++++++++++++++++++++++ > include/linux/mtd/spinand.h | 3 + > 4 files changed, 165 insertions(+), 2 deletions(-) > mode change 100644 => 100755 drivers/mtd/nand/spi/Makefile > mode change 100644 => 100755 drivers/mtd/nand/spi/core.c > create mode 100644 drivers/mtd/nand/spi/skyhigh.c > mode change 100644 => 100755 include/linux/mtd/spinand.h > > diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile > old mode 100644 > new mode 100755 > index 19cc77288ebb..1e61ab21893a > --- a/drivers/mtd/nand/spi/Makefile > +++ b/drivers/mtd/nand/spi/Makefile > @@ -1,4 +1,4 @@ > # SPDX-License-Identifier: GPL-2.0 > spinand-objs := core.o alliancememory.o ato.o esmt.o foresee.o gigadevice.o macronix.o > -spinand-objs += micron.o paragon.o toshiba.o winbond.o xtx.o > +spinand-objs += micron.o paragon.o skyhigh.o toshiba.o winbond.o xtx.o > obj-$(CONFIG_MTD_SPI_NAND) += spinand.o > diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c > old mode 100644 > new mode 100755 > index e0b6715e5dfe..e3f0a7544ba4 > --- a/drivers/mtd/nand/spi/core.c > +++ b/drivers/mtd/nand/spi/core.c > @@ -34,7 +34,7 @@ static int spinand_read_reg_op(struct spinand_device *spinand, u8 reg, u8 *val) > return 0; > } > > -static int spinand_write_reg_op(struct spinand_device *spinand, u8 reg, u8 val) > +int spinand_write_reg_op(struct spinand_device *spinand, u8 reg, u8 val) Please do this in a separate commit. > { > struct spi_mem_op op = SPINAND_SET_FEATURE_OP(reg, > spinand->scratchbuf); > @@ -196,6 +196,10 @@ static int spinand_init_quad_enable(struct spinand_device *spinand) > static int spinand_ecc_enable(struct spinand_device *spinand, > bool enable) > { > + /* SHM : always ECC enable */ > + if (spinand->flags & SPINAND_ON_DIE_ECC_MANDATORY) > + return 0; Silently always enabling ECC is not possible. If you cannot disable the on-die engine, then: - you should prevent any other engine type to be used - you should error out if a raw access is requested - these chips are broken, IMO > + > return spinand_upd_cfg(spinand, CFG_ECC_ENABLE, > enable ? CFG_ECC_ENABLE : 0); > } > @@ -945,6 +949,7 @@ static const struct spinand_manufacturer *spinand_manufacturers[] = { > ¯onix_spinand_manufacturer, > µn_spinand_manufacturer, > ¶gon_spinand_manufacturer, > + &skyhigh_spinand_manufacturer, > &toshiba_spinand_manufacturer, > &winbond_spinand_manufacturer, > &xtx_spinand_manufacturer, > diff --git a/drivers/mtd/nand/spi/skyhigh.c b/drivers/mtd/nand/spi/skyhigh.c > new file mode 100644 > index 000000000000..92e7572094ff > --- /dev/null > +++ b/drivers/mtd/nand/spi/skyhigh.c > @@ -0,0 +1,155 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c) 2022 SkyHigh Memory Limited > + * > + * Author: Takahiro Kuwano <takahiro.kuwano@infineon.com> > + */ > + > +#include <linux/device.h> > +#include <linux/kernel.h> > +#include <linux/mtd/spinand.h> > + > +#define SPINAND_MFR_SKYHIGH 0x01 > + > +#define SKYHIGH_STATUS_ECC_1TO2_BITFLIPS (1 << 4) > +#define SKYHIGH_STATUS_ECC_3TO6_BITFLIPS (2 << 4) > +#define SKYHIGH_STATUS_ECC_UNCOR_ERROR (3 << 4) > + > +#define SKYHIGH_CONFIG_PROTECT_EN BIT(1) > + > +static SPINAND_OP_VARIANTS(read_cache_variants, > + SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 4, NULL, 0), > + SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0), > + SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 2, NULL, 0), > + SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0), > + SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0), > + SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0)); > + > +static SPINAND_OP_VARIANTS(write_cache_variants, > + SPINAND_PROG_LOAD_X4(true, 0, NULL, 0), > + SPINAND_PROG_LOAD(true, 0, NULL, 0)); > + > +static SPINAND_OP_VARIANTS(update_cache_variants, > + SPINAND_PROG_LOAD_X4(false, 0, NULL, 0), > + SPINAND_PROG_LOAD(false, 0, NULL, 0)); > + > +static int skyhigh_spinand_ooblayout_ecc(struct mtd_info *mtd, int section, > + struct mtd_oob_region *region) > +{ > + if (section) > + return -ERANGE; > + > + /* SkyHigh's ecc parity is stored in the internal hidden area and is not needed for them. */ ECC an "needed" is wrong here. Just stop after "area" > + region->length = 0; > + region->offset = mtd->oobsize; > + > + return 0; > +} > + > +static int skyhigh_spinand_ooblayout_free(struct mtd_info *mtd, int section, > + struct mtd_oob_region *region) > +{ > + if (section) > + return -ERANGE; > + > + region->length = mtd->oobsize - 2; > + region->offset = 2; > + > + return 0; > +} > + > +static const struct mtd_ooblayout_ops skyhigh_spinand_ooblayout = { > + .ecc = skyhigh_spinand_ooblayout_ecc, > + .free = skyhigh_spinand_ooblayout_free, > +}; > + > +static int skyhigh_spinand_ecc_get_status(struct spinand_device *spinand, > + u8 status) > +{ > + /* SHM > + * 00 : No bit-flip > + * 01 : 1-2 errors corrected > + * 10 : 3-6 errors corrected > + * 11 : uncorrectable > + */ Thanks for the comment but the switch case looks rather straightforward, it is self-sufficient in this case. > + > + switch (status & STATUS_ECC_MASK) { > + case STATUS_ECC_NO_BITFLIPS: > + return 0; > + > + case SKYHIGH_STATUS_ECC_1TO2_BITFLIPS: > + return 2; > + > + case SKYHIGH_STATUS_ECC_3TO6_BITFLIPS: > + return 6; > + > + case SKYHIGH_STATUS_ECC_UNCOR_ERROR: > + return -EBADMSG;; > + > + default: > + break; I guess you can directly call return -EINVAL here? > + } > + > + return -EINVAL; > +} > + > +static const struct spinand_info skyhigh_spinand_table[] = { > + SPINAND_INFO("S35ML01G301", > + SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x15), > + NAND_MEMORG(1, 2048, 64, 64, 1024, 20, 1, 1, 1), > + NAND_ECCREQ(6, 32), > + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, > + &write_cache_variants, > + &update_cache_variants), > + SPINAND_ON_DIE_ECC_MANDATORY, > + SPINAND_ECCINFO(&skyhigh_spinand_ooblayout, > + skyhigh_spinand_ecc_get_status)), > + SPINAND_INFO("S35ML01G300", > + SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x14), > + NAND_MEMORG(1, 2048, 128, 64, 1024, 20, 1, 1, 1), > + NAND_ECCREQ(6, 32), > + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, > + &write_cache_variants, > + &update_cache_variants), > + SPINAND_ON_DIE_ECC_MANDATORY, > + SPINAND_ECCINFO(&skyhigh_spinand_ooblayout, > + skyhigh_spinand_ecc_get_status)), > + SPINAND_INFO("S35ML02G300", > + SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x25), > + NAND_MEMORG(1, 2048, 128, 64, 2048, 40, 2, 1, 1), > + NAND_ECCREQ(6, 32), > + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, > + &write_cache_variants, > + &update_cache_variants), > + SPINAND_ON_DIE_ECC_MANDATORY, > + SPINAND_ECCINFO(&skyhigh_spinand_ooblayout, > + skyhigh_spinand_ecc_get_status)), > + SPINAND_INFO("S35ML04G300", > + SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x35), > + NAND_MEMORG(1, 2048, 128, 64, 4096, 80, 2, 1, 1), > + NAND_ECCREQ(6, 32), > + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, > + &write_cache_variants, > + &update_cache_variants), > + SPINAND_ON_DIE_ECC_MANDATORY, > + SPINAND_ECCINFO(&skyhigh_spinand_ooblayout, > + skyhigh_spinand_ecc_get_status)), > +}; > + > +static int skyhigh_spinand_init(struct spinand_device *spinand) > +{ > + return spinand_write_reg_op(spinand, REG_BLOCK_LOCK, > + SKYHIGH_CONFIG_PROTECT_EN); Is this really relevant? Isn't there an API for the block lock mechanism? > +} > + > +static const struct spinand_manufacturer_ops skyhigh_spinand_manuf_ops = { > + .init = skyhigh_spinand_init, > + }; > + > +const struct spinand_manufacturer skyhigh_spinand_manufacturer = { > + .id = SPINAND_MFR_SKYHIGH, > + .name = "SkyHigh", > + .chips = skyhigh_spinand_table, > + .nchips = ARRAY_SIZE(skyhigh_spinand_table), > + .ops = &skyhigh_spinand_manuf_ops, > +}; > diff --git a/include/linux/mtd/spinand.h b/include/linux/mtd/spinand.h > old mode 100644 > new mode 100755 > index badb4c1ac079..0e135076df24 > --- a/include/linux/mtd/spinand.h > +++ b/include/linux/mtd/spinand.h > @@ -268,6 +268,7 @@ extern const struct spinand_manufacturer gigadevice_spinand_manufacturer; > extern const struct spinand_manufacturer macronix_spinand_manufacturer; > extern const struct spinand_manufacturer micron_spinand_manufacturer; > extern const struct spinand_manufacturer paragon_spinand_manufacturer; > +extern const struct spinand_manufacturer skyhigh_spinand_manufacturer; > extern const struct spinand_manufacturer toshiba_spinand_manufacturer; > extern const struct spinand_manufacturer winbond_spinand_manufacturer; > extern const struct spinand_manufacturer xtx_spinand_manufacturer; > @@ -312,6 +313,7 @@ struct spinand_ecc_info { > > #define SPINAND_HAS_QE_BIT BIT(0) > #define SPINAND_HAS_CR_FEAT_BIT BIT(1) > +#define SPINAND_ON_DIE_ECC_MANDATORY BIT(2) /* SHM */ If we go this route, then "mandatory" is not relevant here, we shall convey the fact that the on-die ECC engine cannot be disabled and as mentioned above, there are other impacts. > > /** > * struct spinand_ondie_ecc_conf - private SPI-NAND on-die ECC engine structure > @@ -518,5 +520,6 @@ int spinand_match_and_init(struct spinand_device *spinand, > > int spinand_upd_cfg(struct spinand_device *spinand, u8 mask, u8 val); > int spinand_select_target(struct spinand_device *spinand, unsigned int target); > +int spinand_write_reg_op(struct spinand_device *spinand, u8 reg, u8 val); > > #endif /* __LINUX_MTD_SPINAND_H */ Thanks, Miquèl ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: Re: 2024-03-07 8:01 ` Miquel Raynal @ 2024-03-08 1:27 ` Kyeongrho.Kim [not found] ` <SE2P216MB210205B301549661575720CC833A2@SE2P216MB2102.KORP216.PROD.OUTLOOK.COM> 1 sibling, 0 replies; 1767+ messages in thread From: Kyeongrho.Kim @ 2024-03-08 1:27 UTC (permalink / raw) To: Miquel Raynal Cc: richard@nod.at, vigneshr@ti.com, mmkurbanov@salutedevices.com, ddrokosov@sberdevices.ru, gch981213@gmail.com, michael@walle.cc, broonie@kernel.org, mika.westerberg@linux.intel.com, acelan.kao@canonical.com, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, Mohamed Sardi, Changsub.Shim Hi Miquel, Thank you for your comment. I tried to match the patch format, but it seems to be not enough yet. Can you send me a good sample for the patch format? Thanks, KR -----Original Message----- From: Miquel Raynal <miquel.raynal@bootlin.com> Sent: Thursday, March 7, 2024 5:01 PM To: Kyeongrho.Kim <kr.kim@skyhighmemory.com> Cc: richard@nod.at; vigneshr@ti.com; mmkurbanov@salutedevices.com; ddrokosov@sberdevices.ru; gch981213@gmail.com; michael@walle.cc; broonie@kernel.org; mika.westerberg@linux.intel.com; acelan.kao@canonical.com; linux-kernel@vger.kernel.org; linux-mtd@lists.infradead.org; Mohamed Sardi <moh.sardi@skyhighmemory.com>; Changsub.Shim <changsub.shim@skyhighmemory.com> Subject: Re: Hi, kr.kim@skyhighmemory.com wrote on Thu, 7 Mar 2024 15:07:29 +0900: > Feat: Add SkyHigh Memory Patch code > > Add SPI Nand Patch code of SkyHigh Memory > - Add company dependent code with 'skyhigh.c' > - Insert into 'core.c' so that 'always ECC on' Patch formatting is still messed up. > commit 6061b97a830af8cb5fd0917e833e779451f9046a (HEAD -> master) > Author: KR Kim <kr.kim@skyhighmemory.com> > Date: Thu Mar 7 13:24:11 2024 +0900 > > SPI Nand Patch code of SkyHigh Momory > > Signed-off-by: KR Kim <kr.kim@skyhighmemory.com> > > From 6061b97a830af8cb5fd0917e833e779451f9046a Mon Sep 17 00:00:00 2001 > From: KR Kim <kr.kim@skyhighmemory.com> > Date: Thu, 7 Mar 2024 13:24:11 +0900 > Subject: [PATCH] SPI Nand Patch code of SkyHigh Memory > > --- > drivers/mtd/nand/spi/Makefile | 2 +- > drivers/mtd/nand/spi/core.c | 7 +- > drivers/mtd/nand/spi/skyhigh.c | 155 +++++++++++++++++++++++++++++++++ > include/linux/mtd/spinand.h | 3 + > 4 files changed, 165 insertions(+), 2 deletions(-) mode change > 100644 => 100755 drivers/mtd/nand/spi/Makefile mode change 100644 => > 100755 drivers/mtd/nand/spi/core.c create mode 100644 > drivers/mtd/nand/spi/skyhigh.c mode change 100644 => 100755 > include/linux/mtd/spinand.h > > diff --git a/drivers/mtd/nand/spi/Makefile > b/drivers/mtd/nand/spi/Makefile old mode 100644 new mode 100755 index > 19cc77288ebb..1e61ab21893a > --- a/drivers/mtd/nand/spi/Makefile > +++ b/drivers/mtd/nand/spi/Makefile > @@ -1,4 +1,4 @@ > # SPDX-License-Identifier: GPL-2.0 > spinand-objs := core.o alliancememory.o ato.o esmt.o foresee.o > gigadevice.o macronix.o -spinand-objs += micron.o paragon.o toshiba.o > winbond.o xtx.o > +spinand-objs += micron.o paragon.o skyhigh.o toshiba.o winbond.o > +xtx.o > obj-$(CONFIG_MTD_SPI_NAND) += spinand.o diff --git > a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c old mode > 100644 new mode 100755 index e0b6715e5dfe..e3f0a7544ba4 > --- a/drivers/mtd/nand/spi/core.c > +++ b/drivers/mtd/nand/spi/core.c > @@ -34,7 +34,7 @@ static int spinand_read_reg_op(struct spinand_device *spinand, u8 reg, u8 *val) > return 0; > } > > -static int spinand_write_reg_op(struct spinand_device *spinand, u8 > reg, u8 val) > +int spinand_write_reg_op(struct spinand_device *spinand, u8 reg, u8 > +val) Please do this in a separate commit. > { > struct spi_mem_op op = SPINAND_SET_FEATURE_OP(reg, > spinand->scratchbuf); > @@ -196,6 +196,10 @@ static int spinand_init_quad_enable(struct > spinand_device *spinand) static int spinand_ecc_enable(struct spinand_device *spinand, > bool enable) > { > + /* SHM : always ECC enable */ > + if (spinand->flags & SPINAND_ON_DIE_ECC_MANDATORY) > + return 0; Silently always enabling ECC is not possible. If you cannot disable the on-die engine, then: - you should prevent any other engine type to be used - you should error out if a raw access is requested - these chips are broken, IMO > + > return spinand_upd_cfg(spinand, CFG_ECC_ENABLE, > enable ? CFG_ECC_ENABLE : 0); } @@ -945,6 +949,7 @@ static > const struct spinand_manufacturer *spinand_manufacturers[] = { > ¯onix_spinand_manufacturer, > µn_spinand_manufacturer, > ¶gon_spinand_manufacturer, > + &skyhigh_spinand_manufacturer, > &toshiba_spinand_manufacturer, > &winbond_spinand_manufacturer, > &xtx_spinand_manufacturer, > diff --git a/drivers/mtd/nand/spi/skyhigh.c > b/drivers/mtd/nand/spi/skyhigh.c new file mode 100644 index > 000000000000..92e7572094ff > --- /dev/null > +++ b/drivers/mtd/nand/spi/skyhigh.c > @@ -0,0 +1,155 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c) 2022 SkyHigh Memory Limited > + * > + * Author: Takahiro Kuwano <takahiro.kuwano@infineon.com> */ > + > +#include <linux/device.h> > +#include <linux/kernel.h> > +#include <linux/mtd/spinand.h> > + > +#define SPINAND_MFR_SKYHIGH 0x01 > + > +#define SKYHIGH_STATUS_ECC_1TO2_BITFLIPS (1 << 4) > +#define SKYHIGH_STATUS_ECC_3TO6_BITFLIPS (2 << 4) > +#define SKYHIGH_STATUS_ECC_UNCOR_ERROR (3 << 4) > + > +#define SKYHIGH_CONFIG_PROTECT_EN BIT(1) > + > +static SPINAND_OP_VARIANTS(read_cache_variants, > + SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 4, NULL, 0), > + SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0), > + SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 2, NULL, 0), > + SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0), > + SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0), > + SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0)); > + > +static SPINAND_OP_VARIANTS(write_cache_variants, > + SPINAND_PROG_LOAD_X4(true, 0, NULL, 0), > + SPINAND_PROG_LOAD(true, 0, NULL, 0)); > + > +static SPINAND_OP_VARIANTS(update_cache_variants, > + SPINAND_PROG_LOAD_X4(false, 0, NULL, 0), > + SPINAND_PROG_LOAD(false, 0, NULL, 0)); > + > +static int skyhigh_spinand_ooblayout_ecc(struct mtd_info *mtd, int section, > + struct mtd_oob_region *region) > +{ > + if (section) > + return -ERANGE; > + > + /* SkyHigh's ecc parity is stored in the internal hidden area and is > +not needed for them. */ ECC an "needed" is wrong here. Just stop after "area" > + region->length = 0; > + region->offset = mtd->oobsize; > + > + return 0; > +} > + > +static int skyhigh_spinand_ooblayout_free(struct mtd_info *mtd, int section, > + struct mtd_oob_region *region) { > + if (section) > + return -ERANGE; > + > + region->length = mtd->oobsize - 2; > + region->offset = 2; > + > + return 0; > +} > + > +static const struct mtd_ooblayout_ops skyhigh_spinand_ooblayout = { > + .ecc = skyhigh_spinand_ooblayout_ecc, > + .free = skyhigh_spinand_ooblayout_free, }; > + > +static int skyhigh_spinand_ecc_get_status(struct spinand_device *spinand, > + u8 status) > +{ > + /* SHM > + * 00 : No bit-flip > + * 01 : 1-2 errors corrected > + * 10 : 3-6 errors corrected > + * 11 : uncorrectable > + */ Thanks for the comment but the switch case looks rather straightforward, it is self-sufficient in this case. > + > + switch (status & STATUS_ECC_MASK) { > + case STATUS_ECC_NO_BITFLIPS: > + return 0; > + > + case SKYHIGH_STATUS_ECC_1TO2_BITFLIPS: > + return 2; > + > + case SKYHIGH_STATUS_ECC_3TO6_BITFLIPS: > + return 6; > + > + case SKYHIGH_STATUS_ECC_UNCOR_ERROR: > + return -EBADMSG;; > + > + default: > + break; I guess you can directly call return -EINVAL here? > + } > + > + return -EINVAL; > +} > + > +static const struct spinand_info skyhigh_spinand_table[] = { > + SPINAND_INFO("S35ML01G301", > + SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x15), > + NAND_MEMORG(1, 2048, 64, 64, 1024, 20, 1, 1, 1), > + NAND_ECCREQ(6, 32), > + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, > + &write_cache_variants, > + &update_cache_variants), > + SPINAND_ON_DIE_ECC_MANDATORY, > + SPINAND_ECCINFO(&skyhigh_spinand_ooblayout, > + skyhigh_spinand_ecc_get_status)), > + SPINAND_INFO("S35ML01G300", > + SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x14), > + NAND_MEMORG(1, 2048, 128, 64, 1024, 20, 1, 1, 1), > + NAND_ECCREQ(6, 32), > + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, > + &write_cache_variants, > + &update_cache_variants), > + SPINAND_ON_DIE_ECC_MANDATORY, > + SPINAND_ECCINFO(&skyhigh_spinand_ooblayout, > + skyhigh_spinand_ecc_get_status)), > + SPINAND_INFO("S35ML02G300", > + SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x25), > + NAND_MEMORG(1, 2048, 128, 64, 2048, 40, 2, 1, 1), > + NAND_ECCREQ(6, 32), > + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, > + &write_cache_variants, > + &update_cache_variants), > + SPINAND_ON_DIE_ECC_MANDATORY, > + SPINAND_ECCINFO(&skyhigh_spinand_ooblayout, > + skyhigh_spinand_ecc_get_status)), > + SPINAND_INFO("S35ML04G300", > + SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x35), > + NAND_MEMORG(1, 2048, 128, 64, 4096, 80, 2, 1, 1), > + NAND_ECCREQ(6, 32), > + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, > + &write_cache_variants, > + &update_cache_variants), > + SPINAND_ON_DIE_ECC_MANDATORY, > + SPINAND_ECCINFO(&skyhigh_spinand_ooblayout, > + skyhigh_spinand_ecc_get_status)), }; > + > +static int skyhigh_spinand_init(struct spinand_device *spinand) { > + return spinand_write_reg_op(spinand, REG_BLOCK_LOCK, > + SKYHIGH_CONFIG_PROTECT_EN); Is this really relevant? Isn't there an API for the block lock mechanism? > +} > + > +static const struct spinand_manufacturer_ops skyhigh_spinand_manuf_ops = { > + .init = skyhigh_spinand_init, > + }; > + > +const struct spinand_manufacturer skyhigh_spinand_manufacturer = { > + .id = SPINAND_MFR_SKYHIGH, > + .name = "SkyHigh", > + .chips = skyhigh_spinand_table, > + .nchips = ARRAY_SIZE(skyhigh_spinand_table), > + .ops = &skyhigh_spinand_manuf_ops, > +}; > diff --git a/include/linux/mtd/spinand.h b/include/linux/mtd/spinand.h > old mode 100644 new mode 100755 index badb4c1ac079..0e135076df24 > --- a/include/linux/mtd/spinand.h > +++ b/include/linux/mtd/spinand.h > @@ -268,6 +268,7 @@ extern const struct spinand_manufacturer > gigadevice_spinand_manufacturer; extern const struct > spinand_manufacturer macronix_spinand_manufacturer; extern const > struct spinand_manufacturer micron_spinand_manufacturer; extern const > struct spinand_manufacturer paragon_spinand_manufacturer; > +extern const struct spinand_manufacturer > +skyhigh_spinand_manufacturer; > extern const struct spinand_manufacturer > toshiba_spinand_manufacturer; extern const struct > spinand_manufacturer winbond_spinand_manufacturer; extern const > struct spinand_manufacturer xtx_spinand_manufacturer; @@ -312,6 +313,7 > @@ struct spinand_ecc_info { > > #define SPINAND_HAS_QE_BIT BIT(0) > #define SPINAND_HAS_CR_FEAT_BIT BIT(1) > +#define SPINAND_ON_DIE_ECC_MANDATORY BIT(2) /* SHM */ If we go this route, then "mandatory" is not relevant here, we shall convey the fact that the on-die ECC engine cannot be disabled and as mentioned above, there are other impacts. > > /** > * struct spinand_ondie_ecc_conf - private SPI-NAND on-die ECC engine > structure @@ -518,5 +520,6 @@ int spinand_match_and_init(struct > spinand_device *spinand, > > int spinand_upd_cfg(struct spinand_device *spinand, u8 mask, u8 val); > int spinand_select_target(struct spinand_device *spinand, unsigned int > target); > +int spinand_write_reg_op(struct spinand_device *spinand, u8 reg, u8 > +val); > > #endif /* __LINUX_MTD_SPINAND_H */ Thanks, Miquèl ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <SE2P216MB210205B301549661575720CC833A2@SE2P216MB2102.KORP216.PROD.OUTLOOK.COM>]
* RE: Re: [not found] ` <SE2P216MB210205B301549661575720CC833A2@SE2P216MB2102.KORP216.PROD.OUTLOOK.COM> @ 2024-03-29 4:41 ` Kyeongrho.Kim 0 siblings, 0 replies; 1767+ messages in thread From: Kyeongrho.Kim @ 2024-03-29 4:41 UTC (permalink / raw) To: Miquel Raynal Cc: richard@nod.at, vigneshr@ti.com, mmkurbanov@salutedevices.com, ddrokosov@sberdevices.ru, gch981213@gmail.com, michael@walle.cc, broonie@kernel.org, mika.westerberg@linux.intel.com, acelan.kao@canonical.com, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, Mohamed Sardi, Changsub.Shim (I send again this mail with plain text not HTML.) Dear Miquel, Please see my reply in below email. And please comment if you have any others. Thanks, KR -----Original Message----- From: Miquel Raynal <mailto:miquel.raynal@bootlin.com> Sent: Thursday, March 7, 2024 5:01 PM To: Kyeongrho.Kim <mailto:kr.kim@skyhighmemory.com> Cc: mailto:richard@nod.at; mailto:vigneshr@ti.com; mailto:mmkurbanov@salutedevices.com; mailto:ddrokosov@sberdevices.ru; mailto:gch981213@gmail.com; mailto:michael@walle.cc; mailto:broonie@kernel.org; mailto:mika.westerberg@linux.intel.com; mailto:acelan.kao@canonical.com; mailto:linux-kernel@vger.kernel.org; mailto:linux-mtd@lists.infradead.org; Mohamed Sardi <mailto:moh.sardi@skyhighmemory.com>; Changsub.Shim <mailto:changsub.shim@skyhighmemory.com> Subject: Re: Hi, mailto:kr.kim@skyhighmemory.com wrote on Thu, 7 Mar 2024 15:07:29 +0900: > Feat: Add SkyHigh Memory Patch code > > Add SPI Nand Patch code of SkyHigh Memory > - Add company dependent code with 'skyhigh.c' > - Insert into 'core.c' so that 'always ECC on' Patch formatting is still messed up. > commit 6061b97a830af8cb5fd0917e833e779451f9046a (HEAD -> master) > Author: KR Kim <mailto:kr.kim@skyhighmemory.com> > Date: Thu Mar 7 13:24:11 2024 +0900 > > SPI Nand Patch code of SkyHigh Momory > > Signed-off-by: KR Kim <mailto:kr.kim@skyhighmemory.com> > > From 6061b97a830af8cb5fd0917e833e779451f9046a Mon Sep 17 00:00:00 2001 > From: KR Kim <mailto:kr.kim@skyhighmemory.com> > Date: Thu, 7 Mar 2024 13:24:11 +0900 > Subject: [PATCH] SPI Nand Patch code of SkyHigh Memory > > --- > drivers/mtd/nand/spi/Makefile | 2 +- > drivers/mtd/nand/spi/core.c | 7 +- > drivers/mtd/nand/spi/skyhigh.c | 155 +++++++++++++++++++++++++++++++++ > include/linux/mtd/spinand.h | 3 + > 4 files changed, 165 insertions(+), 2 deletions(-) mode change > 100644 => 100755 drivers/mtd/nand/spi/Makefile mode change 100644 => > 100755 drivers/mtd/nand/spi/core.c create mode 100644 > drivers/mtd/nand/spi/skyhigh.c mode change 100644 => 100755 > include/linux/mtd/spinand.h > > diff --git a/drivers/mtd/nand/spi/Makefile > b/drivers/mtd/nand/spi/Makefile old mode 100644 new mode 100755 index > 19cc77288ebb..1e61ab21893a > --- a/drivers/mtd/nand/spi/Makefile > +++ b/drivers/mtd/nand/spi/Makefile > @@ -1,4 +1,4 @@ > # SPDX-License-Identifier: GPL-2.0 > spinand-objs := core.o alliancememory.o ato.o esmt.o foresee.o > gigadevice.o macronix.o -spinand-objs += micron.o paragon.o toshiba.o > winbond.o xtx.o > +spinand-objs += micron.o paragon.o skyhigh.o toshiba.o winbond.o > +xtx.o > obj-$(CONFIG_MTD_SPI_NAND) += spinand.o diff --git > a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c old mode > 100644 new mode 100755 index e0b6715e5dfe..e3f0a7544ba4 > --- a/drivers/mtd/nand/spi/core.c > +++ b/drivers/mtd/nand/spi/core.c > @@ -34,7 +34,7 @@ static int spinand_read_reg_op(struct spinand_device *spinand, u8 reg, u8 *val) > return 0; > } > > -static int spinand_write_reg_op(struct spinand_device *spinand, u8 > reg, u8 val) > +int spinand_write_reg_op(struct spinand_device *spinand, u8 reg, u8 > +val) Please do this in a separate commit. [SHM] May I know why we need to do a separate commit? Please elaborate for the reason. > { > struct spi_mem_op op = SPINAND_SET_FEATURE_OP(reg, > spinand->scratchbuf); > @@ -196,6 +196,10 @@ static int spinand_init_quad_enable(struct > spinand_device *spinand) static int spinand_ecc_enable(struct spinand_device *spinand, > bool enable) > { > + /* SHM : always ECC enable */ > + if (spinand->flags & SPINAND_ON_DIE_ECC_MANDATORY) > + return 0; Silently always enabling ECC is not possible. If you cannot disable the on-die engine, then: - you should prevent any other engine type to be used - you should error out if a raw access is requested - these chips are broken, IMO [SHM] I understand that you are concern. We have already reviewed 'Always ECC on' to see if there was any problem in many aspects and confirmed that there was no problem. > + > return spinand_upd_cfg(spinand, CFG_ECC_ENABLE, > enable ? CFG_ECC_ENABLE : 0); } @@ -945,6 +949,7 @@ static > const struct spinand_manufacturer *spinand_manufacturers[] = { > ¯onix_spinand_manufacturer, > µn_spinand_manufacturer, > ¶gon_spinand_manufacturer, > + &skyhigh_spinand_manufacturer, > &toshiba_spinand_manufacturer, > &winbond_spinand_manufacturer, > &xtx_spinand_manufacturer, > diff --git a/drivers/mtd/nand/spi/skyhigh.c > b/drivers/mtd/nand/spi/skyhigh.c new file mode 100644 index > 000000000000..92e7572094ff > --- /dev/null > +++ b/drivers/mtd/nand/spi/skyhigh.c > @@ -0,0 +1,155 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c) 2022 SkyHigh Memory Limited > + * > + * Author: Takahiro Kuwano <mailto:takahiro.kuwano@infineon.com> */ > + > +#include <linux/device.h> > +#include <linux/kernel.h> > +#include <linux/mtd/spinand.h> > + > +#define SPINAND_MFR_SKYHIGH 0x01 > + > +#define SKYHIGH_STATUS_ECC_1TO2_BITFLIPS (1 << 4) > +#define SKYHIGH_STATUS_ECC_3TO6_BITFLIPS (2 << 4) > +#define SKYHIGH_STATUS_ECC_UNCOR_ERROR (3 << 4) > + > +#define SKYHIGH_CONFIG_PROTECT_EN BIT(1) > + > +static SPINAND_OP_VARIANTS(read_cache_variants, > + SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 4, NULL, 0), > + SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0), > + SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 2, NULL, 0), > + SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0), > + SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0), > + SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0)); > + > +static SPINAND_OP_VARIANTS(write_cache_variants, > + SPINAND_PROG_LOAD_X4(true, 0, NULL, 0), > + SPINAND_PROG_LOAD(true, 0, NULL, 0)); > + > +static SPINAND_OP_VARIANTS(update_cache_variants, > + SPINAND_PROG_LOAD_X4(false, 0, NULL, 0), > + SPINAND_PROG_LOAD(false, 0, NULL, 0)); > + > +static int skyhigh_spinand_ooblayout_ecc(struct mtd_info *mtd, int section, > + struct mtd_oob_region *region) > +{ > + if (section) > + return -ERANGE; > + > + /* SkyHigh's ecc parity is stored in the internal hidden area and is > +not needed for them. */ ECC an "needed" is wrong here. Just stop after "area" > + region->length = 0; > + region->offset = mtd->oobsize; > + > + return 0; > +} > + > +static int skyhigh_spinand_ooblayout_free(struct mtd_info *mtd, int section, > + struct mtd_oob_region *region) { > + if (section) > + return -ERANGE; > + > + region->length = mtd->oobsize - 2; > + region->offset = 2; > + > + return 0; > +} > + > +static const struct mtd_ooblayout_ops skyhigh_spinand_ooblayout = { > + .ecc = skyhigh_spinand_ooblayout_ecc, > + .free = skyhigh_spinand_ooblayout_free, }; > + > +static int skyhigh_spinand_ecc_get_status(struct spinand_device *spinand, > + u8 status) > +{ > + /* SHM > + * 00 : No bit-flip > + * 01 : 1-2 errors corrected > + * 10 : 3-6 errors corrected > + * 11 : uncorrectable > + */ Thanks for the comment but the switch case looks rather straightforward, it is self-sufficient in this case. > + > + switch (status & STATUS_ECC_MASK) { > + case STATUS_ECC_NO_BITFLIPS: > + return 0; > + > + case SKYHIGH_STATUS_ECC_1TO2_BITFLIPS: > + return 2; > + > + case SKYHIGH_STATUS_ECC_3TO6_BITFLIPS: > + return 6; > + > + case SKYHIGH_STATUS_ECC_UNCOR_ERROR: > + return -EBADMSG;; > + > + default: > + break; I guess you can directly call return -EINVAL here? > + } > + > + return -EINVAL; > +} > + > +static const struct spinand_info skyhigh_spinand_table[] = { > + SPINAND_INFO("S35ML01G301", > + SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x15), > + NAND_MEMORG(1, 2048, 64, 64, 1024, 20, 1, 1, 1), > + NAND_ECCREQ(6, 32), > + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, > + &write_cache_variants, > + &update_cache_variants), > + SPINAND_ON_DIE_ECC_MANDATORY, > + SPINAND_ECCINFO(&skyhigh_spinand_ooblayout, > + skyhigh_spinand_ecc_get_status)), > + SPINAND_INFO("S35ML01G300", > + SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x14), > + NAND_MEMORG(1, 2048, 128, 64, 1024, 20, 1, 1, 1), > + NAND_ECCREQ(6, 32), > + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, > + &write_cache_variants, > + &update_cache_variants), > + SPINAND_ON_DIE_ECC_MANDATORY, > + SPINAND_ECCINFO(&skyhigh_spinand_ooblayout, > + skyhigh_spinand_ecc_get_status)), > + SPINAND_INFO("S35ML02G300", > + SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x25), > + NAND_MEMORG(1, 2048, 128, 64, 2048, 40, 2, 1, 1), > + NAND_ECCREQ(6, 32), > + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, > + &write_cache_variants, > + &update_cache_variants), > + SPINAND_ON_DIE_ECC_MANDATORY, > + SPINAND_ECCINFO(&skyhigh_spinand_ooblayout, > + skyhigh_spinand_ecc_get_status)), > + SPINAND_INFO("S35ML04G300", > + SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x35), > + NAND_MEMORG(1, 2048, 128, 64, 4096, 80, 2, 1, 1), > + NAND_ECCREQ(6, 32), > + SPINAND_INFO_OP_VARIANTS(&read_cache_variants, > + &write_cache_variants, > + &update_cache_variants), > + SPINAND_ON_DIE_ECC_MANDATORY, > + SPINAND_ECCINFO(&skyhigh_spinand_ooblayout, > + skyhigh_spinand_ecc_get_status)), }; > + > +static int skyhigh_spinand_init(struct spinand_device *spinand) { > + return spinand_write_reg_op(spinand, REG_BLOCK_LOCK, > + SKYHIGH_CONFIG_PROTECT_EN); Is this really relevant? Isn't there an API for the block lock mechanism? [SHM] SHM device should be done ‘Config Protect Enable’ first for unlock. I changed to use the 'spinand_lock_block' function instead of the 'spinand_write_reg_op' function. > +} > + > +static const struct spinand_manufacturer_ops skyhigh_spinand_manuf_ops = { > + .init = skyhigh_spinand_init, > + }; > + > +const struct spinand_manufacturer skyhigh_spinand_manufacturer = { > + .id = SPINAND_MFR_SKYHIGH, > + .name = "SkyHigh", > + .chips = skyhigh_spinand_table, > + .nchips = ARRAY_SIZE(skyhigh_spinand_table), > + .ops = &skyhigh_spinand_manuf_ops, > +}; > diff --git a/include/linux/mtd/spinand.h b/include/linux/mtd/spinand.h > old mode 100644 new mode 100755 index badb4c1ac079..0e135076df24 > --- a/include/linux/mtd/spinand.h > +++ b/include/linux/mtd/spinand.h > @@ -268,6 +268,7 @@ extern const struct spinand_manufacturer > gigadevice_spinand_manufacturer; extern const struct > spinand_manufacturer macronix_spinand_manufacturer; extern const > struct spinand_manufacturer micron_spinand_manufacturer; extern const > struct spinand_manufacturer paragon_spinand_manufacturer; > +extern const struct spinand_manufacturer > +skyhigh_spinand_manufacturer; > extern const struct spinand_manufacturer > toshiba_spinand_manufacturer; extern const struct > spinand_manufacturer winbond_spinand_manufacturer; extern const > struct spinand_manufacturer xtx_spinand_manufacturer; @@ -312,6 +313,7 > @@ struct spinand_ecc_info { > > #define SPINAND_HAS_QE_BIT BIT(0) > #define SPINAND_HAS_CR_FEAT_BIT BIT(1) > +#define SPINAND_ON_DIE_ECC_MANDATORY BIT(2) /* SHM */ If we go this route, then "mandatory" is not relevant here, we shall convey the fact that the on-die ECC engine cannot be disabled and as mentioned above, there are other impacts. [SHM] Please elaborate in more specific what I should do. > > /** > * struct spinand_ondie_ecc_conf - private SPI-NAND on-die ECC engine > structure @@ -518,5 +520,6 @@ int spinand_match_and_init(struct > spinand_device *spinand, > > int spinand_upd_cfg(struct spinand_device *spinand, u8 mask, u8 val); > int spinand_select_target(struct spinand_device *spinand, unsigned int > target); > +int spinand_write_reg_op(struct spinand_device *spinand, u8 reg, u8 > +val); > > #endif /* __LINUX_MTD_SPINAND_H */ Thanks, Miquèl ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH v3 0/7] net/gve: RSS Support for GVE Driver
@ 2024-01-24 0:14 Joshua Washington
[not found] ` <20240126173317.2779230-1-joshwash@google.com>
0 siblings, 1 reply; 1767+ messages in thread
From: Joshua Washington @ 2024-01-24 0:14 UTC (permalink / raw)
Cc: dev, Ferruh Yigit, Rushil Gupta, Joshua Washington
This patch series introduces RSS support for the GVE poll-mode driver.
This series includes implementations of the following eth_dev_ops:
1) rss_hash_update
2) rss_hash_conf_get
3) reta_query
4) reta_update
In rss_hash_update, the GVE driver supports the following RSS hash
types:
* RTE_ETH_RSS_IPV4
* RTE_ETH_RSS_NONFRAG_IPV4_TCP
* RTE_ETH_RSS_NONFRAG_IPV4_UDP
* RTE_ETH_RSS_IPV6
* RTE_ETH_RSS_IPV6_EX
* RTE_ETH_RSS_NONFRAG_IPV6_TCP
* RTE_ETH_RSS_NONFRAG_IPV6_UDP
* RTE_ETH_RSS_IPV6_TCP_EX
* RTE_ETH_RSS_IPV6_UDP_EX
The hash key is 40B, and the lookup table has 128 entries. These values
are not configurable in this implementation.
In general, the DPDK driver expects the RSS hash configuration to be set
with a key before the redriection table is set up. When the RSS hash is
configured, a default redirection table is generated based on the number
of queues. When the device is re-configured, the redirection table is
reset to the default value based on the queue count.
An important note is that the gVNIC device expects 32 bit integers for
RSS redirection table entries, while the RTE API uses 16 bit integers.
However, this is unlikely to be an issue, as these values represent
receive queues, and the gVNIC device does not support anywhere near 64K
queues.
This series also updates the corresponding feature matrix ertries and
documentation as it pertains to RSS support in the GVE driver.
v2:
Add commmit messages for patches with it missing, and other checkpatches
fixes.
Note: There is a warning about complex macros being parenthesized that
does not seem to be well-founded.
v3:
Fix build warnings that come up on certain distros.
Joshua Washington (7):
net/gve: fully expose RSS offload support in dev_info
net/gve: RSS adminq command changes
net/gve: add gve_rss library for handling RSS-related behaviors
net/gve: RSS configuration update support
net/gve: RSS redirection table update support
net/gve: update gve.ini with RSS capabilities
net/gve: update GVE documentation with RSS support
doc/guides/nics/features/gve.ini | 3 +
doc/guides/nics/gve.rst | 16 ++-
drivers/net/gve/base/gve.h | 15 ++
drivers/net/gve/base/gve_adminq.c | 59 ++++++++
drivers/net/gve/base/gve_adminq.h | 21 +++
drivers/net/gve/gve_ethdev.c | 231 +++++++++++++++++++++++++++++-
drivers/net/gve/gve_ethdev.h | 17 +++
drivers/net/gve/gve_rss.c | 206 ++++++++++++++++++++++++++
drivers/net/gve/gve_rss.h | 107 ++++++++++++++
drivers/net/gve/meson.build | 1 +
10 files changed, 667 insertions(+), 9 deletions(-)
create mode 100644 drivers/net/gve/gve_rss.c
create mode 100644 drivers/net/gve/gve_rss.h
--
2.43.0.429.g432eaa2c6b-goog
^ permalink raw reply [flat|nested] 1767+ messages in thread[parent not found: <20240126173317.2779230-1-joshwash@google.com>]
* Re: [not found] ` <20240126173317.2779230-1-joshwash@google.com> @ 2024-01-31 14:58 ` Ferruh Yigit 0 siblings, 0 replies; 1767+ messages in thread From: Ferruh Yigit @ 2024-01-31 14:58 UTC (permalink / raw) To: Joshua Washington; +Cc: dev, Rushil Gupta On 1/26/2024 5:33 PM, Joshua Washington wrote: > Subject: [PATCH v4 0/7] net/gve: RSS Support for GVE Driver > > This patch series introduces RSS support for the GVE poll-mode driver. > This series includes implementations of the following eth_dev_ops: > > 1) rss_hash_update > 2) rss_hash_conf_get > 3) reta_query > 4) reta_update > > In rss_hash_update, the GVE driver supports the following RSS hash > types: > > * RTE_ETH_RSS_IPV4 > * RTE_ETH_RSS_NONFRAG_IPV4_TCP > * RTE_ETH_RSS_NONFRAG_IPV4_UDP > * RTE_ETH_RSS_IPV6 > * RTE_ETH_RSS_IPV6_EX > * RTE_ETH_RSS_NONFRAG_IPV6_TCP > * RTE_ETH_RSS_NONFRAG_IPV6_UDP > * RTE_ETH_RSS_IPV6_TCP_EX > * RTE_ETH_RSS_IPV6_UDP_EX > > The hash key is 40B, and the lookup table has 128 entries. These values > are not configurable in this implementation. > > In general, the DPDK driver expects the RSS hash configuration to be set > with a key before the redriection table is set up. When the RSS hash is > configured, a default redirection table is generated based on the number > of queues. When the device is re-configured, the redirection table is > reset to the default value based on the queue count. > > An important note is that the gVNIC device expects 32 bit integers for > RSS redirection table entries, while the RTE API uses 16 bit integers. > However, this is unlikely to be an issue, as these values represent > receive queues, and the gVNIC device does not support anywhere near 64K > queues. > > This series also updates the corresponding feature matrix ertries and > documentation as it pertains to RSS support in the GVE driver. > > v2: > Add commmit messages for patches with it missing, and other checkpatches > fixes. > > Note: There is a warning about complex macros being parenthesized that > does not seem to be well-founded. > > v3: > Fix build warnings that come up on certain distros. > > v4: > Fix formatting in gve_adminq.c > > Joshua Washington (7): > net/gve: fully expose RSS offload support in dev_info > net/gve: RSS adminq command changes > net/gve: add gve_rss library for handling RSS-related behaviors > net/gve: RSS configuration update support > net/gve: RSS redirection table update support > net/gve: update gve.ini with RSS capabilities > net/gve: update GVE documentation with RSS support > > './devtools/check-git-log.sh' script is giving warnings [1]: Expected patch title format is: net/gve: <verb> <object> <verb> should start with lowercase. [1] - check-git-log: Wrong headline format: net/gve: fully expose RSS offload support in dev_info net/gve: add gve_rss library for handling RSS-related behaviors Wrong headline uppercase: net/gve: RSS adminq command changes net/gve: RSS configuration update support net/gve: RSS redirection table update support Headline too long: net/gve: add gve_rss library for handling RSS-related behaviors ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [RFC] [PATCH 0/3] xfs: use large folios for buffers @ 2024-01-18 22:19 Dave Chinner 2024-01-22 10:13 ` Andi Kleen 0 siblings, 1 reply; 1767+ messages in thread From: Dave Chinner @ 2024-01-18 22:19 UTC (permalink / raw) To: linux-xfs; +Cc: willy, linux-mm The XFS buffer cache supports metadata buffers up to 64kB, and it does so by aggregating multiple pages into a single contiguous memory region using vmapping. This is expensive (both the setup and the runtime TLB mapping cost), and would be unnecessary if we could allocate large contiguous memory regions for the buffers in the first place. Enter multi-page folios. This patchset converts the buffer cache to use the folio API, then enhances it to optimisitically use large folios where possible. It retains the old "vmap an array of single page folios" functionality as a fallback when large folio allocation fails. This means that, like page cache support for large folios, we aren't dependent on large folio allocation succeeding all the time. This relegates the single page array allocation mechanism to the "slow path" that we don't have to care so much about performance of this path anymore. This might allow us to simplify it a bit in future. One of the issues with the folio conversion is that we use a couple of APIs that take struct page ** (i.e. pointers to page pointer arrays) and there aren't folio counterparts. These are the bulk page allocator and vm_map_ram(). In the cases where they are used, we cast &bp->b_folios[] to (struct page **) knowing that this array will only contain single page folios and that single page folios and struct page are the same structure and so have the same address. This is a bit of a hack (hence the RFC) but I'm not sure that it's worth adding folio versions of these interfaces right now. We don't need to use the bulk page allocator so much any more, because that's now a slow path and we could probably just call folio_alloc() in a loop like we used to. What to do about vm_map_ram() is a little less clear.... The other issue I tripped over in doing this conversion is that the discontiguous buffer straddling code in the buf log item dirty region tracking is broken. We don't actually exercise that code on existing configurations, and I tripped over it when tracking down a bug in the folio conversion. I fixed it and short-circuted the check for contiguous buffers, but that didn't fix the failure I was seeing (which was not handling bp->b_offset and large folios properly when building bios). Apart from those issues, the conversion and enhancement is relatively straight forward. It passes fstests on both 512 and 4096 byte sector size storage (512 byte sectors exercise the XBF_KMEM path which has non-zero bp->b_offset values) and doesn't appear to cause any problems with large directory buffers, though I haven't done any real testing on those yet. Large folio allocations are definitely being exercised, though, as all the inode cluster buffers are 16kB on a 512 byte inode V5 filesystem. Thoughts, comments, etc? Note: this patchset is on top of the NOFS removal patchset I sent a few days ago. That can be pulled from this git branch: https://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git xfs-kmem-cleanup ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) 2024-01-18 22:19 [RFC] [PATCH 0/3] xfs: use large folios for buffers Dave Chinner @ 2024-01-22 10:13 ` Andi Kleen 2024-01-22 11:53 ` Dave Chinner 0 siblings, 1 reply; 1767+ messages in thread From: Andi Kleen @ 2024-01-22 10:13 UTC (permalink / raw) To: linux-xfs, david, linux-mm Dave Chinner <david@fromorbit.com> writes: > Thoughts, comments, etc? The interesting part is if it will cause additional tail latencies allocating under fragmentation with direct reclaim, compaction etc. being triggered before it falls back to the base page path. In fact it is highly likely it will, the question is just how bad it is. Unfortunately benchmarking for that isn't that easy, it needs artificial memory fragmentation and then some high stress workload, and then instrumenting the transactions for individual latencies. I would in any case add a tunable for it in case people run into this. Tail latencies are a common concern on many IO workloads. -Andi ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-01-22 10:13 ` Andi Kleen @ 2024-01-22 11:53 ` Dave Chinner 0 siblings, 0 replies; 1767+ messages in thread From: Dave Chinner @ 2024-01-22 11:53 UTC (permalink / raw) To: Andi Kleen; +Cc: linux-xfs, linux-mm On Mon, Jan 22, 2024 at 02:13:23AM -0800, Andi Kleen wrote: > Dave Chinner <david@fromorbit.com> writes: > > > Thoughts, comments, etc? > > The interesting part is if it will cause additional tail latencies > allocating under fragmentation with direct reclaim, compaction > etc. being triggered before it falls back to the base page path. It's not like I don't know these problems exist with memory allocation. Go have a look at xlog_kvmalloc() which is an open coded kvmalloc() that allows the high order kmalloc allocations to fail-fast without triggering all the expensive and unnecessary direct reclaim overhead (e.g. compaction!) because we can fall back to vmalloc without huge concerns. When high order allocations start to fail, then we fall back to vmalloc and then we hit the long standing vmalloc scalability problems before anything else in XFS or the IO path becomes a bottleneck. IOWs, we already know that fail-fast high-order allocation is a more efficient and effective fast path than using vmalloc/vmap_ram() all the time. As this is an RFC, I haven't implemented stuff like this yet - I haven't seen anything in the profiles indicating that high order folio allocation is failing and causing lots of reclaim overhead, so I simply haven't added fail-fast behaviour yet... > In fact it is highly likely it will, the question is just how bad it is. > > Unfortunately benchmarking for that isn't that easy, it needs artificial > memory fragmentation and then some high stress workload, and then > instrumenting the transactions for individual latencies. I stress test and measure XFS metadata performance under sustained memory pressure all the time. This change has not caused any obvious regressions in the short time I've been testing it. I still need to do perf testing on large directory block sizes. That is where high-order allocations will get stressed - that's where xlog_kvmalloc() starts dominating the profiles as it trips over vmalloc scalability issues... > I would in any case add a tunable for it in case people run into this. No tunables. It either works or it doesn't. If we can't make it work reliably by default, we throw it in the dumpster, light it on fire and walk away. > Tail latencies are a common concern on many IO workloads. Yes, for user data operations it's a common concern. For metadata, not so much - there's so many far worse long tail latencies in metadata operations (like waiting for journal space) that memory allocation latencies in the metadata IO path are largely noise.... -Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2024-01-16 6:46 meir elisha 2024-01-16 7:05 ` Dan Carpenter 0 siblings, 1 reply; 1767+ messages in thread From: meir elisha @ 2024-01-16 6:46 UTC (permalink / raw) To: linux-staging subscribe linux-staging ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-01-16 6:46 meir elisha @ 2024-01-16 7:05 ` Dan Carpenter 0 siblings, 0 replies; 1767+ messages in thread From: Dan Carpenter @ 2024-01-16 7:05 UTC (permalink / raw) To: meir elisha; +Cc: linux-staging You have to send an email to linux-staging+subscribe@lists.linux.dev regards, dan carpenter ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2023-12-07 4:40 Emma Tebibyte 2023-12-07 5:00 ` Christoph Anton Mitterer 0 siblings, 1 reply; 1767+ messages in thread From: Emma Tebibyte @ 2023-12-07 4:40 UTC (permalink / raw) To: dash Hi, I found a bug in dash version 0.5.12 where when shifting more than ?#, the shell exits before evaluating a logical OR operator. To reproduce this issue: $ set -- 1 $ shift 2 || printf 'meow\n' dash: 2: shift: can't shift that many $ This also occurs using if: $ set -- 1 $ if shift 2; then > true > else > printf 'meow\n' > fi dash: 2: shift: can't shift that many $ Thanks, Emma Tebibyte ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2023-12-07 4:40 Emma Tebibyte @ 2023-12-07 5:00 ` Christoph Anton Mitterer 2023-12-07 5:29 ` Re: Lawrence Velázquez 0 siblings, 1 reply; 1767+ messages in thread From: Christoph Anton Mitterer @ 2023-12-07 5:00 UTC (permalink / raw) To: Emma Tebibyte, dash On Wed, 2023-12-06 at 21:40 -0700, Emma Tebibyte wrote: > I found a bug in dash version 0.5.12 where when shifting more than > ?#, > the shell exits before evaluating a logical OR operator. AFAIU from POSIX this is perfectly valid behaviour: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#shift > EXIT STATUS > If the n operand is invalid or is greater than "$#", this may be > considered a syntax error and a non-interactive shell may exit; if > the shell does not exit in this case, a non-zero exit status shall > be returned. Otherwise, zero shall be returned. Cheers, Chris. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2023-12-07 5:00 ` Christoph Anton Mitterer @ 2023-12-07 5:29 ` Lawrence Velázquez 0 siblings, 0 replies; 1767+ messages in thread From: Lawrence Velázquez @ 2023-12-07 5:29 UTC (permalink / raw) To: Christoph Anton Mitterer, Emma Tebibyte; +Cc: dash On Thu, Dec 7, 2023, at 12:00 AM, Christoph Anton Mitterer wrote: > On Wed, 2023-12-06 at 21:40 -0700, Emma Tebibyte wrote: >> I found a bug in dash version 0.5.12 where when shifting more than >> ?#, >> the shell exits before evaluating a logical OR operator. > > AFAIU from POSIX this is perfectly valid behaviour: > > https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#shift > >> EXIT STATUS >> If the n operand is invalid or is greater than "$#", this may be >> considered a syntax error and a non-interactive shell may exit; if >> the shell does not exit in this case, a non-zero exit status shall >> be returned. Otherwise, zero shall be returned. See also Section 2.8.1 [*], which states that interactive shells shall not exit on special built-in utility errors and that: In all of the cases shown in the table where an interactive shell is required not to exit, the shell shall not perform any further processing of the command in which the error occurred. [*] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_01 -- vq ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [NDCTL PATCH v3 2/2] cxl: Add check for regions before disabling memdev @ 2023-11-30 21:51 Dave Jiang 2024-04-17 6:46 ` Yao Xingtao 0 siblings, 1 reply; 1767+ messages in thread From: Dave Jiang @ 2023-11-30 21:51 UTC (permalink / raw) To: linux-cxl, nvdimm; +Cc: vishal.l.verma, caoqq Add a check for memdev disable to see if there are active regions present before disabling the device. This is necessary now regions are present to fulfill the TODO that was left there. The best way to determine if a region is active is to see if there are decoders enabled for the mem device. This is also best effort as the state is only a snapshot the kernel provides and is not atomic WRT the memdev disable operation. The expectation is the admin issuing the command has full control of the mem device and there are no other agents also attempt to control the device. Reviewed-by: Quanquan Cao <caoqq@fujitsu.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> --- v3: - Add emission of warning for forcing operation. (Quanquan) v2: - Warn if active region regardless of -f. (Alison) - Expound on -f behavior in man page. (Vishal) --- Documentation/cxl/cxl-disable-memdev.txt | 4 +++- cxl/memdev.c | 20 +++++++++++++++++--- 2 files changed, 20 insertions(+), 4 deletions(-) diff --git a/Documentation/cxl/cxl-disable-memdev.txt b/Documentation/cxl/cxl-disable-memdev.txt index c4edb93ee94a..34b720288705 100644 --- a/Documentation/cxl/cxl-disable-memdev.txt +++ b/Documentation/cxl/cxl-disable-memdev.txt @@ -27,7 +27,9 @@ include::bus-option.txt[] a device if the tool determines the memdev is in active usage. Recall that CXL memory ranges might have been established by platform firmware and disabling an active device is akin to force removing - memory from a running system. + memory from a running system. Going down this path does not offline + active memory if they are currently online. User is recommended to + offline and disable the appropriate regions before disabling the memdevs. -v:: Turn on verbose debug messages in the library (if libcxl was built with diff --git a/cxl/memdev.c b/cxl/memdev.c index 2dd2e7fcc4dd..ed962d478048 100644 --- a/cxl/memdev.c +++ b/cxl/memdev.c @@ -437,14 +437,28 @@ static int action_free_dpa(struct cxl_memdev *memdev, static int action_disable(struct cxl_memdev *memdev, struct action_context *actx) { + struct cxl_endpoint *ep; + struct cxl_port *port; + if (!cxl_memdev_is_enabled(memdev)) return 0; - if (!param.force) { - /* TODO: actually detect rather than assume active */ + ep = cxl_memdev_get_endpoint(memdev); + if (!ep) + return -ENODEV; + + port = cxl_endpoint_get_port(ep); + if (!port) + return -ENODEV; + + if (cxl_port_decoders_committed(port)) { log_err(&ml, "%s is part of an active region\n", cxl_memdev_get_devname(memdev)); - return -EBUSY; + if (!param.force) + return -EBUSY; + + log_err(&ml, "Forcing %s disable with an active region!\n", + cxl_memdev_get_devname(memdev)); } return cxl_memdev_disable_invalidate(memdev); ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* (no subject) 2023-11-30 21:51 [NDCTL PATCH v3 2/2] cxl: Add check for regions before disabling memdev Dave Jiang @ 2024-04-17 6:46 ` Yao Xingtao 2024-04-17 18:14 ` Verma, Vishal L 0 siblings, 1 reply; 1767+ messages in thread From: Yao Xingtao @ 2024-04-17 6:46 UTC (permalink / raw) To: dave.jiang; +Cc: caoqq, linux-cxl, nvdimm, vishal.l.verma Hi Dave, I have applied this patch in my env, and done a lot of testing, this feature is currently working fine. But it is not merged into master branch yet, are there any updates on this feature? Associated patches: https://lore.kernel.org/linux-cxl/170112921107.2687457.2741231995154639197.stgit@djiang5-mobl3/ https://lore.kernel.org/linux-cxl/170120423159.2725915.14670830315829916850.stgit@djiang5-mobl3/ Thanks Xingtao ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2024-04-17 6:46 ` Yao Xingtao @ 2024-04-17 18:14 ` Verma, Vishal L 2024-04-22 7:26 ` Re: Xingtao Yao (Fujitsu) 0 siblings, 1 reply; 1767+ messages in thread From: Verma, Vishal L @ 2024-04-17 18:14 UTC (permalink / raw) To: Jiang, Dave, yaoxt.fnst@fujitsu.com Cc: caoqq@fujitsu.com, linux-cxl@vger.kernel.org, nvdimm@lists.linux.dev On Wed, 2024-04-17 at 02:46 -0400, Yao Xingtao wrote: > > Hi Dave, > I have applied this patch in my env, and done a lot of testing, > this > feature is currently working fine. > But it is not merged into master branch yet, are there any updates > on this feature? Hi Xingtao, Turns out that I had applied this to a branch but forgot to merge and push it. Thanks for the ping - done now, and pushed to pending. > > Associated patches: > https://lore.kernel.org/linux-cxl/170112921107.2687457.2741231995154639197.stgit@djiang5-mobl3/ > https://lore.kernel.org/linux-cxl/170120423159.2725915.14670830315829916850.stgit@djiang5-mobl3/ > > Thanks > Xingtao ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: Re: 2024-04-17 18:14 ` Verma, Vishal L @ 2024-04-22 7:26 ` Xingtao Yao (Fujitsu) 0 siblings, 0 replies; 1767+ messages in thread From: Xingtao Yao (Fujitsu) @ 2024-04-22 7:26 UTC (permalink / raw) To: Verma, Vishal L, Jiang, Dave Cc: Quanquan Cao (Fujitsu), linux-cxl@vger.kernel.org, nvdimm@lists.linux.dev > -----Original Message----- > From: Verma, Vishal L <vishal.l.verma@intel.com> > Sent: Thursday, April 18, 2024 2:14 AM > To: Jiang, Dave <dave.jiang@intel.com>; Yao, Xingtao/姚 幸涛 > <yaoxt.fnst@fujitsu.com> > Cc: Cao, Quanquan/曹 全全 <caoqq@fujitsu.com>; linux-cxl@vger.kernel.org; > nvdimm@lists.linux.dev > Subject: Re: > > On Wed, 2024-04-17 at 02:46 -0400, Yao Xingtao wrote: > > > > Hi Dave, > > I have applied this patch in my env, and done a lot of testing, > > this > > feature is currently working fine. > > But it is not merged into master branch yet, are there any updates > > on this feature? > > Hi Xingtao, > > Turns out that I had applied this to a branch but forgot to merge and > push it. Thanks for the ping - done now, and pushed to pending. Awesome, many thanks!!! > > > > > Associated patches: > > > https://lore.kernel.org/linux-cxl/170112921107.2687457.2741231995154639197.st > git@djiang5-mobl3/ > > > https://lore.kernel.org/linux-cxl/170120423159.2725915.14670830315829916850.s > tgit@djiang5-mobl3/ > > > > Thanks > > Xingtao ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <c8d43894-7e66-4a01-88fc-10708dc53b6b@amd.com>]
[parent not found: <878r7z4kb4.ffs@tglx>]
[parent not found: <e79dea49-0c07-4ca2-b359-97dd1bc579c8@amd.com>]
[parent not found: <87ttqhcotn.ffs@tglx>]
[parent not found: <87v8avawe0.ffs@tglx>]
[parent not found: <32bcaa8a-0413-4aa4-97a0-189830da8654@amd.com>]
[parent not found: <ZTkzYA3w2p3L4SVA@localhost>]
[parent not found: <87jzra6235.ffs@tglx>]
[parent not found: <875y2u5s8g.ffs@tglx>]
* Re: [not found] ` <875y2u5s8g.ffs@tglx> @ 2023-10-25 22:11 ` Mario Limonciello 2023-10-26 9:27 ` Re: Thomas Gleixner 0 siblings, 1 reply; 1767+ messages in thread From: Mario Limonciello @ 2023-10-25 22:11 UTC (permalink / raw) To: Thomas Gleixner, David Lazar Cc: Hans de Goede, kys, hpa, x86, LKML, Borislav Petkov, Rafael J. Wysocki, Linux kernel regressions list On 10/25/2023 16:04, Thomas Gleixner wrote: > David and a few others reported that on certain newer systems some legacy > interrupts fail to work correctly. > > Debugging revealed that the BIOS of these systems leaves the legacy PIC in > uninitialized state which makes the PIC detection fail and the kernel > switches to a dummy implementation. > > Unfortunately this fallback causes quite some code to fail as it depends on > checks for the number of legacy PIC interrupts or the availability of the > real PIC. > > In theory there is no reason to use the PIC on any modern system when > IO/APIC is available, but the dependencies on the related checks cannot be > resolved trivially and on short notice. This needs lots of analysis and > rework. > > The PIC detection has been added to avoid quirky checks and force selection > of the dummy implementation all over the place, especially in VM guest > scenarios. So it's not an option to revert the relevant commit as that > would break a lot of other scenarios. > > One solution would be to try to initialize the PIC on detection fail and > retry the detection, but that puts the burden on everything which does not > have a PIC. > > Fortunately the ACPI/MADT table header has a flag field, which advertises > in bit 0 that the system is PCAT compatible, which means it has a legacy > 8259 PIC. > > Evaluate that bit and if set avoid the detection routine and keep the real > PIC installed, which then gets initialized (for nothing) and makes the rest > of the code with all the dependencies work again. > > Fixes: e179f6914152 ("x86, irq, pic: Probe for legacy PIC and set legacy_pic appropriately") > Reported-by: David Lazar <dlazar@gmail.com> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > Tested-by: David Lazar <dlazar@gmail.com> > Cc: stable@vger.kernel.org > Link: https://bugzilla.kernel.org/show_bug.cgi?id=218003 s/Link/Closes/ Presumably you will add a proper subject when this is committed? With adding title and fixing that tag: Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> > --- > --- > arch/x86/include/asm/i8259.h | 2 ++ > arch/x86/kernel/acpi/boot.c | 3 +++ > arch/x86/kernel/i8259.c | 38 ++++++++++++++++++++++++++++++-------- > 3 files changed, 35 insertions(+), 8 deletions(-) > > --- a/arch/x86/include/asm/i8259.h > +++ b/arch/x86/include/asm/i8259.h > @@ -69,6 +69,8 @@ struct legacy_pic { > void (*make_irq)(unsigned int irq); > }; > > +void legacy_pic_pcat_compat(void); > + > extern struct legacy_pic *legacy_pic; > extern struct legacy_pic null_legacy_pic; > > --- a/arch/x86/kernel/acpi/boot.c > +++ b/arch/x86/kernel/acpi/boot.c > @@ -148,6 +148,9 @@ static int __init acpi_parse_madt(struct > pr_debug("Local APIC address 0x%08x\n", madt->address); > } > > + if (madt->flags & ACPI_MADT_PCAT_COMPAT) > + legacy_pic_pcat_compat(); > + > /* ACPI 6.3 and newer support the online capable bit. */ > if (acpi_gbl_FADT.header.revision > 6 || > (acpi_gbl_FADT.header.revision == 6 && > --- a/arch/x86/kernel/i8259.c > +++ b/arch/x86/kernel/i8259.c > @@ -32,6 +32,7 @@ > */ > static void init_8259A(int auto_eoi); > > +static bool pcat_compat __ro_after_init; > static int i8259A_auto_eoi; > DEFINE_RAW_SPINLOCK(i8259A_lock); > > @@ -299,15 +300,32 @@ static void unmask_8259A(void) > > static int probe_8259A(void) > { > + unsigned char new_val, probe_val = ~(1 << PIC_CASCADE_IR); > unsigned long flags; > - unsigned char probe_val = ~(1 << PIC_CASCADE_IR); > - unsigned char new_val; > + > + /* > + * If MADT has the PCAT_COMPAT flag set, then do not bother probing > + * for the PIC. Some BIOSes leave the PIC uninitialized and probing > + * fails. > + * > + * Right now this causes problems as quite some code depends on > + * nr_legacy_irqs() > 0 or has_legacy_pic() == true. This is silly > + * when the system has an IO/APIC because then PIC is not required > + * at all, except for really old machines where the timer interrupt > + * must be routed through the PIC. So just pretend that the PIC is > + * there and let legacy_pic->init() initialize it for nothing. > + * > + * Alternatively this could just try to initialize the PIC and > + * repeat the probe, but for cases where there is no PIC that's > + * just pointless. > + */ > + if (pcat_compat) > + return nr_legacy_irqs(); > + > /* > - * Check to see if we have a PIC. > - * Mask all except the cascade and read > - * back the value we just wrote. If we don't > - * have a PIC, we will read 0xff as opposed to the > - * value we wrote. > + * Check to see if we have a PIC. Mask all except the cascade and > + * read back the value we just wrote. If we don't have a PIC, we > + * will read 0xff as opposed to the value we wrote. > */ > raw_spin_lock_irqsave(&i8259A_lock, flags); > > @@ -429,5 +447,9 @@ static int __init i8259A_init_ops(void) > > return 0; > } > - > device_initcall(i8259A_init_ops); > + > +void __init legacy_pic_pcat_compat(void) > +{ > + pcat_compat = true; > +} ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2023-10-25 22:11 ` Re: Mario Limonciello @ 2023-10-26 9:27 ` Thomas Gleixner 0 siblings, 0 replies; 1767+ messages in thread From: Thomas Gleixner @ 2023-10-26 9:27 UTC (permalink / raw) To: Mario Limonciello, David Lazar Cc: Hans de Goede, kys, hpa, x86, LKML, Borislav Petkov, Rafael J. Wysocki, Linux kernel regressions list On Wed, Oct 25 2023 at 17:11, Mario Limonciello wrote: > On 10/25/2023 16:04, Thomas Gleixner wrote: >> Cc: stable@vger.kernel.org >> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218003 > > s/Link/Closes/ Sure. > Presumably you will add a proper subject when this is committed? Bah, yes. I stopped replacing the subject line right after clearing it :( > With adding title and fixing that tag: > > Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <TXJgqLzlM6oCfTXKSqrSBk@txt.att.net>]
* Re: [not found] <TXJgqLzlM6oCfTXKSqrSBk@txt.att.net> @ 2023-08-09 5:12 ` Luna Jernberg 0 siblings, 0 replies; 1767+ messages in thread From: Luna Jernberg @ 2023-08-09 5:12 UTC (permalink / raw) To: 5598162950, Luna Jernberg; +Cc: git What is the question? Den ons 9 aug. 2023 kl 03:31 skrev <5598162950@mms.cricketwireless.net>: ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <64b09dbb.630a0220.e80b9.e2ed@mx.google.com>]
* Re: [not found] <64b09dbb.630a0220.e80b9.e2ed@mx.google.com> @ 2023-07-14 8:05 ` Andy Shevchenko 0 siblings, 0 replies; 1767+ messages in thread From: Andy Shevchenko @ 2023-07-14 8:05 UTC (permalink / raw) To: luoruihong Cc: ilpo.jarvinen, gregkh, jirislaby, linux-kernel, linux-serial, luoruihong, weipengliang, wengjinfei On Fri, Jul 14, 2023 at 08:58:29AM +0800, luoruihong wrote: > On Thu, Jul 13, 2023 at 07:51:14PM +0300, Andy Shevchenko wrote: > > On Thu, Jul 13, 2023 at 08:42:36AM +0800, Ruihong Luo wrote: > > > Preserve the original value of the Divisor Latch Fraction (DLF) register. > > > When the DLF register is modified without preservation, it can disrupt > > > the baudrate settings established by firmware or bootloader, leading to > > > data corruption and the generation of unreadable or distorted characters. > > > > You forgot to add my tag. Why? Do you think the name of variable warrants this? > > Whatever, > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > > > Next time if you don't pick up somebody's tag, care to explain in the changelog > > why. > > > > > Fixes: 701c5e73b296 ("serial: 8250_dw: add fractional divisor support") > > > Signed-off-by: Ruihong Luo <colorsu1922@gmail.com> > > I'm sorry, I didn't know about this rule. Thank you for helping me add > the missing tags back and for all your previous kind assistance. For now no need to do anything, just wait for Ilpo's and/or Greg's answer(s), -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2023-06-27 11:10 Alvaro a-m 2023-06-27 11:15 ` Michael Kjörling 0 siblings, 1 reply; 1767+ messages in thread From: Alvaro a-m @ 2023-06-27 11:10 UTC (permalink / raw) To: cryptsetup HI everyone, My name is Álvaro. I'm texting you this email about LUKS. I have a USB with 3 partitions (/efi, /boot and /data with LVMs encrypted by LUKS). I have a problem entering the password as I don't have a keyboard and I need to enter the password with a touch screen. I tried to search for information about that but nothing was successful. Do you know any solution for this? Can I enable the touch screen before LUKS gets up? Thank you, have a nice day. Kind regards, Álvaro ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2023-06-27 11:10 Alvaro a-m @ 2023-06-27 11:15 ` Michael Kjörling 0 siblings, 0 replies; 1767+ messages in thread From: Michael Kjörling @ 2023-06-27 11:15 UTC (permalink / raw) To: cryptsetup On 27 Jun 2023 13:10 +0200, from alvaroam007@gmail.com (Alvaro a-m): > Do you know any solution for this? Can I enable the touch screen > before LUKS gets up? That is a distribution issue; not a LUKS, dm-crypt or cryptsetup issue. You should ask your question in a forum more geared toward whatever distribution you are using. I do hope that you will be able to find an answer, but the cryptsetup mailing list is the wrong forum for your question. -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <010d01d999f4$257ae020$7070a060$@mirroredgenetworks.com>]
[parent not found: <CAEhhANphwWt5iOMc5Yqp1tT1HGoG_GsCuUWBWeVX4zxL6JwUiw@mail.gmail.com>]
[parent not found: <CAEhhANom-MGPCqEk5LXufMkxvnoY0YRUrr0r07s0_7F=eCQH5Q@mail.gmail.com>]
* Re: [not found] ` <CAEhhANom-MGPCqEk5LXufMkxvnoY0YRUrr0r07s0_7F=eCQH5Q@mail.gmail.com> @ 2023-06-08 10:51 ` Daniel Little 0 siblings, 0 replies; 1767+ messages in thread From: Daniel Little @ 2023-06-08 10:51 UTC (permalink / raw) To: linux-btrfs, support [-- Attachment #1: Type: text/plain, Size: 2581 bytes --] >> >> Good Day, >> >> I’m sorry to message the developers this way. Im sure this is not the purpose of being able to contact developers, but I am pretty desperate here. >> >> I’m desperately seeking some "hands-on" assistance with my broken Rocstor setup. I have a lot of photos and videos on my drives that I cannot reproduce and would really like to retrieve. >> >> With my limited knowledge and skill I have tried as best I can to follow the suggestions made by Philip on my forum post (Disk Pool mounted, shared missing. many errors - #2 by phillxnet), but I’m no closer to success than when I started. Im sure its because Im not doing things right. If someone smarter than me is willing to offer their precious time to assist I am happy to set up remote access to the system for them to work/diagnose/troubleshoot directly. I will fit into your schedule whenever and whatever that may be. I’m willing to put on the dunce hat and be tarred and feathered and publicly mocked, so long as some kind souls help me to recover the data. >> >> I eagerly await and appreciate any assistance offered. I respectfully understand too if this is not something anyone wants to take on. >> >> SITREP: >> >> Rockstor 4.1.0-0 installed on a ESXI vm. Tried to get vmware-tools installed. followed a guide blindly. vm rebooted, all hell broke loose. >> >> “Parent transid verify failed… wanted 32616 found 32441” >> Pool remounts automatically as read-only. >> >> OUTPUTS: >> >> >> >> uname -a >> >> Linux RocStor 5.3.18-150300.59.106-default #1 SMP Mon Dec 12 13:16:24 UTC 2022 (774239c) x86_64 x86_64 x86_64 GNU/Linux >> >> >> >> btrfs --version >> >> btrfs-progs v4.19.1 >> >> >> >> btrfs fi show >> >> Label: ‘ROOT’ uuid: 4ac1b0f-afeb-4946-aad1-975a2a26c941 >> >> Total devices 1 FS bytes used 4.65GiB >> >> Devid 1 size 47.93GiB used 5.80GiB path /dev/sda4 >> >> >> >> Label: ‘DATA’ uuid: 8d3ee597-bddc-4de8-8fc0-23fde00e27f1 >> >> Total devices 1FS bytes used 768.00KiB >> >> Devid 1 size 16.37TiB used 11.72TiB path /dev/sdb >> >> >> >> Inside DATA there are only two folders. DATASTORE and SyncThing. All the required data is in DATASTORE. >> >> >> >> Btrfs fi df /home >> >> Data, single: total=5.54GiB, used=4.55GiB >> >> System, single: total=32.00MiB, used=16.ooKiB >> >> Metadata, single:=232.00MiB, used=110.05MiB >> >> GlobalReserve, single: total=11.55MiB, used=0.00B [-- Attachment #2: requested_logs.tgz --] [-- Type: application/x-compressed, Size: 27311 bytes --] ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <CAKEZqKKdQ9EhRobSmq0sV76arfpk6m5XqA-=XQP_M3VRG=M-eg@mail.gmail.com>]
* Re: [not found] <CAKEZqKKdQ9EhRobSmq0sV76arfpk6m5XqA-=XQP_M3VRG=M-eg@mail.gmail.com> @ 2023-06-08 8:13 ` chenlei0x 0 siblings, 0 replies; 1767+ messages in thread From: chenlei0x @ 2023-06-08 8:13 UTC (permalink / raw) To: linux-xfs unsubscribe linux-xfs On Thu, Jun 8, 2023 at 4:11 PM chenlei0x <losemyheaven@gmail.com> wrote: > > unsubscribe ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE; @ 2023-05-30 2:46 Olena Shevchenko 0 siblings, 0 replies; 1767+ messages in thread From: Olena Shevchenko @ 2023-05-30 2:46 UTC (permalink / raw) To: sparclinux Hello, I have funds for investment. Can we partner if you have a good business idea? Thank you Mrs. Olena ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE; @ 2023-05-30 1:31 Olena Shevchenko 0 siblings, 0 replies; 1767+ messages in thread From: Olena Shevchenko @ 2023-05-30 1:31 UTC (permalink / raw) To: soc Hello, I have funds for investment. Can we partner if you have a good business idea? Thank you Mrs. Olena ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2023-05-11 12:58 Ryan Roberts
2023-05-11 13:13 ` Ryan Roberts
0 siblings, 1 reply; 1767+ messages in thread
From: Ryan Roberts @ 2023-05-11 12:58 UTC (permalink / raw)
To: Andrew Morton, Matthew Wilcox (Oracle), Kirill A. Shutemov,
SeongJae Park
Cc: Ryan Roberts, linux-kernel, linux-mm, damon
Date: Thu, 11 May 2023 11:38:28 +0100
Subject: [PATCH v1 0/5] Encapsulate PTE contents from non-arch code
Hi All,
This series improves the encapsulation of pte entries by disallowing non-arch
code from directly dereferencing pte_t pointers. Instead code must use a new
helper, `pte_t ptep_deref(pte_t *ptep)`. By default, this helper does a direct
dereference of the pointer, so generated code should be exactly the same. But
it's presence sets us up for arch code being able to override the default to
"virtualize" the ptes without needing to maintain a shadow table.
I intend to take advantage of this for arm64 to enable use of its "contiguous
bit" to coalesce multiple ptes into a single tlb entry, reducing pressure and
improving performance. I have an RFC for the first part of this work at [1]. The
cover letter there also explains the second part, which this series is enabling.
I intend to post an RFC for the contpte changes in due course, but it would be
good to get the ball rolling on this enabler.
There are 2 reasons that I need the encapsulation:
- Prevent leaking the arch-private PTE_CONT bit to the core code. If the core
code reads a pte that contains this bit, it could end up calling
set_pte_at() with the bit set which would confuse the implementation. So we
can always clear PTE_CONT in ptep_deref() (and ptep_get()) to avoid a leaky
abstraction.
- Contiguous ptes have a single access and dirty bit for the contiguous range.
So we need to "mix-in" those bits when the core is dereferencing a pte that
lies in the contig range. There is code that dereferences the pte then takes
different actions based on access/dirty (see e.g. write_protect_page()).
While ptep_get() and ptep_get_lockless() already exist, both of them are
implemented using READ_ONCE() by default. While we could use ptep_get() instead
of the new ptep_deref(), I didn't want to risk performance regression.
Alternatively, all call sites that currently use ptep_get() that need the
lockless behaviour could be upgraded to ptep_get_lockless() and ptep_get() could
be downgraded to a simple dereference. That would be cleanest, but is a much
bigger (and likely error prone) change because all the arch code would need to
be updated for the new definitions of ptep_get().
The series is split up as follows:
patchs 1-2: Fix bugs where code was _setting_ ptes directly, rather than using
set_pte_at() and friends.
patch 3: Fix highmem unmapping issue I spotted while doing the work.
patch 4: Introduce the new ptep_deref() helper with default implementation.
patch 5: Convert all direct dereferences to use ptep_deref().
[1] https://lore.kernel.org/linux-mm/20230414130303.2345383-1-ryan.roberts@arm.com/
Thanks,
Ryan
Ryan Roberts (5):
mm: vmalloc must set pte via arch code
mm: damon must atomically clear young on ptes and pmds
mm: Fix failure to unmap pte on highmem systems
mm: Add new ptep_deref() helper to fully encapsulate pte_t
mm: ptep_deref() conversion
.../drm/i915/gem/selftests/i915_gem_mman.c | 8 +-
drivers/misc/sgi-gru/grufault.c | 2 +-
drivers/vfio/vfio_iommu_type1.c | 7 +-
drivers/xen/privcmd.c | 2 +-
fs/proc/task_mmu.c | 33 +++---
fs/userfaultfd.c | 6 +-
include/linux/hugetlb.h | 2 +-
include/linux/mm_inline.h | 2 +-
include/linux/pgtable.h | 13 ++-
kernel/events/uprobes.c | 2 +-
mm/damon/ops-common.c | 18 ++-
mm/damon/ops-common.h | 4 +-
mm/damon/paddr.c | 6 +-
mm/damon/vaddr.c | 14 ++-
mm/filemap.c | 2 +-
mm/gup.c | 21 ++--
mm/highmem.c | 12 +-
mm/hmm.c | 2 +-
mm/huge_memory.c | 4 +-
mm/hugetlb.c | 2 +-
mm/hugetlb_vmemmap.c | 6 +-
mm/kasan/init.c | 9 +-
mm/kasan/shadow.c | 10 +-
mm/khugepaged.c | 24 ++--
mm/ksm.c | 22 ++--
mm/madvise.c | 6 +-
mm/mapping_dirty_helpers.c | 4 +-
mm/memcontrol.c | 4 +-
mm/memory-failure.c | 6 +-
mm/memory.c | 103 +++++++++---------
mm/mempolicy.c | 6 +-
mm/migrate.c | 14 ++-
mm/migrate_device.c | 14 ++-
mm/mincore.c | 2 +-
mm/mlock.c | 6 +-
mm/mprotect.c | 8 +-
mm/mremap.c | 2 +-
mm/page_table_check.c | 4 +-
mm/page_vma_mapped.c | 26 +++--
mm/pgtable-generic.c | 2 +-
mm/rmap.c | 32 +++---
mm/sparse-vmemmap.c | 8 +-
mm/swap_state.c | 4 +-
mm/swapfile.c | 16 +--
mm/userfaultfd.c | 4 +-
mm/vmalloc.c | 11 +-
mm/vmscan.c | 14 ++-
virt/kvm/kvm_main.c | 9 +-
48 files changed, 302 insertions(+), 236 deletions(-)
--
2.25.1
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2023-05-11 12:58 Ryan Roberts @ 2023-05-11 13:13 ` Ryan Roberts 0 siblings, 0 replies; 1767+ messages in thread From: Ryan Roberts @ 2023-05-11 13:13 UTC (permalink / raw) To: Andrew Morton, Matthew Wilcox (Oracle), Kirill A. Shutemov, SeongJae Park Cc: linux-kernel, linux-mm, damon My appologies for the noise: A blank line between Cc and Subject has broken the subject and grouping in lore. Please Ignore this, I will resend. On 11/05/2023 13:58, Ryan Roberts wrote: > Date: Thu, 11 May 2023 11:38:28 +0100 > Subject: [PATCH v1 0/5] Encapsulate PTE contents from non-arch code > > Hi All, > > This series improves the encapsulation of pte entries by disallowing non-arch > code from directly dereferencing pte_t pointers. Instead code must use a new > helper, `pte_t ptep_deref(pte_t *ptep)`. By default, this helper does a direct > dereference of the pointer, so generated code should be exactly the same. But > it's presence sets us up for arch code being able to override the default to > "virtualize" the ptes without needing to maintain a shadow table. > > I intend to take advantage of this for arm64 to enable use of its "contiguous > bit" to coalesce multiple ptes into a single tlb entry, reducing pressure and > improving performance. I have an RFC for the first part of this work at [1]. The > cover letter there also explains the second part, which this series is enabling. > > I intend to post an RFC for the contpte changes in due course, but it would be > good to get the ball rolling on this enabler. > > There are 2 reasons that I need the encapsulation: > > - Prevent leaking the arch-private PTE_CONT bit to the core code. If the core > code reads a pte that contains this bit, it could end up calling > set_pte_at() with the bit set which would confuse the implementation. So we > can always clear PTE_CONT in ptep_deref() (and ptep_get()) to avoid a leaky > abstraction. > - Contiguous ptes have a single access and dirty bit for the contiguous range. > So we need to "mix-in" those bits when the core is dereferencing a pte that > lies in the contig range. There is code that dereferences the pte then takes > different actions based on access/dirty (see e.g. write_protect_page()). > > While ptep_get() and ptep_get_lockless() already exist, both of them are > implemented using READ_ONCE() by default. While we could use ptep_get() instead > of the new ptep_deref(), I didn't want to risk performance regression. > Alternatively, all call sites that currently use ptep_get() that need the > lockless behaviour could be upgraded to ptep_get_lockless() and ptep_get() could > be downgraded to a simple dereference. That would be cleanest, but is a much > bigger (and likely error prone) change because all the arch code would need to > be updated for the new definitions of ptep_get(). > > The series is split up as follows: > > patchs 1-2: Fix bugs where code was _setting_ ptes directly, rather than using > set_pte_at() and friends. > patch 3: Fix highmem unmapping issue I spotted while doing the work. > patch 4: Introduce the new ptep_deref() helper with default implementation. > patch 5: Convert all direct dereferences to use ptep_deref(). > > [1] https://lore.kernel.org/linux-mm/20230414130303.2345383-1-ryan.roberts@arm.com/ > > Thanks, > Ryan > > > Ryan Roberts (5): > mm: vmalloc must set pte via arch code > mm: damon must atomically clear young on ptes and pmds > mm: Fix failure to unmap pte on highmem systems > mm: Add new ptep_deref() helper to fully encapsulate pte_t > mm: ptep_deref() conversion > > .../drm/i915/gem/selftests/i915_gem_mman.c | 8 +- > drivers/misc/sgi-gru/grufault.c | 2 +- > drivers/vfio/vfio_iommu_type1.c | 7 +- > drivers/xen/privcmd.c | 2 +- > fs/proc/task_mmu.c | 33 +++--- > fs/userfaultfd.c | 6 +- > include/linux/hugetlb.h | 2 +- > include/linux/mm_inline.h | 2 +- > include/linux/pgtable.h | 13 ++- > kernel/events/uprobes.c | 2 +- > mm/damon/ops-common.c | 18 ++- > mm/damon/ops-common.h | 4 +- > mm/damon/paddr.c | 6 +- > mm/damon/vaddr.c | 14 ++- > mm/filemap.c | 2 +- > mm/gup.c | 21 ++-- > mm/highmem.c | 12 +- > mm/hmm.c | 2 +- > mm/huge_memory.c | 4 +- > mm/hugetlb.c | 2 +- > mm/hugetlb_vmemmap.c | 6 +- > mm/kasan/init.c | 9 +- > mm/kasan/shadow.c | 10 +- > mm/khugepaged.c | 24 ++-- > mm/ksm.c | 22 ++-- > mm/madvise.c | 6 +- > mm/mapping_dirty_helpers.c | 4 +- > mm/memcontrol.c | 4 +- > mm/memory-failure.c | 6 +- > mm/memory.c | 103 +++++++++--------- > mm/mempolicy.c | 6 +- > mm/migrate.c | 14 ++- > mm/migrate_device.c | 14 ++- > mm/mincore.c | 2 +- > mm/mlock.c | 6 +- > mm/mprotect.c | 8 +- > mm/mremap.c | 2 +- > mm/page_table_check.c | 4 +- > mm/page_vma_mapped.c | 26 +++-- > mm/pgtable-generic.c | 2 +- > mm/rmap.c | 32 +++--- > mm/sparse-vmemmap.c | 8 +- > mm/swap_state.c | 4 +- > mm/swapfile.c | 16 +-- > mm/userfaultfd.c | 4 +- > mm/vmalloc.c | 11 +- > mm/vmscan.c | 14 ++- > virt/kvm/kvm_main.c | 9 +- > 48 files changed, 302 insertions(+), 236 deletions(-) > > -- > 2.25.1 > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH v2] uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS583Gen 2
@ 2023-03-12 6:52 Greg Kroah-Hartman
2023-03-27 13:54 ` Yaroslav Furman
0 siblings, 1 reply; 1767+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-12 6:52 UTC (permalink / raw)
To: Yaroslav Furman; +Cc: Alan Stern, linux-usb, usb-storage, linux-kernel
On Sat, Mar 11, 2023 at 07:12:26PM +0200, Yaroslav Furman wrote:
> Just like other JMicron JMS5xx enclosures, it chokes on report-opcodes,
> let's avoid them.
>
> Signed-off-by: Yaroslav Furman <yaro330@gmail.com>
> ---
> drivers/usb/storage/unusual_uas.h | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/usb/storage/unusual_uas.h b/drivers/usb/storage/unusual_uas.h
> index c7b763d6d102..1f8c9b16a0fb 100644
> --- a/drivers/usb/storage/unusual_uas.h
> +++ b/drivers/usb/storage/unusual_uas.h
> @@ -111,6 +111,13 @@ UNUSUAL_DEV(0x152d, 0x0578, 0x0000, 0x9999,
> USB_SC_DEVICE, USB_PR_DEVICE, NULL,
> US_FL_BROKEN_FUA),
>
> +/* Reported by: Yaroslav Furman <yaro330@gmail.com> */
> +UNUSUAL_DEV(0x152d, 0x0583, 0x0000, 0x9999,
> + "JMicron",
> + "JMS583Gen 2",
> + USB_SC_DEVICE, USB_PR_DEVICE, NULL,
> + US_FL_NO_REPORT_OPCODES),
> +
> /* Reported-by: Thinh Nguyen <thinhn@synopsys.com> */
> UNUSUAL_DEV(0x154b, 0xf00b, 0x0000, 0x9999,
> "PNY",
> --
> 2.39.2
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- This looks like a new version of a previously submitted patch, but you
did not list below the --- line any changes from the previous version.
Please read the section entitled "The canonical patch format" in the
kernel file, Documentation/process/submitting-patches.rst for what
needs to be done here to properly describe this.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
^ permalink raw reply [flat|nested] 1767+ messages in thread* (no subject) 2023-03-12 6:52 [PATCH v2] uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS583Gen 2 Greg Kroah-Hartman @ 2023-03-27 13:54 ` Yaroslav Furman 2023-03-27 14:19 ` Greg Kroah-Hartman 0 siblings, 1 reply; 1767+ messages in thread From: Yaroslav Furman @ 2023-03-27 13:54 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: yaro330, Alan Stern, linux-usb, usb-storage, linux-kernel Will this patch get ported to LTS trees? It applies cleanly. Would love to see it in 6.1 and 5.15 trees. 6.1 is what my steam deck is going to start using soon-ish. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2023-03-27 13:54 ` Yaroslav Furman @ 2023-03-27 14:19 ` Greg Kroah-Hartman 0 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2023-03-27 14:19 UTC (permalink / raw) To: Yaroslav Furman; +Cc: Alan Stern, linux-usb, usb-storage, linux-kernel On Mon, Mar 27, 2023 at 04:54:22PM +0300, Yaroslav Furman wrote: > > Will this patch get ported to LTS trees? It applies cleanly. > Would love to see it in 6.1 and 5.15 trees. What patch? confused, greg k-h ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2023-02-28 6:32 Mahmut Akten 0 siblings, 0 replies; 1767+ messages in thread From: Mahmut Akten @ 2023-02-28 6:32 UTC (permalink / raw) To: stable Hello I need your urgent response to a transaction request attached to your name/email stable@vger.kernel.org I would like to discuss with you now. Thank You Mahmut Akten Vice Chairman Garanti BBVA Bank (Turkey) www.garantibbva.com.tr ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <20230122193117.GA28689@Debian-50-lenny-64-minimal>]
* Re: [not found] <20230122193117.GA28689@Debian-50-lenny-64-minimal> @ 2023-01-22 21:42 ` Alejandro Colomar 2023-01-24 20:01 ` Re: Helge Kreutzmann 0 siblings, 1 reply; 1767+ messages in thread From: Alejandro Colomar @ 2023-01-22 21:42 UTC (permalink / raw) To: Helge Kreutzmann; +Cc: mario.blaettermann, linux-man [-- Attachment #1.1: Type: text/plain, Size: 205 bytes --] Hi Helge, On 1/22/23 20:31, Helge Kreutzmann wrote: > Without further ado, the following was found: Empty report. An accident? :) Cheers, Alex > -- <http://www.alejandro-colomar.es/> [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2023-01-22 21:42 ` Re: Alejandro Colomar @ 2023-01-24 20:01 ` Helge Kreutzmann 0 siblings, 0 replies; 1767+ messages in thread From: Helge Kreutzmann @ 2023-01-24 20:01 UTC (permalink / raw) To: Alejandro Colomar; +Cc: mario.blaettermann, linux-man [-- Attachment #1: Type: text/plain, Size: 661 bytes --] Helo Alex, On Sun, Jan 22, 2023 at 10:42:54PM +0100, Alejandro Colomar wrote: > Hi Helge, > > On 1/22/23 20:31, Helge Kreutzmann wrote: > > Without further ado, the following was found: > > Empty report. An accident? :) I tried to figure out what happend - but I don't know. Sorry for the empty report, please disregard. Greetings Helge -- Dr. Helge Kreutzmann debian@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH v5 0/5] CXL Poison List Retrieval & Tracing @ 2023-01-18 20:59 alison.schofield 2023-01-27 1:59 ` Dan Williams 0 siblings, 1 reply; 1767+ messages in thread From: alison.schofield @ 2023-01-18 20:59 UTC (permalink / raw) To: Dan Williams, Ira Weiny, Vishal Verma, Dave Jiang, Ben Widawsky, Steven Rostedt Cc: Alison Schofield, linux-cxl, linux-kernel From: Alison Schofield <alison.schofield@intel.com> **RESENDING this cover letter previously mis-threaded. Changes in v5: - Rebase on cxl/next - Use struct_size() to calc mbox cmd payload .min_out - s/INTERNAL/INJECTED mocked poison record source - Added Jonathan Reviewed-by tag on Patch 3 Link to v4: https://lore.kernel.org/linux-cxl/cover.1671135967.git.alison.schofield@intel.com/ Add support for retrieving device poison lists and store the returned error records as kernel trace events. The handling of the poison list is guided by the CXL 3.0 Specification Section 8.2.9.8.4.1. [1] Example, triggered by memdev: $ echo 1 > /sys/bus/cxl/devices/mem3/trigger_poison_list cxl_poison: memdev=mem3 pcidev=cxl_mem.3 region= region_uuid=00000000-0000-0000-0000-000000000000 dpa=0x0 length=0x40 source=Internal flags= overflow_time=0 Example, triggered by region: $ echo 1 > /sys/bus/cxl/devices/region5/trigger_poison_list cxl_poison: memdev=mem0 pcidev=cxl_mem.0 region=region5 region_uuid=bfcb7a29-890e-4a41-8236-fe22221fc75c dpa=0x0 length=0x40 source=Internal flags= overflow_time=0 cxl_poison: memdev=mem1 pcidev=cxl_mem.1 region=region5 region_uuid=bfcb7a29-890e-4a41-8236-fe22221fc75c dpa=0x0 length=0x40 source=Internal flags= overflow_time=0 [1]: https://www.computeexpresslink.org/download-the-specification Alison Schofield (5): cxl/mbox: Add GET_POISON_LIST mailbox command cxl/trace: Add TRACE support for CXL media-error records cxl/memdev: Add trigger_poison_list sysfs attribute cxl/region: Add trigger_poison_list sysfs attribute tools/testing/cxl: Mock support for Get Poison List Documentation/ABI/testing/sysfs-bus-cxl | 28 +++++++++ drivers/cxl/core/mbox.c | 78 +++++++++++++++++++++++ drivers/cxl/core/memdev.c | 45 ++++++++++++++ drivers/cxl/core/region.c | 33 ++++++++++ drivers/cxl/core/trace.h | 83 +++++++++++++++++++++++++ drivers/cxl/cxlmem.h | 69 +++++++++++++++++++- drivers/cxl/pci.c | 4 ++ tools/testing/cxl/test/mem.c | 42 +++++++++++++ 8 files changed, 381 insertions(+), 1 deletion(-) base-commit: 589c3357370a596ef7c99c00baca8ac799fce531 -- 2.37.3 ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) 2023-01-18 20:59 [PATCH v5 0/5] CXL Poison List Retrieval & Tracing alison.schofield @ 2023-01-27 1:59 ` Dan Williams 2023-01-27 16:10 ` Alison Schofield 0 siblings, 1 reply; 1767+ messages in thread From: Dan Williams @ 2023-01-27 1:59 UTC (permalink / raw) To: alison.schofield, Dan Williams, Ira Weiny, Vishal Verma, Dave Jiang, Ben Widawsky, Steven Rostedt Cc: Alison Schofield, linux-cxl, linux-kernel alison.schofield@ wrote: > From: Alison Schofield <alison.schofield@intel.com> > > Subject: [PATCH v5 0/5] CXL Poison List Retrieval & Tracing > > Changes in v5: > - Rebase on cxl/next > - Use struct_size() to calc mbox cmd payload .min_out > - s/INTERNAL/INJECTED mocked poison record source > - Added Jonathan Reviewed-by tag on Patch 3 > > Link to v4: > https://lore.kernel.org/linux-cxl/cover.1671135967.git.alison.schofield@intel.com/ > > Add support for retrieving device poison lists and store the returned > error records as kernel trace events. > > The handling of the poison list is guided by the CXL 3.0 Specification > Section 8.2.9.8.4.1. [1] > > Example, triggered by memdev: > $ echo 1 > /sys/bus/cxl/devices/mem3/trigger_poison_list > cxl_poison: memdev=mem3 pcidev=cxl_mem.3 region= region_uuid=00000000-0000-0000-0000-000000000000 dpa=0x0 length=0x40 source=Internal flags= overflow_time=0 I think the pcidev= field wants to be called something like "host" or "parent", because there is no strict requirement that a 'struct cxl_memdev' is related to a 'struct pci_dev'. In fact in that example "cxl_mem.3" is a 'struct platform_device'. Now that I think about it, I think all CXL device events should be emitting the PCIe serial number for the memdev. I will look in the implementation, but do region= and region_uuid= get populated when mem3 is a member of the region? > > Example, triggered by region: > $ echo 1 > /sys/bus/cxl/devices/region5/trigger_poison_list > cxl_poison: memdev=mem0 pcidev=cxl_mem.0 region=region5 region_uuid=bfcb7a29-890e-4a41-8236-fe22221fc75c dpa=0x0 length=0x40 source=Internal flags= overflow_time=0 > cxl_poison: memdev=mem1 pcidev=cxl_mem.1 region=region5 region_uuid=bfcb7a29-890e-4a41-8236-fe22221fc75c dpa=0x0 length=0x40 source=Internal flags= overflow_time=0 > > [1]: https://www.computeexpresslink.org/download-the-specification > > Alison Schofield (5): > cxl/mbox: Add GET_POISON_LIST mailbox command > cxl/trace: Add TRACE support for CXL media-error records > cxl/memdev: Add trigger_poison_list sysfs attribute > cxl/region: Add trigger_poison_list sysfs attribute > tools/testing/cxl: Mock support for Get Poison List > > Documentation/ABI/testing/sysfs-bus-cxl | 28 +++++++++ > drivers/cxl/core/mbox.c | 78 +++++++++++++++++++++++ > drivers/cxl/core/memdev.c | 45 ++++++++++++++ > drivers/cxl/core/region.c | 33 ++++++++++ > drivers/cxl/core/trace.h | 83 +++++++++++++++++++++++++ > drivers/cxl/cxlmem.h | 69 +++++++++++++++++++- > drivers/cxl/pci.c | 4 ++ > tools/testing/cxl/test/mem.c | 42 +++++++++++++ > 8 files changed, 381 insertions(+), 1 deletion(-) > > > base-commit: 589c3357370a596ef7c99c00baca8ac799fce531 > -- > 2.37.3 > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2023-01-27 1:59 ` Dan Williams @ 2023-01-27 16:10 ` Alison Schofield 2023-01-27 19:16 ` Re: Dan Williams 0 siblings, 1 reply; 1767+ messages in thread From: Alison Schofield @ 2023-01-27 16:10 UTC (permalink / raw) To: Dan Williams Cc: Ira Weiny, Vishal Verma, Dave Jiang, Ben Widawsky, Steven Rostedt, linux-cxl, linux-kernel On Thu, Jan 26, 2023 at 05:59:03PM -0800, Dan Williams wrote: > alison.schofield@ wrote: > > From: Alison Schofield <alison.schofield@intel.com> > > > > Subject: [PATCH v5 0/5] CXL Poison List Retrieval & Tracing > > > > Changes in v5: > > - Rebase on cxl/next > > - Use struct_size() to calc mbox cmd payload .min_out > > - s/INTERNAL/INJECTED mocked poison record source > > - Added Jonathan Reviewed-by tag on Patch 3 > > > > Link to v4: > > https://lore.kernel.org/linux-cxl/cover.1671135967.git.alison.schofield@intel.com/ > > > > Add support for retrieving device poison lists and store the returned > > error records as kernel trace events. > > > > The handling of the poison list is guided by the CXL 3.0 Specification > > Section 8.2.9.8.4.1. [1] > > > > Example, triggered by memdev: > > $ echo 1 > /sys/bus/cxl/devices/mem3/trigger_poison_list > > cxl_poison: memdev=mem3 pcidev=cxl_mem.3 region= region_uuid=00000000-0000-0000-0000-000000000000 dpa=0x0 length=0x40 source=Internal flags= overflow_time=0 > > I think the pcidev= field wants to be called something like "host" or > "parent", because there is no strict requirement that a 'struct > cxl_memdev' is related to a 'struct pci_dev'. In fact in that example > "cxl_mem.3" is a 'struct platform_device'. Now that I think about it, I > think all CXL device events should be emitting the PCIe serial number > for the memdev. ] Will do, 'host' and add PCIe serial no. > > I will look in the implementation, but do region= and region_uuid= get > populated when mem3 is a member of the region? Not always. In the case above, where the trigger was by memdev, no. Region= and region_uuid= (and in the follow-on patch, hpa=) only get populated if the poison was triggered by region, like the case below. It could be looked up for the by memdev cases. Is that wanted? Thanks for the reviews Dan! > > > > > Example, triggered by region: > > $ echo 1 > /sys/bus/cxl/devices/region5/trigger_poison_list > > cxl_poison: memdev=mem0 pcidev=cxl_mem.0 region=region5 region_uuid=bfcb7a29-890e-4a41-8236-fe22221fc75c dpa=0x0 length=0x40 source=Internal flags= overflow_time=0 > > cxl_poison: memdev=mem1 pcidev=cxl_mem.1 region=region5 region_uuid=bfcb7a29-890e-4a41-8236-fe22221fc75c dpa=0x0 length=0x40 source=Internal flags= overflow_time=0 > > > > [1]: https://www.computeexpresslink.org/download-the-specification > > > > Alison Schofield (5): > > cxl/mbox: Add GET_POISON_LIST mailbox command > > cxl/trace: Add TRACE support for CXL media-error records > > cxl/memdev: Add trigger_poison_list sysfs attribute > > cxl/region: Add trigger_poison_list sysfs attribute > > tools/testing/cxl: Mock support for Get Poison List > > > > Documentation/ABI/testing/sysfs-bus-cxl | 28 +++++++++ > > drivers/cxl/core/mbox.c | 78 +++++++++++++++++++++++ > > drivers/cxl/core/memdev.c | 45 ++++++++++++++ > > drivers/cxl/core/region.c | 33 ++++++++++ > > drivers/cxl/core/trace.h | 83 +++++++++++++++++++++++++ > > drivers/cxl/cxlmem.h | 69 +++++++++++++++++++- > > drivers/cxl/pci.c | 4 ++ > > tools/testing/cxl/test/mem.c | 42 +++++++++++++ > > 8 files changed, 381 insertions(+), 1 deletion(-) > > > > > > base-commit: 589c3357370a596ef7c99c00baca8ac799fce531 > > -- > > 2.37.3 > > > > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2023-01-27 16:10 ` Alison Schofield @ 2023-01-27 19:16 ` Dan Williams 2023-01-27 21:36 ` Re: Alison Schofield 0 siblings, 1 reply; 1767+ messages in thread From: Dan Williams @ 2023-01-27 19:16 UTC (permalink / raw) To: Alison Schofield, Dan Williams Cc: Ira Weiny, Vishal Verma, Dave Jiang, Ben Widawsky, Steven Rostedt, linux-cxl, linux-kernel Alison Schofield wrote: > On Thu, Jan 26, 2023 at 05:59:03PM -0800, Dan Williams wrote: > > alison.schofield@ wrote: > > > From: Alison Schofield <alison.schofield@intel.com> > > > > > > Subject: [PATCH v5 0/5] CXL Poison List Retrieval & Tracing > > > > > > Changes in v5: > > > - Rebase on cxl/next > > > - Use struct_size() to calc mbox cmd payload .min_out > > > - s/INTERNAL/INJECTED mocked poison record source > > > - Added Jonathan Reviewed-by tag on Patch 3 > > > > > > Link to v4: > > > https://lore.kernel.org/linux-cxl/cover.1671135967.git.alison.schofield@intel.com/ > > > > > > Add support for retrieving device poison lists and store the returned > > > error records as kernel trace events. > > > > > > The handling of the poison list is guided by the CXL 3.0 Specification > > > Section 8.2.9.8.4.1. [1] > > > > > > Example, triggered by memdev: > > > $ echo 1 > /sys/bus/cxl/devices/mem3/trigger_poison_list > > > cxl_poison: memdev=mem3 pcidev=cxl_mem.3 region= region_uuid=00000000-0000-0000-0000-000000000000 dpa=0x0 length=0x40 source=Internal flags= overflow_time=0 > > > > I think the pcidev= field wants to be called something like "host" or > > "parent", because there is no strict requirement that a 'struct > > cxl_memdev' is related to a 'struct pci_dev'. In fact in that example > > "cxl_mem.3" is a 'struct platform_device'. Now that I think about it, I > > think all CXL device events should be emitting the PCIe serial number > > for the memdev. > ] > > Will do, 'host' and add PCIe serial no. > > > > > I will look in the implementation, but do region= and region_uuid= get > > populated when mem3 is a member of the region? > > Not always. > In the case above, where the trigger was by memdev, no. > Region= and region_uuid= (and in the follow-on patch, hpa=) only get > populated if the poison was triggered by region, like the case below. > > It could be looked up for the by memdev cases. Is that wanted? Just trying to understand the semantics. However, I do think it makes sense for a memdev trigger to lookup information on all impacted regions across all of the device's DPA and the region trigger makes sense to lookup all memdevs, but bounded by the DPA that contributes to that region. I just want to avoid someone having to trigger the region to get extra information that was readily available from a memdev listing. > > Thanks for the reviews Dan! > > > > > > > > Example, triggered by region: > > > $ echo 1 > /sys/bus/cxl/devices/region5/trigger_poison_list > > > cxl_poison: memdev=mem0 pcidev=cxl_mem.0 region=region5 region_uuid=bfcb7a29-890e-4a41-8236-fe22221fc75c dpa=0x0 length=0x40 source=Internal flags= overflow_time=0 > > > cxl_poison: memdev=mem1 pcidev=cxl_mem.1 region=region5 region_uuid=bfcb7a29-890e-4a41-8236-fe22221fc75c dpa=0x0 length=0x40 source=Internal flags= overflow_time=0 > > > > > > [1]: https://www.computeexpresslink.org/download-the-specification > > > > > > Alison Schofield (5): > > > cxl/mbox: Add GET_POISON_LIST mailbox command > > > cxl/trace: Add TRACE support for CXL media-error records > > > cxl/memdev: Add trigger_poison_list sysfs attribute > > > cxl/region: Add trigger_poison_list sysfs attribute > > > tools/testing/cxl: Mock support for Get Poison List > > > > > > Documentation/ABI/testing/sysfs-bus-cxl | 28 +++++++++ > > > drivers/cxl/core/mbox.c | 78 +++++++++++++++++++++++ > > > drivers/cxl/core/memdev.c | 45 ++++++++++++++ > > > drivers/cxl/core/region.c | 33 ++++++++++ > > > drivers/cxl/core/trace.h | 83 +++++++++++++++++++++++++ > > > drivers/cxl/cxlmem.h | 69 +++++++++++++++++++- > > > drivers/cxl/pci.c | 4 ++ > > > tools/testing/cxl/test/mem.c | 42 +++++++++++++ > > > 8 files changed, 381 insertions(+), 1 deletion(-) > > > > > > > > > base-commit: 589c3357370a596ef7c99c00baca8ac799fce531 > > > -- > > > 2.37.3 > > > > > > > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2023-01-27 19:16 ` Re: Dan Williams @ 2023-01-27 21:36 ` Alison Schofield 2023-01-27 22:04 ` Re: Dan Williams 0 siblings, 1 reply; 1767+ messages in thread From: Alison Schofield @ 2023-01-27 21:36 UTC (permalink / raw) To: Dan Williams Cc: Ira Weiny, Vishal Verma, Dave Jiang, Ben Widawsky, Steven Rostedt, linux-cxl, linux-kernel On Fri, Jan 27, 2023 at 11:16:49AM -0800, Dan Williams wrote: > Alison Schofield wrote: > > On Thu, Jan 26, 2023 at 05:59:03PM -0800, Dan Williams wrote: > > > alison.schofield@ wrote: > > > > From: Alison Schofield <alison.schofield@intel.com> > > > > > > > > Subject: [PATCH v5 0/5] CXL Poison List Retrieval & Tracing > > > > > > > > Changes in v5: > > > > - Rebase on cxl/next > > > > - Use struct_size() to calc mbox cmd payload .min_out > > > > - s/INTERNAL/INJECTED mocked poison record source > > > > - Added Jonathan Reviewed-by tag on Patch 3 > > > > > > > > Link to v4: > > > > https://lore.kernel.org/linux-cxl/cover.1671135967.git.alison.schofield@intel.com/ > > > > > > > > Add support for retrieving device poison lists and store the returned > > > > error records as kernel trace events. > > > > > > > > The handling of the poison list is guided by the CXL 3.0 Specification > > > > Section 8.2.9.8.4.1. [1] > > > > > > > > Example, triggered by memdev: > > > > $ echo 1 > /sys/bus/cxl/devices/mem3/trigger_poison_list > > > > cxl_poison: memdev=mem3 pcidev=cxl_mem.3 region= region_uuid=00000000-0000-0000-0000-000000000000 dpa=0x0 length=0x40 source=Internal flags= overflow_time=0 > > > > > > I think the pcidev= field wants to be called something like "host" or > > > "parent", because there is no strict requirement that a 'struct > > > cxl_memdev' is related to a 'struct pci_dev'. In fact in that example > > > "cxl_mem.3" is a 'struct platform_device'. Now that I think about it, I > > > think all CXL device events should be emitting the PCIe serial number > > > for the memdev. > > ] > > > > Will do, 'host' and add PCIe serial no. > > > > > > > > I will look in the implementation, but do region= and region_uuid= get > > > populated when mem3 is a member of the region? > > > > Not always. > > In the case above, where the trigger was by memdev, no. > > Region= and region_uuid= (and in the follow-on patch, hpa=) only get > > populated if the poison was triggered by region, like the case below. > > > > It could be looked up for the by memdev cases. Is that wanted? > > Just trying to understand the semantics. However, I do think it makes sense > for a memdev trigger to lookup information on all impacted regions > across all of the device's DPA and the region trigger makes sense to > lookup all memdevs, but bounded by the DPA that contributes to that > region. I just want to avoid someone having to trigger the region to get > extra information that was readily available from a memdev listing. > Dan - Confirming my take-away from this email, and our chat: Remove the by-region trigger_poison_list option entirely. User space needs to trigger by-memdev the memdevs participating in the region and filter those events by region. Add the region info (region name, uuid) to the TRACE_EVENTs when the poisoned DPA is part of any region. Alison > > > > Thanks for the reviews Dan! > > > > > > > > > > > Example, triggered by region: > > > > $ echo 1 > /sys/bus/cxl/devices/region5/trigger_poison_list > > > > cxl_poison: memdev=mem0 pcidev=cxl_mem.0 region=region5 region_uuid=bfcb7a29-890e-4a41-8236-fe22221fc75c dpa=0x0 length=0x40 source=Internal flags= overflow_time=0 > > > > cxl_poison: memdev=mem1 pcidev=cxl_mem.1 region=region5 region_uuid=bfcb7a29-890e-4a41-8236-fe22221fc75c dpa=0x0 length=0x40 source=Internal flags= overflow_time=0 > > > > > > > > [1]: https://www.computeexpresslink.org/download-the-specification > > > > > > > > Alison Schofield (5): > > > > cxl/mbox: Add GET_POISON_LIST mailbox command > > > > cxl/trace: Add TRACE support for CXL media-error records > > > > cxl/memdev: Add trigger_poison_list sysfs attribute > > > > cxl/region: Add trigger_poison_list sysfs attribute > > > > tools/testing/cxl: Mock support for Get Poison List > > > > > > > > Documentation/ABI/testing/sysfs-bus-cxl | 28 +++++++++ > > > > drivers/cxl/core/mbox.c | 78 +++++++++++++++++++++++ > > > > drivers/cxl/core/memdev.c | 45 ++++++++++++++ > > > > drivers/cxl/core/region.c | 33 ++++++++++ > > > > drivers/cxl/core/trace.h | 83 +++++++++++++++++++++++++ > > > > drivers/cxl/cxlmem.h | 69 +++++++++++++++++++- > > > > drivers/cxl/pci.c | 4 ++ > > > > tools/testing/cxl/test/mem.c | 42 +++++++++++++ > > > > 8 files changed, 381 insertions(+), 1 deletion(-) > > > > > > > > > > > > base-commit: 589c3357370a596ef7c99c00baca8ac799fce531 > > > > -- > > > > 2.37.3 > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2023-01-27 21:36 ` Re: Alison Schofield @ 2023-01-27 22:04 ` Dan Williams 0 siblings, 0 replies; 1767+ messages in thread From: Dan Williams @ 2023-01-27 22:04 UTC (permalink / raw) To: Alison Schofield, Dan Williams Cc: Ira Weiny, Vishal Verma, Dave Jiang, Ben Widawsky, Steven Rostedt, linux-cxl, linux-kernel Alison Schofield wrote: > On Fri, Jan 27, 2023 at 11:16:49AM -0800, Dan Williams wrote: > > Alison Schofield wrote: > > > On Thu, Jan 26, 2023 at 05:59:03PM -0800, Dan Williams wrote: > > > > alison.schofield@ wrote: > > > > > From: Alison Schofield <alison.schofield@intel.com> > > > > > > > > > > Subject: [PATCH v5 0/5] CXL Poison List Retrieval & Tracing > > > > > > > > > > Changes in v5: > > > > > - Rebase on cxl/next > > > > > - Use struct_size() to calc mbox cmd payload .min_out > > > > > - s/INTERNAL/INJECTED mocked poison record source > > > > > - Added Jonathan Reviewed-by tag on Patch 3 > > > > > > > > > > Link to v4: > > > > > https://lore.kernel.org/linux-cxl/cover.1671135967.git.alison.schofield@intel.com/ > > > > > > > > > > Add support for retrieving device poison lists and store the returned > > > > > error records as kernel trace events. > > > > > > > > > > The handling of the poison list is guided by the CXL 3.0 Specification > > > > > Section 8.2.9.8.4.1. [1] > > > > > > > > > > Example, triggered by memdev: > > > > > $ echo 1 > /sys/bus/cxl/devices/mem3/trigger_poison_list > > > > > cxl_poison: memdev=mem3 pcidev=cxl_mem.3 region= region_uuid=00000000-0000-0000-0000-000000000000 dpa=0x0 length=0x40 source=Internal flags= overflow_time=0 > > > > > > > > I think the pcidev= field wants to be called something like "host" or > > > > "parent", because there is no strict requirement that a 'struct > > > > cxl_memdev' is related to a 'struct pci_dev'. In fact in that example > > > > "cxl_mem.3" is a 'struct platform_device'. Now that I think about it, I > > > > think all CXL device events should be emitting the PCIe serial number > > > > for the memdev. > > > ] > > > > > > Will do, 'host' and add PCIe serial no. > > > > > > > > > > > I will look in the implementation, but do region= and region_uuid= get > > > > populated when mem3 is a member of the region? > > > > > > Not always. > > > In the case above, where the trigger was by memdev, no. > > > Region= and region_uuid= (and in the follow-on patch, hpa=) only get > > > populated if the poison was triggered by region, like the case below. > > > > > > It could be looked up for the by memdev cases. Is that wanted? > > > > Just trying to understand the semantics. However, I do think it makes sense > > for a memdev trigger to lookup information on all impacted regions > > across all of the device's DPA and the region trigger makes sense to > > lookup all memdevs, but bounded by the DPA that contributes to that > > region. I just want to avoid someone having to trigger the region to get > > extra information that was readily available from a memdev listing. > > > > Dan - > > Confirming my take-away from this email, and our chat: > > Remove the by-region trigger_poison_list option entirely. User space > needs to trigger by-memdev the memdevs participating in the region and > filter those events by region. > > Add the region info (region name, uuid) to the TRACE_EVENTs when the > poisoned DPA is part of any region. That's what I was thinking, yes. So the internals of cxl_mem_get_poison() will take the cxl_region_rwsem for read and compare the device's endpoint decoder settings against the media error records to do the region (and later HPA) lookup. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2022-11-21 11:11 Denis Arefev 2022-11-21 14:28 ` Jason Yan 0 siblings, 1 reply; 1767+ messages in thread From: Denis Arefev @ 2022-11-21 11:11 UTC (permalink / raw) To: Anil Gurumurthy Cc: Sudarsana Kalluru, James E.J. Bottomley, Martin K. Petersen, linux-scsi, linux-kernel, trufanov, vfh Date: Mon, 21 Nov 2022 13:29:03 +0300 Subject: [PATCH] scsi:bfa: Eliminated buffer overflow Buffer 'cmd->adapter_hwpath' of size 32 accessed at bfad_bsg.c:101:103 can overflow, since its index 'i' can have value 32 that is out of range. Signed-off-by: Denis Arefev <arefev@swemel.ru> --- drivers/scsi/bfa/bfad_bsg.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/bfa/bfad_bsg.c b/drivers/scsi/bfa/bfad_bsg.c index be8dfbe13e90..78615ffc62ef 100644 --- a/drivers/scsi/bfa/bfad_bsg.c +++ b/drivers/scsi/bfa/bfad_bsg.c @@ -98,9 +98,9 @@ bfad_iocmd_ioc_get_info(struct bfad_s *bfad, void *cmd) /* set adapter hw path */ strcpy(iocmd->adapter_hwpath, bfad->pci_name); - for (i = 0; iocmd->adapter_hwpath[i] != ':' && i < BFA_STRING_32; i++) + for (i = 0; iocmd->adapter_hwpath[i] != ':' && i < BFA_STRING_32-2; i++) ; - for (; iocmd->adapter_hwpath[++i] != ':' && i < BFA_STRING_32; ) + for (; iocmd->adapter_hwpath[++i] != ':' && i < BFA_STRING_32-1; ) ; iocmd->adapter_hwpath[i] = '\0'; iocmd->status = BFA_STATUS_OK; -- 2.25.1 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2022-11-21 11:11 Denis Arefev @ 2022-11-21 14:28 ` Jason Yan 0 siblings, 0 replies; 1767+ messages in thread From: Jason Yan @ 2022-11-21 14:28 UTC (permalink / raw) To: Denis Arefev, Anil Gurumurthy Cc: Sudarsana Kalluru, James E.J. Bottomley, Martin K. Petersen, linux-scsi, linux-kernel, trufanov, vfh You may need a real subject, not a subject text in the email. type "git help send-email" if you don't know how to use it. On 2022/11/21 19:11, Denis Arefev wrote: > Date: Mon, 21 Nov 2022 13:29:03 +0300 > Subject: [PATCH] scsi:bfa: Eliminated buffer overflow > > Buffer 'cmd->adapter_hwpath' of size 32 accessed at > bfad_bsg.c:101:103 can overflow, since its index 'i' > can have value 32 that is out of range. > > Signed-off-by: Denis Arefev <arefev@swemel.ru> > --- > drivers/scsi/bfa/bfad_bsg.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/scsi/bfa/bfad_bsg.c b/drivers/scsi/bfa/bfad_bsg.c > index be8dfbe13e90..78615ffc62ef 100644 > --- a/drivers/scsi/bfa/bfad_bsg.c > +++ b/drivers/scsi/bfa/bfad_bsg.c > @@ -98,9 +98,9 @@ bfad_iocmd_ioc_get_info(struct bfad_s *bfad, void *cmd) > > /* set adapter hw path */ > strcpy(iocmd->adapter_hwpath, bfad->pci_name); > - for (i = 0; iocmd->adapter_hwpath[i] != ':' && i < BFA_STRING_32; i++) > + for (i = 0; iocmd->adapter_hwpath[i] != ':' && i < BFA_STRING_32-2; i++) > ; > - for (; iocmd->adapter_hwpath[++i] != ':' && i < BFA_STRING_32; ) > + for (; iocmd->adapter_hwpath[++i] != ':' && i < BFA_STRING_32-1; ) > ; > iocmd->adapter_hwpath[i] = '\0'; > iocmd->status = BFA_STATUS_OK; > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2022-11-18 19:33 Mr. JAMES 0 siblings, 0 replies; 1767+ messages in thread From: Mr. JAMES @ 2022-11-18 19:33 UTC (permalink / raw) To: git Hello, I'm James, an Entrepreneur, Venture Capitalist & Private Lender. I represent a group of Ultra High Net Worth Donors worldwide. Kindly let me know if you can be trusted to distribute charitable items which include Cash, Food Items and Clothing in your region. Thank you James. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2022-11-18 18:11 Mr. JAMES 0 siblings, 0 replies; 1767+ messages in thread From: Mr. JAMES @ 2022-11-18 18:11 UTC (permalink / raw) To: devicetree Hello, I'm James, an Entrepreneur, Venture Capitalist & Private Lender. I represent a group of Ultra High Net Worth Donors worldwide. Kindly let me know if you can be trusted to distribute charitable items which include Cash, Food Items and Clothing in your region. Thank you James. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2022-11-18 2:00 Jiamei Xie 2022-11-18 7:47 ` Michal Orzel 0 siblings, 1 reply; 1767+ messages in thread From: Jiamei Xie @ 2022-11-18 2:00 UTC (permalink / raw) To: xen-devel Cc: Jiamei Xie, Stefano Stabellini, Julien Grall, Bertrand Marquis, Volodymyr Babchuk, Wei Chen Date: Thu, 17 Nov 2022 11:07:12 +0800 Subject: [PATCH] xen/arm: vpl011: Make access to DMACR write-ignore When the guest kernel enables DMA engine with "CONFIG_DMA_ENGINE=y", Linux SBSA PL011 driver will access PL011 DMACR register in some functions. As chapter "B Generic UART" in "ARM Server Base System Architecture"[1] documentation describes, SBSA UART doesn't support DMA. In current code, when the kernel tries to access DMACR register, Xen will inject a data abort: Unhandled fault at 0xffffffc00944d048 Mem abort info: ESR = 0x96000000 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x00: ttbr address size fault Data abort info: ISV = 0, ISS = 0x00000000 CM = 0, WnR = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000020e2e000 [ffffffc00944d048] pgd=100000003ffff803, p4d=100000003ffff803, pud=100000003ffff803, pmd=100000003fffa803, pte=006800009c090f13 Internal error: ttbr address size fault: 96000000 [#1] PREEMPT SMP ... Call trace: pl011_stop_rx+0x70/0x80 tty_port_shutdown+0x7c/0xb4 tty_port_close+0x60/0xcc uart_close+0x34/0x8c tty_release+0x144/0x4c0 __fput+0x78/0x220 ____fput+0x1c/0x30 task_work_run+0x88/0xc0 do_notify_resume+0x8d0/0x123c el0_svc+0xa8/0xc0 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4 Code: b9000083 b901f001 794038a0 8b000042 (b9000041) ---[ end trace 83dd93df15c3216f ]--- note: bootlogd[132] exited with preempt_count 1 /etc/rcS.d/S07bootlogd: line 47: 132 Segmentation fault start-stop-daemon As discussed in [2], this commit makes the access to DMACR register write-ignore as an improvement. [1] https://developer.arm.com/documentation/den0094/c/?lang=en [2] https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2211161552420.4020@ubuntu-linux-20-04-desktop/ Signed-off-by: Jiamei Xie <jiamei.xie@arm.com> --- xen/arch/arm/vpl011.c | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c index 43522d48fd..80d00b3052 100644 --- a/xen/arch/arm/vpl011.c +++ b/xen/arch/arm/vpl011.c @@ -463,6 +463,7 @@ static int vpl011_mmio_write(struct vcpu *v, case FR: case RIS: case MIS: + case DMACR: goto write_ignore; case IMSC: -- 2.25.1 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2022-11-18 2:00 Jiamei Xie @ 2022-11-18 7:47 ` Michal Orzel 2022-11-18 9:02 ` Re: Julien Grall 0 siblings, 1 reply; 1767+ messages in thread From: Michal Orzel @ 2022-11-18 7:47 UTC (permalink / raw) To: Jiamei Xie, xen-devel Cc: Stefano Stabellini, Julien Grall, Bertrand Marquis, Volodymyr Babchuk, Wei Chen Hi Jimaei, On 18/11/2022 03:00, Jiamei Xie wrote: > > > Date: Thu, 17 Nov 2022 11:07:12 +0800 > Subject: [PATCH] xen/arm: vpl011: Make access to DMACR write-ignore > > When the guest kernel enables DMA engine with "CONFIG_DMA_ENGINE=y", > Linux SBSA PL011 driver will access PL011 DMACR register in some > functions. As chapter "B Generic UART" in "ARM Server Base System > Architecture"[1] documentation describes, SBSA UART doesn't support > DMA. In current code, when the kernel tries to access DMACR register, > Xen will inject a data abort: > Unhandled fault at 0xffffffc00944d048 > Mem abort info: > ESR = 0x96000000 > EC = 0x25: DABT (current EL), IL = 32 bits > SET = 0, FnV = 0 > EA = 0, S1PTW = 0 > FSC = 0x00: ttbr address size fault > Data abort info: > ISV = 0, ISS = 0x00000000 > CM = 0, WnR = 0 > swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000020e2e000 > [ffffffc00944d048] pgd=100000003ffff803, p4d=100000003ffff803, pud=100000003ffff803, pmd=100000003fffa803, pte=006800009c090f13 > Internal error: ttbr address size fault: 96000000 [#1] PREEMPT SMP > ... > Call trace: > pl011_stop_rx+0x70/0x80 > tty_port_shutdown+0x7c/0xb4 > tty_port_close+0x60/0xcc > uart_close+0x34/0x8c > tty_release+0x144/0x4c0 > __fput+0x78/0x220 > ____fput+0x1c/0x30 > task_work_run+0x88/0xc0 > do_notify_resume+0x8d0/0x123c > el0_svc+0xa8/0xc0 > el0t_64_sync_handler+0xa4/0x130 > el0t_64_sync+0x1a0/0x1a4 > Code: b9000083 b901f001 794038a0 8b000042 (b9000041) > ---[ end trace 83dd93df15c3216f ]--- > note: bootlogd[132] exited with preempt_count 1 > /etc/rcS.d/S07bootlogd: line 47: 132 Segmentation fault start-stop-daemon > > As discussed in [2], this commit makes the access to DMACR register > write-ignore as an improvement. As discussed earlier, if we decide to improve vpl011 (for now only Stefano shared his opinion), then we need to mark *all* the PL011 registers that are not part of SBSA ar RAZ/WI. So handling DMACR and only for writes is not beneficial (it is only fixing current Linux issue, but what we really want is to improve the code in general). > > [1] https://developer.arm.com/documentation/den0094/c/?lang=en > [2] https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2211161552420.4020@ubuntu-linux-20-04-desktop/ > > Signed-off-by: Jiamei Xie <jiamei.xie@arm.com> > --- > xen/arch/arm/vpl011.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c > index 43522d48fd..80d00b3052 100644 > --- a/xen/arch/arm/vpl011.c > +++ b/xen/arch/arm/vpl011.c > @@ -463,6 +463,7 @@ static int vpl011_mmio_write(struct vcpu *v, > case FR: > case RIS: > case MIS: > + case DMACR: > goto write_ignore; > > case IMSC: > -- > 2.25.1 > > ~Michal ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-11-18 7:47 ` Michal Orzel @ 2022-11-18 9:02 ` Julien Grall 0 siblings, 0 replies; 1767+ messages in thread From: Julien Grall @ 2022-11-18 9:02 UTC (permalink / raw) To: Michal Orzel, Jiamei Xie, xen-devel Cc: Stefano Stabellini, Bertrand Marquis, Volodymyr Babchuk, Wei Chen On 18/11/2022 07:47, Michal Orzel wrote: > On 18/11/2022 03:00, Jiamei Xie wrote: >> >> >> Date: Thu, 17 Nov 2022 11:07:12 +0800 >> Subject: [PATCH] xen/arm: vpl011: Make access to DMACR write-ignore >> >> When the guest kernel enables DMA engine with "CONFIG_DMA_ENGINE=y", >> Linux SBSA PL011 driver will access PL011 DMACR register in some >> functions. As chapter "B Generic UART" in "ARM Server Base System >> Architecture"[1] documentation describes, SBSA UART doesn't support >> DMA. In current code, when the kernel tries to access DMACR register, >> Xen will inject a data abort: >> Unhandled fault at 0xffffffc00944d048 >> Mem abort info: >> ESR = 0x96000000 >> EC = 0x25: DABT (current EL), IL = 32 bits >> SET = 0, FnV = 0 >> EA = 0, S1PTW = 0 >> FSC = 0x00: ttbr address size fault >> Data abort info: >> ISV = 0, ISS = 0x00000000 >> CM = 0, WnR = 0 >> swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000020e2e000 >> [ffffffc00944d048] pgd=100000003ffff803, p4d=100000003ffff803, pud=100000003ffff803, pmd=100000003fffa803, pte=006800009c090f13 >> Internal error: ttbr address size fault: 96000000 [#1] PREEMPT SMP >> ... >> Call trace: >> pl011_stop_rx+0x70/0x80 >> tty_port_shutdown+0x7c/0xb4 >> tty_port_close+0x60/0xcc >> uart_close+0x34/0x8c >> tty_release+0x144/0x4c0 >> __fput+0x78/0x220 >> ____fput+0x1c/0x30 >> task_work_run+0x88/0xc0 >> do_notify_resume+0x8d0/0x123c >> el0_svc+0xa8/0xc0 >> el0t_64_sync_handler+0xa4/0x130 >> el0t_64_sync+0x1a0/0x1a4 >> Code: b9000083 b901f001 794038a0 8b000042 (b9000041) >> ---[ end trace 83dd93df15c3216f ]--- >> note: bootlogd[132] exited with preempt_count 1 >> /etc/rcS.d/S07bootlogd: line 47: 132 Segmentation fault start-stop-daemon >> >> As discussed in [2], this commit makes the access to DMACR register >> write-ignore as an improvement. > As discussed earlier, if we decide to improve vpl011 (for now only Stefano shared his opinion), > then we need to mark *all* the PL011 registers that are not part of SBSA ar RAZ/WI. I would be fine to that. But I would like us to print a message using XENLOG_G_DEBUG to catch any OS that would touch those registers. Cheers, -- Julien Grall ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2022-11-09 14:34 Denis Arefev 2022-11-09 14:44 ` Greg Kroah-Hartman 0 siblings, 1 reply; 1767+ messages in thread From: Denis Arefev @ 2022-11-09 14:34 UTC (permalink / raw) To: David Airlie, Daniel Vetter, Greg Kroah-Hartman, stable Cc: Alexey Khoroshilov, ldv-project, trufanov, vfh Date: Wed, 9 Nov 2022 16:52:17 +0300 Subject: [PATCH 5.10] nbio_v7_4: Add pointer check Return value of a function 'amdgpu_ras_find_obj' is dereferenced at nbio_v7_4.c:325 without checking for null Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Denis Arefev <arefev@swemel.ru> --- drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c b/drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c index eadc9526d33f..d2627a610e48 100644 --- a/drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c +++ b/drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c @@ -303,6 +303,9 @@ static void nbio_v7_4_handle_ras_controller_intr_no_bifring(struct amdgpu_device struct ras_manager *obj = amdgpu_ras_find_obj(adev, adev->nbio.ras_if); struct ras_err_data err_data = {0, 0, 0, NULL}; struct amdgpu_ras *ras = amdgpu_ras_get_context(adev); + if (!obj) + return; bif_doorbell_intr_cntl = RREG32_SOC15(NBIO, 0, mmBIF_DOORBELL_INT_CNTL); if (REG_GET_FIELD(bif_doorbell_intr_cntl, -- 2.25.1 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2022-11-09 14:34 Denis Arefev @ 2022-11-09 14:44 ` Greg Kroah-Hartman 0 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2022-11-09 14:44 UTC (permalink / raw) To: Denis Arefev Cc: David Airlie, Daniel Vetter, stable, Alexey Khoroshilov, ldv-project, trufanov, vfh On Wed, Nov 09, 2022 at 05:34:13PM +0300, Denis Arefev wrote: > Date: Wed, 9 Nov 2022 16:52:17 +0300 > Subject: [PATCH 5.10] nbio_v7_4: Add pointer check > > Return value of a function 'amdgpu_ras_find_obj' is dereferenced at nbio_v7_4.c:325 without checking for null > > Found by Linux Verification Center (linuxtesting.org) with SVACE. > > Signed-off-by: Denis Arefev <arefev@swemel.ru> > --- > drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c b/drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c > index eadc9526d33f..d2627a610e48 100644 > --- a/drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c > +++ b/drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c > @@ -303,6 +303,9 @@ static void nbio_v7_4_handle_ras_controller_intr_no_bifring(struct amdgpu_device > struct ras_manager *obj = amdgpu_ras_find_obj(adev, adev->nbio.ras_if); > struct ras_err_data err_data = {0, 0, 0, NULL}; > struct amdgpu_ras *ras = amdgpu_ras_get_context(adev); > > + if (!obj) > + return; > > bif_doorbell_intr_cntl = RREG32_SOC15(NBIO, 0, mmBIF_DOORBELL_INT_CNTL); > if (REG_GET_FIELD(bif_doorbell_intr_cntl, > -- > 2.25.1 > <formletter> This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly. </formletter> ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2022-09-14 13:12 Amjad Ouled-Ameur 2022-09-14 13:18 ` Re: Amjad Ouled-Ameur 0 siblings, 1 reply; 1767+ messages in thread From: Amjad Ouled-Ameur @ 2022-09-14 13:12 UTC (permalink / raw) To: Rob Herring Cc: Amjad Ouled-Ameur, Krzysztof Kozlowski, Matthias Brugger, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel Subject: [PATCH] arm64: dts: mediatek: mt8183: remove thermal zones without trips. Thermal zones without trip point are not registered by thermal core. tzts1 ~ tzts6 zones of mt8183 were intially introduced for test-purpose only but are not supposed to remain on DT. Remove the zones above and keep only cpu_thermal. Signed-off-by: Amjad Ouled-Ameur <aouledameur@baylibre.com> --- arch/arm64/boot/dts/mediatek/mt8183.dtsi | 57 ------------------------ 1 file changed, 57 deletions(-) diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi index 9d32871973a2..f65fae8939de 100644 --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi @@ -1182,63 +1182,6 @@ THERMAL_NO_LIMIT }; }; }; - - /* The tzts1 ~ tzts6 don't need to polling */ - /* The tzts1 ~ tzts6 don't need to thermal throttle */ - - tzts1: tzts1 { - polling-delay-passive = <0>; - polling-delay = <0>; - thermal-sensors = <&thermal 1>; - sustainable-power = <5000>; - trips {}; - cooling-maps {}; - }; - - tzts2: tzts2 { - polling-delay-passive = <0>; - polling-delay = <0>; - thermal-sensors = <&thermal 2>; - sustainable-power = <5000>; - trips {}; - cooling-maps {}; - }; - - tzts3: tzts3 { - polling-delay-passive = <0>; - polling-delay = <0>; - thermal-sensors = <&thermal 3>; - sustainable-power = <5000>; - trips {}; - cooling-maps {}; - }; - - tzts4: tzts4 { - polling-delay-passive = <0>; - polling-delay = <0>; - thermal-sensors = <&thermal 4>; - sustainable-power = <5000>; - trips {}; - cooling-maps {}; - }; - - tzts5: tzts5 { - polling-delay-passive = <0>; - polling-delay = <0>; - thermal-sensors = <&thermal 5>; - sustainable-power = <5000>; - trips {}; - cooling-maps {}; - }; - - tztsABB: tztsABB { - polling-delay-passive = <0>; - polling-delay = <0>; - thermal-sensors = <&thermal 6>; - sustainable-power = <5000>; - trips {}; - cooling-maps {}; - }; }; pwm0: pwm@1100e000 { -- 2.37.3 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2022-09-14 13:12 Amjad Ouled-Ameur @ 2022-09-14 13:18 ` Amjad Ouled-Ameur 0 siblings, 0 replies; 1767+ messages in thread From: Amjad Ouled-Ameur @ 2022-09-14 13:18 UTC (permalink / raw) To: Rob Herring Cc: Krzysztof Kozlowski, Matthias Brugger, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel Hi, The subject has not been parsed correctly, I resent a proper patch here: https://patchwork.kernel.org/project/linux-mediatek/patch/20220914131339.18348-1-aouledameur@baylibre.com/ Sorry for the noise. Regards, Amjad On 9/14/22 15:12, Amjad Ouled-Ameur wrote: > Subject: [PATCH] arm64: dts: mediatek: mt8183: remove thermal zones without > trips. > > Thermal zones without trip point are not registered by thermal core. > > tzts1 ~ tzts6 zones of mt8183 were intially introduced for test-purpose > only but are not supposed to remain on DT. > > Remove the zones above and keep only cpu_thermal. > > Signed-off-by: Amjad Ouled-Ameur <aouledameur@baylibre.com> > --- > arch/arm64/boot/dts/mediatek/mt8183.dtsi | 57 ------------------------ > 1 file changed, 57 deletions(-) > > diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi > index 9d32871973a2..f65fae8939de 100644 > --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi > +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi > @@ -1182,63 +1182,6 @@ THERMAL_NO_LIMIT > }; > }; > }; > - > - /* The tzts1 ~ tzts6 don't need to polling */ > - /* The tzts1 ~ tzts6 don't need to thermal throttle */ > - > - tzts1: tzts1 { > - polling-delay-passive = <0>; > - polling-delay = <0>; > - thermal-sensors = <&thermal 1>; > - sustainable-power = <5000>; > - trips {}; > - cooling-maps {}; > - }; > - > - tzts2: tzts2 { > - polling-delay-passive = <0>; > - polling-delay = <0>; > - thermal-sensors = <&thermal 2>; > - sustainable-power = <5000>; > - trips {}; > - cooling-maps {}; > - }; > - > - tzts3: tzts3 { > - polling-delay-passive = <0>; > - polling-delay = <0>; > - thermal-sensors = <&thermal 3>; > - sustainable-power = <5000>; > - trips {}; > - cooling-maps {}; > - }; > - > - tzts4: tzts4 { > - polling-delay-passive = <0>; > - polling-delay = <0>; > - thermal-sensors = <&thermal 4>; > - sustainable-power = <5000>; > - trips {}; > - cooling-maps {}; > - }; > - > - tzts5: tzts5 { > - polling-delay-passive = <0>; > - polling-delay = <0>; > - thermal-sensors = <&thermal 5>; > - sustainable-power = <5000>; > - trips {}; > - cooling-maps {}; > - }; > - > - tztsABB: tztsABB { > - polling-delay-passive = <0>; > - polling-delay = <0>; > - thermal-sensors = <&thermal 6>; > - sustainable-power = <5000>; > - trips {}; > - cooling-maps {}; > - }; > }; > > pwm0: pwm@1100e000 { ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2022-09-14 13:18 ` Amjad Ouled-Ameur 0 siblings, 0 replies; 1767+ messages in thread From: Amjad Ouled-Ameur @ 2022-09-14 13:18 UTC (permalink / raw) To: Rob Herring Cc: Krzysztof Kozlowski, Matthias Brugger, devicetree, linux-arm-kernel, linux-mediatek, linux-kernel Hi, The subject has not been parsed correctly, I resent a proper patch here: https://patchwork.kernel.org/project/linux-mediatek/patch/20220914131339.18348-1-aouledameur@baylibre.com/ Sorry for the noise. Regards, Amjad On 9/14/22 15:12, Amjad Ouled-Ameur wrote: > Subject: [PATCH] arm64: dts: mediatek: mt8183: remove thermal zones without > trips. > > Thermal zones without trip point are not registered by thermal core. > > tzts1 ~ tzts6 zones of mt8183 were intially introduced for test-purpose > only but are not supposed to remain on DT. > > Remove the zones above and keep only cpu_thermal. > > Signed-off-by: Amjad Ouled-Ameur <aouledameur@baylibre.com> > --- > arch/arm64/boot/dts/mediatek/mt8183.dtsi | 57 ------------------------ > 1 file changed, 57 deletions(-) > > diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi > index 9d32871973a2..f65fae8939de 100644 > --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi > +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi > @@ -1182,63 +1182,6 @@ THERMAL_NO_LIMIT > }; > }; > }; > - > - /* The tzts1 ~ tzts6 don't need to polling */ > - /* The tzts1 ~ tzts6 don't need to thermal throttle */ > - > - tzts1: tzts1 { > - polling-delay-passive = <0>; > - polling-delay = <0>; > - thermal-sensors = <&thermal 1>; > - sustainable-power = <5000>; > - trips {}; > - cooling-maps {}; > - }; > - > - tzts2: tzts2 { > - polling-delay-passive = <0>; > - polling-delay = <0>; > - thermal-sensors = <&thermal 2>; > - sustainable-power = <5000>; > - trips {}; > - cooling-maps {}; > - }; > - > - tzts3: tzts3 { > - polling-delay-passive = <0>; > - polling-delay = <0>; > - thermal-sensors = <&thermal 3>; > - sustainable-power = <5000>; > - trips {}; > - cooling-maps {}; > - }; > - > - tzts4: tzts4 { > - polling-delay-passive = <0>; > - polling-delay = <0>; > - thermal-sensors = <&thermal 4>; > - sustainable-power = <5000>; > - trips {}; > - cooling-maps {}; > - }; > - > - tzts5: tzts5 { > - polling-delay-passive = <0>; > - polling-delay = <0>; > - thermal-sensors = <&thermal 5>; > - sustainable-power = <5000>; > - trips {}; > - cooling-maps {}; > - }; > - > - tztsABB: tztsABB { > - polling-delay-passive = <0>; > - polling-delay = <0>; > - thermal-sensors = <&thermal 6>; > - sustainable-power = <5000>; > - trips {}; > - cooling-maps {}; > - }; > }; > > pwm0: pwm@1100e000 { _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2022-09-12 12:36 Christian König 2022-09-13 2:04 ` Alex Deucher 0 siblings, 1 reply; 1767+ messages in thread From: Christian König @ 2022-09-12 12:36 UTC (permalink / raw) To: alexander.deucher, amd-gfx Hey Alex, I've decided to split this patch set into two because we still can't figure out where the VCN regressions come from. Ruijing tested them and confirmed that they don't regress VCN. Can you and maybe Felix take a look and review them? Thanks, Christian. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-09-12 12:36 Christian König @ 2022-09-13 2:04 ` Alex Deucher 0 siblings, 0 replies; 1767+ messages in thread From: Alex Deucher @ 2022-09-13 2:04 UTC (permalink / raw) To: Christian König; +Cc: alexander.deucher, amd-gfx On Mon, Sep 12, 2022 at 8:36 AM Christian König <ckoenig.leichtzumerken@gmail.com> wrote: > > Hey Alex, > > I've decided to split this patch set into two because we still can't > figure out where the VCN regressions come from. > > Ruijing tested them and confirmed that they don't regress VCN. > > Can you and maybe Felix take a look and review them? Looks good to me. Series is: Reviewed-by: Alex Deucher <alexander.deucher@amd.com> > > Thanks, > Christian. > > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2022-08-28 21:01 Nick Neumann 2022-09-01 17:44 ` Nick Neumann 0 siblings, 1 reply; 1767+ messages in thread From: Nick Neumann @ 2022-08-28 21:01 UTC (permalink / raw) To: fio I've filed the issue on github, but just thought I'd mention here too. In real-world use it appears to be intermittent. I"m not yet sure how intermittent, but I could see it being used in production and not caught right away. I got lucky and stumbled on it when looking at graphs of runs and noticed 15 seconds of no activity. https://github.com/axboe/fio/issues/1457 With the null ioengine, I can make it reproduce very reliably, which is encouraging as I move to debug. I had just moved to using log compression as it is really powerful, and the only way to store per I/O logs for a long run without pushing up against the amount of physical memory in a system. (Without compression, a GB of sequential writes at 128K block size is on the order of 245KB of memory per log, so a TB is 245MB per log. Now run a job to fill a 20TB drive and you're at 4.9GB for one log file. If you record all 3 latency numbers too, you're talking close to 20GB.) ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-08-28 21:01 Nick Neumann @ 2022-09-01 17:44 ` Nick Neumann 0 siblings, 0 replies; 1767+ messages in thread From: Nick Neumann @ 2022-09-01 17:44 UTC (permalink / raw) To: fio PR for this is up now. On Sun, Aug 28, 2022 at 4:01 PM Nick Neumann <nick@pcpartpicker.com> wrote: > > I've filed the issue on github, but just thought I'd mention here too. > In real-world use it appears to be intermittent. I"m not yet sure how > intermittent, but I could see it being used in production and not > caught right away. I got lucky and stumbled on it when looking at > graphs of runs and noticed 15 seconds of no activity. > > https://github.com/axboe/fio/issues/1457 > > With the null ioengine, I can make it reproduce very reliably, which > is encouraging as I move to debug. > > I had just moved to using log compression as it is really powerful, > and the only way to store per I/O logs for a long run without pushing > up against the amount of physical memory in a system. > > (Without compression, a GB of sequential writes at 128K block size is > on the order of 245KB of memory per log, so a TB is 245MB per log. Now > run a job to fill a 20TB drive and you're at 4.9GB for one log file. > If you record all 3 latency numbers too, you're talking close to > 20GB.) ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2022-08-26 22:03 Zach O'Keefe
2022-08-31 21:47 ` Yang Shi
0 siblings, 1 reply; 1767+ messages in thread
From: Zach O'Keefe @ 2022-08-26 22:03 UTC (permalink / raw)
To: linux-mm
Cc: Andrew Morton, linux-api, Axel Rasmussen, James Houghton,
Hugh Dickins, Yang Shi, Miaohe Lin, David Hildenbrand,
David Rientjes, Matthew Wilcox, Pasha Tatashin, Peter Xu,
Rongwei Wang, SeongJae Park, Song Liu, Vlastimil Babka,
Chris Kennelly, Kirill A. Shutemov, Minchan Kim, Patrick Xia,
Zach O'Keefe
Subject: [PATCH mm-unstable v2 0/9] mm: add file/shmem support to MADV_COLLAPSE
v2 Forward
Mostly a RESEND: rebase on latest mm-unstable + minor bug fixes from
kernel test robot.
--------------------------------
This series builds on top of the previous "mm: userspace hugepage collapse"
series which introduced the MADV_COLLAPSE madvise mode and added support
for private, anonymous mappings[1], by adding support for file and shmem
backed memory to CONFIG_READ_ONLY_THP_FOR_FS=y kernels.
File and shmem support have been added with effort to align with existing
MADV_COLLAPSE semantics and policy decisions[2]. Collapse of shmem-backed
memory ignores kernel-guiding directives and heuristics including all
sysfs settings (transparent_hugepage/shmem_enabled), and tmpfs huge= mount
options (shmem always supports large folios). Like anonymous mappings, on
successful return of MADV_COLLAPSE on file/shmem memory, the contents of
memory mapped by the addresses provided will be synchronously pmd-mapped
THPs.
This functionality unlocks two important uses:
(1) Immediately back executable text by THPs. Current support provided
by CONFIG_READ_ONLY_THP_FOR_FS may take a long time on a large
system which might impair services from serving at their full rated
load after (re)starting. Tricks like mremap(2)'ing text onto
anonymous memory to immediately realize iTLB performance prevents
page sharing and demand paging, both of which increase steady state
memory footprint. Now, we can have the best of both worlds: Peak
upfront performance and lower RAM footprints.
(2) userfaultfd-based live migration of virtual machines satisfy UFFD
faults by fetching native-sized pages over the network (to avoid
latency of transferring an entire hugepage). However, after guest
memory has been fully copied to the new host, MADV_COLLAPSE can
be used to immediately increase guest performance.
khugepaged has received a small improvement by association and can now
detect and collapse pte-mapped THPs. However, there is still work to be
done along the file collapse path. Compound pages of arbitrary order still
needs to be supported and THP collapse needs to be converted to using
folios in general. Eventually, we'd like to move away from the read-only
and executable-mapped constraints currently imposed on eligible files and
support any inode claiming huge folio support. That said, I think the
series as-is covers enough to claim that MADV_COLLAPSE supports file/shmem
memory.
Patches 1-3 Implement the guts of the series.
Patch 4 Is a tracepoint for debugging.
Patches 5-8 Refactor existing khugepaged selftests to work with new
memory types.
Patch 9 Adds a userfaultfd selftest mode to mimic a functional test
of UFFDIO_REGISTER_MODE_MINOR+MADV_COLLAPSE live migration.
Applies against mm-unstable.
[1] https://lore.kernel.org/linux-mm/20220706235936.2197195-1-zokeefe@google.com/
[2] https://lore.kernel.org/linux-mm/YtBmhaiPHUTkJml8@google.com/
v1 -> v2:
- Add missing definition for khugepaged_add_pte_mapped_thp() in
!CONFIG_SHEM builds, in "mm/khugepaged: attempt to map
file/shmem-backed pte-mapped THPs by pmds"
- Minor bugfixes in "mm/madvise: add file and shmem support to
MADV_COLLAPSE" for !CONFIG_SHMEM, !CONFIG_TRANSPARENT_HUGEPAGE and some
compiler settings.
- Rebased on latest mm-unstable
Zach O'Keefe (9):
mm/shmem: add flag to enforce shmem THP in hugepage_vma_check()
mm/khugepaged: attempt to map file/shmem-backed pte-mapped THPs by
pmds
mm/madvise: add file and shmem support to MADV_COLLAPSE
mm/khugepaged: add tracepoint to hpage_collapse_scan_file()
selftests/vm: dedup THP helpers
selftests/vm: modularize thp collapse memory operations
selftests/vm: add thp collapse file and tmpfs testing
selftests/vm: add thp collapse shmem testing
selftests/vm: add selftest for MADV_COLLAPSE of uffd-minor memory
include/linux/khugepaged.h | 13 +-
include/linux/shmem_fs.h | 10 +-
include/trace/events/huge_memory.h | 36 +
kernel/events/uprobes.c | 2 +-
mm/huge_memory.c | 2 +-
mm/khugepaged.c | 289 ++++--
mm/shmem.c | 18 +-
tools/testing/selftests/vm/Makefile | 2 +
tools/testing/selftests/vm/khugepaged.c | 828 ++++++++++++------
tools/testing/selftests/vm/soft-dirty.c | 2 +-
.../selftests/vm/split_huge_page_test.c | 12 +-
tools/testing/selftests/vm/userfaultfd.c | 171 +++-
tools/testing/selftests/vm/vm_util.c | 36 +-
tools/testing/selftests/vm/vm_util.h | 5 +-
14 files changed, 1040 insertions(+), 386 deletions(-)
--
2.37.2.672.g94769d06f0-goog
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2022-08-26 22:03 Zach O'Keefe @ 2022-08-31 21:47 ` Yang Shi 2022-09-01 0:24 ` Re: Zach O'Keefe 0 siblings, 1 reply; 1767+ messages in thread From: Yang Shi @ 2022-08-31 21:47 UTC (permalink / raw) To: Zach O'Keefe Cc: linux-mm, Andrew Morton, linux-api, Axel Rasmussen, James Houghton, Hugh Dickins, Miaohe Lin, David Hildenbrand, David Rientjes, Matthew Wilcox, Pasha Tatashin, Peter Xu, Rongwei Wang, SeongJae Park, Song Liu, Vlastimil Babka, Chris Kennelly, Kirill A. Shutemov, Minchan Kim, Patrick Xia Hi Zach, I did a quick look at the series, basically no show stopper to me. But I didn't find time to review them thoroughly yet, quite busy on something else. Just a heads up, I didn't mean to ignore you. I will review them when I find some time. Thanks, Yang On Fri, Aug 26, 2022 at 3:03 PM Zach O'Keefe <zokeefe@google.com> wrote: > > Subject: [PATCH mm-unstable v2 0/9] mm: add file/shmem support to MADV_COLLAPSE > > v2 Forward > > Mostly a RESEND: rebase on latest mm-unstable + minor bug fixes from > kernel test robot. > -------------------------------- > > This series builds on top of the previous "mm: userspace hugepage collapse" > series which introduced the MADV_COLLAPSE madvise mode and added support > for private, anonymous mappings[1], by adding support for file and shmem > backed memory to CONFIG_READ_ONLY_THP_FOR_FS=y kernels. > > File and shmem support have been added with effort to align with existing > MADV_COLLAPSE semantics and policy decisions[2]. Collapse of shmem-backed > memory ignores kernel-guiding directives and heuristics including all > sysfs settings (transparent_hugepage/shmem_enabled), and tmpfs huge= mount > options (shmem always supports large folios). Like anonymous mappings, on > successful return of MADV_COLLAPSE on file/shmem memory, the contents of > memory mapped by the addresses provided will be synchronously pmd-mapped > THPs. > > This functionality unlocks two important uses: > > (1) Immediately back executable text by THPs. Current support provided > by CONFIG_READ_ONLY_THP_FOR_FS may take a long time on a large > system which might impair services from serving at their full rated > load after (re)starting. Tricks like mremap(2)'ing text onto > anonymous memory to immediately realize iTLB performance prevents > page sharing and demand paging, both of which increase steady state > memory footprint. Now, we can have the best of both worlds: Peak > upfront performance and lower RAM footprints. > > (2) userfaultfd-based live migration of virtual machines satisfy UFFD > faults by fetching native-sized pages over the network (to avoid > latency of transferring an entire hugepage). However, after guest > memory has been fully copied to the new host, MADV_COLLAPSE can > be used to immediately increase guest performance. > > khugepaged has received a small improvement by association and can now > detect and collapse pte-mapped THPs. However, there is still work to be > done along the file collapse path. Compound pages of arbitrary order still > needs to be supported and THP collapse needs to be converted to using > folios in general. Eventually, we'd like to move away from the read-only > and executable-mapped constraints currently imposed on eligible files and > support any inode claiming huge folio support. That said, I think the > series as-is covers enough to claim that MADV_COLLAPSE supports file/shmem > memory. > > Patches 1-3 Implement the guts of the series. > Patch 4 Is a tracepoint for debugging. > Patches 5-8 Refactor existing khugepaged selftests to work with new > memory types. > Patch 9 Adds a userfaultfd selftest mode to mimic a functional test > of UFFDIO_REGISTER_MODE_MINOR+MADV_COLLAPSE live migration. > > Applies against mm-unstable. > > [1] https://lore.kernel.org/linux-mm/20220706235936.2197195-1-zokeefe@google.com/ > [2] https://lore.kernel.org/linux-mm/YtBmhaiPHUTkJml8@google.com/ > > v1 -> v2: > - Add missing definition for khugepaged_add_pte_mapped_thp() in > !CONFIG_SHEM builds, in "mm/khugepaged: attempt to map > file/shmem-backed pte-mapped THPs by pmds" > - Minor bugfixes in "mm/madvise: add file and shmem support to > MADV_COLLAPSE" for !CONFIG_SHMEM, !CONFIG_TRANSPARENT_HUGEPAGE and some > compiler settings. > - Rebased on latest mm-unstable > > Zach O'Keefe (9): > mm/shmem: add flag to enforce shmem THP in hugepage_vma_check() > mm/khugepaged: attempt to map file/shmem-backed pte-mapped THPs by > pmds > mm/madvise: add file and shmem support to MADV_COLLAPSE > mm/khugepaged: add tracepoint to hpage_collapse_scan_file() > selftests/vm: dedup THP helpers > selftests/vm: modularize thp collapse memory operations > selftests/vm: add thp collapse file and tmpfs testing > selftests/vm: add thp collapse shmem testing > selftests/vm: add selftest for MADV_COLLAPSE of uffd-minor memory > > include/linux/khugepaged.h | 13 +- > include/linux/shmem_fs.h | 10 +- > include/trace/events/huge_memory.h | 36 + > kernel/events/uprobes.c | 2 +- > mm/huge_memory.c | 2 +- > mm/khugepaged.c | 289 ++++-- > mm/shmem.c | 18 +- > tools/testing/selftests/vm/Makefile | 2 + > tools/testing/selftests/vm/khugepaged.c | 828 ++++++++++++------ > tools/testing/selftests/vm/soft-dirty.c | 2 +- > .../selftests/vm/split_huge_page_test.c | 12 +- > tools/testing/selftests/vm/userfaultfd.c | 171 +++- > tools/testing/selftests/vm/vm_util.c | 36 +- > tools/testing/selftests/vm/vm_util.h | 5 +- > 14 files changed, 1040 insertions(+), 386 deletions(-) > > -- > 2.37.2.672.g94769d06f0-goog > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-08-31 21:47 ` Yang Shi @ 2022-09-01 0:24 ` Zach O'Keefe 0 siblings, 0 replies; 1767+ messages in thread From: Zach O'Keefe @ 2022-09-01 0:24 UTC (permalink / raw) To: Yang Shi Cc: linux-mm, Andrew Morton, linux-api, Axel Rasmussen, James Houghton, Hugh Dickins, Miaohe Lin, David Hildenbrand, David Rientjes, Matthew Wilcox, Pasha Tatashin, Peter Xu, Rongwei Wang, SeongJae Park, Song Liu, Vlastimil Babka, Chris Kennelly, Kirill A. Shutemov, Minchan Kim, Patrick Xia On Wed, Aug 31, 2022 at 2:47 PM Yang Shi <shy828301@gmail.com> wrote: > > Hi Zach, > > I did a quick look at the series, basically no show stopper to me. But > I didn't find time to review them thoroughly yet, quite busy on > something else. Just a heads up, I didn't mean to ignore you. I will > review them when I find some time. > > Thanks, > Yang Hey Yang, Thanks for taking the time to look through, and thanks for giving me a heads up, and no rush! In the last day or so, while porting this series around, I encountered some subtle edge cases I wanted to clean up / address - so it's good you didn't do a thorough review yet. I was *hoping* to have a v3 out last night (which evidently did not happen) and it does not seem like it will happen today, so I'll leave this message as a request for reviewers to hold off on a thorough review until v3. Thanks for your time as always, Zach ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2022-06-06 5:33 Fenil Jain
2022-06-06 5:51 ` Greg Kroah-Hartman
0 siblings, 1 reply; 1767+ messages in thread
From: Fenil Jain @ 2022-06-06 5:33 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Shuah Khan, stable
On Fri, Jun 03, 2022 at 07:43:01PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.18.2 release.
> There are 67 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 Sun, 05 Jun 2022 17:38:05 +0000.
> Anything received after that time might be too late.
Hey Greg,
Ran tests and boot tested on my system, no regression found
Tested-by: Fenil Jain<fkjainco@gmail.com>
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2022-06-06 5:33 Fenil Jain @ 2022-06-06 5:51 ` Greg Kroah-Hartman 0 siblings, 0 replies; 1767+ messages in thread From: Greg Kroah-Hartman @ 2022-06-06 5:51 UTC (permalink / raw) To: Fenil Jain; +Cc: Shuah Khan, stable On Mon, Jun 06, 2022 at 11:03:24AM +0530, Fenil Jain wrote: > On Fri, Jun 03, 2022 at 07:43:01PM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.18.2 release. > > There are 67 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 Sun, 05 Jun 2022 17:38:05 +0000. > > Anything received after that time might be too late. > > Hey Greg, > > Ran tests and boot tested on my system, no regression found > > Tested-by: Fenil Jain<fkjainco@gmail.com> Thanks for the testing, but something went wrong with your email client and it lost the Subject: line, making this impossible to be picked up by our tools. Also, please include an extra ' ' before the '<' character in your tested-by line. thanks, greg k-h ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH bpf-next 1/2] cpuidle/rcu: Making arch_cpu_idle and rcu_idle_exit noinstr @ 2022-05-15 20:36 Jiri Olsa 2023-05-20 9:47 ` Ze Gao 0 siblings, 1 reply; 1767+ messages in thread From: Jiri Olsa @ 2022-05-15 20:36 UTC (permalink / raw) To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, Masami Hiramatsu, Paul E. McKenney Cc: netdev, bpf, lkml, Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend, KP Singh, Steven Rostedt Making arch_cpu_idle and rcu_idle_exit noinstr. Both functions run in rcu 'not watching' context and if there's tracer attached to them, which uses rcu (e.g. kprobe multi interface) it will hit RCU warning like: [ 3.017540] WARNING: suspicious RCU usage ... [ 3.018363] kprobe_multi_link_handler+0x68/0x1c0 [ 3.018364] ? kprobe_multi_link_handler+0x3e/0x1c0 [ 3.018366] ? arch_cpu_idle_dead+0x10/0x10 [ 3.018367] ? arch_cpu_idle_dead+0x10/0x10 [ 3.018371] fprobe_handler.part.0+0xab/0x150 [ 3.018374] 0xffffffffa00080c8 [ 3.018393] ? arch_cpu_idle+0x5/0x10 [ 3.018398] arch_cpu_idle+0x5/0x10 [ 3.018399] default_idle_call+0x59/0x90 [ 3.018401] do_idle+0x1c3/0x1d0 The call path is following: default_idle_call rcu_idle_enter arch_cpu_idle rcu_idle_exit The arch_cpu_idle and rcu_idle_exit are the only ones from above path that are traceble and cause this problem on my setup. Signed-off-by: Jiri Olsa <jolsa@kernel.org> --- arch/x86/kernel/process.c | 2 +- kernel/rcu/tree.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c index b370767f5b19..1345cb0124a6 100644 --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -720,7 +720,7 @@ void arch_cpu_idle_dead(void) /* * Called from the generic idle code. */ -void arch_cpu_idle(void) +void noinstr arch_cpu_idle(void) { x86_idle(); } diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index a4b8189455d5..20d529722f51 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -896,7 +896,7 @@ static void noinstr rcu_eqs_exit(bool user) * If you add or remove a call to rcu_idle_exit(), be sure to test with * CONFIG_RCU_EQS_DEBUG=y. */ -void rcu_idle_exit(void) +void noinstr rcu_idle_exit(void) { unsigned long flags; -- 2.35.3 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* (no subject) 2022-05-15 20:36 [PATCH bpf-next 1/2] cpuidle/rcu: Making arch_cpu_idle and rcu_idle_exit noinstr Jiri Olsa @ 2023-05-20 9:47 ` Ze Gao 2023-05-21 3:58 ` Yonghong Song 2023-05-21 8:08 ` Re: Jiri Olsa 0 siblings, 2 replies; 1767+ messages in thread From: Ze Gao @ 2023-05-20 9:47 UTC (permalink / raw) To: jolsa Cc: Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, Hao Luo, John Fastabend, KP Singh, Martin KaFai Lau, Masami Hiramatsu, Song Liu, Stanislav Fomichev, Steven Rostedt, Yonghong Song, bpf, linux-kernel, linux-trace-kernel, kafai, kpsingh, netdev, paulmck, songliubraving, Ze Gao Hi Jiri, Would you like to consider to add rcu_is_watching check in to solve this from the viewpoint of kprobe_multi_link_prog_run itself? And accounting of missed runs can be added as well to imporve observability. Regards, Ze ----------------- From 29fd3cd713e65461325c2703cf5246a6fae5d4fe Mon Sep 17 00:00:00 2001 From: Ze Gao <zegao@tencent.com> Date: Sat, 20 May 2023 17:32:05 +0800 Subject: [PATCH] bpf: kprobe_multi runs bpf progs only when rcu_is_watching From the perspective of kprobe_multi_link_prog_run, any traceable functions can be attached while bpf progs need specical care and ought to be under rcu protection. To solve the likely rcu lockdep warns once for good, when (future) functions in idle path were attached accidentally, we better paying some cost to check at least in kernel-side, and return when rcu is not watching, which helps to avoid any unpredictable results. Signed-off-by: Ze Gao <zegao@tencent.com> --- kernel/trace/bpf_trace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c index 9a050e36dc6c..3e6ea7274765 100644 --- a/kernel/trace/bpf_trace.c +++ b/kernel/trace/bpf_trace.c @@ -2622,7 +2622,7 @@ kprobe_multi_link_prog_run(struct bpf_kprobe_multi_link *link, struct bpf_run_ctx *old_run_ctx; int err; - if (unlikely(__this_cpu_inc_return(bpf_prog_active) != 1)) { + if (unlikely(__this_cpu_inc_return(bpf_prog_active) != 1 || !rcu_is_watching())) { err = 0; goto out; } -- 2.40.1 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2023-05-20 9:47 ` Ze Gao @ 2023-05-21 3:58 ` Yonghong Song 2023-05-21 15:10 ` Re: Ze Gao 2023-05-21 8:08 ` Re: Jiri Olsa 1 sibling, 1 reply; 1767+ messages in thread From: Yonghong Song @ 2023-05-21 3:58 UTC (permalink / raw) To: Ze Gao, jolsa Cc: Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, Hao Luo, John Fastabend, KP Singh, Martin KaFai Lau, Masami Hiramatsu, Song Liu, Stanislav Fomichev, Steven Rostedt, Yonghong Song, bpf, linux-kernel, linux-trace-kernel, kafai, kpsingh, netdev, paulmck, songliubraving, Ze Gao On 5/20/23 2:47 AM, Ze Gao wrote: > > Hi Jiri, > > Would you like to consider to add rcu_is_watching check in > to solve this from the viewpoint of kprobe_multi_link_prog_run > itself? And accounting of missed runs can be added as well > to imporve observability. > > Regards, > Ze > > > ----------------- > From 29fd3cd713e65461325c2703cf5246a6fae5d4fe Mon Sep 17 00:00:00 2001 > From: Ze Gao <zegao@tencent.com> > Date: Sat, 20 May 2023 17:32:05 +0800 > Subject: [PATCH] bpf: kprobe_multi runs bpf progs only when rcu_is_watching > > From the perspective of kprobe_multi_link_prog_run, any traceable > functions can be attached while bpf progs need specical care and > ought to be under rcu protection. To solve the likely rcu lockdep > warns once for good, when (future) functions in idle path were > attached accidentally, we better paying some cost to check at least > in kernel-side, and return when rcu is not watching, which helps > to avoid any unpredictable results. kprobe_multi/fprobe share the same set of attachments with fentry. Currently, fentry does not filter with !rcu_is_watching, maybe because this is an extreme corner case. Not sure whether it is worthwhile or not. Maybe if you can give a concrete example (e.g., attachment point) with current code base to show what the issue you encountered and it will make it easier to judge whether adding !rcu_is_watching() is necessary or not. > > Signed-off-by: Ze Gao <zegao@tencent.com> > --- > kernel/trace/bpf_trace.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c > index 9a050e36dc6c..3e6ea7274765 100644 > --- a/kernel/trace/bpf_trace.c > +++ b/kernel/trace/bpf_trace.c > @@ -2622,7 +2622,7 @@ kprobe_multi_link_prog_run(struct bpf_kprobe_multi_link *link, > struct bpf_run_ctx *old_run_ctx; > int err; > > - if (unlikely(__this_cpu_inc_return(bpf_prog_active) != 1)) { > + if (unlikely(__this_cpu_inc_return(bpf_prog_active) != 1 || !rcu_is_watching())) { > err = 0; > goto out; > } ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2023-05-21 3:58 ` Yonghong Song @ 2023-05-21 15:10 ` Ze Gao 2023-05-21 20:26 ` Re: Jiri Olsa 0 siblings, 1 reply; 1767+ messages in thread From: Ze Gao @ 2023-05-21 15:10 UTC (permalink / raw) To: Yonghong Song Cc: jolsa, Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, Hao Luo, John Fastabend, KP Singh, Martin KaFai Lau, Masami Hiramatsu, Song Liu, Stanislav Fomichev, Steven Rostedt, Yonghong Song, bpf, linux-kernel, linux-trace-kernel, kafai, kpsingh, netdev, paulmck, songliubraving, Ze Gao > kprobe_multi/fprobe share the same set of attachments with fentry. > Currently, fentry does not filter with !rcu_is_watching, maybe > because this is an extreme corner case. Not sure whether it is > worthwhile or not. Agreed, it's rare, especially after Peter's patches which push narrow down rcu eqs regions in the idle path and reduce the chance of any traceable functions happening in between. However, from RCU's perspective, we ought to check if rcu_is_watching theoretically when there's a chance our code will run in the idle path and also we need rcu to be alive, And also we cannot simply make assumptions for any future changes in the idle path. You know, just like what was hit in the thread. > Maybe if you can give a concrete example (e.g., attachment point) > with current code base to show what the issue you encountered and > it will make it easier to judge whether adding !rcu_is_watching() > is necessary or not. I can reproduce likely warnings on v6.1.18 where arch_cpu_idle is traceable but not on the latest version so far. But as I state above, in theory we need it. So here is a gentle ping :) . ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2023-05-21 15:10 ` Re: Ze Gao @ 2023-05-21 20:26 ` Jiri Olsa 2023-05-22 1:36 ` Re: Masami Hiramatsu 2023-05-22 2:07 ` Re: Ze Gao 0 siblings, 2 replies; 1767+ messages in thread From: Jiri Olsa @ 2023-05-21 20:26 UTC (permalink / raw) To: Ze Gao Cc: Yonghong Song, Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, Hao Luo, John Fastabend, KP Singh, Martin KaFai Lau, Masami Hiramatsu, Song Liu, Stanislav Fomichev, Steven Rostedt, Yonghong Song, bpf, linux-kernel, linux-trace-kernel, kafai, kpsingh, netdev, paulmck, songliubraving, Ze Gao On Sun, May 21, 2023 at 11:10:16PM +0800, Ze Gao wrote: > > kprobe_multi/fprobe share the same set of attachments with fentry. > > Currently, fentry does not filter with !rcu_is_watching, maybe > > because this is an extreme corner case. Not sure whether it is > > worthwhile or not. > > Agreed, it's rare, especially after Peter's patches which push narrow > down rcu eqs regions > in the idle path and reduce the chance of any traceable functions > happening in between. > > However, from RCU's perspective, we ought to check if rcu_is_watching > theoretically > when there's a chance our code will run in the idle path and also we > need rcu to be alive, > And also we cannot simply make assumptions for any future changes in > the idle path. > You know, just like what was hit in the thread. > > > Maybe if you can give a concrete example (e.g., attachment point) > > with current code base to show what the issue you encountered and > > it will make it easier to judge whether adding !rcu_is_watching() > > is necessary or not. > > I can reproduce likely warnings on v6.1.18 where arch_cpu_idle is > traceable but not on the latest version > so far. But as I state above, in theory we need it. So here is a > gentle ping :) . hum, this change [1] added rcu_is_watching check to ftrace_test_recursion_trylock, which we use in fprobe_handler and is coming to fprobe_exit_handler in [2] I might be missing something, but it seems like we don't need another rcu_is_watching call on kprobe_multi level jirka [1] d099dbfd3306 cpuidle: tracing: Warn about !rcu_is_watching() [2] https://lore.kernel.org/bpf/20230517034510.15639-4-zegao@tencent.com/ ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2023-05-21 20:26 ` Re: Jiri Olsa @ 2023-05-22 1:36 ` Masami Hiramatsu 2023-05-22 2:07 ` Re: Ze Gao 1 sibling, 0 replies; 1767+ messages in thread From: Masami Hiramatsu @ 2023-05-22 1:36 UTC (permalink / raw) To: Jiri Olsa Cc: Ze Gao, Yonghong Song, Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, Hao Luo, John Fastabend, KP Singh, Martin KaFai Lau, Masami Hiramatsu, Song Liu, Stanislav Fomichev, Steven Rostedt, Yonghong Song, bpf, linux-kernel, linux-trace-kernel, kafai, kpsingh, netdev, paulmck, songliubraving, Ze Gao On Sun, 21 May 2023 22:26:37 +0200 Jiri Olsa <olsajiri@gmail.com> wrote: > On Sun, May 21, 2023 at 11:10:16PM +0800, Ze Gao wrote: > > > kprobe_multi/fprobe share the same set of attachments with fentry. > > > Currently, fentry does not filter with !rcu_is_watching, maybe > > > because this is an extreme corner case. Not sure whether it is > > > worthwhile or not. > > > > Agreed, it's rare, especially after Peter's patches which push narrow > > down rcu eqs regions > > in the idle path and reduce the chance of any traceable functions > > happening in between. > > > > However, from RCU's perspective, we ought to check if rcu_is_watching > > theoretically > > when there's a chance our code will run in the idle path and also we > > need rcu to be alive, > > And also we cannot simply make assumptions for any future changes in > > the idle path. > > You know, just like what was hit in the thread. > > > > > Maybe if you can give a concrete example (e.g., attachment point) > > > with current code base to show what the issue you encountered and > > > it will make it easier to judge whether adding !rcu_is_watching() > > > is necessary or not. > > > > I can reproduce likely warnings on v6.1.18 where arch_cpu_idle is > > traceable but not on the latest version > > so far. But as I state above, in theory we need it. So here is a > > gentle ping :) . > > hum, this change [1] added rcu_is_watching check to ftrace_test_recursion_trylock, > which we use in fprobe_handler and is coming to fprobe_exit_handler in [2] > > I might be missing something, but it seems like we don't need another > rcu_is_watching call on kprobe_multi level Good point! OK, then it seems we don't need it. The rethook continues to use the rcu_is_watching() because it is also used from kprobes, but the kprobe_multi doesn't need it. Thank you, > > jirka > > > [1] d099dbfd3306 cpuidle: tracing: Warn about !rcu_is_watching() > [2] https://lore.kernel.org/bpf/20230517034510.15639-4-zegao@tencent.com/ -- Masami Hiramatsu (Google) <mhiramat@kernel.org> ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2023-05-21 20:26 ` Re: Jiri Olsa 2023-05-22 1:36 ` Re: Masami Hiramatsu @ 2023-05-22 2:07 ` Ze Gao 2023-05-23 4:38 ` Re: Yonghong Song 2023-05-23 5:30 ` Re: Masami Hiramatsu 1 sibling, 2 replies; 1767+ messages in thread From: Ze Gao @ 2023-05-22 2:07 UTC (permalink / raw) To: Jiri Olsa Cc: Yonghong Song, Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, Hao Luo, John Fastabend, KP Singh, Martin KaFai Lau, Masami Hiramatsu, Song Liu, Stanislav Fomichev, Steven Rostedt, Yonghong Song, bpf, linux-kernel, linux-trace-kernel, kafai, kpsingh, netdev, paulmck, songliubraving, Ze Gao Oops, I missed that. Thanks for pointing that out, which I thought is conditional use of rcu_is_watching before. One last point, I think we should double check on this "fentry does not filter with !rcu_is_watching" as quoted from Yonghong and argue whether it needs the same check for fentry as well. Regards, Ze ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2023-05-22 2:07 ` Re: Ze Gao @ 2023-05-23 4:38 ` Yonghong Song 2023-05-23 5:30 ` Re: Masami Hiramatsu 1 sibling, 0 replies; 1767+ messages in thread From: Yonghong Song @ 2023-05-23 4:38 UTC (permalink / raw) To: Ze Gao, Jiri Olsa Cc: Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, Hao Luo, John Fastabend, KP Singh, Martin KaFai Lau, Masami Hiramatsu, Song Liu, Stanislav Fomichev, Steven Rostedt, Yonghong Song, bpf, linux-kernel, linux-trace-kernel, kafai, kpsingh, netdev, paulmck, songliubraving, Ze Gao On 5/21/23 7:07 PM, Ze Gao wrote: > Oops, I missed that. Thanks for pointing that out, which I thought is > conditional use of rcu_is_watching before. > > One last point, I think we should double check on this > "fentry does not filter with !rcu_is_watching" > as quoted from Yonghong and argue whether it needs > the same check for fentry as well. I would suggest that we address rcu_is_watching issue for fentry only if we do have a reproducible case to show something goes wrong... > > Regards, > Ze ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2023-05-22 2:07 ` Re: Ze Gao 2023-05-23 4:38 ` Re: Yonghong Song @ 2023-05-23 5:30 ` Masami Hiramatsu 2023-05-23 6:59 ` Re: Paul E. McKenney 1 sibling, 1 reply; 1767+ messages in thread From: Masami Hiramatsu @ 2023-05-23 5:30 UTC (permalink / raw) To: Ze Gao Cc: Jiri Olsa, Yonghong Song, Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, Hao Luo, John Fastabend, KP Singh, Martin KaFai Lau, Masami Hiramatsu, Song Liu, Stanislav Fomichev, Steven Rostedt, Yonghong Song, bpf, linux-kernel, linux-trace-kernel, kafai, kpsingh, netdev, paulmck, songliubraving, Ze Gao On Mon, 22 May 2023 10:07:42 +0800 Ze Gao <zegao2021@gmail.com> wrote: > Oops, I missed that. Thanks for pointing that out, which I thought is > conditional use of rcu_is_watching before. > > One last point, I think we should double check on this > "fentry does not filter with !rcu_is_watching" > as quoted from Yonghong and argue whether it needs > the same check for fentry as well. rcu_is_watching() comment says; * if the current CPU is not in its idle loop or is in an interrupt or * NMI handler, return true. Thus it returns *fault* if the current CPU is in the idle loop and not any interrupt(including NMI) context. This means if any tracable function is called from idle loop, it can be !rcu_is_watching(). I meant, this is 'context' based check, thus fentry can not filter out that some commonly used functions is called from that context but it can be detected. Thank you, > > Regards, > Ze -- Masami Hiramatsu (Google) <mhiramat@kernel.org> ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2023-05-23 5:30 ` Re: Masami Hiramatsu @ 2023-05-23 6:59 ` Paul E. McKenney 2023-05-25 0:13 ` Re: Masami Hiramatsu 0 siblings, 1 reply; 1767+ messages in thread From: Paul E. McKenney @ 2023-05-23 6:59 UTC (permalink / raw) To: Masami Hiramatsu Cc: Ze Gao, Jiri Olsa, Yonghong Song, Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, Hao Luo, John Fastabend, KP Singh, Martin KaFai Lau, Song Liu, Stanislav Fomichev, Steven Rostedt, Yonghong Song, bpf, linux-kernel, linux-trace-kernel, kafai, kpsingh, netdev, songliubraving, Ze Gao On Tue, May 23, 2023 at 01:30:19PM +0800, Masami Hiramatsu wrote: > On Mon, 22 May 2023 10:07:42 +0800 > Ze Gao <zegao2021@gmail.com> wrote: > > > Oops, I missed that. Thanks for pointing that out, which I thought is > > conditional use of rcu_is_watching before. > > > > One last point, I think we should double check on this > > "fentry does not filter with !rcu_is_watching" > > as quoted from Yonghong and argue whether it needs > > the same check for fentry as well. > > rcu_is_watching() comment says; > > * if the current CPU is not in its idle loop or is in an interrupt or > * NMI handler, return true. > > Thus it returns *fault* if the current CPU is in the idle loop and not > any interrupt(including NMI) context. This means if any tracable function > is called from idle loop, it can be !rcu_is_watching(). I meant, this is > 'context' based check, thus fentry can not filter out that some commonly > used functions is called from that context but it can be detected. It really does return false (rather than faulting?) if the current CPU is deep within the idle loop. In addition, the recent x86/entry rework (thank you Peter and Thomas!) mean that the "idle loop" is quite restricted, as can be seen by the invocations of ct_cpuidle_enter() and ct_cpuidle_exit(). For example, in default_idle_call(), these are immediately before and after the call to arch_cpu_idle(). Would the following help? Or am I missing your point? Thanx, Paul ------------------------------------------------------------------------ diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 1449cb69a0e0..fae9b4e29c93 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -679,10 +679,14 @@ static void rcu_disable_urgency_upon_qs(struct rcu_data *rdp) /** * rcu_is_watching - see if RCU thinks that the current CPU is not idle * - * Return true if RCU is watching the running CPU, which means that this - * CPU can safely enter RCU read-side critical sections. In other words, - * if the current CPU is not in its idle loop or is in an interrupt or - * NMI handler, return true. + * Return @true if RCU is watching the running CPU and @false otherwise. + * An @true return means that this CPU can safely enter RCU read-side + * critical sections. + * + * More specifically, if the current CPU is not deep within its idle + * loop, return @true. Note that rcu_is_watching() will return @true if + * invoked from an interrupt or NMI handler, even if that interrupt or + * NMI interrupted the CPU while it was deep within its idle loop. * * Make notrace because it can be called by the internal functions of * ftrace, and making this notrace removes unnecessary recursion calls. ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2023-05-23 6:59 ` Re: Paul E. McKenney @ 2023-05-25 0:13 ` Masami Hiramatsu 0 siblings, 0 replies; 1767+ messages in thread From: Masami Hiramatsu @ 2023-05-25 0:13 UTC (permalink / raw) To: paulmck Cc: Ze Gao, Jiri Olsa, Yonghong Song, Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, Hao Luo, John Fastabend, KP Singh, Martin KaFai Lau, Song Liu, Stanislav Fomichev, Steven Rostedt, Yonghong Song, bpf, linux-kernel, linux-trace-kernel, kafai, kpsingh, netdev, songliubraving, Ze Gao On Mon, 22 May 2023 23:59:28 -0700 "Paul E. McKenney" <paulmck@kernel.org> wrote: > On Tue, May 23, 2023 at 01:30:19PM +0800, Masami Hiramatsu wrote: > > On Mon, 22 May 2023 10:07:42 +0800 > > Ze Gao <zegao2021@gmail.com> wrote: > > > > > Oops, I missed that. Thanks for pointing that out, which I thought is > > > conditional use of rcu_is_watching before. > > > > > > One last point, I think we should double check on this > > > "fentry does not filter with !rcu_is_watching" > > > as quoted from Yonghong and argue whether it needs > > > the same check for fentry as well. > > > > rcu_is_watching() comment says; > > > > * if the current CPU is not in its idle loop or is in an interrupt or > > * NMI handler, return true. > > > > Thus it returns *fault* if the current CPU is in the idle loop and not > > any interrupt(including NMI) context. This means if any tracable function > > is called from idle loop, it can be !rcu_is_watching(). I meant, this is > > 'context' based check, thus fentry can not filter out that some commonly > > used functions is called from that context but it can be detected. > > It really does return false (rather than faulting?) if the current CPU > is deep within the idle loop. > > In addition, the recent x86/entry rework (thank you Peter and > Thomas!) mean that the "idle loop" is quite restricted, as can be > seen by the invocations of ct_cpuidle_enter() and ct_cpuidle_exit(). > For example, in default_idle_call(), these are immediately before and > after the call to arch_cpu_idle(). Thanks! I also found that the default_idle_call() is enough small and it seems not happening on fentry because there are no commonly used functions on that path. > > Would the following help? Or am I missing your point? Yes, thank you for the update! > > Thanx, Paul > > ------------------------------------------------------------------------ > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > index 1449cb69a0e0..fae9b4e29c93 100644 > --- a/kernel/rcu/tree.c > +++ b/kernel/rcu/tree.c > @@ -679,10 +679,14 @@ static void rcu_disable_urgency_upon_qs(struct rcu_data *rdp) > /** > * rcu_is_watching - see if RCU thinks that the current CPU is not idle > * > - * Return true if RCU is watching the running CPU, which means that this > - * CPU can safely enter RCU read-side critical sections. In other words, > - * if the current CPU is not in its idle loop or is in an interrupt or > - * NMI handler, return true. > + * Return @true if RCU is watching the running CPU and @false otherwise. > + * An @true return means that this CPU can safely enter RCU read-side > + * critical sections. > + * > + * More specifically, if the current CPU is not deep within its idle > + * loop, return @true. Note that rcu_is_watching() will return @true if > + * invoked from an interrupt or NMI handler, even if that interrupt or > + * NMI interrupted the CPU while it was deep within its idle loop. > * > * Make notrace because it can be called by the internal functions of > * ftrace, and making this notrace removes unnecessary recursion calls. -- Masami Hiramatsu (Google) <mhiramat@kernel.org> ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2023-05-20 9:47 ` Ze Gao 2023-05-21 3:58 ` Yonghong Song @ 2023-05-21 8:08 ` Jiri Olsa 2023-05-21 10:09 ` Re: Masami Hiramatsu 1 sibling, 1 reply; 1767+ messages in thread From: Jiri Olsa @ 2023-05-21 8:08 UTC (permalink / raw) To: Ze Gao Cc: Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, Hao Luo, John Fastabend, KP Singh, Martin KaFai Lau, Masami Hiramatsu, Song Liu, Stanislav Fomichev, Steven Rostedt, Yonghong Song, bpf, linux-kernel, linux-trace-kernel, kafai, kpsingh, netdev, paulmck, songliubraving, Ze Gao On Sat, May 20, 2023 at 05:47:24PM +0800, Ze Gao wrote: > > Hi Jiri, > > Would you like to consider to add rcu_is_watching check in > to solve this from the viewpoint of kprobe_multi_link_prog_run I think this was discussed in here: https://lore.kernel.org/bpf/20230321020103.13494-1-laoar.shao@gmail.com/ and was considered a bug, there's fix mentioned later in the thread there's also this recent patchset: https://lore.kernel.org/bpf/20230517034510.15639-3-zegao@tencent.com/ that solves related problems > itself? And accounting of missed runs can be added as well > to imporve observability. right, we count fprobe->nmissed but it's not exposed, we should allow to get 'missed' stats from both fprobe and kprobe_multi later, which is missing now, will check thanks, jirka > > Regards, > Ze > > > ----------------- > From 29fd3cd713e65461325c2703cf5246a6fae5d4fe Mon Sep 17 00:00:00 2001 > From: Ze Gao <zegao@tencent.com> > Date: Sat, 20 May 2023 17:32:05 +0800 > Subject: [PATCH] bpf: kprobe_multi runs bpf progs only when rcu_is_watching > > From the perspective of kprobe_multi_link_prog_run, any traceable > functions can be attached while bpf progs need specical care and > ought to be under rcu protection. To solve the likely rcu lockdep > warns once for good, when (future) functions in idle path were > attached accidentally, we better paying some cost to check at least > in kernel-side, and return when rcu is not watching, which helps > to avoid any unpredictable results. > > Signed-off-by: Ze Gao <zegao@tencent.com> > --- > kernel/trace/bpf_trace.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c > index 9a050e36dc6c..3e6ea7274765 100644 > --- a/kernel/trace/bpf_trace.c > +++ b/kernel/trace/bpf_trace.c > @@ -2622,7 +2622,7 @@ kprobe_multi_link_prog_run(struct bpf_kprobe_multi_link *link, > struct bpf_run_ctx *old_run_ctx; > int err; > > - if (unlikely(__this_cpu_inc_return(bpf_prog_active) != 1)) { > + if (unlikely(__this_cpu_inc_return(bpf_prog_active) != 1 || !rcu_is_watching())) { > err = 0; > goto out; > } > -- > 2.40.1 > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2023-05-21 8:08 ` Re: Jiri Olsa @ 2023-05-21 10:09 ` Masami Hiramatsu 2023-05-21 14:19 ` Re: Ze Gao 0 siblings, 1 reply; 1767+ messages in thread From: Masami Hiramatsu @ 2023-05-21 10:09 UTC (permalink / raw) To: Jiri Olsa Cc: Ze Gao, Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, Hao Luo, John Fastabend, KP Singh, Martin KaFai Lau, Masami Hiramatsu, Song Liu, Stanislav Fomichev, Steven Rostedt, Yonghong Song, bpf, linux-kernel, linux-trace-kernel, kafai, kpsingh, netdev, paulmck, songliubraving, Ze Gao On Sun, 21 May 2023 10:08:46 +0200 Jiri Olsa <olsajiri@gmail.com> wrote: > On Sat, May 20, 2023 at 05:47:24PM +0800, Ze Gao wrote: > > > > Hi Jiri, > > > > Would you like to consider to add rcu_is_watching check in > > to solve this from the viewpoint of kprobe_multi_link_prog_run > > I think this was discussed in here: > https://lore.kernel.org/bpf/20230321020103.13494-1-laoar.shao@gmail.com/ > > and was considered a bug, there's fix mentioned later in the thread > > there's also this recent patchset: > https://lore.kernel.org/bpf/20230517034510.15639-3-zegao@tencent.com/ > > that solves related problems I think this rcu_is_watching() is a bit different issue. This rcu_is_watching() check is required if the kprobe_multi_link_prog_run() uses any RCU API. E.g. rethook_try_get() is also checks rcu_is_watching() because it uses call_rcu(). Thank you, > > > itself? And accounting of missed runs can be added as well > > to imporve observability. > > right, we count fprobe->nmissed but it's not exposed, we should allow > to get 'missed' stats from both fprobe and kprobe_multi later, which > is missing now, will check > > thanks, > jirka > > > > > Regards, > > Ze > > > > > > ----------------- > > From 29fd3cd713e65461325c2703cf5246a6fae5d4fe Mon Sep 17 00:00:00 2001 > > From: Ze Gao <zegao@tencent.com> > > Date: Sat, 20 May 2023 17:32:05 +0800 > > Subject: [PATCH] bpf: kprobe_multi runs bpf progs only when rcu_is_watching > > > > From the perspective of kprobe_multi_link_prog_run, any traceable > > functions can be attached while bpf progs need specical care and > > ought to be under rcu protection. To solve the likely rcu lockdep > > warns once for good, when (future) functions in idle path were > > attached accidentally, we better paying some cost to check at least > > in kernel-side, and return when rcu is not watching, which helps > > to avoid any unpredictable results. > > > > Signed-off-by: Ze Gao <zegao@tencent.com> > > --- > > kernel/trace/bpf_trace.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c > > index 9a050e36dc6c..3e6ea7274765 100644 > > --- a/kernel/trace/bpf_trace.c > > +++ b/kernel/trace/bpf_trace.c > > @@ -2622,7 +2622,7 @@ kprobe_multi_link_prog_run(struct bpf_kprobe_multi_link *link, > > struct bpf_run_ctx *old_run_ctx; > > int err; > > > > - if (unlikely(__this_cpu_inc_return(bpf_prog_active) != 1)) { > > + if (unlikely(__this_cpu_inc_return(bpf_prog_active) != 1 || !rcu_is_watching())) { > > err = 0; > > goto out; > > } > > -- > > 2.40.1 > > -- Masami Hiramatsu (Google) <mhiramat@kernel.org> ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2023-05-21 10:09 ` Re: Masami Hiramatsu @ 2023-05-21 14:19 ` Ze Gao 0 siblings, 0 replies; 1767+ messages in thread From: Ze Gao @ 2023-05-21 14:19 UTC (permalink / raw) To: Masami Hiramatsu Cc: Jiri Olsa, Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, Hao Luo, John Fastabend, KP Singh, Martin KaFai Lau, Song Liu, Stanislav Fomichev, Steven Rostedt, Yonghong Song, bpf, linux-kernel, linux-trace-kernel, kafai, kpsingh, netdev, paulmck, songliubraving, Ze Gao On Sun, May 21, 2023 at 6:09 PM Masami Hiramatsu <mhiramat@kernel.org> wrote: > > On Sun, 21 May 2023 10:08:46 +0200 > Jiri Olsa <olsajiri@gmail.com> wrote: > > > On Sat, May 20, 2023 at 05:47:24PM +0800, Ze Gao wrote: > > > > > > Hi Jiri, > > > > > > Would you like to consider to add rcu_is_watching check in > > > to solve this from the viewpoint of kprobe_multi_link_prog_run > > > > I think this was discussed in here: > > https://lore.kernel.org/bpf/20230321020103.13494-1-laoar.shao@gmail.com/ > > > > and was considered a bug, there's fix mentioned later in the thread > > > > there's also this recent patchset: > > https://lore.kernel.org/bpf/20230517034510.15639-3-zegao@tencent.com/ > > > > that solves related problems > > I think this rcu_is_watching() is a bit different issue. This rcu_is_watching() > check is required if the kprobe_multi_link_prog_run() uses any RCU API. > E.g. rethook_try_get() is also checks rcu_is_watching() because it uses > call_rcu(). Yes, that's my point! Regards, Ze > > > > > > itself? And accounting of missed runs can be added as well > > > to imporve observability. > > > > right, we count fprobe->nmissed but it's not exposed, we should allow > > to get 'missed' stats from both fprobe and kprobe_multi later, which > > is missing now, will check > > > > thanks, > > jirka > > > > > > > > Regards, > > > Ze > > > > > > > > > ----------------- > > > From 29fd3cd713e65461325c2703cf5246a6fae5d4fe Mon Sep 17 00:00:00 2001 > > > From: Ze Gao <zegao@tencent.com> > > > Date: Sat, 20 May 2023 17:32:05 +0800 > > > Subject: [PATCH] bpf: kprobe_multi runs bpf progs only when rcu_is_watching > > > > > > From the perspective of kprobe_multi_link_prog_run, any traceable > > > functions can be attached while bpf progs need specical care and > > > ought to be under rcu protection. To solve the likely rcu lockdep > > > warns once for good, when (future) functions in idle path were > > > attached accidentally, we better paying some cost to check at least > > > in kernel-side, and return when rcu is not watching, which helps > > > to avoid any unpredictable results. > > > > > > Signed-off-by: Ze Gao <zegao@tencent.com> > > > --- > > > kernel/trace/bpf_trace.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c > > > index 9a050e36dc6c..3e6ea7274765 100644 > > > --- a/kernel/trace/bpf_trace.c > > > +++ b/kernel/trace/bpf_trace.c > > > @@ -2622,7 +2622,7 @@ kprobe_multi_link_prog_run(struct bpf_kprobe_multi_link *link, > > > struct bpf_run_ctx *old_run_ctx; > > > int err; > > > > > > - if (unlikely(__this_cpu_inc_return(bpf_prog_active) != 1)) { > > > + if (unlikely(__this_cpu_inc_return(bpf_prog_active) != 1 || !rcu_is_watching())) { > > > err = 0; > > > goto out; > > > } > > > -- > > > 2.40.1 > > > > > > -- > Masami Hiramatsu (Google) <mhiramat@kernel.org> ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH v3 00/60] target/arm: Cleanups, new features, new cpus
@ 2022-04-17 17:43 Richard Henderson
2022-04-17 17:43 ` [PATCH v3 06/60] target/arm: Change CPUArchState.aarch64 to bool Richard Henderson
0 siblings, 1 reply; 1767+ messages in thread
From: Richard Henderson @ 2022-04-17 17:43 UTC (permalink / raw)
To: qemu-devel; +Cc: qemu-arm
Supercedes: 20220412003326.588530-1-richard.henderson@linaro.org
("target/arm: 8 new features, A76 and N1")
Changes for v3:
* More field updates for H.a. This is not nearly complete, but what
I've encountered so far as I've begun implementing SME.
* Use bool instead of uint32_t for env->{aarch64,thumb}.
I had anticipated other changes for implementing PSTATE.{SM,FA},
but dropped those; these seemed like worth keeping.
* Use tcg_constant_* more -- got stuck on this while working on...
* Lots of cleanups to ARMCPRegInfo.
* Discard unreachable cpregs when ELx not available.
* Transform EL2 regs to RES0 when EL3 present but EL2 isn't.
This greatly simplifies registration of cpregs for new features.
Changes contextidr_el2, minimal_ras_reginfo, scxtnum_reginfo
within this patch set; other uses coming for SME.
r~
Richard Henderson (60):
tcg: Add tcg_constant_ptr
target/arm: Update ISAR fields for ARMv8.8
target/arm: Update SCR_EL3 bits to ARMv8.8
target/arm: Update SCTLR bits to ARMv9.2
target/arm: Change DisasContext.aarch64 to bool
target/arm: Change CPUArchState.aarch64 to bool
target/arm: Extend store_cpu_offset to take field size
target/arm: Change DisasContext.thumb to bool
target/arm: Change CPUArchState.thumb to bool
target/arm: Remove fpexc32_access
target/arm: Split out set_btype_raw
target/arm: Split out gen_rebuild_hflags
target/arm: Use tcg_constant in translate-a64.c
target/arm: Simplify GEN_SHIFT in translate.c
target/arm: Simplify gen_sar
target/arm: Simplify aa32 DISAS_WFI
target/arm: Use tcg_constant in translate.c
target/arm: Use tcg_constant in translate-m-nocp.c
target/arm: Use tcg_constant in translate-neon.c
target/arm: Use smin/smax for do_sat_addsub_32
target/arm: Use tcg_constant in translate-sve.c
target/arm: Use tcg_constant in translate-vfp.c
target/arm: Use tcg_constant_i32 in translate.h
target/arm: Split out cpregs.h
target/arm: Reorg CPAccessResult and access_check_cp_reg
target/arm: Replace sentinels with ARRAY_SIZE in cpregs.h
target/arm: Make some more cpreg data static const
target/arm: Reorg ARMCPRegInfo type field bits
target/arm: Change cpreg access permissions to enum
target/arm: Name CPState type
target/arm: Name CPSecureState type
target/arm: Update sysreg fields when redirecting for E2H
target/arm: Store cpregs key in the hash table directly
target/arm: Cleanup add_cpreg_to_hashtable
target/arm: Handle cpreg registration for missing EL
target/arm: Drop EL3 no EL2 fallbacks
target/arm: Merge zcr reginfo
target/arm: Add isar predicates for FEAT_Debugv8p2
target/arm: Adjust definition of CONTEXTIDR_EL2
target/arm: Move cortex impdef sysregs to cpu_tcg.c
target/arm: Update qemu-system-arm -cpu max to cortex-a57
target/arm: Set ID_DFR0.PerfMon for qemu-system-arm -cpu max
target/arm: Split out aa32_max_features
target/arm: Annotate arm_max_initfn with FEAT identifiers
target/arm: Use field names for manipulating EL2 and EL3 modes
target/arm: Enable FEAT_Debugv8p2 for -cpu max
target/arm: Enable FEAT_Debugv8p4 for -cpu max
target/arm: Add isar_feature_{aa64,any}_ras
target/arm: Add minimal RAS registers
target/arm: Enable SCR and HCR bits for RAS
target/arm: Implement virtual SError exceptions
target/arm: Implement ESB instruction
target/arm: Enable FEAT_RAS for -cpu max
target/arm: Enable FEAT_IESB for -cpu max
target/arm: Enable FEAT_CSV2 for -cpu max
target/arm: Enable FEAT_CSV2_2 for -cpu max
target/arm: Enable FEAT_CSV3 for -cpu max
target/arm: Enable FEAT_DGH for -cpu max
target/arm: Define cortex-a76
target/arm: Define neoverse-n1
docs/system/arm/emulation.rst | 10 +
docs/system/arm/virt.rst | 2 +
include/tcg/tcg.h | 2 +
target/arm/cpregs.h | 459 +++++++++++++++++
target/arm/cpu.h | 475 ++++--------------
target/arm/helper.h | 1 +
target/arm/internals.h | 16 +
target/arm/syndrome.h | 5 +
target/arm/translate-a32.h | 13 +-
target/arm/translate.h | 17 +-
target/arm/a32.decode | 16 +-
target/arm/t32.decode | 18 +-
hw/arm/pxa2xx.c | 2 +-
hw/arm/pxa2xx_pic.c | 2 +-
hw/arm/sbsa-ref.c | 2 +
hw/arm/virt.c | 2 +
hw/intc/arm_gicv3_cpuif.c | 6 +-
hw/intc/arm_gicv3_kvm.c | 3 +-
linux-user/arm/cpu_loop.c | 2 +-
target/arm/cpu.c | 88 ++--
target/arm/cpu64.c | 349 +++++++------
target/arm/cpu_tcg.c | 232 ++++++---
target/arm/gdbstub.c | 5 +-
target/arm/helper-a64.c | 4 +-
target/arm/helper.c | 897 ++++++++++++++++++----------------
target/arm/hvf/hvf.c | 2 +-
target/arm/m_helper.c | 6 +-
target/arm/op_helper.c | 113 +++--
target/arm/translate-a64.c | 395 ++++++---------
target/arm/translate-m-nocp.c | 12 +-
target/arm/translate-neon.c | 21 +-
target/arm/translate-sve.c | 207 +++-----
target/arm/translate-vfp.c | 76 +--
target/arm/translate.c | 400 +++++++--------
34 files changed, 2026 insertions(+), 1834 deletions(-)
create mode 100644 target/arm/cpregs.h
--
2.25.1
^ permalink raw reply [flat|nested] 1767+ messages in thread* [PATCH v3 06/60] target/arm: Change CPUArchState.aarch64 to bool 2022-04-17 17:43 [PATCH v3 00/60] target/arm: Cleanups, new features, new cpus Richard Henderson @ 2022-04-17 17:43 ` Richard Henderson 2022-04-19 11:17 ` Alex Bennée 0 siblings, 1 reply; 1767+ messages in thread From: Richard Henderson @ 2022-04-17 17:43 UTC (permalink / raw) To: qemu-devel; +Cc: qemu-arm Bool is a more appropriate type for this value. Adjust the assignments to use true/false. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> --- target/arm/cpu.h | 2 +- target/arm/cpu.c | 2 +- target/arm/helper-a64.c | 4 ++-- target/arm/helper.c | 2 +- target/arm/hvf/hvf.c | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/target/arm/cpu.h b/target/arm/cpu.h index 9ae9c935a2..a61a52e2f6 100644 --- a/target/arm/cpu.h +++ b/target/arm/cpu.h @@ -258,7 +258,7 @@ typedef struct CPUArchState { * all other bits are stored in their correct places in env->pstate */ uint32_t pstate; - uint32_t aarch64; /* 1 if CPU is in aarch64 state; inverse of PSTATE.nRW */ + bool aarch64; /* True if CPU is in aarch64 state; inverse of PSTATE.nRW */ /* Cached TBFLAGS state. See below for which bits are included. */ CPUARMTBFlags hflags; diff --git a/target/arm/cpu.c b/target/arm/cpu.c index 5d4ca7a227..30e0d16ad4 100644 --- a/target/arm/cpu.c +++ b/target/arm/cpu.c @@ -189,7 +189,7 @@ static void arm_cpu_reset(DeviceState *dev) if (arm_feature(env, ARM_FEATURE_AARCH64)) { /* 64 bit CPUs always start in 64 bit mode */ - env->aarch64 = 1; + env->aarch64 = true; #if defined(CONFIG_USER_ONLY) env->pstate = PSTATE_MODE_EL0t; /* Userspace expects access to DC ZVA, CTL_EL0 and the cache ops */ diff --git a/target/arm/helper-a64.c b/target/arm/helper-a64.c index 7cf953b1e6..77a8502b6b 100644 --- a/target/arm/helper-a64.c +++ b/target/arm/helper-a64.c @@ -952,7 +952,7 @@ void HELPER(exception_return)(CPUARMState *env, uint64_t new_pc) qemu_mutex_unlock_iothread(); if (!return_to_aa64) { - env->aarch64 = 0; + env->aarch64 = false; /* We do a raw CPSR write because aarch64_sync_64_to_32() * will sort the register banks out for us, and we've already * caught all the bad-mode cases in el_from_spsr(). @@ -975,7 +975,7 @@ void HELPER(exception_return)(CPUARMState *env, uint64_t new_pc) } else { int tbii; - env->aarch64 = 1; + env->aarch64 = true; spsr &= aarch64_pstate_valid_mask(&env_archcpu(env)->isar); pstate_write(env, spsr); if (!arm_singlestep_active(env)) { diff --git a/target/arm/helper.c b/target/arm/helper.c index 7d14650615..47fe790854 100644 --- a/target/arm/helper.c +++ b/target/arm/helper.c @@ -10182,7 +10182,7 @@ static void arm_cpu_do_interrupt_aarch64(CPUState *cs) } pstate_write(env, PSTATE_DAIF | new_mode); - env->aarch64 = 1; + env->aarch64 = true; aarch64_restore_sp(env, new_el); helper_rebuild_hflags_a64(env, new_el); diff --git a/target/arm/hvf/hvf.c b/target/arm/hvf/hvf.c index 8c34f86792..11176ef252 100644 --- a/target/arm/hvf/hvf.c +++ b/target/arm/hvf/hvf.c @@ -565,7 +565,7 @@ int hvf_arch_init_vcpu(CPUState *cpu) hv_return_t ret; int i; - env->aarch64 = 1; + env->aarch64 = true; asm volatile("mrs %0, cntfrq_el0" : "=r"(arm_cpu->gt_cntfrq_hz)); /* Allocate enough space for our sysreg sync */ -- 2.25.1 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2022-04-17 17:43 ` [PATCH v3 06/60] target/arm: Change CPUArchState.aarch64 to bool Richard Henderson @ 2022-04-19 11:17 ` Alex Bennée 0 siblings, 0 replies; 1767+ messages in thread From: Alex Bennée @ 2022-04-19 11:17 UTC (permalink / raw) To: Richard Henderson; +Cc: qemu-devel, qemu-arm Richard Henderson <richard.henderson@linaro.org> writes: > Bool is a more appropriate type for this value. > Adjust the assignments to use true/false. > > Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> -- Alex Bennée ^ permalink raw reply [flat|nested] 1767+ messages in thread
* rcu_sched self-detected stall on CPU
@ 2022-04-05 21:41 Miguel Ojeda
2022-04-06 9:31 ` Zhouyi Zhou
0 siblings, 1 reply; 1767+ messages in thread
From: Miguel Ojeda @ 2022-04-05 21:41 UTC (permalink / raw)
To: linuxppc-dev, rcu
[-- Attachment #1: Type: text/plain, Size: 400 bytes --]
Hi PPC/RCU,
While merging v5.18-rc1 changes I noticed our CI PPC runs broke. I
reproduced the problem in v5.18-rc1 as well as next-20220405, under
both QEMU 4.2.1 and 6.1.0, with `-smp 2`; but I cannot reproduce it in
v5.17 from a few tries.
Sadly, the problem is not deterministic although it is not too hard to
reproduce (1 out of 5?). Please see attached config and QEMU output.
Cheers,
Miguel
[-- Attachment #2: qemu --]
[-- Type: application/octet-stream, Size: 20395 bytes --]
# qemu-system-ppc64 -kernel vmlinux -nographic -vga none -no-reboot -smp 2
qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-cfpc=workaround
qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-sbbc=workaround
qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-ibs=workaround
SLOF **********************************************************************
QEMU Starting
Build Date = Jan 31 2020 20:27:09
FW Version = buildd@ release 20191209
Press "s" to enter Open Firmware.
Populating /vdevice methods
Populating /vdevice/vty@71000000
Populating /vdevice/nvram@71000001
Populating /vdevice/l-lan@71000002
Populating /vdevice/v-scsi@71000003
SCSI: Looking for devices
8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+"
Populating /pci@800000020000000
No NVRAM common partition, re-initializing...
Scanning USB
Using default console: /vdevice/vty@71000000
Detected RAM kernel at 400000 (121f8f0 bytes)
Welcome to Open Firmware
Copyright (c) 2004, 2017 IBM Corporation All rights reserved.
This program and the accompanying materials are made available
under the terms of the BSD License available at
http://www.opensource.org/licenses/bsd-license.php
Booting from memory...
OF stdout device is: /vdevice/vty@71000000
Preparing to boot Linux version 5.18.0-rc1 (root@test) (powerpc64le-linux-gnu-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #2 SMP Tue Apr 5 21:09:40 UTC 2022
Detected machine type: 0000000000000101
command line:
Max number of cores passed to firmware: 2 (NR_CPUS = 2)
Calling ibm,client-architecture-support...qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-cfpc=workaround
qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-sbbc=workaround
qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-ibs=workaround
SLOF **********************************************************************
QEMU Starting
Build Date = Jan 31 2020 20:27:09
FW Version = buildd@ release 20191209
Press "s" to enter Open Firmware.
Populating /vdevice methods
Populating /vdevice/vty@71000000
Populating /vdevice/nvram@71000001
Populating /vdevice/l-lan@71000002
Populating /vdevice/v-scsi@71000003
SCSI: Looking for devices
8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+"
Populating /pci@800000020000000
Scanning USB
Using default console: /vdevice/vty@71000000
Detected RAM kernel at 400000 (121f8f0 bytes)
Welcome to Open Firmware
Copyright (c) 2004, 2017 IBM Corporation All rights reserved.
This program and the accompanying materials are made available
under the terms of the BSD License available at
http://www.opensource.org/licenses/bsd-license.php
Booting from memory...
OF stdout device is: /vdevice/vty@71000000
Preparing to boot Linux version 5.18.0-rc1 (root@test) (powerpc64le-linux-gnu-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #2 SMP Tue Apr 5 21:09:40 UTC 2022
Detected machine type: 0000000000000101
command line:
Max number of cores passed to firmware: 2 (NR_CPUS = 2)
Calling ibm,client-architecture-support... done
memory layout at init:
memory_limit : 0000000000000000 (16 MB aligned)
alloc_bottom : 0000000001630000
alloc_top : 0000000020000000
alloc_top_hi : 0000000020000000
rmo_top : 0000000020000000
ram_top : 0000000020000000
instantiating rtas at 0x000000001fff0000... done
prom_hold_cpus: skipped
copying OF device tree...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000001640000 -> 0x0000000001640a77
Device tree struct 0x0000000001650000 -> 0x0000000001660000
Quiescing Open Firmware ...
Booting Linux via __start() @ 0x0000000000400000 ...
[ 0.000000] radix-mmu: Page sizes from device-tree:
[ 0.000000] radix-mmu: Page size shift = 12 AP=0x0
[ 0.000000] radix-mmu: Page size shift = 16 AP=0x5
[ 0.000000] radix-mmu: Page size shift = 21 AP=0x1
[ 0.000000] radix-mmu: Page size shift = 30 AP=0x2
[ 0.000000] Activating Kernel Userspace Access Prevention
[ 0.000000] Activating Kernel Userspace Execution Prevention
[ 0.000000] radix-mmu: Mapped 0x0000000000000000-0x0000000001200000 with 2.00 MiB pages (exec)
[ 0.000000] radix-mmu: Mapped 0x0000000001200000-0x0000000020000000 with 2.00 MiB pages
[ 0.000000] lpar: Using radix MMU under hypervisor
[ 0.000000] Linux version 5.18.0-rc1 (root@test) (powerpc64le-linux-gnu-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #2 SMP Tue Apr 5 21:09:40 UTC 2022
[ 0.000000] Using pSeries machine description
[ 0.000000] printk: bootconsole [udbg0] enabled
[ 0.000000] Partition configured for 2 cpus.
[ 0.000000] CPU maps initialized for 1 thread per core
[ 0.000000] -----------------------------------------------------
[ 0.000000] phys_mem_size = 0x20000000
[ 0.000000] dcache_bsize = 0x80
[ 0.000000] icache_bsize = 0x80
[ 0.000000] cpu_features = 0x0001c06b8f4f9187
[ 0.000000] possible = 0x000ffbebcf5fb187
[ 0.000000] always = 0x0000006b8b5c9181
[ 0.000000] cpu_user_features = 0xdc0065c2 0xaef00000
[ 0.000000] mmu_features = 0x3c007641
[ 0.000000] firmware_features = 0x00000085455a445f
[ 0.000000] vmalloc start = 0xc008000000000000
[ 0.000000] IO start = 0xc00a000000000000
[ 0.000000] vmemmap start = 0xc00c000000000000
[ 0.000000] -----------------------------------------------------
[ 0.000000] rfi-flush: fallback displacement flush available
[ 0.000000] rfi-flush: ori type flush available
[ 0.000000] rfi-flush: mttrig type flush available
[ 0.000000] count-cache-flush: software flush enabled.
[ 0.000000] link-stack-flush: software flush enabled.
[ 0.000000] stf-barrier: eieio barrier available
[ 0.000000] PPC64 nvram contains 65536 bytes
[ 0.000000] PV qspinlock hash table entries: 4096 (order: 0, 65536 bytes, linear)
[ 0.000000] barrier-nospec: using ORI speculation barrier
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000000000000-0x000000001fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x000000001fffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000001fffffff]
[ 0.000000] percpu: Embedded 2 pages/cpu s32544 r0 d98528 u131072
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 8185
[ 0.000000] Kernel command line:
[ 0.000000] Dentry cache hash table entries: 65536 (order: 3, 524288 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 32768 (order: 2, 262144 bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:on, heap free:on
[ 0.000000] mem auto-init: clearing system memory may take some time...
[ 0.000000] Memory: 418560K/524288K available (4096K kernel code, 704K rwdata, 768K rodata, 1024K init, 446K bss, 105728K reserved, 0K cma-reserved)
[ 0.000000] random: get_random_u64 called from __kmem_cache_create+0x34/0x520 with crng_init=0
[ 0.000000] SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 100 jiffies.
[ 0.000000] NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
[ 0.000000] xive: Using IRQ range [0-1]
[ 0.000000] xive: Interrupt handling initialized with spapr backend
[ 0.000000] xive: Using priority 6 for all interrupts
[ 0.000000] xive: Using 64kB queues
[ 0.000061] time_init: 56 bit decrementer (max: 7fffffffffffff)
[ 0.000505] clocksource: timebase: mask: 0xffffffffffffffff max_cycles: 0x761537d007, max_idle_ns: 440795202126 ns
[ 0.000999] clocksource: timebase mult[1f40000] shift[24] registered
[ 0.007895] Console: colour dummy device 80x25
[ 0.008493] printk: console [hvc0] enabled
[ 0.008493] printk: console [hvc0] enabled
[ 0.010438] printk: bootconsole [udbg0] disabled
[ 0.010438] printk: bootconsole [udbg0] disabled
[ 0.011696] pid_max: default: 32768 minimum: 301
[ 0.012503] Mount-cache hash table entries: 8192 (order: 0, 65536 bytes, linear)
[ 0.012575] Mountpoint-cache hash table entries: 8192 (order: 0, 65536 bytes, linear)
[ 0.041799] POWER9 performance monitor hardware support registered
[ 0.042735] rcu: Hierarchical SRCU implementation.
[ 0.045220] smp: Bringing up secondary CPUs ...
[ 0.066059] smp: Brought up 1 node, 2 CPUs
[ 0.093530] devtmpfs: initialized
[ 0.100032] PCI host bridge /pci@800000020000000 ranges:
[ 0.100607] IO 0x0000200000000000..0x000020000000ffff -> 0x0000000000000000
[ 0.100734] MEM 0x0000200080000000..0x00002000ffffffff -> 0x0000000080000000
[ 0.100805] MEM 0x0000210000000000..0x000021ffffffffff -> 0x0000210000000000
[ 0.101744] PCI: OF: PROBE_ONLY disabled
[ 0.102198] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
[ 0.102371] futex hash table entries: 512 (order: 0, 65536 bytes, linear)
Linux ppc64le
#2 SMP Tue Apr 5[ 0.110196] EEH: pSeries platform initialized
[ 0.115987] software IO TLB: tearing down default memory pool
[ 0.134293] PCI: Probing PCI hardware
[ 0.136684] PCI host bridge to bus 0000:00
[ 0.136999] pci_bus 0000:00: root bus resource [io 0x10000-0x1ffff] (bus address [0x0000-0xffff])
[ 0.137449] pci_bus 0000:00: root bus resource [mem 0x200080000000-0x2000ffffffff] (bus address [0x80000000-0xffffffff])
[ 0.137535] pci_bus 0000:00: root bus resource [mem 0x210000000000-0x21ffffffffff 64bit]
[ 0.137720] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 0.142416] IOMMU table initialized, virtual merging enabled
[ 0.143475] pci_bus 0000:00: resource 4 [io 0x10000-0x1ffff]
[ 0.143541] pci_bus 0000:00: resource 5 [mem 0x200080000000-0x2000ffffffff]
[ 0.143575] pci_bus 0000:00: resource 6 [mem 0x210000000000-0x21ffffffffff 64bit]
[ 0.143754] EEH: No capable adapters found: recovery disabled.
[ 0.166254] vgaarb: loaded
[ 0.168227] clocksource: Switched to clocksource timebase
[ 0.182817] PCI: CLS 0 bytes, default 128
[ 1.790625] workingset: timestamp_bits=62 max_order=13 bucket_order=0
[ 21.186912] rcu: INFO: rcu_sched self-detected stall on CPU
[ 21.187331] rcu: 1-...!: (4712629 ticks this GP) idle=2c1/0/0x3 softirq=8/8 fqs=0
[ 21.187529] (t=21000 jiffies g=-1183 q=3)
[ 21.187681] rcu: rcu_sched kthread timer wakeup didn't happen for 20997 jiffies! g-1183 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
[ 21.187770] rcu: Possible timer handling issue on cpu=1 timer-softirq=1
[ 21.187927] rcu: rcu_sched kthread starved for 21001 jiffies! g-1183 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=1
[ 21.188019] rcu: Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.
[ 21.188087] rcu: RCU grace-period kthread stack dump:
[ 21.188196] task:rcu_sched state:I stack: 0 pid: 10 ppid: 2 flags:0x00000800
[ 21.188453] Call Trace:
[ 21.188525] [c0000000061e78a0] [c0000000061e78e0] 0xc0000000061e78e0 (unreliable)
[ 21.188900] [c0000000061e7a90] [c000000000017210] __switch_to+0x250/0x310
[ 21.189210] [c0000000061e7b00] [c0000000003ed660] __schedule+0x210/0x660
[ 21.189315] [c0000000061e7b80] [c0000000003edb14] schedule+0x64/0x110
[ 21.189387] [c0000000061e7bb0] [c0000000003f6648] schedule_timeout+0x1d8/0x390
[ 21.189473] [c0000000061e7c80] [c00000000011111c] rcu_gp_fqs_loop+0x2dc/0x3d0
[ 21.189555] [c0000000061e7d30] [c0000000001144ec] rcu_gp_kthread+0x13c/0x160
[ 21.189633] [c0000000061e7dc0] [c0000000000c1770] kthread+0x110/0x120
[ 21.189714] [c0000000061e7e10] [c00000000000c9e4] ret_from_kernel_thread+0x5c/0x64
[ 21.189938] rcu: Stack dump where RCU GP kthread last ran:
[ 21.189992] Task dump for CPU 1:
[ 21.190059] task:swapper/1 state:R running task stack: 0 pid: 0 ppid: 1 flags:0x00000804
[ 21.190169] Call Trace:
[ 21.190194] [c0000000061ef2d0] [c0000000000c9a40] sched_show_task+0x180/0x1c0 (unreliable)
[ 21.190278] [c0000000061ef340] [c000000000116ca0] rcu_check_gp_kthread_starvation+0x16c/0x19c
[ 21.190370] [c0000000061ef3c0] [c000000000114f7c] rcu_sched_clock_irq+0x7ec/0xaf0
[ 21.190448] [c0000000061ef4b0] [c000000000120fdc] update_process_times+0xbc/0x140
[ 21.190524] [c0000000061ef4f0] [c000000000136a24] tick_nohz_handler+0xf4/0x1b0
[ 21.190608] [c0000000061ef540] [c00000000001c828] timer_interrupt+0x148/0x2d0
[ 21.190699] [c0000000061ef590] [c0000000000098e8] decrementer_common_virt+0x208/0x210
[ 21.190837] --- interrupt: 900 at arch_local_irq_restore+0x168/0x170
[ 21.190941] NIP: c000000000013608 LR: c0000000003f8114 CTR: c0000000000dc630
[ 21.191031] REGS: c0000000061ef600 TRAP: 0900 Not tainted (5.18.0-rc1)
[ 21.191109] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22000202 XER: 00000000
[ 21.191274] CFAR: 0000000000000000 IRQMASK: 0
[ 21.191274] GPR00: c00000000009c368 c0000000061ef8a0 c00000000116a700 0000000000000000
[ 21.191274] GPR04: 0000000000000000 0000000000000000 000000001ee30000 ffffffffffffffff
[ 21.191274] GPR08: 000000001ee30000 0000000000000000 0000000000008002 7265677368657265
[ 21.191274] GPR12: c0000000000dc630 c00000001ffe5800 0000000000000000 0000000000000000
[ 21.191274] GPR16: 0000000000000282 0000000000000000 0000000000000000 c0000000061eff00
[ 21.191274] GPR20: 0000000000000000 0000000000000001 c0000000061b9f80 c000000001195a10
[ 21.191274] GPR24: c000000001193a00 00000000fffb6cc4 000000000000000a c0000000010721e8
[ 21.191274] GPR28: c000000001076800 c000000001070380 c0000000010716d8 c0000000061b9f80
[ 21.191932] NIP [c000000000013608] arch_local_irq_restore+0x168/0x170
[ 21.192024] LR [c0000000003f8114] __do_softirq+0xd4/0x2ec
[ 21.192118] --- interrupt: 900
[ 21.192158] [c0000000061ef8a0] [c0000000061b9f80] 0xc0000000061b9f80 (unreliable)
[ 21.192227] [c0000000061ef9b0] [c00000000009c368] irq_exit+0xc8/0x110
[ 21.192307] [c0000000061ef9d0] [c00000000001c858] timer_interrupt+0x178/0x2d0
[ 21.192397] [c0000000061efa20] [c0000000000098e8] decrementer_common_virt+0x208/0x210
[ 21.192495] --- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c
[ 21.192566] NIP: c000000000072988 LR: c000000000074fa8 CTR: c000000000074f10
[ 21.192615] REGS: c0000000061efa90 TRAP: 0900 Not tainted (5.18.0-rc1)
[ 21.192659] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28000202 XER: 00000000
[ 21.192755] CFAR: 0000000000000000 IRQMASK: 0
[ 21.192755] GPR00: 0000000028000202 c0000000061efd30 c00000000116a700 0000000000000000
[ 21.192755] GPR04: c00000001fea0280 ffffffffffffffff 0000000001f40000 000000019d088fcf
[ 21.192755] GPR08: 000000001ee30000 c00000001ffe5400 0000000000000001 0000000100000000
[ 21.192755] GPR12: c000000000074f10 c00000001ffe5800 0000000000000000 0000000000000000
[ 21.192755] GPR16: 0000000000000000 0000000000000000 0000000000000000 c0000000061eff00
[ 21.192755] GPR20: c00000000003d440 0000000000000001 c000000001195b30 c000000001195a10
[ 21.192755] GPR24: 0000000000080000 c0000000061ba000 c000000001195a98 0000000000000001
[ 21.192755] GPR28: 0000000000000001 c0000000010716d0 c0000000010716d8 c0000000010716d0
[ 21.193290] NIP [c000000000072988] plpar_hcall_norets_notrace+0x18/0x2c
[ 21.193363] LR [c000000000074fa8] pseries_lpar_idle+0x98/0x1b0
[ 21.193428] --- interrupt: 900
[ 21.193457] [c0000000061efd30] [0000000000000001] 0x1 (unreliable)
[ 21.193512] [c0000000061efdb0] [c000000000018b54] arch_cpu_idle+0x44/0x180
[ 21.193590] [c0000000061efde0] [c0000000003f75bc] default_idle_call+0x4c/0x7c
[ 21.193679] [c0000000061efe00] [c0000000000e1384] do_idle+0x114/0x1e0
[ 21.193747] [c0000000061efe60] [c0000000000e1664] cpu_startup_entry+0x34/0x40
[ 21.193901] [c0000000061efe90] [c00000000003f044] start_secondary+0x624/0xa00
[ 21.194002] [c0000000061eff90] [c00000000000cd54] start_secondary_prolog+0x10/0x14
[ 21.194245] Task dump for CPU 1:
[ 21.194284] task:swapper/1 state:R running task stack: 0 pid: 0 ppid: 1 flags:0x00000804
[ 21.194374] Call Trace:
[ 21.194400] [c0000000061ef2b0] [c0000000000c9a40] sched_show_task+0x180/0x1c0 (unreliable)
[ 21.194479] [c0000000061ef320] [c000000000116df8] rcu_dump_cpu_stacks+0x128/0x188
[ 21.194567] [c0000000061ef3c0] [c000000000114f9c] rcu_sched_clock_irq+0x80c/0xaf0
[ 21.194642] [c0000000061ef4b0] [c000000000120fdc] update_process_times+0xbc/0x140
[ 21.194712] [c0000000061ef4f0] [c000000000136a24] tick_nohz_handler+0xf4/0x1b0
[ 21.194828] [c0000000061ef540] [c00000000001c828] timer_interrupt+0x148/0x2d0
[ 21.194942] [c0000000061ef590] [c0000000000098e8] decrementer_common_virt+0x208/0x210
[ 21.195035] --- interrupt: 900 at arch_local_irq_restore+0x168/0x170
[ 21.195104] NIP: c000000000013608 LR: c0000000003f8114 CTR: c0000000000dc630
[ 21.195152] REGS: c0000000061ef600 TRAP: 0900 Not tainted (5.18.0-rc1)
[ 21.195199] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22000202 XER: 00000000
[ 21.195296] CFAR: 0000000000000000 IRQMASK: 0
[ 21.195296] GPR00: c00000000009c368 c0000000061ef8a0 c00000000116a700 0000000000000000
[ 21.195296] GPR04: 0000000000000000 0000000000000000 000000001ee30000 ffffffffffffffff
[ 21.195296] GPR08: 000000001ee30000 0000000000000000 0000000000008002 7265677368657265
[ 21.195296] GPR12: c0000000000dc630 c00000001ffe5800 0000000000000000 0000000000000000
[ 21.195296] GPR16: 0000000000000282 0000000000000000 0000000000000000 c0000000061eff00
[ 21.195296] GPR20: 0000000000000000 0000000000000001 c0000000061b9f80 c000000001195a10
[ 21.195296] GPR24: c000000001193a00 00000000fffb6cc4 000000000000000a c0000000010721e8
[ 21.195296] GPR28: c000000001076800 c000000001070380 c0000000010716d8 c0000000061b9f80
[ 21.195850] NIP [c000000000013608] arch_local_irq_restore+0x168/0x170
[ 21.195944] LR [c0000000003f8114] __do_softirq+0xd4/0x2ec
[ 21.196027] --- interrupt: 900
[ 21.196056] [c0000000061ef8a0] [c0000000061b9f80] 0xc0000000061b9f80 (unreliable)
[ 21.196119] [c0000000061ef9b0] [c00000000009c368] irq_exit+0xc8/0x110
[ 21.196192] [c0000000061ef9d0] [c00000000001c858] timer_interrupt+0x178/0x2d0
[ 21.196282] [c0000000061efa20] [c0000000000098e8] decrementer_common_virt+0x208/0x210
[ 21.196373] --- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c
[ 21.196439] NIP: c000000000072988 LR: c000000000074fa8 CTR: c000000000074f10
[ 21.196489] REGS: c0000000061efa90 TRAP: 0900 Not tainted (5.18.0-rc1)
[ 21.196534] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28000202 XER: 00000000
[ 21.196627] CFAR: 0000000000000000 IRQMASK: 0
[ 21.196627] GPR00: 0000000028000202 c0000000061efd30 c00000000116a700 0000000000000000
[ 21.196627] GPR04: c00000001fea0280 ffffffffffffffff 0000000001f40000 000000019d088fcf
[ 21.196627] GPR08: 000000001ee30000 c00000001ffe5400 0000000000000001 0000000100000000
[ 21.196627] GPR12: c000000000074f10 c00000001ffe5800 0000000000000000 0000000000000000
[ 21.196627] GPR16: 0000000000000000 0000000000000000 0000000000000000 c0000000061eff00
[ 21.196627] GPR20: c00000000003d440 0000000000000001 c000000001195b30 c000000001195a10
[ 21.196627] GPR24: 0000000000080000 c0000000061ba000 c000000001195a98 0000000000000001
[ 21.196627] GPR28: 0000000000000001 c0000000010716d0 c0000000010716d8 c0000000010716d0
[ 21.197168] NIP [c000000000072988] plpar_hcall_norets_notrace+0x18/0x2c
[ 21.197239] LR [c000000000074fa8] pseries_lpar_idle+0x98/0x1b0
[ 21.197305] --- interrupt: 900
[ 21.197333] [c0000000061efd30] [0000000000000001] 0x1 (unreliable)
[ 21.197390] [c0000000061efdb0] [c000000000018b54] arch_cpu_idle+0x44/0x180
[ 21.197470] [c0000000061efde0] [c0000000003f75bc] default_idle_call+0x4c/0x7c
[ 21.197556] [c0000000061efe00] [c0000000000e1384] do_idle+0x114/0x1e0
[ 21.197620] [c0000000061efe60] [c0000000000e1664] cpu_startup_entry+0x34/0x40
[ 21.197696] [c0000000061efe90] [c00000000003f044] start_secondary+0x624/0xa00
[ 21.197820] [c0000000061eff90] [c00000000000cd54] start_secondary_prolog+0x10/0x14
[-- Attachment #3: config --]
[-- Type: application/octet-stream, Size: 35266 bytes --]
#
# Automatically generated file; DO NOT EDIT.
# Linux/powerpc 5.18.0-rc1 Kernel Configuration
#
CONFIG_CC_VERSION_TEXT="powerpc64le-linux-gnu-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0"
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=90400
CONFIG_CLANG_VERSION=0
CONFIG_AS_IS_GNU=y
CONFIG_AS_VERSION=23400
CONFIG_LD_IS_BFD=y
CONFIG_LD_VERSION=23400
CONFIG_LLD_VERSION=0
CONFIG_CC_CAN_LINK=y
CONFIG_CC_CAN_LINK_STATIC=y
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CC_HAS_ASM_INLINE=y
CONFIG_CC_HAS_NO_PROFILE_FN_ATTR=y
CONFIG_PAHOLE_VERSION=0
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_TABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_WERROR=y
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_XZ is not set
CONFIG_DEFAULT_INIT=""
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
# CONFIG_WATCH_QUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
# CONFIG_USELIB is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# end of IRQ subsystem
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_ARCH_HAS_TICK_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
# end of Timers subsystem
CONFIG_HAVE_EBPF_JIT=y
#
# BPF subsystem
#
# CONFIG_BPF_SYSCALL is not set
# end of BPF subsystem
CONFIG_PREEMPT_VOLUNTARY_BUILD=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
# CONFIG_SCHED_CORE is not set
#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_PSI is not set
# end of CPU/Task time and stats accounting
CONFIG_CPU_ISOLATION=y
#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
# end of RCU Subsystem
# CONFIG_IKCONFIG is not set
# CONFIG_IKHEADERS is not set
CONFIG_LOG_BUF_SHIFT=16
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
#
# Scheduler features
#
# end of Scheduler features
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_CC_HAS_INT128=y
CONFIG_CC_IMPLICIT_FALLTHROUGH="-Wimplicit-fallthrough=5"
# CONFIG_CGROUPS is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
CONFIG_TIME_NS=y
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_RD_GZIP is not set
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
# CONFIG_RD_ZSTD is not set
# CONFIG_BOOT_CONFIG is not set
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION=y
CONFIG_LD_ORPHAN_WARN=y
CONFIG_SYSCTL=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
# CONFIG_EXPERT is not set
CONFIG_MULTIUSER=y
CONFIG_SGETMASK_SYSCALL=y
CONFIG_SYSFS_SYSCALL=y
CONFIG_FHANDLE=y
CONFIG_POSIX_TIMERS=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_FUTEX_PI=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_IO_URING=y
CONFIG_ADVISE_SYSCALLS=y
CONFIG_MEMBARRIER=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_BASE_RELATIVE=y
# CONFIG_USERFAULTFD is not set
CONFIG_ARCH_HAS_MEMBARRIER_CALLBACKS=y
CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE=y
CONFIG_RSEQ=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# end of Kernel Performance Events And Counters
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLAB_MERGE_DEFAULT is not set
# CONFIG_SLAB_FREELIST_RANDOM is not set
CONFIG_SLAB_FREELIST_HARDENED=y
# CONFIG_SHUFFLE_PAGE_ALLOCATOR is not set
CONFIG_SLUB_CPU_PARTIAL=y
# CONFIG_PROFILING is not set
# end of General setup
CONFIG_PPC64=y
#
# Processor support
#
CONFIG_PPC_BOOK3S_64=y
# CONFIG_PPC_BOOK3E_64 is not set
CONFIG_GENERIC_CPU=y
# CONFIG_POWER7_CPU is not set
# CONFIG_POWER8_CPU is not set
# CONFIG_POWER9_CPU is not set
CONFIG_PPC_BOOK3S=y
CONFIG_PPC_FPU_REGS=y
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
CONFIG_VSX=y
CONFIG_PPC_64S_HASH_MMU=y
CONFIG_PPC_RADIX_MMU=y
CONFIG_PPC_RADIX_MMU_DEFAULT=y
CONFIG_PPC_KUEP=y
CONFIG_PPC_KUAP=y
# CONFIG_PPC_KUAP_DEBUG is not set
CONFIG_PPC_PKEY=y
CONFIG_PPC_MM_SLICES=y
CONFIG_PPC_HAVE_PMU_SUPPORT=y
# CONFIG_PMU_SYSFS is not set
CONFIG_PPC_PERF_CTRS=y
CONFIG_FORCE_SMP=y
CONFIG_SMP=y
CONFIG_NR_CPUS=2
CONFIG_PPC_DOORBELL=y
# end of Processor support
# CONFIG_CPU_BIG_ENDIAN is not set
CONFIG_CPU_LITTLE_ENDIAN=y
CONFIG_PPC64_BOOT_WRAPPER=y
CONFIG_64BIT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MAX=29
CONFIG_ARCH_MMAP_RND_BITS_MIN=14
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=13
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=7
CONFIG_NR_IRQS=512
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_PPC=y
CONFIG_PPC_BARRIER_NOSPEC=y
CONFIG_EARLY_PRINTK=y
CONFIG_PANIC_TIMEOUT=-1
# CONFIG_COMPAT is not set
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_UDBG_16550=y
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_SUSPEND_NONZERO_CPU=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_PPC_DAWR=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_PPC_MSI_BITMAP=y
CONFIG_PPC_XICS=y
CONFIG_PPC_ICP_NATIVE=y
CONFIG_PPC_ICP_HV=y
CONFIG_PPC_ICS_RTAS=y
CONFIG_PPC_XIVE=y
CONFIG_PPC_XIVE_SPAPR=y
#
# Platform support
#
# CONFIG_PPC_POWERNV is not set
CONFIG_PPC_PSERIES=y
CONFIG_PARAVIRT_SPINLOCKS=y
CONFIG_PPC_SPLPAR=y
# CONFIG_PSERIES_ENERGY is not set
CONFIG_IO_EVENT_IRQ=y
# CONFIG_LPARCFG is not set
# CONFIG_PPC_SMLPAR is not set
# CONFIG_HV_PERF_CTRS is not set
CONFIG_IBMVIO=y
# CONFIG_PPC_SVM is not set
CONFIG_PPC_VAS=y
# CONFIG_KVM_GUEST is not set
# CONFIG_EPAPR_PARAVIRT is not set
CONFIG_PPC_OF_BOOT_TRAMPOLINE=y
# CONFIG_PPC_DT_CPU_FTRS is not set
# CONFIG_UDBG_RTAS_CONSOLE is not set
CONFIG_PPC_SMP_MUXED_IPI=y
CONFIG_MPIC=y
# CONFIG_MPIC_MSGR is not set
CONFIG_PPC_I8259=y
CONFIG_PPC_RTAS=y
CONFIG_RTAS_ERROR_LOGGING=y
CONFIG_PPC_RTAS_DAEMON=y
# CONFIG_RTAS_PROC is not set
CONFIG_EEH=y
#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
# end of CPU Frequency scaling
#
# CPUIdle driver
#
#
# CPU Idle
#
# CONFIG_CPU_IDLE is not set
# end of CPU Idle
# end of CPUIdle driver
# CONFIG_GEN_RTC is not set
# end of Platform support
#
# Kernel options
#
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
# CONFIG_PPC_TRANSACTIONAL_MEM is not set
CONFIG_HOTPLUG_CPU=y
CONFIG_PPC_QUEUED_SPINLOCKS=y
CONFIG_ARCH_CPU_PROBE_RELEASE=y
# CONFIG_PPC64_SUPPORTS_MEMORY_FAILURE is not set
# CONFIG_KEXEC is not set
CONFIG_RELOCATABLE=y
# CONFIG_RELOCATABLE_TEST is not set
# CONFIG_CRASH_DUMP is not set
# CONFIG_FA_DUMP is not set
# CONFIG_IRQ_ALL_CPUS is not set
# CONFIG_NUMA is not set
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ILLEGAL_POINTER_VALUE=0x5deadbeef0000000
# CONFIG_PPC_4K_PAGES is not set
CONFIG_PPC_64K_PAGES=y
CONFIG_PPC_PAGE_SHIFT=16
CONFIG_THREAD_SHIFT=14
CONFIG_DATA_SHIFT=24
CONFIG_FORCE_MAX_ZONEORDER=9
# CONFIG_PPC_SUBPAGE_PROT is not set
# CONFIG_PPC_PROT_SAO_LPAR is not set
CONFIG_SCHED_SMT=y
CONFIG_PPC_DENORMALISATION=y
CONFIG_CMDLINE=""
CONFIG_EXTRA_TARGETS=""
# CONFIG_SUSPEND is not set
# CONFIG_HIBERNATION is not set
# CONFIG_PM is not set
# CONFIG_PPC_MEM_KEYS is not set
CONFIG_PPC_RTAS_FILTER=y
# end of Kernel options
CONFIG_ISA_DMA_API=y
#
# Bus options
#
CONFIG_GENERIC_ISA_DMA=y
# CONFIG_FSL_LBC is not set
# end of Bus options
CONFIG_NONSTATIC_KERNEL=y
CONFIG_PAGE_OFFSET=0xc000000000000000
CONFIG_KERNEL_START=0xc000000000000000
CONFIG_PHYSICAL_START=0x00000000
CONFIG_ARCH_RANDOM=y
# CONFIG_VIRTUALIZATION is not set
#
# General architecture-dependent options
#
# CONFIG_KPROBES is not set
CONFIG_JUMP_LABEL=y
# CONFIG_STATIC_KEYS_SELFTEST is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_ARCH_USE_BUILTIN_BSWAP=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_KPROBES_ON_FTRACE=y
CONFIG_HAVE_FUNCTION_ERROR_INJECTION=y
CONFIG_HAVE_NMI=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_ARCH_HAS_FORTIFY_SOURCE=y
CONFIG_ARCH_HAS_SET_MEMORY=y
CONFIG_HAVE_ASM_MODVERSIONS=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_RSEQ=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_NMI_WATCHDOG=y
CONFIG_HAVE_HARDLOCKUP_DETECTOR_ARCH=y
CONFIG_HAVE_PERF_REGS=y
CONFIG_HAVE_PERF_USER_STACK_DUMP=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_HAVE_ARCH_JUMP_LABEL_RELATIVE=y
CONFIG_MMU_GATHER_TABLE_FREE=y
CONFIG_MMU_GATHER_RCU_TABLE_FREE=y
CONFIG_MMU_GATHER_PAGE_SIZE=y
CONFIG_ARCH_WANT_IRQS_OFF_ACTIVATE_MM=y
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_ARCH_WEAK_RELEASE_ACQUIRE=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
# CONFIG_SECCOMP is not set
CONFIG_HAVE_STACKPROTECTOR=y
CONFIG_STACKPROTECTOR=y
CONFIG_STACKPROTECTOR_STRONG=y
CONFIG_LTO_NONE=y
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_VIRT_CPU_ACCOUNTING=y
CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_MOVE_PUD=y
CONFIG_HAVE_MOVE_PMD=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_HAVE_ARCH_HUGE_VMAP=y
CONFIG_HAVE_ARCH_HUGE_VMALLOC=y
CONFIG_HAVE_ARCH_SOFT_DIRTY=y
CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
CONFIG_MODULES_USE_ELF_RELA=y
CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK=y
CONFIG_HAVE_SOFTIRQ_ON_OWN_STACK=y
CONFIG_ARCH_HAS_ELF_RANDOMIZE=y
CONFIG_HAVE_ARCH_MMAP_RND_BITS=y
CONFIG_ARCH_MMAP_RND_BITS=14
CONFIG_PAGE_SIZE_LESS_THAN_256KB=y
CONFIG_HAVE_RELIABLE_STACKTRACE=y
CONFIG_HAVE_ARCH_NVRAM_OPS=y
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND=y
# CONFIG_COMPAT_32BIT_TIME is not set
CONFIG_ARCH_OPTIONAL_KERNEL_RWX=y
CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT=y
CONFIG_ARCH_HAS_STRICT_KERNEL_RWX=y
CONFIG_STRICT_KERNEL_RWX=y
CONFIG_ARCH_HAS_STRICT_MODULE_RWX=y
CONFIG_STRICT_MODULE_RWX=y
CONFIG_ARCH_HAS_PHYS_TO_DMA=y
CONFIG_ARCH_WANT_LD_ORPHAN_WARN=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
#
# GCOV-based kernel profiling
#
CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y
# end of GCOV-based kernel profiling
CONFIG_HAVE_GCC_PLUGINS=y
# end of General architecture-dependent options
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_MODULE_SIG is not set
CONFIG_MODULE_COMPRESS_NONE=y
# CONFIG_MODULE_COMPRESS_GZIP is not set
# CONFIG_MODULE_COMPRESS_XZ is not set
# CONFIG_MODULE_COMPRESS_ZSTD is not set
# CONFIG_MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS is not set
CONFIG_MODPROBE_PATH="/sbin/modprobe"
CONFIG_MODULES_TREE_LOOKUP=y
CONFIG_BLOCK=y
CONFIG_BLOCK_LEGACY_AUTOLOAD=y
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set
# CONFIG_BLK_DEV_ZONED is not set
# CONFIG_BLK_WBT is not set
# CONFIG_BLK_SED_OPAL is not set
# CONFIG_BLK_INLINE_ENCRYPTION is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_AIX_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
# CONFIG_MSDOS_PARTITION is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set
# CONFIG_CMDLINE_PARTITION is not set
# end of Partition Types
CONFIG_BLK_MQ_PCI=y
#
# IO Schedulers
#
# CONFIG_MQ_IOSCHED_DEADLINE is not set
# CONFIG_MQ_IOSCHED_KYBER is not set
# CONFIG_IOSCHED_BFQ is not set
# end of IO Schedulers
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y
CONFIG_MUTEX_SPIN_ON_OWNER=y
CONFIG_RWSEM_SPIN_ON_OWNER=y
CONFIG_LOCK_SPIN_ON_OWNER=y
CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y
CONFIG_QUEUED_SPINLOCKS=y
CONFIG_ARCH_USE_QUEUED_RWLOCKS=y
CONFIG_QUEUED_RWLOCKS=y
CONFIG_ARCH_HAS_MMIOWB=y
CONFIG_MMIOWB=y
CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE=y
#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_ELFCORE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_BINFMT_SCRIPT=y
# CONFIG_BINFMT_MISC is not set
CONFIG_COREDUMP=y
# end of Executable file formats
#
# Memory Management options
#
CONFIG_SELECT_MEMORY_MODEL=y
# CONFIG_FLATMEM_MANUAL is not set
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_VMEMMAP=y
CONFIG_HAVE_FAST_GUP=y
CONFIG_ARCH_KEEP_MEMBLOCK=y
CONFIG_EXCLUSIVE_SYSTEM_RAM=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
# CONFIG_MEMORY_HOTPLUG is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y
CONFIG_COMPACTION=y
# CONFIG_PAGE_REPORTING is not set
CONFIG_MIGRATION=y
CONFIG_ARCH_ENABLE_THP_MIGRATION=y
CONFIG_PHYS_ADDR_T_64BIT=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_TRANSPARENT_HUGEPAGE=y
# CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not set
CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
# CONFIG_CMA is not set
# CONFIG_ZPOOL is not set
# CONFIG_ZSMALLOC is not set
CONFIG_GENERIC_EARLY_IOREMAP=y
# CONFIG_DEFERRED_STRUCT_PAGE_INIT is not set
# CONFIG_IDLE_PAGE_TRACKING is not set
CONFIG_ARCH_HAS_CURRENT_STACK_POINTER=y
CONFIG_ARCH_HAS_PTE_DEVMAP=y
# CONFIG_PERCPU_STATS is not set
#
# GUP_TEST needs to have DEBUG_FS enabled
#
# CONFIG_READ_ONLY_THP_FOR_FS is not set
CONFIG_ARCH_HAS_PTE_SPECIAL=y
# CONFIG_ANON_VMA_NAME is not set
#
# Data Access Monitoring
#
# CONFIG_DAMON is not set
# end of Data Access Monitoring
# end of Memory Management options
# CONFIG_NET is not set
#
# Device Drivers
#
CONFIG_HAVE_PCI=y
CONFIG_FORCE_PCI=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCI_SYSCALL=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_PCIEASPM=y
CONFIG_PCIEASPM_DEFAULT=y
# CONFIG_PCIEASPM_POWERSAVE is not set
# CONFIG_PCIEASPM_POWER_SUPERSAVE is not set
# CONFIG_PCIEASPM_PERFORMANCE is not set
# CONFIG_PCIE_PTM is not set
CONFIG_PCI_MSI=y
CONFIG_PCI_MSI_IRQ_DOMAIN=y
CONFIG_PCI_MSI_ARCH_FALLBACKS=y
CONFIG_PCI_QUIRKS=y
# CONFIG_PCI_STUB is not set
# CONFIG_PCI_IOV is not set
# CONFIG_PCI_PRI is not set
# CONFIG_PCI_PASID is not set
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=16
# CONFIG_HOTPLUG_PCI is not set
#
# PCI controller drivers
#
# CONFIG_PCI_FTPCI100 is not set
# CONFIG_PCI_HOST_GENERIC is not set
# CONFIG_PCIE_XILINX is not set
# CONFIG_PCIE_MICROCHIP_HOST is not set
#
# DesignWare PCI Core Support
#
# CONFIG_PCIE_DW_PLAT_HOST is not set
# CONFIG_PCI_MESON is not set
# end of DesignWare PCI Core Support
#
# Mobiveil PCIe Core Support
#
# end of Mobiveil PCIe Core Support
#
# Cadence PCIe controllers support
#
# CONFIG_PCIE_CADENCE_PLAT_HOST is not set
# CONFIG_PCI_J721E_HOST is not set
# end of Cadence PCIe controllers support
# end of PCI controller drivers
#
# PCI Endpoint
#
# CONFIG_PCI_ENDPOINT is not set
# end of PCI Endpoint
#
# PCI switch controller drivers
#
# CONFIG_PCI_SW_SWITCHTEC is not set
# end of PCI switch controller drivers
# CONFIG_CXL_BUS is not set
# CONFIG_PCCARD is not set
# CONFIG_RAPIDIO is not set
#
# Generic Driver Options
#
# CONFIG_UEVENT_HELPER is not set
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
# CONFIG_DEVTMPFS_SAFE is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
#
# Firmware loader
#
CONFIG_FW_LOADER=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_FW_LOADER_USER_HELPER is not set
# CONFIG_FW_LOADER_COMPRESS is not set
# end of Firmware loader
CONFIG_ALLOW_DEV_COREDUMP=y
# CONFIG_TEST_ASYNC_DRIVER_PROBE is not set
CONFIG_GENERIC_CPU_AUTOPROBE=y
CONFIG_GENERIC_CPU_VULNERABILITIES=y
# end of Generic Driver Options
#
# Bus devices
#
# CONFIG_MHI_BUS is not set
# end of Bus devices
#
# Firmware Drivers
#
#
# ARM System Control and Management Interface Protocol
#
# end of ARM System Control and Management Interface Protocol
# CONFIG_GOOGLE_FIRMWARE is not set
#
# Tegra firmware driver
#
# end of Tegra firmware driver
# end of Firmware Drivers
# CONFIG_GNSS is not set
# CONFIG_MTD is not set
CONFIG_DTC=y
CONFIG_OF=y
# CONFIG_OF_UNITTEST is not set
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_KOBJ=y
CONFIG_OF_DYNAMIC=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_RESERVED_MEM=y
# CONFIG_OF_OVERLAY is not set
CONFIG_OF_DMA_DEFAULT_COHERENT=y
CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
# CONFIG_PARPORT is not set
# CONFIG_BLK_DEV is not set
#
# NVME Support
#
# CONFIG_BLK_DEV_NVME is not set
# CONFIG_NVME_FC is not set
# end of NVME Support
#
# Misc devices
#
# CONFIG_DUMMY_IRQ is not set
# CONFIG_IBMVMC is not set
# CONFIG_PHANTOM is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_HP_ILO is not set
# CONFIG_SRAM is not set
# CONFIG_DW_XDATA_PCIE is not set
# CONFIG_PCI_ENDPOINT_TEST is not set
# CONFIG_XILINX_SDFEC is not set
# CONFIG_OPEN_DICE is not set
# CONFIG_C2PORT is not set
#
# EEPROM support
#
# CONFIG_EEPROM_93CX6 is not set
# end of EEPROM support
# CONFIG_CB710_CORE is not set
#
# Texas Instruments shared transport line discipline
#
# end of Texas Instruments shared transport line discipline
#
# Altera FPGA firmware download module (requires I2C)
#
# CONFIG_GENWQE is not set
# CONFIG_ECHO is not set
# CONFIG_BCM_VK is not set
# CONFIG_MISC_ALCOR_PCI is not set
# CONFIG_MISC_RTSX_PCI is not set
# CONFIG_HABANA_AI is not set
# CONFIG_PVPANIC is not set
# end of Misc devices
#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
# end of SCSI device support
# CONFIG_ATA is not set
# CONFIG_MD is not set
# CONFIG_TARGET_CORE is not set
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
# CONFIG_FIREWIRE_NOSY is not set
# end of IEEE 1394 (FireWire) support
# CONFIG_MACINTOSH_DRIVERS is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set
#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set
# CONFIG_RMI4_CORE is not set
#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y
# CONFIG_GAMEPORT is not set
# end of Hardware I/O ports
# end of Input device support
#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
# CONFIG_LDISC_AUTOLOAD is not set
#
# Serial drivers
#
CONFIG_SERIAL_EARLYCON=y
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
# CONFIG_SERIAL_8250_16550A_VARIANTS is not set
# CONFIG_SERIAL_8250_FINTEK is not set
CONFIG_SERIAL_8250_CONSOLE=y
# CONFIG_SERIAL_8250_PCI is not set
CONFIG_SERIAL_8250_NR_UARTS=1
CONFIG_SERIAL_8250_RUNTIME_UARTS=1
# CONFIG_SERIAL_8250_EXTENDED is not set
CONFIG_SERIAL_8250_FSL=y
# CONFIG_SERIAL_8250_DW is not set
# CONFIG_SERIAL_8250_RT288X is not set
CONFIG_SERIAL_8250_PERICOM=y
# CONFIG_SERIAL_OF_PLATFORM is not set
#
# Non-8250 serial port support
#
# CONFIG_SERIAL_UARTLITE is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_ICOM is not set
# CONFIG_SERIAL_JSM is not set
# CONFIG_SERIAL_SIFIVE is not set
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_SERIAL_RP2 is not set
# CONFIG_SERIAL_FSL_LPUART is not set
# CONFIG_SERIAL_FSL_LINFLEXUART is not set
# CONFIG_SERIAL_CONEXANT_DIGICOLOR is not set
# end of Serial drivers
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_PPC_EPAPR_HV_BYTECHAN is not set
# CONFIG_NOZOMI is not set
# CONFIG_NULL_TTY is not set
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_CONSOLE=y
# CONFIG_HVC_OLD_HVSI is not set
# CONFIG_HVC_RTAS is not set
# CONFIG_HVC_UDBG is not set
# CONFIG_HVCS is not set
# CONFIG_SERIAL_DEV_BUS is not set
# CONFIG_VIRTIO_CONSOLE is not set
# CONFIG_IBM_BSR is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_APPLICOM is not set
# CONFIG_DEVMEM is not set
# CONFIG_NVRAM is not set
CONFIG_DEVPORT=y
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_XILLYBUS is not set
# CONFIG_RANDOM_TRUST_CPU is not set
# CONFIG_RANDOM_TRUST_BOOTLOADER is not set
# end of Character devices
#
# I2C support
#
# CONFIG_I2C is not set
# end of I2C support
# CONFIG_I3C is not set
# CONFIG_SPI is not set
# CONFIG_SPMI is not set
# CONFIG_HSI is not set
# CONFIG_PPS is not set
#
# PTP clock support
#
CONFIG_PTP_1588_CLOCK_OPTIONAL=y
#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
# end of PTP clock support
# CONFIG_PINCTRL is not set
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
# CONFIG_POWER_RESET is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y
# CONFIG_BCMA is not set
#
# Multifunction device drivers
#
# CONFIG_MFD_ATMEL_FLEXCOM is not set
# CONFIG_MFD_ATMEL_HLCDC is not set
# CONFIG_MFD_MADERA is not set
# CONFIG_MFD_HI6421_PMIC is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_LPC_ICH is not set
# CONFIG_LPC_SCH is not set
# CONFIG_MFD_JANZ_CMODIO is not set
# CONFIG_MFD_KEMPLD is not set
# CONFIG_MFD_MT6397 is not set
# CONFIG_MFD_RDC321X is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_TQMX86 is not set
# CONFIG_MFD_VX855 is not set
# end of Multifunction device drivers
# CONFIG_REGULATOR is not set
# CONFIG_RC_CORE is not set
#
# CEC support
#
# CONFIG_MEDIA_CEC_SUPPORT is not set
# end of CEC support
# CONFIG_MEDIA_SUPPORT is not set
#
# Graphics support
#
# CONFIG_AGP is not set
# CONFIG_DRM is not set
#
# ARM devices
#
# end of ARM devices
#
# Frame buffer Devices
#
# CONFIG_FB is not set
# end of Frame buffer Devices
#
# Backlight & LCD device support
#
# CONFIG_LCD_CLASS_DEVICE is not set
# CONFIG_BACKLIGHT_CLASS_DEVICE is not set
# end of Backlight & LCD device support
#
# Console display driver support
#
# CONFIG_VGA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_DUMMY_CONSOLE_COLUMNS=80
CONFIG_DUMMY_CONSOLE_ROWS=25
# end of Console display driver support
# end of Graphics support
# CONFIG_SOUND is not set
#
# HID support
#
# CONFIG_HID is not set
# end of HID support
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
# CONFIG_USB_SUPPORT is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
CONFIG_EDAC_ATOMIC_SCRUB=y
CONFIG_EDAC_SUPPORT=y
CONFIG_RTC_LIB=y
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
#
# DMABUF options
#
# CONFIG_SYNC_FILE is not set
# CONFIG_DMABUF_HEAPS is not set
# end of DMABUF options
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_VFIO is not set
# CONFIG_VIRT_DRIVERS is not set
# CONFIG_VIRTIO_MENU is not set
# CONFIG_VHOST_MENU is not set
#
# Microsoft Hyper-V guest support
#
# end of Microsoft Hyper-V guest support
# CONFIG_GREYBUS is not set
# CONFIG_COMEDI is not set
# CONFIG_STAGING is not set
# CONFIG_GOLDFISH is not set
# CONFIG_COMMON_CLK is not set
# CONFIG_HWSPINLOCK is not set
#
# Clock Source drivers
#
CONFIG_I8253_LOCK=y
CONFIG_CLKBLD_I8253=y
# CONFIG_MICROCHIP_PIT64B is not set
# end of Clock Source drivers
# CONFIG_MAILBOX is not set
# CONFIG_IOMMU_SUPPORT is not set
#
# Remoteproc drivers
#
# CONFIG_REMOTEPROC is not set
# end of Remoteproc drivers
#
# Rpmsg drivers
#
# CONFIG_RPMSG_VIRTIO is not set
# end of Rpmsg drivers
# CONFIG_SOUNDWIRE is not set
#
# SOC (System On Chip) specific Drivers
#
#
# Amlogic SoC drivers
#
# end of Amlogic SoC drivers
#
# Broadcom SoC drivers
#
# end of Broadcom SoC drivers
#
# NXP/Freescale QorIQ SoC drivers
#
# CONFIG_QUICC_ENGINE is not set
# end of NXP/Freescale QorIQ SoC drivers
#
# i.MX SoC drivers
#
# end of i.MX SoC drivers
#
# Enable LiteX SoC Builder specific drivers
#
# CONFIG_LITEX_SOC_CONTROLLER is not set
# end of Enable LiteX SoC Builder specific drivers
#
# Qualcomm SoC drivers
#
# end of Qualcomm SoC drivers
# CONFIG_SOC_TI is not set
#
# Xilinx SoC drivers
#
# end of Xilinx SoC drivers
# end of SOC (System On Chip) specific Drivers
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
# CONFIG_NTB is not set
# CONFIG_VME_BUS is not set
# CONFIG_PWM is not set
#
# IRQ chip support
#
CONFIG_IRQCHIP=y
# CONFIG_AL_FIC is not set
# end of IRQ chip support
# CONFIG_IPACK_BUS is not set
# CONFIG_RESET_CONTROLLER is not set
#
# PHY Subsystem
#
# CONFIG_GENERIC_PHY is not set
# CONFIG_PHY_CAN_TRANSCEIVER is not set
#
# PHY drivers for Broadcom platforms
#
# CONFIG_BCM_KONA_USB2_PHY is not set
# end of PHY drivers for Broadcom platforms
# CONFIG_PHY_CADENCE_DPHY is not set
# CONFIG_PHY_CADENCE_DPHY_RX is not set
# CONFIG_PHY_CADENCE_SALVO is not set
# CONFIG_PHY_PXA_28NM_HSIC is not set
# CONFIG_PHY_PXA_28NM_USB2 is not set
# end of PHY Subsystem
# CONFIG_POWERCAP is not set
# CONFIG_MCB is not set
#
# Performance monitor support
#
# end of Performance monitor support
# CONFIG_RAS is not set
# CONFIG_USB4 is not set
#
# Android
#
CONFIG_ANDROID=y
# CONFIG_ANDROID_BINDER_IPC is not set
# end of Android
# CONFIG_DAX is not set
# CONFIG_NVMEM is not set
#
# HW tracing support
#
# CONFIG_STM is not set
# CONFIG_INTEL_TH is not set
# end of HW tracing support
# CONFIG_FPGA is not set
# CONFIG_FSI is not set
# CONFIG_SIOX is not set
# CONFIG_SLIMBUS is not set
# CONFIG_INTERCONNECT is not set
# CONFIG_COUNTER is not set
# CONFIG_PECI is not set
# end of Device Drivers
#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
# CONFIG_VALIDATE_FS_PARSER is not set
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_EXT4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_EXPORTFS=y
# CONFIG_EXPORTFS_BLOCK_OPS is not set
CONFIG_FILE_LOCKING=y
# CONFIG_FS_ENCRYPTION is not set
# CONFIG_FS_VERITY is not set
# CONFIG_DNOTIFY is not set
# CONFIG_INOTIFY_USER is not set
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_FUSE_FS is not set
# CONFIG_OVERLAY_FS is not set
#
# Caches
#
# CONFIG_FSCACHE is not set
# end of Caches
#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set
# end of CD-ROM/DVD Filesystems
#
# DOS/FAT/EXFAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_EXFAT_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_NTFS3_FS is not set
# end of DOS/FAT/EXFAT/NT Filesystems
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
# CONFIG_PROC_KCORE is not set
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
# CONFIG_PROC_CHILDREN is not set
CONFIG_KERNFS=y
CONFIG_SYSFS=y
# CONFIG_TMPFS is not set
CONFIG_ARCH_SUPPORTS_HUGETLBFS=y
# CONFIG_HUGETLBFS is not set
CONFIG_ARCH_HAS_GIGANTIC_PAGE=y
# CONFIG_CONFIGFS_FS is not set
# end of Pseudo filesystems
# CONFIG_MISC_FILESYSTEMS is not set
# CONFIG_NLS is not set
# CONFIG_UNICODE is not set
CONFIG_IO_WQ=y
# end of File systems
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR=y
CONFIG_HARDENED_USERCOPY=y
CONFIG_FORTIFY_SOURCE=y
# CONFIG_STATIC_USERMODEHELPER is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_LSM="lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf"
#
# Kernel hardening options
#
#
# Memory initialization
#
CONFIG_INIT_STACK_NONE=y
CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y
CONFIG_INIT_ON_FREE_DEFAULT_ON=y
# end of Memory initialization
# end of Kernel hardening options
# end of Security options
# CONFIG_CRYPTO is not set
#
# Library routines
#
# CONFIG_PACKING is not set
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
# CONFIG_CORDIC is not set
# CONFIG_PRIME_NUMBERS is not set
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
CONFIG_ARCH_HAS_FAST_MULTIPLIER=y
#
# Crypto library routines
#
CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC=y
# CONFIG_CRYPTO_LIB_CURVE25519 is not set
CONFIG_CRYPTO_LIB_POLY1305_RSIZE=1
# CONFIG_CRYPTO_LIB_POLY1305 is not set
# end of Crypto library routines
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
# CONFIG_CRC_T10DIF is not set
# CONFIG_CRC64_ROCKSOFT is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC64 is not set
# CONFIG_CRC4 is not set
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
# CONFIG_CRC8 is not set
# CONFIG_RANDOM32_SELFTEST is not set
CONFIG_ZLIB_DEFLATE=y
# CONFIG_XZ_DEC is not set
CONFIG_XARRAY_MULTI=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT_MAP=y
CONFIG_HAS_DMA=y
CONFIG_DMA_OPS=y
CONFIG_DMA_OPS_BYPASS=y
CONFIG_ARCH_HAS_DMA_MAP_DIRECT=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_DMA_DECLARE_COHERENT=y
CONFIG_SWIOTLB=y
# CONFIG_DMA_RESTRICTED_POOL is not set
# CONFIG_DMA_API_DEBUG is not set
CONFIG_IOMMU_HELPER=y
# CONFIG_IRQ_POLL is not set
CONFIG_LIBFDT=y
CONFIG_HAVE_GENERIC_VDSO=y
CONFIG_GENERIC_GETTIMEOFDAY=y
CONFIG_GENERIC_VDSO_TIME_NS=y
CONFIG_ARCH_HAS_PMEM_API=y
CONFIG_ARCH_HAS_MEMREMAP_COMPAT_ALIGN=y
CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE=y
CONFIG_ARCH_HAS_COPY_MC=y
CONFIG_ARCH_STACKWALK=y
CONFIG_SBITMAP=y
# end of Library routines
#
# Kernel hacking
#
#
# printk and dmesg options
#
CONFIG_PRINTK_TIME=y
# CONFIG_PRINTK_CALLER is not set
# CONFIG_STACKTRACE_BUILD_ID is not set
CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7
CONFIG_CONSOLE_LOGLEVEL_QUIET=4
CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DYNAMIC_DEBUG_CORE is not set
CONFIG_SYMBOLIC_ERRNAME=y
CONFIG_DEBUG_BUGVERBOSE=y
# end of printk and dmesg options
# CONFIG_DEBUG_KERNEL is not set
#
# Compile-time checks and compiler options
#
CONFIG_FRAME_WARN=2048
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_HEADERS_INSTALL is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
# CONFIG_SECTION_MISMATCH_WARN_ONLY is not set
# end of Compile-time checks and compiler options
#
# Generic Kernel Debugging Instruments
#
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_DEBUG_FS is not set
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL=y
# CONFIG_UBSAN is not set
# end of Generic Kernel Debugging Instruments
#
# Networking Debugging
#
# end of Networking Debugging
#
# Memory Debugging
#
# CONFIG_PAGE_EXTENSION is not set
# CONFIG_PAGE_POISONING is not set
# CONFIG_DEBUG_RODATA_TEST is not set
CONFIG_ARCH_HAS_DEBUG_WX=y
# CONFIG_DEBUG_WX is not set
CONFIG_GENERIC_PTDUMP=y
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
CONFIG_ARCH_HAS_DEBUG_VM_PGTABLE=y
# CONFIG_DEBUG_VM_PGTABLE is not set
CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_HAVE_DEBUG_STACKOVERFLOW=y
CONFIG_CC_HAS_KASAN_GENERIC=y
CONFIG_CC_HAS_WORKING_NOSANITIZE_ADDRESS=y
# end of Memory Debugging
#
# Debug Oops, Lockups and Hangs
#
CONFIG_PANIC_ON_OOPS=y
CONFIG_PANIC_ON_OOPS_VALUE=1
# CONFIG_TEST_LOCKUP is not set
# end of Debug Oops, Lockups and Hangs
#
# Scheduler Debugging
#
# end of Scheduler Debugging
# CONFIG_DEBUG_TIMEKEEPING is not set
#
# Lock Debugging (spinlocks, mutexes, etc...)
#
CONFIG_LOCK_DEBUGGING_SUPPORT=y
# CONFIG_WW_MUTEX_SELFTEST is not set
# end of Lock Debugging (spinlocks, mutexes, etc...)
# CONFIG_DEBUG_IRQFLAGS is not set
# CONFIG_STACKTRACE is not set
# CONFIG_WARN_ALL_UNSEEDED_RANDOM is not set
#
# Debug kernel data structures
#
# CONFIG_BUG_ON_DATA_CORRUPTION is not set
# end of Debug kernel data structures
#
# RCU Debugging
#
CONFIG_RCU_CPU_STALL_TIMEOUT=21
# end of RCU Debugging
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
CONFIG_SAMPLES=y
# CONFIG_SAMPLE_AUXDISPLAY is not set
# CONFIG_SAMPLE_KOBJECT is not set
# CONFIG_SAMPLE_HW_BREAKPOINT is not set
# CONFIG_SAMPLE_KFIFO is not set
# CONFIG_SAMPLE_WATCHDOG is not set
CONFIG_ARCH_HAS_DEVMEM_IS_ALLOWED=y
# CONFIG_STRICT_DEVMEM is not set
#
# powerpc Debugging
#
# CONFIG_PPC_DISABLE_WERROR is not set
CONFIG_PPC_WERROR=y
CONFIG_PRINT_STACK_DEPTH=64
# CONFIG_JUMP_LABEL_FEATURE_CHECKS is not set
# CONFIG_PPC_IRQ_SOFT_MASK_DEBUG is not set
# CONFIG_PPC_RFI_SRR_DEBUG is not set
# CONFIG_BOOTX_TEXT is not set
# CONFIG_PPC_EARLY_DEBUG is not set
# end of powerpc Debugging
#
# Kernel Testing and Coverage
#
# CONFIG_KUNIT is not set
CONFIG_ARCH_HAS_KCOV=y
CONFIG_CC_HAS_SANCOV_TRACE_PC=y
# CONFIG_KCOV is not set
# CONFIG_RUNTIME_TESTING_MENU is not set
CONFIG_ARCH_USE_MEMTEST=y
# CONFIG_MEMTEST is not set
# end of Kernel Testing and Coverage
# end of Kernel hacking
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: rcu_sched self-detected stall on CPU 2022-04-05 21:41 rcu_sched self-detected stall on CPU Miguel Ojeda @ 2022-04-06 9:31 ` Zhouyi Zhou 2022-04-06 17:00 ` Paul E. McKenney 0 siblings, 1 reply; 1767+ messages in thread From: Zhouyi Zhou @ 2022-04-06 9:31 UTC (permalink / raw) To: Miguel Ojeda; +Cc: rcu, linuxppc-dev Hi I can reproduce it in a ppc virtual cloud server provided by Oregon State University. Following is what I do: 1) curl -l https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapshot/linux-5.18-rc1.tar.gz -o linux-5.18-rc1.tar.gz 2) tar zxf linux-5.18-rc1.tar.gz 3) cp config linux-5.18-rc1/.config 4) cd linux-5.18-rc1 5) make vmlinux -j 8 6) qemu-system-ppc64 -kernel vmlinux -nographic -vga none -no-reboot -smp 2 (QEMU 4.2.1) 7) after 12 rounds, the bug got reproduced: (http://154.223.142.244/logs/20220406/qemu.log.txt) Cheers ;-) Zhouyi On Wed, Apr 6, 2022 at 3:47 PM Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > > Hi PPC/RCU, > > While merging v5.18-rc1 changes I noticed our CI PPC runs broke. I > reproduced the problem in v5.18-rc1 as well as next-20220405, under > both QEMU 4.2.1 and 6.1.0, with `-smp 2`; but I cannot reproduce it in > v5.17 from a few tries. > > Sadly, the problem is not deterministic although it is not too hard to > reproduce (1 out of 5?). Please see attached config and QEMU output. > > Cheers, > Miguel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: rcu_sched self-detected stall on CPU 2022-04-06 9:31 ` Zhouyi Zhou @ 2022-04-06 17:00 ` Paul E. McKenney 2022-04-08 7:23 ` Michael Ellerman 0 siblings, 1 reply; 1767+ messages in thread From: Paul E. McKenney @ 2022-04-06 17:00 UTC (permalink / raw) To: Zhouyi Zhou; +Cc: rcu, Miguel Ojeda, linuxppc-dev On Wed, Apr 06, 2022 at 05:31:10PM +0800, Zhouyi Zhou wrote: > Hi > > I can reproduce it in a ppc virtual cloud server provided by Oregon > State University. Following is what I do: > 1) curl -l https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapshot/linux-5.18-rc1.tar.gz > -o linux-5.18-rc1.tar.gz > 2) tar zxf linux-5.18-rc1.tar.gz > 3) cp config linux-5.18-rc1/.config > 4) cd linux-5.18-rc1 > 5) make vmlinux -j 8 > 6) qemu-system-ppc64 -kernel vmlinux -nographic -vga none -no-reboot > -smp 2 (QEMU 4.2.1) > 7) after 12 rounds, the bug got reproduced: > (http://154.223.142.244/logs/20220406/qemu.log.txt) Just to make sure, are you both seeing the same thing? Last I knew, Zhouyi was chasing an RCU-tasks issue that appears only in kernels built with CONFIG_PROVE_RCU=y, which Miguel does not have set. Or did I miss something? Miguel is instead seeing an RCU CPU stall warning where RCU's grace-period kthread slept for three milliseconds, but did not wake up for more than 20 seconds. This kthread would normally have awakened on CPU 1, but CPU 1 looks to me to be very unhealthy, as can be seen in your console output below (but maybe my idea of what is healthy for powerpc systems is outdated). Please see also the inline annotations. Thoughts from the PPC guys? Thanx, Paul ------------------------------------------------------------------------ [ 21.186912] rcu: INFO: rcu_sched self-detected stall on CPU [ 21.187331] rcu: 1-...!: (4712629 ticks this GP) idle=2c1/0/0x3 softirq=8/8 fqs=0 [ 21.187529] (t=21000 jiffies g=-1183 q=3) [ 21.187681] rcu: rcu_sched kthread timer wakeup didn't happen for 20997 jiffies! g-1183 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 The grace-period kthread is still asleep (->state=0x402). This indicates that the three-jiffy timer has somehow been prevented from expiring for almost a full 21 seconds. Of course, if timers don't work, RCU cannot work. [ 21.187770] rcu: Possible timer handling issue on cpu=1 timer-softirq=1 [ 21.187927] rcu: rcu_sched kthread starved for 21001 jiffies! g-1183 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=1 [ 21.188019] rcu: Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior. [ 21.188087] rcu: RCU grace-period kthread stack dump: [ 21.188196] task:rcu_sched state:I stack: 0 pid: 10 ppid: 2 flags:0x00000800 [ 21.188453] Call Trace: [ 21.188525] [c0000000061e78a0] [c0000000061e78e0] 0xc0000000061e78e0 (unreliable) [ 21.188900] [c0000000061e7a90] [c000000000017210] __switch_to+0x250/0x310 [ 21.189210] [c0000000061e7b00] [c0000000003ed660] __schedule+0x210/0x660 [ 21.189315] [c0000000061e7b80] [c0000000003edb14] schedule+0x64/0x110 [ 21.189387] [c0000000061e7bb0] [c0000000003f6648] schedule_timeout+0x1d8/0x390 [ 21.189473] [c0000000061e7c80] [c00000000011111c] rcu_gp_fqs_loop+0x2dc/0x3d0 [ 21.189555] [c0000000061e7d30] [c0000000001144ec] rcu_gp_kthread+0x13c/0x160 [ 21.189633] [c0000000061e7dc0] [c0000000000c1770] kthread+0x110/0x120 [ 21.189714] [c0000000061e7e10] [c00000000000c9e4] ret_from_kernel_thread+0x5c/0x64 The above stack trace is expected behavior when the RCU grace-period kthread is waiting to do its next FQS scan. [ 21.189938] rcu: Stack dump where RCU GP kthread last ran: And here is the stalled CPU, which also happens to be the CPU that RCU last ran on: [ 21.189992] Task dump for CPU 1: [ 21.190059] task:swapper/1 state:R running task stack: 0 pid: 0 ppid: 1 flags:0x00000804 [ 21.190169] Call Trace: [ 21.190194] [c0000000061ef2d0] [c0000000000c9a40] sched_show_task+0x180/0x1c0 (unreliable) [ 21.190278] [c0000000061ef340] [c000000000116ca0] rcu_check_gp_kthread_starvation+0x16c/0x19c [ 21.190370] [c0000000061ef3c0] [c000000000114f7c] rcu_sched_clock_irq+0x7ec/0xaf0 [ 21.190448] [c0000000061ef4b0] [c000000000120fdc] update_process_times+0xbc/0x140 [ 21.190524] [c0000000061ef4f0] [c000000000136a24] tick_nohz_handler+0xf4/0x1b0 [ 21.190608] [c0000000061ef540] [c00000000001c828] timer_interrupt+0x148/0x2d0 [ 21.190699] [c0000000061ef590] [c0000000000098e8] decrementer_common_virt+0x208/0x210 [ 21.190837] --- interrupt: 900 at arch_local_irq_restore+0x168/0x170 Up through this point is just the stack trace of the the code doing the stack dump that the RCU CPU stall warning code asked for. [ 21.190941] NIP: c000000000013608 LR: c0000000003f8114 CTR: c0000000000dc630 This NIP does not look at all good to me. But I freely confess that I am out of date on what Power machines do. [ 21.191031] REGS: c0000000061ef600 TRAP: 0900 Not tainted (5.18.0-rc1) [ 21.191109] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22000202 XER: 00000000 [ 21.191274] CFAR: 0000000000000000 IRQMASK: 0 [ 21.191274] GPR00: c00000000009c368 c0000000061ef8a0 c00000000116a700 0000000000000000 [ 21.191274] GPR04: 0000000000000000 0000000000000000 000000001ee30000 ffffffffffffffff [ 21.191274] GPR08: 000000001ee30000 0000000000000000 0000000000008002 7265677368657265 [ 21.191274] GPR12: c0000000000dc630 c00000001ffe5800 0000000000000000 0000000000000000 [ 21.191274] GPR16: 0000000000000282 0000000000000000 0000000000000000 c0000000061eff00 [ 21.191274] GPR20: 0000000000000000 0000000000000001 c0000000061b9f80 c000000001195a10 [ 21.191274] GPR24: c000000001193a00 00000000fffb6cc4 000000000000000a c0000000010721e8 [ 21.191274] GPR28: c000000001076800 c000000001070380 c0000000010716d8 c0000000061b9f80 [ 21.191932] NIP [c000000000013608] arch_local_irq_restore+0x168/0x170 [ 21.192024] LR [c0000000003f8114] __do_softirq+0xd4/0x2ec [ 21.192118] --- interrupt: 900 [ 21.192158] [c0000000061ef8a0] [c0000000061b9f80] 0xc0000000061b9f80 (unreliable) [ 21.192227] [c0000000061ef9b0] [c00000000009c368] irq_exit+0xc8/0x110 [ 21.192307] [c0000000061ef9d0] [c00000000001c858] timer_interrupt+0x178/0x2d0 [ 21.192397] [c0000000061efa20] [c0000000000098e8] decrementer_common_virt+0x208/0x210 [ 21.192495] --- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c [ 21.192566] NIP: c000000000072988 LR: c000000000074fa8 CTR: c000000000074f10 [ 21.192615] REGS: c0000000061efa90 TRAP: 0900 Not tainted (5.18.0-rc1) [ 21.192659] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28000202 XER: 00000000 [ 21.192755] CFAR: 0000000000000000 IRQMASK: 0 [ 21.192755] GPR00: 0000000028000202 c0000000061efd30 c00000000116a700 0000000000000000 [ 21.192755] GPR04: c00000001fea0280 ffffffffffffffff 0000000001f40000 000000019d088fcf [ 21.192755] GPR08: 000000001ee30000 c00000001ffe5400 0000000000000001 0000000100000000 [ 21.192755] GPR12: c000000000074f10 c00000001ffe5800 0000000000000000 0000000000000000 [ 21.192755] GPR16: 0000000000000000 0000000000000000 0000000000000000 c0000000061eff00 [ 21.192755] GPR20: c00000000003d440 0000000000000001 c000000001195b30 c000000001195a10 [ 21.192755] GPR24: 0000000000080000 c0000000061ba000 c000000001195a98 0000000000000001 [ 21.192755] GPR28: 0000000000000001 c0000000010716d0 c0000000010716d8 c0000000010716d0 [ 21.193290] NIP [c000000000072988] plpar_hcall_norets_notrace+0x18/0x2c [ 21.193363] LR [c000000000074fa8] pseries_lpar_idle+0x98/0x1b0 [ 21.193428] --- interrupt: 900 [ 21.193457] [c0000000061efd30] [0000000000000001] 0x1 (unreliable) [ 21.193512] [c0000000061efdb0] [c000000000018b54] arch_cpu_idle+0x44/0x180 [ 21.193590] [c0000000061efde0] [c0000000003f75bc] default_idle_call+0x4c/0x7c [ 21.193679] [c0000000061efe00] [c0000000000e1384] do_idle+0x114/0x1e0 [ 21.193747] [c0000000061efe60] [c0000000000e1664] cpu_startup_entry+0x34/0x40 [ 21.193901] [c0000000061efe90] [c00000000003f044] start_secondary+0x624/0xa00 [ 21.194002] [c0000000061eff90] [c00000000000cd54] start_secondary_prolog+0x10/0x14 [ 21.194245] Task dump for CPU 1: [ 21.194284] task:swapper/1 state:R running task stack: 0 pid: 0 ppid: 1 flags:0x00000804 [ 21.194374] Call Trace: [ 21.194400] [c0000000061ef2b0] [c0000000000c9a40] sched_show_task+0x180/0x1c0 (unreliable) [ 21.194479] [c0000000061ef320] [c000000000116df8] rcu_dump_cpu_stacks+0x128/0x188 [ 21.194567] [c0000000061ef3c0] [c000000000114f9c] rcu_sched_clock_irq+0x80c/0xaf0 [ 21.194642] [c0000000061ef4b0] [c000000000120fdc] update_process_times+0xbc/0x140 [ 21.194712] [c0000000061ef4f0] [c000000000136a24] tick_nohz_handler+0xf4/0x1b0 [ 21.194828] [c0000000061ef540] [c00000000001c828] timer_interrupt+0x148/0x2d0 [ 21.194942] [c0000000061ef590] [c0000000000098e8] decrementer_common_virt+0x208/0x210 [ 21.195035] --- interrupt: 900 at arch_local_irq_restore+0x168/0x170 [ 21.195104] NIP: c000000000013608 LR: c0000000003f8114 CTR: c0000000000dc630 [ 21.195152] REGS: c0000000061ef600 TRAP: 0900 Not tainted (5.18.0-rc1) [ 21.195199] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22000202 XER: 00000000 [ 21.195296] CFAR: 0000000000000000 IRQMASK: 0 [ 21.195296] GPR00: c00000000009c368 c0000000061ef8a0 c00000000116a700 0000000000000000 [ 21.195296] GPR04: 0000000000000000 0000000000000000 000000001ee30000 ffffffffffffffff [ 21.195296] GPR08: 000000001ee30000 0000000000000000 0000000000008002 7265677368657265 [ 21.195296] GPR12: c0000000000dc630 c00000001ffe5800 0000000000000000 0000000000000000 [ 21.195296] GPR16: 0000000000000282 0000000000000000 0000000000000000 c0000000061eff00 [ 21.195296] GPR20: 0000000000000000 0000000000000001 c0000000061b9f80 c000000001195a10 [ 21.195296] GPR24: c000000001193a00 00000000fffb6cc4 000000000000000a c0000000010721e8 [ 21.195296] GPR28: c000000001076800 c000000001070380 c0000000010716d8 c0000000061b9f80 [ 21.195850] NIP [c000000000013608] arch_local_irq_restore+0x168/0x170 [ 21.195944] LR [c0000000003f8114] __do_softirq+0xd4/0x2ec [ 21.196027] --- interrupt: 900 [ 21.196056] [c0000000061ef8a0] [c0000000061b9f80] 0xc0000000061b9f80 (unreliable) [ 21.196119] [c0000000061ef9b0] [c00000000009c368] irq_exit+0xc8/0x110 [ 21.196192] [c0000000061ef9d0] [c00000000001c858] timer_interrupt+0x178/0x2d0 [ 21.196282] [c0000000061efa20] [c0000000000098e8] decrementer_common_virt+0x208/0x210 [ 21.196373] --- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c [ 21.196439] NIP: c000000000072988 LR: c000000000074fa8 CTR: c000000000074f10 [ 21.196489] REGS: c0000000061efa90 TRAP: 0900 Not tainted (5.18.0-rc1) [ 21.196534] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28000202 XER: 00000000 [ 21.196627] CFAR: 0000000000000000 IRQMASK: 0 [ 21.196627] GPR00: 0000000028000202 c0000000061efd30 c00000000116a700 0000000000000000 [ 21.196627] GPR04: c00000001fea0280 ffffffffffffffff 0000000001f40000 000000019d088fcf [ 21.196627] GPR08: 000000001ee30000 c00000001ffe5400 0000000000000001 0000000100000000 [ 21.196627] GPR12: c000000000074f10 c00000001ffe5800 0000000000000000 0000000000000000 [ 21.196627] GPR16: 0000000000000000 0000000000000000 0000000000000000 c0000000061eff00 [ 21.196627] GPR20: c00000000003d440 0000000000000001 c000000001195b30 c000000001195a10 [ 21.196627] GPR24: 0000000000080000 c0000000061ba000 c000000001195a98 0000000000000001 [ 21.196627] GPR28: 0000000000000001 c0000000010716d0 c0000000010716d8 c0000000010716d0 [ 21.197168] NIP [c000000000072988] plpar_hcall_norets_notrace+0x18/0x2c [ 21.197239] LR [c000000000074fa8] pseries_lpar_idle+0x98/0x1b0 [ 21.197305] --- interrupt: 900 [ 21.197333] [c0000000061efd30] [0000000000000001] 0x1 (unreliable) [ 21.197390] [c0000000061efdb0] [c000000000018b54] arch_cpu_idle+0x44/0x180 [ 21.197470] [c0000000061efde0] [c0000000003f75bc] default_idle_call+0x4c/0x7c [ 21.197556] [c0000000061efe00] [c0000000000e1384] do_idle+0x114/0x1e0 [ 21.197620] [c0000000061efe60] [c0000000000e1664] cpu_startup_entry+0x34/0x40 [ 21.197696] [c0000000061efe90] [c00000000003f044] start_secondary+0x624/0xa00 [ 21.197820] [c0000000061eff90] [c00000000000cd54] start_secondary_prolog+0x10/0x1I4 ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: rcu_sched self-detected stall on CPU 2022-04-06 17:00 ` Paul E. McKenney @ 2022-04-08 7:23 ` Michael Ellerman 2022-04-08 14:42 ` Michael Ellerman 0 siblings, 1 reply; 1767+ messages in thread From: Michael Ellerman @ 2022-04-08 7:23 UTC (permalink / raw) To: paulmck, Zhouyi Zhou; +Cc: rcu, Miguel Ojeda, linuxppc-dev, Nicholas Piggin "Paul E. McKenney" <paulmck@kernel.org> writes: > On Wed, Apr 06, 2022 at 05:31:10PM +0800, Zhouyi Zhou wrote: >> Hi >> >> I can reproduce it in a ppc virtual cloud server provided by Oregon >> State University. Following is what I do: >> 1) curl -l https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapshot/linux-5.18-rc1.tar.gz >> -o linux-5.18-rc1.tar.gz >> 2) tar zxf linux-5.18-rc1.tar.gz >> 3) cp config linux-5.18-rc1/.config >> 4) cd linux-5.18-rc1 >> 5) make vmlinux -j 8 >> 6) qemu-system-ppc64 -kernel vmlinux -nographic -vga none -no-reboot >> -smp 2 (QEMU 4.2.1) >> 7) after 12 rounds, the bug got reproduced: >> (http://154.223.142.244/logs/20220406/qemu.log.txt) > > Just to make sure, are you both seeing the same thing? Last I knew, > Zhouyi was chasing an RCU-tasks issue that appears only in kernels > built with CONFIG_PROVE_RCU=y, which Miguel does not have set. Or did > I miss something? > > Miguel is instead seeing an RCU CPU stall warning where RCU's grace-period > kthread slept for three milliseconds, but did not wake up for more than > 20 seconds. This kthread would normally have awakened on CPU 1, but > CPU 1 looks to me to be very unhealthy, as can be seen in your console > output below (but maybe my idea of what is healthy for powerpc systems > is outdated). Please see also the inline annotations. > > Thoughts from the PPC guys? I haven't seen it in my testing. But using Miguel's config I can reproduce it seemingly on every boot. For me it bisects to: 35de589cb879 ("powerpc/time: improve decrementer clockevent processing") Which seems plausible. Reverting that on mainline makes the bug go away. I don't see an obvious bug in the diff, but I could be wrong, or the old code was papering over an existing bug? I'll try and work out what it is about Miguel's config that exposes this vs our defconfig, that might give us a clue. cheers ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: rcu_sched self-detected stall on CPU 2022-04-08 7:23 ` Michael Ellerman @ 2022-04-08 14:42 ` Michael Ellerman 2022-04-13 5:11 ` Nicholas Piggin 0 siblings, 1 reply; 1767+ messages in thread From: Michael Ellerman @ 2022-04-08 14:42 UTC (permalink / raw) To: paulmck, Zhouyi Zhou; +Cc: rcu, Miguel Ojeda, linuxppc-dev, Nicholas Piggin Michael Ellerman <mpe@ellerman.id.au> writes: > "Paul E. McKenney" <paulmck@kernel.org> writes: >> On Wed, Apr 06, 2022 at 05:31:10PM +0800, Zhouyi Zhou wrote: >>> Hi >>> >>> I can reproduce it in a ppc virtual cloud server provided by Oregon >>> State University. Following is what I do: >>> 1) curl -l https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapshot/linux-5.18-rc1.tar.gz >>> -o linux-5.18-rc1.tar.gz >>> 2) tar zxf linux-5.18-rc1.tar.gz >>> 3) cp config linux-5.18-rc1/.config >>> 4) cd linux-5.18-rc1 >>> 5) make vmlinux -j 8 >>> 6) qemu-system-ppc64 -kernel vmlinux -nographic -vga none -no-reboot >>> -smp 2 (QEMU 4.2.1) >>> 7) after 12 rounds, the bug got reproduced: >>> (http://154.223.142.244/logs/20220406/qemu.log.txt) >> >> Just to make sure, are you both seeing the same thing? Last I knew, >> Zhouyi was chasing an RCU-tasks issue that appears only in kernels >> built with CONFIG_PROVE_RCU=y, which Miguel does not have set. Or did >> I miss something? >> >> Miguel is instead seeing an RCU CPU stall warning where RCU's grace-period >> kthread slept for three milliseconds, but did not wake up for more than >> 20 seconds. This kthread would normally have awakened on CPU 1, but >> CPU 1 looks to me to be very unhealthy, as can be seen in your console >> output below (but maybe my idea of what is healthy for powerpc systems >> is outdated). Please see also the inline annotations. >> >> Thoughts from the PPC guys? > > I haven't seen it in my testing. But using Miguel's config I can > reproduce it seemingly on every boot. > > For me it bisects to: > > 35de589cb879 ("powerpc/time: improve decrementer clockevent processing") > > Which seems plausible. > > Reverting that on mainline makes the bug go away. > > I don't see an obvious bug in the diff, but I could be wrong, or the old > code was papering over an existing bug? > > I'll try and work out what it is about Miguel's config that exposes > this vs our defconfig, that might give us a clue. It's CONFIG_HIGH_RES_TIMERS=n which triggers the stall. I can reproduce just with: $ make ppc64le_guest_defconfig $ ./scripts/config -d HIGH_RES_TIMERS We have no defconfigs that disable HIGH_RES_TIMERS, I didn't even realise you could disable it TBH :) The Rust CI has it disabled because I copied that from the x86 defconfig they were using back when I added the Rust support. I think that was meant to be a stripped down fast config for CI, but the result is it's just using a badly tested combination which is not helpful. So I'll send a patch to turn HIGH_RES_TIMERS on for the Rust CI, and we can debug this further without blocking them. cheers ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) 2022-04-08 14:42 ` Michael Ellerman @ 2022-04-13 5:11 ` Nicholas Piggin 2022-04-22 15:53 ` Re: Thomas Gleixner 0 siblings, 1 reply; 1767+ messages in thread From: Nicholas Piggin @ 2022-04-13 5:11 UTC (permalink / raw) To: Michael Ellerman, paulmck, Zhouyi Zhou Cc: Viresh Kumar, Daniel Lezcano, linux-kernel, rcu, Miguel Ojeda, Thomas Gleixner, linuxppc-dev +Daniel, Thomas, Viresh Subject: Re: rcu_sched self-detected stall on CPU Excerpts from Michael Ellerman's message of April 9, 2022 12:42 am: > Michael Ellerman <mpe@ellerman.id.au> writes: >> "Paul E. McKenney" <paulmck@kernel.org> writes: >>> On Wed, Apr 06, 2022 at 05:31:10PM +0800, Zhouyi Zhou wrote: >>>> Hi >>>> >>>> I can reproduce it in a ppc virtual cloud server provided by Oregon >>>> State University. Following is what I do: >>>> 1) curl -l https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapshot/linux-5.18-rc1.tar.gz >>>> -o linux-5.18-rc1.tar.gz >>>> 2) tar zxf linux-5.18-rc1.tar.gz >>>> 3) cp config linux-5.18-rc1/.config >>>> 4) cd linux-5.18-rc1 >>>> 5) make vmlinux -j 8 >>>> 6) qemu-system-ppc64 -kernel vmlinux -nographic -vga none -no-reboot >>>> -smp 2 (QEMU 4.2.1) >>>> 7) after 12 rounds, the bug got reproduced: >>>> (http://154.223.142.244/logs/20220406/qemu.log.txt) >>> >>> Just to make sure, are you both seeing the same thing? Last I knew, >>> Zhouyi was chasing an RCU-tasks issue that appears only in kernels >>> built with CONFIG_PROVE_RCU=y, which Miguel does not have set. Or did >>> I miss something? >>> >>> Miguel is instead seeing an RCU CPU stall warning where RCU's grace-period >>> kthread slept for three milliseconds, but did not wake up for more than >>> 20 seconds. This kthread would normally have awakened on CPU 1, but >>> CPU 1 looks to me to be very unhealthy, as can be seen in your console >>> output below (but maybe my idea of what is healthy for powerpc systems >>> is outdated). Please see also the inline annotations. >>> >>> Thoughts from the PPC guys? >> >> I haven't seen it in my testing. But using Miguel's config I can >> reproduce it seemingly on every boot. >> >> For me it bisects to: >> >> 35de589cb879 ("powerpc/time: improve decrementer clockevent processing") >> >> Which seems plausible. >> >> Reverting that on mainline makes the bug go away. >> >> I don't see an obvious bug in the diff, but I could be wrong, or the old >> code was papering over an existing bug? >> >> I'll try and work out what it is about Miguel's config that exposes >> this vs our defconfig, that might give us a clue. > > It's CONFIG_HIGH_RES_TIMERS=n which triggers the stall. > > I can reproduce just with: > > $ make ppc64le_guest_defconfig > $ ./scripts/config -d HIGH_RES_TIMERS > > We have no defconfigs that disable HIGH_RES_TIMERS, I didn't even > realise you could disable it TBH :) > > The Rust CI has it disabled because I copied that from the x86 defconfig > they were using back when I added the Rust support. I think that was > meant to be a stripped down fast config for CI, but the result is it's > just using a badly tested combination which is not helpful. > > So I'll send a patch to turn HIGH_RES_TIMERS on for the Rust CI, and we > can debug this further without blocking them. So we traced the problem down to possibly a misunderstanding between decrementer clock event device and core code. The decrementer is only oneshot*ish*. It actually needs to either be reprogrammed or shut down otherwise it just continues to cause interrupts. Before commit 35de589cb879, it was sort of two-shot. The initial interrupt at the programmed time would set its internal next_tb variable to ~0 and call the ->event_handler(). If that did not set_next_event or stop the timer, the interrupt will fire again immediately, notice next_tb is ~0, and only then stop the decrementer interrupt. So that was already kind of ugly, this patch just turned it into a hang. The problem happens when the tick is stopped with an event still pending, then tick_nohz_handler() is called, but it bails out because tick_stopped == 1 so the device never gets programmed again, and so it keeps firing. How to fix it? Before commit a7cba02deced, powerpc's decrementer was really oneshot, but we would like to avoid doing that because it requires additional programming of the hardware on each timer interrupt. We have the ONESHOT_STOPPED state which seems to be just about what we want. Did the ONESHOT_STOPPED patch just miss this case, or is there a reason we don't stop it here? This patch seems to fix the hang (not heavily tested though). Thanks, Nick --- diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c index 2d76c91b85de..7e13a55b6b71 100644 --- a/kernel/time/tick-sched.c +++ b/kernel/time/tick-sched.c @@ -1364,9 +1364,11 @@ static void tick_nohz_handler(struct clock_event_device *dev) tick_sched_do_timer(ts, now); tick_sched_handle(ts, regs); - /* No need to reprogram if we are running tickless */ - if (unlikely(ts->tick_stopped)) + if (unlikely(ts->tick_stopped)) { + /* If we are tickless, change the clock event to stopped */ + tick_program_event(KTIME_MAX, 1); return; + } hrtimer_forward(&ts->sched_timer, now, TICK_NSEC); tick_program_event(hrtimer_get_expires(&ts->sched_timer), 1); ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2022-04-13 5:11 ` Nicholas Piggin @ 2022-04-22 15:53 ` Thomas Gleixner 0 siblings, 0 replies; 1767+ messages in thread From: Thomas Gleixner @ 2022-04-22 15:53 UTC (permalink / raw) To: Nicholas Piggin, Michael Ellerman, paulmck, Zhouyi Zhou Cc: Viresh Kumar, Daniel Lezcano, linux-kernel, rcu, Miguel Ojeda, linuxppc-dev On Wed, Apr 13 2022 at 15:11, Nicholas Piggin wrote: > So we traced the problem down to possibly a misunderstanding between > decrementer clock event device and core code. > > The decrementer is only oneshot*ish*. It actually needs to either be > reprogrammed or shut down otherwise it just continues to cause > interrupts. I always thought that PPC had sane timers. That's really disillusioning. > Before commit 35de589cb879, it was sort of two-shot. The initial > interrupt at the programmed time would set its internal next_tb variable > to ~0 and call the ->event_handler(). If that did not set_next_event or > stop the timer, the interrupt will fire again immediately, notice > next_tb is ~0, and only then stop the decrementer interrupt. > > So that was already kind of ugly, this patch just turned it into a hang. > > The problem happens when the tick is stopped with an event still > pending, then tick_nohz_handler() is called, but it bails out because > tick_stopped == 1 so the device never gets programmed again, and so it > keeps firing. > > How to fix it? Before commit a7cba02deced, powerpc's decrementer was > really oneshot, but we would like to avoid doing that because it requires > additional programming of the hardware on each timer interrupt. We have > the ONESHOT_STOPPED state which seems to be just about what we want. > > Did the ONESHOT_STOPPED patch just miss this case, or is there a reason > we don't stop it here? This patch seems to fix the hang (not heavily > tested though). This was definitely overlooked, but it's arguable it is is not required for real oneshot clockevent devices. This should only handle the case where the interrupt was already pending. The ONESHOT_STOPPED state was introduced to handle the case where the last timer gets canceled, so the already programmed event does not fire. It was not necessarily meant to "fix" clockevent devices which are pretending to be ONESHOT, but keep firing over and over. That, said. I'm fine with the change along with a big fat comment why this is required. Thanks, tglx ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2022-04-22 15:53 ` Thomas Gleixner 0 siblings, 0 replies; 1767+ messages in thread From: Thomas Gleixner @ 2022-04-22 15:53 UTC (permalink / raw) To: Nicholas Piggin, Michael Ellerman, paulmck, Zhouyi Zhou Cc: linuxppc-dev, Miguel Ojeda, rcu, Daniel Lezcano, linux-kernel, Viresh Kumar On Wed, Apr 13 2022 at 15:11, Nicholas Piggin wrote: > So we traced the problem down to possibly a misunderstanding between > decrementer clock event device and core code. > > The decrementer is only oneshot*ish*. It actually needs to either be > reprogrammed or shut down otherwise it just continues to cause > interrupts. I always thought that PPC had sane timers. That's really disillusioning. > Before commit 35de589cb879, it was sort of two-shot. The initial > interrupt at the programmed time would set its internal next_tb variable > to ~0 and call the ->event_handler(). If that did not set_next_event or > stop the timer, the interrupt will fire again immediately, notice > next_tb is ~0, and only then stop the decrementer interrupt. > > So that was already kind of ugly, this patch just turned it into a hang. > > The problem happens when the tick is stopped with an event still > pending, then tick_nohz_handler() is called, but it bails out because > tick_stopped == 1 so the device never gets programmed again, and so it > keeps firing. > > How to fix it? Before commit a7cba02deced, powerpc's decrementer was > really oneshot, but we would like to avoid doing that because it requires > additional programming of the hardware on each timer interrupt. We have > the ONESHOT_STOPPED state which seems to be just about what we want. > > Did the ONESHOT_STOPPED patch just miss this case, or is there a reason > we don't stop it here? This patch seems to fix the hang (not heavily > tested though). This was definitely overlooked, but it's arguable it is is not required for real oneshot clockevent devices. This should only handle the case where the interrupt was already pending. The ONESHOT_STOPPED state was introduced to handle the case where the last timer gets canceled, so the already programmed event does not fire. It was not necessarily meant to "fix" clockevent devices which are pretending to be ONESHOT, but keep firing over and over. That, said. I'm fine with the change along with a big fat comment why this is required. Thanks, tglx ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-04-22 15:53 ` Re: Thomas Gleixner @ 2022-04-23 2:29 ` Nicholas Piggin -1 siblings, 0 replies; 1767+ messages in thread From: Nicholas Piggin @ 2022-04-23 2:29 UTC (permalink / raw) To: Michael Ellerman, paulmck, Thomas Gleixner, Zhouyi Zhou Cc: Viresh, Kumar, Daniel, Lezcano, linux-kernel, rcu, Miguel Ojeda, linuxppc-dev Excerpts from Thomas Gleixner's message of April 23, 2022 1:53 am: > On Wed, Apr 13 2022 at 15:11, Nicholas Piggin wrote: >> So we traced the problem down to possibly a misunderstanding between >> decrementer clock event device and core code. >> >> The decrementer is only oneshot*ish*. It actually needs to either be >> reprogrammed or shut down otherwise it just continues to cause >> interrupts. > > I always thought that PPC had sane timers. That's really disillusioning. My comment was probably a bit misleading explanation of the whole situation. This weirdness is actually in software in the powerpc clock event driver due to a recent change I made assuming the clock event goes to oneshot-stopped. The hardware is relatively sane I think, global synchronized constant rate high frequency clock distributed to the CPUs so reads don't go off-core. And per-CPU "decrementer" event interrupt at the same frequency as the clock -- program it to a +ve value and it decrements until zero then creates basically a level triggered interrupt. Before my change, the decrementer interrupt would always clear the interrupt at entry. The event_handler usually programs another timer in so I tried to avoid that first clear counting on the oneshot_stopped callback to clear the interrupt if there was no other timer. >> Before commit 35de589cb879, it was sort of two-shot. The initial >> interrupt at the programmed time would set its internal next_tb variable >> to ~0 and call the ->event_handler(). If that did not set_next_event or >> stop the timer, the interrupt will fire again immediately, notice >> next_tb is ~0, and only then stop the decrementer interrupt. >> >> So that was already kind of ugly, this patch just turned it into a hang. >> >> The problem happens when the tick is stopped with an event still >> pending, then tick_nohz_handler() is called, but it bails out because >> tick_stopped == 1 so the device never gets programmed again, and so it >> keeps firing. >> >> How to fix it? Before commit a7cba02deced, powerpc's decrementer was >> really oneshot, but we would like to avoid doing that because it requires >> additional programming of the hardware on each timer interrupt. We have >> the ONESHOT_STOPPED state which seems to be just about what we want. >> >> Did the ONESHOT_STOPPED patch just miss this case, or is there a reason >> we don't stop it here? This patch seems to fix the hang (not heavily >> tested though). > > This was definitely overlooked, but it's arguable it is is not required > for real oneshot clockevent devices. This should only handle the case > where the interrupt was already pending. > > The ONESHOT_STOPPED state was introduced to handle the case where the > last timer gets canceled, so the already programmed event does not fire. > > It was not necessarily meant to "fix" clockevent devices which are > pretending to be ONESHOT, but keep firing over and over. > > That, said. I'm fine with the change along with a big fat comment why > this is required. Thanks for taking a look and confirming. I just sent a patch with a comment and what looks like another missed case. Hopefully it's okay. Thanks, Nick ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2022-04-23 2:29 ` Nicholas Piggin 0 siblings, 0 replies; 1767+ messages in thread From: Nicholas Piggin @ 2022-04-23 2:29 UTC (permalink / raw) To: Michael Ellerman, paulmck, Thomas Gleixner, Zhouyi Zhou Cc: Daniel, Lezcano, linux-kernel, linuxppc-dev, Miguel Ojeda, rcu, Viresh, Kumar Excerpts from Thomas Gleixner's message of April 23, 2022 1:53 am: > On Wed, Apr 13 2022 at 15:11, Nicholas Piggin wrote: >> So we traced the problem down to possibly a misunderstanding between >> decrementer clock event device and core code. >> >> The decrementer is only oneshot*ish*. It actually needs to either be >> reprogrammed or shut down otherwise it just continues to cause >> interrupts. > > I always thought that PPC had sane timers. That's really disillusioning. My comment was probably a bit misleading explanation of the whole situation. This weirdness is actually in software in the powerpc clock event driver due to a recent change I made assuming the clock event goes to oneshot-stopped. The hardware is relatively sane I think, global synchronized constant rate high frequency clock distributed to the CPUs so reads don't go off-core. And per-CPU "decrementer" event interrupt at the same frequency as the clock -- program it to a +ve value and it decrements until zero then creates basically a level triggered interrupt. Before my change, the decrementer interrupt would always clear the interrupt at entry. The event_handler usually programs another timer in so I tried to avoid that first clear counting on the oneshot_stopped callback to clear the interrupt if there was no other timer. >> Before commit 35de589cb879, it was sort of two-shot. The initial >> interrupt at the programmed time would set its internal next_tb variable >> to ~0 and call the ->event_handler(). If that did not set_next_event or >> stop the timer, the interrupt will fire again immediately, notice >> next_tb is ~0, and only then stop the decrementer interrupt. >> >> So that was already kind of ugly, this patch just turned it into a hang. >> >> The problem happens when the tick is stopped with an event still >> pending, then tick_nohz_handler() is called, but it bails out because >> tick_stopped == 1 so the device never gets programmed again, and so it >> keeps firing. >> >> How to fix it? Before commit a7cba02deced, powerpc's decrementer was >> really oneshot, but we would like to avoid doing that because it requires >> additional programming of the hardware on each timer interrupt. We have >> the ONESHOT_STOPPED state which seems to be just about what we want. >> >> Did the ONESHOT_STOPPED patch just miss this case, or is there a reason >> we don't stop it here? This patch seems to fix the hang (not heavily >> tested though). > > This was definitely overlooked, but it's arguable it is is not required > for real oneshot clockevent devices. This should only handle the case > where the interrupt was already pending. > > The ONESHOT_STOPPED state was introduced to handle the case where the > last timer gets canceled, so the already programmed event does not fire. > > It was not necessarily meant to "fix" clockevent devices which are > pretending to be ONESHOT, but keep firing over and over. > > That, said. I'm fine with the change along with a big fat comment why > this is required. Thanks for taking a look and confirming. I just sent a patch with a comment and what looks like another missed case. Hopefully it's okay. Thanks, Nick ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <Yj1hkpyUqJE9sQ2p@redhat.com>]
* Re: [not found] <Yj1hkpyUqJE9sQ2p@redhat.com> @ 2022-03-25 7:52 ` Jason Wang 2022-03-25 9:10 ` Re: Michael S. Tsirkin 0 siblings, 1 reply; 1767+ messages in thread From: Jason Wang @ 2022-03-25 7:52 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Paul E. McKenney, Peter Zijlstra, Marc Zyngier, Keir Fraser, linux-kernel, virtualization, Thomas Gleixner On Fri, Mar 25, 2022 at 2:31 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > Bcc: > Subject: Re: [PATCH 3/3] virtio: harden vring IRQ > Message-ID: <20220325021422-mutt-send-email-mst@kernel.org> > Reply-To: > In-Reply-To: <f7046303-7d7d-e39f-3c71-3688126cc812@redhat.com> > > On Fri, Mar 25, 2022 at 11:04:08AM +0800, Jason Wang wrote: > > > > 在 2022/3/24 下午7:03, Michael S. Tsirkin 写道: > > > On Thu, Mar 24, 2022 at 04:40:04PM +0800, Jason Wang wrote: > > > > This is a rework on the previous IRQ hardening that is done for > > > > virtio-pci where several drawbacks were found and were reverted: > > > > > > > > 1) try to use IRQF_NO_AUTOEN which is not friendly to affinity managed IRQ > > > > that is used by some device such as virtio-blk > > > > 2) done only for PCI transport > > > > > > > > In this patch, we tries to borrow the idea from the INTX IRQ hardening > > > > in the reverted commit 080cd7c3ac87 ("virtio-pci: harden INTX interrupts") > > > > by introducing a global irq_soft_enabled variable for each > > > > virtio_device. Then we can to toggle it during > > > > virtio_reset_device()/virtio_device_ready(). A synchornize_rcu() is > > > > used in virtio_reset_device() to synchronize with the IRQ handlers. In > > > > the future, we may provide config_ops for the transport that doesn't > > > > use IRQ. With this, vring_interrupt() can return check and early if > > > > irq_soft_enabled is false. This lead to smp_load_acquire() to be used > > > > but the cost should be acceptable. > > > Maybe it should be but is it? Can't we use synchronize_irq instead? > > > > > > Even if we allow the transport driver to synchornize through > > synchronize_irq() we still need a check in the vring_interrupt(). > > > > We do something like the following previously: > > > > if (!READ_ONCE(vp_dev->intx_soft_enabled)) > > return IRQ_NONE; > > > > But it looks like a bug since speculative read can be done before the check > > where the interrupt handler can't see the uncommitted setup which is done by > > the driver. > > I don't think so - if you sync after setting the value then > you are guaranteed that any handler running afterwards > will see the new value. The problem is not disabled but the enable. We use smp_store_relase() to make sure the driver commits the setup before enabling the irq. It means the read needs to be ordered as well in vring_interrupt(). > > Although I couldn't find anything about this in memory-barriers.txt > which surprises me. > > CC Paul to help make sure I'm right. > > > > > > > > > > > To avoid breaking legacy device which can send IRQ before DRIVER_OK, a > > > > module parameter is introduced to enable the hardening so function > > > > hardening is disabled by default. > > > Which devices are these? How come they send an interrupt before there > > > are any buffers in any queues? > > > > > > I copied this from the commit log for 22b7050a024d7 > > > > " > > > > This change will also benefit old hypervisors (before 2009) > > that send interrupts without checking DRIVER_OK: previously, > > the callback could race with driver-specific initialization. > > " > > > > If this is only for config interrupt, I can remove the above log. > > > This is only for config interrupt. Ok. > > > > > > > > > > Note that the hardening is only done for vring interrupt since the > > > > config interrupt hardening is already done in commit 22b7050a024d7 > > > > ("virtio: defer config changed notifications"). But the method that is > > > > used by config interrupt can't be reused by the vring interrupt > > > > handler because it uses spinlock to do the synchronization which is > > > > expensive. > > > > > > > > Signed-off-by: Jason Wang <jasowang@redhat.com> > > > > > > > --- > > > > drivers/virtio/virtio.c | 19 +++++++++++++++++++ > > > > drivers/virtio/virtio_ring.c | 9 ++++++++- > > > > include/linux/virtio.h | 4 ++++ > > > > include/linux/virtio_config.h | 25 +++++++++++++++++++++++++ > > > > 4 files changed, 56 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c > > > > index 8dde44ea044a..85e331efa9cc 100644 > > > > --- a/drivers/virtio/virtio.c > > > > +++ b/drivers/virtio/virtio.c > > > > @@ -7,6 +7,12 @@ > > > > #include <linux/of.h> > > > > #include <uapi/linux/virtio_ids.h> > > > > +static bool irq_hardening = false; > > > > + > > > > +module_param(irq_hardening, bool, 0444); > > > > +MODULE_PARM_DESC(irq_hardening, > > > > + "Disalbe IRQ software processing when it is not expected"); > > > > + > > > > /* Unique numbering for virtio devices. */ > > > > static DEFINE_IDA(virtio_index_ida); > > > > @@ -220,6 +226,15 @@ static int virtio_features_ok(struct virtio_device *dev) > > > > * */ > > > > void virtio_reset_device(struct virtio_device *dev) > > > > { > > > > + /* > > > > + * The below synchronize_rcu() guarantees that any > > > > + * interrupt for this line arriving after > > > > + * synchronize_rcu() has completed is guaranteed to see > > > > + * irq_soft_enabled == false. > > > News to me I did not know synchronize_rcu has anything to do > > > with interrupts. Did not you intend to use synchronize_irq? > > > I am not even 100% sure synchronize_rcu is by design a memory barrier > > > though it's most likely is ... > > > > > > According to the comment above tree RCU version of synchronize_rcu(): > > > > """ > > > > * RCU read-side critical sections are delimited by rcu_read_lock() > > * and rcu_read_unlock(), and may be nested. In addition, but only in > > * v5.0 and later, regions of code across which interrupts, preemption, > > * or softirqs have been disabled also serve as RCU read-side critical > > * sections. This includes hardware interrupt handlers, softirq handlers, > > * and NMI handlers. > > """ > > > > So interrupt handlers are treated as read-side critical sections. > > > > And it has the comment for explain the barrier: > > > > """ > > > > * Note that this guarantee implies further memory-ordering guarantees. > > * On systems with more than one CPU, when synchronize_rcu() returns, > > * each CPU is guaranteed to have executed a full memory barrier since > > * the end of its last RCU read-side critical section whose beginning > > * preceded the call to synchronize_rcu(). In addition, each CPU having > > """ > > > > So on SMP it provides a full barrier. And for UP/tiny RCU we don't need the > > barrier, if the interrupt come after WRITE_ONCE() it will see the > > irq_soft_enabled as false. > > > > You are right. So then > 1. I do not think we need load_acquire - why is it needed? Just > READ_ONCE should do. See above. > 2. isn't synchronize_irq also doing the same thing? Yes, but it requires a config ops since the IRQ knowledge is transport specific. > > > > > > > > > + */ > > > > + WRITE_ONCE(dev->irq_soft_enabled, false); > > > > + synchronize_rcu(); > > > > + > > > > dev->config->reset(dev); > > > > } > > > > EXPORT_SYMBOL_GPL(virtio_reset_device); > > > Please add comment explaining where it will be enabled. > > > Also, we *really* don't need to synch if it was already disabled, > > > let's not add useless overhead to the boot sequence. > > > > > > Ok. > > > > > > > > > > > > > > @@ -427,6 +442,10 @@ int register_virtio_device(struct virtio_device *dev) > > > > spin_lock_init(&dev->config_lock); > > > > dev->config_enabled = false; > > > > dev->config_change_pending = false; > > > > + dev->irq_soft_check = irq_hardening; > > > > + > > > > + if (dev->irq_soft_check) > > > > + dev_info(&dev->dev, "IRQ hardening is enabled\n"); > > > > /* We always start by resetting the device, in case a previous > > > > * driver messed it up. This also tests that code path a little. */ > > > one of the points of hardening is it's also helpful for buggy > > > devices. this flag defeats the purpose. > > > > > > Do you mean: > > > > 1) we need something like config_enable? This seems not easy to be > > implemented without obvious overhead, mainly the synchronize with the > > interrupt handlers > > But synchronize is only on tear-down path. That is not critical for any > users at the moment, even less than probe. I meant if we have vq->irq_pending, we need to call vring_interrupt() in the virtio_device_ready() and synchronize the IRQ handlers with spinlock or others. > > > 2) enable this by default, so I don't object, but this may have some risk > > for old hypervisors > > > The risk if there's a driver adding buffers without setting DRIVER_OK. Probably not, we have devices that accept random inputs from outside, net, console, input etc. I've done a round of audits of the Qemu codes. They look all fine since day0. > So with this approach, how about we rename the flag "driver_ok"? > And then add_buf can actually test it and BUG_ON if not there (at least > in the debug build). This looks like a hardening of the driver in the core instead of the device. I think it can be done but in a separate series. > > And going down from there, how about we cache status in the > device? Then we don't need to keep re-reading it every time, > speeding boot up a tiny bit. I don't fully understand here, actually spec requires status to be read back for validation in many cases. Thanks > > > > > > > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > > > index 962f1477b1fa..0170f8c784d8 100644 > > > > --- a/drivers/virtio/virtio_ring.c > > > > +++ b/drivers/virtio/virtio_ring.c > > > > @@ -2144,10 +2144,17 @@ static inline bool more_used(const struct vring_virtqueue *vq) > > > > return vq->packed_ring ? more_used_packed(vq) : more_used_split(vq); > > > > } > > > > -irqreturn_t vring_interrupt(int irq, void *_vq) > > > > +irqreturn_t vring_interrupt(int irq, void *v) > > > > { > > > > + struct virtqueue *_vq = v; > > > > + struct virtio_device *vdev = _vq->vdev; > > > > struct vring_virtqueue *vq = to_vvq(_vq); > > > > + if (!virtio_irq_soft_enabled(vdev)) { > > > > + dev_warn_once(&vdev->dev, "virtio vring IRQ raised before DRIVER_OK"); > > > > + return IRQ_NONE; > > > > + } > > > > + > > > > if (!more_used(vq)) { > > > > pr_debug("virtqueue interrupt with no work for %p\n", vq); > > > > return IRQ_NONE; > > > > diff --git a/include/linux/virtio.h b/include/linux/virtio.h > > > > index 5464f398912a..957d6ad604ac 100644 > > > > --- a/include/linux/virtio.h > > > > +++ b/include/linux/virtio.h > > > > @@ -95,6 +95,8 @@ dma_addr_t virtqueue_get_used_addr(struct virtqueue *vq); > > > > * @failed: saved value for VIRTIO_CONFIG_S_FAILED bit (for restore) > > > > * @config_enabled: configuration change reporting enabled > > > > * @config_change_pending: configuration change reported while disabled > > > > + * @irq_soft_check: whether or not to check @irq_soft_enabled > > > > + * @irq_soft_enabled: callbacks enabled > > > > * @config_lock: protects configuration change reporting > > > > * @dev: underlying device. > > > > * @id: the device type identification (used to match it with a driver). > > > > @@ -109,6 +111,8 @@ struct virtio_device { > > > > bool failed; > > > > bool config_enabled; > > > > bool config_change_pending; > > > > + bool irq_soft_check; > > > > + bool irq_soft_enabled; > > > > spinlock_t config_lock; > > > > spinlock_t vqs_list_lock; /* Protects VQs list access */ > > > > struct device dev; > > > > diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h > > > > index dafdc7f48c01..9c1b61f2e525 100644 > > > > --- a/include/linux/virtio_config.h > > > > +++ b/include/linux/virtio_config.h > > > > @@ -174,6 +174,24 @@ static inline bool virtio_has_feature(const struct virtio_device *vdev, > > > > return __virtio_test_bit(vdev, fbit); > > > > } > > > > +/* > > > > + * virtio_irq_soft_enabled: whether we can execute callbacks > > > > + * @vdev: the device > > > > + */ > > > > +static inline bool virtio_irq_soft_enabled(const struct virtio_device *vdev) > > > > +{ > > > > + if (!vdev->irq_soft_check) > > > > + return true; > > > > + > > > > + /* > > > > + * Read irq_soft_enabled before reading other device specific > > > > + * data. Paried with smp_store_relase() in > > > paired > > > > > > Will fix. > > > > Thanks > > > > > > > > > > > + * virtio_device_ready() and WRITE_ONCE()/synchronize_rcu() in > > > > + * virtio_reset_device(). > > > > + */ > > > > + return smp_load_acquire(&vdev->irq_soft_enabled); > > > > +} > > > > + > > > > /** > > > > * virtio_has_dma_quirk - determine whether this device has the DMA quirk > > > > * @vdev: the device > > > > @@ -236,6 +254,13 @@ void virtio_device_ready(struct virtio_device *dev) > > > > if (dev->config->enable_cbs) > > > > dev->config->enable_cbs(dev); > > > > + /* > > > > + * Commit the driver setup before enabling the virtqueue > > > > + * callbacks. Paried with smp_load_acuqire() in > > > > + * virtio_irq_soft_enabled() > > > > + */ > > > > + smp_store_release(&dev->irq_soft_enabled, true); > > > > + > > > > BUG_ON(status & VIRTIO_CONFIG_S_DRIVER_OK); > > > > dev->config->set_status(dev, status | VIRTIO_CONFIG_S_DRIVER_OK); > > > > } > > > > -- > > > > 2.25.1 > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-03-25 7:52 ` Re: Jason Wang @ 2022-03-25 9:10 ` Michael S. Tsirkin 2022-03-25 9:20 ` Re: Jason Wang 0 siblings, 1 reply; 1767+ messages in thread From: Michael S. Tsirkin @ 2022-03-25 9:10 UTC (permalink / raw) To: Jason Wang Cc: Paul E. McKenney, Peter Zijlstra, Marc Zyngier, Keir Fraser, linux-kernel, virtualization, Thomas Gleixner On Fri, Mar 25, 2022 at 03:52:00PM +0800, Jason Wang wrote: > On Fri, Mar 25, 2022 at 2:31 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > Bcc: > > Subject: Re: [PATCH 3/3] virtio: harden vring IRQ > > Message-ID: <20220325021422-mutt-send-email-mst@kernel.org> > > Reply-To: > > In-Reply-To: <f7046303-7d7d-e39f-3c71-3688126cc812@redhat.com> > > > > On Fri, Mar 25, 2022 at 11:04:08AM +0800, Jason Wang wrote: > > > > > > 在 2022/3/24 下午7:03, Michael S. Tsirkin 写道: > > > > On Thu, Mar 24, 2022 at 04:40:04PM +0800, Jason Wang wrote: > > > > > This is a rework on the previous IRQ hardening that is done for > > > > > virtio-pci where several drawbacks were found and were reverted: > > > > > > > > > > 1) try to use IRQF_NO_AUTOEN which is not friendly to affinity managed IRQ > > > > > that is used by some device such as virtio-blk > > > > > 2) done only for PCI transport > > > > > > > > > > In this patch, we tries to borrow the idea from the INTX IRQ hardening > > > > > in the reverted commit 080cd7c3ac87 ("virtio-pci: harden INTX interrupts") > > > > > by introducing a global irq_soft_enabled variable for each > > > > > virtio_device. Then we can to toggle it during > > > > > virtio_reset_device()/virtio_device_ready(). A synchornize_rcu() is > > > > > used in virtio_reset_device() to synchronize with the IRQ handlers. In > > > > > the future, we may provide config_ops for the transport that doesn't > > > > > use IRQ. With this, vring_interrupt() can return check and early if > > > > > irq_soft_enabled is false. This lead to smp_load_acquire() to be used > > > > > but the cost should be acceptable. > > > > Maybe it should be but is it? Can't we use synchronize_irq instead? > > > > > > > > > Even if we allow the transport driver to synchornize through > > > synchronize_irq() we still need a check in the vring_interrupt(). > > > > > > We do something like the following previously: > > > > > > if (!READ_ONCE(vp_dev->intx_soft_enabled)) > > > return IRQ_NONE; > > > > > > But it looks like a bug since speculative read can be done before the check > > > where the interrupt handler can't see the uncommitted setup which is done by > > > the driver. > > > > I don't think so - if you sync after setting the value then > > you are guaranteed that any handler running afterwards > > will see the new value. > > The problem is not disabled but the enable. So a misbehaving device can lose interrupts? That's not a problem at all imo. > We use smp_store_relase() > to make sure the driver commits the setup before enabling the irq. It > means the read needs to be ordered as well in vring_interrupt(). > > > > > Although I couldn't find anything about this in memory-barriers.txt > > which surprises me. > > > > CC Paul to help make sure I'm right. > > > > > > > > > > > > > > > > To avoid breaking legacy device which can send IRQ before DRIVER_OK, a > > > > > module parameter is introduced to enable the hardening so function > > > > > hardening is disabled by default. > > > > Which devices are these? How come they send an interrupt before there > > > > are any buffers in any queues? > > > > > > > > > I copied this from the commit log for 22b7050a024d7 > > > > > > " > > > > > > This change will also benefit old hypervisors (before 2009) > > > that send interrupts without checking DRIVER_OK: previously, > > > the callback could race with driver-specific initialization. > > > " > > > > > > If this is only for config interrupt, I can remove the above log. > > > > > > This is only for config interrupt. > > Ok. > > > > > > > > > > > > > > > Note that the hardening is only done for vring interrupt since the > > > > > config interrupt hardening is already done in commit 22b7050a024d7 > > > > > ("virtio: defer config changed notifications"). But the method that is > > > > > used by config interrupt can't be reused by the vring interrupt > > > > > handler because it uses spinlock to do the synchronization which is > > > > > expensive. > > > > > > > > > > Signed-off-by: Jason Wang <jasowang@redhat.com> > > > > > > > > > --- > > > > > drivers/virtio/virtio.c | 19 +++++++++++++++++++ > > > > > drivers/virtio/virtio_ring.c | 9 ++++++++- > > > > > include/linux/virtio.h | 4 ++++ > > > > > include/linux/virtio_config.h | 25 +++++++++++++++++++++++++ > > > > > 4 files changed, 56 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c > > > > > index 8dde44ea044a..85e331efa9cc 100644 > > > > > --- a/drivers/virtio/virtio.c > > > > > +++ b/drivers/virtio/virtio.c > > > > > @@ -7,6 +7,12 @@ > > > > > #include <linux/of.h> > > > > > #include <uapi/linux/virtio_ids.h> > > > > > +static bool irq_hardening = false; > > > > > + > > > > > +module_param(irq_hardening, bool, 0444); > > > > > +MODULE_PARM_DESC(irq_hardening, > > > > > + "Disalbe IRQ software processing when it is not expected"); > > > > > + > > > > > /* Unique numbering for virtio devices. */ > > > > > static DEFINE_IDA(virtio_index_ida); > > > > > @@ -220,6 +226,15 @@ static int virtio_features_ok(struct virtio_device *dev) > > > > > * */ > > > > > void virtio_reset_device(struct virtio_device *dev) > > > > > { > > > > > + /* > > > > > + * The below synchronize_rcu() guarantees that any > > > > > + * interrupt for this line arriving after > > > > > + * synchronize_rcu() has completed is guaranteed to see > > > > > + * irq_soft_enabled == false. > > > > News to me I did not know synchronize_rcu has anything to do > > > > with interrupts. Did not you intend to use synchronize_irq? > > > > I am not even 100% sure synchronize_rcu is by design a memory barrier > > > > though it's most likely is ... > > > > > > > > > According to the comment above tree RCU version of synchronize_rcu(): > > > > > > """ > > > > > > * RCU read-side critical sections are delimited by rcu_read_lock() > > > * and rcu_read_unlock(), and may be nested. In addition, but only in > > > * v5.0 and later, regions of code across which interrupts, preemption, > > > * or softirqs have been disabled also serve as RCU read-side critical > > > * sections. This includes hardware interrupt handlers, softirq handlers, > > > * and NMI handlers. > > > """ > > > > > > So interrupt handlers are treated as read-side critical sections. > > > > > > And it has the comment for explain the barrier: > > > > > > """ > > > > > > * Note that this guarantee implies further memory-ordering guarantees. > > > * On systems with more than one CPU, when synchronize_rcu() returns, > > > * each CPU is guaranteed to have executed a full memory barrier since > > > * the end of its last RCU read-side critical section whose beginning > > > * preceded the call to synchronize_rcu(). In addition, each CPU having > > > """ > > > > > > So on SMP it provides a full barrier. And for UP/tiny RCU we don't need the > > > barrier, if the interrupt come after WRITE_ONCE() it will see the > > > irq_soft_enabled as false. > > > > > > > You are right. So then > > 1. I do not think we need load_acquire - why is it needed? Just > > READ_ONCE should do. > > See above. > > > 2. isn't synchronize_irq also doing the same thing? > > > Yes, but it requires a config ops since the IRQ knowledge is transport specific. > > > > > > > > > > > > > > + */ > > > > > + WRITE_ONCE(dev->irq_soft_enabled, false); > > > > > + synchronize_rcu(); > > > > > + > > > > > dev->config->reset(dev); > > > > > } > > > > > EXPORT_SYMBOL_GPL(virtio_reset_device); > > > > Please add comment explaining where it will be enabled. > > > > Also, we *really* don't need to synch if it was already disabled, > > > > let's not add useless overhead to the boot sequence. > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > @@ -427,6 +442,10 @@ int register_virtio_device(struct virtio_device *dev) > > > > > spin_lock_init(&dev->config_lock); > > > > > dev->config_enabled = false; > > > > > dev->config_change_pending = false; > > > > > + dev->irq_soft_check = irq_hardening; > > > > > + > > > > > + if (dev->irq_soft_check) > > > > > + dev_info(&dev->dev, "IRQ hardening is enabled\n"); > > > > > /* We always start by resetting the device, in case a previous > > > > > * driver messed it up. This also tests that code path a little. */ > > > > one of the points of hardening is it's also helpful for buggy > > > > devices. this flag defeats the purpose. > > > > > > > > > Do you mean: > > > > > > 1) we need something like config_enable? This seems not easy to be > > > implemented without obvious overhead, mainly the synchronize with the > > > interrupt handlers > > > > But synchronize is only on tear-down path. That is not critical for any > > users at the moment, even less than probe. > > I meant if we have vq->irq_pending, we need to call vring_interrupt() > in the virtio_device_ready() and synchronize the IRQ handlers with > spinlock or others. > > > > > > 2) enable this by default, so I don't object, but this may have some risk > > > for old hypervisors > > > > > > The risk if there's a driver adding buffers without setting DRIVER_OK. > > Probably not, we have devices that accept random inputs from outside, > net, console, input etc. I've done a round of audits of the Qemu > codes. They look all fine since day0. > > > So with this approach, how about we rename the flag "driver_ok"? > > And then add_buf can actually test it and BUG_ON if not there (at least > > in the debug build). > > This looks like a hardening of the driver in the core instead of the > device. I think it can be done but in a separate series. > > > > > And going down from there, how about we cache status in the > > device? Then we don't need to keep re-reading it every time, > > speeding boot up a tiny bit. > > I don't fully understand here, actually spec requires status to be > read back for validation in many cases. > > Thanks > > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > > > > index 962f1477b1fa..0170f8c784d8 100644 > > > > > --- a/drivers/virtio/virtio_ring.c > > > > > +++ b/drivers/virtio/virtio_ring.c > > > > > @@ -2144,10 +2144,17 @@ static inline bool more_used(const struct vring_virtqueue *vq) > > > > > return vq->packed_ring ? more_used_packed(vq) : more_used_split(vq); > > > > > } > > > > > -irqreturn_t vring_interrupt(int irq, void *_vq) > > > > > +irqreturn_t vring_interrupt(int irq, void *v) > > > > > { > > > > > + struct virtqueue *_vq = v; > > > > > + struct virtio_device *vdev = _vq->vdev; > > > > > struct vring_virtqueue *vq = to_vvq(_vq); > > > > > + if (!virtio_irq_soft_enabled(vdev)) { > > > > > + dev_warn_once(&vdev->dev, "virtio vring IRQ raised before DRIVER_OK"); > > > > > + return IRQ_NONE; > > > > > + } > > > > > + > > > > > if (!more_used(vq)) { > > > > > pr_debug("virtqueue interrupt with no work for %p\n", vq); > > > > > return IRQ_NONE; > > > > > diff --git a/include/linux/virtio.h b/include/linux/virtio.h > > > > > index 5464f398912a..957d6ad604ac 100644 > > > > > --- a/include/linux/virtio.h > > > > > +++ b/include/linux/virtio.h > > > > > @@ -95,6 +95,8 @@ dma_addr_t virtqueue_get_used_addr(struct virtqueue *vq); > > > > > * @failed: saved value for VIRTIO_CONFIG_S_FAILED bit (for restore) > > > > > * @config_enabled: configuration change reporting enabled > > > > > * @config_change_pending: configuration change reported while disabled > > > > > + * @irq_soft_check: whether or not to check @irq_soft_enabled > > > > > + * @irq_soft_enabled: callbacks enabled > > > > > * @config_lock: protects configuration change reporting > > > > > * @dev: underlying device. > > > > > * @id: the device type identification (used to match it with a driver). > > > > > @@ -109,6 +111,8 @@ struct virtio_device { > > > > > bool failed; > > > > > bool config_enabled; > > > > > bool config_change_pending; > > > > > + bool irq_soft_check; > > > > > + bool irq_soft_enabled; > > > > > spinlock_t config_lock; > > > > > spinlock_t vqs_list_lock; /* Protects VQs list access */ > > > > > struct device dev; > > > > > diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h > > > > > index dafdc7f48c01..9c1b61f2e525 100644 > > > > > --- a/include/linux/virtio_config.h > > > > > +++ b/include/linux/virtio_config.h > > > > > @@ -174,6 +174,24 @@ static inline bool virtio_has_feature(const struct virtio_device *vdev, > > > > > return __virtio_test_bit(vdev, fbit); > > > > > } > > > > > +/* > > > > > + * virtio_irq_soft_enabled: whether we can execute callbacks > > > > > + * @vdev: the device > > > > > + */ > > > > > +static inline bool virtio_irq_soft_enabled(const struct virtio_device *vdev) > > > > > +{ > > > > > + if (!vdev->irq_soft_check) > > > > > + return true; > > > > > + > > > > > + /* > > > > > + * Read irq_soft_enabled before reading other device specific > > > > > + * data. Paried with smp_store_relase() in > > > > paired > > > > > > > > > Will fix. > > > > > > Thanks > > > > > > > > > > > > > > > + * virtio_device_ready() and WRITE_ONCE()/synchronize_rcu() in > > > > > + * virtio_reset_device(). > > > > > + */ > > > > > + return smp_load_acquire(&vdev->irq_soft_enabled); > > > > > +} > > > > > + > > > > > /** > > > > > * virtio_has_dma_quirk - determine whether this device has the DMA quirk > > > > > * @vdev: the device > > > > > @@ -236,6 +254,13 @@ void virtio_device_ready(struct virtio_device *dev) > > > > > if (dev->config->enable_cbs) > > > > > dev->config->enable_cbs(dev); > > > > > + /* > > > > > + * Commit the driver setup before enabling the virtqueue > > > > > + * callbacks. Paried with smp_load_acuqire() in > > > > > + * virtio_irq_soft_enabled() > > > > > + */ > > > > > + smp_store_release(&dev->irq_soft_enabled, true); > > > > > + > > > > > BUG_ON(status & VIRTIO_CONFIG_S_DRIVER_OK); > > > > > dev->config->set_status(dev, status | VIRTIO_CONFIG_S_DRIVER_OK); > > > > > } > > > > > -- > > > > > 2.25.1 > > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-03-25 9:10 ` Re: Michael S. Tsirkin @ 2022-03-25 9:20 ` Jason Wang 2022-03-25 10:09 ` Re: Michael S. Tsirkin 0 siblings, 1 reply; 1767+ messages in thread From: Jason Wang @ 2022-03-25 9:20 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Paul E. McKenney, Peter Zijlstra, Marc Zyngier, Keir Fraser, linux-kernel, virtualization, Thomas Gleixner On Fri, Mar 25, 2022 at 5:10 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > On Fri, Mar 25, 2022 at 03:52:00PM +0800, Jason Wang wrote: > > On Fri, Mar 25, 2022 at 2:31 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > Bcc: > > > Subject: Re: [PATCH 3/3] virtio: harden vring IRQ > > > Message-ID: <20220325021422-mutt-send-email-mst@kernel.org> > > > Reply-To: > > > In-Reply-To: <f7046303-7d7d-e39f-3c71-3688126cc812@redhat.com> > > > > > > On Fri, Mar 25, 2022 at 11:04:08AM +0800, Jason Wang wrote: > > > > > > > > 在 2022/3/24 下午7:03, Michael S. Tsirkin 写道: > > > > > On Thu, Mar 24, 2022 at 04:40:04PM +0800, Jason Wang wrote: > > > > > > This is a rework on the previous IRQ hardening that is done for > > > > > > virtio-pci where several drawbacks were found and were reverted: > > > > > > > > > > > > 1) try to use IRQF_NO_AUTOEN which is not friendly to affinity managed IRQ > > > > > > that is used by some device such as virtio-blk > > > > > > 2) done only for PCI transport > > > > > > > > > > > > In this patch, we tries to borrow the idea from the INTX IRQ hardening > > > > > > in the reverted commit 080cd7c3ac87 ("virtio-pci: harden INTX interrupts") > > > > > > by introducing a global irq_soft_enabled variable for each > > > > > > virtio_device. Then we can to toggle it during > > > > > > virtio_reset_device()/virtio_device_ready(). A synchornize_rcu() is > > > > > > used in virtio_reset_device() to synchronize with the IRQ handlers. In > > > > > > the future, we may provide config_ops for the transport that doesn't > > > > > > use IRQ. With this, vring_interrupt() can return check and early if > > > > > > irq_soft_enabled is false. This lead to smp_load_acquire() to be used > > > > > > but the cost should be acceptable. > > > > > Maybe it should be but is it? Can't we use synchronize_irq instead? > > > > > > > > > > > > Even if we allow the transport driver to synchornize through > > > > synchronize_irq() we still need a check in the vring_interrupt(). > > > > > > > > We do something like the following previously: > > > > > > > > if (!READ_ONCE(vp_dev->intx_soft_enabled)) > > > > return IRQ_NONE; > > > > > > > > But it looks like a bug since speculative read can be done before the check > > > > where the interrupt handler can't see the uncommitted setup which is done by > > > > the driver. > > > > > > I don't think so - if you sync after setting the value then > > > you are guaranteed that any handler running afterwards > > > will see the new value. > > > > The problem is not disabled but the enable. > > So a misbehaving device can lose interrupts? That's not a problem at all > imo. It's the interrupt raised before setting irq_soft_enabled to true: CPU 0 probe) driver specific setup (not commited) CPU 1 IRQ handler) read the uninitialized variable CPU 0 probe) set irq_soft_enabled to true CPU 1 IRQ handler) read irq_soft_enable as true CPU 1 IRQ handler) use the uninitialized variable Thanks > > > We use smp_store_relase() > > to make sure the driver commits the setup before enabling the irq. It > > means the read needs to be ordered as well in vring_interrupt(). > > > > > > > > Although I couldn't find anything about this in memory-barriers.txt > > > which surprises me. > > > > > > CC Paul to help make sure I'm right. > > > > > > > > > > > > > > > > > > > > > To avoid breaking legacy device which can send IRQ before DRIVER_OK, a > > > > > > module parameter is introduced to enable the hardening so function > > > > > > hardening is disabled by default. > > > > > Which devices are these? How come they send an interrupt before there > > > > > are any buffers in any queues? > > > > > > > > > > > > I copied this from the commit log for 22b7050a024d7 > > > > > > > > " > > > > > > > > This change will also benefit old hypervisors (before 2009) > > > > that send interrupts without checking DRIVER_OK: previously, > > > > the callback could race with driver-specific initialization. > > > > " > > > > > > > > If this is only for config interrupt, I can remove the above log. > > > > > > > > > This is only for config interrupt. > > > > Ok. > > > > > > > > > > > > > > > > > > > > Note that the hardening is only done for vring interrupt since the > > > > > > config interrupt hardening is already done in commit 22b7050a024d7 > > > > > > ("virtio: defer config changed notifications"). But the method that is > > > > > > used by config interrupt can't be reused by the vring interrupt > > > > > > handler because it uses spinlock to do the synchronization which is > > > > > > expensive. > > > > > > > > > > > > Signed-off-by: Jason Wang <jasowang@redhat.com> > > > > > > > > > > > --- > > > > > > drivers/virtio/virtio.c | 19 +++++++++++++++++++ > > > > > > drivers/virtio/virtio_ring.c | 9 ++++++++- > > > > > > include/linux/virtio.h | 4 ++++ > > > > > > include/linux/virtio_config.h | 25 +++++++++++++++++++++++++ > > > > > > 4 files changed, 56 insertions(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c > > > > > > index 8dde44ea044a..85e331efa9cc 100644 > > > > > > --- a/drivers/virtio/virtio.c > > > > > > +++ b/drivers/virtio/virtio.c > > > > > > @@ -7,6 +7,12 @@ > > > > > > #include <linux/of.h> > > > > > > #include <uapi/linux/virtio_ids.h> > > > > > > +static bool irq_hardening = false; > > > > > > + > > > > > > +module_param(irq_hardening, bool, 0444); > > > > > > +MODULE_PARM_DESC(irq_hardening, > > > > > > + "Disalbe IRQ software processing when it is not expected"); > > > > > > + > > > > > > /* Unique numbering for virtio devices. */ > > > > > > static DEFINE_IDA(virtio_index_ida); > > > > > > @@ -220,6 +226,15 @@ static int virtio_features_ok(struct virtio_device *dev) > > > > > > * */ > > > > > > void virtio_reset_device(struct virtio_device *dev) > > > > > > { > > > > > > + /* > > > > > > + * The below synchronize_rcu() guarantees that any > > > > > > + * interrupt for this line arriving after > > > > > > + * synchronize_rcu() has completed is guaranteed to see > > > > > > + * irq_soft_enabled == false. > > > > > News to me I did not know synchronize_rcu has anything to do > > > > > with interrupts. Did not you intend to use synchronize_irq? > > > > > I am not even 100% sure synchronize_rcu is by design a memory barrier > > > > > though it's most likely is ... > > > > > > > > > > > > According to the comment above tree RCU version of synchronize_rcu(): > > > > > > > > """ > > > > > > > > * RCU read-side critical sections are delimited by rcu_read_lock() > > > > * and rcu_read_unlock(), and may be nested. In addition, but only in > > > > * v5.0 and later, regions of code across which interrupts, preemption, > > > > * or softirqs have been disabled also serve as RCU read-side critical > > > > * sections. This includes hardware interrupt handlers, softirq handlers, > > > > * and NMI handlers. > > > > """ > > > > > > > > So interrupt handlers are treated as read-side critical sections. > > > > > > > > And it has the comment for explain the barrier: > > > > > > > > """ > > > > > > > > * Note that this guarantee implies further memory-ordering guarantees. > > > > * On systems with more than one CPU, when synchronize_rcu() returns, > > > > * each CPU is guaranteed to have executed a full memory barrier since > > > > * the end of its last RCU read-side critical section whose beginning > > > > * preceded the call to synchronize_rcu(). In addition, each CPU having > > > > """ > > > > > > > > So on SMP it provides a full barrier. And for UP/tiny RCU we don't need the > > > > barrier, if the interrupt come after WRITE_ONCE() it will see the > > > > irq_soft_enabled as false. > > > > > > > > > > You are right. So then > > > 1. I do not think we need load_acquire - why is it needed? Just > > > READ_ONCE should do. > > > > See above. > > > > > 2. isn't synchronize_irq also doing the same thing? > > > > > > Yes, but it requires a config ops since the IRQ knowledge is transport specific. > > > > > > > > > > > > > > > > > > > + */ > > > > > > + WRITE_ONCE(dev->irq_soft_enabled, false); > > > > > > + synchronize_rcu(); > > > > > > + > > > > > > dev->config->reset(dev); > > > > > > } > > > > > > EXPORT_SYMBOL_GPL(virtio_reset_device); > > > > > Please add comment explaining where it will be enabled. > > > > > Also, we *really* don't need to synch if it was already disabled, > > > > > let's not add useless overhead to the boot sequence. > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > > > @@ -427,6 +442,10 @@ int register_virtio_device(struct virtio_device *dev) > > > > > > spin_lock_init(&dev->config_lock); > > > > > > dev->config_enabled = false; > > > > > > dev->config_change_pending = false; > > > > > > + dev->irq_soft_check = irq_hardening; > > > > > > + > > > > > > + if (dev->irq_soft_check) > > > > > > + dev_info(&dev->dev, "IRQ hardening is enabled\n"); > > > > > > /* We always start by resetting the device, in case a previous > > > > > > * driver messed it up. This also tests that code path a little. */ > > > > > one of the points of hardening is it's also helpful for buggy > > > > > devices. this flag defeats the purpose. > > > > > > > > > > > > Do you mean: > > > > > > > > 1) we need something like config_enable? This seems not easy to be > > > > implemented without obvious overhead, mainly the synchronize with the > > > > interrupt handlers > > > > > > But synchronize is only on tear-down path. That is not critical for any > > > users at the moment, even less than probe. > > > > I meant if we have vq->irq_pending, we need to call vring_interrupt() > > in the virtio_device_ready() and synchronize the IRQ handlers with > > spinlock or others. > > > > > > > > > 2) enable this by default, so I don't object, but this may have some risk > > > > for old hypervisors > > > > > > > > > The risk if there's a driver adding buffers without setting DRIVER_OK. > > > > Probably not, we have devices that accept random inputs from outside, > > net, console, input etc. I've done a round of audits of the Qemu > > codes. They look all fine since day0. > > > > > So with this approach, how about we rename the flag "driver_ok"? > > > And then add_buf can actually test it and BUG_ON if not there (at least > > > in the debug build). > > > > This looks like a hardening of the driver in the core instead of the > > device. I think it can be done but in a separate series. > > > > > > > > And going down from there, how about we cache status in the > > > device? Then we don't need to keep re-reading it every time, > > > speeding boot up a tiny bit. > > > > I don't fully understand here, actually spec requires status to be > > read back for validation in many cases. > > > > Thanks > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > > > > > index 962f1477b1fa..0170f8c784d8 100644 > > > > > > --- a/drivers/virtio/virtio_ring.c > > > > > > +++ b/drivers/virtio/virtio_ring.c > > > > > > @@ -2144,10 +2144,17 @@ static inline bool more_used(const struct vring_virtqueue *vq) > > > > > > return vq->packed_ring ? more_used_packed(vq) : more_used_split(vq); > > > > > > } > > > > > > -irqreturn_t vring_interrupt(int irq, void *_vq) > > > > > > +irqreturn_t vring_interrupt(int irq, void *v) > > > > > > { > > > > > > + struct virtqueue *_vq = v; > > > > > > + struct virtio_device *vdev = _vq->vdev; > > > > > > struct vring_virtqueue *vq = to_vvq(_vq); > > > > > > + if (!virtio_irq_soft_enabled(vdev)) { > > > > > > + dev_warn_once(&vdev->dev, "virtio vring IRQ raised before DRIVER_OK"); > > > > > > + return IRQ_NONE; > > > > > > + } > > > > > > + > > > > > > if (!more_used(vq)) { > > > > > > pr_debug("virtqueue interrupt with no work for %p\n", vq); > > > > > > return IRQ_NONE; > > > > > > diff --git a/include/linux/virtio.h b/include/linux/virtio.h > > > > > > index 5464f398912a..957d6ad604ac 100644 > > > > > > --- a/include/linux/virtio.h > > > > > > +++ b/include/linux/virtio.h > > > > > > @@ -95,6 +95,8 @@ dma_addr_t virtqueue_get_used_addr(struct virtqueue *vq); > > > > > > * @failed: saved value for VIRTIO_CONFIG_S_FAILED bit (for restore) > > > > > > * @config_enabled: configuration change reporting enabled > > > > > > * @config_change_pending: configuration change reported while disabled > > > > > > + * @irq_soft_check: whether or not to check @irq_soft_enabled > > > > > > + * @irq_soft_enabled: callbacks enabled > > > > > > * @config_lock: protects configuration change reporting > > > > > > * @dev: underlying device. > > > > > > * @id: the device type identification (used to match it with a driver). > > > > > > @@ -109,6 +111,8 @@ struct virtio_device { > > > > > > bool failed; > > > > > > bool config_enabled; > > > > > > bool config_change_pending; > > > > > > + bool irq_soft_check; > > > > > > + bool irq_soft_enabled; > > > > > > spinlock_t config_lock; > > > > > > spinlock_t vqs_list_lock; /* Protects VQs list access */ > > > > > > struct device dev; > > > > > > diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h > > > > > > index dafdc7f48c01..9c1b61f2e525 100644 > > > > > > --- a/include/linux/virtio_config.h > > > > > > +++ b/include/linux/virtio_config.h > > > > > > @@ -174,6 +174,24 @@ static inline bool virtio_has_feature(const struct virtio_device *vdev, > > > > > > return __virtio_test_bit(vdev, fbit); > > > > > > } > > > > > > +/* > > > > > > + * virtio_irq_soft_enabled: whether we can execute callbacks > > > > > > + * @vdev: the device > > > > > > + */ > > > > > > +static inline bool virtio_irq_soft_enabled(const struct virtio_device *vdev) > > > > > > +{ > > > > > > + if (!vdev->irq_soft_check) > > > > > > + return true; > > > > > > + > > > > > > + /* > > > > > > + * Read irq_soft_enabled before reading other device specific > > > > > > + * data. Paried with smp_store_relase() in > > > > > paired > > > > > > > > > > > > Will fix. > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > + * virtio_device_ready() and WRITE_ONCE()/synchronize_rcu() in > > > > > > + * virtio_reset_device(). > > > > > > + */ > > > > > > + return smp_load_acquire(&vdev->irq_soft_enabled); > > > > > > +} > > > > > > + > > > > > > /** > > > > > > * virtio_has_dma_quirk - determine whether this device has the DMA quirk > > > > > > * @vdev: the device > > > > > > @@ -236,6 +254,13 @@ void virtio_device_ready(struct virtio_device *dev) > > > > > > if (dev->config->enable_cbs) > > > > > > dev->config->enable_cbs(dev); > > > > > > + /* > > > > > > + * Commit the driver setup before enabling the virtqueue > > > > > > + * callbacks. Paried with smp_load_acuqire() in > > > > > > + * virtio_irq_soft_enabled() > > > > > > + */ > > > > > > + smp_store_release(&dev->irq_soft_enabled, true); > > > > > > + > > > > > > BUG_ON(status & VIRTIO_CONFIG_S_DRIVER_OK); > > > > > > dev->config->set_status(dev, status | VIRTIO_CONFIG_S_DRIVER_OK); > > > > > > } > > > > > > -- > > > > > > 2.25.1 > > > > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-03-25 9:20 ` Re: Jason Wang @ 2022-03-25 10:09 ` Michael S. Tsirkin 2022-03-28 4:56 ` Re: Jason Wang 0 siblings, 1 reply; 1767+ messages in thread From: Michael S. Tsirkin @ 2022-03-25 10:09 UTC (permalink / raw) To: Jason Wang Cc: Paul E. McKenney, Peter Zijlstra, Marc Zyngier, Keir Fraser, linux-kernel, virtualization, Thomas Gleixner On Fri, Mar 25, 2022 at 05:20:19PM +0800, Jason Wang wrote: > On Fri, Mar 25, 2022 at 5:10 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > On Fri, Mar 25, 2022 at 03:52:00PM +0800, Jason Wang wrote: > > > On Fri, Mar 25, 2022 at 2:31 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > > > Bcc: > > > > Subject: Re: [PATCH 3/3] virtio: harden vring IRQ > > > > Message-ID: <20220325021422-mutt-send-email-mst@kernel.org> > > > > Reply-To: > > > > In-Reply-To: <f7046303-7d7d-e39f-3c71-3688126cc812@redhat.com> > > > > > > > > On Fri, Mar 25, 2022 at 11:04:08AM +0800, Jason Wang wrote: > > > > > > > > > > 在 2022/3/24 下午7:03, Michael S. Tsirkin 写道: > > > > > > On Thu, Mar 24, 2022 at 04:40:04PM +0800, Jason Wang wrote: > > > > > > > This is a rework on the previous IRQ hardening that is done for > > > > > > > virtio-pci where several drawbacks were found and were reverted: > > > > > > > > > > > > > > 1) try to use IRQF_NO_AUTOEN which is not friendly to affinity managed IRQ > > > > > > > that is used by some device such as virtio-blk > > > > > > > 2) done only for PCI transport > > > > > > > > > > > > > > In this patch, we tries to borrow the idea from the INTX IRQ hardening > > > > > > > in the reverted commit 080cd7c3ac87 ("virtio-pci: harden INTX interrupts") > > > > > > > by introducing a global irq_soft_enabled variable for each > > > > > > > virtio_device. Then we can to toggle it during > > > > > > > virtio_reset_device()/virtio_device_ready(). A synchornize_rcu() is > > > > > > > used in virtio_reset_device() to synchronize with the IRQ handlers. In > > > > > > > the future, we may provide config_ops for the transport that doesn't > > > > > > > use IRQ. With this, vring_interrupt() can return check and early if > > > > > > > irq_soft_enabled is false. This lead to smp_load_acquire() to be used > > > > > > > but the cost should be acceptable. > > > > > > Maybe it should be but is it? Can't we use synchronize_irq instead? > > > > > > > > > > > > > > > Even if we allow the transport driver to synchornize through > > > > > synchronize_irq() we still need a check in the vring_interrupt(). > > > > > > > > > > We do something like the following previously: > > > > > > > > > > if (!READ_ONCE(vp_dev->intx_soft_enabled)) > > > > > return IRQ_NONE; > > > > > > > > > > But it looks like a bug since speculative read can be done before the check > > > > > where the interrupt handler can't see the uncommitted setup which is done by > > > > > the driver. > > > > > > > > I don't think so - if you sync after setting the value then > > > > you are guaranteed that any handler running afterwards > > > > will see the new value. > > > > > > The problem is not disabled but the enable. > > > > So a misbehaving device can lose interrupts? That's not a problem at all > > imo. > > It's the interrupt raised before setting irq_soft_enabled to true: > > CPU 0 probe) driver specific setup (not commited) > CPU 1 IRQ handler) read the uninitialized variable > CPU 0 probe) set irq_soft_enabled to true > CPU 1 IRQ handler) read irq_soft_enable as true > CPU 1 IRQ handler) use the uninitialized variable > > Thanks Yea, it hurts if you do it. So do not do it then ;). irq_soft_enabled (I think driver_ok or status is a better name) should be initialized to false *before* irq is requested. And requesting irq commits all memory otherwise all drivers would be broken, if it doesn't it just needs to be fixed, not worked around in virtio. > > > > > We use smp_store_relase() > > > to make sure the driver commits the setup before enabling the irq. It > > > means the read needs to be ordered as well in vring_interrupt(). > > > > > > > > > > > Although I couldn't find anything about this in memory-barriers.txt > > > > which surprises me. > > > > > > > > CC Paul to help make sure I'm right. > > > > > > > > > > > > > > > > > > > > > > > > > > To avoid breaking legacy device which can send IRQ before DRIVER_OK, a > > > > > > > module parameter is introduced to enable the hardening so function > > > > > > > hardening is disabled by default. > > > > > > Which devices are these? How come they send an interrupt before there > > > > > > are any buffers in any queues? > > > > > > > > > > > > > > > I copied this from the commit log for 22b7050a024d7 > > > > > > > > > > " > > > > > > > > > > This change will also benefit old hypervisors (before 2009) > > > > > that send interrupts without checking DRIVER_OK: previously, > > > > > the callback could race with driver-specific initialization. > > > > > " > > > > > > > > > > If this is only for config interrupt, I can remove the above log. > > > > > > > > > > > > This is only for config interrupt. > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > > > > Note that the hardening is only done for vring interrupt since the > > > > > > > config interrupt hardening is already done in commit 22b7050a024d7 > > > > > > > ("virtio: defer config changed notifications"). But the method that is > > > > > > > used by config interrupt can't be reused by the vring interrupt > > > > > > > handler because it uses spinlock to do the synchronization which is > > > > > > > expensive. > > > > > > > > > > > > > > Signed-off-by: Jason Wang <jasowang@redhat.com> > > > > > > > > > > > > > --- > > > > > > > drivers/virtio/virtio.c | 19 +++++++++++++++++++ > > > > > > > drivers/virtio/virtio_ring.c | 9 ++++++++- > > > > > > > include/linux/virtio.h | 4 ++++ > > > > > > > include/linux/virtio_config.h | 25 +++++++++++++++++++++++++ > > > > > > > 4 files changed, 56 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c > > > > > > > index 8dde44ea044a..85e331efa9cc 100644 > > > > > > > --- a/drivers/virtio/virtio.c > > > > > > > +++ b/drivers/virtio/virtio.c > > > > > > > @@ -7,6 +7,12 @@ > > > > > > > #include <linux/of.h> > > > > > > > #include <uapi/linux/virtio_ids.h> > > > > > > > +static bool irq_hardening = false; > > > > > > > + > > > > > > > +module_param(irq_hardening, bool, 0444); > > > > > > > +MODULE_PARM_DESC(irq_hardening, > > > > > > > + "Disalbe IRQ software processing when it is not expected"); > > > > > > > + > > > > > > > /* Unique numbering for virtio devices. */ > > > > > > > static DEFINE_IDA(virtio_index_ida); > > > > > > > @@ -220,6 +226,15 @@ static int virtio_features_ok(struct virtio_device *dev) > > > > > > > * */ > > > > > > > void virtio_reset_device(struct virtio_device *dev) > > > > > > > { > > > > > > > + /* > > > > > > > + * The below synchronize_rcu() guarantees that any > > > > > > > + * interrupt for this line arriving after > > > > > > > + * synchronize_rcu() has completed is guaranteed to see > > > > > > > + * irq_soft_enabled == false. > > > > > > News to me I did not know synchronize_rcu has anything to do > > > > > > with interrupts. Did not you intend to use synchronize_irq? > > > > > > I am not even 100% sure synchronize_rcu is by design a memory barrier > > > > > > though it's most likely is ... > > > > > > > > > > > > > > > According to the comment above tree RCU version of synchronize_rcu(): > > > > > > > > > > """ > > > > > > > > > > * RCU read-side critical sections are delimited by rcu_read_lock() > > > > > * and rcu_read_unlock(), and may be nested. In addition, but only in > > > > > * v5.0 and later, regions of code across which interrupts, preemption, > > > > > * or softirqs have been disabled also serve as RCU read-side critical > > > > > * sections. This includes hardware interrupt handlers, softirq handlers, > > > > > * and NMI handlers. > > > > > """ > > > > > > > > > > So interrupt handlers are treated as read-side critical sections. > > > > > > > > > > And it has the comment for explain the barrier: > > > > > > > > > > """ > > > > > > > > > > * Note that this guarantee implies further memory-ordering guarantees. > > > > > * On systems with more than one CPU, when synchronize_rcu() returns, > > > > > * each CPU is guaranteed to have executed a full memory barrier since > > > > > * the end of its last RCU read-side critical section whose beginning > > > > > * preceded the call to synchronize_rcu(). In addition, each CPU having > > > > > """ > > > > > > > > > > So on SMP it provides a full barrier. And for UP/tiny RCU we don't need the > > > > > barrier, if the interrupt come after WRITE_ONCE() it will see the > > > > > irq_soft_enabled as false. > > > > > > > > > > > > > You are right. So then > > > > 1. I do not think we need load_acquire - why is it needed? Just > > > > READ_ONCE should do. > > > > > > See above. > > > > > > > 2. isn't synchronize_irq also doing the same thing? > > > > > > > > > Yes, but it requires a config ops since the IRQ knowledge is transport specific. > > > > > > > > > > > > > > > > > > > > > > > > + */ > > > > > > > + WRITE_ONCE(dev->irq_soft_enabled, false); > > > > > > > + synchronize_rcu(); > > > > > > > + > > > > > > > dev->config->reset(dev); > > > > > > > } > > > > > > > EXPORT_SYMBOL_GPL(virtio_reset_device); > > > > > > Please add comment explaining where it will be enabled. > > > > > > Also, we *really* don't need to synch if it was already disabled, > > > > > > let's not add useless overhead to the boot sequence. > > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > @@ -427,6 +442,10 @@ int register_virtio_device(struct virtio_device *dev) > > > > > > > spin_lock_init(&dev->config_lock); > > > > > > > dev->config_enabled = false; > > > > > > > dev->config_change_pending = false; > > > > > > > + dev->irq_soft_check = irq_hardening; > > > > > > > + > > > > > > > + if (dev->irq_soft_check) > > > > > > > + dev_info(&dev->dev, "IRQ hardening is enabled\n"); > > > > > > > /* We always start by resetting the device, in case a previous > > > > > > > * driver messed it up. This also tests that code path a little. */ > > > > > > one of the points of hardening is it's also helpful for buggy > > > > > > devices. this flag defeats the purpose. > > > > > > > > > > > > > > > Do you mean: > > > > > > > > > > 1) we need something like config_enable? This seems not easy to be > > > > > implemented without obvious overhead, mainly the synchronize with the > > > > > interrupt handlers > > > > > > > > But synchronize is only on tear-down path. That is not critical for any > > > > users at the moment, even less than probe. > > > > > > I meant if we have vq->irq_pending, we need to call vring_interrupt() > > > in the virtio_device_ready() and synchronize the IRQ handlers with > > > spinlock or others. > > > > > > > > > > > > 2) enable this by default, so I don't object, but this may have some risk > > > > > for old hypervisors > > > > > > > > > > > > The risk if there's a driver adding buffers without setting DRIVER_OK. > > > > > > Probably not, we have devices that accept random inputs from outside, > > > net, console, input etc. I've done a round of audits of the Qemu > > > codes. They look all fine since day0. > > > > > > > So with this approach, how about we rename the flag "driver_ok"? > > > > And then add_buf can actually test it and BUG_ON if not there (at least > > > > in the debug build). > > > > > > This looks like a hardening of the driver in the core instead of the > > > device. I think it can be done but in a separate series. > > > > > > > > > > > And going down from there, how about we cache status in the > > > > device? Then we don't need to keep re-reading it every time, > > > > speeding boot up a tiny bit. > > > > > > I don't fully understand here, actually spec requires status to be > > > read back for validation in many cases. > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > > > > > > index 962f1477b1fa..0170f8c784d8 100644 > > > > > > > --- a/drivers/virtio/virtio_ring.c > > > > > > > +++ b/drivers/virtio/virtio_ring.c > > > > > > > @@ -2144,10 +2144,17 @@ static inline bool more_used(const struct vring_virtqueue *vq) > > > > > > > return vq->packed_ring ? more_used_packed(vq) : more_used_split(vq); > > > > > > > } > > > > > > > -irqreturn_t vring_interrupt(int irq, void *_vq) > > > > > > > +irqreturn_t vring_interrupt(int irq, void *v) > > > > > > > { > > > > > > > + struct virtqueue *_vq = v; > > > > > > > + struct virtio_device *vdev = _vq->vdev; > > > > > > > struct vring_virtqueue *vq = to_vvq(_vq); > > > > > > > + if (!virtio_irq_soft_enabled(vdev)) { > > > > > > > + dev_warn_once(&vdev->dev, "virtio vring IRQ raised before DRIVER_OK"); > > > > > > > + return IRQ_NONE; > > > > > > > + } > > > > > > > + > > > > > > > if (!more_used(vq)) { > > > > > > > pr_debug("virtqueue interrupt with no work for %p\n", vq); > > > > > > > return IRQ_NONE; > > > > > > > diff --git a/include/linux/virtio.h b/include/linux/virtio.h > > > > > > > index 5464f398912a..957d6ad604ac 100644 > > > > > > > --- a/include/linux/virtio.h > > > > > > > +++ b/include/linux/virtio.h > > > > > > > @@ -95,6 +95,8 @@ dma_addr_t virtqueue_get_used_addr(struct virtqueue *vq); > > > > > > > * @failed: saved value for VIRTIO_CONFIG_S_FAILED bit (for restore) > > > > > > > * @config_enabled: configuration change reporting enabled > > > > > > > * @config_change_pending: configuration change reported while disabled > > > > > > > + * @irq_soft_check: whether or not to check @irq_soft_enabled > > > > > > > + * @irq_soft_enabled: callbacks enabled > > > > > > > * @config_lock: protects configuration change reporting > > > > > > > * @dev: underlying device. > > > > > > > * @id: the device type identification (used to match it with a driver). > > > > > > > @@ -109,6 +111,8 @@ struct virtio_device { > > > > > > > bool failed; > > > > > > > bool config_enabled; > > > > > > > bool config_change_pending; > > > > > > > + bool irq_soft_check; > > > > > > > + bool irq_soft_enabled; > > > > > > > spinlock_t config_lock; > > > > > > > spinlock_t vqs_list_lock; /* Protects VQs list access */ > > > > > > > struct device dev; > > > > > > > diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h > > > > > > > index dafdc7f48c01..9c1b61f2e525 100644 > > > > > > > --- a/include/linux/virtio_config.h > > > > > > > +++ b/include/linux/virtio_config.h > > > > > > > @@ -174,6 +174,24 @@ static inline bool virtio_has_feature(const struct virtio_device *vdev, > > > > > > > return __virtio_test_bit(vdev, fbit); > > > > > > > } > > > > > > > +/* > > > > > > > + * virtio_irq_soft_enabled: whether we can execute callbacks > > > > > > > + * @vdev: the device > > > > > > > + */ > > > > > > > +static inline bool virtio_irq_soft_enabled(const struct virtio_device *vdev) > > > > > > > +{ > > > > > > > + if (!vdev->irq_soft_check) > > > > > > > + return true; > > > > > > > + > > > > > > > + /* > > > > > > > + * Read irq_soft_enabled before reading other device specific > > > > > > > + * data. Paried with smp_store_relase() in > > > > > > paired > > > > > > > > > > > > > > > Will fix. > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > + * virtio_device_ready() and WRITE_ONCE()/synchronize_rcu() in > > > > > > > + * virtio_reset_device(). > > > > > > > + */ > > > > > > > + return smp_load_acquire(&vdev->irq_soft_enabled); > > > > > > > +} > > > > > > > + > > > > > > > /** > > > > > > > * virtio_has_dma_quirk - determine whether this device has the DMA quirk > > > > > > > * @vdev: the device > > > > > > > @@ -236,6 +254,13 @@ void virtio_device_ready(struct virtio_device *dev) > > > > > > > if (dev->config->enable_cbs) > > > > > > > dev->config->enable_cbs(dev); > > > > > > > + /* > > > > > > > + * Commit the driver setup before enabling the virtqueue > > > > > > > + * callbacks. Paried with smp_load_acuqire() in > > > > > > > + * virtio_irq_soft_enabled() > > > > > > > + */ > > > > > > > + smp_store_release(&dev->irq_soft_enabled, true); > > > > > > > + > > > > > > > BUG_ON(status & VIRTIO_CONFIG_S_DRIVER_OK); > > > > > > > dev->config->set_status(dev, status | VIRTIO_CONFIG_S_DRIVER_OK); > > > > > > > } > > > > > > > -- > > > > > > > 2.25.1 > > > > > > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-03-25 10:09 ` Re: Michael S. Tsirkin @ 2022-03-28 4:56 ` Jason Wang 2022-03-28 5:59 ` Re: Michael S. Tsirkin 0 siblings, 1 reply; 1767+ messages in thread From: Jason Wang @ 2022-03-28 4:56 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Paul E. McKenney, Peter Zijlstra, Marc Zyngier, Keir Fraser, linux-kernel, virtualization, Thomas Gleixner On Fri, Mar 25, 2022 at 6:10 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > On Fri, Mar 25, 2022 at 05:20:19PM +0800, Jason Wang wrote: > > On Fri, Mar 25, 2022 at 5:10 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > On Fri, Mar 25, 2022 at 03:52:00PM +0800, Jason Wang wrote: > > > > On Fri, Mar 25, 2022 at 2:31 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > > > > > Bcc: > > > > > Subject: Re: [PATCH 3/3] virtio: harden vring IRQ > > > > > Message-ID: <20220325021422-mutt-send-email-mst@kernel.org> > > > > > Reply-To: > > > > > In-Reply-To: <f7046303-7d7d-e39f-3c71-3688126cc812@redhat.com> > > > > > > > > > > On Fri, Mar 25, 2022 at 11:04:08AM +0800, Jason Wang wrote: > > > > > > > > > > > > 在 2022/3/24 下午7:03, Michael S. Tsirkin 写道: > > > > > > > On Thu, Mar 24, 2022 at 04:40:04PM +0800, Jason Wang wrote: > > > > > > > > This is a rework on the previous IRQ hardening that is done for > > > > > > > > virtio-pci where several drawbacks were found and were reverted: > > > > > > > > > > > > > > > > 1) try to use IRQF_NO_AUTOEN which is not friendly to affinity managed IRQ > > > > > > > > that is used by some device such as virtio-blk > > > > > > > > 2) done only for PCI transport > > > > > > > > > > > > > > > > In this patch, we tries to borrow the idea from the INTX IRQ hardening > > > > > > > > in the reverted commit 080cd7c3ac87 ("virtio-pci: harden INTX interrupts") > > > > > > > > by introducing a global irq_soft_enabled variable for each > > > > > > > > virtio_device. Then we can to toggle it during > > > > > > > > virtio_reset_device()/virtio_device_ready(). A synchornize_rcu() is > > > > > > > > used in virtio_reset_device() to synchronize with the IRQ handlers. In > > > > > > > > the future, we may provide config_ops for the transport that doesn't > > > > > > > > use IRQ. With this, vring_interrupt() can return check and early if > > > > > > > > irq_soft_enabled is false. This lead to smp_load_acquire() to be used > > > > > > > > but the cost should be acceptable. > > > > > > > Maybe it should be but is it? Can't we use synchronize_irq instead? > > > > > > > > > > > > > > > > > > Even if we allow the transport driver to synchornize through > > > > > > synchronize_irq() we still need a check in the vring_interrupt(). > > > > > > > > > > > > We do something like the following previously: > > > > > > > > > > > > if (!READ_ONCE(vp_dev->intx_soft_enabled)) > > > > > > return IRQ_NONE; > > > > > > > > > > > > But it looks like a bug since speculative read can be done before the check > > > > > > where the interrupt handler can't see the uncommitted setup which is done by > > > > > > the driver. > > > > > > > > > > I don't think so - if you sync after setting the value then > > > > > you are guaranteed that any handler running afterwards > > > > > will see the new value. > > > > > > > > The problem is not disabled but the enable. > > > > > > So a misbehaving device can lose interrupts? That's not a problem at all > > > imo. > > > > It's the interrupt raised before setting irq_soft_enabled to true: > > > > CPU 0 probe) driver specific setup (not commited) > > CPU 1 IRQ handler) read the uninitialized variable > > CPU 0 probe) set irq_soft_enabled to true > > CPU 1 IRQ handler) read irq_soft_enable as true > > CPU 1 IRQ handler) use the uninitialized variable > > > > Thanks > > Yea, it hurts if you do it. So do not do it then ;). > > irq_soft_enabled (I think driver_ok or status is a better name) I can change it to driver_ok. > should be initialized to false *before* irq is requested. > > And requesting irq commits all memory otherwise all drivers would be > broken, So I think we might talk different issues: 1) Whether request_irq() commits the previous setups, I think the answer is yes, since the spin_unlock of desc->lock (release) can guarantee this though there seems no documentation around request_irq() to say this. And I can see at least drivers/video/fbdev/omap2/omapfb/dss/dispc.c is using smp_wmb() before the request_irq(). And even if write is ordered we still need read to be ordered to be paired with that. > if it doesn't it just needs to be fixed, not worked around in > virtio. 2) virtio drivers might do a lot of setups between request_irq() and virtio_device_ready(): request_irq() driver specific setups virtio_device_ready() CPU 0 probe) request_irq() CPU 1 IRQ handler) read the uninitialized variable CPU 0 probe) driver specific setups CPU 0 probe) smp_store_release(intr_soft_enabled, true), commit the setups CPU 1 IRQ handler) read irq_soft_enable as true CPU 1 IRQ handler) use the uninitialized variable Thanks > > > > > > > > > We use smp_store_relase() > > > > to make sure the driver commits the setup before enabling the irq. It > > > > means the read needs to be ordered as well in vring_interrupt(). > > > > > > > > > > > > > > Although I couldn't find anything about this in memory-barriers.txt > > > > > which surprises me. > > > > > > > > > > CC Paul to help make sure I'm right. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To avoid breaking legacy device which can send IRQ before DRIVER_OK, a > > > > > > > > module parameter is introduced to enable the hardening so function > > > > > > > > hardening is disabled by default. > > > > > > > Which devices are these? How come they send an interrupt before there > > > > > > > are any buffers in any queues? > > > > > > > > > > > > > > > > > > I copied this from the commit log for 22b7050a024d7 > > > > > > > > > > > > " > > > > > > > > > > > > This change will also benefit old hypervisors (before 2009) > > > > > > that send interrupts without checking DRIVER_OK: previously, > > > > > > the callback could race with driver-specific initialization. > > > > > > " > > > > > > > > > > > > If this is only for config interrupt, I can remove the above log. > > > > > > > > > > > > > > > This is only for config interrupt. > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Note that the hardening is only done for vring interrupt since the > > > > > > > > config interrupt hardening is already done in commit 22b7050a024d7 > > > > > > > > ("virtio: defer config changed notifications"). But the method that is > > > > > > > > used by config interrupt can't be reused by the vring interrupt > > > > > > > > handler because it uses spinlock to do the synchronization which is > > > > > > > > expensive. > > > > > > > > > > > > > > > > Signed-off-by: Jason Wang <jasowang@redhat.com> > > > > > > > > > > > > > > > --- > > > > > > > > drivers/virtio/virtio.c | 19 +++++++++++++++++++ > > > > > > > > drivers/virtio/virtio_ring.c | 9 ++++++++- > > > > > > > > include/linux/virtio.h | 4 ++++ > > > > > > > > include/linux/virtio_config.h | 25 +++++++++++++++++++++++++ > > > > > > > > 4 files changed, 56 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c > > > > > > > > index 8dde44ea044a..85e331efa9cc 100644 > > > > > > > > --- a/drivers/virtio/virtio.c > > > > > > > > +++ b/drivers/virtio/virtio.c > > > > > > > > @@ -7,6 +7,12 @@ > > > > > > > > #include <linux/of.h> > > > > > > > > #include <uapi/linux/virtio_ids.h> > > > > > > > > +static bool irq_hardening = false; > > > > > > > > + > > > > > > > > +module_param(irq_hardening, bool, 0444); > > > > > > > > +MODULE_PARM_DESC(irq_hardening, > > > > > > > > + "Disalbe IRQ software processing when it is not expected"); > > > > > > > > + > > > > > > > > /* Unique numbering for virtio devices. */ > > > > > > > > static DEFINE_IDA(virtio_index_ida); > > > > > > > > @@ -220,6 +226,15 @@ static int virtio_features_ok(struct virtio_device *dev) > > > > > > > > * */ > > > > > > > > void virtio_reset_device(struct virtio_device *dev) > > > > > > > > { > > > > > > > > + /* > > > > > > > > + * The below synchronize_rcu() guarantees that any > > > > > > > > + * interrupt for this line arriving after > > > > > > > > + * synchronize_rcu() has completed is guaranteed to see > > > > > > > > + * irq_soft_enabled == false. > > > > > > > News to me I did not know synchronize_rcu has anything to do > > > > > > > with interrupts. Did not you intend to use synchronize_irq? > > > > > > > I am not even 100% sure synchronize_rcu is by design a memory barrier > > > > > > > though it's most likely is ... > > > > > > > > > > > > > > > > > > According to the comment above tree RCU version of synchronize_rcu(): > > > > > > > > > > > > """ > > > > > > > > > > > > * RCU read-side critical sections are delimited by rcu_read_lock() > > > > > > * and rcu_read_unlock(), and may be nested. In addition, but only in > > > > > > * v5.0 and later, regions of code across which interrupts, preemption, > > > > > > * or softirqs have been disabled also serve as RCU read-side critical > > > > > > * sections. This includes hardware interrupt handlers, softirq handlers, > > > > > > * and NMI handlers. > > > > > > """ > > > > > > > > > > > > So interrupt handlers are treated as read-side critical sections. > > > > > > > > > > > > And it has the comment for explain the barrier: > > > > > > > > > > > > """ > > > > > > > > > > > > * Note that this guarantee implies further memory-ordering guarantees. > > > > > > * On systems with more than one CPU, when synchronize_rcu() returns, > > > > > > * each CPU is guaranteed to have executed a full memory barrier since > > > > > > * the end of its last RCU read-side critical section whose beginning > > > > > > * preceded the call to synchronize_rcu(). In addition, each CPU having > > > > > > """ > > > > > > > > > > > > So on SMP it provides a full barrier. And for UP/tiny RCU we don't need the > > > > > > barrier, if the interrupt come after WRITE_ONCE() it will see the > > > > > > irq_soft_enabled as false. > > > > > > > > > > > > > > > > You are right. So then > > > > > 1. I do not think we need load_acquire - why is it needed? Just > > > > > READ_ONCE should do. > > > > > > > > See above. > > > > > > > > > 2. isn't synchronize_irq also doing the same thing? > > > > > > > > > > > > Yes, but it requires a config ops since the IRQ knowledge is transport specific. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + */ > > > > > > > > + WRITE_ONCE(dev->irq_soft_enabled, false); > > > > > > > > + synchronize_rcu(); > > > > > > > > + > > > > > > > > dev->config->reset(dev); > > > > > > > > } > > > > > > > > EXPORT_SYMBOL_GPL(virtio_reset_device); > > > > > > > Please add comment explaining where it will be enabled. > > > > > > > Also, we *really* don't need to synch if it was already disabled, > > > > > > > let's not add useless overhead to the boot sequence. > > > > > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > @@ -427,6 +442,10 @@ int register_virtio_device(struct virtio_device *dev) > > > > > > > > spin_lock_init(&dev->config_lock); > > > > > > > > dev->config_enabled = false; > > > > > > > > dev->config_change_pending = false; > > > > > > > > + dev->irq_soft_check = irq_hardening; > > > > > > > > + > > > > > > > > + if (dev->irq_soft_check) > > > > > > > > + dev_info(&dev->dev, "IRQ hardening is enabled\n"); > > > > > > > > /* We always start by resetting the device, in case a previous > > > > > > > > * driver messed it up. This also tests that code path a little. */ > > > > > > > one of the points of hardening is it's also helpful for buggy > > > > > > > devices. this flag defeats the purpose. > > > > > > > > > > > > > > > > > > Do you mean: > > > > > > > > > > > > 1) we need something like config_enable? This seems not easy to be > > > > > > implemented without obvious overhead, mainly the synchronize with the > > > > > > interrupt handlers > > > > > > > > > > But synchronize is only on tear-down path. That is not critical for any > > > > > users at the moment, even less than probe. > > > > > > > > I meant if we have vq->irq_pending, we need to call vring_interrupt() > > > > in the virtio_device_ready() and synchronize the IRQ handlers with > > > > spinlock or others. > > > > > > > > > > > > > > > 2) enable this by default, so I don't object, but this may have some risk > > > > > > for old hypervisors > > > > > > > > > > > > > > > The risk if there's a driver adding buffers without setting DRIVER_OK. > > > > > > > > Probably not, we have devices that accept random inputs from outside, > > > > net, console, input etc. I've done a round of audits of the Qemu > > > > codes. They look all fine since day0. > > > > > > > > > So with this approach, how about we rename the flag "driver_ok"? > > > > > And then add_buf can actually test it and BUG_ON if not there (at least > > > > > in the debug build). > > > > > > > > This looks like a hardening of the driver in the core instead of the > > > > device. I think it can be done but in a separate series. > > > > > > > > > > > > > > And going down from there, how about we cache status in the > > > > > device? Then we don't need to keep re-reading it every time, > > > > > speeding boot up a tiny bit. > > > > > > > > I don't fully understand here, actually spec requires status to be > > > > read back for validation in many cases. > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > > > > > > > index 962f1477b1fa..0170f8c784d8 100644 > > > > > > > > --- a/drivers/virtio/virtio_ring.c > > > > > > > > +++ b/drivers/virtio/virtio_ring.c > > > > > > > > @@ -2144,10 +2144,17 @@ static inline bool more_used(const struct vring_virtqueue *vq) > > > > > > > > return vq->packed_ring ? more_used_packed(vq) : more_used_split(vq); > > > > > > > > } > > > > > > > > -irqreturn_t vring_interrupt(int irq, void *_vq) > > > > > > > > +irqreturn_t vring_interrupt(int irq, void *v) > > > > > > > > { > > > > > > > > + struct virtqueue *_vq = v; > > > > > > > > + struct virtio_device *vdev = _vq->vdev; > > > > > > > > struct vring_virtqueue *vq = to_vvq(_vq); > > > > > > > > + if (!virtio_irq_soft_enabled(vdev)) { > > > > > > > > + dev_warn_once(&vdev->dev, "virtio vring IRQ raised before DRIVER_OK"); > > > > > > > > + return IRQ_NONE; > > > > > > > > + } > > > > > > > > + > > > > > > > > if (!more_used(vq)) { > > > > > > > > pr_debug("virtqueue interrupt with no work for %p\n", vq); > > > > > > > > return IRQ_NONE; > > > > > > > > diff --git a/include/linux/virtio.h b/include/linux/virtio.h > > > > > > > > index 5464f398912a..957d6ad604ac 100644 > > > > > > > > --- a/include/linux/virtio.h > > > > > > > > +++ b/include/linux/virtio.h > > > > > > > > @@ -95,6 +95,8 @@ dma_addr_t virtqueue_get_used_addr(struct virtqueue *vq); > > > > > > > > * @failed: saved value for VIRTIO_CONFIG_S_FAILED bit (for restore) > > > > > > > > * @config_enabled: configuration change reporting enabled > > > > > > > > * @config_change_pending: configuration change reported while disabled > > > > > > > > + * @irq_soft_check: whether or not to check @irq_soft_enabled > > > > > > > > + * @irq_soft_enabled: callbacks enabled > > > > > > > > * @config_lock: protects configuration change reporting > > > > > > > > * @dev: underlying device. > > > > > > > > * @id: the device type identification (used to match it with a driver). > > > > > > > > @@ -109,6 +111,8 @@ struct virtio_device { > > > > > > > > bool failed; > > > > > > > > bool config_enabled; > > > > > > > > bool config_change_pending; > > > > > > > > + bool irq_soft_check; > > > > > > > > + bool irq_soft_enabled; > > > > > > > > spinlock_t config_lock; > > > > > > > > spinlock_t vqs_list_lock; /* Protects VQs list access */ > > > > > > > > struct device dev; > > > > > > > > diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h > > > > > > > > index dafdc7f48c01..9c1b61f2e525 100644 > > > > > > > > --- a/include/linux/virtio_config.h > > > > > > > > +++ b/include/linux/virtio_config.h > > > > > > > > @@ -174,6 +174,24 @@ static inline bool virtio_has_feature(const struct virtio_device *vdev, > > > > > > > > return __virtio_test_bit(vdev, fbit); > > > > > > > > } > > > > > > > > +/* > > > > > > > > + * virtio_irq_soft_enabled: whether we can execute callbacks > > > > > > > > + * @vdev: the device > > > > > > > > + */ > > > > > > > > +static inline bool virtio_irq_soft_enabled(const struct virtio_device *vdev) > > > > > > > > +{ > > > > > > > > + if (!vdev->irq_soft_check) > > > > > > > > + return true; > > > > > > > > + > > > > > > > > + /* > > > > > > > > + * Read irq_soft_enabled before reading other device specific > > > > > > > > + * data. Paried with smp_store_relase() in > > > > > > > paired > > > > > > > > > > > > > > > > > > Will fix. > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > + * virtio_device_ready() and WRITE_ONCE()/synchronize_rcu() in > > > > > > > > + * virtio_reset_device(). > > > > > > > > + */ > > > > > > > > + return smp_load_acquire(&vdev->irq_soft_enabled); > > > > > > > > +} > > > > > > > > + > > > > > > > > /** > > > > > > > > * virtio_has_dma_quirk - determine whether this device has the DMA quirk > > > > > > > > * @vdev: the device > > > > > > > > @@ -236,6 +254,13 @@ void virtio_device_ready(struct virtio_device *dev) > > > > > > > > if (dev->config->enable_cbs) > > > > > > > > dev->config->enable_cbs(dev); > > > > > > > > + /* > > > > > > > > + * Commit the driver setup before enabling the virtqueue > > > > > > > > + * callbacks. Paried with smp_load_acuqire() in > > > > > > > > + * virtio_irq_soft_enabled() > > > > > > > > + */ > > > > > > > > + smp_store_release(&dev->irq_soft_enabled, true); > > > > > > > > + > > > > > > > > BUG_ON(status & VIRTIO_CONFIG_S_DRIVER_OK); > > > > > > > > dev->config->set_status(dev, status | VIRTIO_CONFIG_S_DRIVER_OK); > > > > > > > > } > > > > > > > > -- > > > > > > > > 2.25.1 > > > > > > > > > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-03-28 4:56 ` Re: Jason Wang @ 2022-03-28 5:59 ` Michael S. Tsirkin 2022-03-28 6:18 ` Re: Jason Wang 0 siblings, 1 reply; 1767+ messages in thread From: Michael S. Tsirkin @ 2022-03-28 5:59 UTC (permalink / raw) To: Jason Wang Cc: Paul E. McKenney, Peter Zijlstra, Marc Zyngier, Keir Fraser, linux-kernel, virtualization, Thomas Gleixner On Mon, Mar 28, 2022 at 12:56:41PM +0800, Jason Wang wrote: > On Fri, Mar 25, 2022 at 6:10 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > On Fri, Mar 25, 2022 at 05:20:19PM +0800, Jason Wang wrote: > > > On Fri, Mar 25, 2022 at 5:10 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > > > On Fri, Mar 25, 2022 at 03:52:00PM +0800, Jason Wang wrote: > > > > > On Fri, Mar 25, 2022 at 2:31 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > > > > > > > Bcc: > > > > > > Subject: Re: [PATCH 3/3] virtio: harden vring IRQ > > > > > > Message-ID: <20220325021422-mutt-send-email-mst@kernel.org> > > > > > > Reply-To: > > > > > > In-Reply-To: <f7046303-7d7d-e39f-3c71-3688126cc812@redhat.com> > > > > > > > > > > > > On Fri, Mar 25, 2022 at 11:04:08AM +0800, Jason Wang wrote: > > > > > > > > > > > > > > 在 2022/3/24 下午7:03, Michael S. Tsirkin 写道: > > > > > > > > On Thu, Mar 24, 2022 at 04:40:04PM +0800, Jason Wang wrote: > > > > > > > > > This is a rework on the previous IRQ hardening that is done for > > > > > > > > > virtio-pci where several drawbacks were found and were reverted: > > > > > > > > > > > > > > > > > > 1) try to use IRQF_NO_AUTOEN which is not friendly to affinity managed IRQ > > > > > > > > > that is used by some device such as virtio-blk > > > > > > > > > 2) done only for PCI transport > > > > > > > > > > > > > > > > > > In this patch, we tries to borrow the idea from the INTX IRQ hardening > > > > > > > > > in the reverted commit 080cd7c3ac87 ("virtio-pci: harden INTX interrupts") > > > > > > > > > by introducing a global irq_soft_enabled variable for each > > > > > > > > > virtio_device. Then we can to toggle it during > > > > > > > > > virtio_reset_device()/virtio_device_ready(). A synchornize_rcu() is > > > > > > > > > used in virtio_reset_device() to synchronize with the IRQ handlers. In > > > > > > > > > the future, we may provide config_ops for the transport that doesn't > > > > > > > > > use IRQ. With this, vring_interrupt() can return check and early if > > > > > > > > > irq_soft_enabled is false. This lead to smp_load_acquire() to be used > > > > > > > > > but the cost should be acceptable. > > > > > > > > Maybe it should be but is it? Can't we use synchronize_irq instead? > > > > > > > > > > > > > > > > > > > > > Even if we allow the transport driver to synchornize through > > > > > > > synchronize_irq() we still need a check in the vring_interrupt(). > > > > > > > > > > > > > > We do something like the following previously: > > > > > > > > > > > > > > if (!READ_ONCE(vp_dev->intx_soft_enabled)) > > > > > > > return IRQ_NONE; > > > > > > > > > > > > > > But it looks like a bug since speculative read can be done before the check > > > > > > > where the interrupt handler can't see the uncommitted setup which is done by > > > > > > > the driver. > > > > > > > > > > > > I don't think so - if you sync after setting the value then > > > > > > you are guaranteed that any handler running afterwards > > > > > > will see the new value. > > > > > > > > > > The problem is not disabled but the enable. > > > > > > > > So a misbehaving device can lose interrupts? That's not a problem at all > > > > imo. > > > > > > It's the interrupt raised before setting irq_soft_enabled to true: > > > > > > CPU 0 probe) driver specific setup (not commited) > > > CPU 1 IRQ handler) read the uninitialized variable > > > CPU 0 probe) set irq_soft_enabled to true > > > CPU 1 IRQ handler) read irq_soft_enable as true > > > CPU 1 IRQ handler) use the uninitialized variable > > > > > > Thanks > > > > Yea, it hurts if you do it. So do not do it then ;). > > > > irq_soft_enabled (I think driver_ok or status is a better name) > > I can change it to driver_ok. > > > should be initialized to false *before* irq is requested. > > > > And requesting irq commits all memory otherwise all drivers would be > > broken, > > So I think we might talk different issues: > > 1) Whether request_irq() commits the previous setups, I think the > answer is yes, since the spin_unlock of desc->lock (release) can > guarantee this though there seems no documentation around > request_irq() to say this. > > And I can see at least drivers/video/fbdev/omap2/omapfb/dss/dispc.c is > using smp_wmb() before the request_irq(). > > And even if write is ordered we still need read to be ordered to be > paired with that. > > > if it doesn't it just needs to be fixed, not worked around in > > virtio. > > 2) virtio drivers might do a lot of setups between request_irq() and > virtio_device_ready(): > > request_irq() > driver specific setups > virtio_device_ready() > > CPU 0 probe) request_irq() > CPU 1 IRQ handler) read the uninitialized variable > CPU 0 probe) driver specific setups > CPU 0 probe) smp_store_release(intr_soft_enabled, true), commit the setups > CPU 1 IRQ handler) read irq_soft_enable as true > CPU 1 IRQ handler) use the uninitialized variable > > Thanks As I said, virtio_device_ready needs to do synchronize_irq. That will guarantee all setup is visible to the specific IRQ, this is what it's point is. > > > > > > > > > > > > > We use smp_store_relase() > > > > > to make sure the driver commits the setup before enabling the irq. It > > > > > means the read needs to be ordered as well in vring_interrupt(). > > > > > > > > > > > > > > > > > Although I couldn't find anything about this in memory-barriers.txt > > > > > > which surprises me. > > > > > > > > > > > > CC Paul to help make sure I'm right. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To avoid breaking legacy device which can send IRQ before DRIVER_OK, a > > > > > > > > > module parameter is introduced to enable the hardening so function > > > > > > > > > hardening is disabled by default. > > > > > > > > Which devices are these? How come they send an interrupt before there > > > > > > > > are any buffers in any queues? > > > > > > > > > > > > > > > > > > > > > I copied this from the commit log for 22b7050a024d7 > > > > > > > > > > > > > > " > > > > > > > > > > > > > > This change will also benefit old hypervisors (before 2009) > > > > > > > that send interrupts without checking DRIVER_OK: previously, > > > > > > > the callback could race with driver-specific initialization. > > > > > > > " > > > > > > > > > > > > > > If this is only for config interrupt, I can remove the above log. > > > > > > > > > > > > > > > > > > This is only for config interrupt. > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Note that the hardening is only done for vring interrupt since the > > > > > > > > > config interrupt hardening is already done in commit 22b7050a024d7 > > > > > > > > > ("virtio: defer config changed notifications"). But the method that is > > > > > > > > > used by config interrupt can't be reused by the vring interrupt > > > > > > > > > handler because it uses spinlock to do the synchronization which is > > > > > > > > > expensive. > > > > > > > > > > > > > > > > > > Signed-off-by: Jason Wang <jasowang@redhat.com> > > > > > > > > > > > > > > > > > --- > > > > > > > > > drivers/virtio/virtio.c | 19 +++++++++++++++++++ > > > > > > > > > drivers/virtio/virtio_ring.c | 9 ++++++++- > > > > > > > > > include/linux/virtio.h | 4 ++++ > > > > > > > > > include/linux/virtio_config.h | 25 +++++++++++++++++++++++++ > > > > > > > > > 4 files changed, 56 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c > > > > > > > > > index 8dde44ea044a..85e331efa9cc 100644 > > > > > > > > > --- a/drivers/virtio/virtio.c > > > > > > > > > +++ b/drivers/virtio/virtio.c > > > > > > > > > @@ -7,6 +7,12 @@ > > > > > > > > > #include <linux/of.h> > > > > > > > > > #include <uapi/linux/virtio_ids.h> > > > > > > > > > +static bool irq_hardening = false; > > > > > > > > > + > > > > > > > > > +module_param(irq_hardening, bool, 0444); > > > > > > > > > +MODULE_PARM_DESC(irq_hardening, > > > > > > > > > + "Disalbe IRQ software processing when it is not expected"); > > > > > > > > > + > > > > > > > > > /* Unique numbering for virtio devices. */ > > > > > > > > > static DEFINE_IDA(virtio_index_ida); > > > > > > > > > @@ -220,6 +226,15 @@ static int virtio_features_ok(struct virtio_device *dev) > > > > > > > > > * */ > > > > > > > > > void virtio_reset_device(struct virtio_device *dev) > > > > > > > > > { > > > > > > > > > + /* > > > > > > > > > + * The below synchronize_rcu() guarantees that any > > > > > > > > > + * interrupt for this line arriving after > > > > > > > > > + * synchronize_rcu() has completed is guaranteed to see > > > > > > > > > + * irq_soft_enabled == false. > > > > > > > > News to me I did not know synchronize_rcu has anything to do > > > > > > > > with interrupts. Did not you intend to use synchronize_irq? > > > > > > > > I am not even 100% sure synchronize_rcu is by design a memory barrier > > > > > > > > though it's most likely is ... > > > > > > > > > > > > > > > > > > > > > According to the comment above tree RCU version of synchronize_rcu(): > > > > > > > > > > > > > > """ > > > > > > > > > > > > > > * RCU read-side critical sections are delimited by rcu_read_lock() > > > > > > > * and rcu_read_unlock(), and may be nested. In addition, but only in > > > > > > > * v5.0 and later, regions of code across which interrupts, preemption, > > > > > > > * or softirqs have been disabled also serve as RCU read-side critical > > > > > > > * sections. This includes hardware interrupt handlers, softirq handlers, > > > > > > > * and NMI handlers. > > > > > > > """ > > > > > > > > > > > > > > So interrupt handlers are treated as read-side critical sections. > > > > > > > > > > > > > > And it has the comment for explain the barrier: > > > > > > > > > > > > > > """ > > > > > > > > > > > > > > * Note that this guarantee implies further memory-ordering guarantees. > > > > > > > * On systems with more than one CPU, when synchronize_rcu() returns, > > > > > > > * each CPU is guaranteed to have executed a full memory barrier since > > > > > > > * the end of its last RCU read-side critical section whose beginning > > > > > > > * preceded the call to synchronize_rcu(). In addition, each CPU having > > > > > > > """ > > > > > > > > > > > > > > So on SMP it provides a full barrier. And for UP/tiny RCU we don't need the > > > > > > > barrier, if the interrupt come after WRITE_ONCE() it will see the > > > > > > > irq_soft_enabled as false. > > > > > > > > > > > > > > > > > > > You are right. So then > > > > > > 1. I do not think we need load_acquire - why is it needed? Just > > > > > > READ_ONCE should do. > > > > > > > > > > See above. > > > > > > > > > > > 2. isn't synchronize_irq also doing the same thing? > > > > > > > > > > > > > > > Yes, but it requires a config ops since the IRQ knowledge is transport specific. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + */ > > > > > > > > > + WRITE_ONCE(dev->irq_soft_enabled, false); > > > > > > > > > + synchronize_rcu(); > > > > > > > > > + > > > > > > > > > dev->config->reset(dev); > > > > > > > > > } > > > > > > > > > EXPORT_SYMBOL_GPL(virtio_reset_device); > > > > > > > > Please add comment explaining where it will be enabled. > > > > > > > > Also, we *really* don't need to synch if it was already disabled, > > > > > > > > let's not add useless overhead to the boot sequence. > > > > > > > > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > @@ -427,6 +442,10 @@ int register_virtio_device(struct virtio_device *dev) > > > > > > > > > spin_lock_init(&dev->config_lock); > > > > > > > > > dev->config_enabled = false; > > > > > > > > > dev->config_change_pending = false; > > > > > > > > > + dev->irq_soft_check = irq_hardening; > > > > > > > > > + > > > > > > > > > + if (dev->irq_soft_check) > > > > > > > > > + dev_info(&dev->dev, "IRQ hardening is enabled\n"); > > > > > > > > > /* We always start by resetting the device, in case a previous > > > > > > > > > * driver messed it up. This also tests that code path a little. */ > > > > > > > > one of the points of hardening is it's also helpful for buggy > > > > > > > > devices. this flag defeats the purpose. > > > > > > > > > > > > > > > > > > > > > Do you mean: > > > > > > > > > > > > > > 1) we need something like config_enable? This seems not easy to be > > > > > > > implemented without obvious overhead, mainly the synchronize with the > > > > > > > interrupt handlers > > > > > > > > > > > > But synchronize is only on tear-down path. That is not critical for any > > > > > > users at the moment, even less than probe. > > > > > > > > > > I meant if we have vq->irq_pending, we need to call vring_interrupt() > > > > > in the virtio_device_ready() and synchronize the IRQ handlers with > > > > > spinlock or others. > > > > > > > > > > > > > > > > > > 2) enable this by default, so I don't object, but this may have some risk > > > > > > > for old hypervisors > > > > > > > > > > > > > > > > > > The risk if there's a driver adding buffers without setting DRIVER_OK. > > > > > > > > > > Probably not, we have devices that accept random inputs from outside, > > > > > net, console, input etc. I've done a round of audits of the Qemu > > > > > codes. They look all fine since day0. > > > > > > > > > > > So with this approach, how about we rename the flag "driver_ok"? > > > > > > And then add_buf can actually test it and BUG_ON if not there (at least > > > > > > in the debug build). > > > > > > > > > > This looks like a hardening of the driver in the core instead of the > > > > > device. I think it can be done but in a separate series. > > > > > > > > > > > > > > > > > And going down from there, how about we cache status in the > > > > > > device? Then we don't need to keep re-reading it every time, > > > > > > speeding boot up a tiny bit. > > > > > > > > > > I don't fully understand here, actually spec requires status to be > > > > > read back for validation in many cases. > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > > > > > > > > index 962f1477b1fa..0170f8c784d8 100644 > > > > > > > > > --- a/drivers/virtio/virtio_ring.c > > > > > > > > > +++ b/drivers/virtio/virtio_ring.c > > > > > > > > > @@ -2144,10 +2144,17 @@ static inline bool more_used(const struct vring_virtqueue *vq) > > > > > > > > > return vq->packed_ring ? more_used_packed(vq) : more_used_split(vq); > > > > > > > > > } > > > > > > > > > -irqreturn_t vring_interrupt(int irq, void *_vq) > > > > > > > > > +irqreturn_t vring_interrupt(int irq, void *v) > > > > > > > > > { > > > > > > > > > + struct virtqueue *_vq = v; > > > > > > > > > + struct virtio_device *vdev = _vq->vdev; > > > > > > > > > struct vring_virtqueue *vq = to_vvq(_vq); > > > > > > > > > + if (!virtio_irq_soft_enabled(vdev)) { > > > > > > > > > + dev_warn_once(&vdev->dev, "virtio vring IRQ raised before DRIVER_OK"); > > > > > > > > > + return IRQ_NONE; > > > > > > > > > + } > > > > > > > > > + > > > > > > > > > if (!more_used(vq)) { > > > > > > > > > pr_debug("virtqueue interrupt with no work for %p\n", vq); > > > > > > > > > return IRQ_NONE; > > > > > > > > > diff --git a/include/linux/virtio.h b/include/linux/virtio.h > > > > > > > > > index 5464f398912a..957d6ad604ac 100644 > > > > > > > > > --- a/include/linux/virtio.h > > > > > > > > > +++ b/include/linux/virtio.h > > > > > > > > > @@ -95,6 +95,8 @@ dma_addr_t virtqueue_get_used_addr(struct virtqueue *vq); > > > > > > > > > * @failed: saved value for VIRTIO_CONFIG_S_FAILED bit (for restore) > > > > > > > > > * @config_enabled: configuration change reporting enabled > > > > > > > > > * @config_change_pending: configuration change reported while disabled > > > > > > > > > + * @irq_soft_check: whether or not to check @irq_soft_enabled > > > > > > > > > + * @irq_soft_enabled: callbacks enabled > > > > > > > > > * @config_lock: protects configuration change reporting > > > > > > > > > * @dev: underlying device. > > > > > > > > > * @id: the device type identification (used to match it with a driver). > > > > > > > > > @@ -109,6 +111,8 @@ struct virtio_device { > > > > > > > > > bool failed; > > > > > > > > > bool config_enabled; > > > > > > > > > bool config_change_pending; > > > > > > > > > + bool irq_soft_check; > > > > > > > > > + bool irq_soft_enabled; > > > > > > > > > spinlock_t config_lock; > > > > > > > > > spinlock_t vqs_list_lock; /* Protects VQs list access */ > > > > > > > > > struct device dev; > > > > > > > > > diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h > > > > > > > > > index dafdc7f48c01..9c1b61f2e525 100644 > > > > > > > > > --- a/include/linux/virtio_config.h > > > > > > > > > +++ b/include/linux/virtio_config.h > > > > > > > > > @@ -174,6 +174,24 @@ static inline bool virtio_has_feature(const struct virtio_device *vdev, > > > > > > > > > return __virtio_test_bit(vdev, fbit); > > > > > > > > > } > > > > > > > > > +/* > > > > > > > > > + * virtio_irq_soft_enabled: whether we can execute callbacks > > > > > > > > > + * @vdev: the device > > > > > > > > > + */ > > > > > > > > > +static inline bool virtio_irq_soft_enabled(const struct virtio_device *vdev) > > > > > > > > > +{ > > > > > > > > > + if (!vdev->irq_soft_check) > > > > > > > > > + return true; > > > > > > > > > + > > > > > > > > > + /* > > > > > > > > > + * Read irq_soft_enabled before reading other device specific > > > > > > > > > + * data. Paried with smp_store_relase() in > > > > > > > > paired > > > > > > > > > > > > > > > > > > > > > Will fix. > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + * virtio_device_ready() and WRITE_ONCE()/synchronize_rcu() in > > > > > > > > > + * virtio_reset_device(). > > > > > > > > > + */ > > > > > > > > > + return smp_load_acquire(&vdev->irq_soft_enabled); > > > > > > > > > +} > > > > > > > > > + > > > > > > > > > /** > > > > > > > > > * virtio_has_dma_quirk - determine whether this device has the DMA quirk > > > > > > > > > * @vdev: the device > > > > > > > > > @@ -236,6 +254,13 @@ void virtio_device_ready(struct virtio_device *dev) > > > > > > > > > if (dev->config->enable_cbs) > > > > > > > > > dev->config->enable_cbs(dev); > > > > > > > > > + /* > > > > > > > > > + * Commit the driver setup before enabling the virtqueue > > > > > > > > > + * callbacks. Paried with smp_load_acuqire() in > > > > > > > > > + * virtio_irq_soft_enabled() > > > > > > > > > + */ > > > > > > > > > + smp_store_release(&dev->irq_soft_enabled, true); > > > > > > > > > + > > > > > > > > > BUG_ON(status & VIRTIO_CONFIG_S_DRIVER_OK); > > > > > > > > > dev->config->set_status(dev, status | VIRTIO_CONFIG_S_DRIVER_OK); > > > > > > > > > } > > > > > > > > > -- > > > > > > > > > 2.25.1 > > > > > > > > > > > > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-03-28 5:59 ` Re: Michael S. Tsirkin @ 2022-03-28 6:18 ` Jason Wang 2022-03-28 10:40 ` Re: Michael S. Tsirkin 0 siblings, 1 reply; 1767+ messages in thread From: Jason Wang @ 2022-03-28 6:18 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Paul E. McKenney, Peter Zijlstra, Marc Zyngier, Keir Fraser, linux-kernel, virtualization, Thomas Gleixner On Mon, Mar 28, 2022 at 1:59 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > On Mon, Mar 28, 2022 at 12:56:41PM +0800, Jason Wang wrote: > > On Fri, Mar 25, 2022 at 6:10 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > On Fri, Mar 25, 2022 at 05:20:19PM +0800, Jason Wang wrote: > > > > On Fri, Mar 25, 2022 at 5:10 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > > > > > On Fri, Mar 25, 2022 at 03:52:00PM +0800, Jason Wang wrote: > > > > > > On Fri, Mar 25, 2022 at 2:31 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > > > > > > > > > Bcc: > > > > > > > Subject: Re: [PATCH 3/3] virtio: harden vring IRQ > > > > > > > Message-ID: <20220325021422-mutt-send-email-mst@kernel.org> > > > > > > > Reply-To: > > > > > > > In-Reply-To: <f7046303-7d7d-e39f-3c71-3688126cc812@redhat.com> > > > > > > > > > > > > > > On Fri, Mar 25, 2022 at 11:04:08AM +0800, Jason Wang wrote: > > > > > > > > > > > > > > > > 在 2022/3/24 下午7:03, Michael S. Tsirkin 写道: > > > > > > > > > On Thu, Mar 24, 2022 at 04:40:04PM +0800, Jason Wang wrote: > > > > > > > > > > This is a rework on the previous IRQ hardening that is done for > > > > > > > > > > virtio-pci where several drawbacks were found and were reverted: > > > > > > > > > > > > > > > > > > > > 1) try to use IRQF_NO_AUTOEN which is not friendly to affinity managed IRQ > > > > > > > > > > that is used by some device such as virtio-blk > > > > > > > > > > 2) done only for PCI transport > > > > > > > > > > > > > > > > > > > > In this patch, we tries to borrow the idea from the INTX IRQ hardening > > > > > > > > > > in the reverted commit 080cd7c3ac87 ("virtio-pci: harden INTX interrupts") > > > > > > > > > > by introducing a global irq_soft_enabled variable for each > > > > > > > > > > virtio_device. Then we can to toggle it during > > > > > > > > > > virtio_reset_device()/virtio_device_ready(). A synchornize_rcu() is > > > > > > > > > > used in virtio_reset_device() to synchronize with the IRQ handlers. In > > > > > > > > > > the future, we may provide config_ops for the transport that doesn't > > > > > > > > > > use IRQ. With this, vring_interrupt() can return check and early if > > > > > > > > > > irq_soft_enabled is false. This lead to smp_load_acquire() to be used > > > > > > > > > > but the cost should be acceptable. > > > > > > > > > Maybe it should be but is it? Can't we use synchronize_irq instead? > > > > > > > > > > > > > > > > > > > > > > > > Even if we allow the transport driver to synchornize through > > > > > > > > synchronize_irq() we still need a check in the vring_interrupt(). > > > > > > > > > > > > > > > > We do something like the following previously: > > > > > > > > > > > > > > > > if (!READ_ONCE(vp_dev->intx_soft_enabled)) > > > > > > > > return IRQ_NONE; > > > > > > > > > > > > > > > > But it looks like a bug since speculative read can be done before the check > > > > > > > > where the interrupt handler can't see the uncommitted setup which is done by > > > > > > > > the driver. > > > > > > > > > > > > > > I don't think so - if you sync after setting the value then > > > > > > > you are guaranteed that any handler running afterwards > > > > > > > will see the new value. > > > > > > > > > > > > The problem is not disabled but the enable. > > > > > > > > > > So a misbehaving device can lose interrupts? That's not a problem at all > > > > > imo. > > > > > > > > It's the interrupt raised before setting irq_soft_enabled to true: > > > > > > > > CPU 0 probe) driver specific setup (not commited) > > > > CPU 1 IRQ handler) read the uninitialized variable > > > > CPU 0 probe) set irq_soft_enabled to true > > > > CPU 1 IRQ handler) read irq_soft_enable as true > > > > CPU 1 IRQ handler) use the uninitialized variable > > > > > > > > Thanks > > > > > > Yea, it hurts if you do it. So do not do it then ;). > > > > > > irq_soft_enabled (I think driver_ok or status is a better name) > > > > I can change it to driver_ok. > > > > > should be initialized to false *before* irq is requested. > > > > > > And requesting irq commits all memory otherwise all drivers would be > > > broken, > > > > So I think we might talk different issues: > > > > 1) Whether request_irq() commits the previous setups, I think the > > answer is yes, since the spin_unlock of desc->lock (release) can > > guarantee this though there seems no documentation around > > request_irq() to say this. > > > > And I can see at least drivers/video/fbdev/omap2/omapfb/dss/dispc.c is > > using smp_wmb() before the request_irq(). > > > > And even if write is ordered we still need read to be ordered to be > > paired with that. > > > > > if it doesn't it just needs to be fixed, not worked around in > > > virtio. > > > > 2) virtio drivers might do a lot of setups between request_irq() and > > virtio_device_ready(): > > > > request_irq() > > driver specific setups > > virtio_device_ready() > > > > CPU 0 probe) request_irq() > > CPU 1 IRQ handler) read the uninitialized variable > > CPU 0 probe) driver specific setups > > CPU 0 probe) smp_store_release(intr_soft_enabled, true), commit the setups > > CPU 1 IRQ handler) read irq_soft_enable as true > > CPU 1 IRQ handler) use the uninitialized variable > > > > Thanks > > > As I said, virtio_device_ready needs to do synchronize_irq. > That will guarantee all setup is visible to the specific IRQ, Only the interrupt after synchronize_irq() returns. >this > is what it's point is. What happens if an interrupt is raised in the middle like: smp_store_release(dev->irq_soft_enabled, true) IRQ handler synchornize_irq() If we don't enforce a reading order, the IRQ handler may still see the uninitialized variable. Thanks > > > > > > > > > > > > > > > > > > > We use smp_store_relase() > > > > > > to make sure the driver commits the setup before enabling the irq. It > > > > > > means the read needs to be ordered as well in vring_interrupt(). > > > > > > > > > > > > > > > > > > > > Although I couldn't find anything about this in memory-barriers.txt > > > > > > > which surprises me. > > > > > > > > > > > > > > CC Paul to help make sure I'm right. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To avoid breaking legacy device which can send IRQ before DRIVER_OK, a > > > > > > > > > > module parameter is introduced to enable the hardening so function > > > > > > > > > > hardening is disabled by default. > > > > > > > > > Which devices are these? How come they send an interrupt before there > > > > > > > > > are any buffers in any queues? > > > > > > > > > > > > > > > > > > > > > > > > I copied this from the commit log for 22b7050a024d7 > > > > > > > > > > > > > > > > " > > > > > > > > > > > > > > > > This change will also benefit old hypervisors (before 2009) > > > > > > > > that send interrupts without checking DRIVER_OK: previously, > > > > > > > > the callback could race with driver-specific initialization. > > > > > > > > " > > > > > > > > > > > > > > > > If this is only for config interrupt, I can remove the above log. > > > > > > > > > > > > > > > > > > > > > This is only for config interrupt. > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Note that the hardening is only done for vring interrupt since the > > > > > > > > > > config interrupt hardening is already done in commit 22b7050a024d7 > > > > > > > > > > ("virtio: defer config changed notifications"). But the method that is > > > > > > > > > > used by config interrupt can't be reused by the vring interrupt > > > > > > > > > > handler because it uses spinlock to do the synchronization which is > > > > > > > > > > expensive. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Jason Wang <jasowang@redhat.com> > > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > drivers/virtio/virtio.c | 19 +++++++++++++++++++ > > > > > > > > > > drivers/virtio/virtio_ring.c | 9 ++++++++- > > > > > > > > > > include/linux/virtio.h | 4 ++++ > > > > > > > > > > include/linux/virtio_config.h | 25 +++++++++++++++++++++++++ > > > > > > > > > > 4 files changed, 56 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c > > > > > > > > > > index 8dde44ea044a..85e331efa9cc 100644 > > > > > > > > > > --- a/drivers/virtio/virtio.c > > > > > > > > > > +++ b/drivers/virtio/virtio.c > > > > > > > > > > @@ -7,6 +7,12 @@ > > > > > > > > > > #include <linux/of.h> > > > > > > > > > > #include <uapi/linux/virtio_ids.h> > > > > > > > > > > +static bool irq_hardening = false; > > > > > > > > > > + > > > > > > > > > > +module_param(irq_hardening, bool, 0444); > > > > > > > > > > +MODULE_PARM_DESC(irq_hardening, > > > > > > > > > > + "Disalbe IRQ software processing when it is not expected"); > > > > > > > > > > + > > > > > > > > > > /* Unique numbering for virtio devices. */ > > > > > > > > > > static DEFINE_IDA(virtio_index_ida); > > > > > > > > > > @@ -220,6 +226,15 @@ static int virtio_features_ok(struct virtio_device *dev) > > > > > > > > > > * */ > > > > > > > > > > void virtio_reset_device(struct virtio_device *dev) > > > > > > > > > > { > > > > > > > > > > + /* > > > > > > > > > > + * The below synchronize_rcu() guarantees that any > > > > > > > > > > + * interrupt for this line arriving after > > > > > > > > > > + * synchronize_rcu() has completed is guaranteed to see > > > > > > > > > > + * irq_soft_enabled == false. > > > > > > > > > News to me I did not know synchronize_rcu has anything to do > > > > > > > > > with interrupts. Did not you intend to use synchronize_irq? > > > > > > > > > I am not even 100% sure synchronize_rcu is by design a memory barrier > > > > > > > > > though it's most likely is ... > > > > > > > > > > > > > > > > > > > > > > > > According to the comment above tree RCU version of synchronize_rcu(): > > > > > > > > > > > > > > > > """ > > > > > > > > > > > > > > > > * RCU read-side critical sections are delimited by rcu_read_lock() > > > > > > > > * and rcu_read_unlock(), and may be nested. In addition, but only in > > > > > > > > * v5.0 and later, regions of code across which interrupts, preemption, > > > > > > > > * or softirqs have been disabled also serve as RCU read-side critical > > > > > > > > * sections. This includes hardware interrupt handlers, softirq handlers, > > > > > > > > * and NMI handlers. > > > > > > > > """ > > > > > > > > > > > > > > > > So interrupt handlers are treated as read-side critical sections. > > > > > > > > > > > > > > > > And it has the comment for explain the barrier: > > > > > > > > > > > > > > > > """ > > > > > > > > > > > > > > > > * Note that this guarantee implies further memory-ordering guarantees. > > > > > > > > * On systems with more than one CPU, when synchronize_rcu() returns, > > > > > > > > * each CPU is guaranteed to have executed a full memory barrier since > > > > > > > > * the end of its last RCU read-side critical section whose beginning > > > > > > > > * preceded the call to synchronize_rcu(). In addition, each CPU having > > > > > > > > """ > > > > > > > > > > > > > > > > So on SMP it provides a full barrier. And for UP/tiny RCU we don't need the > > > > > > > > barrier, if the interrupt come after WRITE_ONCE() it will see the > > > > > > > > irq_soft_enabled as false. > > > > > > > > > > > > > > > > > > > > > > You are right. So then > > > > > > > 1. I do not think we need load_acquire - why is it needed? Just > > > > > > > READ_ONCE should do. > > > > > > > > > > > > See above. > > > > > > > > > > > > > 2. isn't synchronize_irq also doing the same thing? > > > > > > > > > > > > > > > > > > Yes, but it requires a config ops since the IRQ knowledge is transport specific. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + */ > > > > > > > > > > + WRITE_ONCE(dev->irq_soft_enabled, false); > > > > > > > > > > + synchronize_rcu(); > > > > > > > > > > + > > > > > > > > > > dev->config->reset(dev); > > > > > > > > > > } > > > > > > > > > > EXPORT_SYMBOL_GPL(virtio_reset_device); > > > > > > > > > Please add comment explaining where it will be enabled. > > > > > > > > > Also, we *really* don't need to synch if it was already disabled, > > > > > > > > > let's not add useless overhead to the boot sequence. > > > > > > > > > > > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > @@ -427,6 +442,10 @@ int register_virtio_device(struct virtio_device *dev) > > > > > > > > > > spin_lock_init(&dev->config_lock); > > > > > > > > > > dev->config_enabled = false; > > > > > > > > > > dev->config_change_pending = false; > > > > > > > > > > + dev->irq_soft_check = irq_hardening; > > > > > > > > > > + > > > > > > > > > > + if (dev->irq_soft_check) > > > > > > > > > > + dev_info(&dev->dev, "IRQ hardening is enabled\n"); > > > > > > > > > > /* We always start by resetting the device, in case a previous > > > > > > > > > > * driver messed it up. This also tests that code path a little. */ > > > > > > > > > one of the points of hardening is it's also helpful for buggy > > > > > > > > > devices. this flag defeats the purpose. > > > > > > > > > > > > > > > > > > > > > > > > Do you mean: > > > > > > > > > > > > > > > > 1) we need something like config_enable? This seems not easy to be > > > > > > > > implemented without obvious overhead, mainly the synchronize with the > > > > > > > > interrupt handlers > > > > > > > > > > > > > > But synchronize is only on tear-down path. That is not critical for any > > > > > > > users at the moment, even less than probe. > > > > > > > > > > > > I meant if we have vq->irq_pending, we need to call vring_interrupt() > > > > > > in the virtio_device_ready() and synchronize the IRQ handlers with > > > > > > spinlock or others. > > > > > > > > > > > > > > > > > > > > > 2) enable this by default, so I don't object, but this may have some risk > > > > > > > > for old hypervisors > > > > > > > > > > > > > > > > > > > > > The risk if there's a driver adding buffers without setting DRIVER_OK. > > > > > > > > > > > > Probably not, we have devices that accept random inputs from outside, > > > > > > net, console, input etc. I've done a round of audits of the Qemu > > > > > > codes. They look all fine since day0. > > > > > > > > > > > > > So with this approach, how about we rename the flag "driver_ok"? > > > > > > > And then add_buf can actually test it and BUG_ON if not there (at least > > > > > > > in the debug build). > > > > > > > > > > > > This looks like a hardening of the driver in the core instead of the > > > > > > device. I think it can be done but in a separate series. > > > > > > > > > > > > > > > > > > > > And going down from there, how about we cache status in the > > > > > > > device? Then we don't need to keep re-reading it every time, > > > > > > > speeding boot up a tiny bit. > > > > > > > > > > > > I don't fully understand here, actually spec requires status to be > > > > > > read back for validation in many cases. > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > > > > > > > > > index 962f1477b1fa..0170f8c784d8 100644 > > > > > > > > > > --- a/drivers/virtio/virtio_ring.c > > > > > > > > > > +++ b/drivers/virtio/virtio_ring.c > > > > > > > > > > @@ -2144,10 +2144,17 @@ static inline bool more_used(const struct vring_virtqueue *vq) > > > > > > > > > > return vq->packed_ring ? more_used_packed(vq) : more_used_split(vq); > > > > > > > > > > } > > > > > > > > > > -irqreturn_t vring_interrupt(int irq, void *_vq) > > > > > > > > > > +irqreturn_t vring_interrupt(int irq, void *v) > > > > > > > > > > { > > > > > > > > > > + struct virtqueue *_vq = v; > > > > > > > > > > + struct virtio_device *vdev = _vq->vdev; > > > > > > > > > > struct vring_virtqueue *vq = to_vvq(_vq); > > > > > > > > > > + if (!virtio_irq_soft_enabled(vdev)) { > > > > > > > > > > + dev_warn_once(&vdev->dev, "virtio vring IRQ raised before DRIVER_OK"); > > > > > > > > > > + return IRQ_NONE; > > > > > > > > > > + } > > > > > > > > > > + > > > > > > > > > > if (!more_used(vq)) { > > > > > > > > > > pr_debug("virtqueue interrupt with no work for %p\n", vq); > > > > > > > > > > return IRQ_NONE; > > > > > > > > > > diff --git a/include/linux/virtio.h b/include/linux/virtio.h > > > > > > > > > > index 5464f398912a..957d6ad604ac 100644 > > > > > > > > > > --- a/include/linux/virtio.h > > > > > > > > > > +++ b/include/linux/virtio.h > > > > > > > > > > @@ -95,6 +95,8 @@ dma_addr_t virtqueue_get_used_addr(struct virtqueue *vq); > > > > > > > > > > * @failed: saved value for VIRTIO_CONFIG_S_FAILED bit (for restore) > > > > > > > > > > * @config_enabled: configuration change reporting enabled > > > > > > > > > > * @config_change_pending: configuration change reported while disabled > > > > > > > > > > + * @irq_soft_check: whether or not to check @irq_soft_enabled > > > > > > > > > > + * @irq_soft_enabled: callbacks enabled > > > > > > > > > > * @config_lock: protects configuration change reporting > > > > > > > > > > * @dev: underlying device. > > > > > > > > > > * @id: the device type identification (used to match it with a driver). > > > > > > > > > > @@ -109,6 +111,8 @@ struct virtio_device { > > > > > > > > > > bool failed; > > > > > > > > > > bool config_enabled; > > > > > > > > > > bool config_change_pending; > > > > > > > > > > + bool irq_soft_check; > > > > > > > > > > + bool irq_soft_enabled; > > > > > > > > > > spinlock_t config_lock; > > > > > > > > > > spinlock_t vqs_list_lock; /* Protects VQs list access */ > > > > > > > > > > struct device dev; > > > > > > > > > > diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h > > > > > > > > > > index dafdc7f48c01..9c1b61f2e525 100644 > > > > > > > > > > --- a/include/linux/virtio_config.h > > > > > > > > > > +++ b/include/linux/virtio_config.h > > > > > > > > > > @@ -174,6 +174,24 @@ static inline bool virtio_has_feature(const struct virtio_device *vdev, > > > > > > > > > > return __virtio_test_bit(vdev, fbit); > > > > > > > > > > } > > > > > > > > > > +/* > > > > > > > > > > + * virtio_irq_soft_enabled: whether we can execute callbacks > > > > > > > > > > + * @vdev: the device > > > > > > > > > > + */ > > > > > > > > > > +static inline bool virtio_irq_soft_enabled(const struct virtio_device *vdev) > > > > > > > > > > +{ > > > > > > > > > > + if (!vdev->irq_soft_check) > > > > > > > > > > + return true; > > > > > > > > > > + > > > > > > > > > > + /* > > > > > > > > > > + * Read irq_soft_enabled before reading other device specific > > > > > > > > > > + * data. Paried with smp_store_relase() in > > > > > > > > > paired > > > > > > > > > > > > > > > > > > > > > > > > Will fix. > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + * virtio_device_ready() and WRITE_ONCE()/synchronize_rcu() in > > > > > > > > > > + * virtio_reset_device(). > > > > > > > > > > + */ > > > > > > > > > > + return smp_load_acquire(&vdev->irq_soft_enabled); > > > > > > > > > > +} > > > > > > > > > > + > > > > > > > > > > /** > > > > > > > > > > * virtio_has_dma_quirk - determine whether this device has the DMA quirk > > > > > > > > > > * @vdev: the device > > > > > > > > > > @@ -236,6 +254,13 @@ void virtio_device_ready(struct virtio_device *dev) > > > > > > > > > > if (dev->config->enable_cbs) > > > > > > > > > > dev->config->enable_cbs(dev); > > > > > > > > > > + /* > > > > > > > > > > + * Commit the driver setup before enabling the virtqueue > > > > > > > > > > + * callbacks. Paried with smp_load_acuqire() in > > > > > > > > > > + * virtio_irq_soft_enabled() > > > > > > > > > > + */ > > > > > > > > > > + smp_store_release(&dev->irq_soft_enabled, true); > > > > > > > > > > + > > > > > > > > > > BUG_ON(status & VIRTIO_CONFIG_S_DRIVER_OK); > > > > > > > > > > dev->config->set_status(dev, status | VIRTIO_CONFIG_S_DRIVER_OK); > > > > > > > > > > } > > > > > > > > > > -- > > > > > > > > > > 2.25.1 > > > > > > > > > > > > > > > > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-03-28 6:18 ` Re: Jason Wang @ 2022-03-28 10:40 ` Michael S. Tsirkin 2022-03-29 7:12 ` Re: Jason Wang 2022-03-29 8:35 ` Re: Thomas Gleixner 0 siblings, 2 replies; 1767+ messages in thread From: Michael S. Tsirkin @ 2022-03-28 10:40 UTC (permalink / raw) To: Jason Wang Cc: Paul E. McKenney, Peter Zijlstra, Marc Zyngier, Keir Fraser, linux-kernel, virtualization, Thomas Gleixner On Mon, Mar 28, 2022 at 02:18:22PM +0800, Jason Wang wrote: > On Mon, Mar 28, 2022 at 1:59 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > On Mon, Mar 28, 2022 at 12:56:41PM +0800, Jason Wang wrote: > > > On Fri, Mar 25, 2022 at 6:10 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > > > On Fri, Mar 25, 2022 at 05:20:19PM +0800, Jason Wang wrote: > > > > > On Fri, Mar 25, 2022 at 5:10 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > > > > > > > On Fri, Mar 25, 2022 at 03:52:00PM +0800, Jason Wang wrote: > > > > > > > On Fri, Mar 25, 2022 at 2:31 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > > > > > > > > > > > Bcc: > > > > > > > > Subject: Re: [PATCH 3/3] virtio: harden vring IRQ > > > > > > > > Message-ID: <20220325021422-mutt-send-email-mst@kernel.org> > > > > > > > > Reply-To: > > > > > > > > In-Reply-To: <f7046303-7d7d-e39f-3c71-3688126cc812@redhat.com> > > > > > > > > > > > > > > > > On Fri, Mar 25, 2022 at 11:04:08AM +0800, Jason Wang wrote: > > > > > > > > > > > > > > > > > > 在 2022/3/24 下午7:03, Michael S. Tsirkin 写道: > > > > > > > > > > On Thu, Mar 24, 2022 at 04:40:04PM +0800, Jason Wang wrote: > > > > > > > > > > > This is a rework on the previous IRQ hardening that is done for > > > > > > > > > > > virtio-pci where several drawbacks were found and were reverted: > > > > > > > > > > > > > > > > > > > > > > 1) try to use IRQF_NO_AUTOEN which is not friendly to affinity managed IRQ > > > > > > > > > > > that is used by some device such as virtio-blk > > > > > > > > > > > 2) done only for PCI transport > > > > > > > > > > > > > > > > > > > > > > In this patch, we tries to borrow the idea from the INTX IRQ hardening > > > > > > > > > > > in the reverted commit 080cd7c3ac87 ("virtio-pci: harden INTX interrupts") > > > > > > > > > > > by introducing a global irq_soft_enabled variable for each > > > > > > > > > > > virtio_device. Then we can to toggle it during > > > > > > > > > > > virtio_reset_device()/virtio_device_ready(). A synchornize_rcu() is > > > > > > > > > > > used in virtio_reset_device() to synchronize with the IRQ handlers. In > > > > > > > > > > > the future, we may provide config_ops for the transport that doesn't > > > > > > > > > > > use IRQ. With this, vring_interrupt() can return check and early if > > > > > > > > > > > irq_soft_enabled is false. This lead to smp_load_acquire() to be used > > > > > > > > > > > but the cost should be acceptable. > > > > > > > > > > Maybe it should be but is it? Can't we use synchronize_irq instead? > > > > > > > > > > > > > > > > > > > > > > > > > > > Even if we allow the transport driver to synchornize through > > > > > > > > > synchronize_irq() we still need a check in the vring_interrupt(). > > > > > > > > > > > > > > > > > > We do something like the following previously: > > > > > > > > > > > > > > > > > > if (!READ_ONCE(vp_dev->intx_soft_enabled)) > > > > > > > > > return IRQ_NONE; > > > > > > > > > > > > > > > > > > But it looks like a bug since speculative read can be done before the check > > > > > > > > > where the interrupt handler can't see the uncommitted setup which is done by > > > > > > > > > the driver. > > > > > > > > > > > > > > > > I don't think so - if you sync after setting the value then > > > > > > > > you are guaranteed that any handler running afterwards > > > > > > > > will see the new value. > > > > > > > > > > > > > > The problem is not disabled but the enable. > > > > > > > > > > > > So a misbehaving device can lose interrupts? That's not a problem at all > > > > > > imo. > > > > > > > > > > It's the interrupt raised before setting irq_soft_enabled to true: > > > > > > > > > > CPU 0 probe) driver specific setup (not commited) > > > > > CPU 1 IRQ handler) read the uninitialized variable > > > > > CPU 0 probe) set irq_soft_enabled to true > > > > > CPU 1 IRQ handler) read irq_soft_enable as true > > > > > CPU 1 IRQ handler) use the uninitialized variable > > > > > > > > > > Thanks > > > > > > > > Yea, it hurts if you do it. So do not do it then ;). > > > > > > > > irq_soft_enabled (I think driver_ok or status is a better name) > > > > > > I can change it to driver_ok. > > > > > > > should be initialized to false *before* irq is requested. > > > > > > > > And requesting irq commits all memory otherwise all drivers would be > > > > broken, > > > > > > So I think we might talk different issues: > > > > > > 1) Whether request_irq() commits the previous setups, I think the > > > answer is yes, since the spin_unlock of desc->lock (release) can > > > guarantee this though there seems no documentation around > > > request_irq() to say this. > > > > > > And I can see at least drivers/video/fbdev/omap2/omapfb/dss/dispc.c is > > > using smp_wmb() before the request_irq(). > > > > > > And even if write is ordered we still need read to be ordered to be > > > paired with that. IMO it synchronizes with the CPU to which irq is delivered. Otherwise basically all drivers would be broken, wouldn't they be? I don't know whether it's correct on all platforms, but if not we need to fix request_irq. > > > > > > > if it doesn't it just needs to be fixed, not worked around in > > > > virtio. > > > > > > 2) virtio drivers might do a lot of setups between request_irq() and > > > virtio_device_ready(): > > > > > > request_irq() > > > driver specific setups > > > virtio_device_ready() > > > > > > CPU 0 probe) request_irq() > > > CPU 1 IRQ handler) read the uninitialized variable > > > CPU 0 probe) driver specific setups > > > CPU 0 probe) smp_store_release(intr_soft_enabled, true), commit the setups > > > CPU 1 IRQ handler) read irq_soft_enable as true > > > CPU 1 IRQ handler) use the uninitialized variable > > > > > > Thanks > > > > > > As I said, virtio_device_ready needs to do synchronize_irq. > > That will guarantee all setup is visible to the specific IRQ, > > Only the interrupt after synchronize_irq() returns. Anything else is a buggy device though. > >this > > is what it's point is. > > What happens if an interrupt is raised in the middle like: > > smp_store_release(dev->irq_soft_enabled, true) > IRQ handler > synchornize_irq() > > If we don't enforce a reading order, the IRQ handler may still see the > uninitialized variable. > > Thanks IMHO variables should be initialized before request_irq to a value meaning "not a valid interrupt". Specifically driver_ok = false. Handler in the scenario you describe will then see !driver_ok and exit immediately. > > > > > > > > > > > > > > > > > > > > > > > > > We use smp_store_relase() > > > > > > > to make sure the driver commits the setup before enabling the irq. It > > > > > > > means the read needs to be ordered as well in vring_interrupt(). > > > > > > > > > > > > > > > > > > > > > > > Although I couldn't find anything about this in memory-barriers.txt > > > > > > > > which surprises me. > > > > > > > > > > > > > > > > CC Paul to help make sure I'm right. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To avoid breaking legacy device which can send IRQ before DRIVER_OK, a > > > > > > > > > > > module parameter is introduced to enable the hardening so function > > > > > > > > > > > hardening is disabled by default. > > > > > > > > > > Which devices are these? How come they send an interrupt before there > > > > > > > > > > are any buffers in any queues? > > > > > > > > > > > > > > > > > > > > > > > > > > > I copied this from the commit log for 22b7050a024d7 > > > > > > > > > > > > > > > > > > " > > > > > > > > > > > > > > > > > > This change will also benefit old hypervisors (before 2009) > > > > > > > > > that send interrupts without checking DRIVER_OK: previously, > > > > > > > > > the callback could race with driver-specific initialization. > > > > > > > > > " > > > > > > > > > > > > > > > > > > If this is only for config interrupt, I can remove the above log. > > > > > > > > > > > > > > > > > > > > > > > > This is only for config interrupt. > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Note that the hardening is only done for vring interrupt since the > > > > > > > > > > > config interrupt hardening is already done in commit 22b7050a024d7 > > > > > > > > > > > ("virtio: defer config changed notifications"). But the method that is > > > > > > > > > > > used by config interrupt can't be reused by the vring interrupt > > > > > > > > > > > handler because it uses spinlock to do the synchronization which is > > > > > > > > > > > expensive. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Jason Wang <jasowang@redhat.com> > > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > drivers/virtio/virtio.c | 19 +++++++++++++++++++ > > > > > > > > > > > drivers/virtio/virtio_ring.c | 9 ++++++++- > > > > > > > > > > > include/linux/virtio.h | 4 ++++ > > > > > > > > > > > include/linux/virtio_config.h | 25 +++++++++++++++++++++++++ > > > > > > > > > > > 4 files changed, 56 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c > > > > > > > > > > > index 8dde44ea044a..85e331efa9cc 100644 > > > > > > > > > > > --- a/drivers/virtio/virtio.c > > > > > > > > > > > +++ b/drivers/virtio/virtio.c > > > > > > > > > > > @@ -7,6 +7,12 @@ > > > > > > > > > > > #include <linux/of.h> > > > > > > > > > > > #include <uapi/linux/virtio_ids.h> > > > > > > > > > > > +static bool irq_hardening = false; > > > > > > > > > > > + > > > > > > > > > > > +module_param(irq_hardening, bool, 0444); > > > > > > > > > > > +MODULE_PARM_DESC(irq_hardening, > > > > > > > > > > > + "Disalbe IRQ software processing when it is not expected"); > > > > > > > > > > > + > > > > > > > > > > > /* Unique numbering for virtio devices. */ > > > > > > > > > > > static DEFINE_IDA(virtio_index_ida); > > > > > > > > > > > @@ -220,6 +226,15 @@ static int virtio_features_ok(struct virtio_device *dev) > > > > > > > > > > > * */ > > > > > > > > > > > void virtio_reset_device(struct virtio_device *dev) > > > > > > > > > > > { > > > > > > > > > > > + /* > > > > > > > > > > > + * The below synchronize_rcu() guarantees that any > > > > > > > > > > > + * interrupt for this line arriving after > > > > > > > > > > > + * synchronize_rcu() has completed is guaranteed to see > > > > > > > > > > > + * irq_soft_enabled == false. > > > > > > > > > > News to me I did not know synchronize_rcu has anything to do > > > > > > > > > > with interrupts. Did not you intend to use synchronize_irq? > > > > > > > > > > I am not even 100% sure synchronize_rcu is by design a memory barrier > > > > > > > > > > though it's most likely is ... > > > > > > > > > > > > > > > > > > > > > > > > > > > According to the comment above tree RCU version of synchronize_rcu(): > > > > > > > > > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > * RCU read-side critical sections are delimited by rcu_read_lock() > > > > > > > > > * and rcu_read_unlock(), and may be nested. In addition, but only in > > > > > > > > > * v5.0 and later, regions of code across which interrupts, preemption, > > > > > > > > > * or softirqs have been disabled also serve as RCU read-side critical > > > > > > > > > * sections. This includes hardware interrupt handlers, softirq handlers, > > > > > > > > > * and NMI handlers. > > > > > > > > > """ > > > > > > > > > > > > > > > > > > So interrupt handlers are treated as read-side critical sections. > > > > > > > > > > > > > > > > > > And it has the comment for explain the barrier: > > > > > > > > > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > * Note that this guarantee implies further memory-ordering guarantees. > > > > > > > > > * On systems with more than one CPU, when synchronize_rcu() returns, > > > > > > > > > * each CPU is guaranteed to have executed a full memory barrier since > > > > > > > > > * the end of its last RCU read-side critical section whose beginning > > > > > > > > > * preceded the call to synchronize_rcu(). In addition, each CPU having > > > > > > > > > """ > > > > > > > > > > > > > > > > > > So on SMP it provides a full barrier. And for UP/tiny RCU we don't need the > > > > > > > > > barrier, if the interrupt come after WRITE_ONCE() it will see the > > > > > > > > > irq_soft_enabled as false. > > > > > > > > > > > > > > > > > > > > > > > > > You are right. So then > > > > > > > > 1. I do not think we need load_acquire - why is it needed? Just > > > > > > > > READ_ONCE should do. > > > > > > > > > > > > > > See above. > > > > > > > > > > > > > > > 2. isn't synchronize_irq also doing the same thing? > > > > > > > > > > > > > > > > > > > > > Yes, but it requires a config ops since the IRQ knowledge is transport specific. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + */ > > > > > > > > > > > + WRITE_ONCE(dev->irq_soft_enabled, false); > > > > > > > > > > > + synchronize_rcu(); > > > > > > > > > > > + > > > > > > > > > > > dev->config->reset(dev); > > > > > > > > > > > } > > > > > > > > > > > EXPORT_SYMBOL_GPL(virtio_reset_device); > > > > > > > > > > Please add comment explaining where it will be enabled. > > > > > > > > > > Also, we *really* don't need to synch if it was already disabled, > > > > > > > > > > let's not add useless overhead to the boot sequence. > > > > > > > > > > > > > > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > @@ -427,6 +442,10 @@ int register_virtio_device(struct virtio_device *dev) > > > > > > > > > > > spin_lock_init(&dev->config_lock); > > > > > > > > > > > dev->config_enabled = false; > > > > > > > > > > > dev->config_change_pending = false; > > > > > > > > > > > + dev->irq_soft_check = irq_hardening; > > > > > > > > > > > + > > > > > > > > > > > + if (dev->irq_soft_check) > > > > > > > > > > > + dev_info(&dev->dev, "IRQ hardening is enabled\n"); > > > > > > > > > > > /* We always start by resetting the device, in case a previous > > > > > > > > > > > * driver messed it up. This also tests that code path a little. */ > > > > > > > > > > one of the points of hardening is it's also helpful for buggy > > > > > > > > > > devices. this flag defeats the purpose. > > > > > > > > > > > > > > > > > > > > > > > > > > > Do you mean: > > > > > > > > > > > > > > > > > > 1) we need something like config_enable? This seems not easy to be > > > > > > > > > implemented without obvious overhead, mainly the synchronize with the > > > > > > > > > interrupt handlers > > > > > > > > > > > > > > > > But synchronize is only on tear-down path. That is not critical for any > > > > > > > > users at the moment, even less than probe. > > > > > > > > > > > > > > I meant if we have vq->irq_pending, we need to call vring_interrupt() > > > > > > > in the virtio_device_ready() and synchronize the IRQ handlers with > > > > > > > spinlock or others. > > > > > > > > > > > > > > > > > > > > > > > > 2) enable this by default, so I don't object, but this may have some risk > > > > > > > > > for old hypervisors > > > > > > > > > > > > > > > > > > > > > > > > The risk if there's a driver adding buffers without setting DRIVER_OK. > > > > > > > > > > > > > > Probably not, we have devices that accept random inputs from outside, > > > > > > > net, console, input etc. I've done a round of audits of the Qemu > > > > > > > codes. They look all fine since day0. > > > > > > > > > > > > > > > So with this approach, how about we rename the flag "driver_ok"? > > > > > > > > And then add_buf can actually test it and BUG_ON if not there (at least > > > > > > > > in the debug build). > > > > > > > > > > > > > > This looks like a hardening of the driver in the core instead of the > > > > > > > device. I think it can be done but in a separate series. > > > > > > > > > > > > > > > > > > > > > > > And going down from there, how about we cache status in the > > > > > > > > device? Then we don't need to keep re-reading it every time, > > > > > > > > speeding boot up a tiny bit. > > > > > > > > > > > > > > I don't fully understand here, actually spec requires status to be > > > > > > > read back for validation in many cases. > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > > > > > > > > > > index 962f1477b1fa..0170f8c784d8 100644 > > > > > > > > > > > --- a/drivers/virtio/virtio_ring.c > > > > > > > > > > > +++ b/drivers/virtio/virtio_ring.c > > > > > > > > > > > @@ -2144,10 +2144,17 @@ static inline bool more_used(const struct vring_virtqueue *vq) > > > > > > > > > > > return vq->packed_ring ? more_used_packed(vq) : more_used_split(vq); > > > > > > > > > > > } > > > > > > > > > > > -irqreturn_t vring_interrupt(int irq, void *_vq) > > > > > > > > > > > +irqreturn_t vring_interrupt(int irq, void *v) > > > > > > > > > > > { > > > > > > > > > > > + struct virtqueue *_vq = v; > > > > > > > > > > > + struct virtio_device *vdev = _vq->vdev; > > > > > > > > > > > struct vring_virtqueue *vq = to_vvq(_vq); > > > > > > > > > > > + if (!virtio_irq_soft_enabled(vdev)) { > > > > > > > > > > > + dev_warn_once(&vdev->dev, "virtio vring IRQ raised before DRIVER_OK"); > > > > > > > > > > > + return IRQ_NONE; > > > > > > > > > > > + } > > > > > > > > > > > + > > > > > > > > > > > if (!more_used(vq)) { > > > > > > > > > > > pr_debug("virtqueue interrupt with no work for %p\n", vq); > > > > > > > > > > > return IRQ_NONE; > > > > > > > > > > > diff --git a/include/linux/virtio.h b/include/linux/virtio.h > > > > > > > > > > > index 5464f398912a..957d6ad604ac 100644 > > > > > > > > > > > --- a/include/linux/virtio.h > > > > > > > > > > > +++ b/include/linux/virtio.h > > > > > > > > > > > @@ -95,6 +95,8 @@ dma_addr_t virtqueue_get_used_addr(struct virtqueue *vq); > > > > > > > > > > > * @failed: saved value for VIRTIO_CONFIG_S_FAILED bit (for restore) > > > > > > > > > > > * @config_enabled: configuration change reporting enabled > > > > > > > > > > > * @config_change_pending: configuration change reported while disabled > > > > > > > > > > > + * @irq_soft_check: whether or not to check @irq_soft_enabled > > > > > > > > > > > + * @irq_soft_enabled: callbacks enabled > > > > > > > > > > > * @config_lock: protects configuration change reporting > > > > > > > > > > > * @dev: underlying device. > > > > > > > > > > > * @id: the device type identification (used to match it with a driver). > > > > > > > > > > > @@ -109,6 +111,8 @@ struct virtio_device { > > > > > > > > > > > bool failed; > > > > > > > > > > > bool config_enabled; > > > > > > > > > > > bool config_change_pending; > > > > > > > > > > > + bool irq_soft_check; > > > > > > > > > > > + bool irq_soft_enabled; > > > > > > > > > > > spinlock_t config_lock; > > > > > > > > > > > spinlock_t vqs_list_lock; /* Protects VQs list access */ > > > > > > > > > > > struct device dev; > > > > > > > > > > > diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h > > > > > > > > > > > index dafdc7f48c01..9c1b61f2e525 100644 > > > > > > > > > > > --- a/include/linux/virtio_config.h > > > > > > > > > > > +++ b/include/linux/virtio_config.h > > > > > > > > > > > @@ -174,6 +174,24 @@ static inline bool virtio_has_feature(const struct virtio_device *vdev, > > > > > > > > > > > return __virtio_test_bit(vdev, fbit); > > > > > > > > > > > } > > > > > > > > > > > +/* > > > > > > > > > > > + * virtio_irq_soft_enabled: whether we can execute callbacks > > > > > > > > > > > + * @vdev: the device > > > > > > > > > > > + */ > > > > > > > > > > > +static inline bool virtio_irq_soft_enabled(const struct virtio_device *vdev) > > > > > > > > > > > +{ > > > > > > > > > > > + if (!vdev->irq_soft_check) > > > > > > > > > > > + return true; > > > > > > > > > > > + > > > > > > > > > > > + /* > > > > > > > > > > > + * Read irq_soft_enabled before reading other device specific > > > > > > > > > > > + * data. Paried with smp_store_relase() in > > > > > > > > > > paired > > > > > > > > > > > > > > > > > > > > > > > > > > > Will fix. > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + * virtio_device_ready() and WRITE_ONCE()/synchronize_rcu() in > > > > > > > > > > > + * virtio_reset_device(). > > > > > > > > > > > + */ > > > > > > > > > > > + return smp_load_acquire(&vdev->irq_soft_enabled); > > > > > > > > > > > +} > > > > > > > > > > > + > > > > > > > > > > > /** > > > > > > > > > > > * virtio_has_dma_quirk - determine whether this device has the DMA quirk > > > > > > > > > > > * @vdev: the device > > > > > > > > > > > @@ -236,6 +254,13 @@ void virtio_device_ready(struct virtio_device *dev) > > > > > > > > > > > if (dev->config->enable_cbs) > > > > > > > > > > > dev->config->enable_cbs(dev); > > > > > > > > > > > + /* > > > > > > > > > > > + * Commit the driver setup before enabling the virtqueue > > > > > > > > > > > + * callbacks. Paried with smp_load_acuqire() in > > > > > > > > > > > + * virtio_irq_soft_enabled() > > > > > > > > > > > + */ > > > > > > > > > > > + smp_store_release(&dev->irq_soft_enabled, true); > > > > > > > > > > > + > > > > > > > > > > > BUG_ON(status & VIRTIO_CONFIG_S_DRIVER_OK); > > > > > > > > > > > dev->config->set_status(dev, status | VIRTIO_CONFIG_S_DRIVER_OK); > > > > > > > > > > > } > > > > > > > > > > > -- > > > > > > > > > > > 2.25.1 > > > > > > > > > > > > > > > > > > > > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-03-28 10:40 ` Re: Michael S. Tsirkin @ 2022-03-29 7:12 ` Jason Wang 2022-03-29 14:08 ` Re: Michael S. Tsirkin 2022-03-29 8:35 ` Re: Thomas Gleixner 1 sibling, 1 reply; 1767+ messages in thread From: Jason Wang @ 2022-03-29 7:12 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Paul E. McKenney, Peter Zijlstra, Marc Zyngier, Keir Fraser, linux-kernel, virtualization, Thomas Gleixner On Mon, Mar 28, 2022 at 6:41 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > On Mon, Mar 28, 2022 at 02:18:22PM +0800, Jason Wang wrote: > > On Mon, Mar 28, 2022 at 1:59 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > On Mon, Mar 28, 2022 at 12:56:41PM +0800, Jason Wang wrote: > > > > On Fri, Mar 25, 2022 at 6:10 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > > > > > On Fri, Mar 25, 2022 at 05:20:19PM +0800, Jason Wang wrote: > > > > > > On Fri, Mar 25, 2022 at 5:10 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > > > > > > > > > On Fri, Mar 25, 2022 at 03:52:00PM +0800, Jason Wang wrote: > > > > > > > > On Fri, Mar 25, 2022 at 2:31 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > > > > > > > > > > > > > Bcc: > > > > > > > > > Subject: Re: [PATCH 3/3] virtio: harden vring IRQ > > > > > > > > > Message-ID: <20220325021422-mutt-send-email-mst@kernel.org> > > > > > > > > > Reply-To: > > > > > > > > > In-Reply-To: <f7046303-7d7d-e39f-3c71-3688126cc812@redhat.com> > > > > > > > > > > > > > > > > > > On Fri, Mar 25, 2022 at 11:04:08AM +0800, Jason Wang wrote: > > > > > > > > > > > > > > > > > > > > 在 2022/3/24 下午7:03, Michael S. Tsirkin 写道: > > > > > > > > > > > On Thu, Mar 24, 2022 at 04:40:04PM +0800, Jason Wang wrote: > > > > > > > > > > > > This is a rework on the previous IRQ hardening that is done for > > > > > > > > > > > > virtio-pci where several drawbacks were found and were reverted: > > > > > > > > > > > > > > > > > > > > > > > > 1) try to use IRQF_NO_AUTOEN which is not friendly to affinity managed IRQ > > > > > > > > > > > > that is used by some device such as virtio-blk > > > > > > > > > > > > 2) done only for PCI transport > > > > > > > > > > > > > > > > > > > > > > > > In this patch, we tries to borrow the idea from the INTX IRQ hardening > > > > > > > > > > > > in the reverted commit 080cd7c3ac87 ("virtio-pci: harden INTX interrupts") > > > > > > > > > > > > by introducing a global irq_soft_enabled variable for each > > > > > > > > > > > > virtio_device. Then we can to toggle it during > > > > > > > > > > > > virtio_reset_device()/virtio_device_ready(). A synchornize_rcu() is > > > > > > > > > > > > used in virtio_reset_device() to synchronize with the IRQ handlers. In > > > > > > > > > > > > the future, we may provide config_ops for the transport that doesn't > > > > > > > > > > > > use IRQ. With this, vring_interrupt() can return check and early if > > > > > > > > > > > > irq_soft_enabled is false. This lead to smp_load_acquire() to be used > > > > > > > > > > > > but the cost should be acceptable. > > > > > > > > > > > Maybe it should be but is it? Can't we use synchronize_irq instead? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Even if we allow the transport driver to synchornize through > > > > > > > > > > synchronize_irq() we still need a check in the vring_interrupt(). > > > > > > > > > > > > > > > > > > > > We do something like the following previously: > > > > > > > > > > > > > > > > > > > > if (!READ_ONCE(vp_dev->intx_soft_enabled)) > > > > > > > > > > return IRQ_NONE; > > > > > > > > > > > > > > > > > > > > But it looks like a bug since speculative read can be done before the check > > > > > > > > > > where the interrupt handler can't see the uncommitted setup which is done by > > > > > > > > > > the driver. > > > > > > > > > > > > > > > > > > I don't think so - if you sync after setting the value then > > > > > > > > > you are guaranteed that any handler running afterwards > > > > > > > > > will see the new value. > > > > > > > > > > > > > > > > The problem is not disabled but the enable. > > > > > > > > > > > > > > So a misbehaving device can lose interrupts? That's not a problem at all > > > > > > > imo. > > > > > > > > > > > > It's the interrupt raised before setting irq_soft_enabled to true: > > > > > > > > > > > > CPU 0 probe) driver specific setup (not commited) > > > > > > CPU 1 IRQ handler) read the uninitialized variable > > > > > > CPU 0 probe) set irq_soft_enabled to true > > > > > > CPU 1 IRQ handler) read irq_soft_enable as true > > > > > > CPU 1 IRQ handler) use the uninitialized variable > > > > > > > > > > > > Thanks > > > > > > > > > > Yea, it hurts if you do it. So do not do it then ;). > > > > > > > > > > irq_soft_enabled (I think driver_ok or status is a better name) > > > > > > > > I can change it to driver_ok. > > > > > > > > > should be initialized to false *before* irq is requested. > > > > > > > > > > And requesting irq commits all memory otherwise all drivers would be > > > > > broken, > > > > > > > > So I think we might talk different issues: > > > > > > > > 1) Whether request_irq() commits the previous setups, I think the > > > > answer is yes, since the spin_unlock of desc->lock (release) can > > > > guarantee this though there seems no documentation around > > > > request_irq() to say this. > > > > > > > > And I can see at least drivers/video/fbdev/omap2/omapfb/dss/dispc.c is > > > > using smp_wmb() before the request_irq(). > > > > > > > > And even if write is ordered we still need read to be ordered to be > > > > paired with that. > > IMO it synchronizes with the CPU to which irq is > delivered. Otherwise basically all drivers would be broken, > wouldn't they be? I guess it's because most of the drivers don't care much about the buggy/malicious device. And most of the devices may require an extra step to enable device IRQ after request_irq(). Or it's the charge of the driver to do the synchronization. > I don't know whether it's correct on all platforms, but if not > we need to fix request_irq. > > > > > > > > > > if it doesn't it just needs to be fixed, not worked around in > > > > > virtio. > > > > > > > > 2) virtio drivers might do a lot of setups between request_irq() and > > > > virtio_device_ready(): > > > > > > > > request_irq() > > > > driver specific setups > > > > virtio_device_ready() > > > > > > > > CPU 0 probe) request_irq() > > > > CPU 1 IRQ handler) read the uninitialized variable > > > > CPU 0 probe) driver specific setups > > > > CPU 0 probe) smp_store_release(intr_soft_enabled, true), commit the setups > > > > CPU 1 IRQ handler) read irq_soft_enable as true > > > > CPU 1 IRQ handler) use the uninitialized variable > > > > > > > > Thanks > > > > > > > > > As I said, virtio_device_ready needs to do synchronize_irq. > > > That will guarantee all setup is visible to the specific IRQ, > > > > Only the interrupt after synchronize_irq() returns. > > Anything else is a buggy device though. Yes, but the goal of this patch is to prevent the possible attack from buggy(malicious) devices. > > > >this > > > is what it's point is. > > > > What happens if an interrupt is raised in the middle like: > > > > smp_store_release(dev->irq_soft_enabled, true) > > IRQ handler > > synchornize_irq() > > > > If we don't enforce a reading order, the IRQ handler may still see the > > uninitialized variable. > > > > Thanks > > IMHO variables should be initialized before request_irq > to a value meaning "not a valid interrupt". > Specifically driver_ok = false. > Handler in the scenario you describe will then see !driver_ok > and exit immediately. So just to make sure we're on the same page. 1) virtio_reset_device() will set the driver_ok to false; 2) virtio_device_ready() will set the driver_ok to true So for virtio drivers, it often did: 1) virtio_reset_device() 2) find_vqs() which will call request_irq() 3) other driver specific setups 4) virtio_device_ready() In virtio_device_ready(), the patch perform the following currently: smp_store_release(driver_ok, true); set_status(DRIVER_OK); Per your suggestion, to add synchronize_irq() after smp_store_release() so we had smp_store_release(driver_ok, true); synchornize_irq() set_status(DRIVER_OK) Suppose there's a interrupt raised before the synchronize_irq(), if we do: if (READ_ONCE(driver_ok)) { vq->callback() } It will see the driver_ok as true but how can we make sure vq->callback sees the driver specific setups (3) above? And an example is virtio_scsi(): virtio_reset_device() virtscsi_probe() virtscsi_init() virtio_find_vqs() ... virtscsi_init_vq(&vscsi->event_vq, vqs[1]) .... virtio_device_ready() In virtscsi_event_done(): virtscsi_event_done(): virtscsi_vq_done(vscsi, &vscsi->event_vq, ...); We need to make sure the even_done reads driver_ok before read vscsi->event_vq. Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We use smp_store_relase() > > > > > > > > to make sure the driver commits the setup before enabling the irq. It > > > > > > > > means the read needs to be ordered as well in vring_interrupt(). > > > > > > > > > > > > > > > > > > > > > > > > > > Although I couldn't find anything about this in memory-barriers.txt > > > > > > > > > which surprises me. > > > > > > > > > > > > > > > > > > CC Paul to help make sure I'm right. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To avoid breaking legacy device which can send IRQ before DRIVER_OK, a > > > > > > > > > > > > module parameter is introduced to enable the hardening so function > > > > > > > > > > > > hardening is disabled by default. > > > > > > > > > > > Which devices are these? How come they send an interrupt before there > > > > > > > > > > > are any buffers in any queues? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I copied this from the commit log for 22b7050a024d7 > > > > > > > > > > > > > > > > > > > > " > > > > > > > > > > > > > > > > > > > > This change will also benefit old hypervisors (before 2009) > > > > > > > > > > that send interrupts without checking DRIVER_OK: previously, > > > > > > > > > > the callback could race with driver-specific initialization. > > > > > > > > > > " > > > > > > > > > > > > > > > > > > > > If this is only for config interrupt, I can remove the above log. > > > > > > > > > > > > > > > > > > > > > > > > > > > This is only for config interrupt. > > > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Note that the hardening is only done for vring interrupt since the > > > > > > > > > > > > config interrupt hardening is already done in commit 22b7050a024d7 > > > > > > > > > > > > ("virtio: defer config changed notifications"). But the method that is > > > > > > > > > > > > used by config interrupt can't be reused by the vring interrupt > > > > > > > > > > > > handler because it uses spinlock to do the synchronization which is > > > > > > > > > > > > expensive. > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Jason Wang <jasowang@redhat.com> > > > > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > drivers/virtio/virtio.c | 19 +++++++++++++++++++ > > > > > > > > > > > > drivers/virtio/virtio_ring.c | 9 ++++++++- > > > > > > > > > > > > include/linux/virtio.h | 4 ++++ > > > > > > > > > > > > include/linux/virtio_config.h | 25 +++++++++++++++++++++++++ > > > > > > > > > > > > 4 files changed, 56 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c > > > > > > > > > > > > index 8dde44ea044a..85e331efa9cc 100644 > > > > > > > > > > > > --- a/drivers/virtio/virtio.c > > > > > > > > > > > > +++ b/drivers/virtio/virtio.c > > > > > > > > > > > > @@ -7,6 +7,12 @@ > > > > > > > > > > > > #include <linux/of.h> > > > > > > > > > > > > #include <uapi/linux/virtio_ids.h> > > > > > > > > > > > > +static bool irq_hardening = false; > > > > > > > > > > > > + > > > > > > > > > > > > +module_param(irq_hardening, bool, 0444); > > > > > > > > > > > > +MODULE_PARM_DESC(irq_hardening, > > > > > > > > > > > > + "Disalbe IRQ software processing when it is not expected"); > > > > > > > > > > > > + > > > > > > > > > > > > /* Unique numbering for virtio devices. */ > > > > > > > > > > > > static DEFINE_IDA(virtio_index_ida); > > > > > > > > > > > > @@ -220,6 +226,15 @@ static int virtio_features_ok(struct virtio_device *dev) > > > > > > > > > > > > * */ > > > > > > > > > > > > void virtio_reset_device(struct virtio_device *dev) > > > > > > > > > > > > { > > > > > > > > > > > > + /* > > > > > > > > > > > > + * The below synchronize_rcu() guarantees that any > > > > > > > > > > > > + * interrupt for this line arriving after > > > > > > > > > > > > + * synchronize_rcu() has completed is guaranteed to see > > > > > > > > > > > > + * irq_soft_enabled == false. > > > > > > > > > > > News to me I did not know synchronize_rcu has anything to do > > > > > > > > > > > with interrupts. Did not you intend to use synchronize_irq? > > > > > > > > > > > I am not even 100% sure synchronize_rcu is by design a memory barrier > > > > > > > > > > > though it's most likely is ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > According to the comment above tree RCU version of synchronize_rcu(): > > > > > > > > > > > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > > > * RCU read-side critical sections are delimited by rcu_read_lock() > > > > > > > > > > * and rcu_read_unlock(), and may be nested. In addition, but only in > > > > > > > > > > * v5.0 and later, regions of code across which interrupts, preemption, > > > > > > > > > > * or softirqs have been disabled also serve as RCU read-side critical > > > > > > > > > > * sections. This includes hardware interrupt handlers, softirq handlers, > > > > > > > > > > * and NMI handlers. > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > > > So interrupt handlers are treated as read-side critical sections. > > > > > > > > > > > > > > > > > > > > And it has the comment for explain the barrier: > > > > > > > > > > > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > > > * Note that this guarantee implies further memory-ordering guarantees. > > > > > > > > > > * On systems with more than one CPU, when synchronize_rcu() returns, > > > > > > > > > > * each CPU is guaranteed to have executed a full memory barrier since > > > > > > > > > > * the end of its last RCU read-side critical section whose beginning > > > > > > > > > > * preceded the call to synchronize_rcu(). In addition, each CPU having > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > > > So on SMP it provides a full barrier. And for UP/tiny RCU we don't need the > > > > > > > > > > barrier, if the interrupt come after WRITE_ONCE() it will see the > > > > > > > > > > irq_soft_enabled as false. > > > > > > > > > > > > > > > > > > > > > > > > > > > > You are right. So then > > > > > > > > > 1. I do not think we need load_acquire - why is it needed? Just > > > > > > > > > READ_ONCE should do. > > > > > > > > > > > > > > > > See above. > > > > > > > > > > > > > > > > > 2. isn't synchronize_irq also doing the same thing? > > > > > > > > > > > > > > > > > > > > > > > > Yes, but it requires a config ops since the IRQ knowledge is transport specific. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + */ > > > > > > > > > > > > + WRITE_ONCE(dev->irq_soft_enabled, false); > > > > > > > > > > > > + synchronize_rcu(); > > > > > > > > > > > > + > > > > > > > > > > > > dev->config->reset(dev); > > > > > > > > > > > > } > > > > > > > > > > > > EXPORT_SYMBOL_GPL(virtio_reset_device); > > > > > > > > > > > Please add comment explaining where it will be enabled. > > > > > > > > > > > Also, we *really* don't need to synch if it was already disabled, > > > > > > > > > > > let's not add useless overhead to the boot sequence. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > @@ -427,6 +442,10 @@ int register_virtio_device(struct virtio_device *dev) > > > > > > > > > > > > spin_lock_init(&dev->config_lock); > > > > > > > > > > > > dev->config_enabled = false; > > > > > > > > > > > > dev->config_change_pending = false; > > > > > > > > > > > > + dev->irq_soft_check = irq_hardening; > > > > > > > > > > > > + > > > > > > > > > > > > + if (dev->irq_soft_check) > > > > > > > > > > > > + dev_info(&dev->dev, "IRQ hardening is enabled\n"); > > > > > > > > > > > > /* We always start by resetting the device, in case a previous > > > > > > > > > > > > * driver messed it up. This also tests that code path a little. */ > > > > > > > > > > > one of the points of hardening is it's also helpful for buggy > > > > > > > > > > > devices. this flag defeats the purpose. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do you mean: > > > > > > > > > > > > > > > > > > > > 1) we need something like config_enable? This seems not easy to be > > > > > > > > > > implemented without obvious overhead, mainly the synchronize with the > > > > > > > > > > interrupt handlers > > > > > > > > > > > > > > > > > > But synchronize is only on tear-down path. That is not critical for any > > > > > > > > > users at the moment, even less than probe. > > > > > > > > > > > > > > > > I meant if we have vq->irq_pending, we need to call vring_interrupt() > > > > > > > > in the virtio_device_ready() and synchronize the IRQ handlers with > > > > > > > > spinlock or others. > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) enable this by default, so I don't object, but this may have some risk > > > > > > > > > > for old hypervisors > > > > > > > > > > > > > > > > > > > > > > > > > > > The risk if there's a driver adding buffers without setting DRIVER_OK. > > > > > > > > > > > > > > > > Probably not, we have devices that accept random inputs from outside, > > > > > > > > net, console, input etc. I've done a round of audits of the Qemu > > > > > > > > codes. They look all fine since day0. > > > > > > > > > > > > > > > > > So with this approach, how about we rename the flag "driver_ok"? > > > > > > > > > And then add_buf can actually test it and BUG_ON if not there (at least > > > > > > > > > in the debug build). > > > > > > > > > > > > > > > > This looks like a hardening of the driver in the core instead of the > > > > > > > > device. I think it can be done but in a separate series. > > > > > > > > > > > > > > > > > > > > > > > > > > And going down from there, how about we cache status in the > > > > > > > > > device? Then we don't need to keep re-reading it every time, > > > > > > > > > speeding boot up a tiny bit. > > > > > > > > > > > > > > > > I don't fully understand here, actually spec requires status to be > > > > > > > > read back for validation in many cases. > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > > > > > > > > > > > index 962f1477b1fa..0170f8c784d8 100644 > > > > > > > > > > > > --- a/drivers/virtio/virtio_ring.c > > > > > > > > > > > > +++ b/drivers/virtio/virtio_ring.c > > > > > > > > > > > > @@ -2144,10 +2144,17 @@ static inline bool more_used(const struct vring_virtqueue *vq) > > > > > > > > > > > > return vq->packed_ring ? more_used_packed(vq) : more_used_split(vq); > > > > > > > > > > > > } > > > > > > > > > > > > -irqreturn_t vring_interrupt(int irq, void *_vq) > > > > > > > > > > > > +irqreturn_t vring_interrupt(int irq, void *v) > > > > > > > > > > > > { > > > > > > > > > > > > + struct virtqueue *_vq = v; > > > > > > > > > > > > + struct virtio_device *vdev = _vq->vdev; > > > > > > > > > > > > struct vring_virtqueue *vq = to_vvq(_vq); > > > > > > > > > > > > + if (!virtio_irq_soft_enabled(vdev)) { > > > > > > > > > > > > + dev_warn_once(&vdev->dev, "virtio vring IRQ raised before DRIVER_OK"); > > > > > > > > > > > > + return IRQ_NONE; > > > > > > > > > > > > + } > > > > > > > > > > > > + > > > > > > > > > > > > if (!more_used(vq)) { > > > > > > > > > > > > pr_debug("virtqueue interrupt with no work for %p\n", vq); > > > > > > > > > > > > return IRQ_NONE; > > > > > > > > > > > > diff --git a/include/linux/virtio.h b/include/linux/virtio.h > > > > > > > > > > > > index 5464f398912a..957d6ad604ac 100644 > > > > > > > > > > > > --- a/include/linux/virtio.h > > > > > > > > > > > > +++ b/include/linux/virtio.h > > > > > > > > > > > > @@ -95,6 +95,8 @@ dma_addr_t virtqueue_get_used_addr(struct virtqueue *vq); > > > > > > > > > > > > * @failed: saved value for VIRTIO_CONFIG_S_FAILED bit (for restore) > > > > > > > > > > > > * @config_enabled: configuration change reporting enabled > > > > > > > > > > > > * @config_change_pending: configuration change reported while disabled > > > > > > > > > > > > + * @irq_soft_check: whether or not to check @irq_soft_enabled > > > > > > > > > > > > + * @irq_soft_enabled: callbacks enabled > > > > > > > > > > > > * @config_lock: protects configuration change reporting > > > > > > > > > > > > * @dev: underlying device. > > > > > > > > > > > > * @id: the device type identification (used to match it with a driver). > > > > > > > > > > > > @@ -109,6 +111,8 @@ struct virtio_device { > > > > > > > > > > > > bool failed; > > > > > > > > > > > > bool config_enabled; > > > > > > > > > > > > bool config_change_pending; > > > > > > > > > > > > + bool irq_soft_check; > > > > > > > > > > > > + bool irq_soft_enabled; > > > > > > > > > > > > spinlock_t config_lock; > > > > > > > > > > > > spinlock_t vqs_list_lock; /* Protects VQs list access */ > > > > > > > > > > > > struct device dev; > > > > > > > > > > > > diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h > > > > > > > > > > > > index dafdc7f48c01..9c1b61f2e525 100644 > > > > > > > > > > > > --- a/include/linux/virtio_config.h > > > > > > > > > > > > +++ b/include/linux/virtio_config.h > > > > > > > > > > > > @@ -174,6 +174,24 @@ static inline bool virtio_has_feature(const struct virtio_device *vdev, > > > > > > > > > > > > return __virtio_test_bit(vdev, fbit); > > > > > > > > > > > > } > > > > > > > > > > > > +/* > > > > > > > > > > > > + * virtio_irq_soft_enabled: whether we can execute callbacks > > > > > > > > > > > > + * @vdev: the device > > > > > > > > > > > > + */ > > > > > > > > > > > > +static inline bool virtio_irq_soft_enabled(const struct virtio_device *vdev) > > > > > > > > > > > > +{ > > > > > > > > > > > > + if (!vdev->irq_soft_check) > > > > > > > > > > > > + return true; > > > > > > > > > > > > + > > > > > > > > > > > > + /* > > > > > > > > > > > > + * Read irq_soft_enabled before reading other device specific > > > > > > > > > > > > + * data. Paried with smp_store_relase() in > > > > > > > > > > > paired > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Will fix. > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + * virtio_device_ready() and WRITE_ONCE()/synchronize_rcu() in > > > > > > > > > > > > + * virtio_reset_device(). > > > > > > > > > > > > + */ > > > > > > > > > > > > + return smp_load_acquire(&vdev->irq_soft_enabled); > > > > > > > > > > > > +} > > > > > > > > > > > > + > > > > > > > > > > > > /** > > > > > > > > > > > > * virtio_has_dma_quirk - determine whether this device has the DMA quirk > > > > > > > > > > > > * @vdev: the device > > > > > > > > > > > > @@ -236,6 +254,13 @@ void virtio_device_ready(struct virtio_device *dev) > > > > > > > > > > > > if (dev->config->enable_cbs) > > > > > > > > > > > > dev->config->enable_cbs(dev); > > > > > > > > > > > > + /* > > > > > > > > > > > > + * Commit the driver setup before enabling the virtqueue > > > > > > > > > > > > + * callbacks. Paried with smp_load_acuqire() in > > > > > > > > > > > > + * virtio_irq_soft_enabled() > > > > > > > > > > > > + */ > > > > > > > > > > > > + smp_store_release(&dev->irq_soft_enabled, true); > > > > > > > > > > > > + > > > > > > > > > > > > BUG_ON(status & VIRTIO_CONFIG_S_DRIVER_OK); > > > > > > > > > > > > dev->config->set_status(dev, status | VIRTIO_CONFIG_S_DRIVER_OK); > > > > > > > > > > > > } > > > > > > > > > > > > -- > > > > > > > > > > > > 2.25.1 > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-03-29 7:12 ` Re: Jason Wang @ 2022-03-29 14:08 ` Michael S. Tsirkin 2022-03-30 2:40 ` Re: Jason Wang 0 siblings, 1 reply; 1767+ messages in thread From: Michael S. Tsirkin @ 2022-03-29 14:08 UTC (permalink / raw) To: Jason Wang Cc: Paul E. McKenney, Peter Zijlstra, Marc Zyngier, Keir Fraser, linux-kernel, virtualization, Thomas Gleixner On Tue, Mar 29, 2022 at 03:12:14PM +0800, Jason Wang wrote: > > > > > > And requesting irq commits all memory otherwise all drivers would be > > > > > > broken, > > > > > > > > > > So I think we might talk different issues: > > > > > > > > > > 1) Whether request_irq() commits the previous setups, I think the > > > > > answer is yes, since the spin_unlock of desc->lock (release) can > > > > > guarantee this though there seems no documentation around > > > > > request_irq() to say this. > > > > > > > > > > And I can see at least drivers/video/fbdev/omap2/omapfb/dss/dispc.c is > > > > > using smp_wmb() before the request_irq(). > > > > > > > > > > And even if write is ordered we still need read to be ordered to be > > > > > paired with that. > > > > IMO it synchronizes with the CPU to which irq is > > delivered. Otherwise basically all drivers would be broken, > > wouldn't they be? > > I guess it's because most of the drivers don't care much about the > buggy/malicious device. And most of the devices may require an extra > step to enable device IRQ after request_irq(). Or it's the charge of > the driver to do the synchronization. It is true that the use-case of malicious devices is somewhat boutique. But I think most drivers do want to have their hotplug routines to be robust, yes. > > I don't know whether it's correct on all platforms, but if not > > we need to fix request_irq. > > > > > > > > > > > > > if it doesn't it just needs to be fixed, not worked around in > > > > > > virtio. > > > > > > > > > > 2) virtio drivers might do a lot of setups between request_irq() and > > > > > virtio_device_ready(): > > > > > > > > > > request_irq() > > > > > driver specific setups > > > > > virtio_device_ready() > > > > > > > > > > CPU 0 probe) request_irq() > > > > > CPU 1 IRQ handler) read the uninitialized variable > > > > > CPU 0 probe) driver specific setups > > > > > CPU 0 probe) smp_store_release(intr_soft_enabled, true), commit the setups > > > > > CPU 1 IRQ handler) read irq_soft_enable as true > > > > > CPU 1 IRQ handler) use the uninitialized variable > > > > > > > > > > Thanks > > > > > > > > > > > > As I said, virtio_device_ready needs to do synchronize_irq. > > > > That will guarantee all setup is visible to the specific IRQ, > > > > > > Only the interrupt after synchronize_irq() returns. > > > > Anything else is a buggy device though. > > Yes, but the goal of this patch is to prevent the possible attack from > buggy(malicious) devices. Right. However if a driver of a *buggy* device somehow sees driver_ok = false even though it's actually initialized, that is not a deal breaker as that does not open us up to an attack. > > > > > >this > > > > is what it's point is. > > > > > > What happens if an interrupt is raised in the middle like: > > > > > > smp_store_release(dev->irq_soft_enabled, true) > > > IRQ handler > > > synchornize_irq() > > > > > > If we don't enforce a reading order, the IRQ handler may still see the > > > uninitialized variable. > > > > > > Thanks > > > > IMHO variables should be initialized before request_irq > > to a value meaning "not a valid interrupt". > > Specifically driver_ok = false. > > Handler in the scenario you describe will then see !driver_ok > > and exit immediately. > > So just to make sure we're on the same page. > > 1) virtio_reset_device() will set the driver_ok to false; > 2) virtio_device_ready() will set the driver_ok to true > > So for virtio drivers, it often did: > > 1) virtio_reset_device() > 2) find_vqs() which will call request_irq() > 3) other driver specific setups > 4) virtio_device_ready() > > In virtio_device_ready(), the patch perform the following currently: > > smp_store_release(driver_ok, true); > set_status(DRIVER_OK); > > Per your suggestion, to add synchronize_irq() after > smp_store_release() so we had > > smp_store_release(driver_ok, true); > synchornize_irq() > set_status(DRIVER_OK) > > Suppose there's a interrupt raised before the synchronize_irq(), if we do: > > if (READ_ONCE(driver_ok)) { > vq->callback() > } > > It will see the driver_ok as true but how can we make sure > vq->callback sees the driver specific setups (3) above? > > And an example is virtio_scsi(): > > virtio_reset_device() > virtscsi_probe() > virtscsi_init() > virtio_find_vqs() > ... > virtscsi_init_vq(&vscsi->event_vq, vqs[1]) > .... > virtio_device_ready() > > In virtscsi_event_done(): > > virtscsi_event_done(): > virtscsi_vq_done(vscsi, &vscsi->event_vq, ...); > > We need to make sure the even_done reads driver_ok before read vscsi->event_vq. > > Thanks See response by Thomas. A simple if (!dev->driver_ok) should be enough, it's all under a lock. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We use smp_store_relase() > > > > > > > > > to make sure the driver commits the setup before enabling the irq. It > > > > > > > > > means the read needs to be ordered as well in vring_interrupt(). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Although I couldn't find anything about this in memory-barriers.txt > > > > > > > > > > which surprises me. > > > > > > > > > > > > > > > > > > > > CC Paul to help make sure I'm right. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To avoid breaking legacy device which can send IRQ before DRIVER_OK, a > > > > > > > > > > > > > module parameter is introduced to enable the hardening so function > > > > > > > > > > > > > hardening is disabled by default. > > > > > > > > > > > > Which devices are these? How come they send an interrupt before there > > > > > > > > > > > > are any buffers in any queues? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I copied this from the commit log for 22b7050a024d7 > > > > > > > > > > > > > > > > > > > > > > " > > > > > > > > > > > > > > > > > > > > > > This change will also benefit old hypervisors (before 2009) > > > > > > > > > > > that send interrupts without checking DRIVER_OK: previously, > > > > > > > > > > > the callback could race with driver-specific initialization. > > > > > > > > > > > " > > > > > > > > > > > > > > > > > > > > > > If this is only for config interrupt, I can remove the above log. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is only for config interrupt. > > > > > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Note that the hardening is only done for vring interrupt since the > > > > > > > > > > > > > config interrupt hardening is already done in commit 22b7050a024d7 > > > > > > > > > > > > > ("virtio: defer config changed notifications"). But the method that is > > > > > > > > > > > > > used by config interrupt can't be reused by the vring interrupt > > > > > > > > > > > > > handler because it uses spinlock to do the synchronization which is > > > > > > > > > > > > > expensive. > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Jason Wang <jasowang@redhat.com> > > > > > > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > drivers/virtio/virtio.c | 19 +++++++++++++++++++ > > > > > > > > > > > > > drivers/virtio/virtio_ring.c | 9 ++++++++- > > > > > > > > > > > > > include/linux/virtio.h | 4 ++++ > > > > > > > > > > > > > include/linux/virtio_config.h | 25 +++++++++++++++++++++++++ > > > > > > > > > > > > > 4 files changed, 56 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c > > > > > > > > > > > > > index 8dde44ea044a..85e331efa9cc 100644 > > > > > > > > > > > > > --- a/drivers/virtio/virtio.c > > > > > > > > > > > > > +++ b/drivers/virtio/virtio.c > > > > > > > > > > > > > @@ -7,6 +7,12 @@ > > > > > > > > > > > > > #include <linux/of.h> > > > > > > > > > > > > > #include <uapi/linux/virtio_ids.h> > > > > > > > > > > > > > +static bool irq_hardening = false; > > > > > > > > > > > > > + > > > > > > > > > > > > > +module_param(irq_hardening, bool, 0444); > > > > > > > > > > > > > +MODULE_PARM_DESC(irq_hardening, > > > > > > > > > > > > > + "Disalbe IRQ software processing when it is not expected"); > > > > > > > > > > > > > + > > > > > > > > > > > > > /* Unique numbering for virtio devices. */ > > > > > > > > > > > > > static DEFINE_IDA(virtio_index_ida); > > > > > > > > > > > > > @@ -220,6 +226,15 @@ static int virtio_features_ok(struct virtio_device *dev) > > > > > > > > > > > > > * */ > > > > > > > > > > > > > void virtio_reset_device(struct virtio_device *dev) > > > > > > > > > > > > > { > > > > > > > > > > > > > + /* > > > > > > > > > > > > > + * The below synchronize_rcu() guarantees that any > > > > > > > > > > > > > + * interrupt for this line arriving after > > > > > > > > > > > > > + * synchronize_rcu() has completed is guaranteed to see > > > > > > > > > > > > > + * irq_soft_enabled == false. > > > > > > > > > > > > News to me I did not know synchronize_rcu has anything to do > > > > > > > > > > > > with interrupts. Did not you intend to use synchronize_irq? > > > > > > > > > > > > I am not even 100% sure synchronize_rcu is by design a memory barrier > > > > > > > > > > > > though it's most likely is ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > According to the comment above tree RCU version of synchronize_rcu(): > > > > > > > > > > > > > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > > > > > * RCU read-side critical sections are delimited by rcu_read_lock() > > > > > > > > > > > * and rcu_read_unlock(), and may be nested. In addition, but only in > > > > > > > > > > > * v5.0 and later, regions of code across which interrupts, preemption, > > > > > > > > > > > * or softirqs have been disabled also serve as RCU read-side critical > > > > > > > > > > > * sections. This includes hardware interrupt handlers, softirq handlers, > > > > > > > > > > > * and NMI handlers. > > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > > > > > So interrupt handlers are treated as read-side critical sections. > > > > > > > > > > > > > > > > > > > > > > And it has the comment for explain the barrier: > > > > > > > > > > > > > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > > > > > * Note that this guarantee implies further memory-ordering guarantees. > > > > > > > > > > > * On systems with more than one CPU, when synchronize_rcu() returns, > > > > > > > > > > > * each CPU is guaranteed to have executed a full memory barrier since > > > > > > > > > > > * the end of its last RCU read-side critical section whose beginning > > > > > > > > > > > * preceded the call to synchronize_rcu(). In addition, each CPU having > > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > > > > > So on SMP it provides a full barrier. And for UP/tiny RCU we don't need the > > > > > > > > > > > barrier, if the interrupt come after WRITE_ONCE() it will see the > > > > > > > > > > > irq_soft_enabled as false. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You are right. So then > > > > > > > > > > 1. I do not think we need load_acquire - why is it needed? Just > > > > > > > > > > READ_ONCE should do. > > > > > > > > > > > > > > > > > > See above. > > > > > > > > > > > > > > > > > > > 2. isn't synchronize_irq also doing the same thing? > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, but it requires a config ops since the IRQ knowledge is transport specific. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + */ > > > > > > > > > > > > > + WRITE_ONCE(dev->irq_soft_enabled, false); > > > > > > > > > > > > > + synchronize_rcu(); > > > > > > > > > > > > > + > > > > > > > > > > > > > dev->config->reset(dev); > > > > > > > > > > > > > } > > > > > > > > > > > > > EXPORT_SYMBOL_GPL(virtio_reset_device); > > > > > > > > > > > > Please add comment explaining where it will be enabled. > > > > > > > > > > > > Also, we *really* don't need to synch if it was already disabled, > > > > > > > > > > > > let's not add useless overhead to the boot sequence. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > @@ -427,6 +442,10 @@ int register_virtio_device(struct virtio_device *dev) > > > > > > > > > > > > > spin_lock_init(&dev->config_lock); > > > > > > > > > > > > > dev->config_enabled = false; > > > > > > > > > > > > > dev->config_change_pending = false; > > > > > > > > > > > > > + dev->irq_soft_check = irq_hardening; > > > > > > > > > > > > > + > > > > > > > > > > > > > + if (dev->irq_soft_check) > > > > > > > > > > > > > + dev_info(&dev->dev, "IRQ hardening is enabled\n"); > > > > > > > > > > > > > /* We always start by resetting the device, in case a previous > > > > > > > > > > > > > * driver messed it up. This also tests that code path a little. */ > > > > > > > > > > > > one of the points of hardening is it's also helpful for buggy > > > > > > > > > > > > devices. this flag defeats the purpose. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do you mean: > > > > > > > > > > > > > > > > > > > > > > 1) we need something like config_enable? This seems not easy to be > > > > > > > > > > > implemented without obvious overhead, mainly the synchronize with the > > > > > > > > > > > interrupt handlers > > > > > > > > > > > > > > > > > > > > But synchronize is only on tear-down path. That is not critical for any > > > > > > > > > > users at the moment, even less than probe. > > > > > > > > > > > > > > > > > > I meant if we have vq->irq_pending, we need to call vring_interrupt() > > > > > > > > > in the virtio_device_ready() and synchronize the IRQ handlers with > > > > > > > > > spinlock or others. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) enable this by default, so I don't object, but this may have some risk > > > > > > > > > > > for old hypervisors > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The risk if there's a driver adding buffers without setting DRIVER_OK. > > > > > > > > > > > > > > > > > > Probably not, we have devices that accept random inputs from outside, > > > > > > > > > net, console, input etc. I've done a round of audits of the Qemu > > > > > > > > > codes. They look all fine since day0. > > > > > > > > > > > > > > > > > > > So with this approach, how about we rename the flag "driver_ok"? > > > > > > > > > > And then add_buf can actually test it and BUG_ON if not there (at least > > > > > > > > > > in the debug build). > > > > > > > > > > > > > > > > > > This looks like a hardening of the driver in the core instead of the > > > > > > > > > device. I think it can be done but in a separate series. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And going down from there, how about we cache status in the > > > > > > > > > > device? Then we don't need to keep re-reading it every time, > > > > > > > > > > speeding boot up a tiny bit. > > > > > > > > > > > > > > > > > > I don't fully understand here, actually spec requires status to be > > > > > > > > > read back for validation in many cases. > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > > > > > > > > > > > > index 962f1477b1fa..0170f8c784d8 100644 > > > > > > > > > > > > > --- a/drivers/virtio/virtio_ring.c > > > > > > > > > > > > > +++ b/drivers/virtio/virtio_ring.c > > > > > > > > > > > > > @@ -2144,10 +2144,17 @@ static inline bool more_used(const struct vring_virtqueue *vq) > > > > > > > > > > > > > return vq->packed_ring ? more_used_packed(vq) : more_used_split(vq); > > > > > > > > > > > > > } > > > > > > > > > > > > > -irqreturn_t vring_interrupt(int irq, void *_vq) > > > > > > > > > > > > > +irqreturn_t vring_interrupt(int irq, void *v) > > > > > > > > > > > > > { > > > > > > > > > > > > > + struct virtqueue *_vq = v; > > > > > > > > > > > > > + struct virtio_device *vdev = _vq->vdev; > > > > > > > > > > > > > struct vring_virtqueue *vq = to_vvq(_vq); > > > > > > > > > > > > > + if (!virtio_irq_soft_enabled(vdev)) { > > > > > > > > > > > > > + dev_warn_once(&vdev->dev, "virtio vring IRQ raised before DRIVER_OK"); > > > > > > > > > > > > > + return IRQ_NONE; > > > > > > > > > > > > > + } > > > > > > > > > > > > > + > > > > > > > > > > > > > if (!more_used(vq)) { > > > > > > > > > > > > > pr_debug("virtqueue interrupt with no work for %p\n", vq); > > > > > > > > > > > > > return IRQ_NONE; > > > > > > > > > > > > > diff --git a/include/linux/virtio.h b/include/linux/virtio.h > > > > > > > > > > > > > index 5464f398912a..957d6ad604ac 100644 > > > > > > > > > > > > > --- a/include/linux/virtio.h > > > > > > > > > > > > > +++ b/include/linux/virtio.h > > > > > > > > > > > > > @@ -95,6 +95,8 @@ dma_addr_t virtqueue_get_used_addr(struct virtqueue *vq); > > > > > > > > > > > > > * @failed: saved value for VIRTIO_CONFIG_S_FAILED bit (for restore) > > > > > > > > > > > > > * @config_enabled: configuration change reporting enabled > > > > > > > > > > > > > * @config_change_pending: configuration change reported while disabled > > > > > > > > > > > > > + * @irq_soft_check: whether or not to check @irq_soft_enabled > > > > > > > > > > > > > + * @irq_soft_enabled: callbacks enabled > > > > > > > > > > > > > * @config_lock: protects configuration change reporting > > > > > > > > > > > > > * @dev: underlying device. > > > > > > > > > > > > > * @id: the device type identification (used to match it with a driver). > > > > > > > > > > > > > @@ -109,6 +111,8 @@ struct virtio_device { > > > > > > > > > > > > > bool failed; > > > > > > > > > > > > > bool config_enabled; > > > > > > > > > > > > > bool config_change_pending; > > > > > > > > > > > > > + bool irq_soft_check; > > > > > > > > > > > > > + bool irq_soft_enabled; > > > > > > > > > > > > > spinlock_t config_lock; > > > > > > > > > > > > > spinlock_t vqs_list_lock; /* Protects VQs list access */ > > > > > > > > > > > > > struct device dev; > > > > > > > > > > > > > diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h > > > > > > > > > > > > > index dafdc7f48c01..9c1b61f2e525 100644 > > > > > > > > > > > > > --- a/include/linux/virtio_config.h > > > > > > > > > > > > > +++ b/include/linux/virtio_config.h > > > > > > > > > > > > > @@ -174,6 +174,24 @@ static inline bool virtio_has_feature(const struct virtio_device *vdev, > > > > > > > > > > > > > return __virtio_test_bit(vdev, fbit); > > > > > > > > > > > > > } > > > > > > > > > > > > > +/* > > > > > > > > > > > > > + * virtio_irq_soft_enabled: whether we can execute callbacks > > > > > > > > > > > > > + * @vdev: the device > > > > > > > > > > > > > + */ > > > > > > > > > > > > > +static inline bool virtio_irq_soft_enabled(const struct virtio_device *vdev) > > > > > > > > > > > > > +{ > > > > > > > > > > > > > + if (!vdev->irq_soft_check) > > > > > > > > > > > > > + return true; > > > > > > > > > > > > > + > > > > > > > > > > > > > + /* > > > > > > > > > > > > > + * Read irq_soft_enabled before reading other device specific > > > > > > > > > > > > > + * data. Paried with smp_store_relase() in > > > > > > > > > > > > paired > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Will fix. > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + * virtio_device_ready() and WRITE_ONCE()/synchronize_rcu() in > > > > > > > > > > > > > + * virtio_reset_device(). > > > > > > > > > > > > > + */ > > > > > > > > > > > > > + return smp_load_acquire(&vdev->irq_soft_enabled); > > > > > > > > > > > > > +} > > > > > > > > > > > > > + > > > > > > > > > > > > > /** > > > > > > > > > > > > > * virtio_has_dma_quirk - determine whether this device has the DMA quirk > > > > > > > > > > > > > * @vdev: the device > > > > > > > > > > > > > @@ -236,6 +254,13 @@ void virtio_device_ready(struct virtio_device *dev) > > > > > > > > > > > > > if (dev->config->enable_cbs) > > > > > > > > > > > > > dev->config->enable_cbs(dev); > > > > > > > > > > > > > + /* > > > > > > > > > > > > > + * Commit the driver setup before enabling the virtqueue > > > > > > > > > > > > > + * callbacks. Paried with smp_load_acuqire() in > > > > > > > > > > > > > + * virtio_irq_soft_enabled() > > > > > > > > > > > > > + */ > > > > > > > > > > > > > + smp_store_release(&dev->irq_soft_enabled, true); > > > > > > > > > > > > > + > > > > > > > > > > > > > BUG_ON(status & VIRTIO_CONFIG_S_DRIVER_OK); > > > > > > > > > > > > > dev->config->set_status(dev, status | VIRTIO_CONFIG_S_DRIVER_OK); > > > > > > > > > > > > > } > > > > > > > > > > > > > -- > > > > > > > > > > > > > 2.25.1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-03-29 14:08 ` Re: Michael S. Tsirkin @ 2022-03-30 2:40 ` Jason Wang 2022-03-30 5:14 ` Re: Michael S. Tsirkin 0 siblings, 1 reply; 1767+ messages in thread From: Jason Wang @ 2022-03-30 2:40 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Paul E. McKenney, Peter Zijlstra, Marc Zyngier, Keir Fraser, linux-kernel, virtualization, Thomas Gleixner On Tue, Mar 29, 2022 at 10:09 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > On Tue, Mar 29, 2022 at 03:12:14PM +0800, Jason Wang wrote: > > > > > > > And requesting irq commits all memory otherwise all drivers would be > > > > > > > broken, > > > > > > > > > > > > So I think we might talk different issues: > > > > > > > > > > > > 1) Whether request_irq() commits the previous setups, I think the > > > > > > answer is yes, since the spin_unlock of desc->lock (release) can > > > > > > guarantee this though there seems no documentation around > > > > > > request_irq() to say this. > > > > > > > > > > > > And I can see at least drivers/video/fbdev/omap2/omapfb/dss/dispc.c is > > > > > > using smp_wmb() before the request_irq(). > > > > > > > > > > > > And even if write is ordered we still need read to be ordered to be > > > > > > paired with that. > > > > > > IMO it synchronizes with the CPU to which irq is > > > delivered. Otherwise basically all drivers would be broken, > > > wouldn't they be? > > > > I guess it's because most of the drivers don't care much about the > > buggy/malicious device. And most of the devices may require an extra > > step to enable device IRQ after request_irq(). Or it's the charge of > > the driver to do the synchronization. > > It is true that the use-case of malicious devices is somewhat boutique. > But I think most drivers do want to have their hotplug routines to be > robust, yes. > > > > I don't know whether it's correct on all platforms, but if not > > > we need to fix request_irq. > > > > > > > > > > > > > > > > if it doesn't it just needs to be fixed, not worked around in > > > > > > > virtio. > > > > > > > > > > > > 2) virtio drivers might do a lot of setups between request_irq() and > > > > > > virtio_device_ready(): > > > > > > > > > > > > request_irq() > > > > > > driver specific setups > > > > > > virtio_device_ready() > > > > > > > > > > > > CPU 0 probe) request_irq() > > > > > > CPU 1 IRQ handler) read the uninitialized variable > > > > > > CPU 0 probe) driver specific setups > > > > > > CPU 0 probe) smp_store_release(intr_soft_enabled, true), commit the setups > > > > > > CPU 1 IRQ handler) read irq_soft_enable as true > > > > > > CPU 1 IRQ handler) use the uninitialized variable > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > As I said, virtio_device_ready needs to do synchronize_irq. > > > > > That will guarantee all setup is visible to the specific IRQ, > > > > > > > > Only the interrupt after synchronize_irq() returns. > > > > > > Anything else is a buggy device though. > > > > Yes, but the goal of this patch is to prevent the possible attack from > > buggy(malicious) devices. > > Right. However if a driver of a *buggy* device somehow sees driver_ok = > false even though it's actually initialized, that is not a deal breaker > as that does not open us up to an attack. > > > > > > > > >this > > > > > is what it's point is. > > > > > > > > What happens if an interrupt is raised in the middle like: > > > > > > > > smp_store_release(dev->irq_soft_enabled, true) > > > > IRQ handler > > > > synchornize_irq() > > > > > > > > If we don't enforce a reading order, the IRQ handler may still see the > > > > uninitialized variable. > > > > > > > > Thanks > > > > > > IMHO variables should be initialized before request_irq > > > to a value meaning "not a valid interrupt". > > > Specifically driver_ok = false. > > > Handler in the scenario you describe will then see !driver_ok > > > and exit immediately. > > > > So just to make sure we're on the same page. > > > > 1) virtio_reset_device() will set the driver_ok to false; > > 2) virtio_device_ready() will set the driver_ok to true > > > > So for virtio drivers, it often did: > > > > 1) virtio_reset_device() > > 2) find_vqs() which will call request_irq() > > 3) other driver specific setups > > 4) virtio_device_ready() > > > > In virtio_device_ready(), the patch perform the following currently: > > > > smp_store_release(driver_ok, true); > > set_status(DRIVER_OK); > > > > Per your suggestion, to add synchronize_irq() after > > smp_store_release() so we had > > > > smp_store_release(driver_ok, true); > > synchornize_irq() > > set_status(DRIVER_OK) > > > > Suppose there's a interrupt raised before the synchronize_irq(), if we do: > > > > if (READ_ONCE(driver_ok)) { > > vq->callback() > > } > > > > It will see the driver_ok as true but how can we make sure > > vq->callback sees the driver specific setups (3) above? > > > > And an example is virtio_scsi(): > > > > virtio_reset_device() > > virtscsi_probe() > > virtscsi_init() > > virtio_find_vqs() > > ... > > virtscsi_init_vq(&vscsi->event_vq, vqs[1]) > > .... > > virtio_device_ready() > > > > In virtscsi_event_done(): > > > > virtscsi_event_done(): > > virtscsi_vq_done(vscsi, &vscsi->event_vq, ...); > > > > We need to make sure the even_done reads driver_ok before read vscsi->event_vq. > > > > Thanks > > > See response by Thomas. A simple if (!dev->driver_ok) should be enough, > it's all under a lock. Ordered through ACQUIRE+RELEASE actually since the irq handler is not running under the lock. Another question, for synchronize_irq() do you prefer 1) transport specific callbacks or 2) a simple synchornize_rcu() Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We use smp_store_relase() > > > > > > > > > > to make sure the driver commits the setup before enabling the irq. It > > > > > > > > > > means the read needs to be ordered as well in vring_interrupt(). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Although I couldn't find anything about this in memory-barriers.txt > > > > > > > > > > > which surprises me. > > > > > > > > > > > > > > > > > > > > > > CC Paul to help make sure I'm right. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To avoid breaking legacy device which can send IRQ before DRIVER_OK, a > > > > > > > > > > > > > > module parameter is introduced to enable the hardening so function > > > > > > > > > > > > > > hardening is disabled by default. > > > > > > > > > > > > > Which devices are these? How come they send an interrupt before there > > > > > > > > > > > > > are any buffers in any queues? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I copied this from the commit log for 22b7050a024d7 > > > > > > > > > > > > > > > > > > > > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > This change will also benefit old hypervisors (before 2009) > > > > > > > > > > > > that send interrupts without checking DRIVER_OK: previously, > > > > > > > > > > > > the callback could race with driver-specific initialization. > > > > > > > > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > If this is only for config interrupt, I can remove the above log. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is only for config interrupt. > > > > > > > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Note that the hardening is only done for vring interrupt since the > > > > > > > > > > > > > > config interrupt hardening is already done in commit 22b7050a024d7 > > > > > > > > > > > > > > ("virtio: defer config changed notifications"). But the method that is > > > > > > > > > > > > > > used by config interrupt can't be reused by the vring interrupt > > > > > > > > > > > > > > handler because it uses spinlock to do the synchronization which is > > > > > > > > > > > > > > expensive. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Jason Wang <jasowang@redhat.com> > > > > > > > > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > drivers/virtio/virtio.c | 19 +++++++++++++++++++ > > > > > > > > > > > > > > drivers/virtio/virtio_ring.c | 9 ++++++++- > > > > > > > > > > > > > > include/linux/virtio.h | 4 ++++ > > > > > > > > > > > > > > include/linux/virtio_config.h | 25 +++++++++++++++++++++++++ > > > > > > > > > > > > > > 4 files changed, 56 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c > > > > > > > > > > > > > > index 8dde44ea044a..85e331efa9cc 100644 > > > > > > > > > > > > > > --- a/drivers/virtio/virtio.c > > > > > > > > > > > > > > +++ b/drivers/virtio/virtio.c > > > > > > > > > > > > > > @@ -7,6 +7,12 @@ > > > > > > > > > > > > > > #include <linux/of.h> > > > > > > > > > > > > > > #include <uapi/linux/virtio_ids.h> > > > > > > > > > > > > > > +static bool irq_hardening = false; > > > > > > > > > > > > > > + > > > > > > > > > > > > > > +module_param(irq_hardening, bool, 0444); > > > > > > > > > > > > > > +MODULE_PARM_DESC(irq_hardening, > > > > > > > > > > > > > > + "Disalbe IRQ software processing when it is not expected"); > > > > > > > > > > > > > > + > > > > > > > > > > > > > > /* Unique numbering for virtio devices. */ > > > > > > > > > > > > > > static DEFINE_IDA(virtio_index_ida); > > > > > > > > > > > > > > @@ -220,6 +226,15 @@ static int virtio_features_ok(struct virtio_device *dev) > > > > > > > > > > > > > > * */ > > > > > > > > > > > > > > void virtio_reset_device(struct virtio_device *dev) > > > > > > > > > > > > > > { > > > > > > > > > > > > > > + /* > > > > > > > > > > > > > > + * The below synchronize_rcu() guarantees that any > > > > > > > > > > > > > > + * interrupt for this line arriving after > > > > > > > > > > > > > > + * synchronize_rcu() has completed is guaranteed to see > > > > > > > > > > > > > > + * irq_soft_enabled == false. > > > > > > > > > > > > > News to me I did not know synchronize_rcu has anything to do > > > > > > > > > > > > > with interrupts. Did not you intend to use synchronize_irq? > > > > > > > > > > > > > I am not even 100% sure synchronize_rcu is by design a memory barrier > > > > > > > > > > > > > though it's most likely is ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > According to the comment above tree RCU version of synchronize_rcu(): > > > > > > > > > > > > > > > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > > > > > > > * RCU read-side critical sections are delimited by rcu_read_lock() > > > > > > > > > > > > * and rcu_read_unlock(), and may be nested. In addition, but only in > > > > > > > > > > > > * v5.0 and later, regions of code across which interrupts, preemption, > > > > > > > > > > > > * or softirqs have been disabled also serve as RCU read-side critical > > > > > > > > > > > > * sections. This includes hardware interrupt handlers, softirq handlers, > > > > > > > > > > > > * and NMI handlers. > > > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > > > > > > > So interrupt handlers are treated as read-side critical sections. > > > > > > > > > > > > > > > > > > > > > > > > And it has the comment for explain the barrier: > > > > > > > > > > > > > > > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > > > > > > > * Note that this guarantee implies further memory-ordering guarantees. > > > > > > > > > > > > * On systems with more than one CPU, when synchronize_rcu() returns, > > > > > > > > > > > > * each CPU is guaranteed to have executed a full memory barrier since > > > > > > > > > > > > * the end of its last RCU read-side critical section whose beginning > > > > > > > > > > > > * preceded the call to synchronize_rcu(). In addition, each CPU having > > > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > > > > > > > So on SMP it provides a full barrier. And for UP/tiny RCU we don't need the > > > > > > > > > > > > barrier, if the interrupt come after WRITE_ONCE() it will see the > > > > > > > > > > > > irq_soft_enabled as false. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You are right. So then > > > > > > > > > > > 1. I do not think we need load_acquire - why is it needed? Just > > > > > > > > > > > READ_ONCE should do. > > > > > > > > > > > > > > > > > > > > See above. > > > > > > > > > > > > > > > > > > > > > 2. isn't synchronize_irq also doing the same thing? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, but it requires a config ops since the IRQ knowledge is transport specific. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + */ > > > > > > > > > > > > > > + WRITE_ONCE(dev->irq_soft_enabled, false); > > > > > > > > > > > > > > + synchronize_rcu(); > > > > > > > > > > > > > > + > > > > > > > > > > > > > > dev->config->reset(dev); > > > > > > > > > > > > > > } > > > > > > > > > > > > > > EXPORT_SYMBOL_GPL(virtio_reset_device); > > > > > > > > > > > > > Please add comment explaining where it will be enabled. > > > > > > > > > > > > > Also, we *really* don't need to synch if it was already disabled, > > > > > > > > > > > > > let's not add useless overhead to the boot sequence. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > @@ -427,6 +442,10 @@ int register_virtio_device(struct virtio_device *dev) > > > > > > > > > > > > > > spin_lock_init(&dev->config_lock); > > > > > > > > > > > > > > dev->config_enabled = false; > > > > > > > > > > > > > > dev->config_change_pending = false; > > > > > > > > > > > > > > + dev->irq_soft_check = irq_hardening; > > > > > > > > > > > > > > + > > > > > > > > > > > > > > + if (dev->irq_soft_check) > > > > > > > > > > > > > > + dev_info(&dev->dev, "IRQ hardening is enabled\n"); > > > > > > > > > > > > > > /* We always start by resetting the device, in case a previous > > > > > > > > > > > > > > * driver messed it up. This also tests that code path a little. */ > > > > > > > > > > > > > one of the points of hardening is it's also helpful for buggy > > > > > > > > > > > > > devices. this flag defeats the purpose. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do you mean: > > > > > > > > > > > > > > > > > > > > > > > > 1) we need something like config_enable? This seems not easy to be > > > > > > > > > > > > implemented without obvious overhead, mainly the synchronize with the > > > > > > > > > > > > interrupt handlers > > > > > > > > > > > > > > > > > > > > > > But synchronize is only on tear-down path. That is not critical for any > > > > > > > > > > > users at the moment, even less than probe. > > > > > > > > > > > > > > > > > > > > I meant if we have vq->irq_pending, we need to call vring_interrupt() > > > > > > > > > > in the virtio_device_ready() and synchronize the IRQ handlers with > > > > > > > > > > spinlock or others. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) enable this by default, so I don't object, but this may have some risk > > > > > > > > > > > > for old hypervisors > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The risk if there's a driver adding buffers without setting DRIVER_OK. > > > > > > > > > > > > > > > > > > > > Probably not, we have devices that accept random inputs from outside, > > > > > > > > > > net, console, input etc. I've done a round of audits of the Qemu > > > > > > > > > > codes. They look all fine since day0. > > > > > > > > > > > > > > > > > > > > > So with this approach, how about we rename the flag "driver_ok"? > > > > > > > > > > > And then add_buf can actually test it and BUG_ON if not there (at least > > > > > > > > > > > in the debug build). > > > > > > > > > > > > > > > > > > > > This looks like a hardening of the driver in the core instead of the > > > > > > > > > > device. I think it can be done but in a separate series. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And going down from there, how about we cache status in the > > > > > > > > > > > device? Then we don't need to keep re-reading it every time, > > > > > > > > > > > speeding boot up a tiny bit. > > > > > > > > > > > > > > > > > > > > I don't fully understand here, actually spec requires status to be > > > > > > > > > > read back for validation in many cases. > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > > > > > > > > > > > > > index 962f1477b1fa..0170f8c784d8 100644 > > > > > > > > > > > > > > --- a/drivers/virtio/virtio_ring.c > > > > > > > > > > > > > > +++ b/drivers/virtio/virtio_ring.c > > > > > > > > > > > > > > @@ -2144,10 +2144,17 @@ static inline bool more_used(const struct vring_virtqueue *vq) > > > > > > > > > > > > > > return vq->packed_ring ? more_used_packed(vq) : more_used_split(vq); > > > > > > > > > > > > > > } > > > > > > > > > > > > > > -irqreturn_t vring_interrupt(int irq, void *_vq) > > > > > > > > > > > > > > +irqreturn_t vring_interrupt(int irq, void *v) > > > > > > > > > > > > > > { > > > > > > > > > > > > > > + struct virtqueue *_vq = v; > > > > > > > > > > > > > > + struct virtio_device *vdev = _vq->vdev; > > > > > > > > > > > > > > struct vring_virtqueue *vq = to_vvq(_vq); > > > > > > > > > > > > > > + if (!virtio_irq_soft_enabled(vdev)) { > > > > > > > > > > > > > > + dev_warn_once(&vdev->dev, "virtio vring IRQ raised before DRIVER_OK"); > > > > > > > > > > > > > > + return IRQ_NONE; > > > > > > > > > > > > > > + } > > > > > > > > > > > > > > + > > > > > > > > > > > > > > if (!more_used(vq)) { > > > > > > > > > > > > > > pr_debug("virtqueue interrupt with no work for %p\n", vq); > > > > > > > > > > > > > > return IRQ_NONE; > > > > > > > > > > > > > > diff --git a/include/linux/virtio.h b/include/linux/virtio.h > > > > > > > > > > > > > > index 5464f398912a..957d6ad604ac 100644 > > > > > > > > > > > > > > --- a/include/linux/virtio.h > > > > > > > > > > > > > > +++ b/include/linux/virtio.h > > > > > > > > > > > > > > @@ -95,6 +95,8 @@ dma_addr_t virtqueue_get_used_addr(struct virtqueue *vq); > > > > > > > > > > > > > > * @failed: saved value for VIRTIO_CONFIG_S_FAILED bit (for restore) > > > > > > > > > > > > > > * @config_enabled: configuration change reporting enabled > > > > > > > > > > > > > > * @config_change_pending: configuration change reported while disabled > > > > > > > > > > > > > > + * @irq_soft_check: whether or not to check @irq_soft_enabled > > > > > > > > > > > > > > + * @irq_soft_enabled: callbacks enabled > > > > > > > > > > > > > > * @config_lock: protects configuration change reporting > > > > > > > > > > > > > > * @dev: underlying device. > > > > > > > > > > > > > > * @id: the device type identification (used to match it with a driver). > > > > > > > > > > > > > > @@ -109,6 +111,8 @@ struct virtio_device { > > > > > > > > > > > > > > bool failed; > > > > > > > > > > > > > > bool config_enabled; > > > > > > > > > > > > > > bool config_change_pending; > > > > > > > > > > > > > > + bool irq_soft_check; > > > > > > > > > > > > > > + bool irq_soft_enabled; > > > > > > > > > > > > > > spinlock_t config_lock; > > > > > > > > > > > > > > spinlock_t vqs_list_lock; /* Protects VQs list access */ > > > > > > > > > > > > > > struct device dev; > > > > > > > > > > > > > > diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h > > > > > > > > > > > > > > index dafdc7f48c01..9c1b61f2e525 100644 > > > > > > > > > > > > > > --- a/include/linux/virtio_config.h > > > > > > > > > > > > > > +++ b/include/linux/virtio_config.h > > > > > > > > > > > > > > @@ -174,6 +174,24 @@ static inline bool virtio_has_feature(const struct virtio_device *vdev, > > > > > > > > > > > > > > return __virtio_test_bit(vdev, fbit); > > > > > > > > > > > > > > } > > > > > > > > > > > > > > +/* > > > > > > > > > > > > > > + * virtio_irq_soft_enabled: whether we can execute callbacks > > > > > > > > > > > > > > + * @vdev: the device > > > > > > > > > > > > > > + */ > > > > > > > > > > > > > > +static inline bool virtio_irq_soft_enabled(const struct virtio_device *vdev) > > > > > > > > > > > > > > +{ > > > > > > > > > > > > > > + if (!vdev->irq_soft_check) > > > > > > > > > > > > > > + return true; > > > > > > > > > > > > > > + > > > > > > > > > > > > > > + /* > > > > > > > > > > > > > > + * Read irq_soft_enabled before reading other device specific > > > > > > > > > > > > > > + * data. Paried with smp_store_relase() in > > > > > > > > > > > > > paired > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Will fix. > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + * virtio_device_ready() and WRITE_ONCE()/synchronize_rcu() in > > > > > > > > > > > > > > + * virtio_reset_device(). > > > > > > > > > > > > > > + */ > > > > > > > > > > > > > > + return smp_load_acquire(&vdev->irq_soft_enabled); > > > > > > > > > > > > > > +} > > > > > > > > > > > > > > + > > > > > > > > > > > > > > /** > > > > > > > > > > > > > > * virtio_has_dma_quirk - determine whether this device has the DMA quirk > > > > > > > > > > > > > > * @vdev: the device > > > > > > > > > > > > > > @@ -236,6 +254,13 @@ void virtio_device_ready(struct virtio_device *dev) > > > > > > > > > > > > > > if (dev->config->enable_cbs) > > > > > > > > > > > > > > dev->config->enable_cbs(dev); > > > > > > > > > > > > > > + /* > > > > > > > > > > > > > > + * Commit the driver setup before enabling the virtqueue > > > > > > > > > > > > > > + * callbacks. Paried with smp_load_acuqire() in > > > > > > > > > > > > > > + * virtio_irq_soft_enabled() > > > > > > > > > > > > > > + */ > > > > > > > > > > > > > > + smp_store_release(&dev->irq_soft_enabled, true); > > > > > > > > > > > > > > + > > > > > > > > > > > > > > BUG_ON(status & VIRTIO_CONFIG_S_DRIVER_OK); > > > > > > > > > > > > > > dev->config->set_status(dev, status | VIRTIO_CONFIG_S_DRIVER_OK); > > > > > > > > > > > > > > } > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > 2.25.1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-03-30 2:40 ` Re: Jason Wang @ 2022-03-30 5:14 ` Michael S. Tsirkin 2022-03-30 5:53 ` Re: Jason Wang 0 siblings, 1 reply; 1767+ messages in thread From: Michael S. Tsirkin @ 2022-03-30 5:14 UTC (permalink / raw) To: Jason Wang Cc: Paul E. McKenney, Peter Zijlstra, Marc Zyngier, Keir Fraser, linux-kernel, virtualization, Thomas Gleixner On Wed, Mar 30, 2022 at 10:40:59AM +0800, Jason Wang wrote: > On Tue, Mar 29, 2022 at 10:09 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > On Tue, Mar 29, 2022 at 03:12:14PM +0800, Jason Wang wrote: > > > > > > > > And requesting irq commits all memory otherwise all drivers would be > > > > > > > > broken, > > > > > > > > > > > > > > So I think we might talk different issues: > > > > > > > > > > > > > > 1) Whether request_irq() commits the previous setups, I think the > > > > > > > answer is yes, since the spin_unlock of desc->lock (release) can > > > > > > > guarantee this though there seems no documentation around > > > > > > > request_irq() to say this. > > > > > > > > > > > > > > And I can see at least drivers/video/fbdev/omap2/omapfb/dss/dispc.c is > > > > > > > using smp_wmb() before the request_irq(). > > > > > > > > > > > > > > And even if write is ordered we still need read to be ordered to be > > > > > > > paired with that. > > > > > > > > IMO it synchronizes with the CPU to which irq is > > > > delivered. Otherwise basically all drivers would be broken, > > > > wouldn't they be? > > > > > > I guess it's because most of the drivers don't care much about the > > > buggy/malicious device. And most of the devices may require an extra > > > step to enable device IRQ after request_irq(). Or it's the charge of > > > the driver to do the synchronization. > > > > It is true that the use-case of malicious devices is somewhat boutique. > > But I think most drivers do want to have their hotplug routines to be > > robust, yes. > > > > > > I don't know whether it's correct on all platforms, but if not > > > > we need to fix request_irq. > > > > > > > > > > > > > > > > > > > if it doesn't it just needs to be fixed, not worked around in > > > > > > > > virtio. > > > > > > > > > > > > > > 2) virtio drivers might do a lot of setups between request_irq() and > > > > > > > virtio_device_ready(): > > > > > > > > > > > > > > request_irq() > > > > > > > driver specific setups > > > > > > > virtio_device_ready() > > > > > > > > > > > > > > CPU 0 probe) request_irq() > > > > > > > CPU 1 IRQ handler) read the uninitialized variable > > > > > > > CPU 0 probe) driver specific setups > > > > > > > CPU 0 probe) smp_store_release(intr_soft_enabled, true), commit the setups > > > > > > > CPU 1 IRQ handler) read irq_soft_enable as true > > > > > > > CPU 1 IRQ handler) use the uninitialized variable > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > As I said, virtio_device_ready needs to do synchronize_irq. > > > > > > That will guarantee all setup is visible to the specific IRQ, > > > > > > > > > > Only the interrupt after synchronize_irq() returns. > > > > > > > > Anything else is a buggy device though. > > > > > > Yes, but the goal of this patch is to prevent the possible attack from > > > buggy(malicious) devices. > > > > Right. However if a driver of a *buggy* device somehow sees driver_ok = > > false even though it's actually initialized, that is not a deal breaker > > as that does not open us up to an attack. > > > > > > > > > > > >this > > > > > > is what it's point is. > > > > > > > > > > What happens if an interrupt is raised in the middle like: > > > > > > > > > > smp_store_release(dev->irq_soft_enabled, true) > > > > > IRQ handler > > > > > synchornize_irq() > > > > > > > > > > If we don't enforce a reading order, the IRQ handler may still see the > > > > > uninitialized variable. > > > > > > > > > > Thanks > > > > > > > > IMHO variables should be initialized before request_irq > > > > to a value meaning "not a valid interrupt". > > > > Specifically driver_ok = false. > > > > Handler in the scenario you describe will then see !driver_ok > > > > and exit immediately. > > > > > > So just to make sure we're on the same page. > > > > > > 1) virtio_reset_device() will set the driver_ok to false; > > > 2) virtio_device_ready() will set the driver_ok to true > > > > > > So for virtio drivers, it often did: > > > > > > 1) virtio_reset_device() > > > 2) find_vqs() which will call request_irq() > > > 3) other driver specific setups > > > 4) virtio_device_ready() > > > > > > In virtio_device_ready(), the patch perform the following currently: > > > > > > smp_store_release(driver_ok, true); > > > set_status(DRIVER_OK); > > > > > > Per your suggestion, to add synchronize_irq() after > > > smp_store_release() so we had > > > > > > smp_store_release(driver_ok, true); > > > synchornize_irq() > > > set_status(DRIVER_OK) > > > > > > Suppose there's a interrupt raised before the synchronize_irq(), if we do: > > > > > > if (READ_ONCE(driver_ok)) { > > > vq->callback() > > > } > > > > > > It will see the driver_ok as true but how can we make sure > > > vq->callback sees the driver specific setups (3) above? > > > > > > And an example is virtio_scsi(): > > > > > > virtio_reset_device() > > > virtscsi_probe() > > > virtscsi_init() > > > virtio_find_vqs() > > > ... > > > virtscsi_init_vq(&vscsi->event_vq, vqs[1]) > > > .... > > > virtio_device_ready() > > > > > > In virtscsi_event_done(): > > > > > > virtscsi_event_done(): > > > virtscsi_vq_done(vscsi, &vscsi->event_vq, ...); > > > > > > We need to make sure the even_done reads driver_ok before read vscsi->event_vq. > > > > > > Thanks > > > > > > See response by Thomas. A simple if (!dev->driver_ok) should be enough, > > it's all under a lock. > > Ordered through ACQUIRE+RELEASE actually since the irq handler is not > running under the lock. > > Another question, for synchronize_irq() do you prefer > > 1) transport specific callbacks > or > 2) a simple synchornize_rcu() > > Thanks 1) I think, and I'd add a wrapper so we can switch to 2 if we really want to. But for now synchronizing the specific irq is obviously designed to make any changes to memory visible to this irq. that seems cleaner and easier to understand than memory ordering tricks and relying on side effects of synchornize_rcu, even though internally this all boils down to memory ordering since memory is what's used to implement locks :). Not to mention, synchronize_irq just scales much better from performance POV. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We use smp_store_relase() > > > > > > > > > > > to make sure the driver commits the setup before enabling the irq. It > > > > > > > > > > > means the read needs to be ordered as well in vring_interrupt(). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Although I couldn't find anything about this in memory-barriers.txt > > > > > > > > > > > > which surprises me. > > > > > > > > > > > > > > > > > > > > > > > > CC Paul to help make sure I'm right. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To avoid breaking legacy device which can send IRQ before DRIVER_OK, a > > > > > > > > > > > > > > > module parameter is introduced to enable the hardening so function > > > > > > > > > > > > > > > hardening is disabled by default. > > > > > > > > > > > > > > Which devices are these? How come they send an interrupt before there > > > > > > > > > > > > > > are any buffers in any queues? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I copied this from the commit log for 22b7050a024d7 > > > > > > > > > > > > > > > > > > > > > > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > > This change will also benefit old hypervisors (before 2009) > > > > > > > > > > > > > that send interrupts without checking DRIVER_OK: previously, > > > > > > > > > > > > > the callback could race with driver-specific initialization. > > > > > > > > > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > > If this is only for config interrupt, I can remove the above log. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is only for config interrupt. > > > > > > > > > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Note that the hardening is only done for vring interrupt since the > > > > > > > > > > > > > > > config interrupt hardening is already done in commit 22b7050a024d7 > > > > > > > > > > > > > > > ("virtio: defer config changed notifications"). But the method that is > > > > > > > > > > > > > > > used by config interrupt can't be reused by the vring interrupt > > > > > > > > > > > > > > > handler because it uses spinlock to do the synchronization which is > > > > > > > > > > > > > > > expensive. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Jason Wang <jasowang@redhat.com> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > drivers/virtio/virtio.c | 19 +++++++++++++++++++ > > > > > > > > > > > > > > > drivers/virtio/virtio_ring.c | 9 ++++++++- > > > > > > > > > > > > > > > include/linux/virtio.h | 4 ++++ > > > > > > > > > > > > > > > include/linux/virtio_config.h | 25 +++++++++++++++++++++++++ > > > > > > > > > > > > > > > 4 files changed, 56 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c > > > > > > > > > > > > > > > index 8dde44ea044a..85e331efa9cc 100644 > > > > > > > > > > > > > > > --- a/drivers/virtio/virtio.c > > > > > > > > > > > > > > > +++ b/drivers/virtio/virtio.c > > > > > > > > > > > > > > > @@ -7,6 +7,12 @@ > > > > > > > > > > > > > > > #include <linux/of.h> > > > > > > > > > > > > > > > #include <uapi/linux/virtio_ids.h> > > > > > > > > > > > > > > > +static bool irq_hardening = false; > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > +module_param(irq_hardening, bool, 0444); > > > > > > > > > > > > > > > +MODULE_PARM_DESC(irq_hardening, > > > > > > > > > > > > > > > + "Disalbe IRQ software processing when it is not expected"); > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > /* Unique numbering for virtio devices. */ > > > > > > > > > > > > > > > static DEFINE_IDA(virtio_index_ida); > > > > > > > > > > > > > > > @@ -220,6 +226,15 @@ static int virtio_features_ok(struct virtio_device *dev) > > > > > > > > > > > > > > > * */ > > > > > > > > > > > > > > > void virtio_reset_device(struct virtio_device *dev) > > > > > > > > > > > > > > > { > > > > > > > > > > > > > > > + /* > > > > > > > > > > > > > > > + * The below synchronize_rcu() guarantees that any > > > > > > > > > > > > > > > + * interrupt for this line arriving after > > > > > > > > > > > > > > > + * synchronize_rcu() has completed is guaranteed to see > > > > > > > > > > > > > > > + * irq_soft_enabled == false. > > > > > > > > > > > > > > News to me I did not know synchronize_rcu has anything to do > > > > > > > > > > > > > > with interrupts. Did not you intend to use synchronize_irq? > > > > > > > > > > > > > > I am not even 100% sure synchronize_rcu is by design a memory barrier > > > > > > > > > > > > > > though it's most likely is ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > According to the comment above tree RCU version of synchronize_rcu(): > > > > > > > > > > > > > > > > > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > > > > > > > > > * RCU read-side critical sections are delimited by rcu_read_lock() > > > > > > > > > > > > > * and rcu_read_unlock(), and may be nested. In addition, but only in > > > > > > > > > > > > > * v5.0 and later, regions of code across which interrupts, preemption, > > > > > > > > > > > > > * or softirqs have been disabled also serve as RCU read-side critical > > > > > > > > > > > > > * sections. This includes hardware interrupt handlers, softirq handlers, > > > > > > > > > > > > > * and NMI handlers. > > > > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > > > > > > > > > So interrupt handlers are treated as read-side critical sections. > > > > > > > > > > > > > > > > > > > > > > > > > > And it has the comment for explain the barrier: > > > > > > > > > > > > > > > > > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > > > > > > > > > * Note that this guarantee implies further memory-ordering guarantees. > > > > > > > > > > > > > * On systems with more than one CPU, when synchronize_rcu() returns, > > > > > > > > > > > > > * each CPU is guaranteed to have executed a full memory barrier since > > > > > > > > > > > > > * the end of its last RCU read-side critical section whose beginning > > > > > > > > > > > > > * preceded the call to synchronize_rcu(). In addition, each CPU having > > > > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > > > > > > > > > So on SMP it provides a full barrier. And for UP/tiny RCU we don't need the > > > > > > > > > > > > > barrier, if the interrupt come after WRITE_ONCE() it will see the > > > > > > > > > > > > > irq_soft_enabled as false. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You are right. So then > > > > > > > > > > > > 1. I do not think we need load_acquire - why is it needed? Just > > > > > > > > > > > > READ_ONCE should do. > > > > > > > > > > > > > > > > > > > > > > See above. > > > > > > > > > > > > > > > > > > > > > > > 2. isn't synchronize_irq also doing the same thing? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, but it requires a config ops since the IRQ knowledge is transport specific. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + */ > > > > > > > > > > > > > > > + WRITE_ONCE(dev->irq_soft_enabled, false); > > > > > > > > > > > > > > > + synchronize_rcu(); > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > dev->config->reset(dev); > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > EXPORT_SYMBOL_GPL(virtio_reset_device); > > > > > > > > > > > > > > Please add comment explaining where it will be enabled. > > > > > > > > > > > > > > Also, we *really* don't need to synch if it was already disabled, > > > > > > > > > > > > > > let's not add useless overhead to the boot sequence. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > @@ -427,6 +442,10 @@ int register_virtio_device(struct virtio_device *dev) > > > > > > > > > > > > > > > spin_lock_init(&dev->config_lock); > > > > > > > > > > > > > > > dev->config_enabled = false; > > > > > > > > > > > > > > > dev->config_change_pending = false; > > > > > > > > > > > > > > > + dev->irq_soft_check = irq_hardening; > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > + if (dev->irq_soft_check) > > > > > > > > > > > > > > > + dev_info(&dev->dev, "IRQ hardening is enabled\n"); > > > > > > > > > > > > > > > /* We always start by resetting the device, in case a previous > > > > > > > > > > > > > > > * driver messed it up. This also tests that code path a little. */ > > > > > > > > > > > > > > one of the points of hardening is it's also helpful for buggy > > > > > > > > > > > > > > devices. this flag defeats the purpose. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do you mean: > > > > > > > > > > > > > > > > > > > > > > > > > > 1) we need something like config_enable? This seems not easy to be > > > > > > > > > > > > > implemented without obvious overhead, mainly the synchronize with the > > > > > > > > > > > > > interrupt handlers > > > > > > > > > > > > > > > > > > > > > > > > But synchronize is only on tear-down path. That is not critical for any > > > > > > > > > > > > users at the moment, even less than probe. > > > > > > > > > > > > > > > > > > > > > > I meant if we have vq->irq_pending, we need to call vring_interrupt() > > > > > > > > > > > in the virtio_device_ready() and synchronize the IRQ handlers with > > > > > > > > > > > spinlock or others. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) enable this by default, so I don't object, but this may have some risk > > > > > > > > > > > > > for old hypervisors > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The risk if there's a driver adding buffers without setting DRIVER_OK. > > > > > > > > > > > > > > > > > > > > > > Probably not, we have devices that accept random inputs from outside, > > > > > > > > > > > net, console, input etc. I've done a round of audits of the Qemu > > > > > > > > > > > codes. They look all fine since day0. > > > > > > > > > > > > > > > > > > > > > > > So with this approach, how about we rename the flag "driver_ok"? > > > > > > > > > > > > And then add_buf can actually test it and BUG_ON if not there (at least > > > > > > > > > > > > in the debug build). > > > > > > > > > > > > > > > > > > > > > > This looks like a hardening of the driver in the core instead of the > > > > > > > > > > > device. I think it can be done but in a separate series. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And going down from there, how about we cache status in the > > > > > > > > > > > > device? Then we don't need to keep re-reading it every time, > > > > > > > > > > > > speeding boot up a tiny bit. > > > > > > > > > > > > > > > > > > > > > > I don't fully understand here, actually spec requires status to be > > > > > > > > > > > read back for validation in many cases. > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > > > > > > > > > > > > > > index 962f1477b1fa..0170f8c784d8 100644 > > > > > > > > > > > > > > > --- a/drivers/virtio/virtio_ring.c > > > > > > > > > > > > > > > +++ b/drivers/virtio/virtio_ring.c > > > > > > > > > > > > > > > @@ -2144,10 +2144,17 @@ static inline bool more_used(const struct vring_virtqueue *vq) > > > > > > > > > > > > > > > return vq->packed_ring ? more_used_packed(vq) : more_used_split(vq); > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > -irqreturn_t vring_interrupt(int irq, void *_vq) > > > > > > > > > > > > > > > +irqreturn_t vring_interrupt(int irq, void *v) > > > > > > > > > > > > > > > { > > > > > > > > > > > > > > > + struct virtqueue *_vq = v; > > > > > > > > > > > > > > > + struct virtio_device *vdev = _vq->vdev; > > > > > > > > > > > > > > > struct vring_virtqueue *vq = to_vvq(_vq); > > > > > > > > > > > > > > > + if (!virtio_irq_soft_enabled(vdev)) { > > > > > > > > > > > > > > > + dev_warn_once(&vdev->dev, "virtio vring IRQ raised before DRIVER_OK"); > > > > > > > > > > > > > > > + return IRQ_NONE; > > > > > > > > > > > > > > > + } > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > if (!more_used(vq)) { > > > > > > > > > > > > > > > pr_debug("virtqueue interrupt with no work for %p\n", vq); > > > > > > > > > > > > > > > return IRQ_NONE; > > > > > > > > > > > > > > > diff --git a/include/linux/virtio.h b/include/linux/virtio.h > > > > > > > > > > > > > > > index 5464f398912a..957d6ad604ac 100644 > > > > > > > > > > > > > > > --- a/include/linux/virtio.h > > > > > > > > > > > > > > > +++ b/include/linux/virtio.h > > > > > > > > > > > > > > > @@ -95,6 +95,8 @@ dma_addr_t virtqueue_get_used_addr(struct virtqueue *vq); > > > > > > > > > > > > > > > * @failed: saved value for VIRTIO_CONFIG_S_FAILED bit (for restore) > > > > > > > > > > > > > > > * @config_enabled: configuration change reporting enabled > > > > > > > > > > > > > > > * @config_change_pending: configuration change reported while disabled > > > > > > > > > > > > > > > + * @irq_soft_check: whether or not to check @irq_soft_enabled > > > > > > > > > > > > > > > + * @irq_soft_enabled: callbacks enabled > > > > > > > > > > > > > > > * @config_lock: protects configuration change reporting > > > > > > > > > > > > > > > * @dev: underlying device. > > > > > > > > > > > > > > > * @id: the device type identification (used to match it with a driver). > > > > > > > > > > > > > > > @@ -109,6 +111,8 @@ struct virtio_device { > > > > > > > > > > > > > > > bool failed; > > > > > > > > > > > > > > > bool config_enabled; > > > > > > > > > > > > > > > bool config_change_pending; > > > > > > > > > > > > > > > + bool irq_soft_check; > > > > > > > > > > > > > > > + bool irq_soft_enabled; > > > > > > > > > > > > > > > spinlock_t config_lock; > > > > > > > > > > > > > > > spinlock_t vqs_list_lock; /* Protects VQs list access */ > > > > > > > > > > > > > > > struct device dev; > > > > > > > > > > > > > > > diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h > > > > > > > > > > > > > > > index dafdc7f48c01..9c1b61f2e525 100644 > > > > > > > > > > > > > > > --- a/include/linux/virtio_config.h > > > > > > > > > > > > > > > +++ b/include/linux/virtio_config.h > > > > > > > > > > > > > > > @@ -174,6 +174,24 @@ static inline bool virtio_has_feature(const struct virtio_device *vdev, > > > > > > > > > > > > > > > return __virtio_test_bit(vdev, fbit); > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > +/* > > > > > > > > > > > > > > > + * virtio_irq_soft_enabled: whether we can execute callbacks > > > > > > > > > > > > > > > + * @vdev: the device > > > > > > > > > > > > > > > + */ > > > > > > > > > > > > > > > +static inline bool virtio_irq_soft_enabled(const struct virtio_device *vdev) > > > > > > > > > > > > > > > +{ > > > > > > > > > > > > > > > + if (!vdev->irq_soft_check) > > > > > > > > > > > > > > > + return true; > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > + /* > > > > > > > > > > > > > > > + * Read irq_soft_enabled before reading other device specific > > > > > > > > > > > > > > > + * data. Paried with smp_store_relase() in > > > > > > > > > > > > > > paired > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Will fix. > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + * virtio_device_ready() and WRITE_ONCE()/synchronize_rcu() in > > > > > > > > > > > > > > > + * virtio_reset_device(). > > > > > > > > > > > > > > > + */ > > > > > > > > > > > > > > > + return smp_load_acquire(&vdev->irq_soft_enabled); > > > > > > > > > > > > > > > +} > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > /** > > > > > > > > > > > > > > > * virtio_has_dma_quirk - determine whether this device has the DMA quirk > > > > > > > > > > > > > > > * @vdev: the device > > > > > > > > > > > > > > > @@ -236,6 +254,13 @@ void virtio_device_ready(struct virtio_device *dev) > > > > > > > > > > > > > > > if (dev->config->enable_cbs) > > > > > > > > > > > > > > > dev->config->enable_cbs(dev); > > > > > > > > > > > > > > > + /* > > > > > > > > > > > > > > > + * Commit the driver setup before enabling the virtqueue > > > > > > > > > > > > > > > + * callbacks. Paried with smp_load_acuqire() in > > > > > > > > > > > > > > > + * virtio_irq_soft_enabled() > > > > > > > > > > > > > > > + */ > > > > > > > > > > > > > > > + smp_store_release(&dev->irq_soft_enabled, true); > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > BUG_ON(status & VIRTIO_CONFIG_S_DRIVER_OK); > > > > > > > > > > > > > > > dev->config->set_status(dev, status | VIRTIO_CONFIG_S_DRIVER_OK); > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > 2.25.1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-03-30 5:14 ` Re: Michael S. Tsirkin @ 2022-03-30 5:53 ` Jason Wang 0 siblings, 0 replies; 1767+ messages in thread From: Jason Wang @ 2022-03-30 5:53 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Paul E. McKenney, Peter Zijlstra, Marc Zyngier, Keir Fraser, linux-kernel, virtualization, Thomas Gleixner On Wed, Mar 30, 2022 at 1:14 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > On Wed, Mar 30, 2022 at 10:40:59AM +0800, Jason Wang wrote: > > On Tue, Mar 29, 2022 at 10:09 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > On Tue, Mar 29, 2022 at 03:12:14PM +0800, Jason Wang wrote: > > > > > > > > > And requesting irq commits all memory otherwise all drivers would be > > > > > > > > > broken, > > > > > > > > > > > > > > > > So I think we might talk different issues: > > > > > > > > > > > > > > > > 1) Whether request_irq() commits the previous setups, I think the > > > > > > > > answer is yes, since the spin_unlock of desc->lock (release) can > > > > > > > > guarantee this though there seems no documentation around > > > > > > > > request_irq() to say this. > > > > > > > > > > > > > > > > And I can see at least drivers/video/fbdev/omap2/omapfb/dss/dispc.c is > > > > > > > > using smp_wmb() before the request_irq(). > > > > > > > > > > > > > > > > And even if write is ordered we still need read to be ordered to be > > > > > > > > paired with that. > > > > > > > > > > IMO it synchronizes with the CPU to which irq is > > > > > delivered. Otherwise basically all drivers would be broken, > > > > > wouldn't they be? > > > > > > > > I guess it's because most of the drivers don't care much about the > > > > buggy/malicious device. And most of the devices may require an extra > > > > step to enable device IRQ after request_irq(). Or it's the charge of > > > > the driver to do the synchronization. > > > > > > It is true that the use-case of malicious devices is somewhat boutique. > > > But I think most drivers do want to have their hotplug routines to be > > > robust, yes. > > > > > > > > I don't know whether it's correct on all platforms, but if not > > > > > we need to fix request_irq. > > > > > > > > > > > > > > > > > > > > > > if it doesn't it just needs to be fixed, not worked around in > > > > > > > > > virtio. > > > > > > > > > > > > > > > > 2) virtio drivers might do a lot of setups between request_irq() and > > > > > > > > virtio_device_ready(): > > > > > > > > > > > > > > > > request_irq() > > > > > > > > driver specific setups > > > > > > > > virtio_device_ready() > > > > > > > > > > > > > > > > CPU 0 probe) request_irq() > > > > > > > > CPU 1 IRQ handler) read the uninitialized variable > > > > > > > > CPU 0 probe) driver specific setups > > > > > > > > CPU 0 probe) smp_store_release(intr_soft_enabled, true), commit the setups > > > > > > > > CPU 1 IRQ handler) read irq_soft_enable as true > > > > > > > > CPU 1 IRQ handler) use the uninitialized variable > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > As I said, virtio_device_ready needs to do synchronize_irq. > > > > > > > That will guarantee all setup is visible to the specific IRQ, > > > > > > > > > > > > Only the interrupt after synchronize_irq() returns. > > > > > > > > > > Anything else is a buggy device though. > > > > > > > > Yes, but the goal of this patch is to prevent the possible attack from > > > > buggy(malicious) devices. > > > > > > Right. However if a driver of a *buggy* device somehow sees driver_ok = > > > false even though it's actually initialized, that is not a deal breaker > > > as that does not open us up to an attack. > > > > > > > > > > > > > > >this > > > > > > > is what it's point is. > > > > > > > > > > > > What happens if an interrupt is raised in the middle like: > > > > > > > > > > > > smp_store_release(dev->irq_soft_enabled, true) > > > > > > IRQ handler > > > > > > synchornize_irq() > > > > > > > > > > > > If we don't enforce a reading order, the IRQ handler may still see the > > > > > > uninitialized variable. > > > > > > > > > > > > Thanks > > > > > > > > > > IMHO variables should be initialized before request_irq > > > > > to a value meaning "not a valid interrupt". > > > > > Specifically driver_ok = false. > > > > > Handler in the scenario you describe will then see !driver_ok > > > > > and exit immediately. > > > > > > > > So just to make sure we're on the same page. > > > > > > > > 1) virtio_reset_device() will set the driver_ok to false; > > > > 2) virtio_device_ready() will set the driver_ok to true > > > > > > > > So for virtio drivers, it often did: > > > > > > > > 1) virtio_reset_device() > > > > 2) find_vqs() which will call request_irq() > > > > 3) other driver specific setups > > > > 4) virtio_device_ready() > > > > > > > > In virtio_device_ready(), the patch perform the following currently: > > > > > > > > smp_store_release(driver_ok, true); > > > > set_status(DRIVER_OK); > > > > > > > > Per your suggestion, to add synchronize_irq() after > > > > smp_store_release() so we had > > > > > > > > smp_store_release(driver_ok, true); > > > > synchornize_irq() > > > > set_status(DRIVER_OK) > > > > > > > > Suppose there's a interrupt raised before the synchronize_irq(), if we do: > > > > > > > > if (READ_ONCE(driver_ok)) { > > > > vq->callback() > > > > } > > > > > > > > It will see the driver_ok as true but how can we make sure > > > > vq->callback sees the driver specific setups (3) above? > > > > > > > > And an example is virtio_scsi(): > > > > > > > > virtio_reset_device() > > > > virtscsi_probe() > > > > virtscsi_init() > > > > virtio_find_vqs() > > > > ... > > > > virtscsi_init_vq(&vscsi->event_vq, vqs[1]) > > > > .... > > > > virtio_device_ready() > > > > > > > > In virtscsi_event_done(): > > > > > > > > virtscsi_event_done(): > > > > virtscsi_vq_done(vscsi, &vscsi->event_vq, ...); > > > > > > > > We need to make sure the even_done reads driver_ok before read vscsi->event_vq. > > > > > > > > Thanks > > > > > > > > > See response by Thomas. A simple if (!dev->driver_ok) should be enough, > > > it's all under a lock. > > > > Ordered through ACQUIRE+RELEASE actually since the irq handler is not > > running under the lock. > > > > Another question, for synchronize_irq() do you prefer > > > > 1) transport specific callbacks > > or > > 2) a simple synchornize_rcu() > > > > Thanks > > > 1) I think, and I'd add a wrapper so we can switch to 2 if we really > want to. But for now synchronizing the specific irq is obviously designed to > make any changes to memory visible to this irq. that > seems cleaner and easier to understand than memory ordering tricks > and relying on side effects of synchornize_rcu, even though > internally this all boils down to memory ordering since > memory is what's used to implement locks :). > Not to mention, synchronize_irq just scales much better from performance > POV. Ok. Let me try to do that in V2. Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We use smp_store_relase() > > > > > > > > > > > > to make sure the driver commits the setup before enabling the irq. It > > > > > > > > > > > > means the read needs to be ordered as well in vring_interrupt(). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Although I couldn't find anything about this in memory-barriers.txt > > > > > > > > > > > > > which surprises me. > > > > > > > > > > > > > > > > > > > > > > > > > > CC Paul to help make sure I'm right. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To avoid breaking legacy device which can send IRQ before DRIVER_OK, a > > > > > > > > > > > > > > > > module parameter is introduced to enable the hardening so function > > > > > > > > > > > > > > > > hardening is disabled by default. > > > > > > > > > > > > > > > Which devices are these? How come they send an interrupt before there > > > > > > > > > > > > > > > are any buffers in any queues? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I copied this from the commit log for 22b7050a024d7 > > > > > > > > > > > > > > > > > > > > > > > > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > > > > This change will also benefit old hypervisors (before 2009) > > > > > > > > > > > > > > that send interrupts without checking DRIVER_OK: previously, > > > > > > > > > > > > > > the callback could race with driver-specific initialization. > > > > > > > > > > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > > > > If this is only for config interrupt, I can remove the above log. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is only for config interrupt. > > > > > > > > > > > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Note that the hardening is only done for vring interrupt since the > > > > > > > > > > > > > > > > config interrupt hardening is already done in commit 22b7050a024d7 > > > > > > > > > > > > > > > > ("virtio: defer config changed notifications"). But the method that is > > > > > > > > > > > > > > > > used by config interrupt can't be reused by the vring interrupt > > > > > > > > > > > > > > > > handler because it uses spinlock to do the synchronization which is > > > > > > > > > > > > > > > > expensive. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Jason Wang <jasowang@redhat.com> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > drivers/virtio/virtio.c | 19 +++++++++++++++++++ > > > > > > > > > > > > > > > > drivers/virtio/virtio_ring.c | 9 ++++++++- > > > > > > > > > > > > > > > > include/linux/virtio.h | 4 ++++ > > > > > > > > > > > > > > > > include/linux/virtio_config.h | 25 +++++++++++++++++++++++++ > > > > > > > > > > > > > > > > 4 files changed, 56 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c > > > > > > > > > > > > > > > > index 8dde44ea044a..85e331efa9cc 100644 > > > > > > > > > > > > > > > > --- a/drivers/virtio/virtio.c > > > > > > > > > > > > > > > > +++ b/drivers/virtio/virtio.c > > > > > > > > > > > > > > > > @@ -7,6 +7,12 @@ > > > > > > > > > > > > > > > > #include <linux/of.h> > > > > > > > > > > > > > > > > #include <uapi/linux/virtio_ids.h> > > > > > > > > > > > > > > > > +static bool irq_hardening = false; > > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > > +module_param(irq_hardening, bool, 0444); > > > > > > > > > > > > > > > > +MODULE_PARM_DESC(irq_hardening, > > > > > > > > > > > > > > > > + "Disalbe IRQ software processing when it is not expected"); > > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > > /* Unique numbering for virtio devices. */ > > > > > > > > > > > > > > > > static DEFINE_IDA(virtio_index_ida); > > > > > > > > > > > > > > > > @@ -220,6 +226,15 @@ static int virtio_features_ok(struct virtio_device *dev) > > > > > > > > > > > > > > > > * */ > > > > > > > > > > > > > > > > void virtio_reset_device(struct virtio_device *dev) > > > > > > > > > > > > > > > > { > > > > > > > > > > > > > > > > + /* > > > > > > > > > > > > > > > > + * The below synchronize_rcu() guarantees that any > > > > > > > > > > > > > > > > + * interrupt for this line arriving after > > > > > > > > > > > > > > > > + * synchronize_rcu() has completed is guaranteed to see > > > > > > > > > > > > > > > > + * irq_soft_enabled == false. > > > > > > > > > > > > > > > News to me I did not know synchronize_rcu has anything to do > > > > > > > > > > > > > > > with interrupts. Did not you intend to use synchronize_irq? > > > > > > > > > > > > > > > I am not even 100% sure synchronize_rcu is by design a memory barrier > > > > > > > > > > > > > > > though it's most likely is ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > According to the comment above tree RCU version of synchronize_rcu(): > > > > > > > > > > > > > > > > > > > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > > > > > > > > > > > * RCU read-side critical sections are delimited by rcu_read_lock() > > > > > > > > > > > > > > * and rcu_read_unlock(), and may be nested. In addition, but only in > > > > > > > > > > > > > > * v5.0 and later, regions of code across which interrupts, preemption, > > > > > > > > > > > > > > * or softirqs have been disabled also serve as RCU read-side critical > > > > > > > > > > > > > > * sections. This includes hardware interrupt handlers, softirq handlers, > > > > > > > > > > > > > > * and NMI handlers. > > > > > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > > > > > > > > > > > So interrupt handlers are treated as read-side critical sections. > > > > > > > > > > > > > > > > > > > > > > > > > > > > And it has the comment for explain the barrier: > > > > > > > > > > > > > > > > > > > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > > > > > > > > > > > * Note that this guarantee implies further memory-ordering guarantees. > > > > > > > > > > > > > > * On systems with more than one CPU, when synchronize_rcu() returns, > > > > > > > > > > > > > > * each CPU is guaranteed to have executed a full memory barrier since > > > > > > > > > > > > > > * the end of its last RCU read-side critical section whose beginning > > > > > > > > > > > > > > * preceded the call to synchronize_rcu(). In addition, each CPU having > > > > > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > > > > > > > > > > > So on SMP it provides a full barrier. And for UP/tiny RCU we don't need the > > > > > > > > > > > > > > barrier, if the interrupt come after WRITE_ONCE() it will see the > > > > > > > > > > > > > > irq_soft_enabled as false. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You are right. So then > > > > > > > > > > > > > 1. I do not think we need load_acquire - why is it needed? Just > > > > > > > > > > > > > READ_ONCE should do. > > > > > > > > > > > > > > > > > > > > > > > > See above. > > > > > > > > > > > > > > > > > > > > > > > > > 2. isn't synchronize_irq also doing the same thing? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, but it requires a config ops since the IRQ knowledge is transport specific. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + */ > > > > > > > > > > > > > > > > + WRITE_ONCE(dev->irq_soft_enabled, false); > > > > > > > > > > > > > > > > + synchronize_rcu(); > > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > > dev->config->reset(dev); > > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > EXPORT_SYMBOL_GPL(virtio_reset_device); > > > > > > > > > > > > > > > Please add comment explaining where it will be enabled. > > > > > > > > > > > > > > > Also, we *really* don't need to synch if it was already disabled, > > > > > > > > > > > > > > > let's not add useless overhead to the boot sequence. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > @@ -427,6 +442,10 @@ int register_virtio_device(struct virtio_device *dev) > > > > > > > > > > > > > > > > spin_lock_init(&dev->config_lock); > > > > > > > > > > > > > > > > dev->config_enabled = false; > > > > > > > > > > > > > > > > dev->config_change_pending = false; > > > > > > > > > > > > > > > > + dev->irq_soft_check = irq_hardening; > > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > > + if (dev->irq_soft_check) > > > > > > > > > > > > > > > > + dev_info(&dev->dev, "IRQ hardening is enabled\n"); > > > > > > > > > > > > > > > > /* We always start by resetting the device, in case a previous > > > > > > > > > > > > > > > > * driver messed it up. This also tests that code path a little. */ > > > > > > > > > > > > > > > one of the points of hardening is it's also helpful for buggy > > > > > > > > > > > > > > > devices. this flag defeats the purpose. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do you mean: > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) we need something like config_enable? This seems not easy to be > > > > > > > > > > > > > > implemented without obvious overhead, mainly the synchronize with the > > > > > > > > > > > > > > interrupt handlers > > > > > > > > > > > > > > > > > > > > > > > > > > But synchronize is only on tear-down path. That is not critical for any > > > > > > > > > > > > > users at the moment, even less than probe. > > > > > > > > > > > > > > > > > > > > > > > > I meant if we have vq->irq_pending, we need to call vring_interrupt() > > > > > > > > > > > > in the virtio_device_ready() and synchronize the IRQ handlers with > > > > > > > > > > > > spinlock or others. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) enable this by default, so I don't object, but this may have some risk > > > > > > > > > > > > > > for old hypervisors > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The risk if there's a driver adding buffers without setting DRIVER_OK. > > > > > > > > > > > > > > > > > > > > > > > > Probably not, we have devices that accept random inputs from outside, > > > > > > > > > > > > net, console, input etc. I've done a round of audits of the Qemu > > > > > > > > > > > > codes. They look all fine since day0. > > > > > > > > > > > > > > > > > > > > > > > > > So with this approach, how about we rename the flag "driver_ok"? > > > > > > > > > > > > > And then add_buf can actually test it and BUG_ON if not there (at least > > > > > > > > > > > > > in the debug build). > > > > > > > > > > > > > > > > > > > > > > > > This looks like a hardening of the driver in the core instead of the > > > > > > > > > > > > device. I think it can be done but in a separate series. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And going down from there, how about we cache status in the > > > > > > > > > > > > > device? Then we don't need to keep re-reading it every time, > > > > > > > > > > > > > speeding boot up a tiny bit. > > > > > > > > > > > > > > > > > > > > > > > > I don't fully understand here, actually spec requires status to be > > > > > > > > > > > > read back for validation in many cases. > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > > > > > > > > > > > > > > > index 962f1477b1fa..0170f8c784d8 100644 > > > > > > > > > > > > > > > > --- a/drivers/virtio/virtio_ring.c > > > > > > > > > > > > > > > > +++ b/drivers/virtio/virtio_ring.c > > > > > > > > > > > > > > > > @@ -2144,10 +2144,17 @@ static inline bool more_used(const struct vring_virtqueue *vq) > > > > > > > > > > > > > > > > return vq->packed_ring ? more_used_packed(vq) : more_used_split(vq); > > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > -irqreturn_t vring_interrupt(int irq, void *_vq) > > > > > > > > > > > > > > > > +irqreturn_t vring_interrupt(int irq, void *v) > > > > > > > > > > > > > > > > { > > > > > > > > > > > > > > > > + struct virtqueue *_vq = v; > > > > > > > > > > > > > > > > + struct virtio_device *vdev = _vq->vdev; > > > > > > > > > > > > > > > > struct vring_virtqueue *vq = to_vvq(_vq); > > > > > > > > > > > > > > > > + if (!virtio_irq_soft_enabled(vdev)) { > > > > > > > > > > > > > > > > + dev_warn_once(&vdev->dev, "virtio vring IRQ raised before DRIVER_OK"); > > > > > > > > > > > > > > > > + return IRQ_NONE; > > > > > > > > > > > > > > > > + } > > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > > if (!more_used(vq)) { > > > > > > > > > > > > > > > > pr_debug("virtqueue interrupt with no work for %p\n", vq); > > > > > > > > > > > > > > > > return IRQ_NONE; > > > > > > > > > > > > > > > > diff --git a/include/linux/virtio.h b/include/linux/virtio.h > > > > > > > > > > > > > > > > index 5464f398912a..957d6ad604ac 100644 > > > > > > > > > > > > > > > > --- a/include/linux/virtio.h > > > > > > > > > > > > > > > > +++ b/include/linux/virtio.h > > > > > > > > > > > > > > > > @@ -95,6 +95,8 @@ dma_addr_t virtqueue_get_used_addr(struct virtqueue *vq); > > > > > > > > > > > > > > > > * @failed: saved value for VIRTIO_CONFIG_S_FAILED bit (for restore) > > > > > > > > > > > > > > > > * @config_enabled: configuration change reporting enabled > > > > > > > > > > > > > > > > * @config_change_pending: configuration change reported while disabled > > > > > > > > > > > > > > > > + * @irq_soft_check: whether or not to check @irq_soft_enabled > > > > > > > > > > > > > > > > + * @irq_soft_enabled: callbacks enabled > > > > > > > > > > > > > > > > * @config_lock: protects configuration change reporting > > > > > > > > > > > > > > > > * @dev: underlying device. > > > > > > > > > > > > > > > > * @id: the device type identification (used to match it with a driver). > > > > > > > > > > > > > > > > @@ -109,6 +111,8 @@ struct virtio_device { > > > > > > > > > > > > > > > > bool failed; > > > > > > > > > > > > > > > > bool config_enabled; > > > > > > > > > > > > > > > > bool config_change_pending; > > > > > > > > > > > > > > > > + bool irq_soft_check; > > > > > > > > > > > > > > > > + bool irq_soft_enabled; > > > > > > > > > > > > > > > > spinlock_t config_lock; > > > > > > > > > > > > > > > > spinlock_t vqs_list_lock; /* Protects VQs list access */ > > > > > > > > > > > > > > > > struct device dev; > > > > > > > > > > > > > > > > diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h > > > > > > > > > > > > > > > > index dafdc7f48c01..9c1b61f2e525 100644 > > > > > > > > > > > > > > > > --- a/include/linux/virtio_config.h > > > > > > > > > > > > > > > > +++ b/include/linux/virtio_config.h > > > > > > > > > > > > > > > > @@ -174,6 +174,24 @@ static inline bool virtio_has_feature(const struct virtio_device *vdev, > > > > > > > > > > > > > > > > return __virtio_test_bit(vdev, fbit); > > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > +/* > > > > > > > > > > > > > > > > + * virtio_irq_soft_enabled: whether we can execute callbacks > > > > > > > > > > > > > > > > + * @vdev: the device > > > > > > > > > > > > > > > > + */ > > > > > > > > > > > > > > > > +static inline bool virtio_irq_soft_enabled(const struct virtio_device *vdev) > > > > > > > > > > > > > > > > +{ > > > > > > > > > > > > > > > > + if (!vdev->irq_soft_check) > > > > > > > > > > > > > > > > + return true; > > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > > + /* > > > > > > > > > > > > > > > > + * Read irq_soft_enabled before reading other device specific > > > > > > > > > > > > > > > > + * data. Paried with smp_store_relase() in > > > > > > > > > > > > > > > paired > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Will fix. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + * virtio_device_ready() and WRITE_ONCE()/synchronize_rcu() in > > > > > > > > > > > > > > > > + * virtio_reset_device(). > > > > > > > > > > > > > > > > + */ > > > > > > > > > > > > > > > > + return smp_load_acquire(&vdev->irq_soft_enabled); > > > > > > > > > > > > > > > > +} > > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > > /** > > > > > > > > > > > > > > > > * virtio_has_dma_quirk - determine whether this device has the DMA quirk > > > > > > > > > > > > > > > > * @vdev: the device > > > > > > > > > > > > > > > > @@ -236,6 +254,13 @@ void virtio_device_ready(struct virtio_device *dev) > > > > > > > > > > > > > > > > if (dev->config->enable_cbs) > > > > > > > > > > > > > > > > dev->config->enable_cbs(dev); > > > > > > > > > > > > > > > > + /* > > > > > > > > > > > > > > > > + * Commit the driver setup before enabling the virtqueue > > > > > > > > > > > > > > > > + * callbacks. Paried with smp_load_acuqire() in > > > > > > > > > > > > > > > > + * virtio_irq_soft_enabled() > > > > > > > > > > > > > > > > + */ > > > > > > > > > > > > > > > > + smp_store_release(&dev->irq_soft_enabled, true); > > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > > BUG_ON(status & VIRTIO_CONFIG_S_DRIVER_OK); > > > > > > > > > > > > > > > > dev->config->set_status(dev, status | VIRTIO_CONFIG_S_DRIVER_OK); > > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > 2.25.1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-03-28 10:40 ` Re: Michael S. Tsirkin 2022-03-29 7:12 ` Re: Jason Wang @ 2022-03-29 8:35 ` Thomas Gleixner 2022-03-29 14:37 ` Re: Michael S. Tsirkin 2022-04-12 6:55 ` Re: Michael S. Tsirkin 1 sibling, 2 replies; 1767+ messages in thread From: Thomas Gleixner @ 2022-03-29 8:35 UTC (permalink / raw) To: Michael S. Tsirkin, Jason Wang Cc: Paul E. McKenney, Peter Zijlstra, Marc Zyngier, Keir Fraser, linux-kernel, virtualization On Mon, Mar 28 2022 at 06:40, Michael S. Tsirkin wrote: > On Mon, Mar 28, 2022 at 02:18:22PM +0800, Jason Wang wrote: >> > > So I think we might talk different issues: >> > > >> > > 1) Whether request_irq() commits the previous setups, I think the >> > > answer is yes, since the spin_unlock of desc->lock (release) can >> > > guarantee this though there seems no documentation around >> > > request_irq() to say this. >> > > >> > > And I can see at least drivers/video/fbdev/omap2/omapfb/dss/dispc.c is >> > > using smp_wmb() before the request_irq(). That's a complete bogus example especially as there is not a single smp_rmb() which pairs with the smp_wmb(). >> > > And even if write is ordered we still need read to be ordered to be >> > > paired with that. > > IMO it synchronizes with the CPU to which irq is > delivered. Otherwise basically all drivers would be broken, > wouldn't they be? > I don't know whether it's correct on all platforms, but if not > we need to fix request_irq. There is nothing to fix: request_irq() raw_spin_lock_irq(desc->lock); // ACQUIRE .... raw_spin_unlock_irq(desc->lock); // RELEASE interrupt() raw_spin_lock(desc->lock); // ACQUIRE set status to IN_PROGRESS raw_spin_unlock(desc->lock); // RELEASE invoke handler() So anything which the driver set up _before_ request_irq() is visible to the interrupt handler. No? >> What happens if an interrupt is raised in the middle like: >> >> smp_store_release(dev->irq_soft_enabled, true) >> IRQ handler >> synchornize_irq() This is bogus. The obvious order of things is: dev->ok = false; request_irq(); moar_setup(); synchronize_irq(); // ACQUIRE + RELEASE dev->ok = true; The reverse operation on teardown: dev->ok = false; synchronize_irq(); // ACQUIRE + RELEASE teardown(); So in both cases a simple check in the handler is sufficient: handler() if (!dev->ok) return; I'm not understanding what you folks are trying to "fix" here. If any driver does this in the wrong order, then the driver is broken. Sure, you can do the same with: dev->ok = false; request_irq(); moar_setup(); smp_wmb(); dev->ok = true; for the price of a smp_rmb() in the interrupt handler: handler() if (!dev->ok) return; smp_rmb(); but that's only working for the setup case correctly and not for teardown. Thanks, tglx _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-03-29 8:35 ` Re: Thomas Gleixner @ 2022-03-29 14:37 ` Michael S. Tsirkin 2022-03-29 18:13 ` Re: Thomas Gleixner 2022-04-12 6:55 ` Re: Michael S. Tsirkin 1 sibling, 1 reply; 1767+ messages in thread From: Michael S. Tsirkin @ 2022-03-29 14:37 UTC (permalink / raw) To: Thomas Gleixner Cc: Paul E. McKenney, Peter Zijlstra, Marc Zyngier, Keir Fraser, linux-kernel, virtualization On Tue, Mar 29, 2022 at 10:35:21AM +0200, Thomas Gleixner wrote: > On Mon, Mar 28 2022 at 06:40, Michael S. Tsirkin wrote: > > On Mon, Mar 28, 2022 at 02:18:22PM +0800, Jason Wang wrote: > >> > > So I think we might talk different issues: > >> > > > >> > > 1) Whether request_irq() commits the previous setups, I think the > >> > > answer is yes, since the spin_unlock of desc->lock (release) can > >> > > guarantee this though there seems no documentation around > >> > > request_irq() to say this. > >> > > > >> > > And I can see at least drivers/video/fbdev/omap2/omapfb/dss/dispc.c is > >> > > using smp_wmb() before the request_irq(). > > That's a complete bogus example especially as there is not a single > smp_rmb() which pairs with the smp_wmb(). > > >> > > And even if write is ordered we still need read to be ordered to be > >> > > paired with that. > > > > IMO it synchronizes with the CPU to which irq is > > delivered. Otherwise basically all drivers would be broken, > > wouldn't they be? > > I don't know whether it's correct on all platforms, but if not > > we need to fix request_irq. > > There is nothing to fix: > > request_irq() > raw_spin_lock_irq(desc->lock); // ACQUIRE > .... > raw_spin_unlock_irq(desc->lock); // RELEASE > > interrupt() > raw_spin_lock(desc->lock); // ACQUIRE > set status to IN_PROGRESS > raw_spin_unlock(desc->lock); // RELEASE > invoke handler() > > So anything which the driver set up _before_ request_irq() is visible to > the interrupt handler. No? > >> What happens if an interrupt is raised in the middle like: > >> > >> smp_store_release(dev->irq_soft_enabled, true) > >> IRQ handler > >> synchornize_irq() > > This is bogus. The obvious order of things is: > > dev->ok = false; > request_irq(); > > moar_setup(); > synchronize_irq(); // ACQUIRE + RELEASE > dev->ok = true; > > The reverse operation on teardown: > > dev->ok = false; > synchronize_irq(); // ACQUIRE + RELEASE > > teardown(); > > So in both cases a simple check in the handler is sufficient: > > handler() > if (!dev->ok) > return; Thanks a lot for the analysis Thomas. This is more or less what I was thinking. > > I'm not understanding what you folks are trying to "fix" here. We are trying to fix the driver since at the moment it does not have the dev->ok flag at all. And I suspect virtio is not alone in that. So it would have been nice if there was a standard flag replacing the driver-specific dev->ok above, and ideally would also handle the case of an interrupt triggering too early by deferring the interrupt until the flag is set. And in fact, it does kind of exist: IRQF_NO_AUTOEN, and you would call enable_irq instead of dev->ok = true, except - it doesn't work with affinity managed IRQs - it does not work with shared IRQs So using dev->ok as you propose above seems better at this point. > If any > driver does this in the wrong order, then the driver is broken. I agree, however: $ git grep synchronize_irq `git grep -l request_irq drivers/net/`|wc -l 113 $ git grep -l request_irq drivers/net/|wc -l 397 I suspect there are more drivers which in theory need the synchronize_irq dance but in practice do not execute it. > Sure, you can do the same with: > > dev->ok = false; > request_irq(); > moar_setup(); > smp_wmb(); > dev->ok = true; > > for the price of a smp_rmb() in the interrupt handler: > > handler() > if (!dev->ok) > return; > smp_rmb(); > > but that's only working for the setup case correctly and not for > teardown. > > Thanks, > > tglx _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-03-29 14:37 ` Re: Michael S. Tsirkin @ 2022-03-29 18:13 ` Thomas Gleixner 2022-03-29 22:04 ` Re: Michael S. Tsirkin 0 siblings, 1 reply; 1767+ messages in thread From: Thomas Gleixner @ 2022-03-29 18:13 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Paul E. McKenney, Peter Zijlstra, Marc Zyngier, Keir Fraser, linux-kernel, virtualization On Tue, Mar 29 2022 at 10:37, Michael S. Tsirkin wrote: > On Tue, Mar 29, 2022 at 10:35:21AM +0200, Thomas Gleixner wrote: > We are trying to fix the driver since at the moment it does not > have the dev->ok flag at all. > > And I suspect virtio is not alone in that. > So it would have been nice if there was a standard flag > replacing the driver-specific dev->ok above, and ideally > would also handle the case of an interrupt triggering > too early by deferring the interrupt until the flag is set. > > And in fact, it does kind of exist: IRQF_NO_AUTOEN, and you would call > enable_irq instead of dev->ok = true, except > - it doesn't work with affinity managed IRQs > - it does not work with shared IRQs > > So using dev->ok as you propose above seems better at this point. Unless there is a big enough amount of drivers which could make use of a generic mechanism for that. >> If any driver does this in the wrong order, then the driver is >> broken. > > I agree, however: > $ git grep synchronize_irq `git grep -l request_irq drivers/net/`|wc -l > 113 > $ git grep -l request_irq drivers/net/|wc -l > 397 > > I suspect there are more drivers which in theory need the > synchronize_irq dance but in practice do not execute it. That really depends on when the driver requests the interrupt, when it actually enables the interrupt in the device itself and how the interrupt service routine works. So just doing that grep dance does not tell much. You really have to do a case by case analysis. Thanks, tglx _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-03-29 18:13 ` Re: Thomas Gleixner @ 2022-03-29 22:04 ` Michael S. Tsirkin 2022-03-30 2:38 ` Re: Jason Wang 0 siblings, 1 reply; 1767+ messages in thread From: Michael S. Tsirkin @ 2022-03-29 22:04 UTC (permalink / raw) To: Thomas Gleixner Cc: Paul E. McKenney, Peter Zijlstra, Marc Zyngier, Keir Fraser, linux-kernel, virtualization On Tue, Mar 29, 2022 at 08:13:57PM +0200, Thomas Gleixner wrote: > On Tue, Mar 29 2022 at 10:37, Michael S. Tsirkin wrote: > > On Tue, Mar 29, 2022 at 10:35:21AM +0200, Thomas Gleixner wrote: > > We are trying to fix the driver since at the moment it does not > > have the dev->ok flag at all. > > > > And I suspect virtio is not alone in that. > > So it would have been nice if there was a standard flag > > replacing the driver-specific dev->ok above, and ideally > > would also handle the case of an interrupt triggering > > too early by deferring the interrupt until the flag is set. > > > > And in fact, it does kind of exist: IRQF_NO_AUTOEN, and you would call > > enable_irq instead of dev->ok = true, except > > - it doesn't work with affinity managed IRQs > > - it does not work with shared IRQs > > > > So using dev->ok as you propose above seems better at this point. > > Unless there is a big enough amount of drivers which could make use of a > generic mechanism for that. > > >> If any driver does this in the wrong order, then the driver is > >> broken. > > > > I agree, however: > > $ git grep synchronize_irq `git grep -l request_irq drivers/net/`|wc -l > > 113 > > $ git grep -l request_irq drivers/net/|wc -l > > 397 > > > > I suspect there are more drivers which in theory need the > > synchronize_irq dance but in practice do not execute it. > > That really depends on when the driver requests the interrupt, when > it actually enables the interrupt in the device itself This last point does not matter since we are talking about protecting against buggy/malicious devices. They can inject the interrupt anyway even if driver did not configure it. > and how the > interrupt service routine works. > > So just doing that grep dance does not tell much. You really have to do > a case by case analysis. > > Thanks, > > tglx I agree. In fact, at least for network the standard approach is to request interrupts in the open call, virtio net is unusual in doing it in probe. We should consider changing that. Jason? -- MST _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-03-29 22:04 ` Re: Michael S. Tsirkin @ 2022-03-30 2:38 ` Jason Wang 2022-03-30 5:09 ` Re: Michael S. Tsirkin 0 siblings, 1 reply; 1767+ messages in thread From: Jason Wang @ 2022-03-30 2:38 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Paul E. McKenney, Peter Zijlstra, Marc Zyngier, Keir Fraser, linux-kernel, virtualization, Thomas Gleixner On Wed, Mar 30, 2022 at 6:04 AM Michael S. Tsirkin <mst@redhat.com> wrote: > > On Tue, Mar 29, 2022 at 08:13:57PM +0200, Thomas Gleixner wrote: > > On Tue, Mar 29 2022 at 10:37, Michael S. Tsirkin wrote: > > > On Tue, Mar 29, 2022 at 10:35:21AM +0200, Thomas Gleixner wrote: > > > We are trying to fix the driver since at the moment it does not > > > have the dev->ok flag at all. > > > > > > And I suspect virtio is not alone in that. > > > So it would have been nice if there was a standard flag > > > replacing the driver-specific dev->ok above, and ideally > > > would also handle the case of an interrupt triggering > > > too early by deferring the interrupt until the flag is set. > > > > > > And in fact, it does kind of exist: IRQF_NO_AUTOEN, and you would call > > > enable_irq instead of dev->ok = true, except > > > - it doesn't work with affinity managed IRQs > > > - it does not work with shared IRQs > > > > > > So using dev->ok as you propose above seems better at this point. > > > > Unless there is a big enough amount of drivers which could make use of a > > generic mechanism for that. > > > > >> If any driver does this in the wrong order, then the driver is > > >> broken. > > > > > > I agree, however: > > > $ git grep synchronize_irq `git grep -l request_irq drivers/net/`|wc -l > > > 113 > > > $ git grep -l request_irq drivers/net/|wc -l > > > 397 > > > > > > I suspect there are more drivers which in theory need the > > > synchronize_irq dance but in practice do not execute it. > > > > That really depends on when the driver requests the interrupt, when > > it actually enables the interrupt in the device itself > > This last point does not matter since we are talking about protecting > against buggy/malicious devices. They can inject the interrupt anyway > even if driver did not configure it. > > > and how the > > interrupt service routine works. > > > > So just doing that grep dance does not tell much. You really have to do > > a case by case analysis. > > > > Thanks, > > > > tglx > > > I agree. In fact, at least for network the standard approach is to > request interrupts in the open call, virtio net is unusual > in doing it in probe. We should consider changing that. > Jason? This probably works only for virtio-net and it looks like not trivial since we don't have a specific core API to request interrupts. Thanks > > -- > MST > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-03-30 2:38 ` Re: Jason Wang @ 2022-03-30 5:09 ` Michael S. Tsirkin 2022-03-30 5:53 ` Re: Jason Wang 0 siblings, 1 reply; 1767+ messages in thread From: Michael S. Tsirkin @ 2022-03-30 5:09 UTC (permalink / raw) To: Jason Wang Cc: Paul E. McKenney, Peter Zijlstra, Marc Zyngier, Keir Fraser, linux-kernel, virtualization, Thomas Gleixner On Wed, Mar 30, 2022 at 10:38:06AM +0800, Jason Wang wrote: > On Wed, Mar 30, 2022 at 6:04 AM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > On Tue, Mar 29, 2022 at 08:13:57PM +0200, Thomas Gleixner wrote: > > > On Tue, Mar 29 2022 at 10:37, Michael S. Tsirkin wrote: > > > > On Tue, Mar 29, 2022 at 10:35:21AM +0200, Thomas Gleixner wrote: > > > > We are trying to fix the driver since at the moment it does not > > > > have the dev->ok flag at all. > > > > > > > > And I suspect virtio is not alone in that. > > > > So it would have been nice if there was a standard flag > > > > replacing the driver-specific dev->ok above, and ideally > > > > would also handle the case of an interrupt triggering > > > > too early by deferring the interrupt until the flag is set. > > > > > > > > And in fact, it does kind of exist: IRQF_NO_AUTOEN, and you would call > > > > enable_irq instead of dev->ok = true, except > > > > - it doesn't work with affinity managed IRQs > > > > - it does not work with shared IRQs > > > > > > > > So using dev->ok as you propose above seems better at this point. > > > > > > Unless there is a big enough amount of drivers which could make use of a > > > generic mechanism for that. > > > > > > >> If any driver does this in the wrong order, then the driver is > > > >> broken. > > > > > > > > I agree, however: > > > > $ git grep synchronize_irq `git grep -l request_irq drivers/net/`|wc -l > > > > 113 > > > > $ git grep -l request_irq drivers/net/|wc -l > > > > 397 > > > > > > > > I suspect there are more drivers which in theory need the > > > > synchronize_irq dance but in practice do not execute it. > > > > > > That really depends on when the driver requests the interrupt, when > > > it actually enables the interrupt in the device itself > > > > This last point does not matter since we are talking about protecting > > against buggy/malicious devices. They can inject the interrupt anyway > > even if driver did not configure it. > > > > > and how the > > > interrupt service routine works. > > > > > > So just doing that grep dance does not tell much. You really have to do > > > a case by case analysis. > > > > > > Thanks, > > > > > > tglx > > > > > > I agree. In fact, at least for network the standard approach is to > > request interrupts in the open call, virtio net is unusual > > in doing it in probe. We should consider changing that. > > Jason? > > This probably works only for virtio-net and it looks like not trivial > since we don't have a specific core API to request interrupts. > > Thanks We'll need a new API, for sure. E.g. find vqs with no callback on probe, and then virtio_request_vq_callbacks separately. The existing API that specifies callbacks during find vqs can be used by other drivers. > > > > -- > > MST > > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-03-30 5:09 ` Re: Michael S. Tsirkin @ 2022-03-30 5:53 ` Jason Wang 0 siblings, 0 replies; 1767+ messages in thread From: Jason Wang @ 2022-03-30 5:53 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Paul E. McKenney, Peter Zijlstra, Marc Zyngier, Keir Fraser, linux-kernel, virtualization, Thomas Gleixner On Wed, Mar 30, 2022 at 1:09 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > On Wed, Mar 30, 2022 at 10:38:06AM +0800, Jason Wang wrote: > > On Wed, Mar 30, 2022 at 6:04 AM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > On Tue, Mar 29, 2022 at 08:13:57PM +0200, Thomas Gleixner wrote: > > > > On Tue, Mar 29 2022 at 10:37, Michael S. Tsirkin wrote: > > > > > On Tue, Mar 29, 2022 at 10:35:21AM +0200, Thomas Gleixner wrote: > > > > > We are trying to fix the driver since at the moment it does not > > > > > have the dev->ok flag at all. > > > > > > > > > > And I suspect virtio is not alone in that. > > > > > So it would have been nice if there was a standard flag > > > > > replacing the driver-specific dev->ok above, and ideally > > > > > would also handle the case of an interrupt triggering > > > > > too early by deferring the interrupt until the flag is set. > > > > > > > > > > And in fact, it does kind of exist: IRQF_NO_AUTOEN, and you would call > > > > > enable_irq instead of dev->ok = true, except > > > > > - it doesn't work with affinity managed IRQs > > > > > - it does not work with shared IRQs > > > > > > > > > > So using dev->ok as you propose above seems better at this point. > > > > > > > > Unless there is a big enough amount of drivers which could make use of a > > > > generic mechanism for that. > > > > > > > > >> If any driver does this in the wrong order, then the driver is > > > > >> broken. > > > > > > > > > > I agree, however: > > > > > $ git grep synchronize_irq `git grep -l request_irq drivers/net/`|wc -l > > > > > 113 > > > > > $ git grep -l request_irq drivers/net/|wc -l > > > > > 397 > > > > > > > > > > I suspect there are more drivers which in theory need the > > > > > synchronize_irq dance but in practice do not execute it. > > > > > > > > That really depends on when the driver requests the interrupt, when > > > > it actually enables the interrupt in the device itself > > > > > > This last point does not matter since we are talking about protecting > > > against buggy/malicious devices. They can inject the interrupt anyway > > > even if driver did not configure it. > > > > > > > and how the > > > > interrupt service routine works. > > > > > > > > So just doing that grep dance does not tell much. You really have to do > > > > a case by case analysis. > > > > > > > > Thanks, > > > > > > > > tglx > > > > > > > > > I agree. In fact, at least for network the standard approach is to > > > request interrupts in the open call, virtio net is unusual > > > in doing it in probe. We should consider changing that. > > > Jason? > > > > This probably works only for virtio-net and it looks like not trivial > > since we don't have a specific core API to request interrupts. > > > > Thanks > > We'll need a new API, for sure. E.g. find vqs with no > callback on probe, and then virtio_request_vq_callbacks separately. > > The existing API that specifies callbacks during find vqs > can be used by other drivers. Ok, I will do it. Thanks > > > > > > > -- > > > MST > > > > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-03-29 8:35 ` Re: Thomas Gleixner 2022-03-29 14:37 ` Re: Michael S. Tsirkin @ 2022-04-12 6:55 ` Michael S. Tsirkin 1 sibling, 0 replies; 1767+ messages in thread From: Michael S. Tsirkin @ 2022-04-12 6:55 UTC (permalink / raw) To: Thomas Gleixner Cc: Paul E. McKenney, Peter Zijlstra, Marc Zyngier, Keir Fraser, linux-kernel, virtualization On Tue, Mar 29, 2022 at 10:35:21AM +0200, Thomas Gleixner wrote: > On Mon, Mar 28 2022 at 06:40, Michael S. Tsirkin wrote: > > On Mon, Mar 28, 2022 at 02:18:22PM +0800, Jason Wang wrote: > >> > > So I think we might talk different issues: > >> > > > >> > > 1) Whether request_irq() commits the previous setups, I think the > >> > > answer is yes, since the spin_unlock of desc->lock (release) can > >> > > guarantee this though there seems no documentation around > >> > > request_irq() to say this. > >> > > > >> > > And I can see at least drivers/video/fbdev/omap2/omapfb/dss/dispc.c is > >> > > using smp_wmb() before the request_irq(). > > That's a complete bogus example especially as there is not a single > smp_rmb() which pairs with the smp_wmb(). > > >> > > And even if write is ordered we still need read to be ordered to be > >> > > paired with that. > > > > IMO it synchronizes with the CPU to which irq is > > delivered. Otherwise basically all drivers would be broken, > > wouldn't they be? > > I don't know whether it's correct on all platforms, but if not > > we need to fix request_irq. > > There is nothing to fix: > > request_irq() > raw_spin_lock_irq(desc->lock); // ACQUIRE > .... > raw_spin_unlock_irq(desc->lock); // RELEASE > > interrupt() > raw_spin_lock(desc->lock); // ACQUIRE > set status to IN_PROGRESS > raw_spin_unlock(desc->lock); // RELEASE > invoke handler() > > So anything which the driver set up _before_ request_irq() is visible to > the interrupt handler. No? > > >> What happens if an interrupt is raised in the middle like: > >> > >> smp_store_release(dev->irq_soft_enabled, true) > >> IRQ handler > >> synchornize_irq() > > This is bogus. The obvious order of things is: > > dev->ok = false; > request_irq(); > > moar_setup(); > synchronize_irq(); // ACQUIRE + RELEASE > dev->ok = true; > > The reverse operation on teardown: > > dev->ok = false; > synchronize_irq(); // ACQUIRE + RELEASE > > teardown(); > > So in both cases a simple check in the handler is sufficient: > > handler() > if (!dev->ok) > return; Does this need to be if (!READ_ONCE(dev->ok)) ? > I'm not understanding what you folks are trying to "fix" here. If any > driver does this in the wrong order, then the driver is broken. > > Sure, you can do the same with: > > dev->ok = false; > request_irq(); > moar_setup(); > smp_wmb(); > dev->ok = true; > > for the price of a smp_rmb() in the interrupt handler: > > handler() > if (!dev->ok) > return; > smp_rmb(); > > but that's only working for the setup case correctly and not for > teardown. > > Thanks, > > tglx _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <20220301070226.2477769-1-jaydeepjd.8914>]
* (no subject) [not found] <20220301070226.2477769-1-jaydeepjd.8914> @ 2022-03-06 11:10 ` Jaydeep P Das 2022-03-06 11:22 ` Jaydeep Das 0 siblings, 1 reply; 1767+ messages in thread From: Jaydeep P Das @ 2022-03-06 11:10 UTC (permalink / raw) To: git This patch removes the previously implemented regex for matching method calls and adds a new regex for specially matching floating numbers starting with a decimal point. Added some more compound operators and their tests. -- Thanks :-] Jaydeep ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-03-06 11:10 ` Jaydeep P Das @ 2022-03-06 11:22 ` Jaydeep Das 0 siblings, 0 replies; 1767+ messages in thread From: Jaydeep Das @ 2022-03-06 11:22 UTC (permalink / raw) To: git Please ignore this patch. I think I made some mistake when copy-pasting the In-reply-to code. Sorry for the trouble. I have sent this same patch on the appropriate thread. Thanks, Jaydeep. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2022-03-04 8:47 Harald Hauge 0 siblings, 0 replies; 1767+ messages in thread From: Harald Hauge @ 2022-03-04 8:47 UTC (permalink / raw) To: bpf Hello, I'm Harald Hauge, an Investment Manager from Norway. I will your assistance in executing this Business from my country to yours. This is a short term investment with good returns. Kindly reply to confirm the validity of your email so I can give you comprehensive details about the project. Best Regards, Harald Hauge Business Consultant ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2022-02-13 22:40 Ronnie Sahlberg
2022-02-14 7:52 ` ronnie sahlberg
0 siblings, 1 reply; 1767+ messages in thread
From: Ronnie Sahlberg @ 2022-02-13 22:40 UTC (permalink / raw)
To: linux-cifs; +Cc: Steve French
Steve, List,
Here is a small patch htat fixes an issue with modefromsid where
it would strip off and remove all the ACEs that grants us access to the file.
It fixes this by restoring the "allow AuthenticatedUsers access" ACE that is stripped in
set_chmod_dacl():
/* If it's any one of the ACE we're replacing, skip! */
if (((compare_sids(&pntace->sid, &sid_unix_NFS_mode) == 0) ||
(compare_sids(&pntace->sid, pownersid) == 0) ||
(compare_sids(&pntace->sid, pgrpsid) == 0) ||
(compare_sids(&pntace->sid, &sid_everyone) == 0) ||
(compare_sids(&pntace->sid, &sid_authusers) == 0))) {
goto next_ace;
}
This part is confusing since form many of these cases we are NOT replacing
all these ACEs but only some of them but the code unconditionally removes
all of them, contrary to what the comment suggests.
I think some of my confusion here is that afaik we don't have good documentation
of how modefromsid, and idsfromsid, are supposed to work, what the
restrictions are or the expected semantics.
We need to document both modefromsid and idsfromsid and what the expected
semantics are for when either of them or both of them are enabled.
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2022-02-13 22:40 Ronnie Sahlberg @ 2022-02-14 7:52 ` ronnie sahlberg 0 siblings, 0 replies; 1767+ messages in thread From: ronnie sahlberg @ 2022-02-14 7:52 UTC (permalink / raw) To: Ronnie Sahlberg; +Cc: linux-cifs, Steve French Steve, I have added a test to the buildbot to verify the fix. I.e. two ACEs when file are created, one for mode and one for AuthenticatedUsers and that after chmod we still have two ACEs but the one for mode has been updated. The test is cifs/107 and it can also show how we can now modify the mountoptions we need on a test by test basis by using -o remount, ... wooohooo new mount api :-) On Mon, Feb 14, 2022 at 9:47 AM Ronnie Sahlberg <lsahlber@redhat.com> wrote: > > Steve, List, > > Here is a small patch htat fixes an issue with modefromsid where > it would strip off and remove all the ACEs that grants us access to the file. > It fixes this by restoring the "allow AuthenticatedUsers access" ACE that is stripped in > > set_chmod_dacl(): > /* If it's any one of the ACE we're replacing, skip! */ > if (((compare_sids(&pntace->sid, &sid_unix_NFS_mode) == 0) || > (compare_sids(&pntace->sid, pownersid) == 0) || > (compare_sids(&pntace->sid, pgrpsid) == 0) || > (compare_sids(&pntace->sid, &sid_everyone) == 0) || > (compare_sids(&pntace->sid, &sid_authusers) == 0))) { > goto next_ace; > } > > This part is confusing since form many of these cases we are NOT replacing > all these ACEs but only some of them but the code unconditionally removes > all of them, contrary to what the comment suggests. > > I think some of my confusion here is that afaik we don't have good documentation > of how modefromsid, and idsfromsid, are supposed to work, what the > restrictions are or the expected semantics. > We need to document both modefromsid and idsfromsid and what the expected > semantics are for when either of them or both of them are enabled. > > > > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: Re: @ 2022-02-11 15:06 Caine Chen 0 siblings, 0 replies; 1767+ messages in thread From: Caine Chen @ 2022-02-11 15:06 UTC (permalink / raw) To: neelx.g@gmail.com; +Cc: linux-rt-users@vger.kernel.org Hi Daniel: Thanks for your reply. > Not really. I guess there's one misunderstanding in your description. > Disabling the bottom half is local to running thread and not to the > CPU which executes that thread. As an effect, preemption practically > enables the bottom half again (as long as the new thread did not have > it already disabled before, of course...). It's a bit confused for me why disabling the bottom half is local to thread and not to the CPU. From my humble perspective, every forced threaded irq_threads will invoke local_bh_disable( ) and try to get bh_lock before they enter irq handler. If bh_lock(now is softirq_ctrl.lock) is held by other thread, all forced-threaded irq_threads on this CPU will wait until the lock is released. So how does preemption enable the bottom half again? To test this, I did an experiment in v5.4 kernel. First, I created a kthread and bound it to CPU0: int test_init( ) { ...... p = kthread_create(my_debug_func, NULL, "my_test"); kthread_bind(p, 0); wake_up_process(p); ...... } This kthread will invoke local_bh_disable()/local_bh_enable() periodically: int my_debug_func(void *arg) { ...... while(!kthread_should_stop()) { ...... local_bh_disable(); /* just do some busy work, such as memcpy, kmalloc and so on */ do_some_work(); local_bh_enable(); } ...... } What'more, I added some logs in some forced-threaded irq handlers to find out when they was excuted. After "my_test" thread disabled local bh, there were no forced-threaded irq threads running on CPU0. But after "my_test" thread enabled local bh, forced-threaded irqs came again. It seems that disabling the bottom half is local to CPU. > That said, the irq_thread will _not_ be blocked as bottom half is not > disabled in it's context. From your chart, it's disabled only in > thread_3 context and thread_1 context. But these two are independent > (due to the different thread contexts and not the different CPU > contexts as you misassumed) and they do not block each other either, > it's the rw_lock serializing these threads, right? > You should be able to see this with tracing. There should be no issue > or the issue is different than you think it is and different than you > described here. > Hopefully the above helps you, > Daniel Thanks Caine This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto. 此电子邮件及附件所包含内容具有机密性，且仅限于接收人使用。未经允许，禁止第三人阅读、复制或传播该电子邮件中的任何信息。如果您不属于以上电子邮件的目标接收者，请您立即通知发送人并删除原电子邮件及其相关的附件。 ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH] net/failsafe: Fix crash due to global devargs syntax parsing from secondary process @ 2022-02-10 7:10 madhuker.mythri 2022-02-10 15:00 ` Ferruh Yigit 0 siblings, 1 reply; 1767+ messages in thread From: madhuker.mythri @ 2022-02-10 7:10 UTC (permalink / raw) To: grive; +Cc: dev, Madhuker Mythri From: Madhuker Mythri <madhuker.mythri@oracle.com> Failsafe pmd started crashing with global devargs syntax as devargs is not memset to zero. Access it to in rte_devargs_parse resulted in a crash when called from secondary process. Bugzilla Id: 933 Signed-off-by: Madhuker Mythri <madhuker.mythri@oracle.com> --- drivers/net/failsafe/failsafe.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/failsafe/failsafe.c b/drivers/net/failsafe/failsafe.c index 3c754a5f66..aa93cc6000 100644 --- a/drivers/net/failsafe/failsafe.c +++ b/drivers/net/failsafe/failsafe.c @@ -360,6 +360,7 @@ rte_pmd_failsafe_probe(struct rte_vdev_device *vdev) if (sdev->devargs.name[0] == '\0') continue; + memset(&devargs, 0, sizeof(devargs)); /* rebuild devargs to be able to get the bus name. */ ret = rte_devargs_parse(&devargs, sdev->devargs.name); -- 2.32.0.windows.1 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* (no subject) 2022-02-10 7:10 [PATCH] net/failsafe: Fix crash due to global devargs syntax parsing from secondary process madhuker.mythri @ 2022-02-10 15:00 ` Ferruh Yigit 2022-02-10 16:08 ` Gaëtan Rivet 0 siblings, 1 reply; 1767+ messages in thread From: Ferruh Yigit @ 2022-02-10 15:00 UTC (permalink / raw) To: madhuker.mythri, grive; +Cc: dev On 2/10/2022 7:10 AM, madhuker.mythri@oracle.com wrote: > From: Madhuker Mythri <madhuker.mythri@oracle.com> > > Failsafe pmd started crashing with global devargs syntax as devargs is > not memset to zero. Access it to in rte_devargs_parse resulted in a > crash when called from secondary process. > > Bugzilla Id: 933 > > Signed-off-by: Madhuker Mythri <madhuker.mythri@oracle.com> > --- > drivers/net/failsafe/failsafe.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/net/failsafe/failsafe.c b/drivers/net/failsafe/failsafe.c > index 3c754a5f66..aa93cc6000 100644 > --- a/drivers/net/failsafe/failsafe.c > +++ b/drivers/net/failsafe/failsafe.c > @@ -360,6 +360,7 @@ rte_pmd_failsafe_probe(struct rte_vdev_device *vdev) > if (sdev->devargs.name[0] == '\0') > continue; > > + memset(&devargs, 0, sizeof(devargs)); > /* rebuild devargs to be able to get the bus name. */ > ret = rte_devargs_parse(&devargs, > sdev->devargs.name); if 'rte_devargs_parse()' requires 'devargs' parameter to be memset, what do you think memset it in the API? This prevents forgotten cases like this. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-02-10 15:00 ` Ferruh Yigit @ 2022-02-10 16:08 ` Gaëtan Rivet 0 siblings, 0 replies; 1767+ messages in thread From: Gaëtan Rivet @ 2022-02-10 16:08 UTC (permalink / raw) To: Ferruh Yigit, madhuker.mythri; +Cc: dev On Thu, Feb 10, 2022, at 16:00, Ferruh Yigit wrote: > On 2/10/2022 7:10 AM, madhuker.mythri@oracle.com wrote: >> From: Madhuker Mythri <madhuker.mythri@oracle.com> >> >> Failsafe pmd started crashing with global devargs syntax as devargs is >> not memset to zero. Access it to in rte_devargs_parse resulted in a >> crash when called from secondary process. >> >> Bugzilla Id: 933 >> >> Signed-off-by: Madhuker Mythri <madhuker.mythri@oracle.com> >> --- >> drivers/net/failsafe/failsafe.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/net/failsafe/failsafe.c b/drivers/net/failsafe/failsafe.c >> index 3c754a5f66..aa93cc6000 100644 >> --- a/drivers/net/failsafe/failsafe.c >> +++ b/drivers/net/failsafe/failsafe.c >> @@ -360,6 +360,7 @@ rte_pmd_failsafe_probe(struct rte_vdev_device *vdev) >> if (sdev->devargs.name[0] == '\0') >> continue; >> >> + memset(&devargs, 0, sizeof(devargs)); >> /* rebuild devargs to be able to get the bus name. */ >> ret = rte_devargs_parse(&devargs, >> sdev->devargs.name); > > if 'rte_devargs_parse()' requires 'devargs' parameter to be memset, > what do you think memset it in the API? > This prevents forgotten cases like this. Hi, I was looking at it this morning. Before the last release, rte_devargs_parse() was only supporting legacy syntax. It never read from the devargs structure, only wrote to it. So it was safe to use with a non-memset devargs. The rte_devargs_layer_parse() however is more complex. To allow rte_dev_iterator_init() to call it without doing memory allocation, it reads parts of the devargs to make decisions. Doing a first call to rte_devargs_layer_parse() as part of rte_devargs_parse() thus modified the contract it had with the users, that it would never read from devargs. It is not possible to completely avoid reading from devargs in rte_devargs_layer_parse(). It is necessary for RTE_DEV_FOREACH() to be safe to interrupt without having to do iterator cleanup. This is my current understanding. In that context, yes I think it is preferrable to do memset() within rte_devargs_parse(). It will restore the previous part of the API saying that calling it with non-memset devargs was safe to do. Thanks, -- Gaetan Rivet ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <10b1995b392e490aaa2db645f219015e@dji.com>]
* 转发: [not found] <10b1995b392e490aaa2db645f219015e@dji.com> @ 2022-01-17 12:54 ` Caine Chen 2022-02-03 11:49 ` Daniel Vacek 0 siblings, 1 reply; 1767+ messages in thread From: Caine Chen @ 2022-01-17 12:54 UTC (permalink / raw) To: linux-rt-users@vger.kernel.org Hi guys: We found that some IRQ threads will block in local_bh_disable( ) for long time in some situation and we hope to get your valuable suggestions. My kernel version is 5.4 and the irq-delay is caused by the use of write_lock_bh(). It can be described in the following figure: (1) Thread_1 which is a SCHED_NORMAL thread runs on CPU1, and it uses read_lock_bh() to protect some data. (2) Thread_2 which is a SCHED_RR thread runs on CPU1 and it preempts thread_1 after thread_1 invoked read_lock_bh(). Thread_2 may run 60 ms in my system. (3) Thread_3 which is a SCHED_NORMAL thread runs on CPU0. This thread acquires writer's lock by invoking write_lock_bh(). This function will disable button-half firstly by invoking local_bh_disable( ). But it will block in rt_write_lock() , because read lock is held by thread_1. (4) At this time, if irq thread without IRQF_NO_THREAD flag on CPU0 trys to acquire bh_lock(it has been renamed as softirq_ctrl.lock now), irq thread will block because this lock is held by thread_3. ------------------------------------------------------------------------------------------------------------------------------------ CPU1 CPU0 ------------------------------------------------- --------------------------------------------------------------- thread_2 thread_1 thread_3 irq_thread -------------- ----------- ----------- -------------- read_lock_bh() ...... write_lock_bh() /*do work*/ /* irq thread block here*/ local_bh_disable() ...... read_unlock_bh() ...... /* do work */ ...... write_unlock_bh() irq_thread_fn() ---------------------------------------------------------------------------------------------------------------------------------- In this case, if SCHED_RR thread_2 preempts thread_1 and runs too much time, all irq threads on CPU0 will be blocked. It looks like a priority reverse problem of real-time thread preempt. How can I avoid this problem? I have a few thoughts: (1) The key point, I think, is that write_lock_bh()/read_lock_bh() will disable buttom half which will disable some irq threads too. Could I use write_lock_irq()/read_lock_irq() instead? (2) If my irq handler wants to get better performance, I should request a threaded handler for the IRQ as Sebastian suggested in LKML <RE: irq thread latency caused by softirq_ctrl.lock contention>. Is threaded handler designed for low irq delay? (3) Thread_2 takes too long time for running. So it is not suitable to set this thread with high rt-priority. Should I reduce this thread's priority to solve this problem? Are there better ways to avoid this problem? We hope to get your valuable suggestions. Thanks! Best regards, Caine.chen This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto. 此电子邮件及附件所包含内容具有机密性，且仅限于接收人使用。未经允许，禁止第三人阅读、复制或传播该电子邮件中的任何信息。如果您不属于以上电子邮件的目标接收者，请您立即通知发送人并删除原电子邮件及其相关的附件。 ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-01-17 12:54 ` 转发: Caine Chen @ 2022-02-03 11:49 ` Daniel Vacek 0 siblings, 0 replies; 1767+ messages in thread From: Daniel Vacek @ 2022-02-03 11:49 UTC (permalink / raw) To: Caine Chen; +Cc: linux-rt-users@vger.kernel.org Hi Caine, On Tue, Jan 18, 2022 at 4:44 AM Caine Chen <caine.chen@dji.com> wrote: > > Hi guys: > We found that some IRQ threads will block in local_bh_disable( ) for > long time in some situation and we hope to get your valuable suggestions. > My kernel version is 5.4 and the irq-delay is caused by the use of > write_lock_bh(). > It can be described in the following figure: > (1) Thread_1 which is a SCHED_NORMAL thread runs on CPU1, > and it uses read_lock_bh() to protect some data. > (2) Thread_2 which is a SCHED_RR thread runs on CPU1 and it preempts thread_1 > after thread_1 invoked read_lock_bh(). Thread_2 may run 60 ms in my system. > (3) Thread_3 which is a SCHED_NORMAL thread runs on CPU0. This thread acquires > writer's lock by invoking write_lock_bh(). This function will disable > button-half firstly by invoking local_bh_disable( ). But it will block in > rt_write_lock() , because read lock is held by thread_1. > (4) At this time, if irq thread without IRQF_NO_THREAD flag on CPU0 trys to > acquire bh_lock(it has been renamed as softirq_ctrl.lock now), irq > thread will block because this lock is held by thread_3. > > ------------------------------------------------------------------------------------------------------------------------------------ > CPU1 CPU0 > ------------------------------------------------- --------------------------------------------------------------- > thread_2 thread_1 thread_3 irq_thread > -------------- ----------- ----------- -------------- > read_lock_bh() > > ...... > write_lock_bh() > /*do work*/ /* irq thread block here*/ > local_bh_disable() > ...... > read_unlock_bh() > ...... > /* do work */ > ...... > write_unlock_bh() > irq_thread_fn() > ---------------------------------------------------------------------------------------------------------------------------------- > > In this case, if SCHED_RR thread_2 preempts thread_1 and runs too much time, all > irq threads on CPU0 will be blocked. > It looks like a priority reverse problem of real-time thread preempt. Not really. I guess there's one misunderstanding in your description. Disabling the bottom half is local to running thread and not to the CPU which executes that thread. As an effect, preemption practically enables the bottom half again (as long as the new thread did not have it already disabled before, of course...). That said, the irq_thread will _not_ be blocked as bottom half is not disabled in it's context. From your chart, it's disabled only in thread_3 context and thread_1 context. But these two are independent (due to the different thread contexts and not the different CPU contexts as you misassumed) and they do not block each other either, it's the rw_lock serializing these threads, right? You should be able to see this with tracing. There should be no issue or the issue is different than you think it is and different than you described here. Hopefully the above helps you, Daniel > How can I avoid this problem? I have a few thoughts: > (1) The key point, I think, is that write_lock_bh()/read_lock_bh() will disable > buttom half which will disable some irq threads too. Could I use > write_lock_irq()/read_lock_irq() instead? > (2) If my irq handler wants to get better performance, I should request a > threaded handler for the IRQ as Sebastian suggested in LKML > <RE: irq thread latency caused by softirq_ctrl.lock contention>. > Is threaded handler designed for low irq delay? > (3) Thread_2 takes too long time for running. So it is not suitable to set this > thread with high rt-priority. Should I reduce this thread's priority to > solve this problem? > > Are there better ways to avoid this problem? We hope to get your valuable > suggestions. Thanks! > > Best regards, > Caine.chen > This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto. > > 此电子邮件及附件所包含内容具有机密性，且仅限于接收人使用。未经允许，禁止第三人阅读、复制或传播该电子邮件中的任何信息。如果您不属于以上电子邮件的目标接收者，请您立即通知发送人并删除原电子邮件及其相关的附件。 ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2022-01-24 12:43 Arınç ÜNAL
2022-01-25 14:03 ` Sergio Paracuellos
0 siblings, 1 reply; 1767+ messages in thread
From: Arınç ÜNAL @ 2022-01-24 12:43 UTC (permalink / raw)
To: Greg KH, Sergio Paracuellos, NeilBrown, DENG Qingfang,
Andrew Lunn, Luiz Angelo Daros de Luca
Cc: linux-staging
Hey everyone,
In preperation to mainline mt7621-dts; fix formatting, dtc warning on
switch0@0 node and pinctrl properties for ethernet node on the mt7621.dtsi.
Move the GB-PC2 specific external phy configuration on the main dtsi to
GB-PC2's devicetree, gbpc2.dts.
Now that pinctrl properties are properly defined on the ethernet node,
GMAC1 will start working.
Traffic flow on GMAC1 was tested on a mt7621a board with these modes:
External phy <-> GMAC1
PHY 0/4 <-> GMAC1
Cheers.
Arınç
[0]: https://lore.kernel.org/netdev/83a35aa3-6cb8-2bc4-2ff4-64278bbcd8c8@arinc9.com/T/
Arınç ÜNAL (4):
staging: mt7621-dts: fix formatting
staging: mt7621-dts: fix switch0@0 warnings
staging: mt7621-dts: use trgmii on gmac0 and enable flow control on port@6
staging: mt7621-dts: fix pinctrl properties for ethernet
drivers/staging/mt7621-dts/gbpc2.dts | 16 +++++++++++-----
drivers/staging/mt7621-dts/mt7621.dtsi | 32 ++++++++++++++++----------------
2 files changed, 27 insertions(+), 21 deletions(-)
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2022-01-24 12:43 Arınç ÜNAL @ 2022-01-25 14:03 ` Sergio Paracuellos 2022-01-25 15:24 ` Re: Arınç ÜNAL 0 siblings, 1 reply; 1767+ messages in thread From: Sergio Paracuellos @ 2022-01-25 14:03 UTC (permalink / raw) To: Arınç ÜNAL Cc: Greg KH, NeilBrown, DENG Qingfang, Andrew Lunn, Luiz Angelo Daros de Luca, linux-staging Hi Arinc! On Mon, Jan 24, 2022 at 1:45 PM Arınç ÜNAL <arinc.unal@arinc9.com> wrote: > > Hey everyone, > > In preperation to mainline mt7621-dts; fix formatting, dtc warning on > switch0@0 node and pinctrl properties for ethernet node on the mt7621.dtsi. > Move the GB-PC2 specific external phy configuration on the main dtsi to > GB-PC2's devicetree, gbpc2.dts. > > Now that pinctrl properties are properly defined on the ethernet node, > GMAC1 will start working. > > Traffic flow on GMAC1 was tested on a mt7621a board with these modes: > External phy <-> GMAC1 > PHY 0/4 <-> GMAC1 > > Cheers. > Arınç Nitpick: next time try to put also a subject like "staging: mt7621-dts: cleanups (or whatever)" in the cover letter of the series. > > [0]: https://lore.kernel.org/netdev/83a35aa3-6cb8-2bc4-2ff4-64278bbcd8c8@arinc9.com/T/ > > Arınç ÜNAL (4): > staging: mt7621-dts: fix formatting > staging: mt7621-dts: fix switch0@0 warnings > staging: mt7621-dts: use trgmii on gmac0 and enable flow control on port@6 > staging: mt7621-dts: fix pinctrl properties for ethernet > > drivers/staging/mt7621-dts/gbpc2.dts | 16 +++++++++++----- > drivers/staging/mt7621-dts/mt7621.dtsi | 32 ++++++++++++++++---------------- > 2 files changed, 27 insertions(+), 21 deletions(-) > > Thanks for doing this! Best regards, Sergio Paracuellos ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-01-25 14:03 ` Sergio Paracuellos @ 2022-01-25 15:24 ` Arınç ÜNAL 2022-01-25 15:50 ` Re: Sergio Paracuellos 0 siblings, 1 reply; 1767+ messages in thread From: Arınç ÜNAL @ 2022-01-25 15:24 UTC (permalink / raw) To: Sergio Paracuellos Cc: Greg KH, NeilBrown, DENG Qingfang, Andrew Lunn, Luiz Angelo Daros de Luca, linux-staging Hey Sergio, On 25/01/2022 17:03, Sergio Paracuellos wrote: > Hi Arinc! > > On Mon, Jan 24, 2022 at 1:45 PM Arınç ÜNAL <arinc.unal@arinc9.com> wrote: >> >> Hey everyone, >> >> In preperation to mainline mt7621-dts; fix formatting, dtc warning on >> switch0@0 node and pinctrl properties for ethernet node on the mt7621.dtsi. >> Move the GB-PC2 specific external phy configuration on the main dtsi to >> GB-PC2's devicetree, gbpc2.dts. >> >> Now that pinctrl properties are properly defined on the ethernet node, >> GMAC1 will start working. >> >> Traffic flow on GMAC1 was tested on a mt7621a board with these modes: >> External phy <-> GMAC1 >> PHY 0/4 <-> GMAC1 >> >> Cheers. >> Arınç > > Nitpick: next time try to put also a subject like "staging: > mt7621-dts: cleanups (or whatever)" in the cover letter of the series. I had already sent v2 with that. I'll send v3 with your input on the series, thanks! > >> >> [0]: https://lore.kernel.org/netdev/83a35aa3-6cb8-2bc4-2ff4-64278bbcd8c8@arinc9.com/T/ >> >> Arınç ÜNAL (4): >> staging: mt7621-dts: fix formatting >> staging: mt7621-dts: fix switch0@0 warnings >> staging: mt7621-dts: use trgmii on gmac0 and enable flow control on port@6 >> staging: mt7621-dts: fix pinctrl properties for ethernet >> >> drivers/staging/mt7621-dts/gbpc2.dts | 16 +++++++++++----- >> drivers/staging/mt7621-dts/mt7621.dtsi | 32 ++++++++++++++++---------------- >> 2 files changed, 27 insertions(+), 21 deletions(-) >> >> > > Thanks for doing this! > > Best regards, > Sergio Paracuellos ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-01-25 15:24 ` Re: Arınç ÜNAL @ 2022-01-25 15:50 ` Sergio Paracuellos 0 siblings, 0 replies; 1767+ messages in thread From: Sergio Paracuellos @ 2022-01-25 15:50 UTC (permalink / raw) To: Arınç ÜNAL Cc: Greg KH, NeilBrown, DENG Qingfang, Andrew Lunn, Luiz Angelo Daros de Luca, linux-staging On Tue, Jan 25, 2022 at 4:24 PM Arınç ÜNAL <arinc.unal@arinc9.com> wrote: > > Hey Sergio, > > On 25/01/2022 17:03, Sergio Paracuellos wrote: > > Hi Arinc! > > > > On Mon, Jan 24, 2022 at 1:45 PM Arınç ÜNAL <arinc.unal@arinc9.com> wrote: > >> > >> Hey everyone, > >> > >> In preperation to mainline mt7621-dts; fix formatting, dtc warning on > >> switch0@0 node and pinctrl properties for ethernet node on the mt7621.dtsi. > >> Move the GB-PC2 specific external phy configuration on the main dtsi to > >> GB-PC2's devicetree, gbpc2.dts. > >> > >> Now that pinctrl properties are properly defined on the ethernet node, > >> GMAC1 will start working. > >> > >> Traffic flow on GMAC1 was tested on a mt7621a board with these modes: > >> External phy <-> GMAC1 > >> PHY 0/4 <-> GMAC1 > >> > >> Cheers. > >> Arınç > > > > Nitpick: next time try to put also a subject like "staging: > > mt7621-dts: cleanups (or whatever)" in the cover letter of the series. > > I had already sent v2 with that. I'll send v3 with your input on the > series, thanks! True, sorry I missed that! Thanks, Sergio Paracuellos > > > > >> > >> [0]: https://lore.kernel.org/netdev/83a35aa3-6cb8-2bc4-2ff4-64278bbcd8c8@arinc9.com/T/ > >> > >> Arınç ÜNAL (4): > >> staging: mt7621-dts: fix formatting > >> staging: mt7621-dts: fix switch0@0 warnings > >> staging: mt7621-dts: use trgmii on gmac0 and enable flow control on port@6 > >> staging: mt7621-dts: fix pinctrl properties for ethernet > >> > >> drivers/staging/mt7621-dts/gbpc2.dts | 16 +++++++++++----- > >> drivers/staging/mt7621-dts/mt7621.dtsi | 32 ++++++++++++++++---------------- > >> 2 files changed, 27 insertions(+), 21 deletions(-) > >> > >> > > > > Thanks for doing this! > > > > Best regards, > > Sergio Paracuellos ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2022-01-20 15:28 Myrtle Shah 2022-01-20 15:37 ` Vitaly Wool 0 siblings, 1 reply; 1767+ messages in thread From: Myrtle Shah @ 2022-01-20 15:28 UTC (permalink / raw) To: linux-riscv, paul.walmsley, palmer; +Cc: linux-kernel These are some initial patches to bugs I found attempting to get a XIP kernel working on hardware: - 32-bit VexRiscv processor - kernel in SPI flash, at 0x00200000 - 16MB of RAM at 0x10000000 - MMU enabled I still have some more debugging to do, but these at least get the kernel as far as initialising the MMU, and I would appreciate feedback if anyone else is working on RISC-V XIP. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-01-20 15:28 Myrtle Shah @ 2022-01-20 15:37 ` Vitaly Wool 2022-01-20 23:29 ` Re: Damien Le Moal 2022-02-04 21:45 ` Re: Palmer Dabbelt 0 siblings, 2 replies; 1767+ messages in thread From: Vitaly Wool @ 2022-01-20 15:37 UTC (permalink / raw) To: Myrtle Shah; +Cc: linux-riscv, Paul Walmsley, Palmer Dabbelt, LKML Hey, On Thu, Jan 20, 2022 at 4:30 PM Myrtle Shah <gatecat@ds0.me> wrote: > > These are some initial patches to bugs I found attempting to > get a XIP kernel working on hardware: > - 32-bit VexRiscv processor > - kernel in SPI flash, at 0x00200000 > - 16MB of RAM at 0x10000000 > - MMU enabled > > I still have some more debugging to do, but these at least > get the kernel as far as initialising the MMU, and I would > appreciate feedback if anyone else is working on RISC-V XIP. I'll try to support you as much as I can, unfortunately I don't have any 32-bit RISC-V around so I was rather thinking of extending the RISC-V XIP support to 64-bit non-MMU targets. For now just please keep in mind that there might be some inherent assumptions that a target is 64 bit. Best regards, Vitaly > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-01-20 15:37 ` Vitaly Wool @ 2022-01-20 23:29 ` Damien Le Moal 2022-02-04 21:45 ` Re: Palmer Dabbelt 1 sibling, 0 replies; 1767+ messages in thread From: Damien Le Moal @ 2022-01-20 23:29 UTC (permalink / raw) To: Vitaly Wool, Myrtle Shah; +Cc: linux-riscv, Paul Walmsley, Palmer Dabbelt, LKML On 2022/01/21 0:37, Vitaly Wool wrote: > Hey, > > On Thu, Jan 20, 2022 at 4:30 PM Myrtle Shah <gatecat@ds0.me> wrote: >> >> These are some initial patches to bugs I found attempting to >> get a XIP kernel working on hardware: >> - 32-bit VexRiscv processor >> - kernel in SPI flash, at 0x00200000 >> - 16MB of RAM at 0x10000000 >> - MMU enabled >> >> I still have some more debugging to do, but these at least >> get the kernel as far as initialising the MMU, and I would >> appreciate feedback if anyone else is working on RISC-V XIP. > > I'll try to support you as much as I can, unfortunately I don't have > any 32-bit RISC-V around so I was rather thinking of extending the > RISC-V XIP support to 64-bit non-MMU targets. That would be great ! I am completing the buildroot patches for the K210. Got u-boot almost working for SD card boot too (fighting a problem with rootfs kernel mount on boot when using u-boot though). > For now just please keep in mind that there might be some inherent > assumptions that a target is 64 bit. > > Best regards, > Vitaly > >> >> _______________________________________________ >> linux-riscv mailing list >> linux-riscv@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-riscv > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv -- Damien Le Moal Western Digital Research _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-01-20 15:37 ` Vitaly Wool 2022-01-20 23:29 ` Re: Damien Le Moal @ 2022-02-04 21:45 ` Palmer Dabbelt 1 sibling, 0 replies; 1767+ messages in thread From: Palmer Dabbelt @ 2022-02-04 21:45 UTC (permalink / raw) To: vitaly.wool; +Cc: gatecat, linux-riscv, Paul Walmsley, linux-kernel On Thu, 20 Jan 2022 07:37:00 PST (-0800), vitaly.wool@konsulko.com wrote: > Hey, > > On Thu, Jan 20, 2022 at 4:30 PM Myrtle Shah <gatecat@ds0.me> wrote: >> >> These are some initial patches to bugs I found attempting to >> get a XIP kernel working on hardware: >> - 32-bit VexRiscv processor >> - kernel in SPI flash, at 0x00200000 >> - 16MB of RAM at 0x10000000 >> - MMU enabled >> >> I still have some more debugging to do, but these at least >> get the kernel as far as initialising the MMU, and I would >> appreciate feedback if anyone else is working on RISC-V XIP. > > I'll try to support you as much as I can, unfortunately I don't have > any 32-bit RISC-V around so I was rather thinking of extending the > RISC-V XIP support to 64-bit non-MMU targets. > For now just please keep in mind that there might be some inherent > assumptions that a target is 64 bit. I don't test any of the XIP configs, but if you guys have something that's sane to run in QEMU I'm happy to do so. Given that there's now some folks finding boot bugs it's probably worth getting what does boot into a regression test so it's less likely to break moving forwards. These are on fixes, with the second one split up so it's got a better chance of landing in the stable trees. Thanks! > > Best regards, > Vitaly > >> >> _______________________________________________ >> linux-riscv mailing list >> linux-riscv@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-riscv _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2022-01-13 17:53 Varun Sethi 2022-01-14 17:17 ` Fabio Estevam 0 siblings, 1 reply; 1767+ messages in thread From: Varun Sethi @ 2022-01-13 17:53 UTC (permalink / raw) To: festevam@gmail.com Cc: linux-crypto@vger.kernel.org, andrew.smirnov@gmail.com, Horia Geanta, Gaurav Jain, Pankaj Gupta Hi Fabio, Andrey, So far we have observed this issue on i.MX6 only. Disabling prediction resistance isn't the solution for the problem. We are working on identifying the proper fix for this issue and would post the patch for the same. Regards Varun >>On Tue, Jan 11, 2022 at 4:41 AM Fabio Estevam <festevam@gmail.com> wrote: >> >> From: Fabio Estevam <festevam@denx.de> >> >> Since commit 358ba762d9f1 ("crypto: caam - enable prediction resistance >> in HRWNG") the following CAAM errors can be seen on i.MX6: >> >> caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error >> hwrng: no data available >> caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error >> hwrng: no data available >> caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error >> hwrng: no data available >> caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error >> hwrng: no data available >> >> OP_ALG_PR_ON is enabled unconditionally, which may cause the problem >> on i.MX devices. >Is this true for every i.MX device? I haven't worked with the >i.MX6Q/i.MX8 hardware I was enabling this feature for in a while, so >I'm not 100% up to date on all of the problems we've seen with those, >but last time enabling prediction resistance didn't seem to cause any >issues besides a noticeable slowdown of random data generation. >Can this be a Kconfig option or maybe a runtime flag so that it'd >still be possible for some i.MX users to keep PR enabled? >> >> Fix the problem by only enabling OP_ALG_PR_ON on platforms that have > >Management Complex support. >> > >Fixes: 358ba762d9f1 ("crypto: caam - enable prediction resistance in HRWNG") > >Signed-off-by: Fabio Estevam <festevam@denx.de> > >--- > >drivers/crypto/caam/caamrng.c | 15 +++++++++++---- > > 1 file changed, 11 insertions(+), 4 deletions(-) >> > >diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c > >index 77d048dfe5d0..3514fe5de2a5 100644 > >--- a/drivers/crypto/caam/caamrng.c > >+++ b/drivers/crypto/caam/caamrng.c > >@@ -63,12 +63,19 @@ static void caam_rng_done(struct device *jrdev, u32 *desc, u32 err, > > complete(jctx->done); > > } >> > >-static u32 *caam_init_desc(u32 *desc, dma_addr_t dst_dma) >> +static u32 *caam_init_desc(struct device *jrdev, u32 *desc, dma_addr_t dst_dma) > > { >> + struct caam_drv_private *priv = dev_get_drvdata(jrdev->parent); > >+ > > init_job_desc(desc, 0); /* + 1 cmd_sz */ > > /* Generate random bytes: + 1 cmd_sz */ > >- append_operation(desc, OP_ALG_ALGSEL_RNG | OP_TYPE_CLASS1_ALG | >> - OP_ALG_PR_ON); >> + >> + if (priv->mc_en) >> + append_operation(desc, OP_ALG_ALGSEL_RNG | OP_TYPE_CLASS1_ALG | >> + OP_ALG_PR_ON); >> + else >> + append_operation(desc, OP_ALG_ALGSEL_RNG | OP_TYPE_CLASS1_ALG); >> + > > /* Store bytes: + 1 cmd_sz + caam_ptr_sz */ > > append_fifo_store(desc, dst_dma, > > CAAM_RNG_MAX_FIFO_STORE_SIZE, FIFOST_TYPE_RNGSTORE); > >@@ -101,7 +108,7 @@ static int caam_rng_read_one(struct device *jrdev, >> > > init_completion(done); > > err = caam_jr_enqueue(jrdev, >> - caam_init_desc(desc, dst_dma), >> + caam_init_desc(jrdev, desc, dst_dma), > > caam_rng_done, &jctx); >> if (err == -EINPROGRESS) { > > wait_for_completion(done); >> -- > 2.25.1 > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-01-13 17:53 Varun Sethi @ 2022-01-14 17:17 ` Fabio Estevam 0 siblings, 0 replies; 1767+ messages in thread From: Fabio Estevam @ 2022-01-14 17:17 UTC (permalink / raw) To: Varun Sethi Cc: linux-crypto@vger.kernel.org, andrew.smirnov@gmail.com, Horia Geanta, Gaurav Jain, Pankaj Gupta Hi Varun, On Thu, Jan 13, 2022 at 2:53 PM Varun Sethi <V.Sethi@nxp.com> wrote: > > Hi Fabio, Andrey, > So far we have observed this issue on i.MX6 only. Disabling prediction resistance isn't the solution for the problem. We are working on identifying the proper fix for this issue and would post the patch for the same. Please copy me when you submit a fix for this issue. Thanks! Fabio Estevam ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <20211229092443.GA10533@L-PF27918B-1352.localdomain>]
* Re: [not found] <20211229092443.GA10533@L-PF27918B-1352.localdomain> @ 2022-01-05 6:05 ` Jason Wang 2022-01-05 6:27 ` Re: Jason Wang 0 siblings, 1 reply; 1767+ messages in thread From: Jason Wang @ 2022-01-05 6:05 UTC (permalink / raw) To: Wu Zongyong; +Cc: virtualization On Wed, Dec 29, 2021 at 5:31 PM Wu Zongyong <wuzongyong@linux.alibaba.com> wrote: > > linux-kernel@vger.kernel.org > Bcc: > Subject: Should we call vdpa_config_ops->get_vq_num_{max,min} with a > virtqueue index? > Reply-To: Wu Zongyong <wuzongyong@linux.alibaba.com> > > Hi jason, > > AFAIK, a virtio device may have multiple virtqueues of diffrent sizes. > It is okay for modern devices with the vdpa_config_ops->get_vq_num_max > implementation with a static number currently since modern devices can > reset the queue size. But for legacy-virtio based devices, we cannot > allocate correct sizes for these virtqueues since it is not supported to > negotiate the queue size with harware. > > So as the title said, I wonder is it neccessary to add a new parameter > `index` to vdpa_config_ops->get_vq_num_{max,min} to help us get the size > of a dedicated virtqueue. I've posted something like this in the past here: https://lore.kernel.org/lkml/CACycT3tMd750PQ0mgqCjHnxM4RmMcx2+Eo=2RBs2E2W3qPJang@mail.gmail.com/ > > Or we can introduce a new callback like get_config_vq_num? > > What do you think? If you wish, you can carry on my work. We can start by reusing the current ops, if it doesn't work, we can use new. Thanks > > Thanks > > > > > > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2022-01-05 6:05 ` Re: Jason Wang @ 2022-01-05 6:27 ` Jason Wang 0 siblings, 0 replies; 1767+ messages in thread From: Jason Wang @ 2022-01-05 6:27 UTC (permalink / raw) To: Wu Zongyong; +Cc: virtualization On Wed, Jan 5, 2022 at 2:05 PM Jason Wang <jasowang@redhat.com> wrote: > > On Wed, Dec 29, 2021 at 5:31 PM Wu Zongyong > <wuzongyong@linux.alibaba.com> wrote: > > > > linux-kernel@vger.kernel.org > > Bcc: > > Subject: Should we call vdpa_config_ops->get_vq_num_{max,min} with a > > virtqueue index? > > Reply-To: Wu Zongyong <wuzongyong@linux.alibaba.com> > > > > Hi jason, > > > > AFAIK, a virtio device may have multiple virtqueues of diffrent sizes. > > It is okay for modern devices with the vdpa_config_ops->get_vq_num_max > > implementation with a static number currently since modern devices can > > reset the queue size. But for legacy-virtio based devices, we cannot > > allocate correct sizes for these virtqueues since it is not supported to > > negotiate the queue size with harware. > > > > So as the title said, I wonder is it neccessary to add a new parameter > > `index` to vdpa_config_ops->get_vq_num_{max,min} to help us get the size > > of a dedicated virtqueue. > > I've posted something like this in the past here: > > https://lore.kernel.org/lkml/CACycT3tMd750PQ0mgqCjHnxM4RmMcx2+Eo=2RBs2E2W3qPJang@mail.gmail.com/ > > > > > Or we can introduce a new callback like get_config_vq_num? > > > > What do you think? > > If you wish, you can carry on my work. We can start by reusing the > current ops, if it doesn't work, we can use new. Just to clarify, I meant, we probably need to introduce a new uAPI on top of the above version. Thanks > > Thanks > > > > > Thanks > > > > > > > > > > > > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2021-12-20 6:46 Ralf Beck 2021-12-20 7:55 ` Greg KH 2021-12-20 10:01 ` Re: Oliver Neukum 0 siblings, 2 replies; 1767+ messages in thread From: Ralf Beck @ 2021-12-20 6:46 UTC (permalink / raw) To: linux-usb Currently the usb core is disabling the use of and endpoint, if the endpoint address is present in two different USB interface descriptors within the same USB configuration. This behaviour is obviously based on following passage in the USB specification: "An endpoint is not shared among interfaces within a single configuration unless the endpoint is used by alternate settings of the same interface." However, this behaviour prevents using some interfaces (in my case the Motu AVB audio devices) in their vendor specific mode. They use a single USB configuration with tqo sets of interfaces, which use the same isochronous entpoint numbers. One set with audio class specific interfaces for use by an audi class driver. The other set with vendor specific interfaces for use by the vendor driver. Obviously the class specific interfaces and vendor specific interfaces are not intended to be use by a driver simultaniously. There must be another solution to deal with this. It is unacceptable to request a user of these devices to have to disablethe duplicate endpoint check and recompile the kernel on every update in order to be able to use their devices in vendor mode. Sincerly, Ralf Beck ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2021-12-20 6:46 Ralf Beck @ 2021-12-20 7:55 ` Greg KH 2021-12-20 10:01 ` Re: Oliver Neukum 1 sibling, 0 replies; 1767+ messages in thread From: Greg KH @ 2021-12-20 7:55 UTC (permalink / raw) To: Ralf Beck; +Cc: linux-usb On Mon, Dec 20, 2021 at 07:46:34AM +0100, Ralf Beck wrote: > > Currently the usb core is disabling the use of and endpoint, if the endpoint address is present in two different USB interface descriptors within the same USB configuration. > This behaviour is obviously based on following passage in the USB specification: > > "An endpoint is not shared among interfaces within a single configuration unless the endpoint is used by alternate settings of the same interface." > > However, this behaviour prevents using some interfaces (in my case the Motu AVB audio devices) in their vendor specific mode. > > They use a single USB configuration with tqo sets of interfaces, which use the same isochronous entpoint numbers. > > One set with audio class specific interfaces for use by an audi class driver. > The other set with vendor specific interfaces for use by the vendor driver. > Obviously the class specific interfaces and vendor specific interfaces are not intended to be use by a driver simultaniously. > > There must be another solution to deal with this. It is unacceptable to request a user of these devices to have to disablethe duplicate endpoint check and recompile the kernel on every update in order to be able to use their devices in vendor mode. The device sounds like it des not follow the USB specification, so how does it work with any operating system? What in-kernel driver binds to the device in vendor mode? thanks, greg k-h ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2021-12-20 6:46 Ralf Beck 2021-12-20 7:55 ` Greg KH @ 2021-12-20 10:01 ` Oliver Neukum 1 sibling, 0 replies; 1767+ messages in thread From: Oliver Neukum @ 2021-12-20 10:01 UTC (permalink / raw) To: Ralf Beck, linux-usb On 20.12.21 07:46, Ralf Beck wrote > One set with audio class specific interfaces for use by an audi class driver. > The other set with vendor specific interfaces for use by the vendor driver. > Obviously the class specific interfaces and vendor specific interfaces are not intended to be use by a driver simultaniously. Such devices are buggy. We usually define quirks for such devices. > There must be another solution to deal with this. It is unacceptable to request a user of these devices to have to disablethe duplicate endpoint check and recompile the kernel on every update in order to be able to use their devices in vendor mode. I suggest you write a patch to introduce a quirk that disables one of the interfaces and disregards disabled interfaces for purposes of the check. Regards Oliver PS: Please use a subject line when you post. ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <20211126221034.21331-1-lukasz.bartosik@semihalf.com--annotate>]
* Re: [not found] <20211126221034.21331-1-lukasz.bartosik@semihalf.com--annotate> @ 2021-11-29 21:59 ` sean.wang 0 siblings, 0 replies; 1767+ messages in thread From: sean.wang @ 2021-11-29 21:59 UTC (permalink / raw) To: lb Cc: marcel, johan.hedberg, luiz.dentz, upstream, linux-bluetooth, linux-mediatek, linux-kernel, Sean Wang From: Sean Wang <sean.wang@mediatek.com> >Enable msft opcode for btmtksdio driver. > >Signed-off-by: Łukasz Bartosik <lb@semihalf.com> >--- > drivers/bluetooth/btmtksdio.c | 1 + > 1 file changed, 1 insertion(+) > >diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c index d9cf0c492e29..2a7a615663b9 100644 >--- a/drivers/bluetooth/btmtksdio.c >+++ b/drivers/bluetooth/btmtksdio.c >@@ -887,6 +887,7 @@ static int btmtksdio_setup(struct hci_dev *hdev) > if (enable_autosuspend) > pm_runtime_allow(bdev->dev); > >+ hci_set_msft_opcode(hdev, 0xFD30); Hi Łukasz, msft feature is supposed only supported on mt7921. Could you help rework the patch to enalbe msft opocde only for mt7921? Sean > bt_dev_info(hdev, "Device setup in %llu usecs", duration); > > return 0; > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2021-11-29 21:59 ` sean.wang 0 siblings, 0 replies; 1767+ messages in thread From: sean.wang @ 2021-11-29 21:59 UTC (permalink / raw) To: lb Cc: marcel, johan.hedberg, luiz.dentz, upstream, linux-bluetooth, linux-mediatek, linux-kernel, Sean Wang From: Sean Wang <sean.wang@mediatek.com> >Enable msft opcode for btmtksdio driver. > >Signed-off-by: Łukasz Bartosik <lb@semihalf.com> >--- > drivers/bluetooth/btmtksdio.c | 1 + > 1 file changed, 1 insertion(+) > >diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c index d9cf0c492e29..2a7a615663b9 100644 >--- a/drivers/bluetooth/btmtksdio.c >+++ b/drivers/bluetooth/btmtksdio.c >@@ -887,6 +887,7 @@ static int btmtksdio_setup(struct hci_dev *hdev) > if (enable_autosuspend) > pm_runtime_allow(bdev->dev); > >+ hci_set_msft_opcode(hdev, 0xFD30); Hi Łukasz, msft feature is supposed only supported on mt7921. Could you help rework the patch to enalbe msft opocde only for mt7921? Sean > bt_dev_info(hdev, "Device setup in %llu usecs", duration); > > return 0; > _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <CAGGnn3JZdc3ETS_AijasaFUqLY9e5Q1ZHK3+806rtsEBnAo5Og@mail.gmail.com>]
* Re: [not found] <CAGGnn3JZdc3ETS_AijasaFUqLY9e5Q1ZHK3+806rtsEBnAo5Og@mail.gmail.com> @ 2021-11-23 17:20 ` Christian COMMARMOND 0 siblings, 0 replies; 1767+ messages in thread From: Christian COMMARMOND @ 2021-11-23 17:20 UTC (permalink / raw) To: linux-btrfs Hi, I use a TERRAMASTER F5-422, with 14Gb disks with 3 btrfs partitions. After repeated power outages, the 3rd partition mounts, but data is not visible, other that the first root directory. I tried to repair the disk and get this: [root@TNAS-00E1FD ~]# btrfsck --repair /dev/mapper/vg0-lv2 enabling repair mode ... Starting repair. Opening filesystem to check... Checking filesystem on /dev/mapper/vg0-lv2 UUID: a7b536f5-1827-479c-9170-eccbbc624370 [1/7] checking root items Error: could not find btree root extent for root 257 ERROR: failed to repair root items: No such file or directory (I put the full /var/log/messages at the end of this mail). What can I do to get my data back? This is a backup disk, and I am supposed to have a copy of it in another place, but there too, murphy's law, I had some disk failures, and lost some of my data. So it would be very good to be able to recover some data from these disks. Other informations: lsblk: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 3.7T 0 disk |-sda1 8:1 0 285M 0 part |-sda2 8:2 0 1.9G 0 part | `-md9 9:9 0 1.9G 0 raid1 / -|-sda3 8:3 0 977M 0 part | `-md8 9:8 0 976.4M 0 raid1 [SWAP] `-sda4 8:4 0 3.7T 0 part `-md0 9:0 0 14.6T 0 raid5 |-vg0-lv0 251:0 0 2T 0 lvm /mnt/md0 |-vg0-lv1 251:1 0 3.9T 0 lvm /mnt/md1 `-vg0-lv2 251:2 0 8.7T 0 lvm /mnt/md2 sdb 8:16 0 3.7T 0 disk |-sdb1 8:17 0 285M 0 part |-sdb2 8:18 0 1.9G 0 part | `-md9 9:9 0 1.9G 0 raid1 / |-sdb3 8:19 0 977M 0 part | `-md8 9:8 0 976.4M 0 raid1 [SWAP] `-sdb4 8:20 0 3.7T 0 part `-md0 9:0 0 14.6T 0 raid5 |-vg0-lv0 251:0 0 2T 0 lvm /mnt/md0 |-vg0-lv1 251:1 0 3.9T 0 lvm /mnt/md1 `-vg0-lv2 251:2 0 8.7T 0 lvm /mnt/md2 sdc 8:32 0 3.7T 0 disk |-sdc1 8:33 0 285M 0 part |-sdc2 8:34 0 1.9G 0 part | `-md9 9:9 0 1.9G 0 raid1 / |-sdc3 8:35 0 977M 0 part | `-md8 9:8 0 976.4M 0 raid1 [SWAP] `-sdc4 8:36 0 3.7T 0 part `-md0 9:0 0 14.6T 0 raid5 |-vg0-lv0 251:0 0 2T 0 lvm /mnt/md0 |-vg0-lv1 251:1 0 3.9T 0 lvm /mnt/md1 `-vg0-lv2 251:2 0 8.7T 0 lvm /mnt/md2 sdd 8:48 0 3.7T 0 disk |-sdd1 8:49 0 285M 0 part |-sdd2 8:50 0 1.9G 0 part | `-md9 9:9 0 1.9G 0 raid1 / |-sdd3 8:51 0 977M 0 part | `-md8 9:8 0 976.4M 0 raid1 [SWAP] `-sdd4 8:52 0 3.7T 0 part `-md0 9:0 0 14.6T 0 raid5 |-vg0-lv0 251:0 0 2T 0 lvm /mnt/md0 |-vg0-lv1 251:1 0 3.9T 0 lvm /mnt/md1 `-vg0-lv2 251:2 0 8.7T 0 lvm /mnt/md2 sde 8:64 0 3.7T 0 disk |-sde1 8:65 0 285M 0 part |-sde2 8:66 0 1.9G 0 part | `-md9 9:9 0 1.9G 0 raid1 / |-sde3 8:67 0 977M 0 part | `-md8 9:8 0 976.4M 0 raid1 [SWAP] `-sde4 8:68 0 3.7T 0 part `-md0 9:0 0 14.6T 0 raid5 |-vg0-lv0 251:0 0 2T 0 lvm /mnt/md0 |-vg0-lv1 251:1 0 3.9T 0 lvm /mnt/md1 `-vg0-lv2 251:2 0 8.7T 0 lvm /mnt/md2 df -h: Filesystem Size Used Available Use% Mounted on /dev/md9 1.8G 576.8M 1.2G 32% / devtmpfs 1.8G 0 1.8G 0% /dev tmpfs 1.8G 0 1.8G 0% /dev/shm tmpfs 1.8G 1.1M 1.8G 0% /tmp tmpfs 1.8G 236.0K 1.8G 0% /run tmpfs 1.8G 6.3M 1.8G 0% /opt/var /dev/mapper/vg0-lv0 2.0T 34.5M 2.0T 0% /mnt/md0 /dev/mapper/vg0-lv1 3.9T 16.3M 3.9T 0% /mnt/md1 /dev/mapper/vg0-lv2 8.7T 2.9T 5.8T 33% /mnt/md2 This physical disks are new (a few months) and do not show errors. I hope there is a way to fix this. regards, Christian COMMARMOND Here, the full (restricted to 'kernel') from the lines where I begin to see errors: Nov 23 17:00:46 TNAS-00E1FD kernel: [ 34.540572] Detached from scsi7, channel 0, id 0, lun 0, type 0 Nov 23 17:00:48 TNAS-00E1FD kernel: [ 37.148169] md: md8 stopped. Nov 23 17:00:48 TNAS-00E1FD kernel: [ 37.154395] md/raid1:md8: active with 1 out of 72 mirrors Nov 23 17:00:48 TNAS-00E1FD kernel: [ 37.155564] md8: detected capacity change from 0 to 1023868928 Nov 23 17:00:49 TNAS-00E1FD kernel: [ 38.240910] md: recovery of RAID array md8 Nov 23 17:00:49 TNAS-00E1FD kernel: [ 38.276712] md: md8: recovery interrupted. Nov 23 17:00:50 TNAS-00E1FD kernel: [ 38.346552] md: recovery of RAID array md8 Nov 23 17:00:50 TNAS-00E1FD kernel: [ 38.392148] md: md8: recovery interrupted. Nov 23 17:00:50 TNAS-00E1FD kernel: [ 38.458126] md: recovery of RAID array md8 Nov 23 17:00:50 TNAS-00E1FD kernel: [ 38.494025] md: md8: recovery interrupted. Nov 23 17:00:50 TNAS-00E1FD kernel: [ 38.576871] md: recovery of RAID array md8 Nov 23 17:00:50 TNAS-00E1FD kernel: [ 38.837269] Adding 999868k swap on /dev/md8. Priority:-1 extents:1 across:999868k Nov 23 17:00:51 TNAS-00E1FD kernel: [ 39.801285] md: md0 stopped. Nov 23 17:00:51 TNAS-00E1FD kernel: [ 39.859798] md/raid:md0: device sda4 operational as raid disk 0 Nov 23 17:00:51 TNAS-00E1FD kernel: [ 39.861417] md/raid:md0: device sde4 operational as raid disk 4 Nov 23 17:00:51 TNAS-00E1FD kernel: [ 39.863675] md/raid:md0: device sdd4 operational as raid disk 3 Nov 23 17:00:51 TNAS-00E1FD kernel: [ 39.865059] md/raid:md0: device sdc4 operational as raid disk 2 Nov 23 17:00:51 TNAS-00E1FD kernel: [ 39.866373] md/raid:md0: device sdb4 operational as raid disk 1 Nov 23 17:00:51 TNAS-00E1FD kernel: [ 39.869300] md/raid:md0: raid level 5 active with 5 out of 5 devices, algorithm 2 Nov 23 17:00:51 TNAS-00E1FD kernel: [ 39.926721] md0: detected capacity change from 0 to 15989118861312 Nov 23 17:00:57 TNAS-00E1FD kernel: [ 46.111539] md: md8: recovery done. Nov 23 17:00:57 TNAS-00E1FD kernel: [ 46.269349] flashcache: flashcache-3.1.1 initialized Nov 23 17:00:58 TNAS-00E1FD kernel: [ 46.394510] BTRFS: device fsid bdc3dbee-00a3-4541-99b4-096cd27939f2 devid 1 transid 679 /dev/mapper/vg0-lv0 Nov 23 17:00:58 TNAS-00E1FD kernel: [ 46.397072] BTRFS info (device dm-0): metadata ratio 50 Nov 23 17:00:58 TNAS-00E1FD kernel: [ 46.399122] BTRFS info (device dm-0): using free space tree Nov 23 17:00:58 TNAS-00E1FD kernel: [ 46.400380] BTRFS info (device dm-0): has skinny extents Nov 23 17:00:58 TNAS-00E1FD kernel: [ 46.471236] BTRFS info (device dm-0): new size for /dev/mapper/vg0-lv0 is 2147483648000 Nov 23 17:00:58 TNAS-00E1FD kernel: [ 47.087622] BTRFS: device fsid a5828e5a-1b11-4743-891c-11d0d8aeb1ae devid 1 transid 107 /dev/mapper/vg0-lv1 Nov 23 17:00:58 TNAS-00E1FD kernel: [ 47.089943] BTRFS info (device dm-1): metadata ratio 50 Nov 23 17:00:58 TNAS-00E1FD kernel: [ 47.091505] BTRFS info (device dm-1): using free space tree Nov 23 17:00:58 TNAS-00E1FD kernel: [ 47.093062] BTRFS info (device dm-1): has skinny extents Nov 23 17:00:58 TNAS-00E1FD kernel: [ 47.150713] BTRFS info (device dm-1): new size for /dev/mapper/vg0-lv1 is 4294967296000 Nov 23 17:00:59 TNAS-00E1FD kernel: [ 47.737119] BTRFS: device fsid a7b536f5-1827-479c-9170-eccbbc624370 devid 1 transid 142633 /dev/mapper/vg0-lv2 Nov 23 17:00:59 TNAS-00E1FD kernel: [ 47.739313] BTRFS info (device dm-2): metadata ratio 50 Nov 23 17:00:59 TNAS-00E1FD kernel: [ 47.740630] BTRFS info (device dm-2): using free space tree Nov 23 17:00:59 TNAS-00E1FD kernel: [ 47.741892] BTRFS info (device dm-2): has skinny extents Nov 23 17:00:59 TNAS-00E1FD kernel: [ 47.946451] BTRFS info (device dm-2): bdev /dev/mapper/vg0-lv2 errs: wr 0, rd 0, flush 0, corrupt 0, gen 8 Nov 23 17:01:01 TNAS-00E1FD kernel: [ 49.693394] BTRFS info (device dm-2): checking UUID tree Nov 23 17:01:01 TNAS-00E1FD kernel: [ 49.700560] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:01:01 TNAS-00E1FD kernel: [ 49.707394] BTRFS info (device dm-2): new size for /dev/mapper/vg0-lv2 is 9546663723008 Nov 23 17:01:01 TNAS-00E1FD kernel: [ 49.713109] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:01:01 TNAS-00E1FD kernel: [ 49.715107] BTRFS warning (device dm-2): iterating uuid_tree failed -5 Nov 23 17:01:01 TNAS-00E1FD kernel: [ 49.795716] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:01:01 TNAS-00E1FD kernel: [ 49.798231] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:01:03 TNAS-00E1FD kernel: [ 52.272802] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:01:03 TNAS-00E1FD kernel: [ 52.275264] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:01:03 TNAS-00E1FD kernel: [ 52.277208] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:01:03 TNAS-00E1FD kernel: [ 52.278483] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:01:04 TNAS-00E1FD kernel: [ 52.570033] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:01:04 TNAS-00E1FD kernel: [ 52.571487] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:01:05 TNAS-00E1FD kernel: [ 54.250527] nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead. Nov 23 17:01:07 TNAS-00E1FD kernel: [ 56.050418] verify_parent_transid: 2 callbacks suppressed Nov 23 17:01:07 TNAS-00E1FD kernel: [ 56.050424] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:01:07 TNAS-00E1FD kernel: [ 56.063012] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:01:07 TNAS-00E1FD kernel: [ 56.166746] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:01:07 TNAS-00E1FD kernel: [ 56.167903] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:01:07 TNAS-00E1FD kernel: [ 56.274188] NFSD: starting 90-second grace period (net ffffffff9db5abc0) Nov 23 17:01:09 TNAS-00E1FD kernel: [ 57.524631] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:01:09 TNAS-00E1FD kernel: [ 57.525878] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:01:09 TNAS-00E1FD kernel: [ 57.589706] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:01:09 TNAS-00E1FD kernel: [ 57.590882] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:01:10 TNAS-00E1FD kernel: [ 58.315852] warning: `smbd' uses legacy ethtool link settings API, link modes are only partially reported Nov 23 17:01:31 TNAS-00E1FD kernel: [ 79.882060] BTRFS error (device dm-2): incorrect extent count for 29360128; counted 740, expected 677 Nov 23 17:01:31 TNAS-00E1FD kernel: [ 79.883000] BTRFS: error (device dm-2) in convert_free_space_to_extents:457: errno=-5 IO failure Nov 23 17:01:31 TNAS-00E1FD kernel: [ 79.883946] BTRFS info (device dm-2): forced readonly Nov 23 17:01:31 TNAS-00E1FD kernel: [ 79.884896] BTRFS: error (device dm-2) in add_to_free_space_tree:1052: errno=-5 IO failure Nov 23 17:01:31 TNAS-00E1FD kernel: [ 79.885863] BTRFS: error (device dm-2) in __btrfs_free_extent:7106: errno=-5 IO failure Nov 23 17:01:31 TNAS-00E1FD kernel: [ 79.886825] BTRFS: error (device dm-2) in btrfs_run_delayed_refs:3009: errno=-5 IO failure Nov 23 17:01:31 TNAS-00E1FD kernel: [ 79.887803] BTRFS warning (device dm-2): Skipping commit of aborted transaction. Nov 23 17:01:31 TNAS-00E1FD kernel: [ 79.888807] BTRFS: error (device dm-2) in cleanup_transaction:1873: errno=-5 IO failure Nov 23 17:01:31 TNAS-00E1FD kernel: [ 79.892906] BTRFS error (device dm-2): incorrect extent count for 29360128; counted 739, expected 676 Nov 23 17:02:55 TNAS-00E1FD kernel: [ 164.199509] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:02:55 TNAS-00E1FD kernel: [ 164.212280] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:02:55 TNAS-00E1FD kernel: [ 164.214362] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:02:55 TNAS-00E1FD kernel: [ 164.216331] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:02:55 TNAS-00E1FD kernel: [ 164.224184] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:02:55 TNAS-00E1FD kernel: [ 164.225500] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:02:55 TNAS-00E1FD kernel: [ 164.227338] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:02:55 TNAS-00E1FD kernel: [ 164.228636] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:03:37 TNAS-00E1FD kernel: [ 205.915492] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:03:37 TNAS-00E1FD kernel: [ 205.936745] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:03:37 TNAS-00E1FD kernel: [ 205.938543] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:03:37 TNAS-00E1FD kernel: [ 205.940375] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:03:37 TNAS-00E1FD kernel: [ 205.951375] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:03:37 TNAS-00E1FD kernel: [ 205.952810] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:03:37 TNAS-00E1FD kernel: [ 205.972430] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:03:37 TNAS-00E1FD kernel: [ 205.973548] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:03:37 TNAS-00E1FD kernel: [ 205.974819] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:03:37 TNAS-00E1FD kernel: [ 205.975984] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:03:54 TNAS-00E1FD kernel: [ 222.807122] verify_parent_transid: 6 callbacks suppressed Nov 23 17:03:54 TNAS-00E1FD kernel: [ 222.807127] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:03:54 TNAS-00E1FD kernel: [ 222.819996] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:03:54 TNAS-00E1FD kernel: [ 222.923926] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:03:54 TNAS-00E1FD kernel: [ 222.925434] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:03:54 TNAS-00E1FD kernel: [ 223.061241] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:03:54 TNAS-00E1FD kernel: [ 223.062463] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:03:59 TNAS-00E1FD kernel: [ 227.554549] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:03:59 TNAS-00E1FD kernel: [ 227.556100] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:04:13 TNAS-00E1FD kernel: [ 242.190152] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:04:13 TNAS-00E1FD kernel: [ 242.202843] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:04:13 TNAS-00E1FD kernel: [ 242.215390] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:04:13 TNAS-00E1FD kernel: [ 242.217241] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:05:15 TNAS-00E1FD kernel: [ 303.772878] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:05:15 TNAS-00E1FD kernel: [ 303.785862] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:06:14 TNAS-00E1FD kernel: [ 362.480763] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:06:14 TNAS-00E1FD kernel: [ 362.493848] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:06:43 TNAS-00E1FD kernel: [ 392.055419] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:06:43 TNAS-00E1FD kernel: [ 392.068306] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:06:43 TNAS-00E1FD kernel: [ 392.069074] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:06:43 TNAS-00E1FD kernel: [ 392.069862] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:06:43 TNAS-00E1FD kernel: [ 392.076040] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:06:43 TNAS-00E1FD kernel: [ 392.076821] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:06:43 TNAS-00E1FD kernel: [ 392.077643] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:06:43 TNAS-00E1FD kernel: [ 392.078360] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:14:02 TNAS-00E1FD kernel: [ 830.643054] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:14:02 TNAS-00E1FD kernel: [ 830.664937] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:14:11 TNAS-00E1FD kernel: [ 839.988330] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:14:11 TNAS-00E1FD kernel: [ 839.989850] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:14:11 TNAS-00E1FD kernel: [ 839.991371] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:14:11 TNAS-00E1FD kernel: [ 839.992867] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:14:12 TNAS-00E1FD kernel: [ 840.488126] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:14:12 TNAS-00E1FD kernel: [ 840.488998] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:16:36 TNAS-00E1FD kernel: [ 985.266877] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:16:36 TNAS-00E1FD kernel: [ 985.288688] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:16:36 TNAS-00E1FD kernel: [ 985.289624] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:16:36 TNAS-00E1FD kernel: [ 985.290454] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:16:36 TNAS-00E1FD kernel: [ 985.300198] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:16:36 TNAS-00E1FD kernel: [ 985.300917] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:16:36 TNAS-00E1FD kernel: [ 985.301704] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:16:36 TNAS-00E1FD kernel: [ 985.302318] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:34:24 TNAS-00E1FD kernel: [ 2052.815271] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:34:24 TNAS-00E1FD kernel: [ 2052.838506] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:34:52 TNAS-00E1FD kernel: [ 2081.273231] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:34:52 TNAS-00E1FD kernel: [ 2081.296585] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:39:26 TNAS-00E1FD kernel: [ 2354.866442] BTRFS error (device dm-2): cleaner transaction attach returned -30 Nov 23 17:56:30 TNAS-00E1FD kernel: [ 3378.825461] BTRFS info (device dm-2): using free space tree Nov 23 17:56:30 TNAS-00E1FD kernel: [ 3378.825891] BTRFS info (device dm-2): has skinny extents Nov 23 17:56:30 TNAS-00E1FD kernel: [ 3378.968533] BTRFS info (device dm-2): bdev /dev/mapper/vg0-lv2 errs: wr 0, rd 0, flush 0, corrupt 0, gen 8 Nov 23 17:56:32 TNAS-00E1FD kernel: [ 3380.525294] BTRFS info (device dm-2): checking UUID tree Nov 23 17:56:32 TNAS-00E1FD kernel: [ 3380.535839] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:56:32 TNAS-00E1FD kernel: [ 3380.544791] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:56:32 TNAS-00E1FD kernel: [ 3380.545579] BTRFS warning (device dm-2): iterating uuid_tree failed -5 Nov 23 17:56:42 TNAS-00E1FD kernel: [ 3391.302453] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:56:43 TNAS-00E1FD kernel: [ 3391.328368] BTRFS error (device dm-2): parent transid verify failed on 174735360 wanted 37018 found 37023 Nov 23 17:57:01 TNAS-00E1FD kernel: [ 3409.806326] BTRFS error (device dm-2): incorrect extent count for 29360128; counted 740, expected 677 Nov 23 17:57:01 TNAS-00E1FD kernel: [ 3409.806836] BTRFS: error (device dm-2) in convert_free_space_to_extents:457: errno=-5 IO failure Nov 23 17:57:01 TNAS-00E1FD kernel: [ 3409.807367] BTRFS info (device dm-2): forced readonly Nov 23 17:57:01 TNAS-00E1FD kernel: [ 3409.807904] BTRFS: error (device dm-2) in add_to_free_space_tree:1052: errno=-5 IO failure Nov 23 17:57:01 TNAS-00E1FD kernel: [ 3409.808493] BTRFS: error (device dm-2) in __btrfs_free_extent:7106: errno=-5 IO failure Nov 23 17:57:01 TNAS-00E1FD kernel: [ 3409.809160] BTRFS: error (device dm-2) in btrfs_run_delayed_refs:3009: errno=-5 IO failure Nov 23 17:57:01 TNAS-00E1FD kernel: [ 3409.809785] BTRFS warning (device dm-2): Skipping commit of aborted transaction. Nov 23 17:57:01 TNAS-00E1FD kernel: [ 3409.810444] BTRFS: error (device dm-2) in cleanup_transaction:1873: errno=-5 IO failure Nov 23 17:57:01 TNAS-00E1FD kernel: [ 3409.814113] BTRFS error (device dm-2): incorrect extent count for 29360128; counted 739, expected 676 ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data
@ 2021-11-02 9:48 Hans de Goede
2021-11-02 9:49 ` [PATCH v5 05/11] clk: Introduce clk-tps68470 driver Hans de Goede
0 siblings, 1 reply; 1767+ messages in thread
From: Hans de Goede @ 2021-11-02 9:48 UTC (permalink / raw)
To: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang,
Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd
Cc: Hans de Goede, Len Brown, linux-acpi, platform-driver-x86,
linux-kernel, linux-i2c, Sakari Ailus, Kate Hsuan, linux-media,
linux-clk
Here is v5 of my patch-set adding support for camera sensor connected to a
TPS68470 PMIC on x86/ACPI devices.
Changes in v5:
- Update regulator_init_data in patch 10/11 to include the VCM regulator
- Address various small review remarks from Andy
- Make a couple of functions / vars static in the clk + regulator drivers
Reported-by: kernel test robot <lkp@intel.com>
Changes in v4:
[PATCH 01/11] ACPI: delay enumeration of devices with a _DEP
pointing to an INT3472 device:
- Move the acpi_dev_ready_for_enumeration() check to acpi_bus_attach()
(replacing the acpi_device_is_present() check there)
[PATCH 04/11] regulator: Introduce tps68470-regulator driver:
- Make the top comment block use c++ style comments
- Drop the bogus builtin regulator_init_data
- Make the driver enable the PMIC clk when enabling the Core buck
regulator, this switching regulator needs the PLL to be on
- Kconfig: add || COMPILE_TEST, fix help text
[PATCH 05/11] clk: Introduce clk-tps68470 driver
- Kconfig: select REGMAP_I2C, add || COMPILE_TEST, fix help text
- tps68470_clk_prepare(): Wait for the PLL to lock before returning
- tps68470_clk_unprepare(): Remove unnecesary clearing of divider regs
- tps68470_clk_probe(): Use devm_clk_hw_register()
- Misc. small cleanups
I'm quite happy with how this works now, so from my pov this is the final
version of the device-instantiation deferral code / approach.
###
The clk and regulator frameworks expect clk/regulator consumer-devices
to have info about the consumed clks/regulators described in the device's
fw_node, but on ACPI this info is missing.
This series worksaround this by providing platform_data with the info to
the TPS68470 clk/regulator MFD cells.
Patches 1 - 2 deal with a probe-ordering problem this introduces,
since the lookups are only registered when the provider-driver binds,
trying to get these clks/regulators before then results in a -ENOENT
error for clks and a dummy regulator for regulators. See the patches
for more details.
Patch 3 adds a header file which adds tps68470_clk_platform_data and
tps68470_regulator_platform_data structs. The futher patches depend on
this new header file.
Patch 4 + 5 add the TPS68470 clk and regulator drivers
Patches 6 - 11 Modify the INT3472 driver which instantiates the MFD cells to
provide the necessary platform-data.
Assuming this series is acceptable to everyone, we need to talk about how
to merge this.
Patch 2 has already been acked by Wolfram for merging by Rafael, so patch
1 + 2 can be merged into linux-pm, independent of the rest of the series
(there are some runtime deps on other changes for everything to work,
but the camera-sensors impacted by this are not fully supported yet in
the mainline kernel anyways).
For "[PATCH 03/13] platform_data: Add linux/platform_data/tps68470.h file",
which all further patches depend on I plan to provide an immutable branch
myself (once it has been reviewed), which the clk / regulator maintainers
can then merge before merging the clk / regulator driver which depends on
this.
And I will merge that IM-branch + patches 6-11 into the pdx86 tree myself.
Regards,
Hans
Daniel Scally (1):
platform/x86: int3472: Enable I2c daisy chain
Hans de Goede (10):
ACPI: delay enumeration of devices with a _DEP pointing to an INT3472
device
i2c: acpi: Use acpi_dev_ready_for_enumeration() helper
platform_data: Add linux/platform_data/tps68470.h file
regulator: Introduce tps68470-regulator driver
clk: Introduce clk-tps68470 driver
platform/x86: int3472: Split into 2 drivers
platform/x86: int3472: Add get_sensor_adev_and_name() helper
platform/x86: int3472: Pass tps68470_clk_platform_data to the
tps68470-regulator MFD-cell
platform/x86: int3472: Pass tps68470_regulator_platform_data to the
tps68470-regulator MFD-cell
platform/x86: int3472: Deal with probe ordering issues
drivers/acpi/scan.c | 37 ++-
drivers/clk/Kconfig | 8 +
drivers/clk/Makefile | 1 +
drivers/clk/clk-tps68470.c | 257 ++++++++++++++++++
drivers/i2c/i2c-core-acpi.c | 5 +-
drivers/platform/x86/intel/int3472/Makefile | 9 +-
...lk_and_regulator.c => clk_and_regulator.c} | 2 +-
drivers/platform/x86/intel/int3472/common.c | 82 ++++++
.../{intel_skl_int3472_common.h => common.h} | 6 +-
...ntel_skl_int3472_discrete.c => discrete.c} | 51 ++--
.../intel/int3472/intel_skl_int3472_common.c | 106 --------
...ntel_skl_int3472_tps68470.c => tps68470.c} | 99 ++++++-
drivers/platform/x86/intel/int3472/tps68470.h | 25 ++
.../x86/intel/int3472/tps68470_board_data.c | 134 +++++++++
drivers/regulator/Kconfig | 9 +
drivers/regulator/Makefile | 1 +
drivers/regulator/tps68470-regulator.c | 212 +++++++++++++++
include/acpi/acpi_bus.h | 5 +-
include/linux/mfd/tps68470.h | 11 +
include/linux/platform_data/tps68470.h | 35 +++
20 files changed, 944 insertions(+), 151 deletions(-)
create mode 100644 drivers/clk/clk-tps68470.c
rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_clk_and_regulator.c => clk_and_regulator.c} (99%)
create mode 100644 drivers/platform/x86/intel/int3472/common.c
rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_common.h => common.h} (94%)
rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_discrete.c => discrete.c} (91%)
delete mode 100644 drivers/platform/x86/intel/int3472/intel_skl_int3472_common.c
rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_tps68470.c => tps68470.c} (54%)
create mode 100644 drivers/platform/x86/intel/int3472/tps68470.h
create mode 100644 drivers/platform/x86/intel/int3472/tps68470_board_data.c
create mode 100644 drivers/regulator/tps68470-regulator.c
create mode 100644 include/linux/platform_data/tps68470.h
--
2.31.1
^ permalink raw reply [flat|nested] 1767+ messages in thread* [PATCH v5 05/11] clk: Introduce clk-tps68470 driver 2021-11-02 9:48 [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data Hans de Goede @ 2021-11-02 9:49 ` Hans de Goede [not found] ` <163588780885.2993099.2088131017920983969@swboyd.mtv.corp.google.com> 0 siblings, 1 reply; 1767+ messages in thread From: Hans de Goede @ 2021-11-02 9:49 UTC (permalink / raw) To: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang, Mika Westerberg, Daniel Scally, Laurent Pinchart, Mauro Carvalho Chehab, Liam Girdwood, Mark Brown, Michael Turquette, Stephen Boyd Cc: Hans de Goede, Len Brown, linux-acpi, platform-driver-x86, linux-kernel, linux-i2c, Sakari Ailus, Kate Hsuan, linux-media, linux-clk The TPS68470 PMIC provides Clocks, GPIOs and Regulators. At present in the kernel the Regulators and Clocks are controlled by an OpRegion driver designed to work with power control methods defined in ACPI, but some platforms lack those methods, meaning drivers need to be able to consume the resources of these chips through the usual frameworks. This commit adds a driver for the clocks provided by the tps68470, and is designed to bind to the platform_device registered by the intel_skl_int3472 module. This is based on this out of tree driver written by Intel: https://github.com/intel/linux-intel-lts/blob/4.14/base/drivers/clk/clk-tps68470.c with various cleanups added. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- Changes in v5: - Small comment cleanups based on review from Andy Changes in v4: - Kconfig: select REGMAP_I2C, add || COMPILE_TEST, fix help text - tps68470_clk_prepare(): Wait for the PLL to lock before returning - tps68470_clk_unprepare(): Remove unnecesary clearing of divider regs - tps68470_clk_probe(): Use devm_clk_hw_register() - Misc. small cleanups Changes in v2: - Update the comment on why a subsys_initcall is used to register the drv - Fix trailing whitespice on line 100 --- drivers/clk/Kconfig | 8 ++ drivers/clk/Makefile | 1 + drivers/clk/clk-tps68470.c | 257 +++++++++++++++++++++++++++++++++++ include/linux/mfd/tps68470.h | 11 ++ 4 files changed, 277 insertions(+) create mode 100644 drivers/clk/clk-tps68470.c diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index c5b3dc97396a..4e9098d79249 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -169,6 +169,14 @@ config COMMON_CLK_CDCE706 help This driver supports TI CDCE706 programmable 3-PLL clock synthesizer. +config COMMON_CLK_TPS68470 + tristate "Clock Driver for TI TPS68470 PMIC" + depends on I2C + depends on INTEL_SKL_INT3472 || COMPILE_TEST + select REGMAP_I2C + help + This driver supports the clocks provided by the TPS68470 PMIC. + config COMMON_CLK_CDCE925 tristate "Clock driver for TI CDCE913/925/937/949 devices" depends on I2C diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index e42312121e51..6b6a88ae1425 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -63,6 +63,7 @@ obj-$(CONFIG_COMMON_CLK_SI570) += clk-si570.o obj-$(CONFIG_COMMON_CLK_STM32F) += clk-stm32f4.o obj-$(CONFIG_COMMON_CLK_STM32H7) += clk-stm32h7.o obj-$(CONFIG_COMMON_CLK_STM32MP157) += clk-stm32mp1.o +obj-$(CONFIG_COMMON_CLK_TPS68470) += clk-tps68470.o obj-$(CONFIG_CLK_TWL6040) += clk-twl6040.o obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o obj-$(CONFIG_COMMON_CLK_VC5) += clk-versaclock5.o diff --git a/drivers/clk/clk-tps68470.c b/drivers/clk/clk-tps68470.c new file mode 100644 index 000000000000..2ad0ac2f4096 --- /dev/null +++ b/drivers/clk/clk-tps68470.c @@ -0,0 +1,257 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Clock driver for TPS68470 PMIC + * + * Copyright (c) 2021 Red Hat Inc. + * Copyright (C) 2018 Intel Corporation + * + * Authors: + * Hans de Goede <hdegoede@redhat.com> + * Zaikuo Wang <zaikuo.wang@intel.com> + * Tianshu Qiu <tian.shu.qiu@intel.com> + * Jian Xu Zheng <jian.xu.zheng@intel.com> + * Yuning Pu <yuning.pu@intel.com> + * Antti Laakso <antti.laakso@intel.com> + */ + +#include <linux/clk-provider.h> +#include <linux/clkdev.h> +#include <linux/kernel.h> +#include <linux/mfd/tps68470.h> +#include <linux/module.h> +#include <linux/platform_device.h> +#include <linux/platform_data/tps68470.h> +#include <linux/regmap.h> + +#define TPS68470_CLK_NAME "tps68470-clk" + +#define to_tps68470_clkdata(clkd) \ + container_of(clkd, struct tps68470_clkdata, clkout_hw) + +static struct tps68470_clkout_freqs { + unsigned long freq; + unsigned int xtaldiv; + unsigned int plldiv; + unsigned int postdiv; + unsigned int buckdiv; + unsigned int boostdiv; +} clk_freqs[] = { +/* + * The PLL is used to multiply the crystal oscillator + * frequency range of 3 MHz to 27 MHz by a programmable + * factor of F = (M/N)*(1/P) such that the output + * available at the HCLK_A or HCLK_B pins are in the range + * of 4 MHz to 64 MHz in increments of 0.1 MHz. + * + * hclk_# = osc_in * (((plldiv*2)+320) / (xtaldiv+30)) * (1 / 2^postdiv) + * + * PLL_REF_CLK should be as close as possible to 100kHz + * PLL_REF_CLK = input clk / XTALDIV[7:0] + 30) + * + * PLL_VCO_CLK = (PLL_REF_CLK * (plldiv*2 + 320)) + * + * BOOST should be as close as possible to 2Mhz + * BOOST = PLL_VCO_CLK / (BOOSTDIV[4:0] + 16) * + * + * BUCK should be as close as possible to 5.2Mhz + * BUCK = PLL_VCO_CLK / (BUCKDIV[3:0] + 5) + * + * osc_in xtaldiv plldiv postdiv hclk_# + * 20Mhz 170 32 1 19.2Mhz + * 20Mhz 170 40 1 20Mhz + * 20Mhz 170 80 1 24Mhz + */ + { 19200000, 170, 32, 1, 2, 3 }, + { 20000000, 170, 40, 1, 3, 4 }, + { 24000000, 170, 80, 1, 4, 8 }, +}; + +struct tps68470_clkdata { + struct clk_hw clkout_hw; + struct regmap *regmap; + unsigned int clk_cfg_idx; +}; + +static int tps68470_clk_is_prepared(struct clk_hw *hw) +{ + struct tps68470_clkdata *clkdata = to_tps68470_clkdata(hw); + int val; + + if (regmap_read(clkdata->regmap, TPS68470_REG_PLLCTL, &val)) + return 0; + + return val & TPS68470_PLL_EN_MASK; +} + +static int tps68470_clk_prepare(struct clk_hw *hw) +{ + struct tps68470_clkdata *clkdata = to_tps68470_clkdata(hw); + unsigned int idx = clkdata->clk_cfg_idx; + + regmap_write(clkdata->regmap, TPS68470_REG_BOOSTDIV, clk_freqs[idx].boostdiv); + regmap_write(clkdata->regmap, TPS68470_REG_BUCKDIV, clk_freqs[idx].buckdiv); + regmap_write(clkdata->regmap, TPS68470_REG_PLLSWR, TPS68470_PLLSWR_DEFAULT); + regmap_write(clkdata->regmap, TPS68470_REG_XTALDIV, clk_freqs[idx].xtaldiv); + regmap_write(clkdata->regmap, TPS68470_REG_PLLDIV, clk_freqs[idx].plldiv); + regmap_write(clkdata->regmap, TPS68470_REG_POSTDIV, clk_freqs[idx].postdiv); + regmap_write(clkdata->regmap, TPS68470_REG_POSTDIV2, clk_freqs[idx].postdiv); + regmap_write(clkdata->regmap, TPS68470_REG_CLKCFG2, TPS68470_CLKCFG2_DRV_STR_2MA); + + regmap_write(clkdata->regmap, TPS68470_REG_PLLCTL, + TPS68470_OSC_EXT_CAP_DEFAULT << TPS68470_OSC_EXT_CAP_SHIFT | + TPS68470_CLK_SRC_XTAL << TPS68470_CLK_SRC_SHIFT); + + regmap_write(clkdata->regmap, TPS68470_REG_CLKCFG1, + (TPS68470_PLL_OUTPUT_ENABLE << TPS68470_OUTPUT_A_SHIFT) | + (TPS68470_PLL_OUTPUT_ENABLE << TPS68470_OUTPUT_B_SHIFT)); + + regmap_update_bits(clkdata->regmap, TPS68470_REG_PLLCTL, + TPS68470_PLL_EN_MASK, TPS68470_PLL_EN_MASK); + + /* + * The PLLCTL reg lock bit is set by the PMIC after approx. 4ms and + * does not indicate a true lock, so just wait 4 ms. + */ + usleep_range(4000, 5000); + + return 0; +} + +static void tps68470_clk_unprepare(struct clk_hw *hw) +{ + struct tps68470_clkdata *clkdata = to_tps68470_clkdata(hw); + + /* Disable clock first ... */ + regmap_update_bits(clkdata->regmap, TPS68470_REG_PLLCTL, TPS68470_PLL_EN_MASK, 0); + + /* ... and then tri-state the clock outputs. */ + regmap_write(clkdata->regmap, TPS68470_REG_CLKCFG1, 0); +} + +static unsigned long tps68470_clk_recalc_rate(struct clk_hw *hw, unsigned long parent_rate) +{ + struct tps68470_clkdata *clkdata = to_tps68470_clkdata(hw); + + return clk_freqs[clkdata->clk_cfg_idx].freq; +} + +/* + * This returns the index of the clk_freqs[] cfg with the closest rate for + * use in tps68470_clk_round_rate(). tps68470_clk_set_rate() checks that + * the rate of the returned cfg is an exact match. + */ +static unsigned int tps68470_clk_cfg_lookup(unsigned long rate) +{ + long diff, best_diff = LONG_MAX; + unsigned int i, best_idx = 0; + + for (i = 0; i < ARRAY_SIZE(clk_freqs); i++) { + diff = clk_freqs[i].freq - rate; + if (diff == 0) + return i; + + diff = abs(diff); + if (diff < best_diff) { + best_diff = diff; + best_idx = i; + } + } + + return best_idx; +} + +static long tps68470_clk_round_rate(struct clk_hw *hw, unsigned long rate, + unsigned long *parent_rate) +{ + unsigned int idx = tps68470_clk_cfg_lookup(rate); + + return clk_freqs[idx].freq; +} + +static int tps68470_clk_set_rate(struct clk_hw *hw, unsigned long rate, + unsigned long parent_rate) +{ + struct tps68470_clkdata *clkdata = to_tps68470_clkdata(hw); + unsigned int idx = tps68470_clk_cfg_lookup(rate); + + if (rate != clk_freqs[idx].freq) + return -EINVAL; + + clkdata->clk_cfg_idx = idx; + + return 0; +} + +static const struct clk_ops tps68470_clk_ops = { + .is_prepared = tps68470_clk_is_prepared, + .prepare = tps68470_clk_prepare, + .unprepare = tps68470_clk_unprepare, + .recalc_rate = tps68470_clk_recalc_rate, + .round_rate = tps68470_clk_round_rate, + .set_rate = tps68470_clk_set_rate, +}; + +static const struct clk_init_data tps68470_clk_initdata = { + .name = TPS68470_CLK_NAME, + .ops = &tps68470_clk_ops, +}; + +static int tps68470_clk_probe(struct platform_device *pdev) +{ + struct tps68470_clk_platform_data *pdata = pdev->dev.platform_data; + struct tps68470_clkdata *tps68470_clkdata; + int ret; + + tps68470_clkdata = devm_kzalloc(&pdev->dev, sizeof(*tps68470_clkdata), + GFP_KERNEL); + if (!tps68470_clkdata) + return -ENOMEM; + + tps68470_clkdata->regmap = dev_get_drvdata(pdev->dev.parent); + tps68470_clkdata->clkout_hw.init = &tps68470_clk_initdata; + ret = devm_clk_hw_register(&pdev->dev, &tps68470_clkdata->clkout_hw); + if (ret) + return ret; + + ret = devm_clk_hw_register_clkdev(&pdev->dev, &tps68470_clkdata->clkout_hw, + TPS68470_CLK_NAME, NULL); + if (ret) + return ret; + + if (pdata) { + ret = devm_clk_hw_register_clkdev(&pdev->dev, + &tps68470_clkdata->clkout_hw, + pdata->consumer_con_id, + pdata->consumer_dev_name); + } + + return ret; +} + +static struct platform_driver tps68470_clk_driver = { + .driver = { + .name = TPS68470_CLK_NAME, + }, + .probe = tps68470_clk_probe, +}; + +/* + * The ACPI tps68470 probe-ordering depends on the clk/gpio/regulator drivers + * registering before the drivers for the camera-sensors which use them bind. + * subsys_initcall() ensures this when the drivers are builtin. + */ +static int __init tps68470_clk_init(void) +{ + return platform_driver_register(&tps68470_clk_driver); +} +subsys_initcall(tps68470_clk_init); + +static void __exit tps68470_clk_exit(void) +{ + platform_driver_unregister(&tps68470_clk_driver); +} +module_exit(tps68470_clk_exit); + +MODULE_ALIAS("platform:tps68470-clk"); +MODULE_DESCRIPTION("clock driver for TPS68470 pmic"); +MODULE_LICENSE("GPL"); diff --git a/include/linux/mfd/tps68470.h b/include/linux/mfd/tps68470.h index ffe81127d91c..7807fa329db0 100644 --- a/include/linux/mfd/tps68470.h +++ b/include/linux/mfd/tps68470.h @@ -75,6 +75,17 @@ #define TPS68470_CLKCFG1_MODE_A_MASK GENMASK(1, 0) #define TPS68470_CLKCFG1_MODE_B_MASK GENMASK(3, 2) +#define TPS68470_CLKCFG2_DRV_STR_2MA 0x05 +#define TPS68470_PLL_OUTPUT_ENABLE 0x02 +#define TPS68470_CLK_SRC_XTAL BIT(0) +#define TPS68470_PLLSWR_DEFAULT GENMASK(1, 0) +#define TPS68470_OSC_EXT_CAP_DEFAULT 0x05 + +#define TPS68470_OUTPUT_A_SHIFT 0x00 +#define TPS68470_OUTPUT_B_SHIFT 0x02 +#define TPS68470_CLK_SRC_SHIFT GENMASK(2, 0) +#define TPS68470_OSC_EXT_CAP_SHIFT BIT(2) + #define TPS68470_GPIO_CTL_REG_A(x) (TPS68470_REG_GPCTL0A + (x) * 2) #define TPS68470_GPIO_CTL_REG_B(x) (TPS68470_REG_GPCTL0B + (x) * 2) #define TPS68470_GPIO_MODE_MASK GENMASK(1, 0) -- 2.31.1 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
[parent not found: <163588780885.2993099.2088131017920983969@swboyd.mtv.corp.google.com>]
* Re: [not found] ` <163588780885.2993099.2088131017920983969@swboyd.mtv.corp.google.com> @ 2021-11-25 15:01 ` Hans de Goede 0 siblings, 0 replies; 1767+ messages in thread From: Hans de Goede @ 2021-11-25 15:01 UTC (permalink / raw) To: Stephen Boyd, Andy Shevchenko, Daniel Scally, Laurent Pinchart, Liam Girdwood, Mark Brown, Mark Gross, Mauro Carvalho Chehab, Michael Turquette, Mika Westerberg, Rafael J.Wysocki, Wolfram Sang Cc: Len Brown, linux-acpi, platform-driver-x86, linux-kernel, linux-i2c, Sakari Ailus, Kate Hsuan, linux-media, linux-clk Hi, On 11/2/21 22:16, Stephen Boyd wrote: > Quoting Hans de Goede (2021-11-02 02:49:01) >> diff --git a/drivers/clk/clk-tps68470.c b/drivers/clk/clk-tps68470.c >> new file mode 100644 >> index 000000000000..2ad0ac2f4096 >> --- /dev/null >> +++ b/drivers/clk/clk-tps68470.c >> @@ -0,0 +1,257 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * Clock driver for TPS68470 PMIC >> + * >> + * Copyright (c) 2021 Red Hat Inc. >> + * Copyright (C) 2018 Intel Corporation >> + * >> + * Authors: >> + * Hans de Goede <hdegoede@redhat.com> >> + * Zaikuo Wang <zaikuo.wang@intel.com> >> + * Tianshu Qiu <tian.shu.qiu@intel.com> >> + * Jian Xu Zheng <jian.xu.zheng@intel.com> >> + * Yuning Pu <yuning.pu@intel.com> >> + * Antti Laakso <antti.laakso@intel.com> >> + */ >> + >> +#include <linux/clk-provider.h> >> +#include <linux/clkdev.h> >> +#include <linux/kernel.h> >> +#include <linux/mfd/tps68470.h> >> +#include <linux/module.h> >> +#include <linux/platform_device.h> >> +#include <linux/platform_data/tps68470.h> >> +#include <linux/regmap.h> >> + >> +#define TPS68470_CLK_NAME "tps68470-clk" >> + >> +#define to_tps68470_clkdata(clkd) \ >> + container_of(clkd, struct tps68470_clkdata, clkout_hw) >> + > [...] >> + >> +static int tps68470_clk_set_rate(struct clk_hw *hw, unsigned long rate, >> + unsigned long parent_rate) >> +{ >> + struct tps68470_clkdata *clkdata = to_tps68470_clkdata(hw); >> + unsigned int idx = tps68470_clk_cfg_lookup(rate); >> + >> + if (rate != clk_freqs[idx].freq) >> + return -EINVAL; >> + >> + clkdata->clk_cfg_idx = idx; > > It deserves a comment that set_rate can only be called when the clk is > gated. We have CLK_SET_RATE_GATE flag as well that should be set if the > clk can't support changing rate while enabled. With that flag set, this > function should be able to actually change hardware with the assumption > that the framework won't call down into this clk_op when the clk is > enabled. Ok for v6 I've added the CLK_SET_RATE_GATE flag + a comment why it used and moved the divider programming to tps68470_clk_set_rate()m while keeping the PLL_EN + output-enable writes in tps68470_clk_prepare() > >> + >> + return 0; >> +} >> + >> +static const struct clk_ops tps68470_clk_ops = { >> + .is_prepared = tps68470_clk_is_prepared, >> + .prepare = tps68470_clk_prepare, >> + .unprepare = tps68470_clk_unprepare, >> + .recalc_rate = tps68470_clk_recalc_rate, >> + .round_rate = tps68470_clk_round_rate, >> + .set_rate = tps68470_clk_set_rate, >> +}; >> + >> +static const struct clk_init_data tps68470_clk_initdata = { > > Is there a reason to make this a static global? It's probably better to > throw it on the stack so that a structure isn't sitting around after > driver probe being unused. Fixed for v6. Thanks & Regards, Hans > >> + .name = TPS68470_CLK_NAME, >> + .ops = &tps68470_clk_ops, >> +}; > ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <20211011231530.GA22856@t>]
* (no subject) [not found] <20211011231530.GA22856@t> @ 2021-10-12 1:23 ` James Bottomley 2021-10-12 2:30 ` Bart Van Assche 0 siblings, 1 reply; 1767+ messages in thread From: James Bottomley @ 2021-10-12 1:23 UTC (permalink / raw) To: docfate111, linux-scsi On Mon, 2021-10-11 at 19:15 -0400, docfate111 wrote: > linux-scsi@vger.kernel.org, > linux-kernel@vger.kernel.org, > martin.petersen@oracle.com > Bcc: > Subject: [PATCH] scsi_lib fix the NULL pointer dereference > Reply-To: > > scsi_setup_scsi_cmnd should check for the pointer before > scsi_command_size dereferences it. Have you seen this? As in do you have a trace? This should be an impossible condition, so we need to see where it came from. The patch as proposed is not right, because if something is setting cmd_len without setting the cmnd pointer we need the cause fixed rather than applying a band aid in scsi_setup_scsi_cmnd(). James ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2021-10-12 1:23 ` James Bottomley @ 2021-10-12 2:30 ` Bart Van Assche 0 siblings, 0 replies; 1767+ messages in thread From: Bart Van Assche @ 2021-10-12 2:30 UTC (permalink / raw) To: jejb, docfate111, linux-scsi On 10/11/21 18:23, James Bottomley wrote: > On Mon, 2021-10-11 at 19:15 -0400, docfate111 wrote: >> linux-scsi@vger.kernel.org, >> linux-kernel@vger.kernel.org, >> martin.petersen@oracle.com >> Bcc: >> Subject: [PATCH] scsi_lib fix the NULL pointer dereference >> Reply-To: >> >> scsi_setup_scsi_cmnd should check for the pointer before >> scsi_command_size dereferences it. > > Have you seen this? As in do you have a trace? This should be an > impossible condition, so we need to see where it came from. The patch > as proposed is not right, because if something is setting cmd_len > without setting the cmnd pointer we need the cause fixed rather than > applying a band aid in scsi_setup_scsi_cmnd(). Hi James and Thelford, This patch looks like a duplicate of a patch posted one month ago? I think Christoph agrees to remove the cmd_len == 0 check. See also https://lore.kernel.org/linux-scsi/20210904064534.1919476-1-qiulaibin@huawei.com/. Thanks, Bart. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2021-10-08 1:24 Dmitry Baryshkov
2021-10-12 23:59 ` Linus Walleij
2021-10-17 21:35 ` Re: Linus Walleij
0 siblings, 2 replies; 1767+ messages in thread
From: Dmitry Baryshkov @ 2021-10-08 1:24 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Linus Walleij, Rob Herring
Cc: linux-gpio, devicetree, linux-arm-msm
In 2019 (in kernel 5.4) spmi-gpio and ssbi-gpio drivers were converted
to hierarchical IRQ helpers, however MPP drivers were not converted at
that moment. Complete this by converting MPP drivers.
Changes since v2:
- Add patches fixing/updating mpps nodes in the existing device trees
Changes since v1:
- Drop the interrupt-controller from initial schema conversion
- Add gpio-line-names to the qcom,pmic-mpp schema and to the example
The following changes since commit 6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f:
Linux 5.15-rc1 (2021-09-12 16:28:37 -0700)
are available in the Git repository at:
https://git.linaro.org/people/dmitry.baryshkov/kernel.git spmi-mpp
for you to fetch changes up to 9bccc31fc5cec98f26ca639a2ee21a9831efe1de:
arm64: dts: qcom: pm8994: add interrupt controller properties (2021-10-08 04:19:33 +0300)
----------------------------------------------------------------
Dmitry Baryshkov (25):
dt-bindings: pinctrl: qcom,pmic-mpp: Convert qcom pmic mpp bindings to YAML
dt-bindings: mfd: qcom-pm8xxx: add missing child nodes
ARM: dts: qcom-apq8064: add gpio-ranges to mpps nodes
ARM: dts: qcom-msm8660: add gpio-ranges to mpps nodes
ARM: dts: qcom-pm8841: add gpio-ranges to mpps nodes
ARM: dts: qcom-pm8941: add gpio-ranges to mpps nodes
ARM: dts: qcom-pma8084: add gpio-ranges to mpps nodes
ARM: dts: qcom-mdm9615: add gpio-ranges to mpps node, fix its name
ARM: dts: qcom-apq8060-dragonboard: fix mpps state names
arm64: dts: qcom: pm8916: fix mpps device tree node
arm64: dts: qcom: pm8994: fix mpps device tree node
arm64: dts: qcom: apq8016-sbc: fix mpps state names
pinctrl: qcom: ssbi-mpp: hardcode IRQ counts
pinctrl: qcom: ssbi-mpp: add support for hierarchical IRQ chip
pinctrl: qcom: spmi-mpp: hardcode IRQ counts
pinctrl: qcom: spmi-mpp: add support for hierarchical IRQ chip
dt-bindings: pinctrl: qcom,pmic-mpp: switch to #interrupt-cells
ARM: dts: qcom-apq8064: add interrupt controller properties
ARM: dts: qcom-mdm9615: add interrupt controller properties
ARM: dts: qcom-msm8660: add interrupt controller properties
ARM: dts: qcom-pm8841: add interrupt controller properties
ARM: dts: qcom-pm8941: add interrupt controller properties
ARM: dts: qcom-pma8084: add interrupt controller properties
arm64: dts: qcom: pm8916: add interrupt controller properties
arm64: dts: qcom: pm8994: add interrupt controller properties
.../devicetree/bindings/mfd/qcom-pm8xxx.yaml | 12 ++
.../devicetree/bindings/pinctrl/qcom,pmic-mpp.txt | 187 --------------------
.../devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml | 188 +++++++++++++++++++++
arch/arm/boot/dts/qcom-apq8060-dragonboard.dts | 4 +-
arch/arm/boot/dts/qcom-apq8064.dtsi | 23 +--
arch/arm/boot/dts/qcom-mdm9615.dtsi | 12 +-
arch/arm/boot/dts/qcom-msm8660.dtsi | 17 +-
arch/arm/boot/dts/qcom-pm8841.dtsi | 7 +-
arch/arm/boot/dts/qcom-pm8941.dtsi | 11 +-
arch/arm/boot/dts/qcom-pma8084.dtsi | 11 +-
arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 4 +-
arch/arm64/boot/dts/qcom/pm8916.dtsi | 9 +-
arch/arm64/boot/dts/qcom/pm8994.dtsi | 13 +-
drivers/pinctrl/qcom/pinctrl-spmi-mpp.c | 111 ++++++++----
drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c | 133 +++++++++++----
15 files changed, 414 insertions(+), 328 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt
create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2021-10-08 1:24 Dmitry Baryshkov @ 2021-10-12 23:59 ` Linus Walleij 2021-10-13 3:46 ` Re: Dmitry Baryshkov 2021-10-17 16:54 ` Re: Bjorn Andersson 2021-10-17 21:35 ` Re: Linus Walleij 1 sibling, 2 replies; 1767+ messages in thread From: Linus Walleij @ 2021-10-12 23:59 UTC (permalink / raw) To: Dmitry Baryshkov Cc: Andy Gross, Bjorn Andersson, Rob Herring, open list:GPIO SUBSYSTEM, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, MSM On Fri, Oct 8, 2021 at 3:25 AM Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote: > In 2019 (in kernel 5.4) spmi-gpio and ssbi-gpio drivers were converted > to hierarchical IRQ helpers, however MPP drivers were not converted at > that moment. Complete this by converting MPP drivers. > > Changes since v2: > - Add patches fixing/updating mpps nodes in the existing device trees Thanks a *lot* for being thorough and fixing all this properly! I am happy to apply the pinctrl portions to the pinctrl tree, I'm uncertain about Rob's syntax checker robot here, are there real problems? Sometimes it complains about things being changed in the DTS files at the same time. I could apply all of this (including DTS changes) to an immutable branch and offer to Bjorn if he is fine with the patches and the general approach. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2021-10-12 23:59 ` Linus Walleij @ 2021-10-13 3:46 ` Dmitry Baryshkov 2021-10-13 23:39 ` Re: Linus Walleij 2021-10-17 16:54 ` Re: Bjorn Andersson 1 sibling, 1 reply; 1767+ messages in thread From: Dmitry Baryshkov @ 2021-10-13 3:46 UTC (permalink / raw) To: Linus Walleij Cc: Andy Gross, Bjorn Andersson, Rob Herring, open list:GPIO SUBSYSTEM, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, MSM On Wed, 13 Oct 2021 at 02:59, Linus Walleij <linus.walleij@linaro.org> wrote: > > On Fri, Oct 8, 2021 at 3:25 AM Dmitry Baryshkov > <dmitry.baryshkov@linaro.org> wrote: > > > In 2019 (in kernel 5.4) spmi-gpio and ssbi-gpio drivers were converted > > to hierarchical IRQ helpers, however MPP drivers were not converted at > > that moment. Complete this by converting MPP drivers. > > > > Changes since v2: > > - Add patches fixing/updating mpps nodes in the existing device trees > > Thanks a *lot* for being thorough and fixing all this properly! > > I am happy to apply the pinctrl portions to the pinctrl tree, I'm > uncertain about Rob's syntax checker robot here, are there real > problems? Sometimes it complains about things being changed > in the DTS files at the same time. Rob's checker reports issue that are being fixed by respective patches. I think I've updated all dts entries for the mpp devices tree nodes. > I could apply all of this (including DTS changes) to an immutable > branch and offer to Bjorn if he is fine with the patches and > the general approach. I'm fine with either approach. -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2021-10-13 3:46 ` Re: Dmitry Baryshkov @ 2021-10-13 23:39 ` Linus Walleij 0 siblings, 0 replies; 1767+ messages in thread From: Linus Walleij @ 2021-10-13 23:39 UTC (permalink / raw) To: Dmitry Baryshkov Cc: Andy Gross, Bjorn Andersson, Rob Herring, open list:GPIO SUBSYSTEM, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, MSM On Wed, Oct 13, 2021 at 5:46 AM Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote: > On Wed, 13 Oct 2021 at 02:59, Linus Walleij <linus.walleij@linaro.org> wrote: > > I am happy to apply the pinctrl portions to the pinctrl tree, I'm > > uncertain about Rob's syntax checker robot here, are there real > > problems? Sometimes it complains about things being changed > > in the DTS files at the same time. > > Rob's checker reports issue that are being fixed by respective > patches. I think I've updated all dts entries for the mpp devices tree > nodes. > > > I could apply all of this (including DTS changes) to an immutable > > branch and offer to Bjorn if he is fine with the patches and > > the general approach. > > I'm fine with either approach. Let's see what Bjorn says, if nothing happens poke me again and I'll create an immutable branch and merge it. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2021-10-12 23:59 ` Linus Walleij 2021-10-13 3:46 ` Re: Dmitry Baryshkov @ 2021-10-17 16:54 ` Bjorn Andersson 2021-10-17 21:31 ` Re: Linus Walleij 1 sibling, 1 reply; 1767+ messages in thread From: Bjorn Andersson @ 2021-10-17 16:54 UTC (permalink / raw) To: Linus Walleij Cc: Dmitry Baryshkov, Andy Gross, Rob Herring, open list:GPIO SUBSYSTEM, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, MSM On Tue 12 Oct 18:59 CDT 2021, Linus Walleij wrote: > On Fri, Oct 8, 2021 at 3:25 AM Dmitry Baryshkov > <dmitry.baryshkov@linaro.org> wrote: > > > In 2019 (in kernel 5.4) spmi-gpio and ssbi-gpio drivers were converted > > to hierarchical IRQ helpers, however MPP drivers were not converted at > > that moment. Complete this by converting MPP drivers. > > > > Changes since v2: > > - Add patches fixing/updating mpps nodes in the existing device trees > > Thanks a *lot* for being thorough and fixing all this properly! > > I am happy to apply the pinctrl portions to the pinctrl tree, I'm > uncertain about Rob's syntax checker robot here, are there real > problems? Sometimes it complains about things being changed > in the DTS files at the same time. > > I could apply all of this (including DTS changes) to an immutable > branch and offer to Bjorn if he is fine with the patches and > the general approach. > I like the driver changes and I'm wrapping up a second pull for the dts pieces in the coming few days. So if you're happy to take the driver patches I'll include the DT changes for 5.16 as well. Thanks, Bjorn ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2021-10-17 16:54 ` Re: Bjorn Andersson @ 2021-10-17 21:31 ` Linus Walleij 0 siblings, 0 replies; 1767+ messages in thread From: Linus Walleij @ 2021-10-17 21:31 UTC (permalink / raw) To: Bjorn Andersson Cc: Dmitry Baryshkov, Andy Gross, Rob Herring, open list:GPIO SUBSYSTEM, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, MSM On Sun, Oct 17, 2021 at 6:54 PM Bjorn Andersson <bjorn.andersson@linaro.org> wrote: > I like the driver changes and I'm wrapping up a second pull for the dts > pieces in the coming few days. So if you're happy to take the driver > patches I'll include the DT changes for 5.16 as well. OK let's do like that. I'll queue the binding changes and driver changes so we finally get this fixed up. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2021-10-08 1:24 Dmitry Baryshkov 2021-10-12 23:59 ` Linus Walleij @ 2021-10-17 21:35 ` Linus Walleij 1 sibling, 0 replies; 1767+ messages in thread From: Linus Walleij @ 2021-10-17 21:35 UTC (permalink / raw) To: Dmitry Baryshkov Cc: Andy Gross, Bjorn Andersson, Rob Herring, open list:GPIO SUBSYSTEM, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, MSM I queued thes patches in the pinctrl tree for v5.16: On Fri, Oct 8, 2021 at 3:25 AM Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote: > dt-bindings: pinctrl: qcom,pmic-mpp: Convert qcom pmic mpp bindings to YAML > pinctrl: qcom: ssbi-mpp: hardcode IRQ counts > pinctrl: qcom: ssbi-mpp: add support for hierarchical IRQ chip > pinctrl: qcom: spmi-mpp: hardcode IRQ counts > pinctrl: qcom: spmi-mpp: add support for hierarchical IRQ chip > dt-bindings: pinctrl: qcom,pmic-mpp: switch to #interrupt-cells Any breakages will be fixed when Bjorn applies the DTS changes to his tree. I wonder about the MFD patch, maybe Lee can expedite merging that too or ACK it for Bjorn to merge with the remainders. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2021-09-03 20:51 Mr. James Khmalo 0 siblings, 0 replies; 1767+ messages in thread From: Mr. James Khmalo @ 2021-09-03 20:51 UTC (permalink / raw) To: soc Good Day, I know this email might come to you as a surprise as first coming from one you haven’t met with before. I am Mr. James Khmalo, the bank manager with ABSA bank of South Africa, and a personal banker of Dr.Mohamed Farouk Ibrahim, an Egyptian who happened to be a medical contractor attached to the overthrown Afghan government by the Taliban government. Dr.Mohamed Farouk Ibrahim deposits some sum of money with our bank but passed away with his family while trying to escape from Kandahar. The said sum can be used for an investment if you are interested. Details relating to the funds are in my position and will present you as the Next-of-Kin because there was none, and I shall furnish you with more detail once your response. Regards, Mr. James Khmalo Tel: 27-632696383 South Africa ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <CAKPXbjesQH_k1Z7k4kNwpoAf-jYgbUaPqPCgNTJZ35peVBy_pA@mail.gmail.com>]
* Re: [not found] <CAKPXbjesQH_k1Z7k4kNwpoAf-jYgbUaPqPCgNTJZ35peVBy_pA@mail.gmail.com> @ 2021-08-29 12:01 ` Lukas Bulwahn 0 siblings, 0 replies; 1767+ messages in thread From: Lukas Bulwahn @ 2021-08-29 12:01 UTC (permalink / raw) To: Harshita; +Cc: linux-kernel-mentees On Sat, Aug 28, 2021 at 4:18 AM Harshita <hrsa.kshyp@gmail.com> wrote: > > Hello, I m Harshita. > > I am interested in the Checkpatch Documentation mentorship program and I would like to work on the tasks for the mentee selection. > Sorry, you were too late and missed the deadline. Please re-apply for the next period. Lukas _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH v9] iomap: Support file tail packing @ 2021-07-27 2:59 Gao Xiang 2021-07-27 15:10 ` Darrick J. Wong 0 siblings, 1 reply; 1767+ messages in thread From: Gao Xiang @ 2021-07-27 2:59 UTC (permalink / raw) To: linux-erofs, linux-fsdevel Cc: Andreas Gruenbacher, Darrick J . Wong, LKML, Matthew Wilcox, Joseph Qi, Christoph Hellwig The existing inline data support only works for cases where the entire file is stored as inline data. For larger files, EROFS stores the initial blocks separately and then can pack a small tail adjacent to the inode. Generalise inline data to allow for tail packing. Tails may not cross a page boundary in memory. We currently have no filesystems that support tail packing and writing, so that case is currently disabled (see iomap_write_begin_inline). Cc: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> --- v8: https://lore.kernel.org/r/20210726145734.214295-1-hsiangkao@linux.alibaba.com changes since v8: - update the subject to 'iomap: Support file tail packing' as there are clearly a number of ways to make the inline data support more flexible (Matthew); - add one extra safety check (Darrick): if (WARN_ON_ONCE(size > iomap->length)) return -EIO; fs/iomap/buffered-io.c | 42 ++++++++++++++++++++++++++++++------------ fs/iomap/direct-io.c | 10 ++++++---- include/linux/iomap.h | 18 ++++++++++++++++++ 3 files changed, 54 insertions(+), 16 deletions(-) diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c index 87ccb3438bec..f429b9d87dbe 100644 --- a/fs/iomap/buffered-io.c +++ b/fs/iomap/buffered-io.c @@ -205,25 +205,32 @@ struct iomap_readpage_ctx { struct readahead_control *rac; }; -static void -iomap_read_inline_data(struct inode *inode, struct page *page, +static int iomap_read_inline_data(struct inode *inode, struct page *page, struct iomap *iomap) { - size_t size = i_size_read(inode); + size_t size = i_size_read(inode) - iomap->offset; void *addr; if (PageUptodate(page)) - return; + return 0; - BUG_ON(page_has_private(page)); - BUG_ON(page->index); - BUG_ON(size > PAGE_SIZE - offset_in_page(iomap->inline_data)); + /* inline data must start page aligned in the file */ + if (WARN_ON_ONCE(offset_in_page(iomap->offset))) + return -EIO; + if (WARN_ON_ONCE(size > PAGE_SIZE - + offset_in_page(iomap->inline_data))) + return -EIO; + if (WARN_ON_ONCE(size > iomap->length)) + return -EIO; + if (WARN_ON_ONCE(page_has_private(page))) + return -EIO; addr = kmap_atomic(page); memcpy(addr, iomap->inline_data, size); memset(addr + size, 0, PAGE_SIZE - size); kunmap_atomic(addr); SetPageUptodate(page); + return 0; } static inline bool iomap_block_needs_zeroing(struct inode *inode, @@ -247,8 +254,10 @@ iomap_readpage_actor(struct inode *inode, loff_t pos, loff_t length, void *data, sector_t sector; if (iomap->type == IOMAP_INLINE) { - WARN_ON_ONCE(pos); - iomap_read_inline_data(inode, page, iomap); + int ret = iomap_read_inline_data(inode, page, iomap); + + if (ret) + return ret; return PAGE_SIZE; } @@ -589,6 +598,15 @@ __iomap_write_begin(struct inode *inode, loff_t pos, unsigned len, int flags, return 0; } +static int iomap_write_begin_inline(struct inode *inode, + struct page *page, struct iomap *srcmap) +{ + /* needs more work for the tailpacking case, disable for now */ + if (WARN_ON_ONCE(srcmap->offset != 0)) + return -EIO; + return iomap_read_inline_data(inode, page, srcmap); +} + static int iomap_write_begin(struct inode *inode, loff_t pos, unsigned len, unsigned flags, struct page **pagep, struct iomap *iomap, struct iomap *srcmap) @@ -618,7 +636,7 @@ iomap_write_begin(struct inode *inode, loff_t pos, unsigned len, unsigned flags, } if (srcmap->type == IOMAP_INLINE) - iomap_read_inline_data(inode, page, srcmap); + status = iomap_write_begin_inline(inode, page, srcmap); else if (iomap->flags & IOMAP_F_BUFFER_HEAD) status = __block_write_begin_int(page, pos, len, NULL, srcmap); else @@ -671,11 +689,11 @@ static size_t iomap_write_end_inline(struct inode *inode, struct page *page, void *addr; WARN_ON_ONCE(!PageUptodate(page)); - BUG_ON(pos + copied > PAGE_SIZE - offset_in_page(iomap->inline_data)); + BUG_ON(!iomap_inline_data_valid(iomap)); flush_dcache_page(page); addr = kmap_atomic(page); - memcpy(iomap->inline_data + pos, addr + pos, copied); + memcpy(iomap_inline_data(iomap, pos), addr + pos, copied); kunmap_atomic(addr); mark_inode_dirty(inode); diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c index 9398b8c31323..41ccbfc9dc82 100644 --- a/fs/iomap/direct-io.c +++ b/fs/iomap/direct-io.c @@ -378,23 +378,25 @@ iomap_dio_inline_actor(struct inode *inode, loff_t pos, loff_t length, struct iomap_dio *dio, struct iomap *iomap) { struct iov_iter *iter = dio->submit.iter; + void *inline_data = iomap_inline_data(iomap, pos); size_t copied; - BUG_ON(pos + length > PAGE_SIZE - offset_in_page(iomap->inline_data)); + if (WARN_ON_ONCE(!iomap_inline_data_valid(iomap))) + return -EIO; if (dio->flags & IOMAP_DIO_WRITE) { loff_t size = inode->i_size; if (pos > size) - memset(iomap->inline_data + size, 0, pos - size); - copied = copy_from_iter(iomap->inline_data + pos, length, iter); + memset(iomap_inline_data(iomap, size), 0, pos - size); + copied = copy_from_iter(inline_data, length, iter); if (copied) { if (pos + copied > size) i_size_write(inode, pos + copied); mark_inode_dirty(inode); } } else { - copied = copy_to_iter(iomap->inline_data + pos, length, iter); + copied = copy_to_iter(inline_data, length, iter); } dio->size += copied; return copied; diff --git a/include/linux/iomap.h b/include/linux/iomap.h index 479c1da3e221..b8ec145b2975 100644 --- a/include/linux/iomap.h +++ b/include/linux/iomap.h @@ -97,6 +97,24 @@ iomap_sector(struct iomap *iomap, loff_t pos) return (iomap->addr + pos - iomap->offset) >> SECTOR_SHIFT; } +/* + * Returns the inline data pointer for logical offset @pos. + */ +static inline void *iomap_inline_data(struct iomap *iomap, loff_t pos) +{ + return iomap->inline_data + pos - iomap->offset; +} + +/* + * Check if the mapping's length is within the valid range for inline data. + * This is used to guard against accessing data beyond the page inline_data + * points at. + */ +static inline bool iomap_inline_data_valid(struct iomap *iomap) +{ + return iomap->length <= PAGE_SIZE - offset_in_page(iomap->inline_data); +} + /* * When a filesystem sets page_ops in an iomap mapping it returns, page_prepare * and page_done will be called for each page written to. This only applies to -- 2.24.4 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* (no subject) 2021-07-27 2:59 [PATCH v9] iomap: Support file tail packing Gao Xiang @ 2021-07-27 15:10 ` Darrick J. Wong 2021-07-27 15:23 ` Andreas Grünbacher 2021-07-27 15:30 ` Re: Gao Xiang 0 siblings, 2 replies; 1767+ messages in thread From: Darrick J. Wong @ 2021-07-27 15:10 UTC (permalink / raw) To: Gao Xiang Cc: Andreas Gruenbacher, LKML, Matthew Wilcox, Joseph Qi, linux-fsdevel, linux-erofs, Christoph Hellwig I'll change the subject to: iomap: support reading inline data from non-zero pos The existing inline data support only works for cases where the entire file is stored as inline data. For larger files, EROFS stores the initial blocks separately and the remainder of the file ("file tail") adjacent to the inode. Generalise inline data to allow reading the inline file tail. Tails may not cross a page boundary in memory. We currently have no filesystems that support tails and writing, so that case is currently disabled (see iomap_write_begin_inline). If that's ok with everyone, Reviewed-by: Darrick J. Wong <djwong@kernel.org> --D On Tue, Jul 27, 2021 at 10:59:56AM +0800, Gao Xiang wrote: > The existing inline data support only works for cases where the entire > file is stored as inline data. For larger files, EROFS stores the > initial blocks separately and then can pack a small tail adjacent to the > inode. Generalise inline data to allow for tail packing. Tails may not > cross a page boundary in memory. > > We currently have no filesystems that support tail packing and writing, > so that case is currently disabled (see iomap_write_begin_inline). > > Cc: Darrick J. Wong <djwong@kernel.org> > Reviewed-by: Christoph Hellwig <hch@lst.de> > Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org> > Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> > Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> > --- > v8: https://lore.kernel.org/r/20210726145734.214295-1-hsiangkao@linux.alibaba.com > changes since v8: > - update the subject to 'iomap: Support file tail packing' as there > are clearly a number of ways to make the inline data support more > flexible (Matthew); > > - add one extra safety check (Darrick): > if (WARN_ON_ONCE(size > iomap->length)) > return -EIO; > > fs/iomap/buffered-io.c | 42 ++++++++++++++++++++++++++++++------------ > fs/iomap/direct-io.c | 10 ++++++---- > include/linux/iomap.h | 18 ++++++++++++++++++ > 3 files changed, 54 insertions(+), 16 deletions(-) > > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c > index 87ccb3438bec..f429b9d87dbe 100644 > --- a/fs/iomap/buffered-io.c > +++ b/fs/iomap/buffered-io.c > @@ -205,25 +205,32 @@ struct iomap_readpage_ctx { > struct readahead_control *rac; > }; > > -static void > -iomap_read_inline_data(struct inode *inode, struct page *page, > +static int iomap_read_inline_data(struct inode *inode, struct page *page, > struct iomap *iomap) > { > - size_t size = i_size_read(inode); > + size_t size = i_size_read(inode) - iomap->offset; > void *addr; > > if (PageUptodate(page)) > - return; > + return 0; > > - BUG_ON(page_has_private(page)); > - BUG_ON(page->index); > - BUG_ON(size > PAGE_SIZE - offset_in_page(iomap->inline_data)); > + /* inline data must start page aligned in the file */ > + if (WARN_ON_ONCE(offset_in_page(iomap->offset))) > + return -EIO; > + if (WARN_ON_ONCE(size > PAGE_SIZE - > + offset_in_page(iomap->inline_data))) > + return -EIO; > + if (WARN_ON_ONCE(size > iomap->length)) > + return -EIO; > + if (WARN_ON_ONCE(page_has_private(page))) > + return -EIO; > > addr = kmap_atomic(page); > memcpy(addr, iomap->inline_data, size); > memset(addr + size, 0, PAGE_SIZE - size); > kunmap_atomic(addr); > SetPageUptodate(page); > + return 0; > } > > static inline bool iomap_block_needs_zeroing(struct inode *inode, > @@ -247,8 +254,10 @@ iomap_readpage_actor(struct inode *inode, loff_t pos, loff_t length, void *data, > sector_t sector; > > if (iomap->type == IOMAP_INLINE) { > - WARN_ON_ONCE(pos); > - iomap_read_inline_data(inode, page, iomap); > + int ret = iomap_read_inline_data(inode, page, iomap); > + > + if (ret) > + return ret; > return PAGE_SIZE; > } > > @@ -589,6 +598,15 @@ __iomap_write_begin(struct inode *inode, loff_t pos, unsigned len, int flags, > return 0; > } > > +static int iomap_write_begin_inline(struct inode *inode, > + struct page *page, struct iomap *srcmap) > +{ > + /* needs more work for the tailpacking case, disable for now */ > + if (WARN_ON_ONCE(srcmap->offset != 0)) > + return -EIO; > + return iomap_read_inline_data(inode, page, srcmap); > +} > + > static int > iomap_write_begin(struct inode *inode, loff_t pos, unsigned len, unsigned flags, > struct page **pagep, struct iomap *iomap, struct iomap *srcmap) > @@ -618,7 +636,7 @@ iomap_write_begin(struct inode *inode, loff_t pos, unsigned len, unsigned flags, > } > > if (srcmap->type == IOMAP_INLINE) > - iomap_read_inline_data(inode, page, srcmap); > + status = iomap_write_begin_inline(inode, page, srcmap); > else if (iomap->flags & IOMAP_F_BUFFER_HEAD) > status = __block_write_begin_int(page, pos, len, NULL, srcmap); > else > @@ -671,11 +689,11 @@ static size_t iomap_write_end_inline(struct inode *inode, struct page *page, > void *addr; > > WARN_ON_ONCE(!PageUptodate(page)); > - BUG_ON(pos + copied > PAGE_SIZE - offset_in_page(iomap->inline_data)); > + BUG_ON(!iomap_inline_data_valid(iomap)); > > flush_dcache_page(page); > addr = kmap_atomic(page); > - memcpy(iomap->inline_data + pos, addr + pos, copied); > + memcpy(iomap_inline_data(iomap, pos), addr + pos, copied); > kunmap_atomic(addr); > > mark_inode_dirty(inode); > diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c > index 9398b8c31323..41ccbfc9dc82 100644 > --- a/fs/iomap/direct-io.c > +++ b/fs/iomap/direct-io.c > @@ -378,23 +378,25 @@ iomap_dio_inline_actor(struct inode *inode, loff_t pos, loff_t length, > struct iomap_dio *dio, struct iomap *iomap) > { > struct iov_iter *iter = dio->submit.iter; > + void *inline_data = iomap_inline_data(iomap, pos); > size_t copied; > > - BUG_ON(pos + length > PAGE_SIZE - offset_in_page(iomap->inline_data)); > + if (WARN_ON_ONCE(!iomap_inline_data_valid(iomap))) > + return -EIO; > > if (dio->flags & IOMAP_DIO_WRITE) { > loff_t size = inode->i_size; > > if (pos > size) > - memset(iomap->inline_data + size, 0, pos - size); > - copied = copy_from_iter(iomap->inline_data + pos, length, iter); > + memset(iomap_inline_data(iomap, size), 0, pos - size); > + copied = copy_from_iter(inline_data, length, iter); > if (copied) { > if (pos + copied > size) > i_size_write(inode, pos + copied); > mark_inode_dirty(inode); > } > } else { > - copied = copy_to_iter(iomap->inline_data + pos, length, iter); > + copied = copy_to_iter(inline_data, length, iter); > } > dio->size += copied; > return copied; > diff --git a/include/linux/iomap.h b/include/linux/iomap.h > index 479c1da3e221..b8ec145b2975 100644 > --- a/include/linux/iomap.h > +++ b/include/linux/iomap.h > @@ -97,6 +97,24 @@ iomap_sector(struct iomap *iomap, loff_t pos) > return (iomap->addr + pos - iomap->offset) >> SECTOR_SHIFT; > } > > +/* > + * Returns the inline data pointer for logical offset @pos. > + */ > +static inline void *iomap_inline_data(struct iomap *iomap, loff_t pos) > +{ > + return iomap->inline_data + pos - iomap->offset; > +} > + > +/* > + * Check if the mapping's length is within the valid range for inline data. > + * This is used to guard against accessing data beyond the page inline_data > + * points at. > + */ > +static inline bool iomap_inline_data_valid(struct iomap *iomap) > +{ > + return iomap->length <= PAGE_SIZE - offset_in_page(iomap->inline_data); > +} > + > /* > * When a filesystem sets page_ops in an iomap mapping it returns, page_prepare > * and page_done will be called for each page written to. This only applies to > -- > 2.24.4 > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2021-07-27 15:10 ` Darrick J. Wong @ 2021-07-27 15:23 ` Andreas Grünbacher 2021-07-27 15:30 ` Re: Gao Xiang 1 sibling, 0 replies; 1767+ messages in thread From: Andreas Grünbacher @ 2021-07-27 15:23 UTC (permalink / raw) To: Darrick J. Wong Cc: Andreas Gruenbacher, LKML, Matthew Wilcox, Joseph Qi, Linux FS-devel Mailing List, linux-erofs, Christoph Hellwig Am Di., 27. Juli 2021 um 17:11 Uhr schrieb Darrick J. Wong <djwong@kernel.org>: > I'll change the subject to: > > iomap: support reading inline data from non-zero pos That surely works for me. Thanks, Andreas ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2021-07-27 15:10 ` Darrick J. Wong 2021-07-27 15:23 ` Andreas Grünbacher @ 2021-07-27 15:30 ` Gao Xiang 1 sibling, 0 replies; 1767+ messages in thread From: Gao Xiang @ 2021-07-27 15:30 UTC (permalink / raw) To: Darrick J. Wong Cc: Andreas Gruenbacher, LKML, Matthew Wilcox, Joseph Qi, linux-fsdevel, linux-erofs, Christoph Hellwig On Tue, Jul 27, 2021 at 08:10:51AM -0700, Darrick J. Wong wrote: > I'll change the subject to: > > iomap: support reading inline data from non-zero pos I'm fine with this too. Many thanks for updating! Thanks, Gao Xiang ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2021-07-16 17:07 Subhasmita Swain 2021-07-16 18:15 ` Lukas Bulwahn 0 siblings, 1 reply; 1767+ messages in thread From: Subhasmita Swain @ 2021-07-16 17:07 UTC (permalink / raw) To: lukas.bulwahn, linux-kernel-mentees [-- Attachment #1.1: Type: text/plain, Size: 125 bytes --] I am interested in the Mining Maintainers mentorship program and I would like to work on the tasks for the mentee selection. [-- Attachment #1.2: Type: text/html, Size: 343 bytes --] [-- Attachment #2: Type: text/plain, Size: 201 bytes --] _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2021-07-16 17:07 Subhasmita Swain @ 2021-07-16 18:15 ` Lukas Bulwahn 0 siblings, 0 replies; 1767+ messages in thread From: Lukas Bulwahn @ 2021-07-16 18:15 UTC (permalink / raw) To: Subhasmita Swain; +Cc: linux-kernel-mentees On Fri, Jul 16, 2021 at 7:07 PM Subhasmita Swain <subhasmitaofc@gmail.com> wrote: > > I am interested in the Mining Maintainers mentorship program and I would like to work on the tasks for the mentee selection. Thanks for your interest. For the mentee selection, please work on the following exercise: First, download the kernel git repository and compile the kernel with the x86-defconfig build configuration. There is a file called MAINTAINERS in the root directory of the git repository. Read the introduction at the beginning of the MAINTAINERS file and understand the content in the file and its organisation. Explain in your words: What is stored in the MAINTAINERS file? Now, search for specific MAINTAINER entries; Please answer: Who are the maintainers and reviewers of the following sections? AMD IOMMU (AMD-VI) DRIVER CORE, KOBJECTS, DEBUGFS AND SYSFS DRM DRIVERS FUTEX SUBSYSTEM I2C SUBSYSTEM JAILHOUSE HYPERVISOR INTERFACE KCOV KCSAN LINUX KERNEL MEMORY CONSISTENCY MODEL (LKMM) NAND FLASH SUBSYSTEM THE REST Please let me know about your answers and always send your responses to the linux-kernel-mentees mailing list. After that first exercise, exercises 2 and 3 will follow. Lukas _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <CAFBCWQJX4Xy8Sot7en5JBTuKrzy=_6xFkc+QgOxJEC7G6x+jzg@mail.gmail.com>]
* Re: [not found] <CAFBCWQJX4Xy8Sot7en5JBTuKrzy=_6xFkc+QgOxJEC7G6x+jzg@mail.gmail.com> @ 2021-06-12 3:43 ` Ammar Faizi 0 siblings, 0 replies; 1767+ messages in thread From: Ammar Faizi @ 2021-06-12 3:43 UTC (permalink / raw) To: io-uring subscribe io-uring ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2021-06-06 19:19 Davidlohr Bueso 2021-06-07 16:02 ` André Almeida 0 siblings, 1 reply; 1767+ messages in thread From: Davidlohr Bueso @ 2021-06-06 19:19 UTC (permalink / raw) To: Andr� Almeida Cc: Thomas Gleixner, Ingo Molnar, Peter Zijlstra, Darren Hart, linux-kernel, Steven Rostedt, Sebastian Andrzej Siewior, kernel, krisman, pgriffais, z.figura12, joel, malteskarupke, linux-api, fweimer, libc-alpha, linux-kselftest, shuah, acme, corbet, Peter Oskolkov, Andrey Semashev, mtk.manpages Bcc: Subject: Re: [PATCH v4 07/15] docs: locking: futex2: Add documentation Reply-To: In-Reply-To: <20210603195924.361327-8-andrealmeid@collabora.com> On Thu, 03 Jun 2021, Andr� Almeida wrote: >Add a new documentation file specifying both userspace API and internal >implementation details of futex2 syscalls. I think equally important would be to provide a manpage for each new syscall you are introducing, and keep mkt in the loop as in the past he extensively documented and improved futex manpages, and overall has a lot of experience with dealing with kernel interfaces. Thanks, Davidlohr > >Signed-off-by: André Almeida <andrealmeid@collabora.com> >--- > Documentation/locking/futex2.rst | 198 +++++++++++++++++++++++++++++++ > Documentation/locking/index.rst | 1 + > 2 files changed, 199 insertions(+) > create mode 100644 Documentation/locking/futex2.rst > >diff --git a/Documentation/locking/futex2.rst b/Documentation/locking/futex2.rst >new file mode 100644 >index 000000000000..2f74d7c97a55 >--- /dev/null >+++ b/Documentation/locking/futex2.rst >@@ -0,0 +1,198 @@ >+.. SPDX-License-Identifier: GPL-2.0 >+ >+====== >+futex2 >+====== >+ >+:Author: André Almeida <andrealmeid@collabora.com> >+ >+futex, or fast user mutex, is a set of syscalls to allow userspace to create >+performant synchronization mechanisms, such as mutexes, semaphores and >+conditional variables in userspace. C standard libraries, like glibc, uses it >+as a means to implement more high level interfaces like pthreads. >+ >+The interface >+============= >+ >+uAPI functions >+-------------- >+ >+.. kernel-doc:: kernel/futex2.c >+ :identifiers: sys_futex_wait sys_futex_wake sys_futex_waitv sys_futex_requeue >+ >+uAPI structures >+--------------- >+ >+.. kernel-doc:: include/uapi/linux/futex.h >+ >+The ``flag`` argument >+--------------------- >+ >+The flag is used to specify the size of the futex word >+(FUTEX_[8, 16, 32, 64]). It's mandatory to define one, since there's no >+default size. >+ >+By default, the timeout uses a monotonic clock, but can be used as a realtime >+one by using the FUTEX_REALTIME_CLOCK flag. >+ >+By default, futexes are of the private type, that means that this user address >+will be accessed by threads that share the same memory region. This allows for >+some internal optimizations, so they are faster. However, if the address needs >+to be shared with different processes (like using ``mmap()`` or ``shm()``), they >+need to be defined as shared and the flag FUTEX_SHARED_FLAG is used to set that. >+ >+By default, the operation has no NUMA-awareness, meaning that the user can't >+choose the memory node where the kernel side futex data will be stored. The >+user can choose the node where it wants to operate by setting the >+FUTEX_NUMA_FLAG and using the following structure (where X can be 8, 16, 32 or >+64):: >+ >+ struct futexX_numa { >+ __uX value; >+ __sX hint; >+ }; >+ >+This structure should be passed at the ``void *uaddr`` of futex functions. The >+address of the structure will be used to be waited on/waken on, and the >+``value`` will be compared to ``val`` as usual. The ``hint`` member is used to >+define which node the futex will use. When waiting, the futex will be >+registered on a kernel-side table stored on that node; when waking, the futex >+will be searched for on that given table. That means that there's no redundancy >+between tables, and the wrong ``hint`` value will lead to undesired behavior. >+Userspace is responsible for dealing with node migrations issues that may >+occur. ``hint`` can range from [0, MAX_NUMA_NODES), for specifying a node, or >+-1, to use the same node the current process is using. >+ >+When not using FUTEX_NUMA_FLAG on a NUMA system, the futex will be stored on a >+global table on allocated on the first node. >+ >+The ``timo`` argument >+--------------------- >+ >+As per the Y2038 work done in the kernel, new interfaces shouldn't add timeout >+options known to be buggy. Given that, ``timo`` should be a 64-bit timeout at >+all platforms, using an absolute timeout value. >+ >+Implementation >+============== >+ >+The internal implementation follows a similar design to the original futex. >+Given that we want to replicate the same external behavior of current futex, >+this should be somewhat expected. >+ >+Waiting >+------- >+ >+For the wait operations, they are all treated as if you want to wait on N >+futexes, so the path for futex_wait and futex_waitv is the basically the same. >+For both syscalls, the first step is to prepare an internal list for the list >+of futexes to wait for (using struct futexv_head). For futex_wait() calls, this >+list will have a single object. >+ >+We have a hash table, where waiters register themselves before sleeping. Then >+the wake function checks this table looking for waiters at uaddr. The hash >+bucket to be used is determined by a struct futex_key, that stores information >+to uniquely identify an address from a given process. Given the huge address >+space, there'll be hash collisions, so we store information to be later used on >+collision treatment. >+ >+First, for every futex we want to wait on, we check if (``*uaddr == val``). >+This check is done holding the bucket lock, so we are correctly serialized with >+any futex_wake() calls. If any waiter fails the check above, we dequeue all >+futexes. The check (``*uaddr == val``) can fail for two reasons: >+ >+- The values are different, and we return -EAGAIN. However, if while >+ dequeueing we found that some futexes were awakened, we prioritize this >+ and return success. >+ >+- When trying to access the user address, we do so with page faults >+ disabled because we are holding a bucket's spin lock (and can't sleep >+ while holding a spin lock). If there's an error, it might be a page >+ fault, or an invalid address. We release the lock, dequeue everyone >+ (because it's illegal to sleep while there are futexes enqueued, we >+ could lose wakeups) and try again with page fault enabled. If we >+ succeed, this means that the address is valid, but we need to do >+ all the work again. For serialization reasons, we need to have the >+ spin lock when getting the user value. Additionally, for shared >+ futexes, we also need to recalculate the hash, since the underlying >+ mapping mechanisms could have changed when dealing with page fault. >+ If, even with page fault enabled, we can't access the address, it >+ means it's an invalid user address, and we return -EFAULT. For this >+ case, we prioritize the error, even if some futexes were awaken. >+ >+If the check is OK, they are enqueued on a linked list in our bucket, and >+proceed to the next one. If all waiters succeed, we put the thread to sleep >+until a futex_wake() call, timeout expires or we get a signal. After waking up, >+we dequeue everyone, and check if some futex was awakened. This dequeue is done >+by iteratively walking at each element of struct futex_head list. >+ >+All enqueuing/dequeuing operations requires to hold the bucket lock, to avoid >+racing while modifying the list. >+ >+Waking >+------ >+ >+We get the bucket that's storing the waiters at uaddr, and wake the required >+number of waiters, checking for hash collision. >+ >+There's an optimization that makes futex_wake() not take the bucket lock if >+there's no one to be woken on that bucket. It checks an atomic counter that each >+bucket has, if it says 0, then the syscall exits. In order for this to work, the >+waiter thread increases it before taking the lock, so the wake thread will >+correctly see that there's someone waiting and will continue the path to take >+the bucket lock. To get the correct serialization, the waiter issues a memory >+barrier after increasing the bucket counter and the waker issues a memory >+barrier before checking it. >+ >+Requeuing >+--------- >+ >+The requeue path first checks for each struct futex_requeue and their flags. >+Then, it will compare the expected value with the one at uaddr1::uaddr. >+Following the same serialization explained at Waking_, we increase the atomic >+counter for the bucket of uaddr2 before taking the lock. We need to have both >+buckets locks at same time so we don't race with other futex operation. To >+ensure the locks are taken in the same order for all threads (and thus avoiding >+deadlocks), every requeue operation takes the "smaller" bucket first, when >+comparing both addresses. >+ >+If the compare with user value succeeds, we proceed by waking ``nr_wake`` >+futexes, and then requeuing ``nr_requeue`` from bucket of uaddr1 to the uaddr2. >+This consists in a simple list deletion/addition and replacing the old futex key >+with the new one. >+ >+Futex keys >+---------- >+ >+There are two types of futexes: private and shared ones. The private are futexes >+meant to be used by threads that share the same memory space, are easier to be >+uniquely identified and thus can have some performance optimization. The >+elements for identifying one are: the start address of the page where the >+address is, the address offset within the page and the current->mm pointer. >+ >+Now, for uniquely identifying a shared futex: >+ >+- If the page containing the user address is an anonymous page, we can >+ just use the same data used for private futexes (the start address of >+ the page, the address offset within the page and the current->mm >+ pointer); that will be enough for uniquely identifying such futex. We >+ also set one bit at the key to differentiate if a private futex is >+ used on the same address (mixing shared and private calls does not >+ work). >+ >+- If the page is file-backed, current->mm maybe isn't the same one for >+ every user of this futex, so we need to use other data: the >+ page->index, a UUID for the struct inode and the offset within the >+ page. >+ >+Note that members of futex_key don't have any particular meaning after they >+are part of the struct - they are just bytes to identify a futex. Given that, >+we don't need to use a particular name or type that matches the original data, >+we only need to care about the bitsize of each component and make both private >+and shared fit in the same memory space. >+ >+Source code documentation >+========================= >+ >+.. kernel-doc:: kernel/futex2.c >+ :no-identifiers: sys_futex_wait sys_futex_wake sys_futex_waitv sys_futex_requeue >diff --git a/Documentation/locking/index.rst b/Documentation/locking/index.rst >index 7003bd5aeff4..9bf03c7fa1ec 100644 >--- a/Documentation/locking/index.rst >+++ b/Documentation/locking/index.rst >@@ -24,6 +24,7 @@ locking > percpu-rw-semaphore > robust-futexes > robust-futex-ABI >+ futex2 > > .. only:: subproject and html > >-- >2.31.1 > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2021-06-06 19:19 Davidlohr Bueso @ 2021-06-07 16:02 ` André Almeida 0 siblings, 0 replies; 1767+ messages in thread From: André Almeida @ 2021-06-07 16:02 UTC (permalink / raw) To: Davidlohr Bueso Cc: Thomas Gleixner, Ingo Molnar, Peter Zijlstra, Darren Hart, linux-kernel, Steven Rostedt, Sebastian Andrzej Siewior, kernel, krisman, pgriffais, z.figura12, joel, malteskarupke, linux-api, fweimer, libc-alpha, linux-kselftest, shuah, acme, corbet, Peter Oskolkov, Andrey Semashev, mtk.manpages Às 16:19 de 06/06/21, Davidlohr Bueso escreveu: > Bcc: > Subject: Re: [PATCH v4 07/15] docs: locking: futex2: Add documentation > Reply-To: > In-Reply-To: <20210603195924.361327-8-andrealmeid@collabora.com> > > On Thu, 03 Jun 2021, Andr� Almeida wrote: > >> Add a new documentation file specifying both userspace API and internal >> implementation details of futex2 syscalls. > > I think equally important would be to provide a manpage for each new > syscall you are introducing, and keep mkt in the loop as in the past he > extensively documented and improved futex manpages, and overall has a > lot of experience with dealing with kernel interfaces. Right, I'll add the man pages in a future version and make sure to have mkt in the loop, thanks for the tip. > > Thanks, > Davidlohr > >> >> Signed-off-by: André Almeida <andrealmeid@collabora.com> >> --- >> Documentation/locking/futex2.rst | 198 +++++++++++++++++++++++++++++++ >> Documentation/locking/index.rst | 1 + >> 2 files changed, 199 insertions(+) >> create mode 100644 Documentation/locking/futex2.rst >> >> diff --git a/Documentation/locking/futex2.rst >> b/Documentation/locking/futex2.rst >> new file mode 100644 >> index 000000000000..2f74d7c97a55 >> --- /dev/null >> +++ b/Documentation/locking/futex2.rst >> @@ -0,0 +1,198 @@ >> +.. SPDX-License-Identifier: GPL-2.0 >> + >> +====== >> +futex2 >> +====== >> + >> +:Author: André Almeida <andrealmeid@collabora.com> >> + >> +futex, or fast user mutex, is a set of syscalls to allow userspace to >> create >> +performant synchronization mechanisms, such as mutexes, semaphores and >> +conditional variables in userspace. C standard libraries, like glibc, >> uses it >> +as a means to implement more high level interfaces like pthreads. >> + >> +The interface >> +============= >> + >> +uAPI functions >> +-------------- >> + >> +.. kernel-doc:: kernel/futex2.c >> + :identifiers: sys_futex_wait sys_futex_wake sys_futex_waitv >> sys_futex_requeue >> + >> +uAPI structures >> +--------------- >> + >> +.. kernel-doc:: include/uapi/linux/futex.h >> + >> +The ``flag`` argument >> +--------------------- >> + >> +The flag is used to specify the size of the futex word >> +(FUTEX_[8, 16, 32, 64]). It's mandatory to define one, since there's no >> +default size. >> + >> +By default, the timeout uses a monotonic clock, but can be used as a >> realtime >> +one by using the FUTEX_REALTIME_CLOCK flag. >> + >> +By default, futexes are of the private type, that means that this >> user address >> +will be accessed by threads that share the same memory region. This >> allows for >> +some internal optimizations, so they are faster. However, if the >> address needs >> +to be shared with different processes (like using ``mmap()`` or >> ``shm()``), they >> +need to be defined as shared and the flag FUTEX_SHARED_FLAG is used >> to set that. >> + >> +By default, the operation has no NUMA-awareness, meaning that the >> user can't >> +choose the memory node where the kernel side futex data will be >> stored. The >> +user can choose the node where it wants to operate by setting the >> +FUTEX_NUMA_FLAG and using the following structure (where X can be 8, >> 16, 32 or >> +64):: >> + >> + struct futexX_numa { >> + __uX value; >> + __sX hint; >> + }; >> + >> +This structure should be passed at the ``void *uaddr`` of futex >> functions. The >> +address of the structure will be used to be waited on/waken on, and the >> +``value`` will be compared to ``val`` as usual. The ``hint`` member >> is used to >> +define which node the futex will use. When waiting, the futex will be >> +registered on a kernel-side table stored on that node; when waking, >> the futex >> +will be searched for on that given table. That means that there's no >> redundancy >> +between tables, and the wrong ``hint`` value will lead to undesired >> behavior. >> +Userspace is responsible for dealing with node migrations issues that >> may >> +occur. ``hint`` can range from [0, MAX_NUMA_NODES), for specifying a >> node, or >> +-1, to use the same node the current process is using. >> + >> +When not using FUTEX_NUMA_FLAG on a NUMA system, the futex will be >> stored on a >> +global table on allocated on the first node. >> + >> +The ``timo`` argument >> +--------------------- >> + >> +As per the Y2038 work done in the kernel, new interfaces shouldn't >> add timeout >> +options known to be buggy. Given that, ``timo`` should be a 64-bit >> timeout at >> +all platforms, using an absolute timeout value. >> + >> +Implementation >> +============== >> + >> +The internal implementation follows a similar design to the original >> futex. >> +Given that we want to replicate the same external behavior of current >> futex, >> +this should be somewhat expected. >> + >> +Waiting >> +------- >> + >> +For the wait operations, they are all treated as if you want to wait >> on N >> +futexes, so the path for futex_wait and futex_waitv is the basically >> the same. >> +For both syscalls, the first step is to prepare an internal list for >> the list >> +of futexes to wait for (using struct futexv_head). For futex_wait() >> calls, this >> +list will have a single object. >> + >> +We have a hash table, where waiters register themselves before >> sleeping. Then >> +the wake function checks this table looking for waiters at uaddr. >> The hash >> +bucket to be used is determined by a struct futex_key, that stores >> information >> +to uniquely identify an address from a given process. Given the huge >> address >> +space, there'll be hash collisions, so we store information to be >> later used on >> +collision treatment. >> + >> +First, for every futex we want to wait on, we check if (``*uaddr == >> val``). >> +This check is done holding the bucket lock, so we are correctly >> serialized with >> +any futex_wake() calls. If any waiter fails the check above, we >> dequeue all >> +futexes. The check (``*uaddr == val``) can fail for two reasons: >> + >> +- The values are different, and we return -EAGAIN. However, if while >> + dequeueing we found that some futexes were awakened, we prioritize >> this >> + and return success. >> + >> +- When trying to access the user address, we do so with page faults >> + disabled because we are holding a bucket's spin lock (and can't sleep >> + while holding a spin lock). If there's an error, it might be a page >> + fault, or an invalid address. We release the lock, dequeue everyone >> + (because it's illegal to sleep while there are futexes enqueued, we >> + could lose wakeups) and try again with page fault enabled. If we >> + succeed, this means that the address is valid, but we need to do >> + all the work again. For serialization reasons, we need to have the >> + spin lock when getting the user value. Additionally, for shared >> + futexes, we also need to recalculate the hash, since the underlying >> + mapping mechanisms could have changed when dealing with page fault. >> + If, even with page fault enabled, we can't access the address, it >> + means it's an invalid user address, and we return -EFAULT. For this >> + case, we prioritize the error, even if some futexes were awaken. >> + >> +If the check is OK, they are enqueued on a linked list in our bucket, >> and >> +proceed to the next one. If all waiters succeed, we put the thread to >> sleep >> +until a futex_wake() call, timeout expires or we get a signal. After >> waking up, >> +we dequeue everyone, and check if some futex was awakened. This >> dequeue is done >> +by iteratively walking at each element of struct futex_head list. >> + >> +All enqueuing/dequeuing operations requires to hold the bucket lock, >> to avoid >> +racing while modifying the list. >> + >> +Waking >> +------ >> + >> +We get the bucket that's storing the waiters at uaddr, and wake the >> required >> +number of waiters, checking for hash collision. >> + >> +There's an optimization that makes futex_wake() not take the bucket >> lock if >> +there's no one to be woken on that bucket. It checks an atomic >> counter that each >> +bucket has, if it says 0, then the syscall exits. In order for this >> to work, the >> +waiter thread increases it before taking the lock, so the wake thread >> will >> +correctly see that there's someone waiting and will continue the path >> to take >> +the bucket lock. To get the correct serialization, the waiter issues >> a memory >> +barrier after increasing the bucket counter and the waker issues a >> memory >> +barrier before checking it. >> + >> +Requeuing >> +--------- >> + >> +The requeue path first checks for each struct futex_requeue and their >> flags. >> +Then, it will compare the expected value with the one at uaddr1::uaddr. >> +Following the same serialization explained at Waking_, we increase >> the atomic >> +counter for the bucket of uaddr2 before taking the lock. We need to >> have both >> +buckets locks at same time so we don't race with other futex >> operation. To >> +ensure the locks are taken in the same order for all threads (and >> thus avoiding >> +deadlocks), every requeue operation takes the "smaller" bucket first, >> when >> +comparing both addresses. >> + >> +If the compare with user value succeeds, we proceed by waking >> ``nr_wake`` >> +futexes, and then requeuing ``nr_requeue`` from bucket of uaddr1 to >> the uaddr2. >> +This consists in a simple list deletion/addition and replacing the >> old futex key >> +with the new one. >> + >> +Futex keys >> +---------- >> + >> +There are two types of futexes: private and shared ones. The private >> are futexes >> +meant to be used by threads that share the same memory space, are >> easier to be >> +uniquely identified and thus can have some performance optimization. The >> +elements for identifying one are: the start address of the page where >> the >> +address is, the address offset within the page and the current->mm >> pointer. >> + >> +Now, for uniquely identifying a shared futex: >> + >> +- If the page containing the user address is an anonymous page, we can >> + just use the same data used for private futexes (the start address of >> + the page, the address offset within the page and the current->mm >> + pointer); that will be enough for uniquely identifying such futex. We >> + also set one bit at the key to differentiate if a private futex is >> + used on the same address (mixing shared and private calls does not >> + work). >> + >> +- If the page is file-backed, current->mm maybe isn't the same one for >> + every user of this futex, so we need to use other data: the >> + page->index, a UUID for the struct inode and the offset within the >> + page. >> + >> +Note that members of futex_key don't have any particular meaning >> after they >> +are part of the struct - they are just bytes to identify a futex. >> Given that, >> +we don't need to use a particular name or type that matches the >> original data, >> +we only need to care about the bitsize of each component and make >> both private >> +and shared fit in the same memory space. >> + >> +Source code documentation >> +========================= >> + >> +.. kernel-doc:: kernel/futex2.c >> + :no-identifiers: sys_futex_wait sys_futex_wake sys_futex_waitv >> sys_futex_requeue >> diff --git a/Documentation/locking/index.rst >> b/Documentation/locking/index.rst >> index 7003bd5aeff4..9bf03c7fa1ec 100644 >> --- a/Documentation/locking/index.rst >> +++ b/Documentation/locking/index.rst >> @@ -24,6 +24,7 @@ locking >> percpu-rw-semaphore >> robust-futexes >> robust-futex-ABI >> + futex2 >> >> .. only:: subproject and html >> >> -- >> 2.31.1 >> ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <60a57e3a.lbqA81rLGmtH2qoy%Radisson97@gmx.de>]
* Re: [not found] <60a57e3a.lbqA81rLGmtH2qoy%Radisson97@gmx.de> @ 2021-05-21 11:04 ` Alejandro Colomar (man-pages) 0 siblings, 0 replies; 1767+ messages in thread From: Alejandro Colomar (man-pages) @ 2021-05-21 11:04 UTC (permalink / raw) To: Radisson97; +Cc: linux-man, Michael Kerrisk (man-pages) Hi Walter, On 5/19/21 11:08 PM, Radisson97@gmx.de wrote: > From 765db7b7714514780b4e613c6d09d2ff454b1ef8 Mon Sep 17 00:00:00 2001 > From: Harms <wharms@bfs.de> > Date: Wed, 19 May 2021 22:25:08 +0200 > Subject: [PATCH] gamma.3:Add reentrant functions gamma_r > > Add three variants of gamma_r and explain > the use of the second argument sig > > Signed-off-by: Harms <wharms@bfs.de> I just read the manual page about gamma, and those functions/macros are deprecated (use either lgamma or tgamma instead). As far as I can read, those alternative functions have all the functionality one can need, so I guess there's zero reasons to use gamma at all, which is a misleading alias for lgamma. I think I won't patch that page at all. The glibc source code itself has a comment saying that gamma macros are obsolete: [ #if defined __USE_MISC || (defined __USE_XOPEN && !defined __USE_XOPEN2K) # if !__MATH_DECLARING_FLOATN /* Obsolete alias for `lgamma'. */ __MATHCALL (gamma,, (_Mdouble_)); # endif #endif ] Thanks, Alex -- Alejandro Colomar Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/ Senior SW Engineer; http://www.alejandro-colomar.es/ ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2021-05-15 22:57 Dmitry Baryshkov
2021-06-02 21:45 ` Dmitry Baryshkov
0 siblings, 1 reply; 1767+ messages in thread
From: Dmitry Baryshkov @ 2021-05-15 22:57 UTC (permalink / raw)
To: Bjorn Andersson, Rob Clark, Sean Paul, Abhinav Kumar
Cc: Jonathan Marek, Stephen Boyd, David Airlie, Daniel Vetter,
linux-arm-msm, dri-devel, freedreno
From Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # This line is ignored.
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reply-To:
Subject: [PATCH v2 0/6] drm/msm/dpu: simplify RM code
In-Reply-To:
There is no need to request most of hardware blocks through the resource
manager (RM), since typically there is 1:1 or N:1 relationship between
corresponding blocks. Each LM is tied to the single PP. Each MERGE_3D
can be used by the specified pair of PPs. Each DSPP is also tied to
single LM. So instead of allocating them through the RM, get them via
static configuration.
Depends on: https://lore.kernel.org/linux-arm-msm/20210515190909.1809050-1-dmitry.baryshkov@linaro.org
Changes since v1:
- Split into separate patch series to ease review.
----------------------------------------------------------------
Dmitry Baryshkov (6):
drm/msm/dpu: get DSPP blocks directly rather than through RM
drm/msm/dpu: get MERGE_3D blocks directly rather than through RM
drm/msm/dpu: get PINGPONG blocks directly rather than through RM
drm/msm/dpu: get INTF blocks directly rather than through RM
drm/msm/dpu: drop unused lm_max_width from RM
drm/msm/dpu: simplify peer LM handling
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 54 +---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 8 -
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 5 -
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 8 -
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 8 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 14 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h | 7 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 7 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 4 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 53 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 5 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 310 ++-------------------
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 18 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 9 +-
16 files changed, 115 insertions(+), 401 deletions(-)
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2021-05-15 22:57 Dmitry Baryshkov @ 2021-06-02 21:45 ` Dmitry Baryshkov 0 siblings, 0 replies; 1767+ messages in thread From: Dmitry Baryshkov @ 2021-06-02 21:45 UTC (permalink / raw) To: Bjorn Andersson, Rob Clark, Sean Paul, Abhinav Kumar Cc: Jonathan Marek, Stephen Boyd, David Airlie, Daniel Vetter, linux-arm-msm, dri-devel, freedreno On 16/05/2021 01:57, Dmitry Baryshkov wrote: > From Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # This line is ignored. > From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > Reply-To: > Subject: [PATCH v2 0/6] drm/msm/dpu: simplify RM code > In-Reply-To: > > There is no need to request most of hardware blocks through the resource > manager (RM), since typically there is 1:1 or N:1 relationship between > corresponding blocks. Each LM is tied to the single PP. Each MERGE_3D > can be used by the specified pair of PPs. Each DSPP is also tied to > single LM. So instead of allocating them through the RM, get them via > static configuration. > > Depends on: https://lore.kernel.org/linux-arm-msm/20210515190909.1809050-1-dmitry.baryshkov@linaro.org > > Changes since v1: > - Split into separate patch series to ease review. Another gracious ping, now for this series. I want to send next version with minor changes, but I'd like to hear your overall opinion before doing that. > > ---------------------------------------------------------------- > Dmitry Baryshkov (6): > drm/msm/dpu: get DSPP blocks directly rather than through RM > drm/msm/dpu: get MERGE_3D blocks directly rather than through RM > drm/msm/dpu: get PINGPONG blocks directly rather than through RM > drm/msm/dpu: get INTF blocks directly rather than through RM > drm/msm/dpu: drop unused lm_max_width from RM > drm/msm/dpu: simplify peer LM handling > > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 54 +--- > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 8 - > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 5 - > .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 8 - > .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 8 - > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 14 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h | 7 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 7 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 4 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 53 +++- > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 5 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 310 ++------------------- > drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 18 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 9 +- > 16 files changed, 115 insertions(+), 401 deletions(-) > > -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <CAJr+-6ZR2oH0J4D_Ou13JvX8HLUUK=MKQwD0Kn53cmvAuT99bg@mail.gmail.com>]
* Re: [not found] <CAJr+-6ZR2oH0J4D_Ou13JvX8HLUUK=MKQwD0Kn53cmvAuT99bg@mail.gmail.com> @ 2021-04-27 7:56 ` Fox Chen 0 siblings, 0 replies; 1767+ messages in thread From: Fox Chen @ 2021-04-27 7:56 UTC (permalink / raw) To: Skylar Givens; +Cc: rust-for-linux Hi Skylar, On Tue, Apr 27, 2021 at 11:38 AM Skylar Givens <skylargivens@gmail.com> wrote: > > subscribe rust-for-linux For subscribing please see: http://vger.kernel.org/majordomo-info.html http://vger.kernel.org/vger-lists.html thanks, fox ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <b84772b0-e009-3b68-4e74-525ad8531f95@gmail.com>]
* Re: [not found] <b84772b0-e009-3b68-4e74-525ad8531f95@gmail.com> @ 2021-04-23 13:57 ` Ivan Koveshnikov 2021-04-23 20:35 ` Re: Kajetan Puchalski 0 siblings, 1 reply; 1767+ messages in thread From: Ivan Koveshnikov @ 2021-04-23 13:57 UTC (permalink / raw) To: Kajetan Puchalski; +Cc: rust-for-linux Hi Kajetan, You need to send an `subscribe rust-for-linux` to <majordomo@vger.kernel.org> email, not to the mail list. http://vger.kernel.org/vger-lists.html page contains links that can prepare an email message with correct format and address. Best regards, Ivan Koveshnikov On Fri, 23 Apr 2021 at 02:53, Kajetan Puchalski <mrkajetanp@gmail.com> wrote: > > subscribe ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2021-04-23 13:57 ` Re: Ivan Koveshnikov @ 2021-04-23 20:35 ` Kajetan Puchalski 0 siblings, 0 replies; 1767+ messages in thread From: Kajetan Puchalski @ 2021-04-23 20:35 UTC (permalink / raw) To: Ivan Koveshnikov; +Cc: rust-for-linux On 4/23/21 2:57 PM, Ivan Koveshnikov wrote: > Hi Kajetan, > > You need to send an `subscribe rust-for-linux` to > <majordomo@vger.kernel.org> email, not to the mail list. > http://vger.kernel.org/vger-lists.html page contains links that can > prepare an email message with correct format and address. > > Best regards, > Ivan Koveshnikov > > > On Fri, 23 Apr 2021 at 02:53, Kajetan Puchalski <mrkajetanp@gmail.com> wrote: >> >> subscribe Hi Ivan, Thank you, apologies, I realised that I wasn't supposed to do that literally right after I had sent the email. Regards, Kajetan ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2021-04-15 13:41 Emmanuel Blot 2021-04-15 16:07 ` Palmer Dabbelt 2021-04-15 22:27 ` Re: Alistair Francis 0 siblings, 2 replies; 1767+ messages in thread From: Emmanuel Blot @ 2021-04-15 13:41 UTC (permalink / raw) To: qemu-riscv Cc: Emmanuel Blot, Palmer Dabbelt, Alistair Francis, Sagar Karandikar, Bastian Koppelmann Date: Tue, 13 Apr 2021 18:01:52 +0200 Subject: [PATCH] target/riscv: fix exception index on instruction access fault When no MMU is used and the guest code attempts to fetch an instruction from an invalid memory location, the exception index defaults to a data load access fault, rather an instruction access fault. Signed-off-by: Emmanuel Blot <emmanuel.blot@sifive.com> --- target/riscv/cpu_helper.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c index 21c54ef5613..4e107b1bd23 100644 --- a/target/riscv/cpu_helper.c +++ b/target/riscv/cpu_helper.c @@ -691,8 +691,10 @@ void riscv_cpu_do_transaction_failed(CPUState *cs, hwaddr physaddr, if (access_type == MMU_DATA_STORE) { cs->exception_index = RISCV_EXCP_STORE_AMO_ACCESS_FAULT; - } else { + } else if (access_type == MMU_DATA_LOAD) { cs->exception_index = RISCV_EXCP_LOAD_ACCESS_FAULT; + } else { + cs->exception_index = RISCV_EXCP_INST_ACCESS_FAULT; } env->badaddr = addr; -- 2.31.1 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2021-04-15 13:41 Emmanuel Blot @ 2021-04-15 16:07 ` Palmer Dabbelt 2021-04-15 22:27 ` Re: Alistair Francis 1 sibling, 0 replies; 1767+ messages in thread From: Palmer Dabbelt @ 2021-04-15 16:07 UTC (permalink / raw) To: emmanuel.blot Cc: qemu-riscv, emmanuel.blot, Alistair Francis, sagark, Bastian Koppelmann On Thu, 15 Apr 2021 06:41:29 PDT (-0700), emmanuel.blot@sifive.com wrote: > Date: Tue, 13 Apr 2021 18:01:52 +0200 > Subject: [PATCH] target/riscv: fix exception index on instruction access fault > > When no MMU is used and the guest code attempts to fetch an instruction > from an invalid memory location, the exception index defaults to a data > load access fault, rather an instruction access fault. > > Signed-off-by: Emmanuel Blot <emmanuel.blot@sifive.com> > > --- > target/riscv/cpu_helper.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c > index 21c54ef5613..4e107b1bd23 100644 > --- a/target/riscv/cpu_helper.c > +++ b/target/riscv/cpu_helper.c > @@ -691,8 +691,10 @@ void riscv_cpu_do_transaction_failed(CPUState *cs, hwaddr physaddr, > > if (access_type == MMU_DATA_STORE) { > cs->exception_index = RISCV_EXCP_STORE_AMO_ACCESS_FAULT; > - } else { > + } else if (access_type == MMU_DATA_LOAD) { > cs->exception_index = RISCV_EXCP_LOAD_ACCESS_FAULT; > + } else { > + cs->exception_index = RISCV_EXCP_INST_ACCESS_FAULT; > } > > env->badaddr = addr; Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2021-04-15 13:41 Emmanuel Blot 2021-04-15 16:07 ` Palmer Dabbelt @ 2021-04-15 22:27 ` Alistair Francis 1 sibling, 0 replies; 1767+ messages in thread From: Alistair Francis @ 2021-04-15 22:27 UTC (permalink / raw) To: qemu-riscv@nongnu.org, emmanuel.blot@sifive.com Cc: palmer@dabbelt.com, kbastian@mail.uni-paderborn.de, sagark@eecs.berkeley.edu On Thu, 2021-04-15 at 15:41 +0200, Emmanuel Blot wrote: > Date: Tue, 13 Apr 2021 18:01:52 +0200 > Subject: [PATCH] target/riscv: fix exception index on instruction > access fault > > When no MMU is used and the guest code attempts to fetch an instruction > from an invalid memory location, the exception index defaults to a data > load access fault, rather an instruction access fault. > > Signed-off-by: Emmanuel Blot <emmanuel.blot@sifive.com> Thanks for the patch. Can you send the patch to the QEMU mailling list? qemu-devel@nongnu.org Alistair > > --- > target/riscv/cpu_helper.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c > index 21c54ef5613..4e107b1bd23 100644 > --- a/target/riscv/cpu_helper.c > +++ b/target/riscv/cpu_helper.c > @@ -691,8 +691,10 @@ void riscv_cpu_do_transaction_failed(CPUState *cs, > hwaddr physaddr, > > if (access_type == MMU_DATA_STORE) { > cs->exception_index = RISCV_EXCP_STORE_AMO_ACCESS_FAULT; > - } else { > + } else if (access_type == MMU_DATA_LOAD) { > cs->exception_index = RISCV_EXCP_LOAD_ACCESS_FAULT; > + } else { > + cs->exception_index = RISCV_EXCP_INST_ACCESS_FAULT; > } > > env->badaddr = addr; ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2021-04-05 21:12 David Villasana Jiménez 2021-04-06 5:17 ` Greg KH 0 siblings, 1 reply; 1767+ messages in thread From: David Villasana Jiménez @ 2021-04-05 21:12 UTC (permalink / raw) To: mchehab; +Cc: linux-media, linux-staging linux-kernel@vger.kernel.org, outreachy-kernel@googlegroups.com Bcc: Subject: [PATCH] staging: media: atomisp: i2c: Fix alignment to match open parenthesis Reply-To: Change alignment of arguments in the function __gc0310_write_reg_is_consecutive() to match open parenthesis. Issue found by checkpatch.pl Signed-off-by: David Villasana Jiménez <davidvillasana14@gmail.com> --- drivers/staging/media/atomisp/i2c/atomisp-gc0310.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c b/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c index 2b71de722ec3..6be3ee1d93a5 100644 --- a/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c +++ b/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c @@ -192,8 +192,8 @@ static int __gc0310_buf_reg_array(struct i2c_client *client, } static int __gc0310_write_reg_is_consecutive(struct i2c_client *client, - struct gc0310_write_ctrl *ctrl, - const struct gc0310_reg *next) + struct gc0310_write_ctrl *ctrl, + const struct gc0310_reg *next) { if (ctrl->index == 0) return 1; -- 2.30.2 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2021-04-05 21:12 David Villasana Jiménez @ 2021-04-06 5:17 ` Greg KH 0 siblings, 0 replies; 1767+ messages in thread From: Greg KH @ 2021-04-06 5:17 UTC (permalink / raw) To: David Villasana Jiménez; +Cc: mchehab, linux-media, linux-staging On Mon, Apr 05, 2021 at 04:12:48PM -0500, David Villasana Jiménez wrote: > linux-kernel@vger.kernel.org, outreachy-kernel@googlegroups.com > Bcc: > Subject: [PATCH] staging: media: atomisp: i2c: Fix alignment to match open > parenthesis > Reply-To: Something went wrong with your email again :( ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2021-04-05 0:01 Mitali Borkar 2021-04-06 7:03 ` Arnd Bergmann 0 siblings, 1 reply; 1767+ messages in thread From: Mitali Borkar @ 2021-04-05 0:01 UTC (permalink / raw) To: manish, GR-Linux-NIC-Dev, gregkh; +Cc: linux-staging, linux-kernel outreachy-kernel@googlegroups.com, mitaliborkar810@gmail.com Bcc: Subject: [PATCH] staging: qlge:remove else after break Reply-To: Fixed Warning:- else is not needed after break break terminates the loop if encountered. else is unnecessary and increases indenatation Signed-off-by: Mitali Borkar <mitaliborkar810@gmail.com> --- drivers/staging/qlge/qlge_mpi.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/staging/qlge/qlge_mpi.c b/drivers/staging/qlge/qlge_mpi.c index 2630ebf50341..3a49f187203b 100644 --- a/drivers/staging/qlge/qlge_mpi.c +++ b/drivers/staging/qlge/qlge_mpi.c @@ -935,13 +935,11 @@ static int qlge_idc_wait(struct qlge_adapter *qdev) netif_err(qdev, drv, qdev->ndev, "IDC Success.\n"); status = 0; break; - } else { - netif_err(qdev, drv, qdev->ndev, + } netif_err(qdev, drv, qdev->ndev, "IDC: Invalid State 0x%.04x.\n", mbcp->mbox_out[0]); status = -EIO; break; - } } return status; -- 2.30.2 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2021-04-05 0:01 Mitali Borkar @ 2021-04-06 7:03 ` Arnd Bergmann 0 siblings, 0 replies; 1767+ messages in thread From: Arnd Bergmann @ 2021-04-06 7:03 UTC (permalink / raw) To: Mitali Borkar Cc: manish, GR-Linux-NIC-Dev, gregkh, linux-staging, Linux Kernel Mailing List On Mon, Apr 5, 2021 at 2:03 AM Mitali Borkar <mitaliborkar810@gmail.com> wrote: > > outreachy-kernel@googlegroups.com, mitaliborkar810@gmail.com > Bcc: > Subject: [PATCH] staging: qlge:remove else after break > Reply-To: > > Fixed Warning:- else is not needed after break > break terminates the loop if encountered. else is unnecessary and > increases indenatation > > Signed-off-by: Mitali Borkar <mitaliborkar810@gmail.com> > --- > drivers/staging/qlge/qlge_mpi.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/staging/qlge/qlge_mpi.c b/drivers/staging/qlge/qlge_mpi.c > index 2630ebf50341..3a49f187203b 100644 > --- a/drivers/staging/qlge/qlge_mpi.c > +++ b/drivers/staging/qlge/qlge_mpi.c > @@ -935,13 +935,11 @@ static int qlge_idc_wait(struct qlge_adapter *qdev) > netif_err(qdev, drv, qdev->ndev, "IDC Success.\n"); > status = 0; > break; > - } else { > - netif_err(qdev, drv, qdev->ndev, > + } netif_err(qdev, drv, qdev->ndev, > "IDC: Invalid State 0x%.04x.\n", > mbcp->mbox_out[0]); > status = -EIO; > break; > - } > } It looks like you got this one wrong in multiple ways: - This is not an equivalent transformation, since the errror is now printed in the first part of the 'if()' block as well. - The indentation is wrong now, with the netif_err() starting in the same line as the '}'. - The description mentions a change in indentation, but you did not actually change it. - The changelog text appears mangled. Arnd ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <CAMCTd2kkax9P-OFNHYYz8nKuaKOOkz-zoJ7h2nZ6maUGmjXC-g@mail.gmail.com>]
* Re: [not found] <CAMCTd2kkax9P-OFNHYYz8nKuaKOOkz-zoJ7h2nZ6maUGmjXC-g@mail.gmail.com> @ 2021-03-16 12:16 ` westjoshuaalan 0 siblings, 0 replies; 1767+ messages in thread From: westjoshuaalan @ 2021-03-16 12:16 UTC (permalink / raw) To: linux-rdma subscribe linux-rdma ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2021-01-19 0:10 David Howells
2021-01-20 14:46 ` Jarkko Sakkinen
0 siblings, 1 reply; 1767+ messages in thread
From: David Howells @ 2021-01-19 0:10 UTC (permalink / raw)
To: torvalds
Cc: Tobias Markus, Tianjia Zhang, dhowells, keyrings, linux-crypto,
linux-security-module, stable, linux-kernel
From: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
On the following call path, `sig->pkey_algo` is not assigned
in asymmetric_key_verify_signature(), which causes runtime
crash in public_key_verify_signature().
keyctl_pkey_verify
asymmetric_key_verify_signature
verify_signature
public_key_verify_signature
This patch simply check this situation and fixes the crash
caused by NULL pointer.
Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate verification")
Reported-by: Tobias Markus <tobias@markus-regensburg.de>
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-and-tested-by: Toke Høiland-Jørgensen <toke@redhat.com>
Tested-by: João Fonseca <jpedrofonseca@ua.pt>
Cc: stable@vger.kernel.org # v5.10+
---
crypto/asymmetric_keys/public_key.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/crypto/asymmetric_keys/public_key.c b/crypto/asymmetric_keys/public_key.c
index 8892908ad58c..788a4ba1e2e7 100644
--- a/crypto/asymmetric_keys/public_key.c
+++ b/crypto/asymmetric_keys/public_key.c
@@ -356,7 +356,8 @@ int public_key_verify_signature(const struct public_key *pkey,
if (ret)
goto error_free_key;
- if (strcmp(sig->pkey_algo, "sm2") == 0 && sig->data_size) {
+ if (sig->pkey_algo && strcmp(sig->pkey_algo, "sm2") == 0 &&
+ sig->data_size) {
ret = cert_sig_digest_update(sig, tfm);
if (ret)
goto error_free_key;
^ permalink raw reply related [flat|nested] 1767+ messages in thread* Re: 2021-01-19 0:10 David Howells @ 2021-01-20 14:46 ` Jarkko Sakkinen 0 siblings, 0 replies; 1767+ messages in thread From: Jarkko Sakkinen @ 2021-01-20 14:46 UTC (permalink / raw) To: David Howells Cc: torvalds, Tobias Markus, Tianjia Zhang, keyrings, linux-crypto, linux-security-module, stable, linux-kernel On Tue, Jan 19, 2021 at 12:10:33AM +0000, David Howells wrote: > > From: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> > > On the following call path, `sig->pkey_algo` is not assigned > in asymmetric_key_verify_signature(), which causes runtime > crash in public_key_verify_signature(). > > keyctl_pkey_verify > asymmetric_key_verify_signature > verify_signature > public_key_verify_signature > > This patch simply check this situation and fixes the crash > caused by NULL pointer. > > Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate verification") > Reported-by: Tobias Markus <tobias@markus-regensburg.de> > Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> > Signed-off-by: David Howells <dhowells@redhat.com> > Reviewed-and-tested-by: Toke Høiland-Jørgensen <toke@redhat.com> > Tested-by: João Fonseca <jpedrofonseca@ua.pt> > Cc: stable@vger.kernel.org # v5.10+ > --- For what it's worth Acked-by: Jarkko Sakkinen <jarkko@kernel.org> /Jarkko > > crypto/asymmetric_keys/public_key.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/crypto/asymmetric_keys/public_key.c b/crypto/asymmetric_keys/public_key.c > index 8892908ad58c..788a4ba1e2e7 100644 > --- a/crypto/asymmetric_keys/public_key.c > +++ b/crypto/asymmetric_keys/public_key.c > @@ -356,7 +356,8 @@ int public_key_verify_signature(const struct public_key *pkey, > if (ret) > goto error_free_key; > > - if (strcmp(sig->pkey_algo, "sm2") == 0 && sig->data_size) { > + if (sig->pkey_algo && strcmp(sig->pkey_algo, "sm2") == 0 && > + sig->data_size) { > ret = cert_sig_digest_update(sig, tfm); > if (ret) > goto error_free_key; > > ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <w2q9lf-sait7s-qswxlnzeof4i-7j13q0-zgu9pt-xk3x5enp994p-kewn2p-o86qyug0mutj-91m157sheva0-4k2l8v20kyjp-heu04baxqdc7op987-9zc0bxi0jcgo-wyl26layz5p9-esqncc-g48ass.1610618007875@email.android.com>]
* Re: [not found] <w2q9lf-sait7s-qswxlnzeof4i-7j13q0-zgu9pt-xk3x5enp994p-kewn2p-o86qyug0mutj-91m157sheva0-4k2l8v20kyjp-heu04baxqdc7op987-9zc0bxi0jcgo-wyl26layz5p9-esqncc-g48ass.1610618007875@email.android.com> @ 2021-01-14 10:09 ` Alexander Kapshuk 0 siblings, 0 replies; 1767+ messages in thread From: Alexander Kapshuk @ 2021-01-14 10:09 UTC (permalink / raw) To: bigbird2444@163.com; +Cc: kernelnewbies@kernelnewbies.org On Thu, Jan 14, 2021 at 11:54 AM bigbird2444@163.com <bigbird2444@163.com> wrote: > > On Thu, Jan 14, 2021 at 8:01 AM Alexander Kapshuk > <alexander.kapshuk@gmail.com> wrote: > > > > On Thu, Jan 14, 2021 at 8:14 AM bigbird2444@163.com <bigbird2444@163.com> wrote: > > > > > > > > > I've just added a newbies mailing list, How to join other mailing lists, and I'd like to see what other people are communicating with. > > > > > > _______________________________________________ > > > Kernelnewbies mailing list > > > Kernelnewbies@kernelnewbies.org > > > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > Not sure what other lists you were referring to, but you may want to > > check out these mailing lists, http://vger.kernel.org/vger-lists.html, > > and see if that's what you were after. > > >If you just would like to read the mails on >the different mailing > >list, you do not need to subscribe. > > >You can find all emails at >https://lore.kernel.org/lists.html, just > >look into the various mailing lists and see >what is of interest to > >you. > > >Lukas > > > Thank you, how do I subscribe to other mailing lists? > > Liang Peng > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies By clicking on the link for the mailing list of interest, e.g. linux-next, http://vger.kernel.org/vger-lists.html#linux-next, followed by clicking on the subscribe link, which would launch your email client, if available, with majordomo@vger.kernel.org as the recipient and the following email body: subscribe name-of-mailing-list Alternatively, you could simply send the subscription request above using an email client of your preference. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE:
@ 2021-01-08 10:35 misono.tomohiro
0 siblings, 0 replies; 1767+ messages in thread
From: misono.tomohiro @ 2021-01-08 10:35 UTC (permalink / raw)
To: misono.tomohiro@fujitsu.com,
'linux-arm-kernel@lists.infradead.org',
'soc@kernel.org'
Cc: 'will@kernel.org', 'catalin.marinas@arm.com',
'arnd@arndb.de', 'olof@lixom.net'
Sorry, I failed to add proper subject to cover letter and it does not show lore archive.
I will resend the whole serieses. Plese discard this.
Tomohiro
> -----Original Message-----
> From: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
> Sent: Friday, January 8, 2021 7:32 PM
> To: linux-arm-kernel@lists.infradead.org; soc@kernel.org
> Cc: will@kernel.org; catalin.marinas@arm.com; arnd@arndb.de; olof@lixom.net; Misono, Tomohiro/味曽野 智礼
> <misono.tomohiro@fujitsu.com>
> Subject:
>
> Subject: [RFC PATCH 00/10] Add Fujitsu A64FX soc entry/hardware barrier driver
>
> Hello,
>
> This series adds Fujitsu A64FX SoC entry in drivers/soc and hardware barrier driver for it.
>
> [Driver Description]
> A64FX CPU has several functions for HPC workload and hardware barrier is one of them. It is a mechanism to realize
> fast synchronization by PEs belonging to the same L3 cache domain by using implementation defined hardware
> registers.
> For more details, see A64FX HPC extension specification in https://github.com/fujitsu/A64FX
>
> The driver mainly offers a set of ioctls to manipulate related registers.
> Patch 1-9 implements driver code and patch 10 finally adds kconfig, Makefile and MAINTAINER entry for the driver.
>
> Also, C library and test program for this driver is available on:
> https://github.com/fujitsu/hardware_barrier
>
> The driver is based on v5.11-rc2 and tested on FX700 environment.
>
> [RFC]
> This is the first time we upstream drivers for our chip and I want to confirm driver location and patch submission
> process.
>
> Based on my observation it seems drivers/soc folder is right place to put this driver, so I added Kconfig entry for arm64
> platform config, created soc/fujitsu folder and updated MAINTAINER entry accordingly (last patch).
> Is it right?
>
> Also for final submission I think I need to 1) create some public git tree to push driver code (github or something), 2)
> make pull request to SOC team (soc@kernel.org). Is it a correct procedure?
>
> I will appreciate any help/comments.
>
> sidenote: We plan to post other drivers for A64FX HPC extension (prefetch control and cache control) too anytime soon.
>
> Misono Tomohiro (10):
> soc: fujitsu: hwb: Add hardware barrier driver init/exit code
> soc: fujtisu: hwb: Add open operation
> soc: fujitsu: hwb: Add IOC_BB_ALLOC ioctl
> soc: fujitsu: hwb: Add IOC_BW_ASSIGN ioctl
> soc: fujitsu: hwb: Add IOC_BW_UNASSIGN ioctl
> soc: fujitsu: hwb: Add IOC_BB_FREE ioctl
> soc: fujitsu: hwb: Add IOC_GET_PE_INFO ioctl
> soc: fujitsu: hwb: Add release operation
> soc: fujitsu: hwb: Add sysfs entry
> soc: fujitsu: hwb: Add Kconfig/Makefile to build fujitsu_hwb driver
>
> MAINTAINERS | 7 +
> arch/arm64/Kconfig.platforms | 5 +
> drivers/soc/Kconfig | 1 +
> drivers/soc/Makefile | 1 +
> drivers/soc/fujitsu/Kconfig | 24 +
> drivers/soc/fujitsu/Makefile | 2 +
> drivers/soc/fujitsu/fujitsu_hwb.c | 1253 ++++++++++++++++++++++++
> include/uapi/linux/fujitsu_hpc_ioctl.h | 41 +
> 8 files changed, 1334 insertions(+)
> create mode 100644 drivers/soc/fujitsu/Kconfig create mode 100644 drivers/soc/fujitsu/Makefile create mode
> 100644 drivers/soc/fujitsu/fujitsu_hwb.c create mode 100644 include/uapi/linux/fujitsu_hpc_ioctl.h
>
> --
> 2.26.2
^ permalink raw reply [flat|nested] 1767+ messages in thread* (no subject) @ 2021-01-08 10:32 Misono Tomohiro 2021-01-08 12:30 ` Re: Arnd Bergmann 0 siblings, 1 reply; 1767+ messages in thread From: Misono Tomohiro @ 2021-01-08 10:32 UTC (permalink / raw) To: linux-arm-kernel, soc; +Cc: will, catalin.marinas, arnd, olof, misono.tomohiro Subject: [RFC PATCH 00/10] Add Fujitsu A64FX soc entry/hardware barrier driver Hello, This series adds Fujitsu A64FX SoC entry in drivers/soc and hardware barrier driver for it. [Driver Description] A64FX CPU has several functions for HPC workload and hardware barrier is one of them. It is a mechanism to realize fast synchronization by PEs belonging to the same L3 cache domain by using implementation defined hardware registers. For more details, see A64FX HPC extension specification in https://github.com/fujitsu/A64FX The driver mainly offers a set of ioctls to manipulate related registers. Patch 1-9 implements driver code and patch 10 finally adds kconfig, Makefile and MAINTAINER entry for the driver. Also, C library and test program for this driver is available on: https://github.com/fujitsu/hardware_barrier The driver is based on v5.11-rc2 and tested on FX700 environment. [RFC] This is the first time we upstream drivers for our chip and I want to confirm driver location and patch submission process. Based on my observation it seems drivers/soc folder is right place to put this driver, so I added Kconfig entry for arm64 platform config, created soc/fujitsu folder and updated MAINTAINER entry accordingly (last patch). Is it right? Also for final submission I think I need to 1) create some public git tree to push driver code (github or something), 2) make pull request to SOC team (soc@kernel.org). Is it a correct procedure? I will appreciate any help/comments. sidenote: We plan to post other drivers for A64FX HPC extension (prefetch control and cache control) too anytime soon. Misono Tomohiro (10): soc: fujitsu: hwb: Add hardware barrier driver init/exit code soc: fujtisu: hwb: Add open operation soc: fujitsu: hwb: Add IOC_BB_ALLOC ioctl soc: fujitsu: hwb: Add IOC_BW_ASSIGN ioctl soc: fujitsu: hwb: Add IOC_BW_UNASSIGN ioctl soc: fujitsu: hwb: Add IOC_BB_FREE ioctl soc: fujitsu: hwb: Add IOC_GET_PE_INFO ioctl soc: fujitsu: hwb: Add release operation soc: fujitsu: hwb: Add sysfs entry soc: fujitsu: hwb: Add Kconfig/Makefile to build fujitsu_hwb driver MAINTAINERS | 7 + arch/arm64/Kconfig.platforms | 5 + drivers/soc/Kconfig | 1 + drivers/soc/Makefile | 1 + drivers/soc/fujitsu/Kconfig | 24 + drivers/soc/fujitsu/Makefile | 2 + drivers/soc/fujitsu/fujitsu_hwb.c | 1253 ++++++++++++++++++++++++ include/uapi/linux/fujitsu_hpc_ioctl.h | 41 + 8 files changed, 1334 insertions(+) create mode 100644 drivers/soc/fujitsu/Kconfig create mode 100644 drivers/soc/fujitsu/Makefile create mode 100644 drivers/soc/fujitsu/fujitsu_hwb.c create mode 100644 include/uapi/linux/fujitsu_hpc_ioctl.h -- 2.26.2 ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2021-01-08 12:30 ` Arnd Bergmann 0 siblings, 0 replies; 1767+ messages in thread From: Arnd Bergmann @ 2021-01-08 12:30 UTC (permalink / raw) To: Misono Tomohiro Cc: Linux ARM, SoC Team, Will Deacon, Catalin Marinas, Arnd Bergmann, Olof Johansson On Fri, Jan 8, 2021 at 11:32 AM Misono Tomohiro <misono.tomohiro@jp.fujitsu.com> wrote: > Subject: [RFC PATCH 00/10] Add Fujitsu A64FX soc entry/hardware barrier driver > [RFC] > This is the first time we upstream drivers for our chip and I want to > confirm driver location and patch submission process. > > Based on my observation it seems drivers/soc folder is right place to put > this driver, so I added Kconfig entry for arm64 platform config, created > soc/fujitsu folder and updated MAINTAINER entry accordingly (last patch). > Is it right? This looks good as a start. It may be possible that during review, we come up with a different location or a different user interface that may change the code, but if it stays in drivers/soc/fujitsu, then the other steps are absolutely right. > Also for final submission I think I need to 1) create some public git > tree to push driver code (github or something), 2) make pull request to > SOC team (soc@kernel.org). Is it a correct procedure? Yes. I would prefer something other than github, e.g. an account on a fujitsu.com host, on kernel.org, or on git.linaro.org, but github works if none of the alternatives are easy for you. When you send a pull request, make sure you sign the tag with a gpg key, ideally after getting it on the kernel.org keyring [1]. Arnd [1] https://korg.docs.kernel.org/pgpkeys.html ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2021-01-08 12:30 ` Arnd Bergmann 0 siblings, 0 replies; 1767+ messages in thread From: Arnd Bergmann @ 2021-01-08 12:30 UTC (permalink / raw) To: Misono Tomohiro Cc: Arnd Bergmann, Catalin Marinas, SoC Team, Olof Johansson, Will Deacon, Linux ARM On Fri, Jan 8, 2021 at 11:32 AM Misono Tomohiro <misono.tomohiro@jp.fujitsu.com> wrote: > Subject: [RFC PATCH 00/10] Add Fujitsu A64FX soc entry/hardware barrier driver > [RFC] > This is the first time we upstream drivers for our chip and I want to > confirm driver location and patch submission process. > > Based on my observation it seems drivers/soc folder is right place to put > this driver, so I added Kconfig entry for arm64 platform config, created > soc/fujitsu folder and updated MAINTAINER entry accordingly (last patch). > Is it right? This looks good as a start. It may be possible that during review, we come up with a different location or a different user interface that may change the code, but if it stays in drivers/soc/fujitsu, then the other steps are absolutely right. > Also for final submission I think I need to 1) create some public git > tree to push driver code (github or something), 2) make pull request to > SOC team (soc@kernel.org). Is it a correct procedure? Yes. I would prefer something other than github, e.g. an account on a fujitsu.com host, on kernel.org, or on git.linaro.org, but github works if none of the alternatives are easy for you. When you send a pull request, make sure you sign the tag with a gpg key, ideally after getting it on the kernel.org keyring [1]. Arnd [1] https://korg.docs.kernel.org/pgpkeys.html _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <CAGMNF6W8baS_zLYL8DwVsbfPWTP2ohzRB7xutW0X=MUzv93pbA@mail.gmail.com>]
* Re: [not found] <CAGMNF6W8baS_zLYL8DwVsbfPWTP2ohzRB7xutW0X=MUzv93pbA@mail.gmail.com> @ 2020-12-02 17:09 ` Kun Yi 0 siblings, 0 replies; 1767+ messages in thread From: Kun Yi @ 2020-12-02 17:09 UTC (permalink / raw) To: Kun Yi, Guenter Roeck, robh+dt, Venkatesh, Supreeth Cc: OpenBMC Maillist, linux-hwmon, linux-kernel Much apologies for the super late reply.. I was out for an extended period of time due to personal circumstances. I have now addressed most of the comments in the v4 series. Also cc'ed Supreeth who works on the AMD System Manageability stack. On Wed, Dec 2, 2020 at 8:57 AM Kun Yi <kunyi@google.com> wrote: > > On Sat, Apr 04, 2020 at 08:01:16PM -0700, Kun Yi wrote: > > SB Temperature Sensor Interface (SB-TSI) is an SMBus compatible > > interface that reports AMD SoC's Ttcl (normalized temperature), > > and resembles a typical 8-pin remote temperature sensor's I2C interface > > to BMC. > > > > This commit adds basic support using this interface to read CPU > > temperature, and read/write high/low CPU temp thresholds. > > > > To instantiate this driver on an AMD CPU with SB-TSI > > support, the i2c bus number would be the bus connected from the board > > management controller (BMC) to the CPU. The i2c address is specified in > > Section 6.3.1 of the spec [1]: The SB-TSI address is normally 98h for socket 0 > > and 90h for socket 1, but it could vary based on hardware address select pins. > > > > [1]: https://www.amd.com/system/files/TechDocs/56255_OSRR.pdf > > > > Test status: tested reading temp1_input, and reading/writing > > temp1_max/min. > > > > Signed-off-by: Kun Yi <kunyi at google.com> > > --- > > drivers/hwmon/Kconfig | 10 ++ > > drivers/hwmon/Makefile | 1 + > > drivers/hwmon/sbtsi_temp.c | 259 +++++++++++++++++++++++++++++++++++++ > > 3 files changed, 270 insertions(+) > > create mode 100644 drivers/hwmon/sbtsi_temp.c > > > > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig > > index 05a30832c6ba..9585dcd01d1b 100644 > > --- a/drivers/hwmon/Kconfig > > +++ b/drivers/hwmon/Kconfig > > @@ -1412,6 +1412,16 @@ config SENSORS_RASPBERRYPI_HWMON > > This driver can also be built as a module. If so, the module > > will be called raspberrypi-hwmon. > > > > +config SENSORS_SBTSI > > + tristate "Emulated SB-TSI temperature sensor" > > + depends on I2C > > + help > > + If you say yes here you get support for emulated temperature > > + sensors on AMD SoCs with SB-TSI interface connected to a BMC device. > > + > > + This driver can also be built as a module. If so, the module will > > + be called sbtsi_temp. > > + > > config SENSORS_SHT15 > > tristate "Sensiron humidity and temperature sensors. SHT15 and compat." > > depends on GPIOLIB || COMPILE_TEST > > diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile > > index b0b9c8e57176..cd109f003ce4 100644 > > --- a/drivers/hwmon/Makefile > > +++ b/drivers/hwmon/Makefile > > @@ -152,6 +152,7 @@ obj-$(CONFIG_SENSORS_POWR1220) += powr1220.o > > obj-$(CONFIG_SENSORS_PWM_FAN) += pwm-fan.o > > obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON) += raspberrypi-hwmon.o > > obj-$(CONFIG_SENSORS_S3C) += s3c-hwmon.o > > +obj-$(CONFIG_SENSORS_SBTSI) += sbtsi_temp.o > > obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o > > obj-$(CONFIG_SENSORS_SCH5627) += sch5627.o > > obj-$(CONFIG_SENSORS_SCH5636) += sch5636.o > > diff --git a/drivers/hwmon/sbtsi_temp.c b/drivers/hwmon/sbtsi_temp.c > > new file mode 100644 > > index 000000000000..e3ad6a9f7ec1 > > --- /dev/null > > +++ b/drivers/hwmon/sbtsi_temp.c > > @@ -0,0 +1,259 @@ > > +// SPDX-License-Identifier: GPL-2.0-or-later > > +/* > > + * sbtsi_temp.c - hwmon driver for a SBI Temperature Sensor Interface (SB-TSI) > > + * compliant AMD SoC temperature device. > > + * > > + * Copyright (c) 2020, Google Inc. > > + * Copyright (c) 2020, Kun Yi <kunyi at google.com> > > + */ > > + > > +#include <linux/err.h> > > +#include <linux/i2c.h> > > +#include <linux/init.h> > > +#include <linux/hwmon.h> > > +#include <linux/module.h> > > +#include <linux/mutex.h> > > +#include <linux/of_device.h> > > +#include <linux/of.h> > > + > > +/* > > + * SB-TSI registers only support SMBus byte data access. "_INT" registers are > > + * the integer part of a temperature value or limit, and "_DEC" registers are > > + * corresponding decimal parts. > > + */ > > +#define SBTSI_REG_TEMP_INT 0x01 /* RO */ > > +#define SBTSI_REG_STATUS 0x02 /* RO */ > > +#define SBTSI_REG_CONFIG 0x03 /* RO */ > > +#define SBTSI_REG_TEMP_HIGH_INT 0x07 /* RW */ > > +#define SBTSI_REG_TEMP_LOW_INT 0x08 /* RW */ > > +#define SBTSI_REG_TEMP_DEC 0x10 /* RW */ > > +#define SBTSI_REG_TEMP_HIGH_DEC 0x13 /* RW */ > > +#define SBTSI_REG_TEMP_LOW_DEC 0x14 /* RW */ > > +#define SBTSI_REG_REV 0xFF /* RO */ > > The revision register is not actually used. Thanks. Removed. I agree that the register is not well documented, at least publicly. It shouldn't affect functionality of this driver, so I removed the definition altogether. > > > + > > +#define SBTSI_CONFIG_READ_ORDER_SHIFT 5 > > + > > +#define SBTSI_TEMP_MIN 0 > > +#define SBTSI_TEMP_MAX 255875 > > +#define SBTSI_REV_MAX_VALID_ID 4 > > Not actually used, and I am not sure if it would make sense to check it. > If at all, it would only make sense if you also check SBTSIxFE (Manufacture > ID). Unfortunately, the actual SB-TSI specification seems to be non-public, > so I can't check if the driver as-is supports versions 0..3 (assuming those > exist). Thanks. Removed. > > > + > > +/* Each client has this additional data */ > > +struct sbtsi_data { > > + struct i2c_client *client; > > + struct mutex lock; > > +}; > > + > > +/* > > + * From SB-TSI spec: CPU temperature readings and limit registers encode the > > + * temperature in increments of 0.125 from 0 to 255.875. The "high byte" > > + * register encodes the base-2 of the integer portion, and the upper 3 bits of > > + * the "low byte" encode in base-2 the decimal portion. > > + * > > + * e.g. INT=0x19, DEC=0x20 represents 25.125 degrees Celsius > > + * > > + * Therefore temperature in millidegree Celsius = > > + * (INT + DEC / 256) * 1000 = (INT * 8 + DEC / 32) * 125 > > + */ > > +static inline int sbtsi_reg_to_mc(s32 integer, s32 decimal) > > +{ > > + return ((integer << 3) + (decimal >> 5)) * 125; > > +} > > + > > +/* > > + * Inversely, given temperature in millidegree Celsius > > + * INT = (TEMP / 125) / 8 > > + * DEC = ((TEMP / 125) % 8) * 32 > > + * Caller have to make sure temp doesn't exceed 255875, the max valid value. > > + */ > > +static inline void sbtsi_mc_to_reg(s32 temp, u8 *integer, u8 *decimal) > > +{ > > + temp /= 125; > > + *integer = temp >> 3; > > + *decimal = (temp & 0x7) << 5; > > +} > > + > > +static int sbtsi_read(struct device *dev, enum hwmon_sensor_types type, > > + u32 attr, int channel, long *val) > > +{ > > + struct sbtsi_data *data = dev_get_drvdata(dev); > > + s32 temp_int, temp_dec; > > + int err, reg_int, reg_dec; > > + u8 read_order; > > + > > + if (type != hwmon_temp) > > + return -EINVAL; > > + > > + read_order = 0; > > + switch (attr) { > > + case hwmon_temp_input: > > + /* > > + * ReadOrder bit specifies the reading order of integer and > > + * decimal part of CPU temp for atomic reads. If bit == 0, > > + * reading integer part triggers latching of the decimal part, > > + * so integer part should be read first. If bit == 1, read > > + * order should be reversed. > > + */ > > + err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG); > > + if (err < 0) > > + return err; > > + > As I understand it, the idea is to set this configuration bit once and then > just use it. Any chance to do that ? This would save an i2c read operation > each time the temperature is read, and the if/else complexity below. Unfortunately, the read-order register bit is read-only. > > > + read_order = (u8)err & BIT(SBTSI_CONFIG_READ_ORDER_SHIFT); > > Nit: typecast is unnecessary. Done. > > > + reg_int = SBTSI_REG_TEMP_INT; > > + reg_dec = SBTSI_REG_TEMP_DEC; > > + break; > > + case hwmon_temp_max: > > + reg_int = SBTSI_REG_TEMP_HIGH_INT; > > + reg_dec = SBTSI_REG_TEMP_HIGH_DEC; > > + break; > > + case hwmon_temp_min: > > + reg_int = SBTSI_REG_TEMP_LOW_INT; > > + reg_dec = SBTSI_REG_TEMP_LOW_DEC; > > + break; > > + default: > > + return -EINVAL; > > + } > > + > > + if (read_order == 0) { > > + temp_int = i2c_smbus_read_byte_data(data->client, reg_int); > > + temp_dec = i2c_smbus_read_byte_data(data->client, reg_dec); > > + } else { > > + temp_dec = i2c_smbus_read_byte_data(data->client, reg_dec); > > + temp_int = i2c_smbus_read_byte_data(data->client, reg_int); > > + } > > Just a thought: if you use regmap and tell it that the limit registers > are non-volatile, this wouldn't actually read from the chip more than once. That's a great suggestion, although in our normal use cases the limit values are read and cached by the userspace application. Seems changing to regmap would require some messaging of the code. Would it be acceptable to keep the initial driver as-is and do that in a following patch? > > Also, since the read involves reading two registers, and the first read > locks the value for the second, you'll need mutex protection when reading > the current temperature (not for limits, though). Added mutex locking before/after the temp input reading. > > > + > > + if (temp_int < 0) > > + return temp_int; > > + if (temp_dec < 0) > > + return temp_dec; > > + > > + *val = sbtsi_reg_to_mc(temp_int, temp_dec); > > + > > + return 0; > > +} > > + > > +static int sbtsi_write(struct device *dev, enum hwmon_sensor_types type, > > + u32 attr, int channel, long val) > > +{ > > + struct sbtsi_data *data = dev_get_drvdata(dev); > > + int reg_int, reg_dec, err; > > + u8 temp_int, temp_dec; > > + > > + if (type != hwmon_temp) > > + return -EINVAL; > > + > > + switch (attr) { > > + case hwmon_temp_max: > > + reg_int = SBTSI_REG_TEMP_HIGH_INT; > > + reg_dec = SBTSI_REG_TEMP_HIGH_DEC; > > + break; > > + case hwmon_temp_min: > > + reg_int = SBTSI_REG_TEMP_LOW_INT; > > + reg_dec = SBTSI_REG_TEMP_LOW_DEC; > > + break; > > + default: > > + return -EINVAL; > > + } > > + > > + val = clamp_val(val, SBTSI_TEMP_MIN, SBTSI_TEMP_MAX); > > + mutex_lock(&data->lock); > > + sbtsi_mc_to_reg(val, &temp_int, &temp_dec); > > + err = i2c_smbus_write_byte_data(data->client, reg_int, temp_int); > > + if (err) > > + goto exit; > > + > > + err = i2c_smbus_write_byte_data(data->client, reg_dec, temp_dec); > > +exit: > > + mutex_unlock(&data->lock); > > + return err; > > +} > > + > > +static umode_t sbtsi_is_visible(const void *data, > > + enum hwmon_sensor_types type, > > + u32 attr, int channel) > > +{ > > + switch (type) { > > + case hwmon_temp: > > + switch (attr) { > > + case hwmon_temp_input: > > + return 0444; > > + case hwmon_temp_min: > > + return 0644; > > + case hwmon_temp_max: > > + return 0644; > > + } > > + break; > > + default: > > + break; > > + } > > + return 0; > > +} > > + > > +static const struct hwmon_channel_info *sbtsi_info[] = { > > + HWMON_CHANNEL_INFO(chip, > > + HWMON_C_REGISTER_TZ), > > + HWMON_CHANNEL_INFO(temp, > > + HWMON_T_INPUT | HWMON_T_MIN | HWMON_T_MAX), > > For your consideration: SB-TSI supports reporting high/low alerts. > With this, it would be possible to implement respective alarm attributes. > In conjunction with https://patchwork.kernel.org/patch/11277347/mbox/, > it should also be possible to add interrupt and thus userspace notification > for those attributes. > > SBTSI also supports setting the update rate (SBTSIx04) and setting > the temperature offset (SBTSIx11, SBTSIx12), which could also be > implemented as standard attributes. > > I won't require that for the initial version, just something to keep > in mind. Ack and thanks for the suggestions. I will keep in mind for future improvements. > > > + NULL > > +}; > > + > > +static const struct hwmon_ops sbtsi_hwmon_ops = { > > + .is_visible = sbtsi_is_visible, > > + .read = sbtsi_read, > > + .write = sbtsi_write, > > +}; > > + > > +static const struct hwmon_chip_info sbtsi_chip_info = { > > + .ops = &sbtsi_hwmon_ops, > > + .info = sbtsi_info, > > +}; > > + > > +static int sbtsi_probe(struct i2c_client *client, > > + const struct i2c_device_id *id) > > +{ > > + struct device *dev = &client->dev; > > + struct device *hwmon_dev; > > + struct sbtsi_data *data; > > + > > + data = devm_kzalloc(dev, sizeof(struct sbtsi_data), GFP_KERNEL); > > + if (!data) > > + return -ENOMEM; > > + > > + data->client = client; > > + mutex_init(&data->lock); > > + > > + hwmon_dev = > > + devm_hwmon_device_register_with_info(dev, client->name, data, > > + &sbtsi_chip_info, NULL); > > + > > + return PTR_ERR_OR_ZERO(hwmon_dev); > > +} > > + > > +static const struct i2c_device_id sbtsi_id[] = { > > + {"sbtsi", 0}, > > + {} > > +}; > > +MODULE_DEVICE_TABLE(i2c, sbtsi_id); > > + > > +static const struct of_device_id __maybe_unused sbtsi_of_match[] = { > > + { > > + .compatible = "amd,sbtsi", > > + }, > > + { }, > > +}; > > +MODULE_DEVICE_TABLE(of, sbtsi_of_match); > > + > > +static struct i2c_driver sbtsi_driver = { > > + .class = I2C_CLASS_HWMON, > > + .driver = { > > + .name = "sbtsi", > > + .of_match_table = of_match_ptr(sbtsi_of_match), > > + }, > > + .probe = sbtsi_probe, > > + .id_table = sbtsi_id, > > +}; > > + > > +module_i2c_driver(sbtsi_driver); > > + > > +MODULE_AUTHOR("Kun Yi <kunyi at google.com>"); > > +MODULE_DESCRIPTION("Hwmon driver for AMD SB-TSI emulated sensor"); > > +MODULE_LICENSE("GPL"); -- Regards, Kun ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2020-12-02 17:09 ` Kun Yi 0 siblings, 0 replies; 1767+ messages in thread From: Kun Yi @ 2020-12-02 17:09 UTC (permalink / raw) To: Kun Yi, Guenter Roeck, robh+dt, Venkatesh, Supreeth Cc: linux-hwmon, OpenBMC Maillist, linux-kernel Much apologies for the super late reply.. I was out for an extended period of time due to personal circumstances. I have now addressed most of the comments in the v4 series. Also cc'ed Supreeth who works on the AMD System Manageability stack. On Wed, Dec 2, 2020 at 8:57 AM Kun Yi <kunyi@google.com> wrote: > > On Sat, Apr 04, 2020 at 08:01:16PM -0700, Kun Yi wrote: > > SB Temperature Sensor Interface (SB-TSI) is an SMBus compatible > > interface that reports AMD SoC's Ttcl (normalized temperature), > > and resembles a typical 8-pin remote temperature sensor's I2C interface > > to BMC. > > > > This commit adds basic support using this interface to read CPU > > temperature, and read/write high/low CPU temp thresholds. > > > > To instantiate this driver on an AMD CPU with SB-TSI > > support, the i2c bus number would be the bus connected from the board > > management controller (BMC) to the CPU. The i2c address is specified in > > Section 6.3.1 of the spec [1]: The SB-TSI address is normally 98h for socket 0 > > and 90h for socket 1, but it could vary based on hardware address select pins. > > > > [1]: https://www.amd.com/system/files/TechDocs/56255_OSRR.pdf > > > > Test status: tested reading temp1_input, and reading/writing > > temp1_max/min. > > > > Signed-off-by: Kun Yi <kunyi at google.com> > > --- > > drivers/hwmon/Kconfig | 10 ++ > > drivers/hwmon/Makefile | 1 + > > drivers/hwmon/sbtsi_temp.c | 259 +++++++++++++++++++++++++++++++++++++ > > 3 files changed, 270 insertions(+) > > create mode 100644 drivers/hwmon/sbtsi_temp.c > > > > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig > > index 05a30832c6ba..9585dcd01d1b 100644 > > --- a/drivers/hwmon/Kconfig > > +++ b/drivers/hwmon/Kconfig > > @@ -1412,6 +1412,16 @@ config SENSORS_RASPBERRYPI_HWMON > > This driver can also be built as a module. If so, the module > > will be called raspberrypi-hwmon. > > > > +config SENSORS_SBTSI > > + tristate "Emulated SB-TSI temperature sensor" > > + depends on I2C > > + help > > + If you say yes here you get support for emulated temperature > > + sensors on AMD SoCs with SB-TSI interface connected to a BMC device. > > + > > + This driver can also be built as a module. If so, the module will > > + be called sbtsi_temp. > > + > > config SENSORS_SHT15 > > tristate "Sensiron humidity and temperature sensors. SHT15 and compat." > > depends on GPIOLIB || COMPILE_TEST > > diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile > > index b0b9c8e57176..cd109f003ce4 100644 > > --- a/drivers/hwmon/Makefile > > +++ b/drivers/hwmon/Makefile > > @@ -152,6 +152,7 @@ obj-$(CONFIG_SENSORS_POWR1220) += powr1220.o > > obj-$(CONFIG_SENSORS_PWM_FAN) += pwm-fan.o > > obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON) += raspberrypi-hwmon.o > > obj-$(CONFIG_SENSORS_S3C) += s3c-hwmon.o > > +obj-$(CONFIG_SENSORS_SBTSI) += sbtsi_temp.o > > obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o > > obj-$(CONFIG_SENSORS_SCH5627) += sch5627.o > > obj-$(CONFIG_SENSORS_SCH5636) += sch5636.o > > diff --git a/drivers/hwmon/sbtsi_temp.c b/drivers/hwmon/sbtsi_temp.c > > new file mode 100644 > > index 000000000000..e3ad6a9f7ec1 > > --- /dev/null > > +++ b/drivers/hwmon/sbtsi_temp.c > > @@ -0,0 +1,259 @@ > > +// SPDX-License-Identifier: GPL-2.0-or-later > > +/* > > + * sbtsi_temp.c - hwmon driver for a SBI Temperature Sensor Interface (SB-TSI) > > + * compliant AMD SoC temperature device. > > + * > > + * Copyright (c) 2020, Google Inc. > > + * Copyright (c) 2020, Kun Yi <kunyi at google.com> > > + */ > > + > > +#include <linux/err.h> > > +#include <linux/i2c.h> > > +#include <linux/init.h> > > +#include <linux/hwmon.h> > > +#include <linux/module.h> > > +#include <linux/mutex.h> > > +#include <linux/of_device.h> > > +#include <linux/of.h> > > + > > +/* > > + * SB-TSI registers only support SMBus byte data access. "_INT" registers are > > + * the integer part of a temperature value or limit, and "_DEC" registers are > > + * corresponding decimal parts. > > + */ > > +#define SBTSI_REG_TEMP_INT 0x01 /* RO */ > > +#define SBTSI_REG_STATUS 0x02 /* RO */ > > +#define SBTSI_REG_CONFIG 0x03 /* RO */ > > +#define SBTSI_REG_TEMP_HIGH_INT 0x07 /* RW */ > > +#define SBTSI_REG_TEMP_LOW_INT 0x08 /* RW */ > > +#define SBTSI_REG_TEMP_DEC 0x10 /* RW */ > > +#define SBTSI_REG_TEMP_HIGH_DEC 0x13 /* RW */ > > +#define SBTSI_REG_TEMP_LOW_DEC 0x14 /* RW */ > > +#define SBTSI_REG_REV 0xFF /* RO */ > > The revision register is not actually used. Thanks. Removed. I agree that the register is not well documented, at least publicly. It shouldn't affect functionality of this driver, so I removed the definition altogether. > > > + > > +#define SBTSI_CONFIG_READ_ORDER_SHIFT 5 > > + > > +#define SBTSI_TEMP_MIN 0 > > +#define SBTSI_TEMP_MAX 255875 > > +#define SBTSI_REV_MAX_VALID_ID 4 > > Not actually used, and I am not sure if it would make sense to check it. > If at all, it would only make sense if you also check SBTSIxFE (Manufacture > ID). Unfortunately, the actual SB-TSI specification seems to be non-public, > so I can't check if the driver as-is supports versions 0..3 (assuming those > exist). Thanks. Removed. > > > + > > +/* Each client has this additional data */ > > +struct sbtsi_data { > > + struct i2c_client *client; > > + struct mutex lock; > > +}; > > + > > +/* > > + * From SB-TSI spec: CPU temperature readings and limit registers encode the > > + * temperature in increments of 0.125 from 0 to 255.875. The "high byte" > > + * register encodes the base-2 of the integer portion, and the upper 3 bits of > > + * the "low byte" encode in base-2 the decimal portion. > > + * > > + * e.g. INT=0x19, DEC=0x20 represents 25.125 degrees Celsius > > + * > > + * Therefore temperature in millidegree Celsius = > > + * (INT + DEC / 256) * 1000 = (INT * 8 + DEC / 32) * 125 > > + */ > > +static inline int sbtsi_reg_to_mc(s32 integer, s32 decimal) > > +{ > > + return ((integer << 3) + (decimal >> 5)) * 125; > > +} > > + > > +/* > > + * Inversely, given temperature in millidegree Celsius > > + * INT = (TEMP / 125) / 8 > > + * DEC = ((TEMP / 125) % 8) * 32 > > + * Caller have to make sure temp doesn't exceed 255875, the max valid value. > > + */ > > +static inline void sbtsi_mc_to_reg(s32 temp, u8 *integer, u8 *decimal) > > +{ > > + temp /= 125; > > + *integer = temp >> 3; > > + *decimal = (temp & 0x7) << 5; > > +} > > + > > +static int sbtsi_read(struct device *dev, enum hwmon_sensor_types type, > > + u32 attr, int channel, long *val) > > +{ > > + struct sbtsi_data *data = dev_get_drvdata(dev); > > + s32 temp_int, temp_dec; > > + int err, reg_int, reg_dec; > > + u8 read_order; > > + > > + if (type != hwmon_temp) > > + return -EINVAL; > > + > > + read_order = 0; > > + switch (attr) { > > + case hwmon_temp_input: > > + /* > > + * ReadOrder bit specifies the reading order of integer and > > + * decimal part of CPU temp for atomic reads. If bit == 0, > > + * reading integer part triggers latching of the decimal part, > > + * so integer part should be read first. If bit == 1, read > > + * order should be reversed. > > + */ > > + err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG); > > + if (err < 0) > > + return err; > > + > As I understand it, the idea is to set this configuration bit once and then > just use it. Any chance to do that ? This would save an i2c read operation > each time the temperature is read, and the if/else complexity below. Unfortunately, the read-order register bit is read-only. > > > + read_order = (u8)err & BIT(SBTSI_CONFIG_READ_ORDER_SHIFT); > > Nit: typecast is unnecessary. Done. > > > + reg_int = SBTSI_REG_TEMP_INT; > > + reg_dec = SBTSI_REG_TEMP_DEC; > > + break; > > + case hwmon_temp_max: > > + reg_int = SBTSI_REG_TEMP_HIGH_INT; > > + reg_dec = SBTSI_REG_TEMP_HIGH_DEC; > > + break; > > + case hwmon_temp_min: > > + reg_int = SBTSI_REG_TEMP_LOW_INT; > > + reg_dec = SBTSI_REG_TEMP_LOW_DEC; > > + break; > > + default: > > + return -EINVAL; > > + } > > + > > + if (read_order == 0) { > > + temp_int = i2c_smbus_read_byte_data(data->client, reg_int); > > + temp_dec = i2c_smbus_read_byte_data(data->client, reg_dec); > > + } else { > > + temp_dec = i2c_smbus_read_byte_data(data->client, reg_dec); > > + temp_int = i2c_smbus_read_byte_data(data->client, reg_int); > > + } > > Just a thought: if you use regmap and tell it that the limit registers > are non-volatile, this wouldn't actually read from the chip more than once. That's a great suggestion, although in our normal use cases the limit values are read and cached by the userspace application. Seems changing to regmap would require some messaging of the code. Would it be acceptable to keep the initial driver as-is and do that in a following patch? > > Also, since the read involves reading two registers, and the first read > locks the value for the second, you'll need mutex protection when reading > the current temperature (not for limits, though). Added mutex locking before/after the temp input reading. > > > + > > + if (temp_int < 0) > > + return temp_int; > > + if (temp_dec < 0) > > + return temp_dec; > > + > > + *val = sbtsi_reg_to_mc(temp_int, temp_dec); > > + > > + return 0; > > +} > > + > > +static int sbtsi_write(struct device *dev, enum hwmon_sensor_types type, > > + u32 attr, int channel, long val) > > +{ > > + struct sbtsi_data *data = dev_get_drvdata(dev); > > + int reg_int, reg_dec, err; > > + u8 temp_int, temp_dec; > > + > > + if (type != hwmon_temp) > > + return -EINVAL; > > + > > + switch (attr) { > > + case hwmon_temp_max: > > + reg_int = SBTSI_REG_TEMP_HIGH_INT; > > + reg_dec = SBTSI_REG_TEMP_HIGH_DEC; > > + break; > > + case hwmon_temp_min: > > + reg_int = SBTSI_REG_TEMP_LOW_INT; > > + reg_dec = SBTSI_REG_TEMP_LOW_DEC; > > + break; > > + default: > > + return -EINVAL; > > + } > > + > > + val = clamp_val(val, SBTSI_TEMP_MIN, SBTSI_TEMP_MAX); > > + mutex_lock(&data->lock); > > + sbtsi_mc_to_reg(val, &temp_int, &temp_dec); > > + err = i2c_smbus_write_byte_data(data->client, reg_int, temp_int); > > + if (err) > > + goto exit; > > + > > + err = i2c_smbus_write_byte_data(data->client, reg_dec, temp_dec); > > +exit: > > + mutex_unlock(&data->lock); > > + return err; > > +} > > + > > +static umode_t sbtsi_is_visible(const void *data, > > + enum hwmon_sensor_types type, > > + u32 attr, int channel) > > +{ > > + switch (type) { > > + case hwmon_temp: > > + switch (attr) { > > + case hwmon_temp_input: > > + return 0444; > > + case hwmon_temp_min: > > + return 0644; > > + case hwmon_temp_max: > > + return 0644; > > + } > > + break; > > + default: > > + break; > > + } > > + return 0; > > +} > > + > > +static const struct hwmon_channel_info *sbtsi_info[] = { > > + HWMON_CHANNEL_INFO(chip, > > + HWMON_C_REGISTER_TZ), > > + HWMON_CHANNEL_INFO(temp, > > + HWMON_T_INPUT | HWMON_T_MIN | HWMON_T_MAX), > > For your consideration: SB-TSI supports reporting high/low alerts. > With this, it would be possible to implement respective alarm attributes. > In conjunction with https://patchwork.kernel.org/patch/11277347/mbox/, > it should also be possible to add interrupt and thus userspace notification > for those attributes. > > SBTSI also supports setting the update rate (SBTSIx04) and setting > the temperature offset (SBTSIx11, SBTSIx12), which could also be > implemented as standard attributes. > > I won't require that for the initial version, just something to keep > in mind. Ack and thanks for the suggestions. I will keep in mind for future improvements. > > > + NULL > > +}; > > + > > +static const struct hwmon_ops sbtsi_hwmon_ops = { > > + .is_visible = sbtsi_is_visible, > > + .read = sbtsi_read, > > + .write = sbtsi_write, > > +}; > > + > > +static const struct hwmon_chip_info sbtsi_chip_info = { > > + .ops = &sbtsi_hwmon_ops, > > + .info = sbtsi_info, > > +}; > > + > > +static int sbtsi_probe(struct i2c_client *client, > > + const struct i2c_device_id *id) > > +{ > > + struct device *dev = &client->dev; > > + struct device *hwmon_dev; > > + struct sbtsi_data *data; > > + > > + data = devm_kzalloc(dev, sizeof(struct sbtsi_data), GFP_KERNEL); > > + if (!data) > > + return -ENOMEM; > > + > > + data->client = client; > > + mutex_init(&data->lock); > > + > > + hwmon_dev = > > + devm_hwmon_device_register_with_info(dev, client->name, data, > > + &sbtsi_chip_info, NULL); > > + > > + return PTR_ERR_OR_ZERO(hwmon_dev); > > +} > > + > > +static const struct i2c_device_id sbtsi_id[] = { > > + {"sbtsi", 0}, > > + {} > > +}; > > +MODULE_DEVICE_TABLE(i2c, sbtsi_id); > > + > > +static const struct of_device_id __maybe_unused sbtsi_of_match[] = { > > + { > > + .compatible = "amd,sbtsi", > > + }, > > + { }, > > +}; > > +MODULE_DEVICE_TABLE(of, sbtsi_of_match); > > + > > +static struct i2c_driver sbtsi_driver = { > > + .class = I2C_CLASS_HWMON, > > + .driver = { > > + .name = "sbtsi", > > + .of_match_table = of_match_ptr(sbtsi_of_match), > > + }, > > + .probe = sbtsi_probe, > > + .id_table = sbtsi_id, > > +}; > > + > > +module_i2c_driver(sbtsi_driver); > > + > > +MODULE_AUTHOR("Kun Yi <kunyi at google.com>"); > > +MODULE_DESCRIPTION("Hwmon driver for AMD SB-TSI emulated sensor"); > > +MODULE_LICENSE("GPL"); -- Regards, Kun ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH] lib/find_bit: Add find_prev_*_bit functions. @ 2020-12-02 1:10 Yun Levi 2020-12-02 9:47 ` Andy Shevchenko 0 siblings, 1 reply; 1767+ messages in thread From: Yun Levi @ 2020-12-02 1:10 UTC (permalink / raw) To: dushistov, arnd, akpm, gustavo, vilhelm.gray, richard.weiyang, andriy.shevchenko, joseph.qi, skalluru, yury.norov, jpoimboe Cc: linux-kernel, linux-arch Inspired find_next_*bit function series, add find_prev_*_bit series. I'm not sure whether it'll be used right now But, I add these functions for future usage. Signed-off-by: Levi Yun <ppbuk5246@gmail.com> --- fs/ufs/util.h | 24 +++--- include/asm-generic/bitops/find.h | 69 ++++++++++++++++ include/asm-generic/bitops/le.h | 33 ++++++++ include/linux/bitops.h | 34 +++++--- lib/find_bit.c | 126 +++++++++++++++++++++++++++++- 5 files changed, 260 insertions(+), 26 deletions(-) diff --git a/fs/ufs/util.h b/fs/ufs/util.h index 4931bec1a01c..7c87c77d10ca 100644 --- a/fs/ufs/util.h +++ b/fs/ufs/util.h @@ -2,7 +2,7 @@ /* * linux/fs/ufs/util.h * - * Copyright (C) 1998 + * Copyright (C) 1998 * Daniel Pirkl <daniel.pirkl@email.cz> * Charles University, Faculty of Mathematics and Physics */ @@ -263,7 +263,7 @@ extern int ufs_prepare_chunk(struct page *page, loff_t pos, unsigned len); /* * These functions manipulate ufs buffers */ -#define ubh_bread(sb,fragment,size) _ubh_bread_(uspi,sb,fragment,size) +#define ubh_bread(sb,fragment,size) _ubh_bread_(uspi,sb,fragment,size) extern struct ufs_buffer_head * _ubh_bread_(struct ufs_sb_private_info *, struct super_block *, u64 , u64); extern struct ufs_buffer_head * ubh_bread_uspi(struct ufs_sb_private_info *, struct super_block *, u64, u64); extern void ubh_brelse (struct ufs_buffer_head *); @@ -296,7 +296,7 @@ static inline void *get_usb_offset(struct ufs_sb_private_info *uspi, unsigned int offset) { unsigned int index; - + index = offset >> uspi->s_fshift; offset &= ~uspi->s_fmask; return uspi->s_ubh.bh[index]->b_data + offset; @@ -411,9 +411,9 @@ static inline unsigned _ubh_find_next_zero_bit_( offset = 0; } return (base << uspi->s_bpfshift) + pos - begin; -} +} -static inline unsigned find_last_zero_bit (unsigned char * bitmap, +static inline unsigned __ubh_find_last_zero_bit(unsigned char * bitmap, unsigned size, unsigned offset) { unsigned bit, i; @@ -453,7 +453,7 @@ static inline unsigned _ubh_find_last_zero_bit_( size + (uspi->s_bpf - start), uspi->s_bpf) - (uspi->s_bpf - start); size -= count; - pos = find_last_zero_bit (ubh->bh[base]->b_data, + pos = __ubh_find_last_zero_bit(ubh->bh[base]->b_data, start, start - count); if (pos > start - count || !size) break; @@ -461,7 +461,7 @@ static inline unsigned _ubh_find_last_zero_bit_( start = uspi->s_bpf; } return (base << uspi->s_bpfshift) + pos - begin; -} +} #define ubh_isblockclear(ubh,begin,block) (!_ubh_isblockset_(uspi,ubh,begin,block)) @@ -483,7 +483,7 @@ static inline int _ubh_isblockset_(struct ufs_sb_private_info * uspi, mask = 0x01 << (block & 0x07); return (*ubh_get_addr (ubh, begin + (block >> 3)) & mask) == mask; } - return 0; + return 0; } #define ubh_clrblock(ubh,begin,block) _ubh_clrblock_(uspi,ubh,begin,block) @@ -492,8 +492,8 @@ static inline void _ubh_clrblock_(struct ufs_sb_private_info * uspi, { switch (uspi->s_fpb) { case 8: - *ubh_get_addr (ubh, begin + block) = 0x00; - return; + *ubh_get_addr (ubh, begin + block) = 0x00; + return; case 4: *ubh_get_addr (ubh, begin + (block >> 1)) &= ~(0x0f << ((block & 0x01) << 2)); return; @@ -531,9 +531,9 @@ static inline void ufs_fragacct (struct super_block * sb, unsigned blockmap, { struct ufs_sb_private_info * uspi; unsigned fragsize, pos; - + uspi = UFS_SB(sb)->s_uspi; - + fragsize = 0; for (pos = 0; pos < uspi->s_fpb; pos++) { if (blockmap & (1 << pos)) { diff --git a/include/asm-generic/bitops/find.h b/include/asm-generic/bitops/find.h index 9fdf21302fdf..ca18b2ec954c 100644 --- a/include/asm-generic/bitops/find.h +++ b/include/asm-generic/bitops/find.h @@ -16,6 +16,20 @@ extern unsigned long find_next_bit(const unsigned long *addr, unsigned long size, unsigned long offset); #endif +#ifndef find_prev_bit +/** + * find_prev_bit - find the prev set bit in a memory region + * @addr: The address to base the search on + * @offset: The bitnumber to start searching at + * @size: The bitmap size in bits + * + * Returns the bit number for the prev set bit + * If no bits are set, returns @size. + */ +extern unsigned long find_prev_bit(const unsigned long *addr, unsigned long + size, unsigned long offset); +#endif + #ifndef find_next_and_bit /** * find_next_and_bit - find the next set bit in both memory regions @@ -32,6 +46,22 @@ extern unsigned long find_next_and_bit(const unsigned long *addr1, unsigned long offset); #endif +#ifndef find_prev_and_bit +/** + * find_prev_and_bit - find the prev set bit in both memory regions + * @addr1: The first address to base the search on + * @addr2: The second address to base the search on + * @offset: The bitnumber to start searching at + * @size: The bitmap size in bits + * + * Returns the bit number for the prev set bit + * If no bits are set, returns @size. + */ +extern unsigned long find_prev_and_bit(const unsigned long *addr1, + const unsigned long *addr2, unsigned long size, + unsigned long offset); +#endif + #ifndef find_next_zero_bit /** * find_next_zero_bit - find the next cleared bit in a memory region @@ -46,6 +76,20 @@ extern unsigned long find_next_zero_bit(const unsigned long *addr, unsigned long size, unsigned long offset); #endif +#ifndef find_prev_zero_bit +/** + * find_prev_zero_bit - find the prev cleared bit in a memory region + * @addr: The address to base the search on + * @offset: The bitnumber to start searching at + * @size: The bitmap size in bits + * + * Returns the bit number of the prev zero bit + * If no bits are zero, returns @size. + */ +extern unsigned long find_prev_zero_bit(const unsigned long *addr, unsigned + long size, unsigned long offset); +#endif + #ifdef CONFIG_GENERIC_FIND_FIRST_BIT /** @@ -80,6 +124,31 @@ extern unsigned long find_first_zero_bit(const unsigned long *addr, #endif /* CONFIG_GENERIC_FIND_FIRST_BIT */ +#ifndef find_last_bit +/** + * find_last_bit - find the last set bit in a memory region + * @addr: The address to start the search at + * @size: The number of bits to search + * + * Returns the bit number of the last set bit, or size. + */ +extern unsigned long find_last_bit(const unsigned long *addr, + unsigned long size); +#endif + +#ifndef find_last_zero_bit +/** + * find_last_zero_bit - find the last cleared bit in a memory region + * @addr: The address to start the search at + * @size: The maximum number of bits to search + * + * Returns the bit number of the first cleared bit. + * If no bits are zero, returns @size. + */ +extern unsigned long find_last_zero_bit(const unsigned long *addr, + unsigned long size); +#endif + /** * find_next_clump8 - find next 8-bit clump with set bits in a memory region * @clump: location to store copy of found clump diff --git a/include/asm-generic/bitops/le.h b/include/asm-generic/bitops/le.h index 188d3eba3ace..d0bd15bc34d9 100644 --- a/include/asm-generic/bitops/le.h +++ b/include/asm-generic/bitops/le.h @@ -27,6 +27,24 @@ static inline unsigned long find_first_zero_bit_le(const void *addr, return find_first_zero_bit(addr, size); } +static inline unsigned long find_prev_zero_bit_le(const void *addr, + unsigned long size, unsigned long offset) +{ + return find_prev_zero_bit(addr, size, offset); +} + +static inline unsigned long find_prev_bit_le(const void *addr, + unsigned long size, unsigned long offset) +{ + return find_prev_bit(addr, size, offset); +} + +static inline unsigned long find_last_zero_bit_le(const void *addr, + unsigned long size) +{ + return find_last_zero_bit(addr, size); +} + #elif defined(__BIG_ENDIAN) #define BITOP_LE_SWIZZLE ((BITS_PER_LONG-1) & ~0x7) @@ -41,11 +59,26 @@ extern unsigned long find_next_bit_le(const void *addr, unsigned long size, unsigned long offset); #endif +#ifndef find_prev_zero_bit_le +extern unsigned long find_prev_zero_bit_le(const void *addr, + unsigned long size, unsigned long offset); +#endif + +#ifndef find_prev_bit_le +extern unsigned long find_prev_bit_le(const void *addr, + unsigned long size, unsigned long offset); +#endif + #ifndef find_first_zero_bit_le #define find_first_zero_bit_le(addr, size) \ find_next_zero_bit_le((addr), (size), 0) #endif +#ifndef find_last_zero_bit_le +#define find_last_zero_bit_le(addr, size) \ + find_prev_zero_bit_le((addr), (size), (size - 1)) +#endif + #else #error "Please fix <asm/byteorder.h>" #endif diff --git a/include/linux/bitops.h b/include/linux/bitops.h index 5b74bdf159d6..124c68929861 100644 --- a/include/linux/bitops.h +++ b/include/linux/bitops.h @@ -50,6 +50,28 @@ extern unsigned long __sw_hweight64(__u64 w); (bit) < (size); \ (bit) = find_next_zero_bit((addr), (size), (bit) + 1)) +#define for_each_set_bit_reverse(bit, addr, size) \ + for ((bit) = find_last_bit((addr), (size)); \ + (bit) < (size); \ + (bit) = find_prev_bit((addr), (size), (bit))) + +/* same as for_each_set_bit_reverse() but use bit as value to start with */ +#define for_each_set_bit_from_reverse(bit, addr, size) \ + for ((bit) = find_prev_bit((addr), (size), (bit)); \ + (bit) < (size); \ + (bit) = find_prev_bit((addr), (size), (bit - 1))) + +#define for_each_clear_bit_reverse(bit, addr, size) \ + for ((bit) = find_last_zero_bit((addr), (size)); \ + (bit) < (size); \ + (bit) = find_prev_zero_bit((addr), (size), (bit))) + +/* same as for_each_clear_bit_reverse() but use bit as value to start with */ +#define for_each_clear_bit_from_reverse(bit, addr, size) \ + for ((bit) = find_prev_zero_bit((addr), (size), (bit)); \ + (bit) < (size); \ + (bit) = find_next_zero_bit((addr), (size), (bit - 1))) + /** * for_each_set_clump8 - iterate over bitmap for each 8-bit clump with set bits * @start: bit offset to start search and to store the current iteration offset @@ -283,17 +305,5 @@ static __always_inline void __assign_bit(long nr, volatile unsigned long *addr, }) #endif -#ifndef find_last_bit -/** - * find_last_bit - find the last set bit in a memory region - * @addr: The address to start the search at - * @size: The number of bits to search - * - * Returns the bit number of the last set bit, or size. - */ -extern unsigned long find_last_bit(const unsigned long *addr, - unsigned long size); -#endif - #endif /* __KERNEL__ */ #endif diff --git a/lib/find_bit.c b/lib/find_bit.c index 4a8751010d59..cbe06abd3d21 100644 --- a/lib/find_bit.c +++ b/lib/find_bit.c @@ -69,6 +69,58 @@ static unsigned long _find_next_bit(const unsigned long *addr1, } #endif +#if !defined(find_prev_bit) || !defined(find_prev_zero_bit) || \ + !defined(find_prev_bit_le) || !defined(find_prev_zero_bit_le) || \ + !defined(find_prev_and_bit) +/* + * This is a common helper function for find_prev_bit, find_prev_zero_bit, and + * find_prev_and_bit. The differences are: + * - The "invert" argument, which is XORed with each fetched word before + * searching it for one bits. + * - The optional "addr2", which is anded with "addr1" if present. + */ +static unsigned long _find_prev_bit(const unsigned long *addr1, + const unsigned long *addr2, unsigned long nbits, + unsigned long start, unsigned long invert, unsigned long le) +{ + unsigned long tmp, mask; + + if (unlikely(start >= nbits)) + return nbits; + + tmp = addr1[start / BITS_PER_LONG]; + if (addr2) + tmp &= addr2[start / BITS_PER_LONG]; + tmp ^= invert; + + /* Handle 1st word. */ + mask = BITMAP_LAST_WORD_MASK(start + 1); + if (le) + mask = swab(mask); + + tmp &= mask; + + start = round_down(start, BITS_PER_LONG); + + while (!tmp) { + start -= BITS_PER_LONG; + if (start >= nbits) + return nbits; + + tmp = addr1[start / BITS_PER_LONG]; + if (addr2) + tmp &= addr2[start / BITS_PER_LONG]; + tmp ^= invert; + } + + if (le) + tmp = swab(tmp); + + return start + __fls(tmp); +} +#endif + + #ifndef find_next_bit /* * Find the next set bit in a memory region. @@ -81,6 +133,18 @@ unsigned long find_next_bit(const unsigned long *addr, unsigned long size, EXPORT_SYMBOL(find_next_bit); #endif +#ifndef find_prev_bit +/* + * Find the prev set bit in a memory region. + */ +unsigned long find_prev_bit(const unsigned long *addr, unsigned long size, + unsigned long offset) +{ + return _find_prev_bit(addr, NULL, size, offset, 0UL, 0); +} +EXPORT_SYMBOL(find_prev_bit); +#endif + #ifndef find_next_zero_bit unsigned long find_next_zero_bit(const unsigned long *addr, unsigned long size, unsigned long offset) @@ -90,7 +154,16 @@ unsigned long find_next_zero_bit(const unsigned long *addr, unsigned long size, EXPORT_SYMBOL(find_next_zero_bit); #endif -#if !defined(find_next_and_bit) +#ifndef find_prev_zero_bit +unsigned long find_prev_zero_bit(const unsigned long *addr, unsigned long size, + unsigned long offset) +{ + return _find_prev_bit(addr, NULL, size, offset, ~0UL, 0); +} +EXPORT_SYMBOL(find_prev_zero_bit); +#endif + +#ifndef find_next_and_bit unsigned long find_next_and_bit(const unsigned long *addr1, const unsigned long *addr2, unsigned long size, unsigned long offset) @@ -100,6 +173,16 @@ unsigned long find_next_and_bit(const unsigned long *addr1, EXPORT_SYMBOL(find_next_and_bit); #endif +#ifndef find_prev_and_bit +unsigned long find_prev_and_bit(const unsigned long *addr1, + const unsigned long *addr2, unsigned long size, + unsigned long offset) +{ + return _find_prev_bit(addr1, addr2, size, offset, 0UL, 0); +} +EXPORT_SYMBOL(find_prev_and_bit); +#endif + #ifndef find_first_bit /* * Find the first set bit in a memory region. @@ -141,7 +224,7 @@ unsigned long find_last_bit(const unsigned long *addr, unsigned long size) { if (size) { unsigned long val = BITMAP_LAST_WORD_MASK(size); - unsigned long idx = (size-1) / BITS_PER_LONG; + unsigned long idx = (size - 1) / BITS_PER_LONG; do { val &= addr[idx]; @@ -156,6 +239,27 @@ unsigned long find_last_bit(const unsigned long *addr, unsigned long size) EXPORT_SYMBOL(find_last_bit); #endif +#ifndef find_last_zero_bit +unsigned long find_last_zero_bit(const unsigned long *addr, unsigned long size) +{ + if (size) { + unsigned long val = BITMAP_LAST_WORD_MASK(size); + unsigned long idx = (size - 1) / BITS_PER_LONG; + + do { + val &= ~addr[idx]; + if (val) + return idx * BITS_PER_LONG + __fls(val); + + val = ~0ul; + } while (idx--); + } + + return size; +} +EXPORT_SYMBOL(find_last_zero_bit); +#endif + #ifdef __BIG_ENDIAN #ifndef find_next_zero_bit_le @@ -167,6 +271,15 @@ unsigned long find_next_zero_bit_le(const void *addr, unsigned EXPORT_SYMBOL(find_next_zero_bit_le); #endif +#ifndef find_prev_zero_bit_le +unsigned long find_prev_zero_bit_le(const void *addr, unsigned + long size, unsigned long offset) +{ + return _find_prev_bit(addr, NULL, size, offset, ~0UL, 1); +} +EXPORT_SYMBOL(find_prev_zero_bit_le); +#endif + #ifndef find_next_bit_le unsigned long find_next_bit_le(const void *addr, unsigned long size, unsigned long offset) @@ -176,6 +289,15 @@ unsigned long find_next_bit_le(const void *addr, unsigned EXPORT_SYMBOL(find_next_bit_le); #endif +#ifdef find_prev_bit_le +unsigned long find_prev_bit_le(const void *addr, unsigned + long size, unsigned long offset) +{ + return _find_prev_bit(addr, NULL, size, offset, 0UL, 1); +} +EXPORT_SYMBOL(find_prev_bit_le); +#endif + #endif /* __BIG_ENDIAN */ unsigned long find_next_clump8(unsigned long *clump, const unsigned long *addr, -- 2.29.2 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: [PATCH] lib/find_bit: Add find_prev_*_bit functions. 2020-12-02 1:10 [PATCH] lib/find_bit: Add find_prev_*_bit functions Yun Levi @ 2020-12-02 9:47 ` Andy Shevchenko 2020-12-02 10:04 ` Rasmus Villemoes 0 siblings, 1 reply; 1767+ messages in thread From: Andy Shevchenko @ 2020-12-02 9:47 UTC (permalink / raw) To: Yun Levi Cc: dushistov, arnd, akpm, gustavo, vilhelm.gray, richard.weiyang, joseph.qi, skalluru, yury.norov, jpoimboe, linux-kernel, linux-arch On Wed, Dec 02, 2020 at 10:10:09AM +0900, Yun Levi wrote: > Inspired find_next_*bit function series, add find_prev_*_bit series. > I'm not sure whether it'll be used right now But, I add these functions > for future usage. This patch has few issues: - it has more things than described (should be several patches instead) - new functionality can be split logically to couple or more pieces as well - it proposes functionality w/o user (dead code) -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH] lib/find_bit: Add find_prev_*_bit functions. 2020-12-02 9:47 ` Andy Shevchenko @ 2020-12-02 10:04 ` Rasmus Villemoes 2020-12-02 11:50 ` Yun Levi 0 siblings, 1 reply; 1767+ messages in thread From: Rasmus Villemoes @ 2020-12-02 10:04 UTC (permalink / raw) To: Andy Shevchenko, Yun Levi Cc: dushistov, arnd, akpm, gustavo, vilhelm.gray, richard.weiyang, joseph.qi, skalluru, yury.norov, jpoimboe, linux-kernel, linux-arch On 02/12/2020 10.47, Andy Shevchenko wrote: > On Wed, Dec 02, 2020 at 10:10:09AM +0900, Yun Levi wrote: >> Inspired find_next_*bit function series, add find_prev_*_bit series. >> I'm not sure whether it'll be used right now But, I add these functions >> for future usage. > > This patch has few issues: > - it has more things than described (should be several patches instead) > - new functionality can be split logically to couple or more pieces as well > - it proposes functionality w/o user (dead code) Yeah, the last point means it can't be applied - please submit it again if and when you have an actual use case. And I'll add - it lacks extension of the bitmap test module to cover the new functions (that also wants to be a separate patch). Rasmus ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH] lib/find_bit: Add find_prev_*_bit functions. 2020-12-02 10:04 ` Rasmus Villemoes @ 2020-12-02 11:50 ` Yun Levi [not found] ` <CAAH8bW-jUeFVU-0OrJzK-MuGgKJgZv38RZugEQzFRJHSXFRRDA@mail.gmail.com> 0 siblings, 1 reply; 1767+ messages in thread From: Yun Levi @ 2020-12-02 11:50 UTC (permalink / raw) To: Rasmus Villemoes Cc: Andy Shevchenko, dushistov, arnd, akpm, gustavo, vilhelm.gray, richard.weiyang, joseph.qi, skalluru, yury.norov, jpoimboe, linux-kernel, linux-arch Thanks for kind advice. But I'm so afraid to have questions below: > - it proposes functionality w/o user (dead code) Actually, I add these series functions to rewrite some of the resource clean-up routine. A typical case is ethtool_set_per_queue_coalesce 's rollback label. Could this usage be an actual use case? >- it lacks extension of the bitmap test module to cover the new > functions (that also wants to be a separate patch). I see, then Could I add some of testcase on lib/test_bitops.c for testing? On Wed, Dec 2, 2020 at 7:04 PM Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote: > > On 02/12/2020 10.47, Andy Shevchenko wrote: > > On Wed, Dec 02, 2020 at 10:10:09AM +0900, Yun Levi wrote: > >> Inspired find_next_*bit function series, add find_prev_*_bit series. > >> I'm not sure whether it'll be used right now But, I add these functions > >> for future usage. > > > > This patch has few issues: > > - it has more things than described (should be several patches instead) > > - new functionality can be split logically to couple or more pieces as well > > - it proposes functionality w/o user (dead code) > > Yeah, the last point means it can't be applied - please submit it again > if and when you have an actual use case. And I'll add > > - it lacks extension of the bitmap test module to cover the new > functions (that also wants to be a separate patch). > > Rasmus ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <CAAH8bW-jUeFVU-0OrJzK-MuGgKJgZv38RZugEQzFRJHSXFRRDA@mail.gmail.com>]
* (no subject) [not found] ` <CAAH8bW-jUeFVU-0OrJzK-MuGgKJgZv38RZugEQzFRJHSXFRRDA@mail.gmail.com> @ 2020-12-02 18:22 ` Yun Levi 2020-12-02 21:26 ` Yury Norov 0 siblings, 1 reply; 1767+ messages in thread From: Yun Levi @ 2020-12-02 18:22 UTC (permalink / raw) To: Yury Norov Cc: Rasmus Villemoes, dushistov, Arnd Bergmann, Andrew Morton, Gustavo A. R. Silva, William Breathitt Gray, richard.weiyang, joseph.qi, skalluru, Josh Poimboeuf, Linux Kernel Mailing List, linux-arch, Andy Shevchenko On Thu, Dec 3, 2020 at 2:26 AM Yury Norov <yury.norov@gmail.com> wrote: > Also look at lib/find_bit_benchmark.c Thanks. I'll see. > We need find_next_*_bit() because find_first_*_bit() can start searching only at word-aligned > bits. In the case of find_last_*_bit(), we can start at any bit. So, if my understanding is correct, > for the purpose of reverse traversing we can go with already existing find_last_bit(), Thank you. I haven't thought that way. But I think if we implement reverse traversing using find_last_bit(), we have a problem. Suppose the last bit 0, 1, 2, is set. If we start find_last_bit(bitmap, 3) ==> return 2; find_last_bit(bitmap, 2) ==> return 1; find_last_bit(bitmap, 1) ==> return 0; find_last_bit(bitmap, 0) ===> return 0? // here we couldn't distinguish size 0 input or 0 is set and the for_each traverse routine prevent above case by returning size (nbits) using find_next_bit. So, for compatibility and the same expected return value like next traversing, I think we need to find_prev_*_bit routine. if my understanding is correct. > I think this patch has some good catches. We definitely need to implement > find_last_zero_bit(), as it is used by fs/ufs, and their local implementation is not optimal. > > We also should consider adding reverse traversing macros based on find_last_*_bit(), > if there are proposed users. Not only this, I think 'steal_from_bitmap_to_front' can be improved using ffind_prev_zero_bit like diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c index af0013d3df63..9debb9707390 100644 --- a/fs/btrfs/free-space-cache.c +++ b/fs/btrfs/free-space-cache.c @@ -2372,7 +2372,6 @@ static bool steal_from_bitmap_to_front(struct btrfs_free_space_ctl *ctl, u64 bitmap_offset; unsigned long i; unsigned long j; - unsigned long prev_j; u64 bytes; bitmap_offset = offset_to_bitmap(ctl, info->offset); @@ -2388,20 +2387,15 @@ static bool steal_from_bitmap_to_front(struct btrfs_free_space_ctl *ctl, return false; i = offset_to_bit(bitmap->offset, ctl->unit, info->offset) - 1; - j = 0; - prev_j = (unsigned long)-1; - for_each_clear_bit_from(j, bitmap->bitmap, BITS_PER_BITMAP) { - if (j > i) - break; - prev_j = j; - } - if (prev_j == i) + j = find_prev_zero_bit(bitmap->bitmap, BITS_PER_BITMAP, i); + + if (j == i) return false; - if (prev_j == (unsigned long)-1) + if (j == BITS_PER_BITMAP) bytes = (i + 1) * ctl->unit; else - bytes = (i - prev_j) * ctl->unit; + bytes = (i - j) * ctl->unit; info->offset -= bytes; info->bytes += bytes; Thanks. HTH Levi. ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2020-12-02 18:22 ` Yun Levi @ 2020-12-02 21:26 ` Yury Norov 2020-12-02 22:51 ` Yun Levi 0 siblings, 1 reply; 1767+ messages in thread From: Yury Norov @ 2020-12-02 21:26 UTC (permalink / raw) To: Yun Levi Cc: Rasmus Villemoes, dushistov, Arnd Bergmann, Andrew Morton, Gustavo A. R. Silva, William Breathitt Gray, richard.weiyang, joseph.qi, skalluru, Josh Poimboeuf, Linux Kernel Mailing List, linux-arch, Andy Shevchenko On Wed, Dec 2, 2020 at 10:22 AM Yun Levi <ppbuk5246@gmail.com> wrote: > > On Thu, Dec 3, 2020 at 2:26 AM Yury Norov <yury.norov@gmail.com> wrote: > > > Also look at lib/find_bit_benchmark.c > Thanks. I'll see. > > > We need find_next_*_bit() because find_first_*_bit() can start searching only at word-aligned > > bits. In the case of find_last_*_bit(), we can start at any bit. So, if my understanding is correct, > > for the purpose of reverse traversing we can go with already existing find_last_bit(), > > Thank you. I haven't thought that way. > But I think if we implement reverse traversing using find_last_bit(), > we have a problem. > Suppose the last bit 0, 1, 2, is set. > If we start > find_last_bit(bitmap, 3) ==> return 2; > find_last_bit(bitmap, 2) ==> return 1; > find_last_bit(bitmap, 1) ==> return 0; > find_last_bit(bitmap, 0) ===> return 0? // here we couldn't > distinguish size 0 input or 0 is set If you traverse backward and reach bit #0, you're done. No need to continue. > > and the for_each traverse routine prevent above case by returning size > (nbits) using find_next_bit. > So, for compatibility and the same expected return value like next traversing, > I think we need to find_prev_*_bit routine. if my understanding is correct. > > > > I think this patch has some good catches. We definitely need to implement > > find_last_zero_bit(), as it is used by fs/ufs, and their local implementation is not optimal. > > > > We also should consider adding reverse traversing macros based on find_last_*_bit(), > > if there are proposed users. > > Not only this, I think 'steal_from_bitmap_to_front' can be improved > using ffind_prev_zero_bit > like > > diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c > index af0013d3df63..9debb9707390 100644 > --- a/fs/btrfs/free-space-cache.c > +++ b/fs/btrfs/free-space-cache.c > @@ -2372,7 +2372,6 @@ static bool steal_from_bitmap_to_front(struct > btrfs_free_space_ctl *ctl, > u64 bitmap_offset; > unsigned long i; > unsigned long j; > - unsigned long prev_j; > u64 bytes; > > bitmap_offset = offset_to_bitmap(ctl, info->offset); > @@ -2388,20 +2387,15 @@ static bool steal_from_bitmap_to_front(struct > btrfs_free_space_ctl *ctl, > return false; > > i = offset_to_bit(bitmap->offset, ctl->unit, info->offset) - 1; > - j = 0; > - prev_j = (unsigned long)-1; > - for_each_clear_bit_from(j, bitmap->bitmap, BITS_PER_BITMAP) { > - if (j > i) > - break; > - prev_j = j; > - } > - if (prev_j == i) > + j = find_prev_zero_bit(bitmap->bitmap, BITS_PER_BITMAP, i); This one may be implemented with find_last_zero_bit() as well: unsigned log j = find_last_zero_bit(bitmap, BITS_PER_BITMAP); if (j <= i || j >= BITS_PER_BITMAP) return false; I believe the latter version is better because find_last_*_bit() is simpler in implementation (and partially exists), has less parameters, and therefore simpler for users, and doesn't introduce functionality duplication. The only consideration I can imagine to advocate find_prev*() is the performance advantage in the scenario when we know for sure that first N bits of bitmap are all set/clear, and we can bypass traversing that area. But again, in this case we can pass the bitmap address with the appropriate offset, and stay with find_last_*() > + > + if (j == i) > return false; > > - if (prev_j == (unsigned long)-1) > + if (j == BITS_PER_BITMAP) > bytes = (i + 1) * ctl->unit; > else > - bytes = (i - prev_j) * ctl->unit; > + bytes = (i - j) * ctl->unit; > > info->offset -= bytes; > info->bytes += bytes; > > Thanks. > > HTH > Levi. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) 2020-12-02 21:26 ` Yury Norov @ 2020-12-02 22:51 ` Yun Levi 2020-12-03 1:23 ` Yun Levi 0 siblings, 1 reply; 1767+ messages in thread From: Yun Levi @ 2020-12-02 22:51 UTC (permalink / raw) To: Yury Norov Cc: Rasmus Villemoes, dushistov, Arnd Bergmann, Andrew Morton, Gustavo A. R. Silva, William Breathitt Gray, richard.weiyang, joseph.qi, skalluru, Josh Poimboeuf, Linux Kernel Mailing List, linux-arch, Andy Shevchenko On Thu, Dec 3, 2020 at 6:26 AM Yury Norov <yury.norov@gmail.com> wrote: > > On Wed, Dec 2, 2020 at 10:22 AM Yun Levi <ppbuk5246@gmail.com> wrote: > > > > On Thu, Dec 3, 2020 at 2:26 AM Yury Norov <yury.norov@gmail.com> wrote: > > > > > Also look at lib/find_bit_benchmark.c > > Thanks. I'll see. > > > > > We need find_next_*_bit() because find_first_*_bit() can start searching only at word-aligned > > > bits. In the case of find_last_*_bit(), we can start at any bit. So, if my understanding is correct, > > > for the purpose of reverse traversing we can go with already existing find_last_bit(), > > > > Thank you. I haven't thought that way. > > But I think if we implement reverse traversing using find_last_bit(), > > we have a problem. > > Suppose the last bit 0, 1, 2, is set. > > If we start > > find_last_bit(bitmap, 3) ==> return 2; > > find_last_bit(bitmap, 2) ==> return 1; > > find_last_bit(bitmap, 1) ==> return 0; > > find_last_bit(bitmap, 0) ===> return 0? // here we couldn't > > distinguish size 0 input or 0 is set > > If you traverse backward and reach bit #0, you're done. No need to continue. I think the case when I consider the this macro like #define for_each_clear_bit_reverse(bit, addr, size) for ((bit) = find_last_zero_bit((addr), (size)) (bit) < (size); (bit) = find_prev_zero_bit((addr), (size), (bit))) If we implement the above macro only with find_last_zero_bit, I think there is no way without adding any additional variable to finish loop. But I don't want to add additional variable to sustain same format with for_each_clear_bit, That's why i decide to implement find_prev_*_bit series. I don't know it's correct thinking or biased. Am I wrong? > > > > > and the for_each traverse routine prevent above case by returning size > > (nbits) using find_next_bit. > > So, for compatibility and the same expected return value like next traversing, > > I think we need to find_prev_*_bit routine. if my understanding is correct. > > > > > > > I think this patch has some good catches. We definitely need to implement > > > find_last_zero_bit(), as it is used by fs/ufs, and their local implementation is not optimal. > > > > > > We also should consider adding reverse traversing macros based on find_last_*_bit(), > > > if there are proposed users. > > > > Not only this, I think 'steal_from_bitmap_to_front' can be improved > > using ffind_prev_zero_bit > > like > > > > diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c > > index af0013d3df63..9debb9707390 100644 > > --- a/fs/btrfs/free-space-cache.c > > +++ b/fs/btrfs/free-space-cache.c > > @@ -2372,7 +2372,6 @@ static bool steal_from_bitmap_to_front(struct > > btrfs_free_space_ctl *ctl, > > u64 bitmap_offset; > > unsigned long i; > > unsigned long j; > > - unsigned long prev_j; > > u64 bytes; > > > > bitmap_offset = offset_to_bitmap(ctl, info->offset); > > @@ -2388,20 +2387,15 @@ static bool steal_from_bitmap_to_front(struct > > btrfs_free_space_ctl *ctl, > > return false; > > > > i = offset_to_bit(bitmap->offset, ctl->unit, info->offset) - 1; > > - j = 0; > > - prev_j = (unsigned long)-1; > > - for_each_clear_bit_from(j, bitmap->bitmap, BITS_PER_BITMAP) { > > - if (j > i) > > - break; > > - prev_j = j; > > - } > > - if (prev_j == i) > > + j = find_prev_zero_bit(bitmap->bitmap, BITS_PER_BITMAP, i); > > This one may be implemented with find_last_zero_bit() as well: > > unsigned log j = find_last_zero_bit(bitmap, BITS_PER_BITMAP); > if (j <= i || j >= BITS_PER_BITMAP) > return false; > Actually, in that code, we don't need to check the bit after i. Originally, if my understanding is correct, former code tries to find the last 0 bit before i. and if all bits are fully set before i, it use next one as i + 1 that's why i think the if condition should be if (j >= i) But above condition couldn't the discern the case when all bits are fully set before i. Also, I think we don't need to check the bit after i and In this case, find_prev_zero_bit which specifies the start point is clear to show the meaning of the code. > I believe the latter version is better because find_last_*_bit() is simpler in > implementation (and partially exists), has less parameters, and therefore > simpler for users, and doesn't introduce functionality duplication. > > The only consideration I can imagine to advocate find_prev*() is the performance > advantage in the scenario when we know for sure that first N bits of > bitmap are all > set/clear, and we can bypass traversing that area. But again, in this > case we can pass the > bitmap address with the appropriate offset, and stay with find_last_*() > > > + > > + if (j == i) > > return false; > > > > - if (prev_j == (unsigned long)-1) > > + if (j == BITS_PER_BITMAP) > > bytes = (i + 1) * ctl->unit; > > else > > - bytes = (i - prev_j) * ctl->unit; > > + bytes = (i - j) * ctl->unit; > > > > info->offset -= bytes; > > info->bytes += bytes; > > > > Thanks. > > > > HTH > > Levi. Thanks but ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) 2020-12-02 22:51 ` Yun Levi @ 2020-12-03 1:23 ` Yun Levi 2020-12-03 8:33 ` Rasmus Villemoes 0 siblings, 1 reply; 1767+ messages in thread From: Yun Levi @ 2020-12-03 1:23 UTC (permalink / raw) To: Yury Norov Cc: Rasmus Villemoes, dushistov, Arnd Bergmann, Andrew Morton, Gustavo A. R. Silva, William Breathitt Gray, richard.weiyang, joseph.qi, skalluru, Josh Poimboeuf, Linux Kernel Mailing List, linux-arch, Andy Shevchenko On Thu, Dec 3, 2020 at 7:51 AM Yun Levi <ppbuk5246@gmail.com> wrote: > > On Thu, Dec 3, 2020 at 6:26 AM Yury Norov <yury.norov@gmail.com> wrote: > > > > On Wed, Dec 2, 2020 at 10:22 AM Yun Levi <ppbuk5246@gmail.com> wrote: > > > > > > On Thu, Dec 3, 2020 at 2:26 AM Yury Norov <yury.norov@gmail.com> wrote: > > > > > > > Also look at lib/find_bit_benchmark.c > > > Thanks. I'll see. > > > > > > > We need find_next_*_bit() because find_first_*_bit() can start searching only at word-aligned > > > > bits. In the case of find_last_*_bit(), we can start at any bit. So, if my understanding is correct, > > > > for the purpose of reverse traversing we can go with already existing find_last_bit(), > > > > > > Thank you. I haven't thought that way. > > > But I think if we implement reverse traversing using find_last_bit(), > > > we have a problem. > > > Suppose the last bit 0, 1, 2, is set. > > > If we start > > > find_last_bit(bitmap, 3) ==> return 2; > > > find_last_bit(bitmap, 2) ==> return 1; > > > find_last_bit(bitmap, 1) ==> return 0; > > > find_last_bit(bitmap, 0) ===> return 0? // here we couldn't > > > distinguish size 0 input or 0 is set > > > > If you traverse backward and reach bit #0, you're done. No need to continue. > I think the case when I consider the this macro like > > #define for_each_clear_bit_reverse(bit, addr, size) > for ((bit) = find_last_zero_bit((addr), (size)) > (bit) < (size); > (bit) = find_prev_zero_bit((addr), (size), (bit))) > > If we implement the above macro only with find_last_zero_bit, > I think there is no way without adding any additional variable to finish loop. > But I don't want to add additional variable to sustain same format > with for_each_clear_bit, > That's why i decide to implement find_prev_*_bit series. > > I don't know it's correct thinking or biased. Am I wrong? > > > > > > > > > and the for_each traverse routine prevent above case by returning size > > > (nbits) using find_next_bit. > > > So, for compatibility and the same expected return value like next traversing, > > > I think we need to find_prev_*_bit routine. if my understanding is correct. > > > > > > > > > > I think this patch has some good catches. We definitely need to implement > > > > find_last_zero_bit(), as it is used by fs/ufs, and their local implementation is not optimal. > > > > > > > > We also should consider adding reverse traversing macros based on find_last_*_bit(), > > > > if there are proposed users. > > > > > > Not only this, I think 'steal_from_bitmap_to_front' can be improved > > > using ffind_prev_zero_bit > > > like > > > > > > diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c > > > index af0013d3df63..9debb9707390 100644 > > > --- a/fs/btrfs/free-space-cache.c > > > +++ b/fs/btrfs/free-space-cache.c > > > @@ -2372,7 +2372,6 @@ static bool steal_from_bitmap_to_front(struct > > > btrfs_free_space_ctl *ctl, > > > u64 bitmap_offset; > > > unsigned long i; > > > unsigned long j; > > > - unsigned long prev_j; > > > u64 bytes; > > > > > > bitmap_offset = offset_to_bitmap(ctl, info->offset); > > > @@ -2388,20 +2387,15 @@ static bool steal_from_bitmap_to_front(struct > > > btrfs_free_space_ctl *ctl, > > > return false; > > > > > > i = offset_to_bit(bitmap->offset, ctl->unit, info->offset) - 1; > > > - j = 0; > > > - prev_j = (unsigned long)-1; > > > - for_each_clear_bit_from(j, bitmap->bitmap, BITS_PER_BITMAP) { > > > - if (j > i) > > > - break; > > > - prev_j = j; > > > - } > > > - if (prev_j == i) > > > + j = find_prev_zero_bit(bitmap->bitmap, BITS_PER_BITMAP, i); > > > > This one may be implemented with find_last_zero_bit() as well: > > > > unsigned log j = find_last_zero_bit(bitmap, BITS_PER_BITMAP); > > if (j <= i || j >= BITS_PER_BITMAP) > > return false; > > > Actually, in that code, we don't need to check the bit after i. > Originally, if my understanding is correct, former code tries to find > the last 0 bit before i. > and if all bits are fully set before i, it use next one as i + 1 > > that's why i think the if condition should be > if (j >= i) > > But above condition couldn't the discern the case when all bits are > fully set before i. > Also, I think we don't need to check the bit after i and In this case, > find_prev_zero_bit which > specifies the start point is clear to show the meaning of the code. > > > > I believe the latter version is better because find_last_*_bit() is simpler in > > implementation (and partially exists), has less parameters, and therefore > > simpler for users, and doesn't introduce functionality duplication. I think it's not duplication. Actually, former you teach me find_first_*_bit should be start word-aligned bit, But as find_first_*_bit declares it as "size of bitmap" not a start offset. Though the bitmap size it's word-aligned, it doesn't matter to fine first bit in the specified size of bitmap (it no, it will return just size of bitmap) Likewise, find_last_*_bit is also similar in context. Fundamentally, it's not a start offset of bitmap but I think it just size of bitmap. That's the reason why we need to find_next_*_bit to start at the specified offset. In this matter, I think it's better to have find_prev_*_bit. So, I think we can use both of these functions to be used to achieve a goal. But, each function has different concept actually that's why I don't think it's not duplication. if my understanding is wrong.. Forgive me. and let me know.. Thanks. > > > > The only consideration I can imagine to advocate find_prev*() is the performance > > advantage in the scenario when we know for sure that first N bits of > > bitmap are all > > set/clear, and we can bypass traversing that area. But again, in this > > case we can pass the > > bitmap address with the appropriate offset, and stay with find_last_*() > > > > > + > > > + if (j == i) > > > return false; > > > > > > - if (prev_j == (unsigned long)-1) > > > + if (j == BITS_PER_BITMAP) > > > bytes = (i + 1) * ctl->unit; > > > else > > > - bytes = (i - prev_j) * ctl->unit; > > > + bytes = (i - j) * ctl->unit; > > > > > > info->offset -= bytes; > > > info->bytes += bytes; > > > > > > Thanks. > > > > > > HTH > > > Levi. > > Thanks but ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-12-03 1:23 ` Yun Levi @ 2020-12-03 8:33 ` Rasmus Villemoes 2020-12-03 9:47 ` Re: Yun Levi 0 siblings, 1 reply; 1767+ messages in thread From: Rasmus Villemoes @ 2020-12-03 8:33 UTC (permalink / raw) To: Yun Levi, Yury Norov Cc: dushistov, Arnd Bergmann, Andrew Morton, Gustavo A. R. Silva, William Breathitt Gray, richard.weiyang, joseph.qi, skalluru, Josh Poimboeuf, Linux Kernel Mailing List, linux-arch, Andy Shevchenko On 03/12/2020 02.23, Yun Levi wrote: > On Thu, Dec 3, 2020 at 7:51 AM Yun Levi <ppbuk5246@gmail.com> wrote: >> >> On Thu, Dec 3, 2020 at 6:26 AM Yury Norov <yury.norov@gmail.com> wrote: >>> >>> On Wed, Dec 2, 2020 at 10:22 AM Yun Levi <ppbuk5246@gmail.com> wrote: >>>> >>>> On Thu, Dec 3, 2020 at 2:26 AM Yury Norov <yury.norov@gmail.com> wrote: >>>> >>>>> Also look at lib/find_bit_benchmark.c >>>> Thanks. I'll see. >>>> >>>>> We need find_next_*_bit() because find_first_*_bit() can start searching only at word-aligned >>>>> bits. In the case of find_last_*_bit(), we can start at any bit. So, if my understanding is correct, >>>>> for the purpose of reverse traversing we can go with already existing find_last_bit(), >>>> >>>> Thank you. I haven't thought that way. >>>> But I think if we implement reverse traversing using find_last_bit(), >>>> we have a problem. >>>> Suppose the last bit 0, 1, 2, is set. >>>> If we start >>>> find_last_bit(bitmap, 3) ==> return 2; >>>> find_last_bit(bitmap, 2) ==> return 1; >>>> find_last_bit(bitmap, 1) ==> return 0; >>>> find_last_bit(bitmap, 0) ===> return 0? // here we couldn't Either just make the return type of all find_prev/find_last be signed int and use -1 as the sentinel to indicate "no such position exists", so the loop condition would be foo >= 0. Or, change the condition from "stop if we get the size returned" to "only continue if we get something strictly less than the size we passed in (i.e., something which can possibly be a valid bit index). In the latter case, both (unsigned)-1 aka UINT_MAX and the actual size value passed work equally well as a sentinel. If one uses UINT_MAX, a for_each_bit_reverse() macro would just be something like for (i = find_last_bit(bitmap, size); i < size; i = find_last_bit(bitmap, i)) if one wants to use the size argument as the sentinel, the caller would have to supply a scratch variable to keep track of the last i value: for (j = size, i = find_last_bit(bitmap, j); i < j; j = i, i = find_last_bit(bitmap, j)) which is probably a little less ergonomic. Rasmus ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-12-03 8:33 ` Rasmus Villemoes @ 2020-12-03 9:47 ` Yun Levi 2020-12-03 18:46 ` Re: Yury Norov 0 siblings, 1 reply; 1767+ messages in thread From: Yun Levi @ 2020-12-03 9:47 UTC (permalink / raw) To: Rasmus Villemoes Cc: Yury Norov, dushistov, Arnd Bergmann, Andrew Morton, Gustavo A. R. Silva, William Breathitt Gray, richard.weiyang, joseph.qi, skalluru, Josh Poimboeuf, Linux Kernel Mailing List, linux-arch, Andy Shevchenko > If one uses UINT_MAX, a for_each_bit_reverse() macro would just be > something like > > for (i = find_last_bit(bitmap, size); i < size; i = > find_last_bit(bitmap, i)) > > if one wants to use the size argument as the sentinel, the caller would > have to supply a scratch variable to keep track of the last i value: > > for (j = size, i = find_last_bit(bitmap, j); i < j; j = i, i = > find_last_bit(bitmap, j)) > > which is probably a little less ergonomic. Actually Because I want to avoid the modification of return type of find_last_*_bit for new sentinel, I add find_prev_*_bit. the big difference between find_last_bit and find_prev_bit is find_last_bit doesn't check the size bit and use sentinel with size. but find_prev_bit check the offset bit and use sentinel with size which passed by another argument. So if we use find_prev_bit, we could have a clear iteration if using find_prev_bit like. #define for_each_set_bit_reverse(bit, addr, size) \ for ((bit) = find_last_bit((addr), (size)); \ (bit) < (size); \ (bit) = find_prev_bit((addr), (size), (bit - 1))) #define for_each_set_bit_from_reverse(bit, addr, size) \ for ((bit) = find_prev_bit((addr), (size), (bit)); \ (bit) < (size); \ (bit) = find_prev_bit((addr), (size), (bit - 1))) Though find_prev_*_bit / find_last_*_bit have the same functionality. But they also have a small difference. I think this small this small difference doesn't make some of confusion to user but it help to solve problem with a simple way (just like the iteration above). So I think I need, find_prev_*_bit series. Am I missing anything? Thanks. Levi. On Thu, Dec 3, 2020 at 5:33 PM Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote: > > On 03/12/2020 02.23, Yun Levi wrote: > > On Thu, Dec 3, 2020 at 7:51 AM Yun Levi <ppbuk5246@gmail.com> wrote: > >> > >> On Thu, Dec 3, 2020 at 6:26 AM Yury Norov <yury.norov@gmail.com> wrote: > >>> > >>> On Wed, Dec 2, 2020 at 10:22 AM Yun Levi <ppbuk5246@gmail.com> wrote: > >>>> > >>>> On Thu, Dec 3, 2020 at 2:26 AM Yury Norov <yury.norov@gmail.com> wrote: > >>>> > >>>>> Also look at lib/find_bit_benchmark.c > >>>> Thanks. I'll see. > >>>> > >>>>> We need find_next_*_bit() because find_first_*_bit() can start searching only at word-aligned > >>>>> bits. In the case of find_last_*_bit(), we can start at any bit. So, if my understanding is correct, > >>>>> for the purpose of reverse traversing we can go with already existing find_last_bit(), > >>>> > >>>> Thank you. I haven't thought that way. > >>>> But I think if we implement reverse traversing using find_last_bit(), > >>>> we have a problem. > >>>> Suppose the last bit 0, 1, 2, is set. > >>>> If we start > >>>> find_last_bit(bitmap, 3) ==> return 2; > >>>> find_last_bit(bitmap, 2) ==> return 1; > >>>> find_last_bit(bitmap, 1) ==> return 0; > >>>> find_last_bit(bitmap, 0) ===> return 0? // here we couldn't > > Either just make the return type of all find_prev/find_last be signed > int and use -1 as the sentinel to indicate "no such position exists", so > the loop condition would be foo >= 0. Or, change the condition from > "stop if we get the size returned" to "only continue if we get something > strictly less than the size we passed in (i.e., something which can > possibly be a valid bit index). In the latter case, both (unsigned)-1 > aka UINT_MAX and the actual size value passed work equally well as a > sentinel. > > If one uses UINT_MAX, a for_each_bit_reverse() macro would just be > something like > > for (i = find_last_bit(bitmap, size); i < size; i = > find_last_bit(bitmap, i)) > > if one wants to use the size argument as the sentinel, the caller would > have to supply a scratch variable to keep track of the last i value: > > for (j = size, i = find_last_bit(bitmap, j); i < j; j = i, i = > find_last_bit(bitmap, j)) > > which is probably a little less ergonomic. > > Rasmus ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-12-03 9:47 ` Re: Yun Levi @ 2020-12-03 18:46 ` Yury Norov 2020-12-03 18:52 ` Re: Willy Tarreau 2020-12-05 11:10 ` Re: Rasmus Villemoes 0 siblings, 2 replies; 1767+ messages in thread From: Yury Norov @ 2020-12-03 18:46 UTC (permalink / raw) To: Yun Levi Cc: Rasmus Villemoes, dushistov, Arnd Bergmann, Andrew Morton, Gustavo A. R. Silva, William Breathitt Gray, richard.weiyang, joseph.qi, skalluru, Josh Poimboeuf, Linux Kernel Mailing List, linux-arch, Andy Shevchenko Yun, could you please stop top-posting and excessive trimming in the thread? On Thu, Dec 3, 2020 at 1:47 AM Yun Levi <ppbuk5246@gmail.com> wrote: > > Either just make the return type of all find_prev/find_last be signed > > int and use -1 as the sentinel to indicate "no such position exists", so > > the loop condition would be foo >= 0. Or, change the condition from > > "stop if we get the size returned" to "only continue if we get something > > strictly less than the size we passed in (i.e., something which can > > possibly be a valid bit index). In the latter case, both (unsigned)-1 > > aka UINT_MAX and the actual size value passed work equally well as a > > sentinel. > > > > If one uses UINT_MAX, a for_each_bit_reverse() macro would just be > > something like > > > > for (i = find_last_bit(bitmap, size); i < size; i = > > find_last_bit(bitmap, i)) > > > > if one wants to use the size argument as the sentinel, the caller would > > have to supply a scratch variable to keep track of the last i value: > > > > for (j = size, i = find_last_bit(bitmap, j); i < j; j = i, i = > > find_last_bit(bitmap, j)) > > > > which is probably a little less ergonomic. > > > > Rasmus I would prefer to avoid changing the find*bit() semantics. As for now, if any of find_*_bit() finds nothing, it returns the size of the bitmap it was passed. Changing this for a single function would break the consistency, and may cause problems for those who rely on existing behaviour. Passing non-positive size to find_*_bit() should produce undefined behaviour, because we cannot dereference a pointer to the bitmap in this case; this is most probably a sign of a problem on a caller side anyways. Let's keep this logic unchanged? > Actually Because I want to avoid the modification of return type of > find_last_*_bit for new sentinel, > I add find_prev_*_bit. > the big difference between find_last_bit and find_prev_bit is > find_last_bit doesn't check the size bit and use sentinel with size. > but find_prev_bit check the offset bit and use sentinel with size > which passed by another argument. > So if we use find_prev_bit, we could have a clear iteration if > using find_prev_bit like. > > #define for_each_set_bit_reverse(bit, addr, size) \ > for ((bit) = find_last_bit((addr), (size)); \ > (bit) < (size); \ > (bit) = find_prev_bit((addr), (size), (bit - 1))) > > #define for_each_set_bit_from_reverse(bit, addr, size) \ > for ((bit) = find_prev_bit((addr), (size), (bit)); \ > (bit) < (size); \ > (bit) = find_prev_bit((addr), (size), (bit - 1))) > > Though find_prev_*_bit / find_last_*_bit have the same functionality. > But they also have a small difference. > I think this small this small difference doesn't make some of > confusion to user but it help to solve problem > with a simple way (just like the iteration above). > > So I think I need, find_prev_*_bit series. > > Am I missing anything? > > Thanks. > > Levi. As you said, find_last_bit() and proposed find_prev_*_bit() have the same functionality. If you really want to have find_prev_*_bit(), could you please at least write it using find_last_bit(), otherwise it would be just a blottering. Regarding reverse search, we can probably do like this (not tested, just an idea): #define for_each_set_bit_reverse(bit, addr, size) \ for ((bit) = find_last_bit((addr), (size)); \ (bit) < (size); \ (size) = (bit), (bit) = find_last_bit((addr), (bit))) Thanks, Yury ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-12-03 18:46 ` Re: Yury Norov @ 2020-12-03 18:52 ` Willy Tarreau 2020-12-04 1:36 ` Re: Yun Levi 2020-12-05 11:10 ` Re: Rasmus Villemoes 1 sibling, 1 reply; 1767+ messages in thread From: Willy Tarreau @ 2020-12-03 18:52 UTC (permalink / raw) To: Yury Norov Cc: Yun Levi, Rasmus Villemoes, dushistov, Arnd Bergmann, Andrew Morton, Gustavo A. R. Silva, William Breathitt Gray, richard.weiyang, joseph.qi, skalluru, Josh Poimboeuf, Linux Kernel Mailing List, linux-arch, Andy Shevchenko On Thu, Dec 03, 2020 at 10:46:25AM -0800, Yury Norov wrote: > Yun, could you please stop top-posting and excessive trimming in the thread? And re-configure the mail agent to make the "Subject" field appear and fill it. Willy ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-12-03 18:52 ` Re: Willy Tarreau @ 2020-12-04 1:36 ` Yun Levi 2020-12-04 18:14 ` Re: Yury Norov 0 siblings, 1 reply; 1767+ messages in thread From: Yun Levi @ 2020-12-04 1:36 UTC (permalink / raw) To: Willy Tarreau Cc: Yury Norov, Rasmus Villemoes, dushistov, Arnd Bergmann, Andrew Morton, Gustavo A. R. Silva, William Breathitt Gray, richard.weiyang, joseph.qi, skalluru, Josh Poimboeuf, Linux Kernel Mailing List, linux-arch, Andy Shevchenko >On Fri, Dec 4, 2020 at 3:53 AM Willy Tarreau <w@1wt.eu> wrote: > > On Thu, Dec 03, 2020 at 10:46:25AM -0800, Yury Norov wrote: > > Yun, could you please stop top-posting and excessive trimming in the thread? > > And re-configure the mail agent to make the "Subject" field appear and > fill it. >On Thu, Dec 03, 2020 at 10:46:25AM -0800, Yury Norov wrote: > Yun, could you please stop top-posting and excessive trimming in the thread? Sorry to make you uncomfortable... Thanks for advice. >On Thu, Dec 03, 2020 at 10:46:25AM -0800, Yury Norov wrote: > As you said, find_last_bit() and proposed find_prev_*_bit() have the > same functionality. > If you really want to have find_prev_*_bit(), could you please at > least write it using find_last_bit(), otherwise it would be just a > blottering. Actually find_prev_*_bit call _find_prev_bit which is a common helper function like _find_next_bit. As you know this function is required to support __BIGEDIAN's little endian search. find_prev_bit actually wrapper of _find_prev_bit which have a feature the find_last_bit. That makes the semantics difference between find_last_bit and find_prev_bit. -- specify where you find from and In loop, find_last_bit couldn't sustain original size as sentinel return value (we should change the size argument for next searching But it means whenever we call, "NOT SET or NOT CLEAR"'s sentinel return value is changed per call). Because we should have _find_prev_bit, I think it's the matter to choose which is better to usein find_prev_bit (find_last_bit? or _find_prev_bit?) sustaining find_prev_bit feature (give size as sentinel return, from where I start). if my understanding is correct. In my view, I prefer to use _find_prev_bit like find_next_bit for integrated format. But In some of the benchmarking, find_last_bit is better than _find_prev_bit, here what I tested (look similar but sometimes have some difference). Start testing find_bit() with random-filled bitmap [ +0.001850] find_next_bit: 842792 ns, 163788 iterations [ +0.000873] find_prev_bit: 870914 ns, 163788 iterations [ +0.000824] find_next_zero_bit: 821959 ns, 163894 iterations [ +0.000677] find_prev_zero_bit: 676240 ns, 163894 iterations [ +0.000777] find_last_bit: 659103 ns, 163788 iterations [ +0.001822] find_first_bit: 1708041 ns, 16250 iterations [ +0.000539] find_next_and_bit: 492182 ns, 73871 iterations [ +0.000001] Start testing find_bit() with sparse bitmap [ +0.000222] find_next_bit: 13227 ns, 654 iterations [ +0.000013] find_prev_bit: 11652 ns, 654 iterations [ +0.001845] find_next_zero_bit: 1723869 ns, 327028 iterations [ +0.001538] find_prev_zero_bit: 1355808 ns, 327028 iterations [ +0.000010] find_last_bit: 8114 ns, 654 iterations [ +0.000867] find_first_bit: 710639 ns, 654 iterations [ +0.000006] find_next_and_bit: 4273 ns, 1 iterations [ +0.000004] find_next_and_bit: 3278 ns, 1 iterations Start testing find_bit() with random-filled bitmap [ +0.001784] find_next_bit: 805553 ns, 164240 iterations [ +0.000643] find_prev_bit: 632474 ns, 164240 iterations [ +0.000950] find_next_zero_bit: 877215 ns, 163442 iterations [ +0.000664] find_prev_zero_bit: 662339 ns, 163442 iterations [ +0.000680] find_last_bit: 602204 ns, 164240 iterations [ +0.001912] find_first_bit: 1758208 ns, 16408 iterations [ +0.000760] find_next_and_bit: 531033 ns, 73798 iterations [ +0.000002] Start testing find_bit() with sparse bitmap [ +0.000203] find_next_bit: 12468 ns, 656 iterations [ +0.000205] find_prev_bit: 10948 ns, 656 iterations [ +0.001759] find_next_zero_bit: 1579447 ns, 327026 iterations [ +0.001935] find_prev_zero_bit: 1931961 ns, 327026 iterations [ +0.000013] find_last_bit: 9543 ns, 656 iterations [ +0.000732] find_first_bit: 562009 ns, 656 iterations [ +0.000217] find_next_and_bit: 6804 ns, 1 iterations [ +0.000007] find_next_and_bit: 4367 ns, 1 iterations Is it better to write find_prev_bit using find_last_bit? I question again. Thanks for your great advice, But please forgive my fault and lackness. HTH. Levi. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-12-04 1:36 ` Re: Yun Levi @ 2020-12-04 18:14 ` Yury Norov 2020-12-05 0:45 ` Re: Yun Levi 0 siblings, 1 reply; 1767+ messages in thread From: Yury Norov @ 2020-12-04 18:14 UTC (permalink / raw) To: Yun Levi Cc: Willy Tarreau, Rasmus Villemoes, dushistov, Arnd Bergmann, Andrew Morton, Gustavo A. R. Silva, William Breathitt Gray, richard.weiyang, joseph.qi, skalluru, Josh Poimboeuf, Linux Kernel Mailing List, linux-arch, Andy Shevchenko On Thu, Dec 3, 2020 at 5:36 PM Yun Levi <ppbuk5246@gmail.com> wrote: > > >On Fri, Dec 4, 2020 at 3:53 AM Willy Tarreau <w@1wt.eu> wrote: > > > > On Thu, Dec 03, 2020 at 10:46:25AM -0800, Yury Norov wrote: > > > Yun, could you please stop top-posting and excessive trimming in the thread? > > > > And re-configure the mail agent to make the "Subject" field appear and > > fill it. > > >On Thu, Dec 03, 2020 at 10:46:25AM -0800, Yury Norov wrote: > > Yun, could you please stop top-posting and excessive trimming in the thread? > Sorry to make you uncomfortable... Thanks for advice. > > >On Thu, Dec 03, 2020 at 10:46:25AM -0800, Yury Norov wrote: > > As you said, find_last_bit() and proposed find_prev_*_bit() have the > > same functionality. > > If you really want to have find_prev_*_bit(), could you please at > > least write it using find_last_bit(), otherwise it would be just a > > blottering. > > Actually find_prev_*_bit call _find_prev_bit which is a common helper function > like _find_next_bit. > As you know this function is required to support __BIGEDIAN's little > endian search. > find_prev_bit actually wrapper of _find_prev_bit which have a feature > the find_last_bit. > > That makes the semantics difference between find_last_bit and find_prev_bit. > -- specify where you find from and > In loop, find_last_bit couldn't sustain original size as sentinel > return value > (we should change the size argument for next searching > But it means whenever we call, "NOT SET or NOT CLEAR"'s sentinel > return value is changed per call). > > Because we should have _find_prev_bit, > I think it's the matter to choose which is better to usein > find_prev_bit (find_last_bit? or _find_prev_bit?) > sustaining find_prev_bit feature (give size as sentinel return, from > where I start). > if my understanding is correct. > > In my view, I prefer to use _find_prev_bit like find_next_bit for > integrated format. > > But In some of the benchmarking, find_last_bit is better than _find_prev_bit, > here what I tested (look similar but sometimes have some difference). > > Start testing find_bit() with random-filled bitmap > [ +0.001850] find_next_bit: 842792 ns, 163788 iterations > [ +0.000873] find_prev_bit: 870914 ns, 163788 iterations > [ +0.000824] find_next_zero_bit: 821959 ns, 163894 iterations > [ +0.000677] find_prev_zero_bit: 676240 ns, 163894 iterations > [ +0.000777] find_last_bit: 659103 ns, 163788 iterations > [ +0.001822] find_first_bit: 1708041 ns, 16250 iterations > [ +0.000539] find_next_and_bit: 492182 ns, 73871 iterations > [ +0.000001] > Start testing find_bit() with sparse bitmap > [ +0.000222] find_next_bit: 13227 ns, 654 iterations > [ +0.000013] find_prev_bit: 11652 ns, 654 iterations > [ +0.001845] find_next_zero_bit: 1723869 ns, 327028 iterations > [ +0.001538] find_prev_zero_bit: 1355808 ns, 327028 iterations > [ +0.000010] find_last_bit: 8114 ns, 654 iterations > [ +0.000867] find_first_bit: 710639 ns, 654 iterations > [ +0.000006] find_next_and_bit: 4273 ns, 1 iterations > [ +0.000004] find_next_and_bit: 3278 ns, 1 iterations > > Start testing find_bit() with random-filled bitmap > [ +0.001784] find_next_bit: 805553 ns, 164240 iterations > [ +0.000643] find_prev_bit: 632474 ns, 164240 iterations > [ +0.000950] find_next_zero_bit: 877215 ns, 163442 iterations > [ +0.000664] find_prev_zero_bit: 662339 ns, 163442 iterations > [ +0.000680] find_last_bit: 602204 ns, 164240 iterations > [ +0.001912] find_first_bit: 1758208 ns, 16408 iterations > [ +0.000760] find_next_and_bit: 531033 ns, 73798 iterations > [ +0.000002] > Start testing find_bit() with sparse bitmap > [ +0.000203] find_next_bit: 12468 ns, 656 iterations > [ +0.000205] find_prev_bit: 10948 ns, 656 iterations > [ +0.001759] find_next_zero_bit: 1579447 ns, 327026 iterations > [ +0.001935] find_prev_zero_bit: 1931961 ns, 327026 iterations > [ +0.000013] find_last_bit: 9543 ns, 656 iterations > [ +0.000732] find_first_bit: 562009 ns, 656 iterations > [ +0.000217] find_next_and_bit: 6804 ns, 1 iterations > [ +0.000007] find_next_and_bit: 4367 ns, 1 iterations > > Is it better to write find_prev_bit using find_last_bit? > I question again. I answer again. It's better not to write find_prev_bit at all and learn how to use existing functionality. Yury > Thanks for your great advice, But please forgive my fault and lackness. > > HTH. > Levi. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-12-04 18:14 ` Re: Yury Norov @ 2020-12-05 0:45 ` Yun Levi 0 siblings, 0 replies; 1767+ messages in thread From: Yun Levi @ 2020-12-05 0:45 UTC (permalink / raw) To: Yury Norov Cc: Willy Tarreau, Rasmus Villemoes, dushistov, Arnd Bergmann, Andrew Morton, Gustavo A. R. Silva, William Breathitt Gray, richard.weiyang, joseph.qi, skalluru, Josh Poimboeuf, Linux Kernel Mailing List, linux-arch, Andy Shevchenko > I answer again. It's better not to write find_prev_bit at all and > learn how to use existing functionality. Thanks for the answer I'll fix and send the patch again :) On Sat, Dec 5, 2020 at 3:14 AM Yury Norov <yury.norov@gmail.com> wrote: > > On Thu, Dec 3, 2020 at 5:36 PM Yun Levi <ppbuk5246@gmail.com> wrote: > > > > >On Fri, Dec 4, 2020 at 3:53 AM Willy Tarreau <w@1wt.eu> wrote: > > > > > > On Thu, Dec 03, 2020 at 10:46:25AM -0800, Yury Norov wrote: > > > > Yun, could you please stop top-posting and excessive trimming in the thread? > > > > > > And re-configure the mail agent to make the "Subject" field appear and > > > fill it. > > > > >On Thu, Dec 03, 2020 at 10:46:25AM -0800, Yury Norov wrote: > > > Yun, could you please stop top-posting and excessive trimming in the thread? > > Sorry to make you uncomfortable... Thanks for advice. > > > > >On Thu, Dec 03, 2020 at 10:46:25AM -0800, Yury Norov wrote: > > > As you said, find_last_bit() and proposed find_prev_*_bit() have the > > > same functionality. > > > If you really want to have find_prev_*_bit(), could you please at > > > least write it using find_last_bit(), otherwise it would be just a > > > blottering. > > > > Actually find_prev_*_bit call _find_prev_bit which is a common helper function > > like _find_next_bit. > > As you know this function is required to support __BIGEDIAN's little > > endian search. > > find_prev_bit actually wrapper of _find_prev_bit which have a feature > > the find_last_bit. > > > > That makes the semantics difference between find_last_bit and find_prev_bit. > > -- specify where you find from and > > In loop, find_last_bit couldn't sustain original size as sentinel > > return value > > (we should change the size argument for next searching > > But it means whenever we call, "NOT SET or NOT CLEAR"'s sentinel > > return value is changed per call). > > > > Because we should have _find_prev_bit, > > I think it's the matter to choose which is better to usein > > find_prev_bit (find_last_bit? or _find_prev_bit?) > > sustaining find_prev_bit feature (give size as sentinel return, from > > where I start). > > if my understanding is correct. > > > > In my view, I prefer to use _find_prev_bit like find_next_bit for > > integrated format. > > > > But In some of the benchmarking, find_last_bit is better than _find_prev_bit, > > here what I tested (look similar but sometimes have some difference). > > > > Start testing find_bit() with random-filled bitmap > > [ +0.001850] find_next_bit: 842792 ns, 163788 iterations > > [ +0.000873] find_prev_bit: 870914 ns, 163788 iterations > > [ +0.000824] find_next_zero_bit: 821959 ns, 163894 iterations > > [ +0.000677] find_prev_zero_bit: 676240 ns, 163894 iterations > > [ +0.000777] find_last_bit: 659103 ns, 163788 iterations > > [ +0.001822] find_first_bit: 1708041 ns, 16250 iterations > > [ +0.000539] find_next_and_bit: 492182 ns, 73871 iterations > > [ +0.000001] > > Start testing find_bit() with sparse bitmap > > [ +0.000222] find_next_bit: 13227 ns, 654 iterations > > [ +0.000013] find_prev_bit: 11652 ns, 654 iterations > > [ +0.001845] find_next_zero_bit: 1723869 ns, 327028 iterations > > [ +0.001538] find_prev_zero_bit: 1355808 ns, 327028 iterations > > [ +0.000010] find_last_bit: 8114 ns, 654 iterations > > [ +0.000867] find_first_bit: 710639 ns, 654 iterations > > [ +0.000006] find_next_and_bit: 4273 ns, 1 iterations > > [ +0.000004] find_next_and_bit: 3278 ns, 1 iterations > > > > Start testing find_bit() with random-filled bitmap > > [ +0.001784] find_next_bit: 805553 ns, 164240 iterations > > [ +0.000643] find_prev_bit: 632474 ns, 164240 iterations > > [ +0.000950] find_next_zero_bit: 877215 ns, 163442 iterations > > [ +0.000664] find_prev_zero_bit: 662339 ns, 163442 iterations > > [ +0.000680] find_last_bit: 602204 ns, 164240 iterations > > [ +0.001912] find_first_bit: 1758208 ns, 16408 iterations > > [ +0.000760] find_next_and_bit: 531033 ns, 73798 iterations > > [ +0.000002] > > Start testing find_bit() with sparse bitmap > > [ +0.000203] find_next_bit: 12468 ns, 656 iterations > > [ +0.000205] find_prev_bit: 10948 ns, 656 iterations > > [ +0.001759] find_next_zero_bit: 1579447 ns, 327026 iterations > > [ +0.001935] find_prev_zero_bit: 1931961 ns, 327026 iterations > > [ +0.000013] find_last_bit: 9543 ns, 656 iterations > > [ +0.000732] find_first_bit: 562009 ns, 656 iterations > > [ +0.000217] find_next_and_bit: 6804 ns, 1 iterations > > [ +0.000007] find_next_and_bit: 4367 ns, 1 iterations > > > > Is it better to write find_prev_bit using find_last_bit? > > I question again. > > I answer again. It's better not to write find_prev_bit at all and > learn how to use existing functionality. > > Yury > > > Thanks for your great advice, But please forgive my fault and lackness. > > > > HTH. > > Levi. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-12-03 18:46 ` Re: Yury Norov 2020-12-03 18:52 ` Re: Willy Tarreau @ 2020-12-05 11:10 ` Rasmus Villemoes 2020-12-05 18:20 ` Re: Yury Norov 1 sibling, 1 reply; 1767+ messages in thread From: Rasmus Villemoes @ 2020-12-05 11:10 UTC (permalink / raw) To: Yury Norov, Yun Levi Cc: dushistov, Arnd Bergmann, Andrew Morton, Gustavo A. R. Silva, William Breathitt Gray, richard.weiyang, joseph.qi, skalluru, Josh Poimboeuf, Linux Kernel Mailing List, linux-arch, Andy Shevchenko On 03/12/2020 19.46, Yury Norov wrote: > I would prefer to avoid changing the find*bit() semantics. As for now, > if any of find_*_bit() > finds nothing, it returns the size of the bitmap it was passed. Yeah, we should actually try to fix that, it causes bad code generation. It's hard, because callers of course do that "if ret == size" check. But it's really silly that something like find_first_bit needs to do that "min(i*BPL + __ffs(word), size)" - the caller does a comparison anyway, that comparison might as well be "ret >= size" rather than "ret == size", and then we could get rid of that branch (which min() necessarily becomes) at the end of find_next_bit. I haven't dug very deep into this, but I could also imagine the arch-specific parts of this might become a little easier to do if the semantics were just "if no such bit, return an indeterminate value >= the size". > Changing this for > a single function would break the consistency, and may cause problems > for those who > rely on existing behaviour. True. But I think it should be possible - I suppose most users are via the iterator macros, which could all be updated at once. Changing ret == size to ret >= size will still work even if the implementations have not been switched over, so it should be doable. > > Passing non-positive size to find_*_bit() should produce undefined > behaviour, because we cannot dereference a pointer to the bitmap in > this case; this is most probably a sign of a problem on a caller side > anyways. No, the out-of-line bitmap functions should all handle the case of a zero-size bitmap sensibly. Is bitmap full? Yes (all the 0 bits are set). Is bitmap empty? Yes, (none of the 0 bits are set). Find the first bit set (returns 0, there's no such bit) Etc. The static inlines for small_const_nbits do assume that the pointer can be dereferenced, which is why small_const_nbits was updated to mean 1<=bits<=BITS_PER_LONG rather than just bits<=BITS_PER_LONG. Rasmus ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-12-05 11:10 ` Re: Rasmus Villemoes @ 2020-12-05 18:20 ` Yury Norov 0 siblings, 0 replies; 1767+ messages in thread From: Yury Norov @ 2020-12-05 18:20 UTC (permalink / raw) To: Rasmus Villemoes Cc: Yun Levi, dushistov, Arnd Bergmann, Andrew Morton, Gustavo A. R. Silva, William Breathitt Gray, richard.weiyang, joseph.qi, skalluru, Josh Poimboeuf, Linux Kernel Mailing List, linux-arch, Andy Shevchenko On Sat, Dec 5, 2020 at 3:10 AM Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote: > > On 03/12/2020 19.46, Yury Norov wrote: > > > I would prefer to avoid changing the find*bit() semantics. As for now, > > if any of find_*_bit() > > finds nothing, it returns the size of the bitmap it was passed. > > Yeah, we should actually try to fix that, it causes bad code generation. > It's hard, because callers of course do that "if ret == size" check. But > it's really silly that something like find_first_bit needs to do that > "min(i*BPL + __ffs(word), size)" - the caller does a comparison anyway, > that comparison might as well be "ret >= size" rather than "ret == > size", and then we could get rid of that branch (which min() necessarily > becomes) at the end of find_next_bit. We didn't do that 5 years ago because it's too invasive and the improvement is barely measurable, the difference is 2 instructions (on arm64).e. Has something changed since that? 20000000000000000 <find_first_bit_better>: 0: aa0003e3 mov x3, x0 4: aa0103e0 mov x0, x1 8: b4000181 cbz x1, 38 <find_first_bit_better+0x38> c: f9400064 ldr x4, [x3] 10: d2800802 mov x2, #0x40 // #64 14: 91002063 add x3, x3, #0x8 18: b40000c4 cbz x4, 30 <find_first_bit_better+0x30> 1c: 14000008 b 3c <find_first_bit_better+0x3c> 20: f8408464 ldr x4, [x3], #8 24: 91010045 add x5, x2, #0x40 28: b50000c4 cbnz x4, 40 <find_first_bit_better+0x40> 2c: aa0503e2 mov x2, x5 30: eb00005f cmp x2, x0 34: 54ffff63 b.cc 20 <find_first_bit_better+0x20> // b.lo, b.ul, b.last 38: d65f03c0 ret 3c: d2800002 mov x2, #0x0 // #0 40: dac00084 rbit x4, x4 44: dac01084 clz x4, x4 48: 8b020080 add x0, x4, x2 4c: d65f03c0 ret 0000000000000050 <find_first_bit_worse>: 50: aa0003e4 mov x4, x0 54: aa0103e0 mov x0, x1 58: b4000181 cbz x1, 88 <find_first_bit_worse+0x38> 5c: f9400083 ldr x3, [x4] 60: d2800802 mov x2, #0x40 // #64 64: 91002084 add x4, x4, #0x8 68: b40000c3 cbz x3, 80 <find_first_bit_worse+0x30> 6c: 14000008 b 8c <find_first_bit_worse+0x3c> 70: f8408483 ldr x3, [x4], #8 74: 91010045 add x5, x2, #0x40 78: b50000c3 cbnz x3, 90 <find_first_bit_worse+0x40> 7c: aa0503e2 mov x2, x5 80: eb02001f cmp x0, x2 84: 54ffff68 b.hi 70 <find_first_bit_worse+0x20> // b.pmore 88: d65f03c0 ret 8c: d2800002 mov x2, #0x0 // #0 90: dac00063 rbit x3, x3 94: dac01063 clz x3, x3 98: 8b020062 add x2, x3, x2 9c: eb02001f cmp x0, x2 a0: 9a829000 csel x0, x0, x2, ls // ls = plast a4: d65f03c0 ret > I haven't dug very deep into this, but I could also imagine the > arch-specific parts of this might become a little easier to do if the > semantics were just "if no such bit, return an indeterminate value >= > the size". > > > Changing this for > > a single function would break the consistency, and may cause problems > > for those who > > rely on existing behaviour. > > True. But I think it should be possible - I suppose most users are via > the iterator macros, which could all be updated at once. Changing ret == > size to ret >= size will still work even if the implementations have not > been switched over, so it should be doable. Since there's no assembler users for it, we can do just: #define find_first_bit(bitmap, size) min(better_find_first_bit((bitmap), (size)), (size)) ... and deprecate find_first_bit. > > Passing non-positive size to find_*_bit() should produce undefined > > behaviour, because we cannot dereference a pointer to the bitmap in > > this case; this is most probably a sign of a problem on a caller side > > anyways. > > No, the out-of-line bitmap functions should all handle the case of a > zero-size bitmap sensibly. I could be more specific, the behaviour is defined: don't dereference the address and return undefined value (which now is always 0). > Is bitmap full? Yes (all the 0 bits are set). > Is bitmap empty? Yes, (none of the 0 bits are set). > Find the first bit set (returns 0, there's no such bit) I can't answer because this object is not a map of bits - there's no room for bits inside. > Etc. The static inlines for small_const_nbits do assume that the pointer > can be dereferenced, which is why small_const_nbits was updated to mean > 1<=bits<=BITS_PER_LONG rather than just bits<=BITS_PER_LONG. I don't want to do something like if (size == 0) return -1; ... because it legitimizes this kind of usage and hides problems on callers' side. Instead, I'd add WARN_ON(size == 0), but I don't think it's so critical to bother with it. Yury > Rasmus ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2020-11-30 10:31 Oleksandr Tyshchenko
2020-11-30 16:21 ` Alex Bennée
0 siblings, 1 reply; 1767+ messages in thread
From: Oleksandr Tyshchenko @ 2020-11-30 10:31 UTC (permalink / raw)
To: xen-devel
Cc: Oleksandr Tyshchenko, Paul Durrant, Jan Beulich, Andrew Cooper,
Roger Pau Monné, Wei Liu, Julien Grall, George Dunlap,
Ian Jackson, Julien Grall, Stefano Stabellini, Tim Deegan,
Daniel De Graaf, Volodymyr Babchuk, Jun Nakajima, Kevin Tian,
Anthony PERARD, Bertrand Marquis, Wei Chen, Kaly Xin,
Artem Mygaiev, Alex Bennée
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Date: Sat, 28 Nov 2020 22:33:51 +0200
Subject: [PATCH V3 00/23] IOREQ feature (+ virtio-mmio) on Arm
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Hello all.
The purpose of this patch series is to add IOREQ/DM support to Xen on Arm.
You can find an initial discussion at [1] and RFC/V1/V2 series at [2]/[3]/[4].
Xen on Arm requires some implementation to forward guest MMIO access to a device
model in order to implement virtio-mmio backend or even mediator outside of hypervisor.
As Xen on x86 already contains required support this series tries to make it common
and introduce Arm specific bits plus some new functionality. Patch series is based on
Julien's PoC "xen/arm: Add support for Guest IO forwarding to a device emulator".
Besides splitting existing IOREQ/DM support and introducing Arm side, the series
also includes virtio-mmio related changes (last 2 patches for toolstack)
for the reviewers to be able to see how the whole picture could look like.
According to the initial discussion there are a few open questions/concerns
regarding security, performance in VirtIO solution:
1. virtio-mmio vs virtio-pci, SPI vs MSI, different use-cases require different
transport...
2. virtio backend is able to access all guest memory, some kind of protection
is needed: 'virtio-iommu in Xen' vs 'pre-shared-memory & memcpys in guest'
3. interface between toolstack and 'out-of-qemu' virtio backend, avoid using
Xenstore in virtio backend if possible.
4. a lot of 'foreing mapping' could lead to the memory exhaustion, Julien
has some idea regarding that.
Looks like all of them are valid and worth considering, but the first thing
which we need on Arm is a mechanism to forward guest IO to a device emulator,
so let's focus on it in the first place.
***
There are a lot of changes since RFC series, almost all TODOs were resolved on Arm,
Arm code was improved and hardened, common IOREQ/DM code became really arch-agnostic
(without HVM-ism), the "legacy" mechanism of mapping magic pages for the IOREQ servers
was left x86 specific, etc. But one TODO still remains which is "PIO handling" on Arm.
The "PIO handling" TODO is expected to left unaddressed for the current series.
It is not an big issue for now while Xen doesn't have support for vPCI on Arm.
On Arm64 they are only used for PCI IO Bar and we would probably want to expose
them to emulator as PIO access to make a DM completely arch-agnostic. So "PIO handling"
should be implemented when we add support for vPCI.
I left interface untouched in the following patch
"xen/dm: Introduce xendevicemodel_set_irq_level DM op"
since there is still an open discussion what interface to use/what
information to pass to the hypervisor.
There is a patch on review this series depends on:
https://patchwork.kernel.org/patch/11816689
Please note, that IOREQ feature is disabled by default on Arm within current series.
***
Patch series [5] was rebased on recent "staging branch"
(181f2c2 evtchn: double per-channel locking can't hit identical channels) and tested on
Renesas Salvator-X board + H3 ES3.0 SoC (Arm64) with virtio-mmio disk backend [6]
running in driver domain and unmodified Linux Guest running on existing
virtio-blk driver (frontend). No issues were observed. Guest domain 'reboot/destroy'
use-cases work properly. Patch series was only build-tested on x86.
Please note, build-test passed for the following modes:
1. x86: CONFIG_HVM=y / CONFIG_IOREQ_SERVER=y (default)
2. x86: #CONFIG_HVM is not set / #CONFIG_IOREQ_SERVER is not set
3. Arm64: CONFIG_HVM=y / CONFIG_IOREQ_SERVER=y
4. Arm64: CONFIG_HVM=y / #CONFIG_IOREQ_SERVER is not set (default)
5. Arm32: CONFIG_HVM=y / CONFIG_IOREQ_SERVER=y
6. Arm32: CONFIG_HVM=y / #CONFIG_IOREQ_SERVER is not set (default)
***
Any feedback/help would be highly appreciated.
[1] https://lists.xenproject.org/archives/html/xen-devel/2020-07/msg00825.html
[2] https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg00071.html
[3] https://lists.xenproject.org/archives/html/xen-devel/2020-09/msg00732.html
[4] https://lists.xenproject.org/archives/html/xen-devel/2020-10/msg01077.html
[5] https://github.com/otyshchenko1/xen/commits/ioreq_4.14_ml4
[6] https://github.com/xen-troops/virtio-disk/commits/ioreq_ml1
Julien Grall (5):
xen/dm: Make x86's DM feature common
xen/mm: Make x86's XENMEM_resource_ioreq_server handling common
arm/ioreq: Introduce arch specific bits for IOREQ/DM features
xen/dm: Introduce xendevicemodel_set_irq_level DM op
libxl: Introduce basic virtio-mmio support on Arm
Oleksandr Tyshchenko (18):
x86/ioreq: Prepare IOREQ feature for making it common
x86/ioreq: Add IOREQ_STATUS_* #define-s and update code for moving
x86/ioreq: Provide out-of-line wrapper for the handle_mmio()
xen/ioreq: Make x86's IOREQ feature common
xen/ioreq: Make x86's hvm_ioreq_needs_completion() common
xen/ioreq: Make x86's hvm_mmio_first(last)_byte() common
xen/ioreq: Make x86's hvm_ioreq_(page/vcpu/server) structs common
xen/ioreq: Move x86's ioreq_server to struct domain
xen/ioreq: Move x86's io_completion/io_req fields to struct vcpu
xen/ioreq: Remove "hvm" prefixes from involved function names
xen/ioreq: Use guest_cmpxchg64() instead of cmpxchg()
xen/arm: Stick around in leave_hypervisor_to_guest until I/O has
completed
xen/mm: Handle properly reference in set_foreign_p2m_entry() on Arm
xen/ioreq: Introduce domain_has_ioreq_server()
xen/arm: io: Abstract sign-extension
xen/ioreq: Make x86's send_invalidate_req() common
xen/arm: Add mapcache invalidation handling
[RFC] libxl: Add support for virtio-disk configuration
MAINTAINERS | 8 +-
tools/include/xendevicemodel.h | 4 +
tools/libs/devicemodel/core.c | 18 +
tools/libs/devicemodel/libxendevicemodel.map | 1 +
tools/libs/light/Makefile | 1 +
tools/libs/light/libxl_arm.c | 94 +-
tools/libs/light/libxl_create.c | 1 +
tools/libs/light/libxl_internal.h | 1 +
tools/libs/light/libxl_types.idl | 16 +
tools/libs/light/libxl_types_internal.idl | 1 +
tools/libs/light/libxl_virtio_disk.c | 109 +++
tools/xl/Makefile | 2 +-
tools/xl/xl.h | 3 +
tools/xl/xl_cmdtable.c | 15 +
tools/xl/xl_parse.c | 116 +++
tools/xl/xl_virtio_disk.c | 46 +
xen/arch/arm/Makefile | 2 +
xen/arch/arm/dm.c | 89 ++
xen/arch/arm/domain.c | 9 +
xen/arch/arm/hvm.c | 4 +
xen/arch/arm/io.c | 29 +-
xen/arch/arm/ioreq.c | 126 +++
xen/arch/arm/p2m.c | 48 +-
xen/arch/arm/traps.c | 58 +-
xen/arch/x86/Kconfig | 1 +
xen/arch/x86/hvm/dm.c | 295 +-----
xen/arch/x86/hvm/emulate.c | 80 +-
xen/arch/x86/hvm/hvm.c | 12 +-
xen/arch/x86/hvm/hypercall.c | 9 +-
xen/arch/x86/hvm/intercept.c | 5 +-
xen/arch/x86/hvm/io.c | 26 +-
xen/arch/x86/hvm/ioreq.c | 1357 ++------------------------
xen/arch/x86/hvm/stdvga.c | 10 +-
xen/arch/x86/hvm/svm/nestedsvm.c | 2 +-
xen/arch/x86/hvm/vmx/realmode.c | 6 +-
xen/arch/x86/hvm/vmx/vvmx.c | 2 +-
xen/arch/x86/mm.c | 46 +-
xen/arch/x86/mm/p2m.c | 13 +-
xen/arch/x86/mm/shadow/common.c | 2 +-
xen/common/Kconfig | 3 +
xen/common/Makefile | 2 +
xen/common/dm.c | 292 ++++++
xen/common/ioreq.c | 1307 +++++++++++++++++++++++++
xen/common/memory.c | 73 +-
xen/include/asm-arm/domain.h | 3 +
xen/include/asm-arm/hvm/ioreq.h | 139 +++
xen/include/asm-arm/mm.h | 8 -
xen/include/asm-arm/mmio.h | 1 +
xen/include/asm-arm/p2m.h | 19 +-
xen/include/asm-arm/traps.h | 24 +
xen/include/asm-x86/hvm/domain.h | 43 -
xen/include/asm-x86/hvm/emulate.h | 2 +-
xen/include/asm-x86/hvm/io.h | 17 -
xen/include/asm-x86/hvm/ioreq.h | 58 +-
xen/include/asm-x86/hvm/vcpu.h | 18 -
xen/include/asm-x86/mm.h | 4 -
xen/include/asm-x86/p2m.h | 24 +-
xen/include/public/arch-arm.h | 5 +
xen/include/public/hvm/dm_op.h | 16 +
xen/include/xen/dm.h | 44 +
xen/include/xen/ioreq.h | 146 +++
xen/include/xen/p2m-common.h | 4 +
xen/include/xen/sched.h | 32 +
xen/include/xsm/dummy.h | 4 +-
xen/include/xsm/xsm.h | 6 +-
xen/xsm/dummy.c | 2 +-
xen/xsm/flask/hooks.c | 5 +-
67 files changed, 3084 insertions(+), 1884 deletions(-)
create mode 100644 tools/libs/light/libxl_virtio_disk.c
create mode 100644 tools/xl/xl_virtio_disk.c
create mode 100644 xen/arch/arm/dm.c
create mode 100644 xen/arch/arm/ioreq.c
create mode 100644 xen/common/dm.c
create mode 100644 xen/common/ioreq.c
create mode 100644 xen/include/asm-arm/hvm/ioreq.h
create mode 100644 xen/include/xen/dm.h
create mode 100644 xen/include/xen/ioreq.h
--
2.7.4
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2020-11-30 10:31 Oleksandr Tyshchenko @ 2020-11-30 16:21 ` Alex Bennée 2020-12-29 15:32 ` Re: Roger Pau Monné 0 siblings, 1 reply; 1767+ messages in thread From: Alex Bennée @ 2020-11-30 16:21 UTC (permalink / raw) To: Oleksandr Tyshchenko Cc: xen-devel, Oleksandr Tyshchenko, Paul Durrant, Jan Beulich, Andrew Cooper, Roger Pau Monné, Wei Liu, Julien Grall, George Dunlap, Ian Jackson, Julien Grall, Stefano Stabellini, Tim Deegan, Daniel De Graaf, Volodymyr Babchuk, Jun Nakajima, Kevin Tian, Anthony PERARD, Bertrand Marquis, Wei Chen, Kaly Xin, Artem Mygaiev Oleksandr Tyshchenko <olekstysh@gmail.com> writes: > From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> > > > Date: Sat, 28 Nov 2020 22:33:51 +0200 > Subject: [PATCH V3 00/23] IOREQ feature (+ virtio-mmio) on Arm > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > Hello all. > > The purpose of this patch series is to add IOREQ/DM support to Xen on Arm. > You can find an initial discussion at [1] and RFC/V1/V2 series at [2]/[3]/[4]. > Xen on Arm requires some implementation to forward guest MMIO access to a device > model in order to implement virtio-mmio backend or even mediator outside of hypervisor. > As Xen on x86 already contains required support this series tries to make it common > and introduce Arm specific bits plus some new functionality. Patch series is based on > Julien's PoC "xen/arm: Add support for Guest IO forwarding to a device emulator". > Besides splitting existing IOREQ/DM support and introducing Arm side, the series > also includes virtio-mmio related changes (last 2 patches for toolstack) > for the reviewers to be able to see how the whole picture could look > like. Thanks for posting the latest version. > > According to the initial discussion there are a few open questions/concerns > regarding security, performance in VirtIO solution: > 1. virtio-mmio vs virtio-pci, SPI vs MSI, different use-cases require different > transport... I think I'm repeating things here I've said in various ephemeral video chats over the last few weeks but I should probably put things down on the record. I think the original intention of the virtio framers is advanced features would build on virtio-pci because you get a bunch of things "for free" - notably enumeration and MSI support. There is assumption that by the time you add these features to virtio-mmio you end up re-creating your own less well tested version of virtio-pci. I've not been terribly convinced by the argument that the guest implementation of PCI presents a sufficiently large blob of code to make the simpler MMIO desirable. My attempts to build two virtio kernels (PCI/MMIO) with otherwise the same devices wasn't terribly conclusive either way. That said virtio-mmio still has life in it because the cloudy slimmed down guests moved to using it because the enumeration of PCI is a road block to their fast boot up requirements. I'm sure they would also appreciate a MSI implementation to reduce the overhead that handling notifications currently has on trap-and-emulate. AIUI for Xen the other downside to PCI is you would have to emulate it in the hypervisor which would be additional code at the most privileged level. > 2. virtio backend is able to access all guest memory, some kind of protection > is needed: 'virtio-iommu in Xen' vs 'pre-shared-memory & memcpys in > guest' This is also an area of interest for Project Stratos and something we would like to be solved generally for all hypervisors. There is a good write up of some approaches that Jean Phillipe did on the stratos mailing list: From: Jean-Philippe Brucker <jean-philippe@linaro.org> Subject: Limited memory sharing investigation Message-ID: <20201002134336.GA2196245@myrica> I suspect there is a good argument for the simplicity of a combined virt queue but it is unlikely to be very performance orientated. > 3. interface between toolstack and 'out-of-qemu' virtio backend, avoid using > Xenstore in virtio backend if possible. I wonder how much work it would be for a rust expert to make: https://github.com/slp/vhost-user-blk handle an IOREQ signalling pathway instead of the vhost-user/eventfd pathway? That would give a good indication on how "hypervisor blind" these daemons could be made. <snip> > > Please note, build-test passed for the following modes: > 1. x86: CONFIG_HVM=y / CONFIG_IOREQ_SERVER=y (default) > 2. x86: #CONFIG_HVM is not set / #CONFIG_IOREQ_SERVER is not set > 3. Arm64: CONFIG_HVM=y / CONFIG_IOREQ_SERVER=y Forgive my relative newness to Xen, how do I convince the hypervisor to build with this on? I've tried variants of: make -j9 CROSS_COMPILE=aarch64-linux-gnu- XEN_TARGET_ARCH=arm64 menuconfig XEN_EXPERT=y [CONFIG_|XEN_|_]IOREQ_SERVER=y with no joy... > 4. Arm64: CONFIG_HVM=y / #CONFIG_IOREQ_SERVER is not set (default) > 5. Arm32: CONFIG_HVM=y / CONFIG_IOREQ_SERVER=y > 6. Arm32: CONFIG_HVM=y / #CONFIG_IOREQ_SERVER is not set (default) > > *** > > Any feedback/help would be highly appreciated. <snip> -- Alex Bennée ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-11-30 16:21 ` Alex Bennée @ 2020-12-29 15:32 ` Roger Pau Monné 0 siblings, 0 replies; 1767+ messages in thread From: Roger Pau Monné @ 2020-12-29 15:32 UTC (permalink / raw) To: Alex Bennée Cc: Oleksandr Tyshchenko, xen-devel, Oleksandr Tyshchenko, Paul Durrant, Jan Beulich, Andrew Cooper, Wei Liu, Julien Grall, George Dunlap, Ian Jackson, Julien Grall, Stefano Stabellini, Tim Deegan, Daniel De Graaf, Volodymyr Babchuk, Jun Nakajima, Kevin Tian, Anthony PERARD, Bertrand Marquis, Wei Chen, Kaly Xin, Artem Mygaiev On Mon, Nov 30, 2020 at 04:21:59PM +0000, Alex Bennée wrote: > > Oleksandr Tyshchenko <olekstysh@gmail.com> writes: > > > From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> > > > > > > Date: Sat, 28 Nov 2020 22:33:51 +0200 > > Subject: [PATCH V3 00/23] IOREQ feature (+ virtio-mmio) on Arm > > MIME-Version: 1.0 > > Content-Type: text/plain; charset=UTF-8 > > Content-Transfer-Encoding: 8bit > > > > Hello all. > > > > The purpose of this patch series is to add IOREQ/DM support to Xen on Arm. > > You can find an initial discussion at [1] and RFC/V1/V2 series at [2]/[3]/[4]. > > Xen on Arm requires some implementation to forward guest MMIO access to a device > > model in order to implement virtio-mmio backend or even mediator outside of hypervisor. > > As Xen on x86 already contains required support this series tries to make it common > > and introduce Arm specific bits plus some new functionality. Patch series is based on > > Julien's PoC "xen/arm: Add support for Guest IO forwarding to a device emulator". > > Besides splitting existing IOREQ/DM support and introducing Arm side, the series > > also includes virtio-mmio related changes (last 2 patches for toolstack) > > for the reviewers to be able to see how the whole picture could look > > like. > > Thanks for posting the latest version. > > > > > According to the initial discussion there are a few open questions/concerns > > regarding security, performance in VirtIO solution: > > 1. virtio-mmio vs virtio-pci, SPI vs MSI, different use-cases require different > > transport... > > I think I'm repeating things here I've said in various ephemeral video > chats over the last few weeks but I should probably put things down on > the record. > > I think the original intention of the virtio framers is advanced > features would build on virtio-pci because you get a bunch of things > "for free" - notably enumeration and MSI support. There is assumption > that by the time you add these features to virtio-mmio you end up > re-creating your own less well tested version of virtio-pci. I've not > been terribly convinced by the argument that the guest implementation of > PCI presents a sufficiently large blob of code to make the simpler MMIO > desirable. My attempts to build two virtio kernels (PCI/MMIO) with > otherwise the same devices wasn't terribly conclusive either way. > > That said virtio-mmio still has life in it because the cloudy slimmed > down guests moved to using it because the enumeration of PCI is a road > block to their fast boot up requirements. I'm sure they would also > appreciate a MSI implementation to reduce the overhead that handling > notifications currently has on trap-and-emulate. > > AIUI for Xen the other downside to PCI is you would have to emulate it > in the hypervisor which would be additional code at the most privileged > level. Xen already emulates (or maybe it would be better to say decodes) PCI accesses on the hypervisor and forwards them to the appropriate device model using the IOREQ interface, so that's not something new. It's not really emulating the PCI config space, but just detecting accesses and forwarding them to the device model that should handle them. You can register different emulators in user space that handle accesses to different PCI devices from a guest. Thanks, Roger. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2020-11-06 10:44 Luis Gerhorst 2020-11-06 14:34 ` Pavel Begunkov 0 siblings, 1 reply; 1767+ messages in thread From: Luis Gerhorst @ 2020-11-06 10:44 UTC (permalink / raw) To: asml.silence; +Cc: axboe, io-uring, metze, carter.li Hello Pavel, I'm from a university and am searching for a project to work on in the upcoming year. I am looking into allowing userspace to run multiple system calls interleaved with application-specific logic using a single context switch. I noticed that you, Jens Axboe, and Carter Li discussed the possibility of integrating eBPF into io_uring earlier this year [1, 2, 3]. Is there any WIP on this topic? If not I am considering to implement this. Besides the fact that AOT eBPF is only supported for priviledged processes, are there any issues you are aware of or reasons why this was not implemented yet? Best, Luis [1] https://lore.kernel.org/io-uring/67b28e66-f2f8-99a1-dfd1-14f753d11f7a@gmail.com/ [2] https://lore.kernel.org/io-uring/8b3f182c-7c4b-da41-7ec8-bb4f22429ed1@kernel.dk/ [3] https://github.com/axboe/liburing/issues/58 ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-11-06 10:44 Luis Gerhorst @ 2020-11-06 14:34 ` Pavel Begunkov 0 siblings, 0 replies; 1767+ messages in thread From: Pavel Begunkov @ 2020-11-06 14:34 UTC (permalink / raw) To: Luis Gerhorst; +Cc: axboe, io-uring, metze, carter.li On 06/11/2020 10:44, Luis Gerhorst wrote: > Hello Pavel, > > I'm from a university and am searching for a project to work on in the > upcoming year. I am looking into allowing userspace to run multiple > system calls interleaved with application-specific logic using a single > context switch. > > I noticed that you, Jens Axboe, and Carter Li discussed the possibility > of integrating eBPF into io_uring earlier this year [1, 2, 3]. Is there > any WIP on this topic? To be honest, I've finally returned to it a week ago, just because got more free time. I was implicitly patching/refactoring some bits keeping this in mind but rather very lazily. > If not I am considering to implement this. Besides the fact that AOT > eBPF is only supported for priviledged processes, are there any issues > you are aware of or reasons why this was not implemented yet? All others I was anticipating are gone by now. I'd be really great to think something out for non-privileged processes, but as you know that doesn't hold us off. > [1] https://lore.kernel.org/io-uring/67b28e66-f2f8-99a1-dfd1-14f753d11f7a@gmail.com/ > [2] https://lore.kernel.org/io-uring/8b3f182c-7c4b-da41-7ec8-bb4f22429ed1@kernel.dk/ > [3] https://github.com/axboe/liburing/issues/58 > -- Pavel Begunkov ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2020-08-12 10:54 Alex Anadi 0 siblings, 0 replies; 1767+ messages in thread From: Alex Anadi @ 2020-08-12 10:54 UTC (permalink / raw) Attention: Sir/Madam, Compliments of the season. I am Mr Alex Anadi a senior staff of Computer Telex Dept of central bank of Nigeria. I decided to contact you because of the prevailing security report reaching my office and the intense nature of polity in Nigeria. This is to inform you about the recent plan of federal government of Nigeria to send your fund to you via diplomatic immunity CASH DELIVERY SYSTEM valued at $10.6 Million United states dollars only, contact me for further details. Regards, Mr Alex Anadi. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium) @ 2020-08-05 11:02 Amit Pundir 2020-08-06 22:31 ` Konrad Dybcio 0 siblings, 1 reply; 1767+ messages in thread From: Amit Pundir @ 2020-08-05 11:02 UTC (permalink / raw) To: Andy Gross, Bjorn Andersson, Rob Herring, John Stultz, Sumit Semwal Cc: linux-arm-msm, dt, lkml On Wed, 5 Aug 2020 at 16:21, Amit Pundir <amit.pundir@linaro.org> wrote: > > Add initial dts support for Xiaomi Poco F1 (Beryllium). > > This initial support is based on upstream Dragonboard 845c > (sdm845) device. With this dts, Beryllium boots AOSP up to > ADB shell over USB-C. > > Supported functionality includes UFS, USB-C (peripheral), > microSD card and Vol+/Vol-/power keys. Bluetooth should work > too but couldn't be verified from adb command line, it is > verified when enabled from UI with few WIP display patches. > > Just like initial db845c support, initializing the SMMU is > clearing the mapping used for the splash screen framebuffer, > which causes the device to hang during boot and recovery > needs a hard power reset. This can be worked around using: > > fastboot oem select-display-panel none > > To switch ON the display back run: > > fastboot oem select-display-panel > > But this only works on Beryllium devices running bootloader > version BOOT.XF.2.0-00369-SDM845LZB-1 that shipped with > Android-9 based release. Newer bootloader version do not > support switching OFF the display panel at all. So we need > a few additional smmu patches (under review) from here to > boot to shell: > https://github.com/pundiramit/linux/commits/beryllium-mainline > > Signed-off-by: Amit Pundir <amit.pundir@linaro.org> > --- > v4: Added more downstream reserved memory regions. It probably > need more work, but for now I see adsp/cdsp/wlan remoteprocs > powering up properly. Also removed the regulator nodes not > required for the device, as suggested by Bjorn. Forgot to mention that I added couple of clocks to protected clocks in v4, which need for display to work. > v3: Added a reserved-memory region from downstream kernel to fix > a boot regression with recent dma-pool changes in v5.8-rc6. > v2: Updated machine compatible string for seemingly inevitable > future quirks. > > arch/arm64/boot/dts/qcom/Makefile | 1 + > arch/arm64/boot/dts/qcom/sdm845-beryllium.dts | 383 ++++++++++++++++++++++++++ > 2 files changed, 384 insertions(+) > create mode 100644 arch/arm64/boot/dts/qcom/sdm845-beryllium.dts > > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile > index 0f2c33d611df..3ef1b48bc0cb 100644 > --- a/arch/arm64/boot/dts/qcom/Makefile > +++ b/arch/arm64/boot/dts/qcom/Makefile > @@ -21,6 +21,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r1.dtb > dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r2.dtb > dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r3.dtb > dtb-$(CONFIG_ARCH_QCOM) += sdm845-db845c.dtb > +dtb-$(CONFIG_ARCH_QCOM) += sdm845-beryllium.dtb > dtb-$(CONFIG_ARCH_QCOM) += sdm845-mtp.dtb > dtb-$(CONFIG_ARCH_QCOM) += sdm850-lenovo-yoga-c630.dtb > dtb-$(CONFIG_ARCH_QCOM) += sm8150-mtp.dtb > diff --git a/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts > new file mode 100644 > index 000000000000..0f9f61bf9fa4 > --- /dev/null > +++ b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts > @@ -0,0 +1,383 @@ > +// SPDX-License-Identifier: GPL-2.0 > + > +/dts-v1/; > + > +#include <dt-bindings/gpio/gpio.h> > +#include <dt-bindings/pinctrl/qcom,pmic-gpio.h> > +#include <dt-bindings/regulator/qcom,rpmh-regulator.h> > +#include "sdm845.dtsi" > +#include "pm8998.dtsi" > +#include "pmi8998.dtsi" > + > +/ { > + model = "Xiaomi Technologies Inc. Beryllium"; > + compatible = "xiaomi,beryllium", "qcom,sdm845"; > + > + /* required for bootloader to select correct board */ > + qcom,board-id = <69 0>; > + qcom,msm-id = <321 0x20001>; > + > + aliases { > + hsuart0 = &uart6; > + }; > + > + gpio-keys { > + compatible = "gpio-keys"; > + autorepeat; > + > + pinctrl-names = "default"; > + pinctrl-0 = <&vol_up_pin_a>; > + > + vol-up { > + label = "Volume Up"; > + linux,code = <KEY_VOLUMEUP>; > + gpios = <&pm8998_gpio 6 GPIO_ACTIVE_LOW>; > + }; > + }; > + > + vreg_s4a_1p8: vreg-s4a-1p8 { > + compatible = "regulator-fixed"; > + regulator-name = "vreg_s4a_1p8"; > + > + regulator-min-microvolt = <1800000>; > + regulator-max-microvolt = <1800000>; > + regulator-always-on; > + }; > +}; > + > +&adsp_pas { > + status = "okay"; > + firmware-name = "qcom/sdm845/adsp.mdt"; > +}; > + > +&apps_rsc { > + pm8998-rpmh-regulators { > + compatible = "qcom,pm8998-rpmh-regulators"; > + qcom,pmic-id = "a"; > + > + vreg_l1a_0p875: ldo1 { > + regulator-min-microvolt = <880000>; > + regulator-max-microvolt = <880000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l5a_0p8: ldo5 { > + regulator-min-microvolt = <800000>; > + regulator-max-microvolt = <800000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l7a_1p8: ldo7 { > + regulator-min-microvolt = <1800000>; > + regulator-max-microvolt = <1800000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l12a_1p8: ldo12 { > + regulator-min-microvolt = <1800000>; > + regulator-max-microvolt = <1800000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l13a_2p95: ldo13 { > + regulator-min-microvolt = <1800000>; > + regulator-max-microvolt = <2960000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l17a_1p3: ldo17 { > + regulator-min-microvolt = <1304000>; > + regulator-max-microvolt = <1304000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l20a_2p95: ldo20 { > + regulator-min-microvolt = <2960000>; > + regulator-max-microvolt = <2968000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l21a_2p95: ldo21 { > + regulator-min-microvolt = <2960000>; > + regulator-max-microvolt = <2968000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l24a_3p075: ldo24 { > + regulator-min-microvolt = <3088000>; > + regulator-max-microvolt = <3088000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l25a_3p3: ldo25 { > + regulator-min-microvolt = <3300000>; > + regulator-max-microvolt = <3312000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l26a_1p2: ldo26 { > + regulator-min-microvolt = <1200000>; > + regulator-max-microvolt = <1200000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + }; > +}; > + > +&cdsp_pas { > + status = "okay"; > + firmware-name = "qcom/sdm845/cdsp.mdt"; > +}; > + > +&gcc { > + protected-clocks = <GCC_QSPI_CORE_CLK>, > + <GCC_QSPI_CORE_CLK_SRC>, > + <GCC_QSPI_CNOC_PERIPH_AHB_CLK>, > + <GCC_LPASS_Q6_AXI_CLK>, > + <GCC_LPASS_SWAY_CLK>; > +}; > + > +&gpu { > + zap-shader { > + memory-region = <&gpu_mem>; > + firmware-name = "qcom/sdm845/a630_zap.mbn"; > + }; > +}; > + > +/* Reserved memory changes from downstream */ > +/delete-node/ &adsp_mem; > +/delete-node/ &wlan_msa_mem; > +/delete-node/ &mpss_region; > +/delete-node/ &venus_mem; > +/delete-node/ &cdsp_mem; > +/delete-node/ &mba_region; > +/delete-node/ &slpi_mem; > +/delete-node/ &spss_mem; > +/delete-node/ &rmtfs_mem; > +/ { > + reserved-memory { > + // This removed_region is needed to boot the device > + // TODO: Find out the user of this reserved memory > + removed_region: memory@88f00000 { > + reg = <0 0x88f00000 0 0x1a00000>; > + no-map; > + }; > + > + adsp_mem: memory@8c500000 { > + reg = <0 0x8c500000 0 0x1e00000>; > + no-map; > + }; > + > + wlan_msa_mem: memory@8e300000 { > + reg = <0 0x8e300000 0 0x100000>; > + no-map; > + }; > + > + mpss_region: memory@8e400000 { > + reg = <0 0x8e400000 0 0x7800000>; > + no-map; > + }; > + > + venus_mem: memory@95c00000 { > + reg = <0 0x95c00000 0 0x500000>; > + no-map; > + }; > + > + cdsp_mem: memory@96100000 { > + reg = <0 0x96100000 0 0x800000>; > + no-map; > + }; > + > + mba_region: memory@96900000 { > + reg = <0 0x96900000 0 0x200000>; > + no-map; > + }; > + > + slpi_mem: memory@96b00000 { > + reg = <0 0x96b00000 0 0x1400000>; > + no-map; > + }; > + > + spss_mem: memory@97f00000 { > + reg = <0 0x97f00000 0 0x100000>; > + no-map; > + }; > + > + rmtfs_mem: memory@f6301000 { > + compatible = "qcom,rmtfs-mem"; > + reg = <0 0xf6301000 0 0x200000>; > + no-map; > + > + qcom,client-id = <1>; > + qcom,vmid = <15>; > + }; > + }; > +}; > + > +&mss_pil { > + status = "okay"; > + firmware-name = "qcom/sdm845/mba.mbn", "qcom/sdm845/modem.mdt"; > +}; > + > +&pm8998_gpio { > + vol_up_pin_a: vol-up-active { > + pins = "gpio6"; > + function = "normal"; > + input-enable; > + bias-pull-up; > + qcom,drive-strength = <PMIC_GPIO_STRENGTH_NO>; > + }; > +}; > + > +&pm8998_pon { > + resin { > + compatible = "qcom,pm8941-resin"; > + interrupts = <0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>; > + debounce = <15625>; > + bias-pull-up; > + linux,code = <KEY_VOLUMEDOWN>; > + }; > +}; > + > +&qupv3_id_0 { > + status = "okay"; > +}; > + > +&sdhc_2 { > + status = "okay"; > + > + pinctrl-names = "default"; > + pinctrl-0 = <&sdc2_default_state &sdc2_card_det_n>; > + > + vmmc-supply = <&vreg_l21a_2p95>; > + vqmmc-supply = <&vreg_l13a_2p95>; > + > + bus-width = <4>; > + cd-gpios = <&tlmm 126 GPIO_ACTIVE_HIGH>; > +}; > + > +&tlmm { > + gpio-reserved-ranges = <0 4>, <81 4>; > + > + sdc2_default_state: sdc2-default { > + clk { > + pins = "sdc2_clk"; > + bias-disable; > + > + /* > + * It seems that mmc_test reports errors if drive > + * strength is not 16 on clk, cmd, and data pins. > + */ > + drive-strength = <16>; > + }; > + > + cmd { > + pins = "sdc2_cmd"; > + bias-pull-up; > + drive-strength = <10>; > + }; > + > + data { > + pins = "sdc2_data"; > + bias-pull-up; > + drive-strength = <10>; > + }; > + }; > + > + sdc2_card_det_n: sd-card-det-n { > + pins = "gpio126"; > + function = "gpio"; > + bias-pull-up; > + }; > +}; > + > +&uart6 { > + status = "okay"; > + > + bluetooth { > + compatible = "qcom,wcn3990-bt"; > + > + vddio-supply = <&vreg_s4a_1p8>; > + vddxo-supply = <&vreg_l7a_1p8>; > + vddrf-supply = <&vreg_l17a_1p3>; > + vddch0-supply = <&vreg_l25a_3p3>; > + max-speed = <3200000>; > + }; > +}; > + > +&usb_1 { > + status = "okay"; > +}; > + > +&usb_1_dwc3 { > + dr_mode = "peripheral"; > +}; > + > +&usb_1_hsphy { > + status = "okay"; > + > + vdd-supply = <&vreg_l1a_0p875>; > + vdda-pll-supply = <&vreg_l12a_1p8>; > + vdda-phy-dpdm-supply = <&vreg_l24a_3p075>; > + > + qcom,imp-res-offset-value = <8>; > + qcom,hstx-trim-value = <QUSB2_V2_HSTX_TRIM_21_6_MA>; > + qcom,preemphasis-level = <QUSB2_V2_PREEMPHASIS_5_PERCENT>; > + qcom,preemphasis-width = <QUSB2_V2_PREEMPHASIS_WIDTH_HALF_BIT>; > +}; > + > +&usb_1_qmpphy { > + status = "okay"; > + > + vdda-phy-supply = <&vreg_l26a_1p2>; > + vdda-pll-supply = <&vreg_l1a_0p875>; > +}; > + > +&ufs_mem_hc { > + status = "okay"; > + > + reset-gpios = <&tlmm 150 GPIO_ACTIVE_LOW>; > + > + vcc-supply = <&vreg_l20a_2p95>; > + vcc-max-microamp = <800000>; > +}; > + > +&ufs_mem_phy { > + status = "okay"; > + > + vdda-phy-supply = <&vreg_l1a_0p875>; > + vdda-pll-supply = <&vreg_l26a_1p2>; > +}; > + > +&wifi { > + status = "okay"; > + > + vdd-0.8-cx-mx-supply = <&vreg_l5a_0p8>; > + vdd-1.8-xo-supply = <&vreg_l7a_1p8>; > + vdd-1.3-rfa-supply = <&vreg_l17a_1p3>; > + vdd-3.3-ch0-supply = <&vreg_l25a_3p3>; > +}; > + > +/* PINCTRL - additions to nodes defined in sdm845.dtsi */ > + > +&qup_uart6_default { > + pinmux { > + pins = "gpio45", "gpio46", "gpio47", "gpio48"; > + function = "qup6"; > + }; > + > + cts { > + pins = "gpio45"; > + bias-disable; > + }; > + > + rts-tx { > + pins = "gpio46", "gpio47"; > + drive-strength = <2>; > + bias-disable; > + }; > + > + rx { > + pins = "gpio48"; > + bias-pull-up; > + }; > +}; > -- > 2.7.4 > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) 2020-08-05 11:02 [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium) Amit Pundir @ 2020-08-06 22:31 ` Konrad Dybcio 2020-08-12 13:37 ` Amit Pundir 0 siblings, 1 reply; 1767+ messages in thread From: Konrad Dybcio @ 2020-08-06 22:31 UTC (permalink / raw) To: amit.pundir Cc: agross, bjorn.andersson, devicetree, john.stultz, linux-arm-msm, linux-kernel, robh+dt, sumit.semwal, Konrad Dybcio Subject: Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium) >// This removed_region is needed to boot the device > // TODO: Find out the user of this reserved memory > removed_region: memory@88f00000 { This region seems to belong to the Trust Zone. When Linux tries to access it, TZ bites and shuts the device down. Konrad ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-08-06 22:31 ` Konrad Dybcio @ 2020-08-12 13:37 ` Amit Pundir 0 siblings, 0 replies; 1767+ messages in thread From: Amit Pundir @ 2020-08-12 13:37 UTC (permalink / raw) To: Konrad Dybcio Cc: Andy Gross, Bjorn Andersson, dt, John Stultz, linux-arm-msm, lkml, Rob Herring, Sumit Semwal On Fri, 7 Aug 2020 at 04:02, Konrad Dybcio <konradybcio@gmail.com> wrote: > > Subject: Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium) > > >// This removed_region is needed to boot the device > > // TODO: Find out the user of this reserved memory > > removed_region: memory@88f00000 { > > This region seems to belong to the Trust Zone. When Linux tries to access it, TZ bites and shuts the device down. That is totally possible. Plus it falls right in between TZ and QSEE reserved-memory regions. However, I do not find any credible source of information which can confirm this. So I'm hesitant to update the TODO item in the above comment. > > Konrad ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2020-07-16 21:22 Mauro Rossi 2020-07-20 9:00 ` Christian König 0 siblings, 1 reply; 1767+ messages in thread From: Mauro Rossi @ 2020-07-16 21:22 UTC (permalink / raw) To: amd-gfx; +Cc: alexander.deucher, Mauro Rossi, harry.wentland The series adds SI support to AMD DC Changelog: [RFC] Preliminar Proof Of Concept, with DCE8 headers still used in dce60_resources.c [PATCH v2] Rebase on amd-staging-drm-next dated 17-Oct-2018 [PATCH v3] Add support for DCE6 specific headers, ad hoc DCE6 macros, funtions and fixes, rebase on current amd-staging-drm-next Commits [01/27]..[08/27] SI support added in various DC components [PATCH v3 01/27] drm/amdgpu: add some required DCE6 registers (v6) [PATCH v3 02/27] drm/amd/display: add asics info for SI parts [PATCH v3 03/27] drm/amd/display: dc/dce: add initial DCE6 support (v9b) [PATCH v3 04/27] drm/amd/display: dc/core: add SI/DCE6 support (v2) [PATCH v3 05/27] drm/amd/display: dc/bios: add support for DCE6 [PATCH v3 06/27] drm/amd/display: dc/gpio: add support for DCE6 (v2) [PATCH v3 07/27] drm/amd/display: dc/irq: add support for DCE6 (v4) [PATCH v3 08/27] drm/amd/display: amdgpu_dm: add SI support (v4) Commits [09/27]..[24/27] DCE6 specific code adaptions [PATCH v3 09/27] drm/amd/display: dc/clk_mgr: add support for SI parts (v2) [PATCH v3 10/27] drm/amd/display: dc/dce60: set max_cursor_size to 64 [PATCH v3 11/27] drm/amd/display: dce_audio: add DCE6 specific macros,functions [PATCH v3 12/27] drm/amd/display: dce_dmcu: add DCE6 specific macros [PATCH v3 13/27] drm/amd/display: dce_hwseq: add DCE6 specific macros,functions [PATCH v3 14/27] drm/amd/display: dce_ipp: add DCE6 specific macros,functions [PATCH v3 15/27] drm/amd/display: dce_link_encoder: add DCE6 specific macros,functions [PATCH v3 16/27] drm/amd/display: dce_mem_input: add DCE6 specific macros,functions [PATCH v3 17/27] drm/amd/display: dce_opp: add DCE6 specific macros,functions [PATCH v3 18/27] drm/amd/display: dce_transform: add DCE6 specific macros,functions [PATCH v3 19/27] drm/amdgpu: add some required DCE6 registers (v7) [PATCH v3 20/27] drm/amd/display: dce_transform: DCE6 Scaling Horizontal Filter Init [PATCH v3 21/27] drm/amd/display: dce60_hw_sequencer: add DCE6 macros,functions [PATCH v3 22/27] drm/amd/display: dce60_hw_sequencer: add DCE6 specific .cursor_lock [PATCH v3 23/27] drm/amd/display: dce60_timing_generator: add DCE6 specific functions [PATCH v3 24/27] drm/amd/display: dc/dce60: use DCE6 headers (v6) Commits [25/27]..[27/27] SI support final enablements [PATCH v3 25/27] drm/amd/display: create plane rotation property for Bonarie and later [PATCH v3 26/27] drm/amdgpu: enable DC support for SI parts (v2) [PATCH v3 27/27] drm/amd/display: enable SI support in the Kconfig (v2) Signed-off-by: Mauro Rossi <issor.oruam@gmail.com> _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-07-16 21:22 Mauro Rossi @ 2020-07-20 9:00 ` Christian König 2020-07-20 9:59 ` Re: Mauro Rossi 0 siblings, 1 reply; 1767+ messages in thread From: Christian König @ 2020-07-20 9:00 UTC (permalink / raw) To: Mauro Rossi, amd-gfx; +Cc: alexander.deucher, harry.wentland Hi Mauro, I'm not deep into the whole DC design, so just some general high level comments on the cover letter: 1. Please add a subject line to the cover letter, my spam filter thinks that this is suspicious otherwise. 2. Then you should probably note how well (badly?) is that tested. Since you noted proof of concept it might not even work. 3. How feature complete (HDMI audio?, Freesync?) is it? Apart from that it looks like a rather impressive piece of work :) Cheers, Christian. Am 16.07.20 um 23:22 schrieb Mauro Rossi: > The series adds SI support to AMD DC > > Changelog: > > [RFC] > Preliminar Proof Of Concept, with DCE8 headers still used in dce60_resources.c > > [PATCH v2] > Rebase on amd-staging-drm-next dated 17-Oct-2018 > > [PATCH v3] > Add support for DCE6 specific headers, > ad hoc DCE6 macros, funtions and fixes, > rebase on current amd-staging-drm-next > > > Commits [01/27]..[08/27] SI support added in various DC components > > [PATCH v3 01/27] drm/amdgpu: add some required DCE6 registers (v6) > [PATCH v3 02/27] drm/amd/display: add asics info for SI parts > [PATCH v3 03/27] drm/amd/display: dc/dce: add initial DCE6 support (v9b) > [PATCH v3 04/27] drm/amd/display: dc/core: add SI/DCE6 support (v2) > [PATCH v3 05/27] drm/amd/display: dc/bios: add support for DCE6 > [PATCH v3 06/27] drm/amd/display: dc/gpio: add support for DCE6 (v2) > [PATCH v3 07/27] drm/amd/display: dc/irq: add support for DCE6 (v4) > [PATCH v3 08/27] drm/amd/display: amdgpu_dm: add SI support (v4) > > Commits [09/27]..[24/27] DCE6 specific code adaptions > > [PATCH v3 09/27] drm/amd/display: dc/clk_mgr: add support for SI parts (v2) > [PATCH v3 10/27] drm/amd/display: dc/dce60: set max_cursor_size to 64 > [PATCH v3 11/27] drm/amd/display: dce_audio: add DCE6 specific macros,functions > [PATCH v3 12/27] drm/amd/display: dce_dmcu: add DCE6 specific macros > [PATCH v3 13/27] drm/amd/display: dce_hwseq: add DCE6 specific macros,functions > [PATCH v3 14/27] drm/amd/display: dce_ipp: add DCE6 specific macros,functions > [PATCH v3 15/27] drm/amd/display: dce_link_encoder: add DCE6 specific macros,functions > [PATCH v3 16/27] drm/amd/display: dce_mem_input: add DCE6 specific macros,functions > [PATCH v3 17/27] drm/amd/display: dce_opp: add DCE6 specific macros,functions > [PATCH v3 18/27] drm/amd/display: dce_transform: add DCE6 specific macros,functions > [PATCH v3 19/27] drm/amdgpu: add some required DCE6 registers (v7) > [PATCH v3 20/27] drm/amd/display: dce_transform: DCE6 Scaling Horizontal Filter Init > [PATCH v3 21/27] drm/amd/display: dce60_hw_sequencer: add DCE6 macros,functions > [PATCH v3 22/27] drm/amd/display: dce60_hw_sequencer: add DCE6 specific .cursor_lock > [PATCH v3 23/27] drm/amd/display: dce60_timing_generator: add DCE6 specific functions > [PATCH v3 24/27] drm/amd/display: dc/dce60: use DCE6 headers (v6) > > > Commits [25/27]..[27/27] SI support final enablements > > [PATCH v3 25/27] drm/amd/display: create plane rotation property for Bonarie and later > [PATCH v3 26/27] drm/amdgpu: enable DC support for SI parts (v2) > [PATCH v3 27/27] drm/amd/display: enable SI support in the Kconfig (v2) > > > Signed-off-by: Mauro Rossi <issor.oruam@gmail.com> > > _______________________________________________ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-07-20 9:00 ` Christian König @ 2020-07-20 9:59 ` Mauro Rossi 2020-07-22 2:51 ` Re: Alex Deucher 0 siblings, 1 reply; 1767+ messages in thread From: Mauro Rossi @ 2020-07-20 9:59 UTC (permalink / raw) To: christian.koenig; +Cc: Deucher, Alexander, Harry Wentland, amd-gfx Hi Christian, On Mon, Jul 20, 2020 at 11:00 AM Christian König <ckoenig.leichtzumerken@gmail.com> wrote: > > Hi Mauro, > > I'm not deep into the whole DC design, so just some general high level > comments on the cover letter: > > 1. Please add a subject line to the cover letter, my spam filter thinks > that this is suspicious otherwise. My mistake in the editing of covert letter with git send-email, I may have forgot to keep the Subject at the top > > 2. Then you should probably note how well (badly?) is that tested. Since > you noted proof of concept it might not even work. The Changelog is to be read as: [RFC] was the initial Proof of concept was the RFC and [PATCH v2] was just a rebase onto amd-staging-drm-next this series [PATCH v3] has all the known changes required for DCE6 specificity and based on a long offline thread with Alexander Deutcher and past dri-devel chats with Harry Wentland. It was tested for my possibilities of testing with HD7750 and HD7950, with checks in dmesg output for not getting "missing registers/masks" kernel WARNING and with kernel build on Ubuntu 20.04 and with android-x86 The proposal I made to Alex is that AMD testing systems will be used for further regression testing, as part of review and validation for eligibility to amd-staging-drm-next > > 3. How feature complete (HDMI audio?, Freesync?) is it? All the changes in DC impacting DCE8 (dc/dce80 path) were ported to DCE6 (dc/dce60 path) in the last two years from initial submission > > Apart from that it looks like a rather impressive piece of work :) > > Cheers, > Christian. Thanks, please consider that most of the latest DCE6 specific parts were possible due to recent Alex support in getting the correct DCE6 headers, his suggestions and continuous feedback. I would suggest that Alex comments on the proposed next steps to follow. Mauro > > Am 16.07.20 um 23:22 schrieb Mauro Rossi: > > The series adds SI support to AMD DC > > > > Changelog: > > > > [RFC] > > Preliminar Proof Of Concept, with DCE8 headers still used in dce60_resources.c > > > > [PATCH v2] > > Rebase on amd-staging-drm-next dated 17-Oct-2018 > > > > [PATCH v3] > > Add support for DCE6 specific headers, > > ad hoc DCE6 macros, funtions and fixes, > > rebase on current amd-staging-drm-next > > > > > > Commits [01/27]..[08/27] SI support added in various DC components > > > > [PATCH v3 01/27] drm/amdgpu: add some required DCE6 registers (v6) > > [PATCH v3 02/27] drm/amd/display: add asics info for SI parts > > [PATCH v3 03/27] drm/amd/display: dc/dce: add initial DCE6 support (v9b) > > [PATCH v3 04/27] drm/amd/display: dc/core: add SI/DCE6 support (v2) > > [PATCH v3 05/27] drm/amd/display: dc/bios: add support for DCE6 > > [PATCH v3 06/27] drm/amd/display: dc/gpio: add support for DCE6 (v2) > > [PATCH v3 07/27] drm/amd/display: dc/irq: add support for DCE6 (v4) > > [PATCH v3 08/27] drm/amd/display: amdgpu_dm: add SI support (v4) > > > > Commits [09/27]..[24/27] DCE6 specific code adaptions > > > > [PATCH v3 09/27] drm/amd/display: dc/clk_mgr: add support for SI parts (v2) > > [PATCH v3 10/27] drm/amd/display: dc/dce60: set max_cursor_size to 64 > > [PATCH v3 11/27] drm/amd/display: dce_audio: add DCE6 specific macros,functions > > [PATCH v3 12/27] drm/amd/display: dce_dmcu: add DCE6 specific macros > > [PATCH v3 13/27] drm/amd/display: dce_hwseq: add DCE6 specific macros,functions > > [PATCH v3 14/27] drm/amd/display: dce_ipp: add DCE6 specific macros,functions > > [PATCH v3 15/27] drm/amd/display: dce_link_encoder: add DCE6 specific macros,functions > > [PATCH v3 16/27] drm/amd/display: dce_mem_input: add DCE6 specific macros,functions > > [PATCH v3 17/27] drm/amd/display: dce_opp: add DCE6 specific macros,functions > > [PATCH v3 18/27] drm/amd/display: dce_transform: add DCE6 specific macros,functions > > [PATCH v3 19/27] drm/amdgpu: add some required DCE6 registers (v7) > > [PATCH v3 20/27] drm/amd/display: dce_transform: DCE6 Scaling Horizontal Filter Init > > [PATCH v3 21/27] drm/amd/display: dce60_hw_sequencer: add DCE6 macros,functions > > [PATCH v3 22/27] drm/amd/display: dce60_hw_sequencer: add DCE6 specific .cursor_lock > > [PATCH v3 23/27] drm/amd/display: dce60_timing_generator: add DCE6 specific functions > > [PATCH v3 24/27] drm/amd/display: dc/dce60: use DCE6 headers (v6) > > > > > > Commits [25/27]..[27/27] SI support final enablements > > > > [PATCH v3 25/27] drm/amd/display: create plane rotation property for Bonarie and later > > [PATCH v3 26/27] drm/amdgpu: enable DC support for SI parts (v2) > > [PATCH v3 27/27] drm/amd/display: enable SI support in the Kconfig (v2) > > > > > > Signed-off-by: Mauro Rossi <issor.oruam@gmail.com> > > > > _______________________________________________ > > amd-gfx mailing list > > amd-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-07-20 9:59 ` Re: Mauro Rossi @ 2020-07-22 2:51 ` Alex Deucher 2020-07-22 7:56 ` Re: Mauro Rossi 0 siblings, 1 reply; 1767+ messages in thread From: Alex Deucher @ 2020-07-22 2:51 UTC (permalink / raw) To: Mauro Rossi Cc: Deucher, Alexander, Harry Wentland, Christian Koenig, amd-gfx list On Mon, Jul 20, 2020 at 6:00 AM Mauro Rossi <issor.oruam@gmail.com> wrote: > > Hi Christian, > > On Mon, Jul 20, 2020 at 11:00 AM Christian König > <ckoenig.leichtzumerken@gmail.com> wrote: > > > > Hi Mauro, > > > > I'm not deep into the whole DC design, so just some general high level > > comments on the cover letter: > > > > 1. Please add a subject line to the cover letter, my spam filter thinks > > that this is suspicious otherwise. > > My mistake in the editing of covert letter with git send-email, > I may have forgot to keep the Subject at the top > > > > > 2. Then you should probably note how well (badly?) is that tested. Since > > you noted proof of concept it might not even work. > > The Changelog is to be read as: > > [RFC] was the initial Proof of concept was the RFC and [PATCH v2] was > just a rebase onto amd-staging-drm-next > > this series [PATCH v3] has all the known changes required for DCE6 specificity > and based on a long offline thread with Alexander Deutcher and past > dri-devel chats with Harry Wentland. > > It was tested for my possibilities of testing with HD7750 and HD7950, > with checks in dmesg output for not getting "missing registers/masks" > kernel WARNING > and with kernel build on Ubuntu 20.04 and with android-x86 > > The proposal I made to Alex is that AMD testing systems will be used > for further regression testing, > as part of review and validation for eligibility to amd-staging-drm-next > We will certainly test it once it lands, but presumably this is working on the SI cards you have access to? > > > > 3. How feature complete (HDMI audio?, Freesync?) is it? > > All the changes in DC impacting DCE8 (dc/dce80 path) were ported to > DCE6 (dc/dce60 path) in the last two years from initial submission > > > > > Apart from that it looks like a rather impressive piece of work :) > > > > Cheers, > > Christian. > > Thanks, > please consider that most of the latest DCE6 specific parts were > possible due to recent Alex support in getting the correct DCE6 > headers, > his suggestions and continuous feedback. > > I would suggest that Alex comments on the proposed next steps to follow. The code looks pretty good to me. I'd like to get some feedback from the display team to see if they have any concerns, but beyond that I think we can pull it into the tree and continue improving it there. Do you have a link to a git tree I can pull directly that contains these patches? Is this the right branch? https://github.com/maurossi/linux/commits/kernel-5.8rc4_si_next Thanks! Alex > > Mauro > > > > > Am 16.07.20 um 23:22 schrieb Mauro Rossi: > > > The series adds SI support to AMD DC > > > > > > Changelog: > > > > > > [RFC] > > > Preliminar Proof Of Concept, with DCE8 headers still used in dce60_resources.c > > > > > > [PATCH v2] > > > Rebase on amd-staging-drm-next dated 17-Oct-2018 > > > > > > [PATCH v3] > > > Add support for DCE6 specific headers, > > > ad hoc DCE6 macros, funtions and fixes, > > > rebase on current amd-staging-drm-next > > > > > > > > > Commits [01/27]..[08/27] SI support added in various DC components > > > > > > [PATCH v3 01/27] drm/amdgpu: add some required DCE6 registers (v6) > > > [PATCH v3 02/27] drm/amd/display: add asics info for SI parts > > > [PATCH v3 03/27] drm/amd/display: dc/dce: add initial DCE6 support (v9b) > > > [PATCH v3 04/27] drm/amd/display: dc/core: add SI/DCE6 support (v2) > > > [PATCH v3 05/27] drm/amd/display: dc/bios: add support for DCE6 > > > [PATCH v3 06/27] drm/amd/display: dc/gpio: add support for DCE6 (v2) > > > [PATCH v3 07/27] drm/amd/display: dc/irq: add support for DCE6 (v4) > > > [PATCH v3 08/27] drm/amd/display: amdgpu_dm: add SI support (v4) > > > > > > Commits [09/27]..[24/27] DCE6 specific code adaptions > > > > > > [PATCH v3 09/27] drm/amd/display: dc/clk_mgr: add support for SI parts (v2) > > > [PATCH v3 10/27] drm/amd/display: dc/dce60: set max_cursor_size to 64 > > > [PATCH v3 11/27] drm/amd/display: dce_audio: add DCE6 specific macros,functions > > > [PATCH v3 12/27] drm/amd/display: dce_dmcu: add DCE6 specific macros > > > [PATCH v3 13/27] drm/amd/display: dce_hwseq: add DCE6 specific macros,functions > > > [PATCH v3 14/27] drm/amd/display: dce_ipp: add DCE6 specific macros,functions > > > [PATCH v3 15/27] drm/amd/display: dce_link_encoder: add DCE6 specific macros,functions > > > [PATCH v3 16/27] drm/amd/display: dce_mem_input: add DCE6 specific macros,functions > > > [PATCH v3 17/27] drm/amd/display: dce_opp: add DCE6 specific macros,functions > > > [PATCH v3 18/27] drm/amd/display: dce_transform: add DCE6 specific macros,functions > > > [PATCH v3 19/27] drm/amdgpu: add some required DCE6 registers (v7) > > > [PATCH v3 20/27] drm/amd/display: dce_transform: DCE6 Scaling Horizontal Filter Init > > > [PATCH v3 21/27] drm/amd/display: dce60_hw_sequencer: add DCE6 macros,functions > > > [PATCH v3 22/27] drm/amd/display: dce60_hw_sequencer: add DCE6 specific .cursor_lock > > > [PATCH v3 23/27] drm/amd/display: dce60_timing_generator: add DCE6 specific functions > > > [PATCH v3 24/27] drm/amd/display: dc/dce60: use DCE6 headers (v6) > > > > > > > > > Commits [25/27]..[27/27] SI support final enablements > > > > > > [PATCH v3 25/27] drm/amd/display: create plane rotation property for Bonarie and later > > > [PATCH v3 26/27] drm/amdgpu: enable DC support for SI parts (v2) > > > [PATCH v3 27/27] drm/amd/display: enable SI support in the Kconfig (v2) > > > > > > > > > Signed-off-by: Mauro Rossi <issor.oruam@gmail.com> > > > > > > _______________________________________________ > > > amd-gfx mailing list > > > amd-gfx@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > > > _______________________________________________ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-07-22 2:51 ` Re: Alex Deucher @ 2020-07-22 7:56 ` Mauro Rossi 2020-07-24 18:31 ` Re: Alex Deucher 0 siblings, 1 reply; 1767+ messages in thread From: Mauro Rossi @ 2020-07-22 7:56 UTC (permalink / raw) To: Alex Deucher Cc: Deucher, Alexander, Harry Wentland, Christian Koenig, amd-gfx list [-- Attachment #1.1: Type: text/plain, Size: 6915 bytes --] Hello, re-sending and copying full DL On Wed, Jul 22, 2020 at 4:51 AM Alex Deucher <alexdeucher@gmail.com> wrote: > On Mon, Jul 20, 2020 at 6:00 AM Mauro Rossi <issor.oruam@gmail.com> wrote: > > > > Hi Christian, > > > > On Mon, Jul 20, 2020 at 11:00 AM Christian König > > <ckoenig.leichtzumerken@gmail.com> wrote: > > > > > > Hi Mauro, > > > > > > I'm not deep into the whole DC design, so just some general high level > > > comments on the cover letter: > > > > > > 1. Please add a subject line to the cover letter, my spam filter thinks > > > that this is suspicious otherwise. > > > > My mistake in the editing of covert letter with git send-email, > > I may have forgot to keep the Subject at the top > > > > > > > > 2. Then you should probably note how well (badly?) is that tested. > Since > > > you noted proof of concept it might not even work. > > > > The Changelog is to be read as: > > > > [RFC] was the initial Proof of concept was the RFC and [PATCH v2] was > > just a rebase onto amd-staging-drm-next > > > > this series [PATCH v3] has all the known changes required for DCE6 > specificity > > and based on a long offline thread with Alexander Deutcher and past > > dri-devel chats with Harry Wentland. > > > > It was tested for my possibilities of testing with HD7750 and HD7950, > > with checks in dmesg output for not getting "missing registers/masks" > > kernel WARNING > > and with kernel build on Ubuntu 20.04 and with android-x86 > > > > The proposal I made to Alex is that AMD testing systems will be used > > for further regression testing, > > as part of review and validation for eligibility to amd-staging-drm-next > > > > We will certainly test it once it lands, but presumably this is > working on the SI cards you have access to? > Yes, most of my testing was done with android-x86 Android CTS (EGL, GLES2, GLES3, VK) I am also in contact with a person with Firepro W5130M who is running a piglit session I had bought an HD7850 to test with Pitcairn, but it arrived as defective so I could not test with Pitcair > > > > > > 3. How feature complete (HDMI audio?, Freesync?) is it? > > > > All the changes in DC impacting DCE8 (dc/dce80 path) were ported to > > DCE6 (dc/dce60 path) in the last two years from initial submission > > > > > > > > Apart from that it looks like a rather impressive piece of work :) > > > > > > Cheers, > > > Christian. > > > > Thanks, > > please consider that most of the latest DCE6 specific parts were > > possible due to recent Alex support in getting the correct DCE6 > > headers, > > his suggestions and continuous feedback. > > > > I would suggest that Alex comments on the proposed next steps to follow. > > The code looks pretty good to me. I'd like to get some feedback from > the display team to see if they have any concerns, but beyond that I > think we can pull it into the tree and continue improving it there. > Do you have a link to a git tree I can pull directly that contains > these patches? Is this the right branch? > https://github.com/maurossi/linux/commits/kernel-5.8rc4_si_next > > Thanks! > > Alex > The following branch was pushed with the series on top of amd-staging-drm-next https://github.com/maurossi/linux/commits/kernel-5.6_si_drm-next > > > > > Mauro > > > > > > > > Am 16.07.20 um 23:22 schrieb Mauro Rossi: > > > > The series adds SI support to AMD DC > > > > > > > > Changelog: > > > > > > > > [RFC] > > > > Preliminar Proof Of Concept, with DCE8 headers still used in > dce60_resources.c > > > > > > > > [PATCH v2] > > > > Rebase on amd-staging-drm-next dated 17-Oct-2018 > > > > > > > > [PATCH v3] > > > > Add support for DCE6 specific headers, > > > > ad hoc DCE6 macros, funtions and fixes, > > > > rebase on current amd-staging-drm-next > > > > > > > > > > > > Commits [01/27]..[08/27] SI support added in various DC components > > > > > > > > [PATCH v3 01/27] drm/amdgpu: add some required DCE6 registers (v6) > > > > [PATCH v3 02/27] drm/amd/display: add asics info for SI parts > > > > [PATCH v3 03/27] drm/amd/display: dc/dce: add initial DCE6 support > (v9b) > > > > [PATCH v3 04/27] drm/amd/display: dc/core: add SI/DCE6 support (v2) > > > > [PATCH v3 05/27] drm/amd/display: dc/bios: add support for DCE6 > > > > [PATCH v3 06/27] drm/amd/display: dc/gpio: add support for DCE6 (v2) > > > > [PATCH v3 07/27] drm/amd/display: dc/irq: add support for DCE6 (v4) > > > > [PATCH v3 08/27] drm/amd/display: amdgpu_dm: add SI support (v4) > > > > > > > > Commits [09/27]..[24/27] DCE6 specific code adaptions > > > > > > > > [PATCH v3 09/27] drm/amd/display: dc/clk_mgr: add support for SI > parts (v2) > > > > [PATCH v3 10/27] drm/amd/display: dc/dce60: set max_cursor_size to 64 > > > > [PATCH v3 11/27] drm/amd/display: dce_audio: add DCE6 specific > macros,functions > > > > [PATCH v3 12/27] drm/amd/display: dce_dmcu: add DCE6 specific macros > > > > [PATCH v3 13/27] drm/amd/display: dce_hwseq: add DCE6 specific > macros,functions > > > > [PATCH v3 14/27] drm/amd/display: dce_ipp: add DCE6 specific > macros,functions > > > > [PATCH v3 15/27] drm/amd/display: dce_link_encoder: add DCE6 > specific macros,functions > > > > [PATCH v3 16/27] drm/amd/display: dce_mem_input: add DCE6 specific > macros,functions > > > > [PATCH v3 17/27] drm/amd/display: dce_opp: add DCE6 specific > macros,functions > > > > [PATCH v3 18/27] drm/amd/display: dce_transform: add DCE6 specific > macros,functions > > > > [PATCH v3 19/27] drm/amdgpu: add some required DCE6 registers (v7) > > > > [PATCH v3 20/27] drm/amd/display: dce_transform: DCE6 Scaling > Horizontal Filter Init > > > > [PATCH v3 21/27] drm/amd/display: dce60_hw_sequencer: add DCE6 > macros,functions > > > > [PATCH v3 22/27] drm/amd/display: dce60_hw_sequencer: add DCE6 > specific .cursor_lock > > > > [PATCH v3 23/27] drm/amd/display: dce60_timing_generator: add DCE6 > specific functions > > > > [PATCH v3 24/27] drm/amd/display: dc/dce60: use DCE6 headers (v6) > > > > > > > > > > > > Commits [25/27]..[27/27] SI support final enablements > > > > > > > > [PATCH v3 25/27] drm/amd/display: create plane rotation property for > Bonarie and later > > > > [PATCH v3 26/27] drm/amdgpu: enable DC support for SI parts (v2) > > > > [PATCH v3 27/27] drm/amd/display: enable SI support in the Kconfig > (v2) > > > > > > > > > > > > Signed-off-by: Mauro Rossi <issor.oruam@gmail.com> > > > > > > > > _______________________________________________ > > > > amd-gfx mailing list > > > > amd-gfx@lists.freedesktop.org > > > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > > > > > _______________________________________________ > > amd-gfx mailing list > > amd-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > [-- Attachment #1.2: Type: text/html, Size: 9472 bytes --] [-- Attachment #2: Type: text/plain, Size: 154 bytes --] _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-07-22 7:56 ` Re: Mauro Rossi @ 2020-07-24 18:31 ` Alex Deucher 2020-07-26 15:31 ` Re: Mauro Rossi 0 siblings, 1 reply; 1767+ messages in thread From: Alex Deucher @ 2020-07-24 18:31 UTC (permalink / raw) To: Mauro Rossi Cc: Deucher, Alexander, Harry Wentland, Christian Koenig, amd-gfx list [-- Attachment #1: Type: text/plain, Size: 7470 bytes --] On Wed, Jul 22, 2020 at 3:57 AM Mauro Rossi <issor.oruam@gmail.com> wrote: > > Hello, > re-sending and copying full DL > > On Wed, Jul 22, 2020 at 4:51 AM Alex Deucher <alexdeucher@gmail.com> wrote: >> >> On Mon, Jul 20, 2020 at 6:00 AM Mauro Rossi <issor.oruam@gmail.com> wrote: >> > >> > Hi Christian, >> > >> > On Mon, Jul 20, 2020 at 11:00 AM Christian König >> > <ckoenig.leichtzumerken@gmail.com> wrote: >> > > >> > > Hi Mauro, >> > > >> > > I'm not deep into the whole DC design, so just some general high level >> > > comments on the cover letter: >> > > >> > > 1. Please add a subject line to the cover letter, my spam filter thinks >> > > that this is suspicious otherwise. >> > >> > My mistake in the editing of covert letter with git send-email, >> > I may have forgot to keep the Subject at the top >> > >> > > >> > > 2. Then you should probably note how well (badly?) is that tested. Since >> > > you noted proof of concept it might not even work. >> > >> > The Changelog is to be read as: >> > >> > [RFC] was the initial Proof of concept was the RFC and [PATCH v2] was >> > just a rebase onto amd-staging-drm-next >> > >> > this series [PATCH v3] has all the known changes required for DCE6 specificity >> > and based on a long offline thread with Alexander Deutcher and past >> > dri-devel chats with Harry Wentland. >> > >> > It was tested for my possibilities of testing with HD7750 and HD7950, >> > with checks in dmesg output for not getting "missing registers/masks" >> > kernel WARNING >> > and with kernel build on Ubuntu 20.04 and with android-x86 >> > >> > The proposal I made to Alex is that AMD testing systems will be used >> > for further regression testing, >> > as part of review and validation for eligibility to amd-staging-drm-next >> > >> >> We will certainly test it once it lands, but presumably this is >> working on the SI cards you have access to? > > > Yes, most of my testing was done with android-x86 Android CTS (EGL, GLES2, GLES3, VK) > > I am also in contact with a person with Firepro W5130M who is running a piglit session > > I had bought an HD7850 to test with Pitcairn, but it arrived as defective so I could not test with Pitcair > > >> >> > > >> > > 3. How feature complete (HDMI audio?, Freesync?) is it? >> > >> > All the changes in DC impacting DCE8 (dc/dce80 path) were ported to >> > DCE6 (dc/dce60 path) in the last two years from initial submission >> > >> > > >> > > Apart from that it looks like a rather impressive piece of work :) >> > > >> > > Cheers, >> > > Christian. >> > >> > Thanks, >> > please consider that most of the latest DCE6 specific parts were >> > possible due to recent Alex support in getting the correct DCE6 >> > headers, >> > his suggestions and continuous feedback. >> > >> > I would suggest that Alex comments on the proposed next steps to follow. >> >> The code looks pretty good to me. I'd like to get some feedback from >> the display team to see if they have any concerns, but beyond that I >> think we can pull it into the tree and continue improving it there. >> Do you have a link to a git tree I can pull directly that contains >> these patches? Is this the right branch? >> https://github.com/maurossi/linux/commits/kernel-5.8rc4_si_next >> >> Thanks! >> >> Alex > > > The following branch was pushed with the series on top of amd-staging-drm-next > > https://github.com/maurossi/linux/commits/kernel-5.6_si_drm-next I gave this a quick test on all of the SI asics and the various monitors I had available and it looks good. A few minor patches I noticed are attached. If they look good to you, I'll squash them into the series when I commit it. I've pushed it to my fdo tree as well: https://cgit.freedesktop.org/~agd5f/linux/log/?h=si_dc_support Thanks! Alex > >> >> >> > >> > Mauro >> > >> > > >> > > Am 16.07.20 um 23:22 schrieb Mauro Rossi: >> > > > The series adds SI support to AMD DC >> > > > >> > > > Changelog: >> > > > >> > > > [RFC] >> > > > Preliminar Proof Of Concept, with DCE8 headers still used in dce60_resources.c >> > > > >> > > > [PATCH v2] >> > > > Rebase on amd-staging-drm-next dated 17-Oct-2018 >> > > > >> > > > [PATCH v3] >> > > > Add support for DCE6 specific headers, >> > > > ad hoc DCE6 macros, funtions and fixes, >> > > > rebase on current amd-staging-drm-next >> > > > >> > > > >> > > > Commits [01/27]..[08/27] SI support added in various DC components >> > > > >> > > > [PATCH v3 01/27] drm/amdgpu: add some required DCE6 registers (v6) >> > > > [PATCH v3 02/27] drm/amd/display: add asics info for SI parts >> > > > [PATCH v3 03/27] drm/amd/display: dc/dce: add initial DCE6 support (v9b) >> > > > [PATCH v3 04/27] drm/amd/display: dc/core: add SI/DCE6 support (v2) >> > > > [PATCH v3 05/27] drm/amd/display: dc/bios: add support for DCE6 >> > > > [PATCH v3 06/27] drm/amd/display: dc/gpio: add support for DCE6 (v2) >> > > > [PATCH v3 07/27] drm/amd/display: dc/irq: add support for DCE6 (v4) >> > > > [PATCH v3 08/27] drm/amd/display: amdgpu_dm: add SI support (v4) >> > > > >> > > > Commits [09/27]..[24/27] DCE6 specific code adaptions >> > > > >> > > > [PATCH v3 09/27] drm/amd/display: dc/clk_mgr: add support for SI parts (v2) >> > > > [PATCH v3 10/27] drm/amd/display: dc/dce60: set max_cursor_size to 64 >> > > > [PATCH v3 11/27] drm/amd/display: dce_audio: add DCE6 specific macros,functions >> > > > [PATCH v3 12/27] drm/amd/display: dce_dmcu: add DCE6 specific macros >> > > > [PATCH v3 13/27] drm/amd/display: dce_hwseq: add DCE6 specific macros,functions >> > > > [PATCH v3 14/27] drm/amd/display: dce_ipp: add DCE6 specific macros,functions >> > > > [PATCH v3 15/27] drm/amd/display: dce_link_encoder: add DCE6 specific macros,functions >> > > > [PATCH v3 16/27] drm/amd/display: dce_mem_input: add DCE6 specific macros,functions >> > > > [PATCH v3 17/27] drm/amd/display: dce_opp: add DCE6 specific macros,functions >> > > > [PATCH v3 18/27] drm/amd/display: dce_transform: add DCE6 specific macros,functions >> > > > [PATCH v3 19/27] drm/amdgpu: add some required DCE6 registers (v7) >> > > > [PATCH v3 20/27] drm/amd/display: dce_transform: DCE6 Scaling Horizontal Filter Init >> > > > [PATCH v3 21/27] drm/amd/display: dce60_hw_sequencer: add DCE6 macros,functions >> > > > [PATCH v3 22/27] drm/amd/display: dce60_hw_sequencer: add DCE6 specific .cursor_lock >> > > > [PATCH v3 23/27] drm/amd/display: dce60_timing_generator: add DCE6 specific functions >> > > > [PATCH v3 24/27] drm/amd/display: dc/dce60: use DCE6 headers (v6) >> > > > >> > > > >> > > > Commits [25/27]..[27/27] SI support final enablements >> > > > >> > > > [PATCH v3 25/27] drm/amd/display: create plane rotation property for Bonarie and later >> > > > [PATCH v3 26/27] drm/amdgpu: enable DC support for SI parts (v2) >> > > > [PATCH v3 27/27] drm/amd/display: enable SI support in the Kconfig (v2) >> > > > >> > > > >> > > > Signed-off-by: Mauro Rossi <issor.oruam@gmail.com> >> > > > >> > > > _______________________________________________ >> > > > amd-gfx mailing list >> > > > amd-gfx@lists.freedesktop.org >> > > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx >> > > >> > _______________________________________________ >> > amd-gfx mailing list >> > amd-gfx@lists.freedesktop.org >> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx [-- Attachment #2: 0002-drm-amdgpu-display-addming-return-type-for-dce60_pro.patch --] [-- Type: text/x-patch, Size: 982 bytes --] From 782fea4387d22686856c87b8ac0491a43a4d944c Mon Sep 17 00:00:00 2001 From: Alex Deucher <alexander.deucher@amd.com> Date: Thu, 23 Jul 2020 21:05:41 -0400 Subject: [PATCH 2/3] drm/amdgpu/display: addming return type for dce60_program_front_end_for_pipe Probably a copy/paste typo. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> --- drivers/gpu/drm/amd/display/dc/dce60/dce60_hw_sequencer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce60/dce60_hw_sequencer.c b/drivers/gpu/drm/amd/display/dc/dce60/dce60_hw_sequencer.c index 66e5a1ba2a58..920c7ae29d53 100644 --- a/drivers/gpu/drm/amd/display/dc/dce60/dce60_hw_sequencer.c +++ b/drivers/gpu/drm/amd/display/dc/dce60/dce60_hw_sequencer.c @@ -266,7 +266,7 @@ static void dce60_program_scaler(const struct dc *dc, &pipe_ctx->plane_res.scl_data); } - +static void dce60_program_front_end_for_pipe( struct dc *dc, struct pipe_ctx *pipe_ctx) { -- 2.25.4 [-- Attachment #3: 0003-drm-amdgpu-display-Fix-up-PLL-handling-for-DCE6.patch --] [-- Type: text/x-patch, Size: 1855 bytes --] From 2b18098918717d9ee4c69a47be3527d1cc812b7f Mon Sep 17 00:00:00 2001 From: Alex Deucher <alexander.deucher@amd.com> Date: Fri, 24 Jul 2020 11:41:31 -0400 Subject: [PATCH 3/3] drm/amdgpu/display: Fix up PLL handling for DCE6 DCE6.0 supports 2 PLLs. DCE6.1 supports 3 PLLs. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> --- drivers/gpu/drm/amd/display/dc/dce60/dce60_resource.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce60/dce60_resource.c b/drivers/gpu/drm/amd/display/dc/dce60/dce60_resource.c index 261333afc936..5a5a9cb77acb 100644 --- a/drivers/gpu/drm/amd/display/dc/dce60/dce60_resource.c +++ b/drivers/gpu/drm/amd/display/dc/dce60/dce60_resource.c @@ -379,7 +379,7 @@ static const struct resource_caps res_cap_61 = { .num_timing_generator = 4, .num_audio = 6, .num_stream_encoder = 6, - .num_pll = 2, + .num_pll = 3, .num_ddc = 6, }; @@ -983,9 +983,7 @@ static bool dce60_construct( dce60_clock_source_create(ctx, bp, CLOCK_SOURCE_ID_PLL0, &clk_src_regs[0], false); pool->base.clock_sources[1] = dce60_clock_source_create(ctx, bp, CLOCK_SOURCE_ID_PLL1, &clk_src_regs[1], false); - pool->base.clock_sources[2] = - dce60_clock_source_create(ctx, bp, CLOCK_SOURCE_ID_PLL2, &clk_src_regs[2], false); - pool->base.clk_src_count = 3; + pool->base.clk_src_count = 2; } else { pool->base.dp_clock_source = @@ -993,9 +991,7 @@ static bool dce60_construct( pool->base.clock_sources[0] = dce60_clock_source_create(ctx, bp, CLOCK_SOURCE_ID_PLL1, &clk_src_regs[1], false); - pool->base.clock_sources[1] = - dce60_clock_source_create(ctx, bp, CLOCK_SOURCE_ID_PLL2, &clk_src_regs[2], false); - pool->base.clk_src_count = 2; + pool->base.clk_src_count = 1; } if (pool->base.dp_clock_source == NULL) { -- 2.25.4 [-- Attachment #4: 0001-drm-amdgpu-display-remove-unused-variable-in-dce60_c.patch --] [-- Type: text/x-patch, Size: 1084 bytes --] From 2ced8e528937051e4d8536718c6dc776e0b46314 Mon Sep 17 00:00:00 2001 From: Alex Deucher <alexander.deucher@amd.com> Date: Thu, 23 Jul 2020 21:02:14 -0400 Subject: [PATCH 1/3] drm/amdgpu/display: remove unused variable in dce60_configure_crc Signed-off-by: Alex Deucher <alexander.deucher@amd.com> --- drivers/gpu/drm/amd/display/dc/dce60/dce60_timing_generator.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce60/dce60_timing_generator.c b/drivers/gpu/drm/amd/display/dc/dce60/dce60_timing_generator.c index 4a5b7a0940c6..fc1af0ff0ca4 100644 --- a/drivers/gpu/drm/amd/display/dc/dce60/dce60_timing_generator.c +++ b/drivers/gpu/drm/amd/display/dc/dce60/dce60_timing_generator.c @@ -192,8 +192,6 @@ static bool dce60_is_tg_enabled(struct timing_generator *tg) bool dce60_configure_crc(struct timing_generator *tg, const struct crc_params *params) { - struct dce110_timing_generator *tg110 = DCE110TG_FROM_TG(tg); - /* Cannot configure crc on a CRTC that is disabled */ if (!dce60_is_tg_enabled(tg)) return false; -- 2.25.4 [-- Attachment #5: Type: text/plain, Size: 154 bytes --] _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2020-07-24 18:31 ` Re: Alex Deucher @ 2020-07-26 15:31 ` Mauro Rossi 2020-07-27 18:31 ` Re: Alex Deucher 0 siblings, 1 reply; 1767+ messages in thread From: Mauro Rossi @ 2020-07-26 15:31 UTC (permalink / raw) To: Alex Deucher Cc: Deucher, Alexander, Harry Wentland, Christian Koenig, amd-gfx list [-- Attachment #1.1: Type: text/plain, Size: 9396 bytes --] Hello, On Fri, Jul 24, 2020 at 8:31 PM Alex Deucher <alexdeucher@gmail.com> wrote: > On Wed, Jul 22, 2020 at 3:57 AM Mauro Rossi <issor.oruam@gmail.com> wrote: > > > > Hello, > > re-sending and copying full DL > > > > On Wed, Jul 22, 2020 at 4:51 AM Alex Deucher <alexdeucher@gmail.com> > wrote: > >> > >> On Mon, Jul 20, 2020 at 6:00 AM Mauro Rossi <issor.oruam@gmail.com> > wrote: > >> > > >> > Hi Christian, > >> > > >> > On Mon, Jul 20, 2020 at 11:00 AM Christian König > >> > <ckoenig.leichtzumerken@gmail.com> wrote: > >> > > > >> > > Hi Mauro, > >> > > > >> > > I'm not deep into the whole DC design, so just some general high > level > >> > > comments on the cover letter: > >> > > > >> > > 1. Please add a subject line to the cover letter, my spam filter > thinks > >> > > that this is suspicious otherwise. > >> > > >> > My mistake in the editing of covert letter with git send-email, > >> > I may have forgot to keep the Subject at the top > >> > > >> > > > >> > > 2. Then you should probably note how well (badly?) is that tested. > Since > >> > > you noted proof of concept it might not even work. > >> > > >> > The Changelog is to be read as: > >> > > >> > [RFC] was the initial Proof of concept was the RFC and [PATCH v2] was > >> > just a rebase onto amd-staging-drm-next > >> > > >> > this series [PATCH v3] has all the known changes required for DCE6 > specificity > >> > and based on a long offline thread with Alexander Deutcher and past > >> > dri-devel chats with Harry Wentland. > >> > > >> > It was tested for my possibilities of testing with HD7750 and HD7950, > >> > with checks in dmesg output for not getting "missing registers/masks" > >> > kernel WARNING > >> > and with kernel build on Ubuntu 20.04 and with android-x86 > >> > > >> > The proposal I made to Alex is that AMD testing systems will be used > >> > for further regression testing, > >> > as part of review and validation for eligibility to > amd-staging-drm-next > >> > > >> > >> We will certainly test it once it lands, but presumably this is > >> working on the SI cards you have access to? > > > > > > Yes, most of my testing was done with android-x86 Android CTS (EGL, > GLES2, GLES3, VK) > > > > I am also in contact with a person with Firepro W5130M who is running a > piglit session > > > > I had bought an HD7850 to test with Pitcairn, but it arrived as > defective so I could not test with Pitcair > > > > > >> > >> > > > >> > > 3. How feature complete (HDMI audio?, Freesync?) is it? > >> > > >> > All the changes in DC impacting DCE8 (dc/dce80 path) were ported to > >> > DCE6 (dc/dce60 path) in the last two years from initial submission > >> > > >> > > > >> > > Apart from that it looks like a rather impressive piece of work :) > >> > > > >> > > Cheers, > >> > > Christian. > >> > > >> > Thanks, > >> > please consider that most of the latest DCE6 specific parts were > >> > possible due to recent Alex support in getting the correct DCE6 > >> > headers, > >> > his suggestions and continuous feedback. > >> > > >> > I would suggest that Alex comments on the proposed next steps to > follow. > >> > >> The code looks pretty good to me. I'd like to get some feedback from > >> the display team to see if they have any concerns, but beyond that I > >> think we can pull it into the tree and continue improving it there. > >> Do you have a link to a git tree I can pull directly that contains > >> these patches? Is this the right branch? > >> https://github.com/maurossi/linux/commits/kernel-5.8rc4_si_next > >> > >> Thanks! > >> > >> Alex > > > > > > The following branch was pushed with the series on top of > amd-staging-drm-next > > > > https://github.com/maurossi/linux/commits/kernel-5.6_si_drm-next > > I gave this a quick test on all of the SI asics and the various > monitors I had available and it looks good. A few minor patches I > noticed are attached. If they look good to you, I'll squash them into > the series when I commit it. I've pushed it to my fdo tree as well: > https://cgit.freedesktop.org/~agd5f/linux/log/?h=si_dc_support > > Thanks! > > Alex > The new patches are ok and with the following infomation about piglit tests, the series may be good to go. I have performed piglit tests on Tahiti HD7950 on kernel 5.8.0-rc6 with AMD DC support for SI and comparison with vanilla kernel 5.8.0-rc6 Results are the following [piglit gpu tests with kernel 5.8.0-rc6-amddcsi] utente@utente-desktop:~/piglit$ ./piglit run gpu . [26714/26714] skip: 1731, pass: 24669, warn: 15, fail: 288, crash: 11 Thank you for running Piglit! Results have been written to /home/utente/piglit [piglit gpu tests with vanilla 5.8.0-rc6] utente@utente-desktop:~/piglit$ ./piglit run gpu . [26714/26714] skip: 1731, pass: 24673, warn: 13, fail: 283, crash: 14 Thank you for running Piglit! Results have been written to /home/utente/piglit In the attachment the comparison of "5.8.0-rc6-amddcsi" vs "5.8.0-rc6" vanilla and viceversa, I see no significant regression and in the delta of failed tests I don't recognize DC related test cases, but you may also have a look. dmesg for "5.8.0-rc6-amddcsi" is also provide the check the crashes Regarding the other user testing the series with Firepro W5130M he found an already existing issue in amdgpu si_support=1 which is independent from my series and matches a problem alrady reported. [1] Mauro [1] https://bbs.archlinux.org/viewtopic.php?id=249097 > > > > >> > >> > >> > > >> > Mauro > >> > > >> > > > >> > > Am 16.07.20 um 23:22 schrieb Mauro Rossi: > >> > > > The series adds SI support to AMD DC > >> > > > > >> > > > Changelog: > >> > > > > >> > > > [RFC] > >> > > > Preliminar Proof Of Concept, with DCE8 headers still used in > dce60_resources.c > >> > > > > >> > > > [PATCH v2] > >> > > > Rebase on amd-staging-drm-next dated 17-Oct-2018 > >> > > > > >> > > > [PATCH v3] > >> > > > Add support for DCE6 specific headers, > >> > > > ad hoc DCE6 macros, funtions and fixes, > >> > > > rebase on current amd-staging-drm-next > >> > > > > >> > > > > >> > > > Commits [01/27]..[08/27] SI support added in various DC components > >> > > > > >> > > > [PATCH v3 01/27] drm/amdgpu: add some required DCE6 registers (v6) > >> > > > [PATCH v3 02/27] drm/amd/display: add asics info for SI parts > >> > > > [PATCH v3 03/27] drm/amd/display: dc/dce: add initial DCE6 > support (v9b) > >> > > > [PATCH v3 04/27] drm/amd/display: dc/core: add SI/DCE6 support > (v2) > >> > > > [PATCH v3 05/27] drm/amd/display: dc/bios: add support for DCE6 > >> > > > [PATCH v3 06/27] drm/amd/display: dc/gpio: add support for DCE6 > (v2) > >> > > > [PATCH v3 07/27] drm/amd/display: dc/irq: add support for DCE6 > (v4) > >> > > > [PATCH v3 08/27] drm/amd/display: amdgpu_dm: add SI support (v4) > >> > > > > >> > > > Commits [09/27]..[24/27] DCE6 specific code adaptions > >> > > > > >> > > > [PATCH v3 09/27] drm/amd/display: dc/clk_mgr: add support for SI > parts (v2) > >> > > > [PATCH v3 10/27] drm/amd/display: dc/dce60: set max_cursor_size > to 64 > >> > > > [PATCH v3 11/27] drm/amd/display: dce_audio: add DCE6 specific > macros,functions > >> > > > [PATCH v3 12/27] drm/amd/display: dce_dmcu: add DCE6 specific > macros > >> > > > [PATCH v3 13/27] drm/amd/display: dce_hwseq: add DCE6 specific > macros,functions > >> > > > [PATCH v3 14/27] drm/amd/display: dce_ipp: add DCE6 specific > macros,functions > >> > > > [PATCH v3 15/27] drm/amd/display: dce_link_encoder: add DCE6 > specific macros,functions > >> > > > [PATCH v3 16/27] drm/amd/display: dce_mem_input: add DCE6 > specific macros,functions > >> > > > [PATCH v3 17/27] drm/amd/display: dce_opp: add DCE6 specific > macros,functions > >> > > > [PATCH v3 18/27] drm/amd/display: dce_transform: add DCE6 > specific macros,functions > >> > > > [PATCH v3 19/27] drm/amdgpu: add some required DCE6 registers (v7) > >> > > > [PATCH v3 20/27] drm/amd/display: dce_transform: DCE6 Scaling > Horizontal Filter Init > >> > > > [PATCH v3 21/27] drm/amd/display: dce60_hw_sequencer: add DCE6 > macros,functions > >> > > > [PATCH v3 22/27] drm/amd/display: dce60_hw_sequencer: add DCE6 > specific .cursor_lock > >> > > > [PATCH v3 23/27] drm/amd/display: dce60_timing_generator: add > DCE6 specific functions > >> > > > [PATCH v3 24/27] drm/amd/display: dc/dce60: use DCE6 headers (v6) > >> > > > > >> > > > > >> > > > Commits [25/27]..[27/27] SI support final enablements > >> > > > > >> > > > [PATCH v3 25/27] drm/amd/display: create plane rotation property > for Bonarie and later > >> > > > [PATCH v3 26/27] drm/amdgpu: enable DC support for SI parts (v2) > >> > > > [PATCH v3 27/27] drm/amd/display: enable SI support in the > Kconfig (v2) > >> > > > > >> > > > > >> > > > Signed-off-by: Mauro Rossi <issor.oruam@gmail.com> > >> > > > > >> > > > _______________________________________________ > >> > > > amd-gfx mailing list > >> > > > amd-gfx@lists.freedesktop.org > >> > > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > >> > > > >> > _______________________________________________ > >> > amd-gfx mailing list > >> > amd-gfx@lists.freedesktop.org > >> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > [-- Attachment #1.2: Type: text/html, Size: 13512 bytes --] [-- Attachment #2: dmesg_kernel-5.8.0-rc6_amddcsi.txt --] [-- Type: text/plain, Size: 87504 bytes --] [ 0.000000] microcode: microcode updated early to revision 0x21, date = 2019-02-13 [ 0.000000] Linux version 5.8.0-050800rc6-generic (kernel@kathleen) (gcc (Ubuntu 9.3.0-13ubuntu1) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34.90.20200716) #202007192331 SMP Sun Jul 19 23:33:45 UTC 2020 [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.8.0-050800rc6-generic root=UUID=833ac3c7-4d08-47b5-807f-9a8ddeb3a8d2 ro quiet splash radeon.si_support=0 amdgpu.si_support=1 vt.handoff=7 [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Hygon HygonGenuine [ 0.000000] Centaur CentaurHauls [ 0.000000] zhaoxin Shanghai [ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009d7ff] usable [ 0.000000] BIOS-e820: [mem 0x000000000009d800-0x000000000009ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000dd907fff] usable [ 0.000000] BIOS-e820: [mem 0x00000000dd908000-0x00000000de08cfff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000de08d000-0x00000000de116fff] usable [ 0.000000] BIOS-e820: [mem 0x00000000de117000-0x00000000de1b6fff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x00000000de1b7000-0x00000000de9a5fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000de9a6000-0x00000000de9a6fff] usable [ 0.000000] BIOS-e820: [mem 0x00000000de9a7000-0x00000000de9e9fff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x00000000de9ea000-0x00000000df407fff] usable [ 0.000000] BIOS-e820: [mem 0x00000000df408000-0x00000000df7f0fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000df7f1000-0x00000000df7fffff] usable [ 0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed00000-0x00000000fed03fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000021effffff] usable [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] SMBIOS 2.7 present. [ 0.000000] DMI: To Be Filled By O.E.M. To Be Filled By O.E.M./H77 Pro4/MVP, BIOS P1.70 08/07/2013 [ 0.000000] tsc: Fast TSC calibration using PIT [ 0.000000] tsc: Detected 3392.425 MHz processor [ 0.000891] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved [ 0.000892] e820: remove [mem 0x000a0000-0x000fffff] usable [ 0.000897] last_pfn = 0x21f000 max_arch_pfn = 0x400000000 [ 0.000901] MTRR default type: uncachable [ 0.000901] MTRR fixed ranges enabled: [ 0.000902] 00000-9FFFF write-back [ 0.000903] A0000-BFFFF uncachable [ 0.000903] C0000-CFFFF write-protect [ 0.000904] D0000-E7FFF uncachable [ 0.000904] E8000-FFFFF write-protect [ 0.000905] MTRR variable ranges enabled: [ 0.000906] 0 base 000000000 mask E00000000 write-back [ 0.000907] 1 base 200000000 mask FF0000000 write-back [ 0.000907] 2 base 210000000 mask FF8000000 write-back [ 0.000908] 3 base 218000000 mask FFC000000 write-back [ 0.000908] 4 base 21C000000 mask FFE000000 write-back [ 0.000909] 5 base 21E000000 mask FFF000000 write-back [ 0.000910] 6 base 0E0000000 mask FE0000000 uncachable [ 0.000910] 7 disabled [ 0.000910] 8 disabled [ 0.000911] 9 disabled [ 0.001158] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [ 0.001265] total RAM covered: 8176M [ 0.001638] Found optimal setting for mtrr clean up [ 0.001639] gran_size: 64K chunk_size: 32M num_reg: 6 lose cover RAM: 0G [ 0.001863] e820: update [mem 0xe0000000-0xffffffff] usable ==> reserved [ 0.001866] last_pfn = 0xdf800 max_arch_pfn = 0x400000000 [ 0.008892] found SMP MP-table at [mem 0x000fd8d0-0x000fd8df] [ 0.030371] check: Scanning 1 areas for low memory corruption [ 0.030771] RAMDISK: [mem 0x3172d000-0x34b8dfff] [ 0.030777] ACPI: Early table checksum verification disabled [ 0.030780] ACPI: RSDP 0x00000000000F0490 000024 (v02 ALASKA) [ 0.030782] ACPI: XSDT 0x00000000DE19B080 00007C (v01 ALASKA A M I 01072009 AMI 00010013) [ 0.030787] ACPI: FACP 0x00000000DE1A4DC0 00010C (v05 ALASKA A M I 01072009 AMI 00010013) [ 0.030791] ACPI: DSDT 0x00000000DE19B190 009C2D (v02 ALASKA A M I 00000022 INTL 20051117) [ 0.030794] ACPI: FACS 0x00000000DE1B5080 000040 [ 0.030796] ACPI: APIC 0x00000000DE1A4ED0 000072 (v03 ALASKA A M I 01072009 AMI 00010013) [ 0.030798] ACPI: FPDT 0x00000000DE1A4F48 000044 (v01 ALASKA A M I 01072009 AMI 00010013) [ 0.030800] ACPI: MCFG 0x00000000DE1A4F90 00003C (v01 ALASKA A M I 01072009 MSFT 00000097) [ 0.030802] ACPI: SSDT 0x00000000DE1A4FD0 0007E1 (v01 Intel_ AoacTabl 00001000 INTL 20091112) [ 0.030804] ACPI: AAFT 0x00000000DE1A57B8 000112 (v01 ALASKA OEMAAFT 01072009 MSFT 00000097) [ 0.030806] ACPI: HPET 0x00000000DE1A58D0 000038 (v01 ALASKA A M I 01072009 AMI. 00000005) [ 0.030808] ACPI: SSDT 0x00000000DE1A5908 00036D (v01 SataRe SataTabl 00001000 INTL 20091112) [ 0.030811] ACPI: SSDT 0x00000000DE1A5C78 0009AA (v01 PmRef Cpu0Ist 00003000 INTL 20051117) [ 0.030813] ACPI: SSDT 0x00000000DE1A6628 000A92 (v01 PmRef CpuPm 00003000 INTL 20051117) [ 0.030815] ACPI: BGRT 0x00000000DE1A70C0 000038 (v00 ALASKA A M I 01072009 AMI 00010013) [ 0.030822] ACPI: Local APIC address 0xfee00000 [ 0.030892] No NUMA configuration found [ 0.030893] Faking a node at [mem 0x0000000000000000-0x000000021effffff] [ 0.030901] NODE_DATA(0) allocated [mem 0x21efd1000-0x21effafff] [ 0.031211] Zone ranges: [ 0.031211] DMA [mem 0x0000000000001000-0x0000000000ffffff] [ 0.031212] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] [ 0.031213] Normal [mem 0x0000000100000000-0x000000021effffff] [ 0.031214] Device empty [ 0.031214] Movable zone start for each node [ 0.031217] Early memory node ranges [ 0.031217] node 0: [mem 0x0000000000001000-0x000000000009cfff] [ 0.031218] node 0: [mem 0x0000000000100000-0x00000000dd907fff] [ 0.031219] node 0: [mem 0x00000000de08d000-0x00000000de116fff] [ 0.031219] node 0: [mem 0x00000000de9a6000-0x00000000de9a6fff] [ 0.031220] node 0: [mem 0x00000000de9ea000-0x00000000df407fff] [ 0.031220] node 0: [mem 0x00000000df7f1000-0x00000000df7fffff] [ 0.031221] node 0: [mem 0x0000000100000000-0x000000021effffff] [ 0.031310] Zeroed struct page in unavailable ranges: 11428 pages [ 0.031311] Initmem setup node 0 [mem 0x0000000000001000-0x000000021effffff] [ 0.031312] On node 0 totalpages: 2085724 [ 0.031313] DMA zone: 64 pages used for memmap [ 0.031313] DMA zone: 21 pages reserved [ 0.031314] DMA zone: 3996 pages, LIFO batch:0 [ 0.031341] DMA32 zone: 14159 pages used for memmap [ 0.031341] DMA32 zone: 906176 pages, LIFO batch:63 [ 0.042718] Normal zone: 18368 pages used for memmap [ 0.042720] Normal zone: 1175552 pages, LIFO batch:63 [ 0.058107] ACPI: PM-Timer IO Port: 0x408 [ 0.058109] ACPI: Local APIC address 0xfee00000 [ 0.058116] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) [ 0.058126] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 [ 0.058128] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.058129] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [ 0.058130] ACPI: IRQ0 used by override. [ 0.058131] ACPI: IRQ9 used by override. [ 0.058133] Using ACPI (MADT) for SMP configuration information [ 0.058134] ACPI: HPET id: 0x8086a701 base: 0xfed00000 [ 0.058139] TSC deadline timer available [ 0.058140] smpboot: Allowing 4 CPUs, 0 hotplug CPUs [ 0.058155] PM: hibernation: Registered nosave memory: [mem 0x00000000-0x00000fff] [ 0.058157] PM: hibernation: Registered nosave memory: [mem 0x0009d000-0x0009dfff] [ 0.058157] PM: hibernation: Registered nosave memory: [mem 0x0009e000-0x0009ffff] [ 0.058157] PM: hibernation: Registered nosave memory: [mem 0x000a0000-0x000dffff] [ 0.058158] PM: hibernation: Registered nosave memory: [mem 0x000e0000-0x000fffff] [ 0.058159] PM: hibernation: Registered nosave memory: [mem 0xdd908000-0xde08cfff] [ 0.058160] PM: hibernation: Registered nosave memory: [mem 0xde117000-0xde1b6fff] [ 0.058161] PM: hibernation: Registered nosave memory: [mem 0xde1b7000-0xde9a5fff] [ 0.058162] PM: hibernation: Registered nosave memory: [mem 0xde9a7000-0xde9e9fff] [ 0.058163] PM: hibernation: Registered nosave memory: [mem 0xdf408000-0xdf7f0fff] [ 0.058164] PM: hibernation: Registered nosave memory: [mem 0xdf800000-0xf7ffffff] [ 0.058164] PM: hibernation: Registered nosave memory: [mem 0xf8000000-0xfbffffff] [ 0.058165] PM: hibernation: Registered nosave memory: [mem 0xfc000000-0xfebfffff] [ 0.058165] PM: hibernation: Registered nosave memory: [mem 0xfec00000-0xfec00fff] [ 0.058166] PM: hibernation: Registered nosave memory: [mem 0xfec01000-0xfecfffff] [ 0.058166] PM: hibernation: Registered nosave memory: [mem 0xfed00000-0xfed03fff] [ 0.058166] PM: hibernation: Registered nosave memory: [mem 0xfed04000-0xfed1bfff] [ 0.058167] PM: hibernation: Registered nosave memory: [mem 0xfed1c000-0xfed1ffff] [ 0.058167] PM: hibernation: Registered nosave memory: [mem 0xfed20000-0xfedfffff] [ 0.058168] PM: hibernation: Registered nosave memory: [mem 0xfee00000-0xfee00fff] [ 0.058168] PM: hibernation: Registered nosave memory: [mem 0xfee01000-0xfeffffff] [ 0.058168] PM: hibernation: Registered nosave memory: [mem 0xff000000-0xffffffff] [ 0.058170] [mem 0xdf800000-0xf7ffffff] available for PCI devices [ 0.058171] Booting paravirtualized kernel on bare hardware [ 0.058173] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns [ 0.058179] setup_percpu: NR_CPUS:8192 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1 [ 0.058466] percpu: Embedded 56 pages/cpu s192512 r8192 d28672 u524288 [ 0.058471] pcpu-alloc: s192512 r8192 d28672 u524288 alloc=1*2097152 [ 0.058471] pcpu-alloc: [0] 0 1 2 3 [ 0.058495] Built 1 zonelists, mobility grouping on. Total pages: 2053112 [ 0.058495] Policy zone: Normal [ 0.058497] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.8.0-050800rc6-generic root=UUID=833ac3c7-4d08-47b5-807f-9a8ddeb3a8d2 ro quiet splash radeon.si_support=0 amdgpu.si_support=1 vt.handoff=7 [ 0.059394] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear) [ 0.059799] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear) [ 0.059841] mem auto-init: stack:off, heap alloc:on, heap free:off [ 0.098003] Memory: 8041840K/8342896K available (14339K kernel code, 2555K rwdata, 8736K rodata, 2632K init, 4912K bss, 301056K reserved, 0K cma-reserved) [ 0.098010] random: get_random_u64 called from kmem_cache_open+0x2d/0x410 with crng_init=0 [ 0.098116] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [ 0.098128] Kernel/User page tables isolation: enabled [ 0.098144] ftrace: allocating 46071 entries in 180 pages [ 0.111578] ftrace: allocated 180 pages with 4 groups [ 0.111684] rcu: Hierarchical RCU implementation. [ 0.111685] rcu: RCU restricting CPUs from NR_CPUS=8192 to nr_cpu_ids=4. [ 0.111686] Trampoline variant of Tasks RCU enabled. [ 0.111686] Rude variant of Tasks RCU enabled. [ 0.111687] Tracing variant of Tasks RCU enabled. [ 0.111687] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. [ 0.111688] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 [ 0.114400] NR_IRQS: 524544, nr_irqs: 456, preallocated irqs: 16 [ 0.114611] random: crng done (trusting CPU's manufacturer) [ 0.114630] Console: colour dummy device 80x25 [ 0.114634] printk: console [tty0] enabled [ 0.114648] ACPI: Core revision 20200528 [ 0.114745] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484882848 ns [ 0.114755] APIC: Switch to symmetric I/O mode setup [ 0.114825] x2apic: IRQ remapping doesn't support X2APIC mode [ 0.115236] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 [ 0.134755] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x30e65a81c66, max_idle_ns: 440795263477 ns [ 0.134758] Calibrating delay loop (skipped), value calculated using timer frequency.. 6784.85 BogoMIPS (lpj=13569700) [ 0.134760] pid_max: default: 32768 minimum: 301 [ 0.134781] LSM: Security Framework initializing [ 0.134788] Yama: becoming mindful. [ 0.134810] AppArmor: AppArmor initialized [ 0.134854] Mount-cache hash table entries: 16384 (order: 5, 131072 bytes, linear) [ 0.134874] Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes, linear) [ 0.135089] mce: CPU0: Thermal monitoring enabled (TM1) [ 0.135099] process: using mwait in idle threads [ 0.135101] Last level iTLB entries: 4KB 512, 2MB 8, 4MB 8 [ 0.135101] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32, 1GB 0 [ 0.135103] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization [ 0.135104] Spectre V2 : Mitigation: Full generic retpoline [ 0.135105] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch [ 0.135105] Spectre V2 : Enabling Restricted Speculation for firmware calls [ 0.135106] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier [ 0.135107] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl and seccomp [ 0.135109] SRBDS: Vulnerable: No microcode [ 0.135110] MDS: Mitigation: Clear CPU buffers [ 0.135279] Freeing SMP alternatives memory: 40K [ 0.138821] smpboot: CPU0: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz (family: 0x6, model: 0x3a, stepping: 0x9) [ 0.138915] Performance Events: PEBS fmt1+, IvyBridge events, 16-deep LBR, full-width counters, Intel PMU driver. [ 0.138921] ... version: 3 [ 0.138921] ... bit width: 48 [ 0.138922] ... generic registers: 8 [ 0.138922] ... value mask: 0000ffffffffffff [ 0.138922] ... max period: 00007fffffffffff [ 0.138923] ... fixed-purpose events: 3 [ 0.138923] ... event mask: 00000007000000ff [ 0.138953] rcu: Hierarchical SRCU implementation. [ 0.139601] NMI watchdog: Enabled. Permanently consumes one hw-PMU counter. [ 0.139647] smp: Bringing up secondary CPUs ... [ 0.139724] x86: Booting SMP configuration: [ 0.139725] .... node #0, CPUs: #1 #2 #3 [ 0.146807] smp: Brought up 1 node, 4 CPUs [ 0.146807] smpboot: Max logical packages: 1 [ 0.146807] smpboot: Total of 4 processors activated (27139.40 BogoMIPS) [ 0.147882] devtmpfs: initialized [ 0.147882] x86/mm: Memory block size: 128MB [ 0.147882] PM: Registering ACPI NVS region [mem 0xde117000-0xde1b6fff] (655360 bytes) [ 0.147882] PM: Registering ACPI NVS region [mem 0xde9a7000-0xde9e9fff] (274432 bytes) [ 0.147882] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns [ 0.147882] futex hash table entries: 1024 (order: 4, 65536 bytes, linear) [ 0.147882] pinctrl core: initialized pinctrl subsystem [ 0.147882] PM: RTC time: 12:11:09, date: 2020-07-26 [ 0.147882] thermal_sys: Registered thermal governor 'fair_share' [ 0.147882] thermal_sys: Registered thermal governor 'bang_bang' [ 0.147882] thermal_sys: Registered thermal governor 'step_wise' [ 0.147882] thermal_sys: Registered thermal governor 'user_space' [ 0.147882] thermal_sys: Registered thermal governor 'power_allocator' [ 0.147882] NET: Registered protocol family 16 [ 0.147882] DMA: preallocated 1024 KiB GFP_KERNEL pool for atomic allocations [ 0.147882] DMA: preallocated 1024 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations [ 0.147882] DMA: preallocated 1024 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations [ 0.147882] audit: initializing netlink subsys (disabled) [ 0.147882] audit: type=2000 audit(1595765468.032:1): state=initialized audit_enabled=0 res=1 [ 0.147882] EISA bus registered [ 0.147882] cpuidle: using governor ladder [ 0.147882] cpuidle: using governor menu [ 0.147882] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it [ 0.147882] ACPI: bus type PCI registered [ 0.147882] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [ 0.147882] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000) [ 0.147882] PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in E820 [ 0.147882] PCI: Using configuration type 1 for base access [ 0.147882] core: PMU erratum BJ122, BV98, HSD29 workaround disabled, HT off [ 0.147882] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' [ 0.150780] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages [ 0.150835] ACPI: Added _OSI(Module Device) [ 0.150835] ACPI: Added _OSI(Processor Device) [ 0.150836] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.150837] ACPI: Added _OSI(Processor Aggregator Device) [ 0.150837] ACPI: Added _OSI(Linux-Dell-Video) [ 0.150838] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio) [ 0.150839] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics) [ 0.157639] ACPI: 5 ACPI AML tables successfully acquired and loaded [ 0.159283] ACPI: Dynamic OEM Table Load: [ 0.159288] ACPI: SSDT 0xFFFF9176154C7000 00083B (v01 PmRef Cpu0Cst 00003001 INTL 20051117) [ 0.160055] ACPI: Dynamic OEM Table Load: [ 0.160059] ACPI: SSDT 0xFFFF9176154BE000 000303 (v01 PmRef ApIst 00003000 INTL 20051117) [ 0.160633] ACPI: Dynamic OEM Table Load: [ 0.160636] ACPI: SSDT 0xFFFF917615082400 000119 (v01 PmRef ApCst 00003000 INTL 20051117) [ 0.161917] ACPI: Interpreter enabled [ 0.161936] ACPI: (supports S0 S3 S4 S5) [ 0.161937] ACPI: Using IOAPIC for interrupt routing [ 0.162004] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [ 0.162243] ACPI: Enabled 16 GPEs in block 00 to 3F [ 0.167082] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3e]) [ 0.167087] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3] [ 0.167379] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug SHPCHotplug PME LTR] [ 0.167574] acpi PNP0A08:00: _OSC: OS now controls [AER PCIeCapability] [ 0.167574] acpi PNP0A08:00: FADT indicates ASPM is unsupported, using BIOS configuration [ 0.168078] PCI host bridge to bus 0000:00 [ 0.168080] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] [ 0.168081] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] [ 0.168082] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] [ 0.168083] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000d3fff window] [ 0.168083] pci_bus 0000:00: root bus resource [mem 0x000d4000-0x000d7fff window] [ 0.168084] pci_bus 0000:00: root bus resource [mem 0x000d8000-0x000dbfff window] [ 0.168085] pci_bus 0000:00: root bus resource [mem 0x000dc000-0x000dffff window] [ 0.168086] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000e3fff window] [ 0.168087] pci_bus 0000:00: root bus resource [mem 0x000e4000-0x000e7fff window] [ 0.168087] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xfeafffff window] [ 0.168088] pci_bus 0000:00: root bus resource [bus 00-3e] [ 0.168096] pci 0000:00:00.0: [8086:0150] type 00 class 0x060000 [ 0.168183] pci 0000:00:01.0: [8086:0151] type 01 class 0x060400 [ 0.168215] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold [ 0.168321] pci 0000:00:14.0: [8086:1e31] type 00 class 0x0c0330 [ 0.168343] pci 0000:00:14.0: reg 0x10: [mem 0xf7f00000-0xf7f0ffff 64bit] [ 0.168408] pci 0000:00:14.0: PME# supported from D3hot D3cold [ 0.168494] pci 0000:00:16.0: [8086:1e3a] type 00 class 0x078000 [ 0.168517] pci 0000:00:16.0: reg 0x10: [mem 0xf7f1a000-0xf7f1a00f 64bit] [ 0.168585] pci 0000:00:16.0: PME# supported from D0 D3hot D3cold [ 0.168668] pci 0000:00:1a.0: [8086:1e2d] type 00 class 0x0c0320 [ 0.168688] pci 0000:00:1a.0: reg 0x10: [mem 0xf7f18000-0xf7f183ff] [ 0.168767] pci 0000:00:1a.0: PME# supported from D0 D3hot D3cold [ 0.168853] pci 0000:00:1b.0: [8086:1e20] type 00 class 0x040300 [ 0.168872] pci 0000:00:1b.0: reg 0x10: [mem 0xf7f10000-0xf7f13fff 64bit] [ 0.168944] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold [ 0.169037] pci 0000:00:1c.0: [8086:1e10] type 01 class 0x060400 [ 0.169192] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold [ 0.169312] pci 0000:00:1c.4: [8086:244e] type 01 class 0x060401 [ 0.169401] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold [ 0.169496] pci 0000:00:1c.5: [8086:1e1a] type 01 class 0x060400 [ 0.169586] pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold [ 0.169683] pci 0000:00:1c.7: [8086:1e1e] type 01 class 0x060400 [ 0.169773] pci 0000:00:1c.7: PME# supported from D0 D3hot D3cold [ 0.169870] pci 0000:00:1d.0: [8086:1e26] type 00 class 0x0c0320 [ 0.169890] pci 0000:00:1d.0: reg 0x10: [mem 0xf7f17000-0xf7f173ff] [ 0.169969] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold [ 0.170057] pci 0000:00:1f.0: [8086:1e4a] type 00 class 0x060100 [ 0.170234] pci 0000:00:1f.2: [8086:1e02] type 00 class 0x010601 [ 0.170250] pci 0000:00:1f.2: reg 0x10: [io 0xf070-0xf077] [ 0.170256] pci 0000:00:1f.2: reg 0x14: [io 0xf060-0xf063] [ 0.170263] pci 0000:00:1f.2: reg 0x18: [io 0xf050-0xf057] [ 0.170269] pci 0000:00:1f.2: reg 0x1c: [io 0xf040-0xf043] [ 0.170275] pci 0000:00:1f.2: reg 0x20: [io 0xf020-0xf03f] [ 0.170281] pci 0000:00:1f.2: reg 0x24: [mem 0xf7f16000-0xf7f167ff] [ 0.170318] pci 0000:00:1f.2: PME# supported from D3hot [ 0.170397] pci 0000:00:1f.3: [8086:1e22] type 00 class 0x0c0500 [ 0.170413] pci 0000:00:1f.3: reg 0x10: [mem 0xf7f15000-0xf7f150ff 64bit] [ 0.170431] pci 0000:00:1f.3: reg 0x20: [io 0xf000-0xf01f] [ 0.170547] pci 0000:01:00.0: [1002:679a] type 00 class 0x030000 [ 0.170558] pci 0000:01:00.0: reg 0x10: [mem 0xe0000000-0xefffffff 64bit pref] [ 0.170563] pci 0000:01:00.0: reg 0x18: [mem 0xf7e00000-0xf7e3ffff 64bit] [ 0.170567] pci 0000:01:00.0: reg 0x20: [io 0xe000-0xe0ff] [ 0.170573] pci 0000:01:00.0: reg 0x30: [mem 0xf7e40000-0xf7e5ffff pref] [ 0.170576] pci 0000:01:00.0: enabling Extended Tags [ 0.170602] pci 0000:01:00.0: supports D1 D2 [ 0.170603] pci 0000:01:00.0: PME# supported from D1 D2 D3hot [ 0.170651] pci 0000:01:00.1: [1002:aaa0] type 00 class 0x040300 [ 0.170661] pci 0000:01:00.1: reg 0x10: [mem 0xf7e60000-0xf7e63fff 64bit] [ 0.170677] pci 0000:01:00.1: enabling Extended Tags [ 0.170699] pci 0000:01:00.1: supports D1 D2 [ 0.170743] pci 0000:00:01.0: PCI bridge to [bus 01] [ 0.170744] pci 0000:00:01.0: bridge window [io 0xe000-0xefff] [ 0.170746] pci 0000:00:01.0: bridge window [mem 0xf7e00000-0xf7efffff] [ 0.170748] pci 0000:00:01.0: bridge window [mem 0xe0000000-0xefffffff 64bit pref] [ 0.174800] pci 0000:00:1c.0: PCI bridge to [bus 02] [ 0.174868] pci 0000:03:00.0: [1b21:1080] type 01 class 0x060401 [ 0.175050] pci 0000:00:1c.4: PCI bridge to [bus 03-04] (subtractive decode) [ 0.175059] pci 0000:00:1c.4: bridge window [io 0x0000-0x0cf7 window] (subtractive decode) [ 0.175060] pci 0000:00:1c.4: bridge window [io 0x0d00-0xffff window] (subtractive decode) [ 0.175061] pci 0000:00:1c.4: bridge window [mem 0x000a0000-0x000bffff window] (subtractive decode) [ 0.175062] pci 0000:00:1c.4: bridge window [mem 0x000d0000-0x000d3fff window] (subtractive decode) [ 0.175063] pci 0000:00:1c.4: bridge window [mem 0x000d4000-0x000d7fff window] (subtractive decode) [ 0.175063] pci 0000:00:1c.4: bridge window [mem 0x000d8000-0x000dbfff window] (subtractive decode) [ 0.175065] pci 0000:00:1c.4: bridge window [mem 0x000dc000-0x000dffff window] (subtractive decode) [ 0.175066] pci 0000:00:1c.4: bridge window [mem 0x000e0000-0x000e3fff window] (subtractive decode) [ 0.175067] pci 0000:00:1c.4: bridge window [mem 0x000e4000-0x000e7fff window] (subtractive decode) [ 0.175068] pci 0000:00:1c.4: bridge window [mem 0xe0000000-0xfeafffff window] (subtractive decode) [ 0.175102] pci_bus 0000:04: extended config space not accessible [ 0.175181] pci 0000:03:00.0: PCI bridge to [bus 04] (subtractive decode) [ 0.175201] pci 0000:03:00.0: bridge window [io 0x0000-0x0cf7 window] (subtractive decode) [ 0.175202] pci 0000:03:00.0: bridge window [io 0x0d00-0xffff window] (subtractive decode) [ 0.175203] pci 0000:03:00.0: bridge window [mem 0x000a0000-0x000bffff window] (subtractive decode) [ 0.175204] pci 0000:03:00.0: bridge window [mem 0x000d0000-0x000d3fff window] (subtractive decode) [ 0.175204] pci 0000:03:00.0: bridge window [mem 0x000d4000-0x000d7fff window] (subtractive decode) [ 0.175205] pci 0000:03:00.0: bridge window [mem 0x000d8000-0x000dbfff window] (subtractive decode) [ 0.175206] pci 0000:03:00.0: bridge window [mem 0x000dc000-0x000dffff window] (subtractive decode) [ 0.175207] pci 0000:03:00.0: bridge window [mem 0x000e0000-0x000e3fff window] (subtractive decode) [ 0.175208] pci 0000:03:00.0: bridge window [mem 0x000e4000-0x000e7fff window] (subtractive decode) [ 0.175208] pci 0000:03:00.0: bridge window [mem 0xe0000000-0xfeafffff window] (subtractive decode) [ 0.175270] pci 0000:05:00.0: [10ec:8168] type 00 class 0x020000 [ 0.175303] pci 0000:05:00.0: reg 0x10: [io 0xd000-0xd0ff] [ 0.175335] pci 0000:05:00.0: reg 0x18: [mem 0xf0004000-0xf0004fff 64bit pref] [ 0.175354] pci 0000:05:00.0: reg 0x20: [mem 0xf0000000-0xf0003fff 64bit pref] [ 0.175479] pci 0000:05:00.0: supports D1 D2 [ 0.175480] pci 0000:05:00.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.175606] pci 0000:00:1c.5: PCI bridge to [bus 05] [ 0.175609] pci 0000:00:1c.5: bridge window [io 0xd000-0xdfff] [ 0.175616] pci 0000:00:1c.5: bridge window [mem 0xf0000000-0xf00fffff 64bit pref] [ 0.175666] pci 0000:06:00.0: [1b21:0612] type 00 class 0x010601 [ 0.175694] pci 0000:06:00.0: reg 0x10: [io 0xc050-0xc057] [ 0.175707] pci 0000:06:00.0: reg 0x14: [io 0xc040-0xc043] [ 0.175719] pci 0000:06:00.0: reg 0x18: [io 0xc030-0xc037] [ 0.175731] pci 0000:06:00.0: reg 0x1c: [io 0xc020-0xc023] [ 0.175743] pci 0000:06:00.0: reg 0x20: [io 0xc000-0xc01f] [ 0.175756] pci 0000:06:00.0: reg 0x24: [mem 0xf7d00000-0xf7d001ff] [ 0.175931] pci 0000:00:1c.7: PCI bridge to [bus 06] [ 0.175933] pci 0000:00:1c.7: bridge window [io 0xc000-0xcfff] [ 0.175936] pci 0000:00:1c.7: bridge window [mem 0xf7d00000-0xf7dfffff] [ 0.176585] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 *11 12 14 15) [ 0.176646] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 *10 11 12 14 15) [ 0.176705] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 *10 11 12 14 15) [ 0.176763] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 10 11 12 14 15) [ 0.176822] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled. [ 0.176880] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled. [ 0.176938] ACPI: PCI Interrupt Link [LNKG] (IRQs *3 4 5 6 10 11 12 14 15) [ 0.176998] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 10 *11 12 14 15) [ 0.177169] iommu: Default domain type: Translated [ 0.177169] pci 0000:01:00.0: vgaarb: setting as boot VGA device [ 0.177169] pci 0000:01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none [ 0.177169] pci 0000:01:00.0: vgaarb: bridge control possible [ 0.177169] vgaarb: loaded [ 0.177169] SCSI subsystem initialized [ 0.177169] libata version 3.00 loaded. [ 0.177169] ACPI: bus type USB registered [ 0.177169] usbcore: registered new interface driver usbfs [ 0.177169] usbcore: registered new interface driver hub [ 0.177169] usbcore: registered new device driver usb [ 0.177169] pps_core: LinuxPPS API ver. 1 registered [ 0.177169] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> [ 0.177169] PTP clock support registered [ 0.177169] EDAC MC: Ver: 3.0.0 [ 0.177169] NetLabel: Initializing [ 0.177169] NetLabel: domain hash size = 128 [ 0.177169] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO [ 0.177169] NetLabel: unlabeled traffic allowed by default [ 0.177169] PCI: Using ACPI for IRQ routing [ 0.179063] PCI: pci_cache_line_size set to 64 bytes [ 0.179109] e820: reserve RAM buffer [mem 0x0009d800-0x0009ffff] [ 0.179109] e820: reserve RAM buffer [mem 0xdd908000-0xdfffffff] [ 0.179110] e820: reserve RAM buffer [mem 0xde117000-0xdfffffff] [ 0.179111] e820: reserve RAM buffer [mem 0xde9a7000-0xdfffffff] [ 0.179112] e820: reserve RAM buffer [mem 0xdf408000-0xdfffffff] [ 0.179112] e820: reserve RAM buffer [mem 0xdf800000-0xdfffffff] [ 0.179113] e820: reserve RAM buffer [mem 0x21f000000-0x21fffffff] [ 0.179338] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0 [ 0.179340] hpet0: 8 comparators, 64-bit 14.318180 MHz counter [ 0.181360] clocksource: Switched to clocksource tsc-early [ 0.190211] VFS: Disk quotas dquot_6.6.0 [ 0.190224] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 0.190309] AppArmor: AppArmor Filesystem Enabled [ 0.190331] pnp: PnP ACPI init [ 0.190448] system 00:00: [mem 0xfed40000-0xfed44fff] has been reserved [ 0.190452] system 00:00: Plug and Play ACPI device, IDs PNP0c01 (active) [ 0.190536] system 00:01: [io 0x0680-0x069f] has been reserved [ 0.190537] system 00:01: [io 0x1000-0x100f] has been reserved [ 0.190538] system 00:01: [io 0xffff] has been reserved [ 0.190539] system 00:01: [io 0xffff] has been reserved [ 0.190540] system 00:01: [io 0x0400-0x0453] has been reserved [ 0.190541] system 00:01: [io 0x0458-0x047f] has been reserved [ 0.190543] system 00:01: [io 0x0500-0x057f] has been reserved [ 0.190544] system 00:01: [io 0x164e-0x164f] has been reserved [ 0.190546] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.190567] pnp 00:02: Plug and Play ACPI device, IDs PNP0b00 (active) [ 0.190613] system 00:03: [io 0x0454-0x0457] has been reserved [ 0.190616] system 00:03: Plug and Play ACPI device, IDs INT3f0d PNP0c02 (active) [ 0.190699] system 00:04: [io 0x0290-0x029f] has been reserved [ 0.190701] system 00:04: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.190931] system 00:05: [io 0x04d0-0x04d1] has been reserved [ 0.190934] system 00:05: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.190972] pnp 00:06: Plug and Play ACPI device, IDs PNP0303 PNP030b (active) [ 0.191125] pnp 00:07: [dma 0 disabled] [ 0.191160] pnp 00:07: Plug and Play ACPI device, IDs PNP0501 (active) [ 0.191391] system 00:08: [mem 0xfed1c000-0xfed1ffff] has been reserved [ 0.191392] system 00:08: [mem 0xfed10000-0xfed17fff] has been reserved [ 0.191393] system 00:08: [mem 0xfed18000-0xfed18fff] has been reserved [ 0.191394] system 00:08: [mem 0xfed19000-0xfed19fff] has been reserved [ 0.191395] system 00:08: [mem 0xf8000000-0xfbffffff] has been reserved [ 0.191396] system 00:08: [mem 0xfed20000-0xfed3ffff] has been reserved [ 0.191397] system 00:08: [mem 0xfed90000-0xfed93fff] has been reserved [ 0.191398] system 00:08: [mem 0xfed45000-0xfed8ffff] has been reserved [ 0.191399] system 00:08: [mem 0xff000000-0xffffffff] has been reserved [ 0.191400] system 00:08: [mem 0xfee00000-0xfeefffff] could not be reserved [ 0.191401] system 00:08: [mem 0xf0100000-0xf0100fff] has been reserved [ 0.191403] system 00:08: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.191561] pnp: PnP ACPI: found 9 devices [ 0.197011] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns [ 0.197057] NET: Registered protocol family 2 [ 0.197198] tcp_listen_portaddr_hash hash table entries: 4096 (order: 4, 65536 bytes, linear) [ 0.197256] TCP established hash table entries: 65536 (order: 7, 524288 bytes, linear) [ 0.197413] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes, linear) [ 0.197478] TCP: Hash tables configured (established 65536 bind 65536) [ 0.197550] UDP hash table entries: 4096 (order: 5, 131072 bytes, linear) [ 0.197573] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes, linear) [ 0.197615] NET: Registered protocol family 1 [ 0.197619] NET: Registered protocol family 44 [ 0.197629] pci 0000:00:01.0: PCI bridge to [bus 01] [ 0.197631] pci 0000:00:01.0: bridge window [io 0xe000-0xefff] [ 0.197633] pci 0000:00:01.0: bridge window [mem 0xf7e00000-0xf7efffff] [ 0.197635] pci 0000:00:01.0: bridge window [mem 0xe0000000-0xefffffff 64bit pref] [ 0.197637] pci 0000:00:1c.0: PCI bridge to [bus 02] [ 0.197654] pci 0000:03:00.0: PCI bridge to [bus 04] [ 0.197672] pci 0000:00:1c.4: PCI bridge to [bus 03-04] [ 0.197682] pci 0000:00:1c.5: PCI bridge to [bus 05] [ 0.197683] pci 0000:00:1c.5: bridge window [io 0xd000-0xdfff] [ 0.197689] pci 0000:00:1c.5: bridge window [mem 0xf0000000-0xf00fffff 64bit pref] [ 0.197694] pci 0000:00:1c.7: PCI bridge to [bus 06] [ 0.197695] pci 0000:00:1c.7: bridge window [io 0xc000-0xcfff] [ 0.197699] pci 0000:00:1c.7: bridge window [mem 0xf7d00000-0xf7dfffff] [ 0.197706] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7 window] [ 0.197707] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff window] [ 0.197708] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window] [ 0.197709] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000d3fff window] [ 0.197710] pci_bus 0000:00: resource 8 [mem 0x000d4000-0x000d7fff window] [ 0.197711] pci_bus 0000:00: resource 9 [mem 0x000d8000-0x000dbfff window] [ 0.197712] pci_bus 0000:00: resource 10 [mem 0x000dc000-0x000dffff window] [ 0.197712] pci_bus 0000:00: resource 11 [mem 0x000e0000-0x000e3fff window] [ 0.197713] pci_bus 0000:00: resource 12 [mem 0x000e4000-0x000e7fff window] [ 0.197714] pci_bus 0000:00: resource 13 [mem 0xe0000000-0xfeafffff window] [ 0.197715] pci_bus 0000:01: resource 0 [io 0xe000-0xefff] [ 0.197716] pci_bus 0000:01: resource 1 [mem 0xf7e00000-0xf7efffff] [ 0.197716] pci_bus 0000:01: resource 2 [mem 0xe0000000-0xefffffff 64bit pref] [ 0.197718] pci_bus 0000:03: resource 4 [io 0x0000-0x0cf7 window] [ 0.197718] pci_bus 0000:03: resource 5 [io 0x0d00-0xffff window] [ 0.197719] pci_bus 0000:03: resource 6 [mem 0x000a0000-0x000bffff window] [ 0.197720] pci_bus 0000:03: resource 7 [mem 0x000d0000-0x000d3fff window] [ 0.197721] pci_bus 0000:03: resource 8 [mem 0x000d4000-0x000d7fff window] [ 0.197722] pci_bus 0000:03: resource 9 [mem 0x000d8000-0x000dbfff window] [ 0.197722] pci_bus 0000:03: resource 10 [mem 0x000dc000-0x000dffff window] [ 0.197723] pci_bus 0000:03: resource 11 [mem 0x000e0000-0x000e3fff window] [ 0.197724] pci_bus 0000:03: resource 12 [mem 0x000e4000-0x000e7fff window] [ 0.197725] pci_bus 0000:03: resource 13 [mem 0xe0000000-0xfeafffff window] [ 0.197726] pci_bus 0000:04: resource 4 [io 0x0000-0x0cf7 window] [ 0.197726] pci_bus 0000:04: resource 5 [io 0x0d00-0xffff window] [ 0.197727] pci_bus 0000:04: resource 6 [mem 0x000a0000-0x000bffff window] [ 0.197728] pci_bus 0000:04: resource 7 [mem 0x000d0000-0x000d3fff window] [ 0.197729] pci_bus 0000:04: resource 8 [mem 0x000d4000-0x000d7fff window] [ 0.197730] pci_bus 0000:04: resource 9 [mem 0x000d8000-0x000dbfff window] [ 0.197730] pci_bus 0000:04: resource 10 [mem 0x000dc000-0x000dffff window] [ 0.197731] pci_bus 0000:04: resource 11 [mem 0x000e0000-0x000e3fff window] [ 0.197732] pci_bus 0000:04: resource 12 [mem 0x000e4000-0x000e7fff window] [ 0.197733] pci_bus 0000:04: resource 13 [mem 0xe0000000-0xfeafffff window] [ 0.197734] pci_bus 0000:05: resource 0 [io 0xd000-0xdfff] [ 0.197735] pci_bus 0000:05: resource 2 [mem 0xf0000000-0xf00fffff 64bit pref] [ 0.197735] pci_bus 0000:06: resource 0 [io 0xc000-0xcfff] [ 0.197736] pci_bus 0000:06: resource 1 [mem 0xf7d00000-0xf7dfffff] [ 0.222890] pci 0000:00:1a.0: quirk_usb_early_handoff+0x0/0x662 took 24314 usecs [ 0.246886] pci 0000:00:1d.0: quirk_usb_early_handoff+0x0/0x662 took 23419 usecs [ 0.246898] pci 0000:01:00.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff] [ 0.246903] pci 0000:01:00.1: D0 power state depends on 0000:01:00.0 [ 0.246910] pci 0000:03:00.0: CLS mismatch (64 != 32), using 64 bytes [ 0.246965] Trying to unpack rootfs image as initramfs... [ 0.364777] Freeing initrd memory: 53636K [ 0.364812] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) [ 0.364814] software IO TLB: mapped [mem 0xd6600000-0xda600000] (64MB) [ 0.365043] check: Scanning for low memory corruption every 60 seconds [ 0.365380] Initialise system trusted keyrings [ 0.365388] Key type blacklist registered [ 0.365410] workingset: timestamp_bits=36 max_order=21 bucket_order=0 [ 0.366383] zbud: loaded [ 0.366576] squashfs: version 4.0 (2009/01/31) Phillip Lougher [ 0.366695] fuse: init (API version 7.31) [ 0.366801] integrity: Platform Keyring initialized [ 0.375417] Key type asymmetric registered [ 0.375418] Asymmetric key parser 'x509' registered [ 0.375424] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 244) [ 0.375457] io scheduler mq-deadline registered [ 0.376279] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [ 0.376316] vesafb: mode is 1280x1024x32, linelength=5120, pages=0 [ 0.376317] vesafb: scrolling: redraw [ 0.376318] vesafb: Truecolor: size=0:8:8:8, shift=0:16:8:0 [ 0.376332] vesafb: framebuffer at 0xe0000000, mapped to 0x0000000076879528, using 5120k, total 5120k [ 0.376360] fbcon: Deferring console take-over [ 0.376361] fb0: VESA VGA frame buffer device [ 0.376369] intel_idle: MWAIT substates: 0x1120 [ 0.376370] intel_idle: v0.5.1 model 0x3A [ 0.376490] intel_idle: Local APIC timer is reliable in all C-states [ 0.376584] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0 [ 0.376600] ACPI: Power Button [PWRB] [ 0.376625] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 [ 0.376649] ACPI: Power Button [PWRF] [ 0.376964] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 0.397473] 00:07: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A [ 0.399205] Linux agpgart interface v0.103 [ 0.401124] loop: module loaded [ 0.401322] libphy: Fixed MDIO Bus: probed [ 0.401323] tun: Universal TUN/TAP device driver, 1.6 [ 0.401342] PPP generic driver version 2.4.2 [ 0.401375] VFIO - User Level meta-driver version: 0.3 [ 0.401445] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 0.401447] ehci-pci: EHCI PCI platform driver [ 0.401544] ehci-pci 0000:00:1a.0: EHCI Host Controller [ 0.401548] ehci-pci 0000:00:1a.0: new USB bus registered, assigned bus number 1 [ 0.401558] ehci-pci 0000:00:1a.0: debug port 2 [ 0.405470] ehci-pci 0000:00:1a.0: cache line size of 64 is not supported [ 0.405481] ehci-pci 0000:00:1a.0: irq 16, io mem 0xf7f18000 [ 0.418782] ehci-pci 0000:00:1a.0: USB 2.0 started, EHCI 1.00 [ 0.418858] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.08 [ 0.418859] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 0.418860] usb usb1: Product: EHCI Host Controller [ 0.418861] usb usb1: Manufacturer: Linux 5.8.0-050800rc6-generic ehci_hcd [ 0.418861] usb usb1: SerialNumber: 0000:00:1a.0 [ 0.419022] hub 1-0:1.0: USB hub found [ 0.419029] hub 1-0:1.0: 2 ports detected [ 0.419235] ehci-pci 0000:00:1d.0: EHCI Host Controller [ 0.419238] ehci-pci 0000:00:1d.0: new USB bus registered, assigned bus number 2 [ 0.419247] ehci-pci 0000:00:1d.0: debug port 2 [ 0.423140] ehci-pci 0000:00:1d.0: cache line size of 64 is not supported [ 0.423147] ehci-pci 0000:00:1d.0: irq 23, io mem 0xf7f17000 [ 0.438781] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00 [ 0.438850] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.08 [ 0.438851] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 0.438852] usb usb2: Product: EHCI Host Controller [ 0.438853] usb usb2: Manufacturer: Linux 5.8.0-050800rc6-generic ehci_hcd [ 0.438854] usb usb2: SerialNumber: 0000:00:1d.0 [ 0.439011] hub 2-0:1.0: USB hub found [ 0.439017] hub 2-0:1.0: 2 ports detected [ 0.439137] ehci-platform: EHCI generic platform driver [ 0.439143] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 0.439146] ohci-pci: OHCI PCI platform driver [ 0.439153] ohci-platform: OHCI generic platform driver [ 0.439157] uhci_hcd: USB Universal Host Controller Interface driver [ 0.439197] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1 [ 0.439197] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp [ 0.439680] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 0.439888] mousedev: PS/2 mouse device common for all mice [ 0.440215] rtc_cmos 00:02: RTC can wake from S4 [ 0.440407] rtc_cmos 00:02: registered as rtc0 [ 0.440466] rtc_cmos 00:02: setting system clock to 2020-07-26T12:11:09 UTC (1595765469) [ 0.440478] rtc_cmos 00:02: alarms up to one month, y3k, 242 bytes nvram, hpet irqs [ 0.440483] i2c /dev entries driver [ 0.440513] device-mapper: uevent: version 1.0.3 [ 0.440556] device-mapper: ioctl: 4.42.0-ioctl (2020-02-27) initialised: dm-devel@redhat.com [ 0.440571] platform eisa.0: Probing EISA bus 0 [ 0.440572] platform eisa.0: EISA: Cannot allocate resource for mainboard [ 0.440573] platform eisa.0: Cannot allocate resource for EISA slot 1 [ 0.440574] platform eisa.0: Cannot allocate resource for EISA slot 2 [ 0.440574] platform eisa.0: Cannot allocate resource for EISA slot 3 [ 0.440575] platform eisa.0: Cannot allocate resource for EISA slot 4 [ 0.440576] platform eisa.0: Cannot allocate resource for EISA slot 5 [ 0.440577] platform eisa.0: Cannot allocate resource for EISA slot 6 [ 0.440577] platform eisa.0: Cannot allocate resource for EISA slot 7 [ 0.440578] platform eisa.0: Cannot allocate resource for EISA slot 8 [ 0.440579] platform eisa.0: EISA: Detected 0 cards [ 0.440583] intel_pstate: Intel P-state driver initializing [ 0.440811] ledtrig-cpu: registered to indicate activity on CPUs [ 0.440850] drop_monitor: Initializing network drop monitor service [ 0.440988] NET: Registered protocol family 10 [ 0.446148] Segment Routing with IPv6 [ 0.446163] NET: Registered protocol family 17 [ 0.446230] Key type dns_resolver registered [ 0.446481] microcode: sig=0x306a9, pf=0x2, revision=0x21 [ 0.446529] microcode: Microcode Update Driver: v2.2. [ 0.446532] IPI shorthand broadcast: enabled [ 0.446537] sched_clock: Marking stable (446362121, 164421)->(452023091, -5496549) [ 0.446596] registered taskstats version 1 [ 0.446605] Loading compiled-in X.509 certificates [ 0.447191] Loaded X.509 cert 'Build time autogenerated kernel key: f5ed095bb538b9d2a07de73aa8b3b326e45d53f0' [ 0.447219] zswap: loaded using pool lzo/zbud [ 0.447327] Key type ._fscrypt registered [ 0.447328] Key type .fscrypt registered [ 0.447328] Key type fscrypt-provisioning registered [ 0.449435] Key type encrypted registered [ 0.449437] AppArmor: AppArmor sha1 policy hashing enabled [ 0.449442] ima: No TPM chip found, activating TPM-bypass! [ 0.449445] ima: Allocated hash algorithm: sha1 [ 0.449452] ima: No architecture policies found [ 0.449462] evm: Initialising EVM extended attributes: [ 0.449462] evm: security.selinux [ 0.449463] evm: security.SMACK64 [ 0.449463] evm: security.SMACK64EXEC [ 0.449463] evm: security.SMACK64TRANSMUTE [ 0.449464] evm: security.SMACK64MMAP [ 0.449464] evm: security.apparmor [ 0.449464] evm: security.ima [ 0.449464] evm: security.capability [ 0.449465] evm: HMAC attrs: 0x1 [ 0.449711] PM: Magic number: 12:847:178 [ 0.449746] acpi device:0e: hash matches [ 0.449762] platform: hash matches [ 0.449851] RAS: Correctable Errors collector initialized. [ 0.450788] Freeing unused decrypted memory: 2040K [ 0.451226] Freeing unused kernel image (initmem) memory: 2632K [ 0.464247] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2 [ 0.470785] Write protecting the kernel read-only data: 26624k [ 0.471421] Freeing unused kernel image (text/rodata gap) memory: 2044K [ 0.471711] Freeing unused kernel image (rodata/data gap) memory: 1504K [ 0.511328] x86/mm: Checked W+X mappings: passed, no W+X pages found. [ 0.511329] x86/mm: Checking user space page tables [ 0.550008] x86/mm: Checked W+X mappings: passed, no W+X pages found. [ 0.550011] Run /init as init process [ 0.550012] with arguments: [ 0.550012] /init [ 0.550013] splash [ 0.550013] with environment: [ 0.550014] HOME=/ [ 0.550014] TERM=linux [ 0.550014] BOOT_IMAGE=/boot/vmlinuz-5.8.0-050800rc6-generic [ 0.616201] xhci_hcd 0000:00:14.0: xHCI Host Controller [ 0.616206] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 3 [ 0.617408] xhci_hcd 0000:00:14.0: hcc params 0x20007181 hci version 0x100 quirks 0x000000000000b930 [ 0.617412] xhci_hcd 0000:00:14.0: cache line size of 64 is not supported [ 0.617453] ACPI Warning: SystemIO range 0x0000000000000428-0x000000000000042F conflicts with OpRegion 0x0000000000000400-0x000000000000047F (\PMIO) (20200528/utaddress-204) [ 0.617458] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 0.617460] ACPI Warning: SystemIO range 0x0000000000000540-0x000000000000054F conflicts with OpRegion 0x0000000000000500-0x000000000000057F (\GPR2) (20200528/utaddress-204) [ 0.617463] ACPI Warning: SystemIO range 0x0000000000000540-0x000000000000054F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20200528/utaddress-204) [ 0.617465] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 0.617465] ACPI Warning: SystemIO range 0x0000000000000530-0x000000000000053F conflicts with OpRegion 0x0000000000000500-0x000000000000057F (\GPR2) (20200528/utaddress-204) [ 0.617467] ACPI Warning: SystemIO range 0x0000000000000530-0x000000000000053F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20200528/utaddress-204) [ 0.617469] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 0.617469] ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x000000000000057F (\GPR2) (20200528/utaddress-204) [ 0.617471] ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20200528/utaddress-204) [ 0.617473] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 0.617473] lpc_ich: Resource conflict(s) found affecting gpio_ich [ 0.617550] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.08 [ 0.617551] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 0.617551] usb usb3: Product: xHCI Host Controller [ 0.617552] usb usb3: Manufacturer: Linux 5.8.0-050800rc6-generic xhci-hcd [ 0.617553] usb usb3: SerialNumber: 0000:00:14.0 [ 0.619611] ahci 0000:00:1f.2: version 3.0 [ 0.619698] r8169 0000:05:00.0: can't disable ASPM; OS doesn't have ASPM control [ 0.619813] hub 3-0:1.0: USB hub found [ 0.620778] hub 3-0:1.0: 4 ports detected [ 0.630937] ahci 0000:00:1f.2: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f impl SATA mode [ 0.630939] ahci 0000:00:1f.2: flags: 64bit ncq pm led clo pio slum part ems apst [ 0.636087] i801_smbus 0000:00:1f.3: SMBus using PCI interrupt [ 0.636977] xhci_hcd 0000:00:14.0: xHCI Host Controller [ 0.636980] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 4 [ 0.636982] xhci_hcd 0000:00:14.0: Host supports USB 3.0 SuperSpeed [ 0.637007] i2c i2c-0: 2/4 memory slots populated (from DMI) [ 0.637019] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.08 [ 0.637020] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 0.637021] usb usb4: Product: xHCI Host Controller [ 0.637021] usb usb4: Manufacturer: Linux 5.8.0-050800rc6-generic xhci-hcd [ 0.637022] usb usb4: SerialNumber: 0000:00:14.0 [ 0.637102] hub 4-0:1.0: USB hub found [ 0.637109] hub 4-0:1.0: 4 ports detected [ 0.637356] i2c i2c-0: Successfully instantiated SPD at 0x50 [ 0.637656] i2c i2c-0: Successfully instantiated SPD at 0x51 [ 0.650843] libphy: r8169: probed [ 0.659022] r8169 0000:05:00.0 eth0: RTL8168evl/8111evl, bc:5f:f4:99:82:b4, XID 2c9, IRQ 31 [ 0.659023] r8169 0000:05:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko] [ 0.695313] scsi host0: ahci [ 0.695501] scsi host1: ahci [ 0.695605] scsi host2: ahci [ 0.695702] scsi host3: ahci [ 0.695832] scsi host4: ahci [ 0.695947] scsi host5: ahci [ 0.695978] ata1: SATA max UDMA/133 abar m2048@0xf7f16000 port 0xf7f16100 irq 30 [ 0.695979] ata2: SATA max UDMA/133 abar m2048@0xf7f16000 port 0xf7f16180 irq 30 [ 0.695981] ata3: SATA max UDMA/133 abar m2048@0xf7f16000 port 0xf7f16200 irq 30 [ 0.695982] ata4: SATA max UDMA/133 abar m2048@0xf7f16000 port 0xf7f16280 irq 30 [ 0.695983] ata5: SATA max UDMA/133 abar m2048@0xf7f16000 port 0xf7f16300 irq 30 [ 0.695984] ata6: SATA max UDMA/133 abar m2048@0xf7f16000 port 0xf7f16380 irq 30 [ 0.696142] ahci 0000:06:00.0: SSS flag set, parallel bus scan disabled [ 0.696180] ahci 0000:06:00.0: AHCI 0001.0200 32 slots 2 ports 6 Gbps 0x3 impl SATA mode [ 0.696181] ahci 0000:06:00.0: flags: 64bit ncq sntf stag led clo pmp pio slum part ccc sxs [ 0.696361] scsi host6: ahci [ 0.696415] scsi host7: ahci [ 0.696446] ata7: SATA max UDMA/133 abar m512@0xf7d00000 port 0xf7d00100 irq 32 [ 0.696448] ata8: SATA max UDMA/133 abar m512@0xf7d00000 port 0xf7d00180 irq 32 [ 0.754782] usb 1-1: new high-speed USB device number 2 using ehci-pci [ 0.774790] usb 2-1: new high-speed USB device number 2 using ehci-pci [ 0.911507] usb 1-1: New USB device found, idVendor=8087, idProduct=0024, bcdDevice= 0.00 [ 0.911508] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 0.911849] hub 1-1:1.0: USB hub found [ 0.912053] hub 1-1:1.0: 6 ports detected [ 0.931162] usb 2-1: New USB device found, idVendor=8087, idProduct=0024, bcdDevice= 0.00 [ 0.931165] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 0.931557] hub 2-1:1.0: USB hub found [ 0.931651] hub 2-1:1.0: 8 ports detected [ 1.010804] ata7: SATA link down (SStatus 0 SControl 300) [ 1.010808] ata6: SATA link down (SStatus 0 SControl 300) [ 1.010836] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 1.010857] ata5: SATA link down (SStatus 0 SControl 300) [ 1.010883] ata2: SATA link down (SStatus 0 SControl 300) [ 1.010895] ata1: SATA link down (SStatus 0 SControl 300) [ 1.010908] ata4: SATA link down (SStatus 0 SControl 300) [ 1.012014] ata3.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded [ 1.012018] ata3.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out [ 1.012020] ata3.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out [ 1.047436] ata3.00: ATA-7: ST3360320AS, 3.AAM, max UDMA/133 [ 1.047437] ata3.00: 703282608 sectors, multi 16: LBA48 NCQ (depth 32) [ 1.073177] ata3.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded [ 1.073180] ata3.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out [ 1.073183] ata3.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out [ 1.105743] ata3.00: configured for UDMA/133 [ 1.105861] scsi 2:0:0:0: Direct-Access ATA ST3360320AS M PQ: 0 ANSI: 5 [ 1.106002] sd 2:0:0:0: Attached scsi generic sg0 type 0 [ 1.106029] sd 2:0:0:0: [sda] 703282608 512-byte logical blocks: (360 GB/335 GiB) [ 1.106036] sd 2:0:0:0: [sda] Write Protect is off [ 1.106037] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 1.106050] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 1.173751] sda: sda1 sda2 [ 1.174077] sd 2:0:0:0: [sda] Attached SCSI disk [ 1.178771] usb 1-1.5: new low-speed USB device number 3 using ehci-pci [ 1.302266] usb 1-1.5: New USB device found, idVendor=045e, idProduct=0040, bcdDevice= 1.21 [ 1.302269] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 1.302279] usb 1-1.5: Product: Microsoft Wheel Mouse Optical® [ 1.302280] usb 1-1.5: Manufacturer: Microsoft [ 1.306529] hid: raw HID events driver (C) Jiri Kosina [ 1.313170] usbcore: registered new interface driver usbhid [ 1.313170] usbhid: USB HID core driver [ 1.315148] input: Microsoft Microsoft Wheel Mouse Optical® as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5:1.0/0003:045E:0040.0001/input/input3 [ 1.315224] hid-generic 0003:045E:0040.0001: input,hidraw0: USB HID v1.00 Mouse [Microsoft Microsoft Wheel Mouse Optical®] on usb-0000:00:1a.0-1.5/input0 [ 1.366782] tsc: Refined TSC clocksource calibration: 3392.293 MHz [ 1.366789] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x30e5de2a436, max_idle_ns: 440795285127 ns [ 1.366901] clocksource: Switched to clocksource tsc [ 1.382775] usb 1-1.6: new high-speed USB device number 4 using ehci-pci [ 1.405193] ata8: SATA link down (SStatus 0 SControl 300) [ 1.493243] usb 1-1.6: New USB device found, idVendor=05e3, idProduct=0605, bcdDevice= 6.0b [ 1.493244] usb 1-1.6: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 1.493245] usb 1-1.6: Product: USB2.0 Hub [ 1.493691] hub 1-1.6:1.0: USB hub found [ 1.494115] hub 1-1.6:1.0: 4 ports detected [ 2.119687] fbcon: Taking over console [ 2.119758] Console: switching to colour frame buffer device 160x64 [ 2.192425] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) [ 4.153346] systemd[1]: Inserted module 'autofs4' [ 4.317155] systemd[1]: systemd 245.4-4ubuntu3.2 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid) [ 4.334876] systemd[1]: Detected architecture x86-64. [ 4.360873] systemd[1]: Set hostname to <utente-desktop>. [ 7.546847] systemd[1]: /lib/systemd/system/dbus.socket:5: ListenStream= references a path below legacy directory /var/run/, updating /var/run/dbus/system_bus_socket → /run/dbus/system_bus_socket; please update the unit file accordingly. [ 8.593193] systemd[1]: Created slice Virtual Machine and Container Slice. [ 8.593492] systemd[1]: Created slice system-modprobe.slice. [ 8.593642] systemd[1]: Created slice User and Session Slice. [ 8.593690] systemd[1]: Started Forward Password Requests to Wall Directory Watch. [ 8.593823] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point. [ 8.593856] systemd[1]: Reached target User and Group Name Lookups. [ 8.593866] systemd[1]: Reached target Remote File Systems. [ 8.593872] systemd[1]: Reached target Slices. [ 8.593888] systemd[1]: Reached target Libvirt guests shutdown. [ 8.593938] systemd[1]: Listening on Device-mapper event daemon FIFOs. [ 8.594003] systemd[1]: Listening on LVM2 poll daemon socket. [ 8.605075] systemd[1]: Listening on Syslog Socket. [ 8.605141] systemd[1]: Listening on fsck to fsckd communication Socket. [ 8.605180] systemd[1]: Listening on initctl Compatibility Named Pipe. [ 8.605314] systemd[1]: Listening on Journal Audit Socket. [ 8.605367] systemd[1]: Listening on Journal Socket (/dev/log). [ 8.605436] systemd[1]: Listening on Journal Socket. [ 8.605529] systemd[1]: Listening on Network Service Netlink Socket. [ 8.605591] systemd[1]: Listening on udev Control Socket. [ 8.605632] systemd[1]: Listening on udev Kernel Socket. [ 8.606314] systemd[1]: Mounting Huge Pages File System... [ 8.607032] systemd[1]: Mounting POSIX Message Queue File System... [ 8.607828] systemd[1]: Mounting Kernel Debug File System... [ 8.608560] systemd[1]: Mounting Kernel Trace File System... [ 8.609756] systemd[1]: Starting Journal Service... [ 8.610486] systemd[1]: Starting Availability of block devices... [ 8.611470] systemd[1]: Starting Set the console keyboard layout... [ 8.612340] systemd[1]: Starting Create list of static device nodes for the current kernel... [ 8.613086] systemd[1]: Starting Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling... [ 8.613818] systemd[1]: Starting Load Kernel Module drm... [ 8.755368] systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped. [ 8.755416] systemd[1]: Condition check resulted in File System Check on Root Device being skipped. [ 8.834411] systemd[1]: Starting Load Kernel Modules... [ 8.835159] systemd[1]: Starting Remount Root and Kernel File Systems... [ 8.835857] systemd[1]: Starting udev Coldplug all Devices... [ 8.836525] systemd[1]: Starting Uncomplicated firewall... [ 8.837906] systemd[1]: Mounted Huge Pages File System. [ 8.838007] systemd[1]: Mounted POSIX Message Queue File System. [ 8.838088] systemd[1]: Mounted Kernel Debug File System. [ 8.838167] systemd[1]: Mounted Kernel Trace File System. [ 8.838502] systemd[1]: Finished Availability of block devices. [ 8.846510] systemd[1]: Finished Create list of static device nodes for the current kernel. [ 9.003539] systemd[1]: Started Journal Service. [ 9.039225] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro [ 9.207828] systemd-journald[295]: Received client request to flush runtime journal. [ 9.534583] lp: driver loaded but no devices found [ 9.675407] ppdev: user-space parallel port driver [ 13.179050] audit: type=1400 audit(1595765482.234:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=388 comm="apparmor_parser" [ 13.179061] audit: type=1400 audit(1595765482.234:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_filter" pid=388 comm="apparmor_parser" [ 13.179063] audit: type=1400 audit(1595765482.234:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=388 comm="apparmor_parser" [ 13.228910] audit: type=1400 audit(1595765482.282:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-oopslash" pid=390 comm="apparmor_parser" [ 13.321052] audit: type=1400 audit(1595765482.374:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="unity8-dash" pid=392 comm="apparmor_parser" [ 13.327188] audit: type=1400 audit(1595765482.382:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="content-hub-peer-picker" pid=391 comm="apparmor_parser" [ 13.391780] audit: type=1400 audit(1595765482.446:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/tcpdump" pid=387 comm="apparmor_parser" [ 13.470023] audit: type=1400 audit(1595765482.522:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/cups-browsed" pid=393 comm="apparmor_parser" [ 13.493912] audit: type=1400 audit(1595765482.546:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/cups/backend/cups-pdf" pid=389 comm="apparmor_parser" [ 13.493923] audit: type=1400 audit(1595765482.546:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/cupsd" pid=389 comm="apparmor_parser" [ 16.818546] at24 0-0050: supply vcc not found, using dummy regulator [ 16.819139] at24 0-0050: 256 byte spd EEPROM, read-only [ 16.819164] at24 0-0051: supply vcc not found, using dummy regulator [ 16.819730] at24 0-0051: 256 byte spd EEPROM, read-only [ 20.037329] RAPL PMU: API unit is 2^-32 Joules, 2 fixed counters, 163840 ms ovfl timer [ 20.037330] RAPL PMU: hw unit of domain pp0-core 2^-16 Joules [ 20.037331] RAPL PMU: hw unit of domain package 2^-16 Joules [ 21.044402] [drm] radeon kernel modesetting enabled. [ 21.044450] radeon 0000:01:00.0: SI support disabled by module param [ 21.048448] cryptd: max_cpu_qlen set to 1000 [ 21.477046] AVX version of gcm_enc/dec engaged. [ 21.477048] AES CTR mode by8 optimization enabled [ 21.618260] AMD-Vi: AMD IOMMUv2 driver by Joerg Roedel <jroedel@suse.de> [ 21.618262] AMD-Vi: AMD IOMMUv2 functionality not available on this system [ 22.281348] [drm] amdgpu kernel modesetting enabled. [ 22.281415] CRAT table not found [ 22.281418] Virtual CRAT table created for CPU [ 22.281432] amdgpu: Topology: Add CPU node [ 22.281502] checking generic (e0000000 500000) vs hw (e0000000 10000000) [ 22.281503] fb0: switching to amdgpudrmfb from VESA VGA [ 22.281577] Console: switching to colour dummy device 80x25 [ 22.281606] amdgpu 0000:01:00.0: vgaarb: deactivate vga console [ 22.281726] [drm] initializing kernel modesetting (TAHITI 0x1002:0x679A 0x174B:0xE207 0x00). [ 22.281728] amdgpu 0000:01:00.0: amdgpu: Trusted Memory Zone (TMZ) feature not supported [ 22.281734] [drm] register mmio base: 0xF7E00000 [ 22.281734] [drm] register mmio size: 262144 [ 22.281735] [drm] PCIE atomic ops is not supported [ 22.281739] [drm] add ip block number 0 <si_common> [ 22.281739] [drm] add ip block number 1 <gmc_v6_0> [ 22.281740] [drm] add ip block number 2 <si_ih> [ 22.281740] [drm] add ip block number 3 <gfx_v6_0> [ 22.281741] [drm] add ip block number 4 <si_dma> [ 22.281741] [drm] add ip block number 5 <si_dpm> [ 22.281742] [drm] add ip block number 6 <dce_v6_0> [ 22.281743] kfd kfd: TAHITI not supported in kfd [ 22.288950] [drm] BIOS signature incorrect 0 0 [ 22.288955] resource sanity check: requesting [mem 0x000c0000-0x000dffff], which spans more than PCI Bus 0000:00 [mem 0x000d0000-0x000d3fff window] [ 22.288958] caller pci_map_rom+0x71/0x18c mapping multiple BARs [ 22.288975] amdgpu: ATOM BIOS: 113-1E207200SA-T47 [ 22.289285] [drm] vm size is 64 GB, 2 levels, block size is 10-bit, fragment size is 9-bit [ 22.380020] snd_hda_intel 0000:01:00.1: Force to non-snoop mode [ 22.490933] input: HDA ATI HDMI HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input4 [ 22.490969] input: HDA ATI HDMI HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input5 [ 22.490998] input: HDA ATI HDMI HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input6 [ 22.491027] input: HDA ATI HDMI HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input7 [ 22.491058] input: HDA ATI HDMI HDMI/DP,pcm=10 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input8 [ 22.491087] input: HDA ATI HDMI HDMI/DP,pcm=11 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input9 [ 22.813179] amdgpu 0000:01:00.0: amdgpu: VRAM: 3072M 0x000000F400000000 - 0x000000F4BFFFFFFF (3072M used) [ 22.813181] amdgpu 0000:01:00.0: amdgpu: GART: 1024M 0x000000FF00000000 - 0x000000FF3FFFFFFF [ 22.813190] [drm] Detected VRAM RAM=3072M, BAR=256M [ 22.813190] [drm] RAM width 384bits GDDR5 [ 22.813279] [TTM] Zone kernel: Available graphics memory: 4051868 KiB [ 22.813280] [TTM] Zone dma32: Available graphics memory: 2097152 KiB [ 22.813280] [TTM] Initializing pool allocator [ 22.813283] [TTM] Initializing DMA pool allocator [ 22.813315] [drm] amdgpu: 3072M of VRAM memory ready [ 22.813317] [drm] amdgpu: 3072M of GTT memory ready. [ 22.813320] [drm] GART: num cpu pages 262144, num gpu pages 262144 [ 22.813765] amdgpu 0000:01:00.0: amdgpu: PCIE GART of 1024M enabled (table at 0x000000F400500000). [ 22.813811] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 22.828189] intel_rapl_common: Found RAPL domain package [ 22.828190] intel_rapl_common: Found RAPL domain core [ 23.047397] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC892: line_outs=3 (0x14/0x15/0x16/0x0/0x0) type:line [ 23.047399] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 23.047400] snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x1b/0x0/0x0/0x0/0x0) [ 23.047400] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0 [ 23.047401] snd_hda_codec_realtek hdaudioC0D0: dig-out=0x1e/0x0 [ 23.047401] snd_hda_codec_realtek hdaudioC0D0: inputs: [ 23.047403] snd_hda_codec_realtek hdaudioC0D0: Front Mic=0x19 [ 23.047404] snd_hda_codec_realtek hdaudioC0D0: Rear Mic=0x18 [ 23.047404] snd_hda_codec_realtek hdaudioC0D0: Line=0x1a [ 23.060290] input: HDA Intel PCH Rear Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input10 [ 23.060326] input: HDA Intel PCH Line as /devices/pci0000:00/0000:00:1b.0/sound/card0/input11 [ 23.060356] input: HDA Intel PCH Line Out Front as /devices/pci0000:00/0000:00:1b.0/sound/card0/input12 [ 23.060386] input: HDA Intel PCH Line Out Surround as /devices/pci0000:00/0000:00:1b.0/sound/card0/input13 [ 23.060424] input: HDA Intel PCH Line Out CLFE as /devices/pci0000:00/0000:00:1b.0/sound/card0/input14 [ 23.132188] [drm] Internal thermal controller with fan control [ 23.132195] [drm] amdgpu: dpm initialized [ 23.132231] [drm] AMDGPU Display Connectors [ 23.132231] [drm] Connector 0: [ 23.132232] [drm] DP-1 [ 23.132232] [drm] HPD5 [ 23.132233] [drm] DDC: 0x194c 0x194c 0x194d 0x194d 0x194e 0x194e 0x194f 0x194f [ 23.132233] [drm] Encoders: [ 23.132234] [drm] DFP1: INTERNAL_UNIPHY2 [ 23.132234] [drm] Connector 1: [ 23.132234] [drm] DP-2 [ 23.132235] [drm] HPD4 [ 23.132235] [drm] DDC: 0x1950 0x1950 0x1951 0x1951 0x1952 0x1952 0x1953 0x1953 [ 23.132236] [drm] Encoders: [ 23.132236] [drm] DFP2: INTERNAL_UNIPHY2 [ 23.132236] [drm] Connector 2: [ 23.132236] [drm] HDMI-A-1 [ 23.132237] [drm] HPD1 [ 23.132237] [drm] DDC: 0x1954 0x1954 0x1955 0x1955 0x1956 0x1956 0x1957 0x1957 [ 23.132238] [drm] Encoders: [ 23.132238] [drm] DFP3: INTERNAL_UNIPHY1 [ 23.132238] [drm] Connector 3: [ 23.132238] [drm] DVI-I-1 [ 23.132239] [drm] HPD3 [ 23.132239] [drm] DDC: 0x1960 0x1960 0x1961 0x1961 0x1962 0x1962 0x1963 0x1963 [ 23.132240] [drm] Encoders: [ 23.132240] [drm] DFP4: INTERNAL_UNIPHY [ 23.132240] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 23.132527] [drm] PCIE gen 3 link speeds already enabled [ 23.274921] amdgpu 0000:01:00.0: amdgpu: SE 2, SH per SE 2, CU per SH 8, active_cu_number 28 [ 23.364927] [drm] fb mappable at 0xE0703000 [ 23.364928] [drm] vram apper at 0xE0000000 [ 23.364929] [drm] size 5242880 [ 23.364929] [drm] fb depth is 24 [ 23.364929] [drm] pitch is 5120 [ 23.365091] fbcon: amdgpudrmfb (fb0) is primary device [ 23.463699] Console: switching to colour frame buffer device 160x64 [ 23.465607] amdgpu 0000:01:00.0: fb0: amdgpudrmfb frame buffer device [ 23.736585] [drm] Initialized amdgpu 3.38.0 20150101 for 0000:01:00.0 on minor 0 ... [ 7723.674495] arb_gpu_shader5[114877]: segfault at 7fbb937fe9d0 ip 00007fbbbaad8aab sp 00007fff47d256a0 error 4 in libpthread-2.31.so[7fbbbaad5000+11000] [ 7723.674502] Code: Bad RIP value. [ 7758.485659] arb_enhanced_la[124954]: segfault at 290001 ip 00007f73e6c3ad5a sp 00007ffdbe5d4aa8 error 4 in libc-2.31.so[7f73e6bab000+178000] [ 7758.485664] Code: Bad RIP value. [ 7759.173405] arb_enhanced_la[125230]: segfault at 290001 ip 00007f5ad9fa7d5a sp 00007fffd9aaa1e8 error 4 in libc-2.31.so[7f5ad9f18000+178000] [ 7759.173411] Code: Bad RIP value. [ 7805.053360] amdgpu 0000:01:00.0: amdgpu: GPU fault detected: 146 0x0006880c [ 7805.053364] amdgpu 0000:01:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 7805.053365] amdgpu 0000:01:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0608800C [ 7805.053367] amdgpu 0000:01:00.0: amdgpu: VM fault (0x0c, vmid 3) at page 0, read from '' (0x00000000) (136) [ 7813.142358] [TTM] Failed to find memory space for buffer 0x00000000812205b0 eviction [ 7813.142371] [TTM] No space for 00000000812205b0 (524288 pages, 2097152K, 2048M) [ 7813.142373] [TTM] placement[0]=0x00060002 (1) [ 7813.142374] [TTM] has_type: 1 [ 7813.142374] [TTM] use_type: 1 [ 7813.142375] [TTM] flags: 0x0000000A [ 7813.142376] [TTM] gpu_offset: 0xFF00000000 [ 7813.142376] [TTM] size: 786432 [ 7813.142377] [TTM] available_caching: 0x00070000 [ 7813.142377] [TTM] default_caching: 0x00010000 [ 7813.142379] [TTM] 0x0000000000000400-0x0000000000000402: 2: used [ 7813.142380] [TTM] 0x0000000000000402-0x0000000000000412: 16: used [ 7813.142381] [TTM] 0x0000000000000412-0x0000000000000414: 2: used [ 7813.142382] [TTM] 0x0000000000000414-0x0000000000000416: 2: used [ 7813.142383] [TTM] 0x0000000000000416-0x0000000000000418: 2: used [ 7813.142384] [TTM] 0x0000000000000418-0x000000000000041a: 2: used [ 7813.142384] [TTM] 0x000000000000041a-0x000000000000041c: 2: used [ 7813.142385] [TTM] 0x000000000000041c-0x000000000000051c: 256: used [ 7813.142386] [TTM] 0x000000000000051c-0x000000000000061c: 256: used [ 7813.142387] [TTM] 0x000000000000061c-0x000000000000061e: 2: used [ 7813.142388] [TTM] 0x000000000000061e-0x0000000000000620: 2: used [ 7813.142388] [TTM] 0x0000000000000620-0x0000000000000622: 2: used [ 7813.142389] [TTM] 0x0000000000000622-0x0000000000000624: 2: used [ 7813.142390] [TTM] 0x0000000000000624-0x0000000000000626: 2: used [ 7813.142391] [TTM] 0x0000000000000626-0x0000000000000628: 2: used [ 7813.142391] [TTM] 0x0000000000000628-0x000000000000062a: 2: used [ 7813.142392] [TTM] 0x000000000000062a-0x000000000000062c: 2: used [ 7813.142393] [TTM] 0x000000000000062c-0x000000000000062e: 2: used [ 7813.142393] [TTM] 0x000000000000062e-0x0000000000000630: 2: used [ 7813.142394] [TTM] 0x0000000000000630-0x0000000000000632: 2: used [ 7813.142395] [TTM] 0x0000000000000632-0x0000000000000634: 2: used [ 7813.142395] [TTM] 0x0000000000000634-0x0000000000000636: 2: used [ 7813.142396] [TTM] 0x0000000000000636-0x0000000000000638: 2: used [ 7813.142397] [TTM] 0x0000000000000638-0x000000000000063a: 2: used [ 7813.142398] [TTM] 0x000000000000063a-0x000000000000063c: 2: used [ 7813.142399] [TTM] 0x000000000000063c-0x000000000000063e: 2: used [ 7813.142400] [TTM] 0x000000000000063e-0x000000000000063f: 1: used [ 7813.142400] [TTM] 0x000000000000063f-0x0000000000000641: 2: used [ 7813.142401] [TTM] 0x0000000000000641-0x0000000000000643: 2: used [ 7813.142402] [TTM] 0x0000000000000643-0x0000000000000645: 2: used [ 7813.142402] [TTM] 0x0000000000000645-0x0000000000000647: 2: used [ 7813.142403] [TTM] 0x0000000000000647-0x0000000000000649: 2: used [ 7813.142404] [TTM] 0x0000000000000649-0x000000000000064b: 2: used [ 7813.142405] [TTM] 0x000000000000064b-0x000000000000064d: 2: used [ 7813.142406] [TTM] 0x000000000000064d-0x000000000000064f: 2: used [ 7813.142406] [TTM] 0x000000000000064f-0x0000000000000651: 2: used [ 7813.142407] [TTM] 0x0000000000000651-0x0000000000000653: 2: used [ 7813.142408] [TTM] 0x0000000000000653-0x0000000000000655: 2: used [ 7813.142409] [TTM] 0x0000000000000655-0x0000000000000657: 2: used [ 7813.142409] [TTM] 0x0000000000000657-0x0000000000000659: 2: used [ 7813.142410] [TTM] 0x0000000000000659-0x000000000000065b: 2: used [ 7813.142411] [TTM] 0x000000000000065b-0x0000000000000692: 55: free [ 7813.142411] [TTM] 0x0000000000000692-0x0000000000000694: 2: used [ 7813.142412] [TTM] 0x0000000000000694-0x000000000000070f: 123: free [ 7813.142413] [TTM] 0x000000000000070f-0x0000000000000711: 2: used [ 7813.142413] [TTM] 0x0000000000000711-0x000000000000079c: 139: free [ 7813.142414] [TTM] 0x000000000000079c-0x000000000000079e: 2: used [ 7813.142415] [TTM] 0x000000000000079e-0x00000000000007ee: 80: free [ 7813.142415] [TTM] 0x00000000000007ee-0x00000000000007f0: 2: used [ 7813.142461] [TTM] 0x00000000000007f0-0x00000000000007f2: 2: used [ 7813.142462] [TTM] 0x00000000000007f2-0x00000000000007fe: 12: free [ 7813.142463] [TTM] 0x00000000000007fe-0x0000000000000800: 2: used [ 7813.142463] [TTM] 0x0000000000000800-0x0000000000000806: 6: free [ 7813.142464] [TTM] 0x0000000000000806-0x0000000000000808: 2: used [ 7813.142464] [TTM] 0x0000000000000808-0x000000000000080e: 6: free [ 7813.142465] [TTM] 0x000000000000080e-0x000000000000082e: 32: used [ 7813.142465] [TTM] 0x000000000000082e-0x000000000000083a: 12: free [ 7813.142466] [TTM] 0x000000000000083a-0x000000000000083c: 2: used [ 7813.142467] [TTM] 0x000000000000083c-0x000000000000083e: 2: used [ 7813.142467] [TTM] 0x000000000000083e-0x0000000000000840: 2: used [ 7813.142469] [TTM] 0x0000000000000840-0x0000000000000842: 2: used [ 7813.142469] [TTM] 0x0000000000000842-0x0000000000000844: 2: used [ 7813.142470] [TTM] 0x0000000000000844-0x0000000000000846: 2: used [ 7813.142471] [TTM] 0x0000000000000846-0x0000000000000848: 2: used [ 7813.142472] [TTM] 0x0000000000000848-0x000000000000084a: 2: used [ 7813.142473] [TTM] 0x000000000000084a-0x000000000000084c: 2: used [ 7813.142473] [TTM] 0x000000000000084c-0x000000000000084e: 2: used [ 7813.142474] [TTM] 0x000000000000084e-0x0000000000000850: 2: used [ 7813.142475] [TTM] 0x0000000000000850-0x0000000000000852: 2: used [ 7813.142475] [TTM] 0x0000000000000852-0x0000000000000854: 2: used [ 7813.142476] [TTM] 0x0000000000000854-0x000000000000088a: 54: free [ 7813.142476] [TTM] 0x000000000000088a-0x000000000000088c: 2: used [ 7813.142477] [TTM] 0x000000000000088c-0x0000000000040000: 259956: free [ 7813.142478] [TTM] total: 261120, used 677 free 260443 [ 7813.142479] [TTM] man size:786432 pages, gtt available:260443 pages, usage:2054MB [ 7813.270091] [TTM] Failed to find memory space for buffer 0x00000000812205b0 eviction [ 7813.270104] [TTM] No space for 00000000812205b0 (524288 pages, 2097152K, 2048M) [ 7813.270105] [TTM] placement[0]=0x00060002 (1) [ 7813.270105] [TTM] has_type: 1 [ 7813.270106] [TTM] use_type: 1 [ 7813.270106] [TTM] flags: 0x0000000A [ 7813.270107] [TTM] gpu_offset: 0xFF00000000 [ 7813.270108] [TTM] size: 786432 [ 7813.270108] [TTM] available_caching: 0x00070000 [ 7813.270109] [TTM] default_caching: 0x00010000 [ 7813.270110] [TTM] 0x0000000000000400-0x0000000000000402: 2: used [ 7813.270111] [TTM] 0x0000000000000402-0x0000000000000412: 16: used [ 7813.270112] [TTM] 0x0000000000000412-0x0000000000000414: 2: used [ 7813.270113] [TTM] 0x0000000000000414-0x0000000000000416: 2: used [ 7813.270113] [TTM] 0x0000000000000416-0x0000000000000418: 2: used [ 7813.270114] [TTM] 0x0000000000000418-0x000000000000041a: 2: used [ 7813.270115] [TTM] 0x000000000000041a-0x000000000000041c: 2: used [ 7813.270116] [TTM] 0x000000000000041c-0x000000000000051c: 256: used [ 7813.270116] [TTM] 0x000000000000051c-0x000000000000061c: 256: used [ 7813.270117] [TTM] 0x000000000000061c-0x000000000000061e: 2: used [ 7813.270118] [TTM] 0x000000000000061e-0x0000000000040000: 260578: free [ 7813.270119] [TTM] total: 261120, used 542 free 260578 [ 7813.270120] [TTM] man size:786432 pages, gtt available:261602 pages, usage:2050MB [ 7813.339330] [TTM] Failed to find memory space for buffer 0x00000000812205b0 eviction [ 7813.339339] [TTM] No space for 00000000812205b0 (524288 pages, 2097152K, 2048M) [ 7813.339340] [TTM] placement[0]=0x00060002 (1) [ 7813.339341] [TTM] has_type: 1 [ 7813.339341] [TTM] use_type: 1 [ 7813.339342] [TTM] flags: 0x0000000A [ 7813.339343] [TTM] gpu_offset: 0xFF00000000 [ 7813.339343] [TTM] size: 786432 [ 7813.339344] [TTM] available_caching: 0x00070000 [ 7813.339344] [TTM] default_caching: 0x00010000 [ 7813.339347] [TTM] 0x0000000000000400-0x0000000000000402: 2: used [ 7813.339348] [TTM] 0x0000000000000402-0x0000000000000412: 16: used [ 7813.339348] [TTM] 0x0000000000000412-0x0000000000000414: 2: used [ 7813.339349] [TTM] 0x0000000000000414-0x0000000000000416: 2: used [ 7813.339350] [TTM] 0x0000000000000416-0x0000000000000418: 2: used [ 7813.339350] [TTM] 0x0000000000000418-0x000000000000041a: 2: used [ 7813.339351] [TTM] 0x000000000000041a-0x000000000000041c: 2: used [ 7813.339352] [TTM] 0x000000000000041c-0x000000000000051c: 256: used [ 7813.339353] [TTM] 0x000000000000051c-0x000000000000061c: 256: used [ 7813.339353] [TTM] 0x000000000000061c-0x000000000000061e: 2: used [ 7813.339354] [TTM] 0x000000000000061e-0x0000000000000620: 2: used [ 7813.339355] [TTM] 0x0000000000000620-0x0000000000000622: 2: used [ 7813.339356] [TTM] 0x0000000000000622-0x0000000000000624: 2: used [ 7813.339357] [TTM] 0x0000000000000624-0x0000000000000626: 2: used [ 7813.339357] [TTM] 0x0000000000000626-0x0000000000000628: 2: used [ 7813.339358] [TTM] 0x0000000000000628-0x00000000000006fe: 214: free [ 7813.339359] [TTM] 0x00000000000006fe-0x000000000000071e: 32: used [ 7813.339360] [TTM] 0x000000000000071e-0x000000000000071f: 1: used [ 7813.339360] [TTM] 0x000000000000071f-0x0000000000040000: 260321: free [ 7813.339361] [TTM] total: 261120, used 585 free 260535 [ 7813.339363] [TTM] man size:786432 pages, gtt available:260791 pages, usage:2053MB [ 7813.437505] [TTM] Failed to find memory space for buffer 0x00000000812205b0 eviction [ 7813.437516] [TTM] No space for 00000000812205b0 (524288 pages, 2097152K, 2048M) [ 7813.437517] [TTM] placement[0]=0x00060002 (1) [ 7813.437518] [TTM] has_type: 1 [ 7813.437519] [TTM] use_type: 1 [ 7813.437519] [TTM] flags: 0x0000000A [ 7813.437520] [TTM] gpu_offset: 0xFF00000000 [ 7813.437521] [TTM] size: 786432 [ 7813.437521] [TTM] available_caching: 0x00070000 [ 7813.437522] [TTM] default_caching: 0x00010000 [ 7813.437523] [TTM] 0x0000000000000400-0x0000000000000402: 2: used [ 7813.437524] [TTM] 0x0000000000000402-0x0000000000000412: 16: used [ 7813.437525] [TTM] 0x0000000000000412-0x0000000000000414: 2: used [ 7813.437526] [TTM] 0x0000000000000414-0x0000000000000416: 2: used [ 7813.437527] [TTM] 0x0000000000000416-0x0000000000000418: 2: used [ 7813.437527] [TTM] 0x0000000000000418-0x000000000000041a: 2: used [ 7813.437528] [TTM] 0x000000000000041a-0x000000000000041c: 2: used [ 7813.437529] [TTM] 0x000000000000041c-0x000000000000051c: 256: used [ 7813.437529] [TTM] 0x000000000000051c-0x000000000000061c: 256: used [ 7813.437530] [TTM] 0x000000000000061c-0x000000000000061e: 2: used [ 7813.437531] [TTM] 0x000000000000061e-0x0000000000040000: 260578: free [ 7813.437531] [TTM] total: 261120, used 542 free 260578 [ 7813.437533] [TTM] man size:786432 pages, gtt available:261602 pages, usage:2050MB [ 7813.438518] arb_uniform_buf[143135]: segfault at 0 ip 00007f20b6f990d7 sp 00007ffdebfcc8c8 error 6 in libc-2.31.so[7f20b6eff000+178000] [ 7813.438532] Code: Bad RIP value. [ 7919.344885] arb_shader_stor[146734]: segfault at 0 ip 00007fe2ab5020d7 sp 00007fff6027eda8 error 6 in libc-2.31.so[7fe2ab468000+178000] [ 7919.344894] Code: Bad RIP value. [ 7919.897315] arb_shader_stor[146769]: segfault at 0 ip 00007f10d8fbd0d7 sp 00007ffcf8895608 error 6 in libc-2.31.so[7f10d8f23000+178000] [ 7919.897332] Code: Bad RIP value. [ 8009.208256] egl-copy-buffer[147619]: segfault at 18 ip 00007f968e8c9e9b sp 00007ffe7ca12200 error 4 in libEGL_mesa.so.0.0.0[7f968e8a9000+26000] [ 8009.208263] Code: Bad RIP value. [ 8032.266864] perf: interrupt took too long (2507 > 2500), lowering kernel.perf_event_max_sample_rate to 79750 [ 8070.875068] [TTM] Buffer eviction failed [ 8080.462745] amdgpu 0000:01:00.0: amdgpu: GPU fault detected: 146 0x00ce8804 [ 8080.462756] amdgpu 0000:01:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00134006 [ 8080.462758] amdgpu 0000:01:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0E088004 [ 8080.462759] amdgpu 0000:01:00.0: amdgpu: VM fault (0x04, vmid 7) at page 1261574, read from '' (0x00000000) (136) [ 8080.478266] amdgpu 0000:01:00.0: amdgpu: GPU fault detected: 146 0x00c28804 [ 8080.478271] amdgpu 0000:01:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00134006 [ 8080.478272] amdgpu 0000:01:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x02088004 [ 8080.478274] amdgpu 0000:01:00.0: amdgpu: VM fault (0x04, vmid 1) at page 1261574, read from '' (0x00000000) (136) [ 8204.864339] shader_runner[168816]: segfault at 7f64df7fe9d0 ip 00007f6506a47aab sp 00007fff3961d340 error 4 [ 8204.864343] shader_runner[168803]: segfault at 7faa7d7fa9d0 ip 00007faa941ccaab sp 00007ffca97f4490 error 4 [ 8204.864345] in libpthread-2.31.so[7f6506a44000+11000] [ 8204.864348] Code: Bad RIP value. [ 8204.864349] in libpthread-2.31.so[7faa941c9000+11000] [ 8204.864351] Code: Bad RIP value. [ 8204.864376] shader_runner[168801]: segfault at 7f12bf7fe9d0 ip 00007f12d3155aab sp 00007fff81846f80 error 4 in libpthread-2.31.so[7f12d3152000+11000] [ 8204.864381] Code: Bad RIP value. [ 8204.864501] shader_runner[168802]: segfault at 7f7225ffb9d0 ip 00007f723cfa4aab sp 00007ffda6a8a890 error 4 in libpthread-2.31.so[7f723cfa1000+11000] [ 8204.864507] Code: Bad RIP value. [ 8207.293001] shader_runner[168847]: segfault at 7f4781ffb9d0 ip 00007f4799379aab sp 00007ffd72820630 error 4 in libpthread-2.31.so[7f4799376000+11000] [ 8207.293009] Code: Bad RIP value. [ 8207.303214] shader_runner[168849]: segfault at 7f01a27fc9d0 ip 00007f01c1c58aab sp 00007ffef3fc31d0 error 4 in libpthread-2.31.so[7f01c1c55000+11000] [ 8207.303220] Code: Bad RIP value. [ 8207.333651] shader_runner[168872]: segfault at 7f84fffff9d0 ip 00007f852f5f4aab sp 00007ffc03821a30 error 4 in libpthread-2.31.so[7f852f5f1000+11000] [ 8207.333656] Code: Bad RIP value. [ 8207.339399] shader_runner[168875]: segfault at 7f5dedffb9d0 ip 00007f5e04e37aab sp 00007ffd41558ad0 error 4 in libpthread-2.31.so[7f5e04e34000+11000] [ 8207.339405] Code: Bad RIP value. [ 8207.515900] shader_runner[168890]: segfault at 7f3e677fe9d0 ip 00007f3e76a5baab sp 00007ffe1bdbfa30 error 4 in libpthread-2.31.so[7f3e76a58000+11000] [ 8207.515907] Code: Bad RIP value. [ 8207.551837] shader_runner[168915]: segfault at 7f14667fc9d0 ip 00007f147dbdbaab sp 00007ffef737bb30 error 4 in libpthread-2.31.so[7f147dbd8000+11000] [ 8207.551842] Code: Bad RIP value. [ 8209.900683] show_signal_msg: 38 callbacks suppressed [ 8209.900686] shader_runner[169450]: segfault at 7fe88d1119d0 ip 00007fe897dc7aab sp 00007fff9a7994e0 error 4 in libpthread-2.31.so[7fe897dc4000+11000] [ 8209.900695] Code: Bad RIP value. [ 8209.958317] shader_runner[169463]: segfault at 7f05d8ff99d0 ip 00007f05e82a9aab sp 00007ffd29495db0 error 4 in libpthread-2.31.so[7f05e82a6000+11000] [ 8209.958323] Code: Bad RIP value. [ 8210.016780] shader_runner[169477]: segfault at 7fd1657fa9d0 ip 00007fd174c58aab sp 00007ffd46a738b0 error 4 in libpthread-2.31.so[7fd174c55000+11000] [ 8210.016787] Code: Bad RIP value. [ 8210.095393] shader_runner[169492]: segfault at 7f8d79d7c9d0 ip 00007f8d84a32aab sp 00007ffe83c7c320 error 4 in libpthread-2.31.so[7f8d84a2f000+11000] [ 8210.095398] Code: Bad RIP value. [ 8210.175068] shader_runner[169506]: segfault at 7f27877fe9d0 ip 00007f27a68b4aab sp 00007ffd39ff79a0 error 4 in libpthread-2.31.so[7f27a68b1000+11000] [ 8210.175075] Code: Bad RIP value. [ 8210.202147] shader_runner[169519]: segfault at 7f315a7fc9d0 ip 00007f316970daab sp 00007ffee6c3a210 error 4 in libpthread-2.31.so[7f316970a000+11000] [ 8210.202156] Code: Bad RIP value. [ 8210.288298] shader_runner[169534]: segfault at 7f7a3cff99d0 ip 00007f7a4c23baab sp 00007ffc087caeb0 error 4 in libpthread-2.31.so[7f7a4c238000+11000] [ 8210.288303] Code: Bad RIP value. [ 8210.329530] shader_runner[169547]: segfault at 7f63f57fa9d0 ip 00007f6404af5aab sp 00007ffdf3e7f790 error 4 in libpthread-2.31.so[7f6404af2000+11000] [ 8210.329536] Code: Bad RIP value. [ 8210.412320] shader_runner[169562]: segfault at 7f622471f9d0 ip 00007f622f3d5aab sp 00007fff6f38f6b0 error 4 in libpthread-2.31.so[7f622f3d2000+11000] [ 8210.412325] Code: Bad RIP value. [ 8210.455261] shader_runner[169575]: segfault at 7f0d177fe9d0 ip 00007f0d2e351aab sp 00007fff77b01400 error 4 in libpthread-2.31.so[7f0d2e34e000+11000] [ 8210.455269] Code: Bad RIP value. [ 8218.886289] show_signal_msg: 27 callbacks suppressed [ 8218.886292] shader_runner[172286]: segfault at 56393e81e408 ip 00007f4feb9a3ed9 sp 00007ffe74015800 error 4 in radeonsi_dri.so[7f4feb6ad000+d49000] [ 8218.886297] Code: Bad RIP value. [ 8218.899687] shader_runner[172285]: segfault at 563750011378 ip 00007ff7236e4ed9 sp 00007ffe2e978e10 error 4 in radeonsi_dri.so[7ff7233ee000+d49000] [ 8218.899692] Code: Bad RIP value. [ 8219.001985] shader_runner[172334]: segfault at 5623ce8c4848 ip 00007fa239f2bed9 sp 00007ffcaf7c4170 error 4 in radeonsi_dri.so[7fa239c35000+d49000] [ 8219.001991] Code: Bad RIP value. [ 8219.490115] shader_runner[172514]: segfault at 55f2d3009314 ip 00007fad22647500 sp 00007ffe441c0120 error 4 in radeonsi_dri.so[7fad2234f000+d49000] [ 8219.490123] Code: Bad RIP value. [ 8219.491095] shader_runner[172516]: segfault at 563bd86d20a4 ip 00007fb9e40f9500 sp 00007ffcd77518b0 error 4 in radeonsi_dri.so[7fb9e3e01000+d49000] [ 8219.491101] Code: Bad RIP value. [ 8219.711083] shader_runner[172588]: segfault at 55ca9ae686a4 ip 00007fe140555500 sp 00007ffe9cae1400 error 4 in radeonsi_dri.so[7fe14025d000+d49000] [ 8219.711090] Code: Bad RIP value. [ 8430.203633] perf: interrupt took too long (3138 > 3133), lowering kernel.perf_event_max_sample_rate to 63500 [ 9055.012725] audit: type=1400 audit(1595774523.846:84): apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="/usr/share/libdrm/amdgpu.ids" pid=383072 comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [-- Attachment #3: piglit_tests_amddcsi.ods --] [-- Type: application/vnd.oasis.opendocument.spreadsheet, Size: 34347 bytes --] [-- Attachment #4: Type: text/plain, Size: 154 bytes --] _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-07-26 15:31 ` Re: Mauro Rossi @ 2020-07-27 18:31 ` Alex Deucher 2020-07-27 19:46 ` Re: Mauro Rossi 0 siblings, 1 reply; 1767+ messages in thread From: Alex Deucher @ 2020-07-27 18:31 UTC (permalink / raw) To: Mauro Rossi Cc: Deucher, Alexander, Harry Wentland, Christian Koenig, amd-gfx list On Sun, Jul 26, 2020 at 11:31 AM Mauro Rossi <issor.oruam@gmail.com> wrote: > > Hello, > > On Fri, Jul 24, 2020 at 8:31 PM Alex Deucher <alexdeucher@gmail.com> wrote: >> >> On Wed, Jul 22, 2020 at 3:57 AM Mauro Rossi <issor.oruam@gmail.com> wrote: >> > >> > Hello, >> > re-sending and copying full DL >> > >> > On Wed, Jul 22, 2020 at 4:51 AM Alex Deucher <alexdeucher@gmail.com> wrote: >> >> >> >> On Mon, Jul 20, 2020 at 6:00 AM Mauro Rossi <issor.oruam@gmail.com> wrote: >> >> > >> >> > Hi Christian, >> >> > >> >> > On Mon, Jul 20, 2020 at 11:00 AM Christian König >> >> > <ckoenig.leichtzumerken@gmail.com> wrote: >> >> > > >> >> > > Hi Mauro, >> >> > > >> >> > > I'm not deep into the whole DC design, so just some general high level >> >> > > comments on the cover letter: >> >> > > >> >> > > 1. Please add a subject line to the cover letter, my spam filter thinks >> >> > > that this is suspicious otherwise. >> >> > >> >> > My mistake in the editing of covert letter with git send-email, >> >> > I may have forgot to keep the Subject at the top >> >> > >> >> > > >> >> > > 2. Then you should probably note how well (badly?) is that tested. Since >> >> > > you noted proof of concept it might not even work. >> >> > >> >> > The Changelog is to be read as: >> >> > >> >> > [RFC] was the initial Proof of concept was the RFC and [PATCH v2] was >> >> > just a rebase onto amd-staging-drm-next >> >> > >> >> > this series [PATCH v3] has all the known changes required for DCE6 specificity >> >> > and based on a long offline thread with Alexander Deutcher and past >> >> > dri-devel chats with Harry Wentland. >> >> > >> >> > It was tested for my possibilities of testing with HD7750 and HD7950, >> >> > with checks in dmesg output for not getting "missing registers/masks" >> >> > kernel WARNING >> >> > and with kernel build on Ubuntu 20.04 and with android-x86 >> >> > >> >> > The proposal I made to Alex is that AMD testing systems will be used >> >> > for further regression testing, >> >> > as part of review and validation for eligibility to amd-staging-drm-next >> >> > >> >> >> >> We will certainly test it once it lands, but presumably this is >> >> working on the SI cards you have access to? >> > >> > >> > Yes, most of my testing was done with android-x86 Android CTS (EGL, GLES2, GLES3, VK) >> > >> > I am also in contact with a person with Firepro W5130M who is running a piglit session >> > >> > I had bought an HD7850 to test with Pitcairn, but it arrived as defective so I could not test with Pitcair >> > >> > >> >> >> >> > > >> >> > > 3. How feature complete (HDMI audio?, Freesync?) is it? >> >> > >> >> > All the changes in DC impacting DCE8 (dc/dce80 path) were ported to >> >> > DCE6 (dc/dce60 path) in the last two years from initial submission >> >> > >> >> > > >> >> > > Apart from that it looks like a rather impressive piece of work :) >> >> > > >> >> > > Cheers, >> >> > > Christian. >> >> > >> >> > Thanks, >> >> > please consider that most of the latest DCE6 specific parts were >> >> > possible due to recent Alex support in getting the correct DCE6 >> >> > headers, >> >> > his suggestions and continuous feedback. >> >> > >> >> > I would suggest that Alex comments on the proposed next steps to follow. >> >> >> >> The code looks pretty good to me. I'd like to get some feedback from >> >> the display team to see if they have any concerns, but beyond that I >> >> think we can pull it into the tree and continue improving it there. >> >> Do you have a link to a git tree I can pull directly that contains >> >> these patches? Is this the right branch? >> >> https://github.com/maurossi/linux/commits/kernel-5.8rc4_si_next >> >> >> >> Thanks! >> >> >> >> Alex >> > >> > >> > The following branch was pushed with the series on top of amd-staging-drm-next >> > >> > https://github.com/maurossi/linux/commits/kernel-5.6_si_drm-next >> >> I gave this a quick test on all of the SI asics and the various >> monitors I had available and it looks good. A few minor patches I >> noticed are attached. If they look good to you, I'll squash them into >> the series when I commit it. I've pushed it to my fdo tree as well: >> https://cgit.freedesktop.org/~agd5f/linux/log/?h=si_dc_support >> >> Thanks! >> >> Alex > > > The new patches are ok and with the following infomation about piglit tests, > the series may be good to go. > > I have performed piglit tests on Tahiti HD7950 on kernel 5.8.0-rc6 with AMD DC support for SI > and comparison with vanilla kernel 5.8.0-rc6 > > Results are the following > > [piglit gpu tests with kernel 5.8.0-rc6-amddcsi] > > utente@utente-desktop:~/piglit$ ./piglit run gpu . > [26714/26714] skip: 1731, pass: 24669, warn: 15, fail: 288, crash: 11 > Thank you for running Piglit! > Results have been written to /home/utente/piglit > > [piglit gpu tests with vanilla 5.8.0-rc6] > > utente@utente-desktop:~/piglit$ ./piglit run gpu . > [26714/26714] skip: 1731, pass: 24673, warn: 13, fail: 283, crash: 14 > Thank you for running Piglit! > Results have been written to /home/utente/piglit > > In the attachment the comparison of "5.8.0-rc6-amddcsi" vs "5.8.0-rc6" vanilla > and viceversa, I see no significant regression and in the delta of failed tests I don't recognize DC related test cases, > but you may also have a look. Looks good to me. The series is: Reviewed-by: Alex Deucher <alexander.deucher@amd.com> > > dmesg for "5.8.0-rc6-amddcsi" is also provide the check the crashes > > Regarding the other user testing the series with Firepro W5130M > he found an already existing issue in amdgpu si_support=1 which is independent from my series and matches a problem alrady reported. [1] > amdgpu does not currently implement GPU reset support for SI. Alex > Mauro > > [1] https://bbs.archlinux.org/viewtopic.php?id=249097 > >> >> >> > >> >> >> >> >> >> > >> >> > Mauro >> >> > >> >> > > >> >> > > Am 16.07.20 um 23:22 schrieb Mauro Rossi: >> >> > > > The series adds SI support to AMD DC >> >> > > > >> >> > > > Changelog: >> >> > > > >> >> > > > [RFC] >> >> > > > Preliminar Proof Of Concept, with DCE8 headers still used in dce60_resources.c >> >> > > > >> >> > > > [PATCH v2] >> >> > > > Rebase on amd-staging-drm-next dated 17-Oct-2018 >> >> > > > >> >> > > > [PATCH v3] >> >> > > > Add support for DCE6 specific headers, >> >> > > > ad hoc DCE6 macros, funtions and fixes, >> >> > > > rebase on current amd-staging-drm-next >> >> > > > >> >> > > > >> >> > > > Commits [01/27]..[08/27] SI support added in various DC components >> >> > > > >> >> > > > [PATCH v3 01/27] drm/amdgpu: add some required DCE6 registers (v6) >> >> > > > [PATCH v3 02/27] drm/amd/display: add asics info for SI parts >> >> > > > [PATCH v3 03/27] drm/amd/display: dc/dce: add initial DCE6 support (v9b) >> >> > > > [PATCH v3 04/27] drm/amd/display: dc/core: add SI/DCE6 support (v2) >> >> > > > [PATCH v3 05/27] drm/amd/display: dc/bios: add support for DCE6 >> >> > > > [PATCH v3 06/27] drm/amd/display: dc/gpio: add support for DCE6 (v2) >> >> > > > [PATCH v3 07/27] drm/amd/display: dc/irq: add support for DCE6 (v4) >> >> > > > [PATCH v3 08/27] drm/amd/display: amdgpu_dm: add SI support (v4) >> >> > > > >> >> > > > Commits [09/27]..[24/27] DCE6 specific code adaptions >> >> > > > >> >> > > > [PATCH v3 09/27] drm/amd/display: dc/clk_mgr: add support for SI parts (v2) >> >> > > > [PATCH v3 10/27] drm/amd/display: dc/dce60: set max_cursor_size to 64 >> >> > > > [PATCH v3 11/27] drm/amd/display: dce_audio: add DCE6 specific macros,functions >> >> > > > [PATCH v3 12/27] drm/amd/display: dce_dmcu: add DCE6 specific macros >> >> > > > [PATCH v3 13/27] drm/amd/display: dce_hwseq: add DCE6 specific macros,functions >> >> > > > [PATCH v3 14/27] drm/amd/display: dce_ipp: add DCE6 specific macros,functions >> >> > > > [PATCH v3 15/27] drm/amd/display: dce_link_encoder: add DCE6 specific macros,functions >> >> > > > [PATCH v3 16/27] drm/amd/display: dce_mem_input: add DCE6 specific macros,functions >> >> > > > [PATCH v3 17/27] drm/amd/display: dce_opp: add DCE6 specific macros,functions >> >> > > > [PATCH v3 18/27] drm/amd/display: dce_transform: add DCE6 specific macros,functions >> >> > > > [PATCH v3 19/27] drm/amdgpu: add some required DCE6 registers (v7) >> >> > > > [PATCH v3 20/27] drm/amd/display: dce_transform: DCE6 Scaling Horizontal Filter Init >> >> > > > [PATCH v3 21/27] drm/amd/display: dce60_hw_sequencer: add DCE6 macros,functions >> >> > > > [PATCH v3 22/27] drm/amd/display: dce60_hw_sequencer: add DCE6 specific .cursor_lock >> >> > > > [PATCH v3 23/27] drm/amd/display: dce60_timing_generator: add DCE6 specific functions >> >> > > > [PATCH v3 24/27] drm/amd/display: dc/dce60: use DCE6 headers (v6) >> >> > > > >> >> > > > >> >> > > > Commits [25/27]..[27/27] SI support final enablements >> >> > > > >> >> > > > [PATCH v3 25/27] drm/amd/display: create plane rotation property for Bonarie and later >> >> > > > [PATCH v3 26/27] drm/amdgpu: enable DC support for SI parts (v2) >> >> > > > [PATCH v3 27/27] drm/amd/display: enable SI support in the Kconfig (v2) >> >> > > > >> >> > > > >> >> > > > Signed-off-by: Mauro Rossi <issor.oruam@gmail.com> >> >> > > > >> >> > > > _______________________________________________ >> >> > > > amd-gfx mailing list >> >> > > > amd-gfx@lists.freedesktop.org >> >> > > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx >> >> > > >> >> > _______________________________________________ >> >> > amd-gfx mailing list >> >> > amd-gfx@lists.freedesktop.org >> >> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-07-27 18:31 ` Re: Alex Deucher @ 2020-07-27 19:46 ` Mauro Rossi 2020-07-27 19:54 ` Re: Alex Deucher 0 siblings, 1 reply; 1767+ messages in thread From: Mauro Rossi @ 2020-07-27 19:46 UTC (permalink / raw) To: Alex Deucher Cc: Deucher, Alexander, Harry Wentland, Christian Koenig, amd-gfx list [-- Attachment #1.1: Type: text/plain, Size: 10849 bytes --] On Mon, Jul 27, 2020 at 8:31 PM Alex Deucher <alexdeucher@gmail.com> wrote: > On Sun, Jul 26, 2020 at 11:31 AM Mauro Rossi <issor.oruam@gmail.com> > wrote: > > > > Hello, > > > > On Fri, Jul 24, 2020 at 8:31 PM Alex Deucher <alexdeucher@gmail.com> > wrote: > >> > >> On Wed, Jul 22, 2020 at 3:57 AM Mauro Rossi <issor.oruam@gmail.com> > wrote: > >> > > >> > Hello, > >> > re-sending and copying full DL > >> > > >> > On Wed, Jul 22, 2020 at 4:51 AM Alex Deucher <alexdeucher@gmail.com> > wrote: > >> >> > >> >> On Mon, Jul 20, 2020 at 6:00 AM Mauro Rossi <issor.oruam@gmail.com> > wrote: > >> >> > > >> >> > Hi Christian, > >> >> > > >> >> > On Mon, Jul 20, 2020 at 11:00 AM Christian König > >> >> > <ckoenig.leichtzumerken@gmail.com> wrote: > >> >> > > > >> >> > > Hi Mauro, > >> >> > > > >> >> > > I'm not deep into the whole DC design, so just some general high > level > >> >> > > comments on the cover letter: > >> >> > > > >> >> > > 1. Please add a subject line to the cover letter, my spam filter > thinks > >> >> > > that this is suspicious otherwise. > >> >> > > >> >> > My mistake in the editing of covert letter with git send-email, > >> >> > I may have forgot to keep the Subject at the top > >> >> > > >> >> > > > >> >> > > 2. Then you should probably note how well (badly?) is that > tested. Since > >> >> > > you noted proof of concept it might not even work. > >> >> > > >> >> > The Changelog is to be read as: > >> >> > > >> >> > [RFC] was the initial Proof of concept was the RFC and [PATCH v2] > was > >> >> > just a rebase onto amd-staging-drm-next > >> >> > > >> >> > this series [PATCH v3] has all the known changes required for DCE6 > specificity > >> >> > and based on a long offline thread with Alexander Deutcher and past > >> >> > dri-devel chats with Harry Wentland. > >> >> > > >> >> > It was tested for my possibilities of testing with HD7750 and > HD7950, > >> >> > with checks in dmesg output for not getting "missing > registers/masks" > >> >> > kernel WARNING > >> >> > and with kernel build on Ubuntu 20.04 and with android-x86 > >> >> > > >> >> > The proposal I made to Alex is that AMD testing systems will be > used > >> >> > for further regression testing, > >> >> > as part of review and validation for eligibility to > amd-staging-drm-next > >> >> > > >> >> > >> >> We will certainly test it once it lands, but presumably this is > >> >> working on the SI cards you have access to? > >> > > >> > > >> > Yes, most of my testing was done with android-x86 Android CTS (EGL, > GLES2, GLES3, VK) > >> > > >> > I am also in contact with a person with Firepro W5130M who is running > a piglit session > >> > > >> > I had bought an HD7850 to test with Pitcairn, but it arrived as > defective so I could not test with Pitcair > >> > > >> > > >> >> > >> >> > > > >> >> > > 3. How feature complete (HDMI audio?, Freesync?) is it? > >> >> > > >> >> > All the changes in DC impacting DCE8 (dc/dce80 path) were ported to > >> >> > DCE6 (dc/dce60 path) in the last two years from initial submission > >> >> > > >> >> > > > >> >> > > Apart from that it looks like a rather impressive piece of work > :) > >> >> > > > >> >> > > Cheers, > >> >> > > Christian. > >> >> > > >> >> > Thanks, > >> >> > please consider that most of the latest DCE6 specific parts were > >> >> > possible due to recent Alex support in getting the correct DCE6 > >> >> > headers, > >> >> > his suggestions and continuous feedback. > >> >> > > >> >> > I would suggest that Alex comments on the proposed next steps to > follow. > >> >> > >> >> The code looks pretty good to me. I'd like to get some feedback from > >> >> the display team to see if they have any concerns, but beyond that I > >> >> think we can pull it into the tree and continue improving it there. > >> >> Do you have a link to a git tree I can pull directly that contains > >> >> these patches? Is this the right branch? > >> >> https://github.com/maurossi/linux/commits/kernel-5.8rc4_si_next > >> >> > >> >> Thanks! > >> >> > >> >> Alex > >> > > >> > > >> > The following branch was pushed with the series on top of > amd-staging-drm-next > >> > > >> > https://github.com/maurossi/linux/commits/kernel-5.6_si_drm-next > >> > >> I gave this a quick test on all of the SI asics and the various > >> monitors I had available and it looks good. A few minor patches I > >> noticed are attached. If they look good to you, I'll squash them into > >> the series when I commit it. I've pushed it to my fdo tree as well: > >> https://cgit.freedesktop.org/~agd5f/linux/log/?h=si_dc_support > >> > >> Thanks! > >> > >> Alex > > > > > > The new patches are ok and with the following infomation about piglit > tests, > > the series may be good to go. > > > > I have performed piglit tests on Tahiti HD7950 on kernel 5.8.0-rc6 with > AMD DC support for SI > > and comparison with vanilla kernel 5.8.0-rc6 > > > > Results are the following > > > > [piglit gpu tests with kernel 5.8.0-rc6-amddcsi] > > > > utente@utente-desktop:~/piglit$ ./piglit run gpu . > > [26714/26714] skip: 1731, pass: 24669, warn: 15, fail: 288, crash: 11 > > Thank you for running Piglit! > > Results have been written to /home/utente/piglit > > > > [piglit gpu tests with vanilla 5.8.0-rc6] > > > > utente@utente-desktop:~/piglit$ ./piglit run gpu . > > [26714/26714] skip: 1731, pass: 24673, warn: 13, fail: 283, crash: 14 > > Thank you for running Piglit! > > Results have been written to /home/utente/piglit > > > > In the attachment the comparison of "5.8.0-rc6-amddcsi" vs "5.8.0-rc6" > vanilla > > and viceversa, I see no significant regression and in the delta of > failed tests I don't recognize DC related test cases, > > but you may also have a look. > > Looks good to me. The series is: > Reviewed-by: Alex Deucher <alexander.deucher@amd.com> > Thank you Alex for review and the help in finalizing the series and to Harry who initially encouraged me and provided the feedbacks to previous v2 series > > > > > dmesg for "5.8.0-rc6-amddcsi" is also provide the check the crashes > > > > Regarding the other user testing the series with Firepro W5130M > > he found an already existing issue in amdgpu si_support=1 which is > independent from my series and matches a problem alrady reported. [1] > > > > amdgpu does not currently implement GPU reset support for SI. > > Alex > If you have in the plans to add support and prevent those crashes, the user would be glad to be available for glxgears and piglit testing on Firepro W5130M Please let me know Mauro > > > Mauro > > > > [1] https://bbs.archlinux.org/viewtopic.php?id=249097 > > > >> > >> > >> > > >> >> > >> >> > >> >> > > >> >> > Mauro > >> >> > > >> >> > > > >> >> > > Am 16.07.20 um 23:22 schrieb Mauro Rossi: > >> >> > > > The series adds SI support to AMD DC > >> >> > > > > >> >> > > > Changelog: > >> >> > > > > >> >> > > > [RFC] > >> >> > > > Preliminar Proof Of Concept, with DCE8 headers still used in > dce60_resources.c > >> >> > > > > >> >> > > > [PATCH v2] > >> >> > > > Rebase on amd-staging-drm-next dated 17-Oct-2018 > >> >> > > > > >> >> > > > [PATCH v3] > >> >> > > > Add support for DCE6 specific headers, > >> >> > > > ad hoc DCE6 macros, funtions and fixes, > >> >> > > > rebase on current amd-staging-drm-next > >> >> > > > > >> >> > > > > >> >> > > > Commits [01/27]..[08/27] SI support added in various DC > components > >> >> > > > > >> >> > > > [PATCH v3 01/27] drm/amdgpu: add some required DCE6 registers > (v6) > >> >> > > > [PATCH v3 02/27] drm/amd/display: add asics info for SI parts > >> >> > > > [PATCH v3 03/27] drm/amd/display: dc/dce: add initial DCE6 > support (v9b) > >> >> > > > [PATCH v3 04/27] drm/amd/display: dc/core: add SI/DCE6 support > (v2) > >> >> > > > [PATCH v3 05/27] drm/amd/display: dc/bios: add support for DCE6 > >> >> > > > [PATCH v3 06/27] drm/amd/display: dc/gpio: add support for > DCE6 (v2) > >> >> > > > [PATCH v3 07/27] drm/amd/display: dc/irq: add support for DCE6 > (v4) > >> >> > > > [PATCH v3 08/27] drm/amd/display: amdgpu_dm: add SI support > (v4) > >> >> > > > > >> >> > > > Commits [09/27]..[24/27] DCE6 specific code adaptions > >> >> > > > > >> >> > > > [PATCH v3 09/27] drm/amd/display: dc/clk_mgr: add support for > SI parts (v2) > >> >> > > > [PATCH v3 10/27] drm/amd/display: dc/dce60: set > max_cursor_size to 64 > >> >> > > > [PATCH v3 11/27] drm/amd/display: dce_audio: add DCE6 specific > macros,functions > >> >> > > > [PATCH v3 12/27] drm/amd/display: dce_dmcu: add DCE6 specific > macros > >> >> > > > [PATCH v3 13/27] drm/amd/display: dce_hwseq: add DCE6 specific > macros,functions > >> >> > > > [PATCH v3 14/27] drm/amd/display: dce_ipp: add DCE6 specific > macros,functions > >> >> > > > [PATCH v3 15/27] drm/amd/display: dce_link_encoder: add DCE6 > specific macros,functions > >> >> > > > [PATCH v3 16/27] drm/amd/display: dce_mem_input: add DCE6 > specific macros,functions > >> >> > > > [PATCH v3 17/27] drm/amd/display: dce_opp: add DCE6 specific > macros,functions > >> >> > > > [PATCH v3 18/27] drm/amd/display: dce_transform: add DCE6 > specific macros,functions > >> >> > > > [PATCH v3 19/27] drm/amdgpu: add some required DCE6 registers > (v7) > >> >> > > > [PATCH v3 20/27] drm/amd/display: dce_transform: DCE6 Scaling > Horizontal Filter Init > >> >> > > > [PATCH v3 21/27] drm/amd/display: dce60_hw_sequencer: add DCE6 > macros,functions > >> >> > > > [PATCH v3 22/27] drm/amd/display: dce60_hw_sequencer: add DCE6 > specific .cursor_lock > >> >> > > > [PATCH v3 23/27] drm/amd/display: dce60_timing_generator: add > DCE6 specific functions > >> >> > > > [PATCH v3 24/27] drm/amd/display: dc/dce60: use DCE6 headers > (v6) > >> >> > > > > >> >> > > > > >> >> > > > Commits [25/27]..[27/27] SI support final enablements > >> >> > > > > >> >> > > > [PATCH v3 25/27] drm/amd/display: create plane rotation > property for Bonarie and later > >> >> > > > [PATCH v3 26/27] drm/amdgpu: enable DC support for SI parts > (v2) > >> >> > > > [PATCH v3 27/27] drm/amd/display: enable SI support in the > Kconfig (v2) > >> >> > > > > >> >> > > > > >> >> > > > Signed-off-by: Mauro Rossi <issor.oruam@gmail.com> > >> >> > > > > >> >> > > > _______________________________________________ > >> >> > > > amd-gfx mailing list > >> >> > > > amd-gfx@lists.freedesktop.org > >> >> > > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > >> >> > > > >> >> > _______________________________________________ > >> >> > amd-gfx mailing list > >> >> > amd-gfx@lists.freedesktop.org > >> >> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > [-- Attachment #1.2: Type: text/html, Size: 16193 bytes --] [-- Attachment #2: Type: text/plain, Size: 154 bytes --] _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-07-27 19:46 ` Re: Mauro Rossi @ 2020-07-27 19:54 ` Alex Deucher 0 siblings, 0 replies; 1767+ messages in thread From: Alex Deucher @ 2020-07-27 19:54 UTC (permalink / raw) To: Mauro Rossi Cc: Deucher, Alexander, Harry Wentland, Christian Koenig, amd-gfx list On Mon, Jul 27, 2020 at 3:46 PM Mauro Rossi <issor.oruam@gmail.com> wrote: > > > > On Mon, Jul 27, 2020 at 8:31 PM Alex Deucher <alexdeucher@gmail.com> wrote: >> >> On Sun, Jul 26, 2020 at 11:31 AM Mauro Rossi <issor.oruam@gmail.com> wrote: >> > >> > Hello, >> > >> > On Fri, Jul 24, 2020 at 8:31 PM Alex Deucher <alexdeucher@gmail.com> wrote: >> >> >> >> On Wed, Jul 22, 2020 at 3:57 AM Mauro Rossi <issor.oruam@gmail.com> wrote: >> >> > >> >> > Hello, >> >> > re-sending and copying full DL >> >> > >> >> > On Wed, Jul 22, 2020 at 4:51 AM Alex Deucher <alexdeucher@gmail.com> wrote: >> >> >> >> >> >> On Mon, Jul 20, 2020 at 6:00 AM Mauro Rossi <issor.oruam@gmail.com> wrote: >> >> >> > >> >> >> > Hi Christian, >> >> >> > >> >> >> > On Mon, Jul 20, 2020 at 11:00 AM Christian König >> >> >> > <ckoenig.leichtzumerken@gmail.com> wrote: >> >> >> > > >> >> >> > > Hi Mauro, >> >> >> > > >> >> >> > > I'm not deep into the whole DC design, so just some general high level >> >> >> > > comments on the cover letter: >> >> >> > > >> >> >> > > 1. Please add a subject line to the cover letter, my spam filter thinks >> >> >> > > that this is suspicious otherwise. >> >> >> > >> >> >> > My mistake in the editing of covert letter with git send-email, >> >> >> > I may have forgot to keep the Subject at the top >> >> >> > >> >> >> > > >> >> >> > > 2. Then you should probably note how well (badly?) is that tested. Since >> >> >> > > you noted proof of concept it might not even work. >> >> >> > >> >> >> > The Changelog is to be read as: >> >> >> > >> >> >> > [RFC] was the initial Proof of concept was the RFC and [PATCH v2] was >> >> >> > just a rebase onto amd-staging-drm-next >> >> >> > >> >> >> > this series [PATCH v3] has all the known changes required for DCE6 specificity >> >> >> > and based on a long offline thread with Alexander Deutcher and past >> >> >> > dri-devel chats with Harry Wentland. >> >> >> > >> >> >> > It was tested for my possibilities of testing with HD7750 and HD7950, >> >> >> > with checks in dmesg output for not getting "missing registers/masks" >> >> >> > kernel WARNING >> >> >> > and with kernel build on Ubuntu 20.04 and with android-x86 >> >> >> > >> >> >> > The proposal I made to Alex is that AMD testing systems will be used >> >> >> > for further regression testing, >> >> >> > as part of review and validation for eligibility to amd-staging-drm-next >> >> >> > >> >> >> >> >> >> We will certainly test it once it lands, but presumably this is >> >> >> working on the SI cards you have access to? >> >> > >> >> > >> >> > Yes, most of my testing was done with android-x86 Android CTS (EGL, GLES2, GLES3, VK) >> >> > >> >> > I am also in contact with a person with Firepro W5130M who is running a piglit session >> >> > >> >> > I had bought an HD7850 to test with Pitcairn, but it arrived as defective so I could not test with Pitcair >> >> > >> >> > >> >> >> >> >> >> > > >> >> >> > > 3. How feature complete (HDMI audio?, Freesync?) is it? >> >> >> > >> >> >> > All the changes in DC impacting DCE8 (dc/dce80 path) were ported to >> >> >> > DCE6 (dc/dce60 path) in the last two years from initial submission >> >> >> > >> >> >> > > >> >> >> > > Apart from that it looks like a rather impressive piece of work :) >> >> >> > > >> >> >> > > Cheers, >> >> >> > > Christian. >> >> >> > >> >> >> > Thanks, >> >> >> > please consider that most of the latest DCE6 specific parts were >> >> >> > possible due to recent Alex support in getting the correct DCE6 >> >> >> > headers, >> >> >> > his suggestions and continuous feedback. >> >> >> > >> >> >> > I would suggest that Alex comments on the proposed next steps to follow. >> >> >> >> >> >> The code looks pretty good to me. I'd like to get some feedback from >> >> >> the display team to see if they have any concerns, but beyond that I >> >> >> think we can pull it into the tree and continue improving it there. >> >> >> Do you have a link to a git tree I can pull directly that contains >> >> >> these patches? Is this the right branch? >> >> >> https://github.com/maurossi/linux/commits/kernel-5.8rc4_si_next >> >> >> >> >> >> Thanks! >> >> >> >> >> >> Alex >> >> > >> >> > >> >> > The following branch was pushed with the series on top of amd-staging-drm-next >> >> > >> >> > https://github.com/maurossi/linux/commits/kernel-5.6_si_drm-next >> >> >> >> I gave this a quick test on all of the SI asics and the various >> >> monitors I had available and it looks good. A few minor patches I >> >> noticed are attached. If they look good to you, I'll squash them into >> >> the series when I commit it. I've pushed it to my fdo tree as well: >> >> https://cgit.freedesktop.org/~agd5f/linux/log/?h=si_dc_support >> >> >> >> Thanks! >> >> >> >> Alex >> > >> > >> > The new patches are ok and with the following infomation about piglit tests, >> > the series may be good to go. >> > >> > I have performed piglit tests on Tahiti HD7950 on kernel 5.8.0-rc6 with AMD DC support for SI >> > and comparison with vanilla kernel 5.8.0-rc6 >> > >> > Results are the following >> > >> > [piglit gpu tests with kernel 5.8.0-rc6-amddcsi] >> > >> > utente@utente-desktop:~/piglit$ ./piglit run gpu . >> > [26714/26714] skip: 1731, pass: 24669, warn: 15, fail: 288, crash: 11 >> > Thank you for running Piglit! >> > Results have been written to /home/utente/piglit >> > >> > [piglit gpu tests with vanilla 5.8.0-rc6] >> > >> > utente@utente-desktop:~/piglit$ ./piglit run gpu . >> > [26714/26714] skip: 1731, pass: 24673, warn: 13, fail: 283, crash: 14 >> > Thank you for running Piglit! >> > Results have been written to /home/utente/piglit >> > >> > In the attachment the comparison of "5.8.0-rc6-amddcsi" vs "5.8.0-rc6" vanilla >> > and viceversa, I see no significant regression and in the delta of failed tests I don't recognize DC related test cases, >> > but you may also have a look. >> >> Looks good to me. The series is: >> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> > > > Thank you Alex for review and the help in finalizing the series > and to Harry who initially encouraged me and provided the feedbacks to previous v2 series > Thanks for sticking with this! > >> >> >> > >> > dmesg for "5.8.0-rc6-amddcsi" is also provide the check the crashes >> > >> > Regarding the other user testing the series with Firepro W5130M >> > he found an already existing issue in amdgpu si_support=1 which is independent from my series and matches a problem alrady reported. [1] >> > >> >> amdgpu does not currently implement GPU reset support for SI. >> >> Alex > > > If you have in the plans to add support and prevent those crashes, > the user would be glad to be available for glxgears and piglit testing on Firepro W5130M Initial patch here: https://patchwork.freedesktop.org/patch/380648/ Alex > > Please let me know > > Mauro > >> >> >> > Mauro >> > >> > [1] https://bbs.archlinux.org/viewtopic.php?id=249097 >> > >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> > >> >> >> > Mauro >> >> >> > >> >> >> > > >> >> >> > > Am 16.07.20 um 23:22 schrieb Mauro Rossi: >> >> >> > > > The series adds SI support to AMD DC >> >> >> > > > >> >> >> > > > Changelog: >> >> >> > > > >> >> >> > > > [RFC] >> >> >> > > > Preliminar Proof Of Concept, with DCE8 headers still used in dce60_resources.c >> >> >> > > > >> >> >> > > > [PATCH v2] >> >> >> > > > Rebase on amd-staging-drm-next dated 17-Oct-2018 >> >> >> > > > >> >> >> > > > [PATCH v3] >> >> >> > > > Add support for DCE6 specific headers, >> >> >> > > > ad hoc DCE6 macros, funtions and fixes, >> >> >> > > > rebase on current amd-staging-drm-next >> >> >> > > > >> >> >> > > > >> >> >> > > > Commits [01/27]..[08/27] SI support added in various DC components >> >> >> > > > >> >> >> > > > [PATCH v3 01/27] drm/amdgpu: add some required DCE6 registers (v6) >> >> >> > > > [PATCH v3 02/27] drm/amd/display: add asics info for SI parts >> >> >> > > > [PATCH v3 03/27] drm/amd/display: dc/dce: add initial DCE6 support (v9b) >> >> >> > > > [PATCH v3 04/27] drm/amd/display: dc/core: add SI/DCE6 support (v2) >> >> >> > > > [PATCH v3 05/27] drm/amd/display: dc/bios: add support for DCE6 >> >> >> > > > [PATCH v3 06/27] drm/amd/display: dc/gpio: add support for DCE6 (v2) >> >> >> > > > [PATCH v3 07/27] drm/amd/display: dc/irq: add support for DCE6 (v4) >> >> >> > > > [PATCH v3 08/27] drm/amd/display: amdgpu_dm: add SI support (v4) >> >> >> > > > >> >> >> > > > Commits [09/27]..[24/27] DCE6 specific code adaptions >> >> >> > > > >> >> >> > > > [PATCH v3 09/27] drm/amd/display: dc/clk_mgr: add support for SI parts (v2) >> >> >> > > > [PATCH v3 10/27] drm/amd/display: dc/dce60: set max_cursor_size to 64 >> >> >> > > > [PATCH v3 11/27] drm/amd/display: dce_audio: add DCE6 specific macros,functions >> >> >> > > > [PATCH v3 12/27] drm/amd/display: dce_dmcu: add DCE6 specific macros >> >> >> > > > [PATCH v3 13/27] drm/amd/display: dce_hwseq: add DCE6 specific macros,functions >> >> >> > > > [PATCH v3 14/27] drm/amd/display: dce_ipp: add DCE6 specific macros,functions >> >> >> > > > [PATCH v3 15/27] drm/amd/display: dce_link_encoder: add DCE6 specific macros,functions >> >> >> > > > [PATCH v3 16/27] drm/amd/display: dce_mem_input: add DCE6 specific macros,functions >> >> >> > > > [PATCH v3 17/27] drm/amd/display: dce_opp: add DCE6 specific macros,functions >> >> >> > > > [PATCH v3 18/27] drm/amd/display: dce_transform: add DCE6 specific macros,functions >> >> >> > > > [PATCH v3 19/27] drm/amdgpu: add some required DCE6 registers (v7) >> >> >> > > > [PATCH v3 20/27] drm/amd/display: dce_transform: DCE6 Scaling Horizontal Filter Init >> >> >> > > > [PATCH v3 21/27] drm/amd/display: dce60_hw_sequencer: add DCE6 macros,functions >> >> >> > > > [PATCH v3 22/27] drm/amd/display: dce60_hw_sequencer: add DCE6 specific .cursor_lock >> >> >> > > > [PATCH v3 23/27] drm/amd/display: dce60_timing_generator: add DCE6 specific functions >> >> >> > > > [PATCH v3 24/27] drm/amd/display: dc/dce60: use DCE6 headers (v6) >> >> >> > > > >> >> >> > > > >> >> >> > > > Commits [25/27]..[27/27] SI support final enablements >> >> >> > > > >> >> >> > > > [PATCH v3 25/27] drm/amd/display: create plane rotation property for Bonarie and later >> >> >> > > > [PATCH v3 26/27] drm/amdgpu: enable DC support for SI parts (v2) >> >> >> > > > [PATCH v3 27/27] drm/amd/display: enable SI support in the Kconfig (v2) >> >> >> > > > >> >> >> > > > >> >> >> > > > Signed-off-by: Mauro Rossi <issor.oruam@gmail.com> >> >> >> > > > >> >> >> > > > _______________________________________________ >> >> >> > > > amd-gfx mailing list >> >> >> > > > amd-gfx@lists.freedesktop.org >> >> >> > > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx >> >> >> > > >> >> >> > _______________________________________________ >> >> >> > amd-gfx mailing list >> >> >> > amd-gfx@lists.freedesktop.org >> >> >> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (unknown) @ 2020-06-30 17:56 Vasiliy Kupriakov 2020-07-10 20:36 ` Andy Shevchenko 0 siblings, 1 reply; 1767+ messages in thread From: Vasiliy Kupriakov @ 2020-06-30 17:56 UTC (permalink / raw) To: Corentin Chary, Darren Hart, Andy Shevchenko Cc: Vasiliy Kupriakov, open list:ASUS NOTEBOOKS AND EEEPC ACPI/WMI EXTRAS DRIVERS, open list:ASUS NOTEBOOKS AND EEEPC ACPI/WMI EXTRAS DRIVERS, open list Subject: [PATCH] platform/x86: asus-wmi: allow BAT1 battery name The battery on my laptop ASUS TUF Gaming FX706II is named BAT1. This patch allows battery extension to load. Signed-off-by: Vasiliy Kupriakov <rublag-ns@yandex.ru> --- drivers/platform/x86/asus-wmi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c index 877aade19497..8f4acdc06b13 100644 --- a/drivers/platform/x86/asus-wmi.c +++ b/drivers/platform/x86/asus-wmi.c @@ -441,6 +441,7 @@ static int asus_wmi_battery_add(struct power_supply *battery) * battery is named BATT. */ if (strcmp(battery->desc->name, "BAT0") != 0 && + strcmp(battery->desc->name, "BAT1") != 0 && strcmp(battery->desc->name, "BATT") != 0) return -ENODEV; -- 2.27.0 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2020-06-30 17:56 (unknown) Vasiliy Kupriakov @ 2020-07-10 20:36 ` Andy Shevchenko 0 siblings, 0 replies; 1767+ messages in thread From: Andy Shevchenko @ 2020-07-10 20:36 UTC (permalink / raw) To: Vasiliy Kupriakov Cc: Corentin Chary, Darren Hart, Andy Shevchenko, open list:ASUS NOTEBOOKS AND EEEPC ACPI/WMI EXTRAS DRIVERS, open list:ASUS NOTEBOOKS AND EEEPC ACPI/WMI EXTRAS DRIVERS, open list On Tue, Jun 30, 2020 at 8:57 PM Vasiliy Kupriakov <rublag-ns@yandex.ru> wrote: > > Subject: [PATCH] platform/x86: asus-wmi: allow BAT1 battery name > > The battery on my laptop ASUS TUF Gaming FX706II is named BAT1. > This patch allows battery extension to load. > Pushed to my review and testing queue, thanks! > Signed-off-by: Vasiliy Kupriakov <rublag-ns@yandex.ru> > --- > drivers/platform/x86/asus-wmi.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c > index 877aade19497..8f4acdc06b13 100644 > --- a/drivers/platform/x86/asus-wmi.c > +++ b/drivers/platform/x86/asus-wmi.c > @@ -441,6 +441,7 @@ static int asus_wmi_battery_add(struct power_supply *battery) > * battery is named BATT. > */ > if (strcmp(battery->desc->name, "BAT0") != 0 && > + strcmp(battery->desc->name, "BAT1") != 0 && > strcmp(battery->desc->name, "BATT") != 0) > return -ENODEV; > > -- > 2.27.0 > -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re; @ 2020-06-24 13:54 test02 0 siblings, 0 replies; 1767+ messages in thread From: test02 @ 2020-06-24 13:54 UTC (permalink / raw) To: Recipients Congratulations!!! As part of my humanitarian individual support during this hard times of fighting the Corona Virus (Convid-19); your email account was selected for a Donation of $1,000,000.00 USD for charity and community medical support in your area. Please contact us for more information on charles_jackson001@yahoo.com.com Send Your Response To: charles_jackson001@yahoo.com Best Regards, Charles .W. Jackson Jr -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re; @ 2020-06-24 13:54 test02 0 siblings, 0 replies; 1767+ messages in thread From: test02 @ 2020-06-24 13:54 UTC (permalink / raw) To: Recipients Congratulations!!! As part of my humanitarian individual support during this hard times of fighting the Corona Virus (Convid-19); your email account was selected for a Donation of $1,000,000.00 USD for charity and community medical support in your area. Please contact us for more information on charles_jackson001@yahoo.com.com Send Your Response To: charles_jackson001@yahoo.com Best Regards, Charles .W. Jackson Jr -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re:
@ 2020-05-21 0:22 STOREBRAND
0 siblings, 0 replies; 1767+ messages in thread
From: STOREBRAND @ 2020-05-21 0:22 UTC (permalink / raw)
To: linux-m68k
Hello,
Am Harald Hauge an Investment Manager from Norway. I wish to solicit your interest in an investment project that is currently ongoing in my company (Storebrand); It is a short term investment with good returns. Simply reply for me to confirm the validity of your email so i shall give you a comprehensive details about the project.
Best Regards,
Harald Hauge
Business Consultant
^ permalink raw reply [flat|nested] 1767+ messages in thread* (no subject) @ 2020-05-14 8:17 Maksim Iushchenko 2020-05-14 10:29 ` fboehm 0 siblings, 1 reply; 1767+ messages in thread From: Maksim Iushchenko @ 2020-05-14 8:17 UTC (permalink / raw) To: b.a.t.m.a.n Hello, I am creating a Wi-Fi ad-hoc network based on batman-adv. I read that batman-adv is able to work with any types of interfaces, but I still have a question related to ad-hoc networking. Will Wi-Fi ad-hoc network (based on batman-adv) work if Wi-Fi chip does not support 802.11s standard? Unfortunately, there is no mention of ad-hoc mode support in documentation of many Wi-Fi chips. How to check if a Wi-Fi chip is suited to be used to create a Wi-Fi ad-hoc network based on batman-adv? For example, is ATWILC3000-MR110CA an appropriate chip to build a Wi-Fi ad-hoc network based on batman-adv? Or maybe you could suggest any another Wi-Fi chips? Thanks in advance ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-05-14 8:17 Maksim Iushchenko @ 2020-05-14 10:29 ` fboehm 0 siblings, 0 replies; 1767+ messages in thread From: fboehm @ 2020-05-14 10:29 UTC (permalink / raw) To: b.a.t.m.a.n Maksim, for clarification: ATWILC3000 is a Wifi-Module for low-end embedded systems. This module consists of a Wifi-Chip + a small processor. The processor does stuff like authentication/registration with the Wifi network, WPA-Encryption and this kind of things. A typical use-case would be to add a Wifi interface to some sort of IoT device or some sort of computer peripheral device (like a Wifi-enabled printer or a smart-speaker). Looking at the driver code it might not be impossible but it's just very unlikely that you will be happy to use it in combination with Batman. You would first of all need to connect the module to a much more powerful processor that runs Linux and Batman. But assuming you anyway need such a powerful processor for your application then you have a good chance that you can use a real Wifi-Adapter (with USB or PICe interface) instead of such a Wifi-Module. Regards, Franz Am 14.05.20 um 10:17 schrieb Maksim Iushchenko: > Hello, > I am creating a Wi-Fi ad-hoc network based on batman-adv. I read that > batman-adv is able to work with any types of interfaces, but I still > have a question related to ad-hoc networking. Will Wi-Fi ad-hoc > network (based on batman-adv) work if Wi-Fi chip does not support > 802.11s standard? > Unfortunately, there is no mention of ad-hoc mode support in > documentation of many Wi-Fi chips. > > How to check if a Wi-Fi chip is suited to be used to create a Wi-Fi > ad-hoc network based on batman-adv? > > For example, is ATWILC3000-MR110CA an appropriate chip to build a > Wi-Fi ad-hoc network based on batman-adv? Or maybe you could suggest > any another Wi-Fi chips? > > Thanks in advance ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2020-05-06 5:52 Jiaxun Yang 2020-05-06 17:17 ` Nick Desaulniers 0 siblings, 1 reply; 1767+ messages in thread From: Jiaxun Yang @ 2020-05-06 5:52 UTC (permalink / raw) To: linux-mips Cc: Jiaxun Yang, clang-built-linux, Maciej W . Rozycki, Fangrui Song, Kees Cook, Nathan Chancellor, Thomas Bogendoerfer, Paul Burton, Masahiro Yamada, Jouni Hogander, Kevin Darbyshire-Bryant, Borislav Petkov, Heiko Carstens, linux-kernel Subject: [PATCH v6] MIPS: Truncate link address into 32bit for 32bit kernel In-Reply-To: <20200413062651.3992652-1-jiaxun.yang@flygoat.com> LLD failed to link vmlinux with 64bit load address for 32bit ELF while bfd will strip 64bit address into 32bit silently. To fix LLD build, we should truncate load address provided by platform into 32bit for 32bit kernel. Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Link: https://github.com/ClangBuiltLinux/linux/issues/786 Link: https://sourceware.org/bugzilla/show_bug.cgi?id=25784 Reviewed-by: Fangrui Song <maskray@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> --- V2: Take MaskRay's shell magic. V3: After spent an hour on dealing with special character issue in Makefile, I gave up to do shell hacks and write a util in C instead. Thanks Maciej for pointing out Makefile variable problem. v4: Finally we managed to find a Makefile method to do it properly thanks to Kees. As it's too far from the initial version, I removed Review & Test tag from Nick and Fangrui and Cc instead. v5: Care vmlinuz as well. v6: Rename to LIKER_LOAD_ADDRESS --- arch/mips/Makefile | 13 ++++++++++++- arch/mips/boot/compressed/Makefile | 2 +- arch/mips/kernel/vmlinux.lds.S | 2 +- 3 files changed, 14 insertions(+), 3 deletions(-) diff --git a/arch/mips/Makefile b/arch/mips/Makefile index e1c44aed8156..68c0f22fefc0 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -288,12 +288,23 @@ ifdef CONFIG_64BIT endif endif +# When linking a 32-bit executable the LLVM linker cannot cope with a +# 32-bit load address that has been sign-extended to 64 bits. Simply +# remove the upper 32 bits then, as it is safe to do so with other +# linkers. +ifdef CONFIG_64BIT + load-ld = $(load-y) +else + load-ld = $(subst 0xffffffff,0x,$(load-y)) +endif + KBUILD_AFLAGS += $(cflags-y) KBUILD_CFLAGS += $(cflags-y) -KBUILD_CPPFLAGS += -DVMLINUX_LOAD_ADDRESS=$(load-y) +KBUILD_CPPFLAGS += -DVMLINUX_LOAD_ADDRESS=$(load-y) -DLINKER_LOAD_ADDRESS=$(load-ld) KBUILD_CPPFLAGS += -DDATAOFFSET=$(if $(dataoffset-y),$(dataoffset-y),0) bootvars-y = VMLINUX_LOAD_ADDRESS=$(load-y) \ + LINKER_LOAD_ADDRESS=$(load-ld) \ VMLINUX_ENTRY_ADDRESS=$(entry-y) \ PLATFORM="$(platform-y)" \ ITS_INPUTS="$(its-y)" diff --git a/arch/mips/boot/compressed/Makefile b/arch/mips/boot/compressed/Makefile index 0df0ee8a298d..3d391256ab7e 100644 --- a/arch/mips/boot/compressed/Makefile +++ b/arch/mips/boot/compressed/Makefile @@ -90,7 +90,7 @@ ifneq ($(zload-y),) VMLINUZ_LOAD_ADDRESS := $(zload-y) else VMLINUZ_LOAD_ADDRESS = $(shell $(obj)/calc_vmlinuz_load_addr \ - $(obj)/vmlinux.bin $(VMLINUX_LOAD_ADDRESS)) + $(obj)/vmlinux.bin $(LINKER_LOAD_ADDRESS)) endif UIMAGE_LOADADDR = $(VMLINUZ_LOAD_ADDRESS) diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S index a5f00ec73ea6..5226cd8e4bee 100644 --- a/arch/mips/kernel/vmlinux.lds.S +++ b/arch/mips/kernel/vmlinux.lds.S @@ -55,7 +55,7 @@ SECTIONS /* . = 0xa800000000300000; */ . = 0xffffffff80300000; #endif - . = VMLINUX_LOAD_ADDRESS; + . = LINKER_LOAD_ADDRESS; /* read-only */ _text = .; /* Text and read-only data */ .text : { ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2020-05-06 5:52 Jiaxun Yang @ 2020-05-06 17:17 ` Nick Desaulniers 0 siblings, 0 replies; 1767+ messages in thread From: Nick Desaulniers @ 2020-05-06 17:17 UTC (permalink / raw) To: Jiaxun Yang Cc: linux-mips, clang-built-linux, Maciej W . Rozycki, Fangrui Song, Kees Cook, Nathan Chancellor, Thomas Bogendoerfer, Paul Burton, Masahiro Yamada, Jouni Hogander, Kevin Darbyshire-Bryant, Borislav Petkov, Heiko Carstens, LKML On Tue, May 5, 2020 at 10:52 PM Jiaxun Yang <jiaxun.yang@flygoat.com> wrote: > > Subject: [PATCH v6] MIPS: Truncate link address into 32bit for 32bit kernel > In-Reply-To: <20200413062651.3992652-1-jiaxun.yang@flygoat.com> > > LLD failed to link vmlinux with 64bit load address for 32bit ELF > while bfd will strip 64bit address into 32bit silently. > To fix LLD build, we should truncate load address provided by platform > into 32bit for 32bit kernel. > > Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> > Link: https://github.com/ClangBuiltLinux/linux/issues/786 > Link: https://sourceware.org/bugzilla/show_bug.cgi?id=25784 > Reviewed-by: Fangrui Song <maskray@google.com> > Reviewed-by: Kees Cook <keescook@chromium.org> > Tested-by: Nathan Chancellor <natechancellor@gmail.com> > Cc: Maciej W. Rozycki <macro@linux-mips.org> Cool, this revision looks a bit simpler. Thanks for chasing this. Tested-by: Nick Desaulniers <ndesaulniers@google.com> > --- > V2: Take MaskRay's shell magic. > > V3: After spent an hour on dealing with special character issue in > Makefile, I gave up to do shell hacks and write a util in C instead. > Thanks Maciej for pointing out Makefile variable problem. > > v4: Finally we managed to find a Makefile method to do it properly > thanks to Kees. As it's too far from the initial version, I removed > Review & Test tag from Nick and Fangrui and Cc instead. > > v5: Care vmlinuz as well. > > v6: Rename to LIKER_LOAD_ADDRESS > --- > arch/mips/Makefile | 13 ++++++++++++- > arch/mips/boot/compressed/Makefile | 2 +- > arch/mips/kernel/vmlinux.lds.S | 2 +- > 3 files changed, 14 insertions(+), 3 deletions(-) > > diff --git a/arch/mips/Makefile b/arch/mips/Makefile > index e1c44aed8156..68c0f22fefc0 100644 > --- a/arch/mips/Makefile > +++ b/arch/mips/Makefile > @@ -288,12 +288,23 @@ ifdef CONFIG_64BIT > endif > endif > > +# When linking a 32-bit executable the LLVM linker cannot cope with a > +# 32-bit load address that has been sign-extended to 64 bits. Simply > +# remove the upper 32 bits then, as it is safe to do so with other > +# linkers. > +ifdef CONFIG_64BIT > + load-ld = $(load-y) > +else > + load-ld = $(subst 0xffffffff,0x,$(load-y)) > +endif > + > KBUILD_AFLAGS += $(cflags-y) > KBUILD_CFLAGS += $(cflags-y) > -KBUILD_CPPFLAGS += -DVMLINUX_LOAD_ADDRESS=$(load-y) > +KBUILD_CPPFLAGS += -DVMLINUX_LOAD_ADDRESS=$(load-y) -DLINKER_LOAD_ADDRESS=$(load-ld) > KBUILD_CPPFLAGS += -DDATAOFFSET=$(if $(dataoffset-y),$(dataoffset-y),0) > > bootvars-y = VMLINUX_LOAD_ADDRESS=$(load-y) \ > + LINKER_LOAD_ADDRESS=$(load-ld) \ > VMLINUX_ENTRY_ADDRESS=$(entry-y) \ > PLATFORM="$(platform-y)" \ > ITS_INPUTS="$(its-y)" > diff --git a/arch/mips/boot/compressed/Makefile b/arch/mips/boot/compressed/Makefile > index 0df0ee8a298d..3d391256ab7e 100644 > --- a/arch/mips/boot/compressed/Makefile > +++ b/arch/mips/boot/compressed/Makefile > @@ -90,7 +90,7 @@ ifneq ($(zload-y),) > VMLINUZ_LOAD_ADDRESS := $(zload-y) > else > VMLINUZ_LOAD_ADDRESS = $(shell $(obj)/calc_vmlinuz_load_addr \ > - $(obj)/vmlinux.bin $(VMLINUX_LOAD_ADDRESS)) > + $(obj)/vmlinux.bin $(LINKER_LOAD_ADDRESS)) > endif > UIMAGE_LOADADDR = $(VMLINUZ_LOAD_ADDRESS) > > diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S > index a5f00ec73ea6..5226cd8e4bee 100644 > --- a/arch/mips/kernel/vmlinux.lds.S > +++ b/arch/mips/kernel/vmlinux.lds.S > @@ -55,7 +55,7 @@ SECTIONS > /* . = 0xa800000000300000; */ > . = 0xffffffff80300000; > #endif > - . = VMLINUX_LOAD_ADDRESS; > + . = LINKER_LOAD_ADDRESS; > /* read-only */ > _text = .; /* Text and read-only data */ > .text : { > > -- -- Thanks, ~Nick Desaulniers ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2020-04-18 12:26 Levi Brown 0 siblings, 0 replies; 1767+ messages in thread From: Levi Brown @ 2020-04-18 12:26 UTC (permalink / raw) To: linux-sh LS0gDQrjgYLjgarjgZ/jgajoqbHjgZfjgZ/jgYTjgafjgZnjgIIg56eB44Gu5Lul5YmN44Gu44Oh 44O844Or44KS5Y+X44GR5Y+W44KK44G+44GX44Gf44GL77yfDQo ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <CAPXXXSDVGeEK_NCSkDMwTpuvVxYkWGdQk=L=bz+RN4XLiGZmcg@mail.gmail.com>]
[parent not found: <CAPXXXSBYcU1QamovmP-gVTXms67Xi_QpMCV=V3570q1nnuWqNw@mail.gmail.com>]
* Re: [not found] ` <CAPXXXSBYcU1QamovmP-gVTXms67Xi_QpMCV=V3570q1nnuWqNw@mail.gmail.com> @ 2020-04-04 21:05 ` Ruslan Bilovol 2020-04-05 1:27 ` Re: Alan Stern 0 siblings, 1 reply; 1767+ messages in thread From: Ruslan Bilovol @ 2020-04-04 21:05 UTC (permalink / raw) To: Colin Williams, Linux USB, alsa-devel Hi, Please also add to CC related mailing lists (alsa-devel, linux-usb) rather then directly emailing - community may also help with the issue. Also it can be googled so if somebody else have same issue it can find answers faster. On Fri, Apr 3, 2020 at 10:56 AM Colin Williams <colin.williams.seattle@gmail.com> wrote: > > https://ubuntuforums.org/showthread.php?t=2439897 > > On Thu, Apr 2, 2020 at 4:50 PM Colin Williams <colin.williams.seattle@gmail.com> wrote: >> >> Hello, >> >> Is it possible that one of these commits or related broke support for the Blue Mic Yeti? >> >> https://github.com/torvalds/linux/blame/ac438771ccb4479528594c7e19f2c39cf1814a86/sound/usb/stream.c#L816 Tha'ts workaround to ignore last altsetting which is the same as previous. During UAC3 implementation, I reimplemented that workaround carefully, but I didn't have (and still do not own) any Blue Mic USB device. I don't know whether it was tested after that by anyone. >> >> I am getting the following when I plug my mic in: Which kernel version is that? Have you tried latest Linux Kernel? >> >> [ 1283.848740] usb 1-1.2: new full-speed USB device number 82 using ehci-pci >> [ 1283.964802] usb 1-1.2: New USB device found, idVendor=b58e, idProduct=9e84, bcdDevice= 1.00 >> [ 1283.964808] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 >> [ 1283.964810] usb 1-1.2: Product: Yeti Stereo Microphone >> [ 1283.964812] usb 1-1.2: Manufacturer: Blue Microphones >> [ 1284.080671] usb 1-1.3: new low-speed USB device number 83 using ehci-pci >> [ 1284.784678] usb 1-1.3: device descriptor read/64, error -32 >> [ 1285.180674] usb 1-1.3: device descriptor read/64, error -32 >> [ 1285.992682] usb 1-1.3: new low-speed USB device number 84 using ehci-pci >> [ 1286.696672] usb 1-1.3: device descriptor read/64, error -32 >> [ 1287.092695] usb 1-1.3: device descriptor read/64, error -32 >> [ 1287.200804] usb 1-1-port3: attempt power cycle >> [ 1287.804662] usb 1-1.3: new low-speed USB device number 85 using ehci-pci >> [ 1288.220686] usb 1-1.3: device not accepting address 85, error -32 >> [ 1288.508685] usb 1-1.3: new low-speed USB device number 86 using ehci-pci >> [ 1288.924690] usb 1-1.3: device not accepting address 86, error -32 >> [ 1288.924916] usb 1-1-port3: unable to enumerate USB device >> [ 1288.925391] usb 1-1.2: USB disconnect, device number 82 >> [ 1289.308736] usb 1-1.3: new low-speed USB device number 87 using ehci-pci >> [ 1289.596727] usb 1-1.3: device descriptor read/64, error -32 >> [ 1289.992635] usb 1-1.3: device descriptor read/64, error -32 >> [ 1290.596683] usb 1-1.3: new low-speed USB device number 88 using ehci-pci >> [ 1290.888718] usb 1-1.3: device descriptor read/64, error -32 >> [ 1291.284673] usb 1-1.3: device descriptor read/64, error -32 >> [ 1291.392928] usb 1-1-port3: attempt power cycle Looking at this log, it seems the issue happens during enumeration, so mentioned workaround isn't executed yet at this moment. So it seems this is related to USB core, not to ALSA driver. Thanks, Ruslan >> >> Furthermore, there is some evidence this is happening to other users: >> >> https://askubuntu.com/questions/1027188/external-yeti-michrophone-not-detected-on-ubuntu-18-04 >> >> Best Regards, >> >> Colin Williams >> >> ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-04-04 21:05 ` Re: Ruslan Bilovol @ 2020-04-05 1:27 ` Alan Stern 0 siblings, 0 replies; 1767+ messages in thread From: Alan Stern @ 2020-04-05 1:27 UTC (permalink / raw) To: Ruslan Bilovol; +Cc: alsa-devel, Linux USB, Colin Williams On Sun, 5 Apr 2020, Ruslan Bilovol wrote: > Hi, > > Please also add to CC related mailing lists (alsa-devel, linux-usb) rather > then directly emailing - community may also help with the issue. Also it can be > googled so if somebody else have same issue it can find answers faster. > > On Fri, Apr 3, 2020 at 10:56 AM Colin Williams > <colin.williams.seattle@gmail.com> wrote: > > > > https://ubuntuforums.org/showthread.php?t=2439897 > > > > On Thu, Apr 2, 2020 at 4:50 PM Colin Williams <colin.williams.seattle@gmail.com> wrote: > >> > >> Hello, > >> > >> Is it possible that one of these commits or related broke support for the Blue Mic Yeti? > >> > >> https://github.com/torvalds/linux/blame/ac438771ccb4479528594c7e19f2c39cf1814a86/sound/usb/stream.c#L816 > > Tha'ts workaround to ignore last altsetting which is the same as previous. > During UAC3 implementation, I reimplemented that workaround carefully, > but I didn't have (and still do not own) any Blue Mic USB device. > I don't know whether it was tested after that by anyone. > > >> > >> I am getting the following when I plug my mic in: > > Which kernel version is that? Have you tried latest Linux Kernel? > > >> > >> [ 1283.848740] usb 1-1.2: new full-speed USB device number 82 using ehci-pci > >> [ 1283.964802] usb 1-1.2: New USB device found, idVendor=b58e, idProduct=9e84, bcdDevice= 1.00 > >> [ 1283.964808] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > >> [ 1283.964810] usb 1-1.2: Product: Yeti Stereo Microphone > >> [ 1283.964812] usb 1-1.2: Manufacturer: Blue Microphones > >> [ 1284.080671] usb 1-1.3: new low-speed USB device number 83 using ehci-pci > >> [ 1284.784678] usb 1-1.3: device descriptor read/64, error -32 > >> [ 1285.180674] usb 1-1.3: device descriptor read/64, error -32 > >> [ 1285.992682] usb 1-1.3: new low-speed USB device number 84 using ehci-pci > >> [ 1286.696672] usb 1-1.3: device descriptor read/64, error -32 > >> [ 1287.092695] usb 1-1.3: device descriptor read/64, error -32 > >> [ 1287.200804] usb 1-1-port3: attempt power cycle > >> [ 1287.804662] usb 1-1.3: new low-speed USB device number 85 using ehci-pci > >> [ 1288.220686] usb 1-1.3: device not accepting address 85, error -32 > >> [ 1288.508685] usb 1-1.3: new low-speed USB device number 86 using ehci-pci > >> [ 1288.924690] usb 1-1.3: device not accepting address 86, error -32 > >> [ 1288.924916] usb 1-1-port3: unable to enumerate USB device > >> [ 1288.925391] usb 1-1.2: USB disconnect, device number 82 > >> [ 1289.308736] usb 1-1.3: new low-speed USB device number 87 using ehci-pci > >> [ 1289.596727] usb 1-1.3: device descriptor read/64, error -32 > >> [ 1289.992635] usb 1-1.3: device descriptor read/64, error -32 > >> [ 1290.596683] usb 1-1.3: new low-speed USB device number 88 using ehci-pci > >> [ 1290.888718] usb 1-1.3: device descriptor read/64, error -32 > >> [ 1291.284673] usb 1-1.3: device descriptor read/64, error -32 > >> [ 1291.392928] usb 1-1-port3: attempt power cycle > > Looking at this log, it seems the issue happens during enumeration, > so mentioned workaround isn't executed yet at this moment. > So it seems this is related to USB core, not to ALSA driver. All those errors were for the 1-1.3 device. The microphone was 1-1.2. It's not clear from the log above what the relationship between those two devices is, but it sure looks like the microphone was enumerated okay. What shows up in /sys/kernel/debug/usb/devices? Alan Stern ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2020-04-05 1:27 ` Alan Stern 0 siblings, 0 replies; 1767+ messages in thread From: Alan Stern @ 2020-04-05 1:27 UTC (permalink / raw) To: Ruslan Bilovol; +Cc: Colin Williams, Linux USB, alsa-devel On Sun, 5 Apr 2020, Ruslan Bilovol wrote: > Hi, > > Please also add to CC related mailing lists (alsa-devel, linux-usb) rather > then directly emailing - community may also help with the issue. Also it can be > googled so if somebody else have same issue it can find answers faster. > > On Fri, Apr 3, 2020 at 10:56 AM Colin Williams > <colin.williams.seattle@gmail.com> wrote: > > > > https://ubuntuforums.org/showthread.php?t=2439897 > > > > On Thu, Apr 2, 2020 at 4:50 PM Colin Williams <colin.williams.seattle@gmail.com> wrote: > >> > >> Hello, > >> > >> Is it possible that one of these commits or related broke support for the Blue Mic Yeti? > >> > >> https://github.com/torvalds/linux/blame/ac438771ccb4479528594c7e19f2c39cf1814a86/sound/usb/stream.c#L816 > > Tha'ts workaround to ignore last altsetting which is the same as previous. > During UAC3 implementation, I reimplemented that workaround carefully, > but I didn't have (and still do not own) any Blue Mic USB device. > I don't know whether it was tested after that by anyone. > > >> > >> I am getting the following when I plug my mic in: > > Which kernel version is that? Have you tried latest Linux Kernel? > > >> > >> [ 1283.848740] usb 1-1.2: new full-speed USB device number 82 using ehci-pci > >> [ 1283.964802] usb 1-1.2: New USB device found, idVendor=b58e, idProduct=9e84, bcdDevice= 1.00 > >> [ 1283.964808] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > >> [ 1283.964810] usb 1-1.2: Product: Yeti Stereo Microphone > >> [ 1283.964812] usb 1-1.2: Manufacturer: Blue Microphones > >> [ 1284.080671] usb 1-1.3: new low-speed USB device number 83 using ehci-pci > >> [ 1284.784678] usb 1-1.3: device descriptor read/64, error -32 > >> [ 1285.180674] usb 1-1.3: device descriptor read/64, error -32 > >> [ 1285.992682] usb 1-1.3: new low-speed USB device number 84 using ehci-pci > >> [ 1286.696672] usb 1-1.3: device descriptor read/64, error -32 > >> [ 1287.092695] usb 1-1.3: device descriptor read/64, error -32 > >> [ 1287.200804] usb 1-1-port3: attempt power cycle > >> [ 1287.804662] usb 1-1.3: new low-speed USB device number 85 using ehci-pci > >> [ 1288.220686] usb 1-1.3: device not accepting address 85, error -32 > >> [ 1288.508685] usb 1-1.3: new low-speed USB device number 86 using ehci-pci > >> [ 1288.924690] usb 1-1.3: device not accepting address 86, error -32 > >> [ 1288.924916] usb 1-1-port3: unable to enumerate USB device > >> [ 1288.925391] usb 1-1.2: USB disconnect, device number 82 > >> [ 1289.308736] usb 1-1.3: new low-speed USB device number 87 using ehci-pci > >> [ 1289.596727] usb 1-1.3: device descriptor read/64, error -32 > >> [ 1289.992635] usb 1-1.3: device descriptor read/64, error -32 > >> [ 1290.596683] usb 1-1.3: new low-speed USB device number 88 using ehci-pci > >> [ 1290.888718] usb 1-1.3: device descriptor read/64, error -32 > >> [ 1291.284673] usb 1-1.3: device descriptor read/64, error -32 > >> [ 1291.392928] usb 1-1-port3: attempt power cycle > > Looking at this log, it seems the issue happens during enumeration, > so mentioned workaround isn't executed yet at this moment. > So it seems this is related to USB core, not to ALSA driver. All those errors were for the 1-1.3 device. The microphone was 1-1.2. It's not clear from the log above what the relationship between those two devices is, but it sure looks like the microphone was enumerated okay. What shows up in /sys/kernel/debug/usb/devices? Alan Stern ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <CAPXXXSBLHYdHNSS4aM2Ax07+GQSB1WbPziOrk0iVWf-LXLmQRg@mail.gmail.com>]
[parent not found: <CAPXXXSAajets4AqcBKt8aRd8V1AL4bjAmCyuBOKr8qBG-AHO1A@mail.gmail.com>]
* Re: [not found] ` <CAPXXXSAajets4AqcBKt8aRd8V1AL4bjAmCyuBOKr8qBG-AHO1A@mail.gmail.com> @ 2020-04-05 2:51 ` Colin Williams 0 siblings, 0 replies; 1767+ messages in thread From: Colin Williams @ 2020-04-05 2:51 UTC (permalink / raw) To: Alan Stern; +Cc: Ruslan Bilovol, Linux USB, alsa-devel Hello all This is embarrassing but I think my issues were due to a bad USB cable. Thank You On Sat, Apr 4, 2020 at 7:50 PM Colin Williams <colin.williams.seattle@gmail.com> wrote: > > Hello all > > > This is embarrassing but I think my issues were due to a bad USB cable. > > > Thank You > >> >> On Sat, Apr 4, 2020 at 6:27 PM Alan Stern <stern@rowland.harvard.edu> wrote: >>> >>> On Sun, 5 Apr 2020, Ruslan Bilovol wrote: >>> >>> > Hi, >>> > >>> > Please also add to CC related mailing lists (alsa-devel, linux-usb) rather >>> > then directly emailing - community may also help with the issue. Also it can be >>> > googled so if somebody else have same issue it can find answers faster. >>> > >>> > On Fri, Apr 3, 2020 at 10:56 AM Colin Williams >>> > <colin.williams.seattle@gmail.com> wrote: >>> > > >>> > > https://ubuntuforums.org/showthread.php?t=2439897 >>> > > >>> > > On Thu, Apr 2, 2020 at 4:50 PM Colin Williams <colin.williams.seattle@gmail.com> wrote: >>> > >> >>> > >> Hello, >>> > >> >>> > >> Is it possible that one of these commits or related broke support for the Blue Mic Yeti? >>> > >> >>> > >> https://github.com/torvalds/linux/blame/ac438771ccb4479528594c7e19f2c39cf1814a86/sound/usb/stream.c#L816 >>> > >>> > Tha'ts workaround to ignore last altsetting which is the same as previous. >>> > During UAC3 implementation, I reimplemented that workaround carefully, >>> > but I didn't have (and still do not own) any Blue Mic USB device. >>> > I don't know whether it was tested after that by anyone. >>> > >>> > >> >>> > >> I am getting the following when I plug my mic in: >>> > >>> > Which kernel version is that? Have you tried latest Linux Kernel? >>> > >>> > >> >>> > >> [ 1283.848740] usb 1-1.2: new full-speed USB device number 82 using ehci-pci >>> > >> [ 1283.964802] usb 1-1.2: New USB device found, idVendor=b58e, idProduct=9e84, bcdDevice= 1.00 >>> > >> [ 1283.964808] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 >>> > >> [ 1283.964810] usb 1-1.2: Product: Yeti Stereo Microphone >>> > >> [ 1283.964812] usb 1-1.2: Manufacturer: Blue Microphones >>> > >> [ 1284.080671] usb 1-1.3: new low-speed USB device number 83 using ehci-pci >>> > >> [ 1284.784678] usb 1-1.3: device descriptor read/64, error -32 >>> > >> [ 1285.180674] usb 1-1.3: device descriptor read/64, error -32 >>> > >> [ 1285.992682] usb 1-1.3: new low-speed USB device number 84 using ehci-pci >>> > >> [ 1286.696672] usb 1-1.3: device descriptor read/64, error -32 >>> > >> [ 1287.092695] usb 1-1.3: device descriptor read/64, error -32 >>> > >> [ 1287.200804] usb 1-1-port3: attempt power cycle >>> > >> [ 1287.804662] usb 1-1.3: new low-speed USB device number 85 using ehci-pci >>> > >> [ 1288.220686] usb 1-1.3: device not accepting address 85, error -32 >>> > >> [ 1288.508685] usb 1-1.3: new low-speed USB device number 86 using ehci-pci >>> > >> [ 1288.924690] usb 1-1.3: device not accepting address 86, error -32 >>> > >> [ 1288.924916] usb 1-1-port3: unable to enumerate USB device >>> > >> [ 1288.925391] usb 1-1.2: USB disconnect, device number 82 >>> > >> [ 1289.308736] usb 1-1.3: new low-speed USB device number 87 using ehci-pci >>> > >> [ 1289.596727] usb 1-1.3: device descriptor read/64, error -32 >>> > >> [ 1289.992635] usb 1-1.3: device descriptor read/64, error -32 >>> > >> [ 1290.596683] usb 1-1.3: new low-speed USB device number 88 using ehci-pci >>> > >> [ 1290.888718] usb 1-1.3: device descriptor read/64, error -32 >>> > >> [ 1291.284673] usb 1-1.3: device descriptor read/64, error -32 >>> > >> [ 1291.392928] usb 1-1-port3: attempt power cycle >>> > >>> > Looking at this log, it seems the issue happens during enumeration, >>> > so mentioned workaround isn't executed yet at this moment. >>> > So it seems this is related to USB core, not to ALSA driver. >>> >>> All those errors were for the 1-1.3 device. The microphone was 1-1.2. >>> It's not clear from the log above what the relationship between those >>> two devices is, but it sure looks like the microphone was enumerated >>> okay. >>> >>> What shows up in /sys/kernel/debug/usb/devices? >>> >>> Alan Stern >>> ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (unknown)
@ 2020-03-27 9:20 chenanqing
[not found] ` <5e7dc543.vYG3wru8B/me1sOV%chenanqing-Oq79sGaMObY@public.gmane.org>
0 siblings, 1 reply; 1767+ messages in thread
From: chenanqing @ 2020-03-27 9:20 UTC (permalink / raw)
To: chenanqing, linux-kernel, linux-scsi, open-iscsi, ceph-devel,
martin.petersen, jejb, cleech, lduncan
From: Chen Anqing <chenanqing@oppo.com>
To: Lee Duncan <lduncan@suse.com>
Cc: Chris Leech <cleech@redhat.com>,
"James E . J . Bottomley" <jejb@linux.ibm.com>,
"Martin K . Petersen" <martin.petersen@oracle.com>,
ceph-devel@vger.kernel.org,
open-iscsi@googlegroups.com,
linux-scsi@vger.kernel.org,
linux-kernel@vger.kernel.org,
chenanqing@oppo.com
Subject: [PATCH] scsi: libiscsi: we should take compound page into account also
Date: Fri, 27 Mar 2020 05:20:01 -0400
Message-Id: <20200327092001.56879-1-chenanqing@oppo.com>
X-Mailer: git-send-email 2.18.2
the patch is occur at a real crash,which slab is
come from a compound page,so we need take the compound page
into account also.
fixed commit 08b11eaccfcf ("scsi: libiscsi: fall back to
sendmsg for slab pages").
Signed-off-by: Chen Anqing <chenanqing@oppo.com>
---
drivers/scsi/libiscsi_tcp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/libiscsi_tcp.c b/drivers/scsi/libiscsi_tcp.c
index 6ef93c7af954..98304e5e1f6f 100644
--- a/drivers/scsi/libiscsi_tcp.c
+++ b/drivers/scsi/libiscsi_tcp.c
@@ -128,7 +128,8 @@ static void iscsi_tcp_segment_map(struct iscsi_segment *segment, int recv)
* coalescing neighboring slab objects into a single frag which
* triggers one of hardened usercopy checks.
*/
- if (!recv && page_count(sg_page(sg)) >= 1 && !PageSlab(sg_page(sg)))
+ if (!recv && page_count(sg_page(sg)) >= 1 &&
+ !PageSlab(compound_head(sg_page(sg))))
return;
if (recv) {
--
2.18.2
________________________________
OPPO
本电子邮件及其附件含有OPPO公司的保密信息，仅限于邮件指明的收件人使用（包含个人及群组）。禁止任何人在未经授权的情况下以任何形式使用。如果您错收了本邮件，请立即以电子邮件通知发件人并删除本邮件及其附件。
This e-mail and its attachments contain confidential information from OPPO, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
^ permalink raw reply related [flat|nested] 1767+ messages in thread[parent not found: <5e7dc543.vYG3wru8B/me1sOV%chenanqing-Oq79sGaMObY@public.gmane.org>]
* Re: 2020-03-27 9:20 (unknown) chenanqing @ 2020-03-27 15:53 ` Lee Duncan 0 siblings, 0 replies; 1767+ messages in thread From: Lee Duncan @ 2020-03-27 15:53 UTC (permalink / raw) To: chenanqing-Oq79sGaMObY, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-scsi-u79uwXL29TY76Z2rM5mHXA, open-iscsi-/JYPxA39Uh5TLH3MbocFFw, ceph-devel-u79uwXL29TY76Z2rM5mHXA, martin.petersen-QHcLZuEGTsvQT0dZR+AlfA, jejb-tEXmvtCZX7AybS5Ee8rs3A, cleech-H+wXaHxf7aLQT0dZR+AlfA On 3/27/20 2:20 AM, chenanqing-Oq79sGaMObY@public.gmane.org wrote: > From: Chen Anqing <chenanqing-Oq79sGaMObY@public.gmane.org> > To: Lee Duncan <lduncan-IBi9RG/b67k@public.gmane.org> > Cc: Chris Leech <cleech-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, > "James E . J . Bottomley" <jejb-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>, > "Martin K . Petersen" <martin.petersen-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>, > ceph-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, > open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, > linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, > linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, > chenanqing-Oq79sGaMObY@public.gmane.org > Subject: [PATCH] scsi: libiscsi: we should take compound page into account also > Date: Fri, 27 Mar 2020 05:20:01 -0400 > Message-Id: <20200327092001.56879-1-chenanqing-Oq79sGaMObY@public.gmane.org> > X-Mailer: git-send-email 2.18.2 > > the patch is occur at a real crash,which slab is > come from a compound page,so we need take the compound page > into account also. > fixed commit 08b11eaccfcf ("scsi: libiscsi: fall back to > sendmsg for slab pages"). > > Signed-off-by: Chen Anqing <chenanqing-Oq79sGaMObY@public.gmane.org> > --- > drivers/scsi/libiscsi_tcp.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/scsi/libiscsi_tcp.c b/drivers/scsi/libiscsi_tcp.c > index 6ef93c7af954..98304e5e1f6f 100644 > --- a/drivers/scsi/libiscsi_tcp.c > +++ b/drivers/scsi/libiscsi_tcp.c > @@ -128,7 +128,8 @@ static void iscsi_tcp_segment_map(struct iscsi_segment *segment, int recv) > * coalescing neighboring slab objects into a single frag which > * triggers one of hardened usercopy checks. > */ > - if (!recv && page_count(sg_page(sg)) >= 1 && !PageSlab(sg_page(sg))) > + if (!recv && page_count(sg_page(sg)) >= 1 && > + !PageSlab(compound_head(sg_page(sg)))) > return; > > if (recv) { > -- > 2.18.2 > This is missing a proper subject ... -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/5462bc04-8409-a0c3-628f-640d1c92b8c6%40suse.com. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2020-03-27 15:53 ` Lee Duncan 0 siblings, 0 replies; 1767+ messages in thread From: Lee Duncan @ 2020-03-27 15:53 UTC (permalink / raw) To: chenanqing, linux-kernel, linux-scsi, open-iscsi, ceph-devel, martin.petersen, jejb, cleech On 3/27/20 2:20 AM, chenanqing@oppo.com wrote: > From: Chen Anqing <chenanqing@oppo.com> > To: Lee Duncan <lduncan@suse.com> > Cc: Chris Leech <cleech@redhat.com>, > "James E . J . Bottomley" <jejb@linux.ibm.com>, > "Martin K . Petersen" <martin.petersen@oracle.com>, > ceph-devel@vger.kernel.org, > open-iscsi@googlegroups.com, > linux-scsi@vger.kernel.org, > linux-kernel@vger.kernel.org, > chenanqing@oppo.com > Subject: [PATCH] scsi: libiscsi: we should take compound page into account also > Date: Fri, 27 Mar 2020 05:20:01 -0400 > Message-Id: <20200327092001.56879-1-chenanqing@oppo.com> > X-Mailer: git-send-email 2.18.2 > > the patch is occur at a real crash,which slab is > come from a compound page,so we need take the compound page > into account also. > fixed commit 08b11eaccfcf ("scsi: libiscsi: fall back to > sendmsg for slab pages"). > > Signed-off-by: Chen Anqing <chenanqing@oppo.com> > --- > drivers/scsi/libiscsi_tcp.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/scsi/libiscsi_tcp.c b/drivers/scsi/libiscsi_tcp.c > index 6ef93c7af954..98304e5e1f6f 100644 > --- a/drivers/scsi/libiscsi_tcp.c > +++ b/drivers/scsi/libiscsi_tcp.c > @@ -128,7 +128,8 @@ static void iscsi_tcp_segment_map(struct iscsi_segment *segment, int recv) > * coalescing neighboring slab objects into a single frag which > * triggers one of hardened usercopy checks. > */ > - if (!recv && page_count(sg_page(sg)) >= 1 && !PageSlab(sg_page(sg))) > + if (!recv && page_count(sg_page(sg)) >= 1 && > + !PageSlab(compound_head(sg_page(sg)))) > return; > > if (recv) { > -- > 2.18.2 > This is missing a proper subject ... ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (unknown)
@ 2020-03-27 8:36 chenanqing
2020-03-27 8:59 ` Ilya Dryomov
0 siblings, 1 reply; 1767+ messages in thread
From: chenanqing @ 2020-03-27 8:36 UTC (permalink / raw)
To: chenanqing, linux-kernel, netdev, ceph-devel, kuba, sage, jlayton,
idryomov
From: Chen Anqing <chenanqing@oppo.com>
To: Ilya Dryomov <idryomov@gmail.com>
Cc: Jeff Layton <jlayton@kernel.org>,
Sage Weil <sage@redhat.com>,
Jakub Kicinski <kuba@kernel.org>,
ceph-devel@vger.kernel.org,
netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
chenanqing@oppo.com
Subject: [PATCH] libceph: we should take compound page into account also
Date: Fri, 27 Mar 2020 04:36:30 -0400
Message-Id: <20200327083630.36296-1-chenanqing@oppo.com>
X-Mailer: git-send-email 2.18.2
the patch is occur at a real crash,which slab is
come from a compound page,so we need take the compound page
into account also.
fixed commit 7e241f647dc7 ("libceph: fall back to sendmsg for slab pages")'
Signed-off-by: Chen Anqing <chenanqing@oppo.com>
---
net/ceph/messenger.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ceph/messenger.c b/net/ceph/messenger.c
index f8ca5edc5f2c..e08c1c334cd9 100644
--- a/net/ceph/messenger.c
+++ b/net/ceph/messenger.c
@@ -582,7 +582,7 @@ static int ceph_tcp_sendpage(struct socket *sock, struct page *page,
* coalescing neighboring slab objects into a single frag which
* triggers one of hardened usercopy checks.
*/
- if (page_count(page) >= 1 && !PageSlab(page))
+ if (page_count(page) >= 1 && !PageSlab(compound_head(page)))
sendpage = sock->ops->sendpage;
else
sendpage = sock_no_sendpage;
--
2.18.2
________________________________
OPPO
本电子邮件及其附件含有OPPO公司的保密信息，仅限于邮件指明的收件人使用（包含个人及群组）。禁止任何人在未经授权的情况下以任何形式使用。如果您错收了本邮件，请立即以电子邮件通知发件人并删除本邮件及其附件。
This e-mail and its attachments contain confidential information from OPPO, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
^ permalink raw reply related [flat|nested] 1767+ messages in thread* Re: 2020-03-27 8:36 (unknown) chenanqing @ 2020-03-27 8:59 ` Ilya Dryomov 0 siblings, 0 replies; 1767+ messages in thread From: Ilya Dryomov @ 2020-03-27 8:59 UTC (permalink / raw) To: chenanqing; +Cc: LKML, netdev, Ceph Development, kuba, Sage Weil, Jeff Layton On Fri, Mar 27, 2020 at 9:36 AM <chenanqing@oppo.com> wrote: > > From: Chen Anqing <chenanqing@oppo.com> > To: Ilya Dryomov <idryomov@gmail.com> > Cc: Jeff Layton <jlayton@kernel.org>, > Sage Weil <sage@redhat.com>, > Jakub Kicinski <kuba@kernel.org>, > ceph-devel@vger.kernel.org, > netdev@vger.kernel.org, > linux-kernel@vger.kernel.org, > chenanqing@oppo.com > Subject: [PATCH] libceph: we should take compound page into account also > Date: Fri, 27 Mar 2020 04:36:30 -0400 > Message-Id: <20200327083630.36296-1-chenanqing@oppo.com> > X-Mailer: git-send-email 2.18.2 > > the patch is occur at a real crash,which slab is > come from a compound page,so we need take the compound page > into account also. > fixed commit 7e241f647dc7 ("libceph: fall back to sendmsg for slab pages")' > > Signed-off-by: Chen Anqing <chenanqing@oppo.com> > --- > net/ceph/messenger.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/ceph/messenger.c b/net/ceph/messenger.c > index f8ca5edc5f2c..e08c1c334cd9 100644 > --- a/net/ceph/messenger.c > +++ b/net/ceph/messenger.c > @@ -582,7 +582,7 @@ static int ceph_tcp_sendpage(struct socket *sock, struct page *page, > * coalescing neighboring slab objects into a single frag which > * triggers one of hardened usercopy checks. > */ > - if (page_count(page) >= 1 && !PageSlab(page)) > + if (page_count(page) >= 1 && !PageSlab(compound_head(page))) > sendpage = sock->ops->sendpage; > else > sendpage = sock_no_sendpage; Hi Chen, AFAICT compound pages should already be taken into account, because PageSlab is defined as: __PAGEFLAG(Slab, slab, PF_NO_TAIL) #define __PAGEFLAG(uname, lname, policy) \ TESTPAGEFLAG(uname, lname, policy) \ __SETPAGEFLAG(uname, lname, policy) \ __CLEARPAGEFLAG(uname, lname, policy) #define TESTPAGEFLAG(uname, lname, policy) \ static __always_inline int Page##uname(struct page *page) \ { return test_bit(PG_##lname, &policy(page, 0)->flags); } and PF_NO_TAIL policy is defined as: #define PF_NO_TAIL(page, enforce) ({ \ VM_BUG_ON_PGFLAGS(enforce && PageTail(page), page); \ PF_POISONED_CHECK(compound_head(page)); }) So compound_head() is called behind the scenes. Could you please explain what crash did you observe in more detail? Perhaps you backported this patch to an older kernel? Thanks, Ilya ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <CALeDE9OeBx6v6nGVjeydgF1vpfX1Bus319h3M1=49PMETdaCtw@mail.gmail.com>]
* Re: [not found] <CALeDE9OeBx6v6nGVjeydgF1vpfX1Bus319h3M1=49PMETdaCtw@mail.gmail.com> @ 2020-03-20 11:49 ` Josh Boyer 0 siblings, 0 replies; 1767+ messages in thread From: Josh Boyer @ 2020-03-20 11:49 UTC (permalink / raw) To: Peter Robinson; +Cc: Linux Firmware On Fri, Mar 20, 2020 at 7:47 AM Peter Robinson <pbrobinson@gmail.com> wrote: > > subscribe linux-firmware isn't a mailing list. It's an alias for the maintainers. You can find a lore instance for it though! https://lore.kernel.org/linux-firmware/ josh ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2020-03-16 23:07 Sankalp Bhardwaj 2020-03-17 9:13 ` Valdis Klētnieks 0 siblings, 1 reply; 1767+ messages in thread From: Sankalp Bhardwaj @ 2020-03-16 23:07 UTC (permalink / raw) To: kernelnewbies [-- Attachment #1.1: Type: text/plain, Size: 122 bytes --] Where to get started?? I am interested in understanding how the kernel works but have no prior knowledge... Please help!! [-- Attachment #1.2: Type: text/html, Size: 146 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-03-16 23:07 Sankalp Bhardwaj @ 2020-03-17 9:13 ` Valdis Klētnieks 2020-03-17 10:10 ` Re: suvrojit 0 siblings, 1 reply; 1767+ messages in thread From: Valdis Klētnieks @ 2020-03-17 9:13 UTC (permalink / raw) To: Sankalp Bhardwaj; +Cc: kernelnewbies [-- Attachment #1.1: Type: text/plain, Size: 1820 bytes --] On Tue, 17 Mar 2020 04:37:58 +0530, Sankalp Bhardwaj said: > Where to get started?? I am interested in understanding how the > kernel works but have no prior knowledge... Please help!! A good place to start is to realize that the answers often depend on what the question is - and there's usually a difference between the question that is asked, and the question that the person needs the answer for. You probably want to read this: https://lists.kernelnewbies.org/pipermail/kernelnewbies/2017-April/017765.html Something that you'll need is a good understanding of operating system concepts. Almost all modern computer systems have some idea of basic concepts such as processes, files, a directory structure, security and permissions, scheduling, locking, and so on. And for most of these, there is more than one way to accomplish the goal. So two books that are useful to read for a compare-and-contrast view are Bach's book on the System V kernel, and McKusic's book on the BSD kernel - both go into details of *why* some things are done they are. It's really helpful to see stuff like "We need to lock this inode while we do X, because otherwise another thread could concurrently do Y, and then Bad Thing Z will happen". Of course, a Linux filesystem that does things differently won't have the same exact issues, but understanding the *sort* of things that break when you screw up your locking is quite the useful info, especially if most of your coding has been in userspace where single-threaded is common and libraries did their own locking when needed. I admit that I also learned a bunch from Tanenbaum's "Modern Operating Systems", but that was a long long time ago in a galaxy far far away, and I have no idea what the cool kids are reading instead these days... [-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-03-17 9:13 ` Valdis Klētnieks @ 2020-03-17 10:10 ` suvrojit 0 siblings, 0 replies; 1767+ messages in thread From: suvrojit @ 2020-03-17 10:10 UTC (permalink / raw) To: Valdis Klētnieks; +Cc: kernelnewbies, Sankalp Bhardwaj [-- Attachment #1.1: Type: text/plain, Size: 2247 bytes --] ULK by Bovet Cessati is the book u should start reading Sankalp On Tue, Mar 17, 2020, 2:44 PM Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote: > On Tue, 17 Mar 2020 04:37:58 +0530, Sankalp Bhardwaj said: > > > Where to get started?? I am interested in understanding how the > > kernel works but have no prior knowledge... Please help!! > > A good place to start is to realize that the answers often depend on what > the > question is - and there's usually a difference between the question that is > asked, and the question that the person needs the answer for. You probably > want to read this: > > > https://lists.kernelnewbies.org/pipermail/kernelnewbies/2017-April/017765.html > > Something that you'll need is a good understanding of operating system > concepts. Almost all modern computer systems have some idea of basic > concepts > such as processes, files, a directory structure, security and permissions, > scheduling, locking, and so on. And for most of these, there is more than > one > way to accomplish the goal. > > So two books that are useful to read for a compare-and-contrast view are > Bach's > book on the System V kernel, and McKusic's book on the BSD kernel - both go > into details of *why* some things are done they are. It's really helpful > to > see stuff like "We need to lock this inode while we do X, because otherwise > another thread could concurrently do Y, and then Bad Thing Z will happen". > > Of course, a Linux filesystem that does things differently won't have the > same > exact issues, but understanding the *sort* of things that break when you > screw > up your locking is quite the useful info, especially if most of your > coding has > been in userspace where single-threaded is common and libraries did their > own > locking when needed. > > I admit that I also learned a bunch from Tanenbaum's "Modern Operating > Systems", but that was a long long time ago in a galaxy far far away, and I > have no idea what the cool kids are reading instead these days... > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > [-- Attachment #1.2: Type: text/html, Size: 2959 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2020-03-08 19:12 Francois Pinault 0 siblings, 0 replies; 1767+ messages in thread From: Francois Pinault @ 2020-03-08 19:12 UTC (permalink / raw) To: target-devel A donation was made in your favour by Francois Pinault, reply for more details. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2020-03-08 17:33 Francois Pinault 0 siblings, 0 replies; 1767+ messages in thread From: Francois Pinault @ 2020-03-08 17:33 UTC (permalink / raw) A donation was made in your favour by Francois Pinault, reply for more details. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2020-03-08 17:33 ` Francois Pinault 0 siblings, 0 replies; 1767+ messages in thread From: Francois Pinault @ 2020-03-08 17:33 UTC (permalink / raw) To: linux-fbdev A donation was made in your favour by Francois Pinault, reply for more details. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2020-03-08 17:33 ` Francois Pinault 0 siblings, 0 replies; 1767+ messages in thread From: Francois Pinault @ 2020-03-08 17:33 UTC (permalink / raw) A donation was made in your favour by Francois Pinault, reply for more details. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2020-03-08 17:19 Francois Pinault 0 siblings, 0 replies; 1767+ messages in thread From: Francois Pinault @ 2020-03-08 17:19 UTC (permalink / raw) To: keyrings A donation was made in your favour by Francois Pinault, reply for more details. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2020-03-03 15:27 Gene Chen 2020-03-04 14:56 ` Re: Matthias Brugger 0 siblings, 1 reply; 1767+ messages in thread From: Gene Chen @ 2020-03-03 15:27 UTC (permalink / raw) To: lee.jones, matthias.bgg Cc: gene_chen, linux-kernel, cy_huang, linux-mediatek, Wilma.Wu, linux-arm-kernel, shufan_lee Add mfd driver for mt6360 pmic chip include Battery Charger/USB_PD/Flash LED/RGB LED/LDO/Buck Signed-off-by: Gene Chen <gene_chen@richtek.com --- drivers/mfd/Kconfig | 12 ++ drivers/mfd/Makefile | 1 + drivers/mfd/mt6360-core.c | 425 +++++++++++++++++++++++++++++++++++++++++++++ include/linux/mfd/mt6360.h | 240 +++++++++++++++++++++++++ 4 files changed, 678 insertions(+) create mode 100644 drivers/mfd/mt6360-core.c create mode 100644 include/linux/mfd/mt6360.h changelogs between v1 & v2 - include missing header file changelogs between v2 & v3 - add changelogs changelogs between v3 & v4 - fix Kconfig description - replace mt6360_pmu_info with mt6360_pmu_data - replace probe with probe_new - remove unnecessary irq_chip variable - remove annotation - replace MT6360_MFD_CELL with OF_MFD_CELL changelogs between v4 & v5 - remove unnecessary parse dt function - use devm_i2c_new_dummy_device - add base-commit message changelogs between v5 & v6 - review return value - remove i2c id_table - use GPL license v2 changelogs between v6 & v7 - add author description - replace MT6360_REGMAP_IRQ_REG by REGMAP_IRQ_REG_LINE - remove mt6360-private.h changelogs between v7 & v8 - fix kbuild auto reboot by include interrupt header diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 2b20329..0f8c341 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -857,6 +857,18 @@ config MFD_MAX8998 additional drivers must be enabled in order to use the functionality of the device. +config MFD_MT6360 + tristate "Mediatek MT6360 SubPMIC" + select MFD_CORE + select REGMAP_I2C + select REGMAP_IRQ + depends on I2C + help + Say Y here to enable MT6360 PMU/PMIC/LDO functional support. + PMU part includes Charger, Flashlight, RGB LED + PMIC part includes 2-channel BUCKs and 2-channel LDOs + LDO part includes 4-channel LDOs + config MFD_MT6397 tristate "MediaTek MT6397 PMIC Support" select MFD_CORE diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index b83f172..8c35816 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -238,6 +238,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI) += intel_soc_pmic_chtdc_ti.o +obj-$(CONFIG_MFD_MT6360) += mt6360-core.o mt6397-objs := mt6397-core.o mt6397-irq.o obj-$(CONFIG_MFD_MT6397) += mt6397.o obj-$(CONFIG_INTEL_SOC_PMIC_MRFLD) += intel_soc_pmic_mrfld.o diff --git a/drivers/mfd/mt6360-core.c b/drivers/mfd/mt6360-core.c new file mode 100644 index 0000000..d1168f8 --- /dev/null +++ b/drivers/mfd/mt6360-core.c @@ -0,0 +1,425 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2019 MediaTek Inc. + * + * Author: Gene Chen <gene_chen@richtek.com> + */ + +#include <linux/i2c.h> +#include <linux/init.h> +#include <linux/interrupt.h> +#include <linux/kernel.h> +#include <linux/mfd/core.h> +#include <linux/module.h> +#include <linux/of_irq.h> +#include <linux/of_platform.h> +#include <linux/version.h> + +#include <linux/mfd/mt6360.h> + +/* reg 0 -> 0 ~ 7 */ +#define MT6360_CHG_TREG_EVT (4) +#define MT6360_CHG_AICR_EVT (5) +#define MT6360_CHG_MIVR_EVT (6) +#define MT6360_PWR_RDY_EVT (7) +/* REG 1 -> 8 ~ 15 */ +#define MT6360_CHG_BATSYSUV_EVT (9) +#define MT6360_FLED_CHG_VINOVP_EVT (11) +#define MT6360_CHG_VSYSUV_EVT (12) +#define MT6360_CHG_VSYSOV_EVT (13) +#define MT6360_CHG_VBATOV_EVT (14) +#define MT6360_CHG_VBUSOV_EVT (15) +/* REG 2 -> 16 ~ 23 */ +/* REG 3 -> 24 ~ 31 */ +#define MT6360_WD_PMU_DET (25) +#define MT6360_WD_PMU_DONE (26) +#define MT6360_CHG_TMRI (27) +#define MT6360_CHG_ADPBADI (29) +#define MT6360_CHG_RVPI (30) +#define MT6360_OTPI (31) +/* REG 4 -> 32 ~ 39 */ +#define MT6360_CHG_AICCMEASL (32) +#define MT6360_CHGDET_DONEI (34) +#define MT6360_WDTMRI (35) +#define MT6360_SSFINISHI (36) +#define MT6360_CHG_RECHGI (37) +#define MT6360_CHG_TERMI (38) +#define MT6360_CHG_IEOCI (39) +/* REG 5 -> 40 ~ 47 */ +#define MT6360_PUMPX_DONEI (40) +#define MT6360_BAT_OVP_ADC_EVT (41) +#define MT6360_TYPEC_OTP_EVT (42) +#define MT6360_ADC_WAKEUP_EVT (43) +#define MT6360_ADC_DONEI (44) +#define MT6360_BST_BATUVI (45) +#define MT6360_BST_VBUSOVI (46) +#define MT6360_BST_OLPI (47) +/* REG 6 -> 48 ~ 55 */ +#define MT6360_ATTACH_I (48) +#define MT6360_DETACH_I (49) +#define MT6360_QC30_STPDONE (51) +#define MT6360_QC_VBUSDET_DONE (52) +#define MT6360_HVDCP_DET (53) +#define MT6360_CHGDETI (54) +#define MT6360_DCDTI (55) +/* REG 7 -> 56 ~ 63 */ +#define MT6360_FOD_DONE_EVT (56) +#define MT6360_FOD_OV_EVT (57) +#define MT6360_CHRDET_UVP_EVT (58) +#define MT6360_CHRDET_OVP_EVT (59) +#define MT6360_CHRDET_EXT_EVT (60) +#define MT6360_FOD_LR_EVT (61) +#define MT6360_FOD_HR_EVT (62) +#define MT6360_FOD_DISCHG_FAIL_EVT (63) +/* REG 8 -> 64 ~ 71 */ +#define MT6360_USBID_EVT (64) +#define MT6360_APWDTRST_EVT (65) +#define MT6360_EN_EVT (66) +#define MT6360_QONB_RST_EVT (67) +#define MT6360_MRSTB_EVT (68) +#define MT6360_OTP_EVT (69) +#define MT6360_VDDAOV_EVT (70) +#define MT6360_SYSUV_EVT (71) +/* REG 9 -> 72 ~ 79 */ +#define MT6360_FLED_STRBPIN_EVT (72) +#define MT6360_FLED_TORPIN_EVT (73) +#define MT6360_FLED_TX_EVT (74) +#define MT6360_FLED_LVF_EVT (75) +#define MT6360_FLED2_SHORT_EVT (78) +#define MT6360_FLED1_SHORT_EVT (79) +/* REG 10 -> 80 ~ 87 */ +#define MT6360_FLED2_STRB_EVT (80) +#define MT6360_FLED1_STRB_EVT (81) +#define MT6360_FLED2_STRB_TO_EVT (82) +#define MT6360_FLED1_STRB_TO_EVT (83) +#define MT6360_FLED2_TOR_EVT (84) +#define MT6360_FLED1_TOR_EVT (85) +/* REG 11 -> 88 ~ 95 */ +/* REG 12 -> 96 ~ 103 */ +#define MT6360_BUCK1_PGB_EVT (96) +#define MT6360_BUCK1_OC_EVT (100) +#define MT6360_BUCK1_OV_EVT (101) +#define MT6360_BUCK1_UV_EVT (102) +/* REG 13 -> 104 ~ 111 */ +#define MT6360_BUCK2_PGB_EVT (104) +#define MT6360_BUCK2_OC_EVT (108) +#define MT6360_BUCK2_OV_EVT (109) +#define MT6360_BUCK2_UV_EVT (110) +/* REG 14 -> 112 ~ 119 */ +#define MT6360_LDO1_OC_EVT (113) +#define MT6360_LDO2_OC_EVT (114) +#define MT6360_LDO3_OC_EVT (115) +#define MT6360_LDO5_OC_EVT (117) +#define MT6360_LDO6_OC_EVT (118) +#define MT6360_LDO7_OC_EVT (119) +/* REG 15 -> 120 ~ 127 */ +#define MT6360_LDO1_PGB_EVT (121) +#define MT6360_LDO2_PGB_EVT (122) +#define MT6360_LDO3_PGB_EVT (123) +#define MT6360_LDO5_PGB_EVT (125) +#define MT6360_LDO6_PGB_EVT (126) +#define MT6360_LDO7_PGB_EVT (127) + +static const struct regmap_irq mt6360_pmu_irqs[] = { + REGMAP_IRQ_REG_LINE(MT6360_CHG_TREG_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_CHG_AICR_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_CHG_MIVR_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_PWR_RDY_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_CHG_BATSYSUV_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_FLED_CHG_VINOVP_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_CHG_VSYSUV_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_CHG_VSYSOV_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_CHG_VBATOV_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_CHG_VBUSOV_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_WD_PMU_DET, 8), + REGMAP_IRQ_REG_LINE(MT6360_WD_PMU_DONE, 8), + REGMAP_IRQ_REG_LINE(MT6360_CHG_TMRI, 8), + REGMAP_IRQ_REG_LINE(MT6360_CHG_ADPBADI, 8), + REGMAP_IRQ_REG_LINE(MT6360_CHG_RVPI, 8), + REGMAP_IRQ_REG_LINE(MT6360_OTPI, 8), + REGMAP_IRQ_REG_LINE(MT6360_CHG_AICCMEASL, 8), + REGMAP_IRQ_REG_LINE(MT6360_CHGDET_DONEI, 8), + REGMAP_IRQ_REG_LINE(MT6360_WDTMRI, 8), + REGMAP_IRQ_REG_LINE(MT6360_SSFINISHI, 8), + REGMAP_IRQ_REG_LINE(MT6360_CHG_RECHGI, 8), + REGMAP_IRQ_REG_LINE(MT6360_CHG_TERMI, 8), + REGMAP_IRQ_REG_LINE(MT6360_CHG_IEOCI, 8), + REGMAP_IRQ_REG_LINE(MT6360_PUMPX_DONEI, 8), + REGMAP_IRQ_REG_LINE(MT6360_CHG_TREG_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_BAT_OVP_ADC_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_TYPEC_OTP_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_ADC_WAKEUP_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_ADC_DONEI, 8), + REGMAP_IRQ_REG_LINE(MT6360_BST_BATUVI, 8), + REGMAP_IRQ_REG_LINE(MT6360_BST_VBUSOVI, 8), + REGMAP_IRQ_REG_LINE(MT6360_BST_OLPI, 8), + REGMAP_IRQ_REG_LINE(MT6360_ATTACH_I, 8), + REGMAP_IRQ_REG_LINE(MT6360_DETACH_I, 8), + REGMAP_IRQ_REG_LINE(MT6360_QC30_STPDONE, 8), + REGMAP_IRQ_REG_LINE(MT6360_QC_VBUSDET_DONE, 8), + REGMAP_IRQ_REG_LINE(MT6360_HVDCP_DET, 8), + REGMAP_IRQ_REG_LINE(MT6360_CHGDETI, 8), + REGMAP_IRQ_REG_LINE(MT6360_DCDTI, 8), + REGMAP_IRQ_REG_LINE(MT6360_FOD_DONE_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_FOD_OV_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_CHRDET_UVP_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_CHRDET_OVP_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_CHRDET_EXT_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_FOD_LR_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_FOD_HR_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_FOD_DISCHG_FAIL_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_USBID_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_APWDTRST_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_EN_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_QONB_RST_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_MRSTB_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_OTP_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_VDDAOV_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_SYSUV_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_FLED_STRBPIN_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_FLED_TORPIN_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_FLED_TX_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_FLED_LVF_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_FLED2_SHORT_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_FLED1_SHORT_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_FLED2_STRB_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_FLED1_STRB_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_FLED2_STRB_TO_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_FLED1_STRB_TO_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_FLED2_TOR_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_FLED1_TOR_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_BUCK1_PGB_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_BUCK1_OC_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_BUCK1_OV_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_BUCK1_UV_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_BUCK2_PGB_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_BUCK2_OC_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_BUCK2_OV_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_BUCK2_UV_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_LDO1_OC_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_LDO2_OC_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_LDO3_OC_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_LDO5_OC_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_LDO6_OC_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_LDO7_OC_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_LDO1_PGB_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_LDO2_PGB_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_LDO3_PGB_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_LDO5_PGB_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_LDO6_PGB_EVT, 8), + REGMAP_IRQ_REG_LINE(MT6360_LDO7_PGB_EVT, 8), +}; + +static int mt6360_pmu_handle_post_irq(void *irq_drv_data) +{ + struct mt6360_pmu_data *mpd = irq_drv_data; + + return regmap_update_bits(mpd->regmap, + MT6360_PMU_IRQ_SET, MT6360_IRQ_RETRIG, MT6360_IRQ_RETRIG); +} + +static struct regmap_irq_chip mt6360_pmu_irq_chip = { + .irqs = mt6360_pmu_irqs, + .num_irqs = ARRAY_SIZE(mt6360_pmu_irqs), + .num_regs = MT6360_PMU_IRQ_REGNUM, + .mask_base = MT6360_PMU_CHG_MASK1, + .status_base = MT6360_PMU_CHG_IRQ1, + .ack_base = MT6360_PMU_CHG_IRQ1, + .init_ack_masked = true, + .use_ack = true, + .handle_post_irq = mt6360_pmu_handle_post_irq, +}; + +static const struct regmap_config mt6360_pmu_regmap_config = { + .reg_bits = 8, + .val_bits = 8, + .max_register = MT6360_PMU_MAXREG, +}; + +static const struct resource mt6360_adc_resources[] = { + DEFINE_RES_IRQ_NAMED(MT6360_ADC_DONEI, "adc_donei"), +}; + +static const struct resource mt6360_chg_resources[] = { + DEFINE_RES_IRQ_NAMED(MT6360_CHG_TREG_EVT, "chg_treg_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_PWR_RDY_EVT, "pwr_rdy_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_CHG_BATSYSUV_EVT, "chg_batsysuv_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VSYSUV_EVT, "chg_vsysuv_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VSYSOV_EVT, "chg_vsysov_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VBATOV_EVT, "chg_vbatov_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VBUSOV_EVT, "chg_vbusov_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_CHG_AICCMEASL, "chg_aiccmeasl"), + DEFINE_RES_IRQ_NAMED(MT6360_WDTMRI, "wdtmri"), + DEFINE_RES_IRQ_NAMED(MT6360_CHG_RECHGI, "chg_rechgi"), + DEFINE_RES_IRQ_NAMED(MT6360_CHG_TERMI, "chg_termi"), + DEFINE_RES_IRQ_NAMED(MT6360_CHG_IEOCI, "chg_ieoci"), + DEFINE_RES_IRQ_NAMED(MT6360_PUMPX_DONEI, "pumpx_donei"), + DEFINE_RES_IRQ_NAMED(MT6360_ATTACH_I, "attach_i"), + DEFINE_RES_IRQ_NAMED(MT6360_CHRDET_EXT_EVT, "chrdet_ext_evt"), +}; + +static const struct resource mt6360_led_resources[] = { + DEFINE_RES_IRQ_NAMED(MT6360_FLED_CHG_VINOVP_EVT, "fled_chg_vinovp_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_FLED_LVF_EVT, "fled_lvf_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_FLED2_SHORT_EVT, "fled2_short_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_FLED1_SHORT_EVT, "fled1_short_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_FLED2_STRB_TO_EVT, "fled2_strb_to_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_FLED1_STRB_TO_EVT, "fled1_strb_to_evt"), +}; + +static const struct resource mt6360_pmic_resources[] = { + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_PGB_EVT, "buck1_pgb_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_OC_EVT, "buck1_oc_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_OV_EVT, "buck1_ov_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_UV_EVT, "buck1_uv_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_PGB_EVT, "buck2_pgb_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_OC_EVT, "buck2_oc_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_OV_EVT, "buck2_ov_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_UV_EVT, "buck2_uv_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_LDO6_OC_EVT, "ldo6_oc_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_LDO7_OC_EVT, "ldo7_oc_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_LDO6_PGB_EVT, "ldo6_pgb_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_LDO7_PGB_EVT, "ldo7_pgb_evt"), +}; + +static const struct resource mt6360_ldo_resources[] = { + DEFINE_RES_IRQ_NAMED(MT6360_LDO1_OC_EVT, "ldo1_oc_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_LDO2_OC_EVT, "ldo2_oc_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_LDO3_OC_EVT, "ldo3_oc_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_LDO5_OC_EVT, "ldo5_oc_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_LDO1_PGB_EVT, "ldo1_pgb_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_LDO2_PGB_EVT, "ldo2_pgb_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_LDO3_PGB_EVT, "ldo3_pgb_evt"), + DEFINE_RES_IRQ_NAMED(MT6360_LDO5_PGB_EVT, "ldo5_pgb_evt"), +}; + +static const struct mfd_cell mt6360_devs[] = { + OF_MFD_CELL("mt6360_adc", mt6360_adc_resources, + NULL, 0, 0, "mediatek,mt6360_adc"), + OF_MFD_CELL("mt6360_chg", mt6360_chg_resources, + NULL, 0, 0, "mediatek,mt6360_chg"), + OF_MFD_CELL("mt6360_led", mt6360_led_resources, + NULL, 0, 0, "mediatek,mt6360_led"), + OF_MFD_CELL("mt6360_pmic", mt6360_pmic_resources, + NULL, 0, 0, "mediatek,mt6360_pmic"), + OF_MFD_CELL("mt6360_ldo", mt6360_ldo_resources, + NULL, 0, 0, "mediatek,mt6360_ldo"), + OF_MFD_CELL("mt6360_tcpc", NULL, + NULL, 0, 0, "mediatek,mt6360_tcpc"), +}; + +static const unsigned short mt6360_slave_addr[MT6360_SLAVE_MAX] = { + MT6360_PMU_SLAVEID, + MT6360_PMIC_SLAVEID, + MT6360_LDO_SLAVEID, + MT6360_TCPC_SLAVEID, +}; + +static int mt6360_pmu_probe(struct i2c_client *client) +{ + struct mt6360_pmu_data *mpd; + unsigned int reg_data; + int i, ret; + + mpd = devm_kzalloc(&client->dev, sizeof(*mpd), GFP_KERNEL); + if (!mpd) + return -ENOMEM; + + mpd->dev = &client->dev; + i2c_set_clientdata(client, mpd); + + mpd->regmap = devm_regmap_init_i2c(client, &mt6360_pmu_regmap_config); + if (IS_ERR(mpd->regmap)) { + dev_err(&client->dev, "Failed to register regmap\n"); + return PTR_ERR(mpd->regmap); + } + + ret = regmap_read(mpd->regmap, MT6360_PMU_DEV_INFO, ®_data); + if (ret) { + dev_err(&client->dev, "Device not found\n"); + return ret; + } + + mpd->chip_rev = reg_data & CHIP_REV_MASK; + if (mpd->chip_rev != CHIP_VEN_MT6360) { + dev_err(&client->dev, "Device not supported\n"); + return -ENODEV; + } + + mt6360_pmu_irq_chip.irq_drv_data = mpd; + ret = devm_regmap_add_irq_chip(&client->dev, mpd->regmap, client->irq, + IRQF_TRIGGER_FALLING, 0, + &mt6360_pmu_irq_chip, &mpd->irq_data); + if (ret) { + dev_err(&client->dev, "Failed to add Regmap IRQ Chip\n"); + return ret; + } + + mpd->i2c[0] = client; + for (i = 1; i < MT6360_SLAVE_MAX; i++) { + mpd->i2c[i] = devm_i2c_new_dummy_device(&client->dev, + client->adapter, + mt6360_slave_addr[i]); + if (IS_ERR(mpd->i2c[i])) { + dev_err(&client->dev, + "Failed to get new dummy I2C device for address 0x%x", + mt6360_slave_addr[i]); + return PTR_ERR(mpd->i2c[i]); + } + i2c_set_clientdata(mpd->i2c[i], mpd); + } + + ret = devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_AUTO, + mt6360_devs, ARRAY_SIZE(mt6360_devs), NULL, + 0, regmap_irq_get_domain(mpd->irq_data)); + if (ret) { + dev_err(&client->dev, + "Failed to register subordinate devices\n"); + return ret; + } + + return 0; +} + +static int __maybe_unused mt6360_pmu_suspend(struct device *dev) +{ + struct i2c_client *i2c = to_i2c_client(dev); + + if (device_may_wakeup(dev)) + enable_irq_wake(i2c->irq); + + return 0; +} + +static int __maybe_unused mt6360_pmu_resume(struct device *dev) +{ + + struct i2c_client *i2c = to_i2c_client(dev); + + if (device_may_wakeup(dev)) + disable_irq_wake(i2c->irq); + + return 0; +} + +static SIMPLE_DEV_PM_OPS(mt6360_pmu_pm_ops, + mt6360_pmu_suspend, mt6360_pmu_resume); + +static const struct of_device_id __maybe_unused mt6360_pmu_of_id[] = { + { .compatible = "mediatek,mt6360_pmu", }, + {}, +}; +MODULE_DEVICE_TABLE(of, mt6360_pmu_of_id); + +static struct i2c_driver mt6360_pmu_driver = { + .driver = { + .pm = &mt6360_pmu_pm_ops, + .of_match_table = of_match_ptr(mt6360_pmu_of_id), + }, + .probe_new = mt6360_pmu_probe, +}; +module_i2c_driver(mt6360_pmu_driver); + +MODULE_AUTHOR("Gene Chen <gene_chen@richtek.com>"); +MODULE_DESCRIPTION("MT6360 PMU I2C Driver"); +MODULE_LICENSE("GPL v2"); diff --git a/include/linux/mfd/mt6360.h b/include/linux/mfd/mt6360.h new file mode 100644 index 0000000..c03e6d1 --- /dev/null +++ b/include/linux/mfd/mt6360.h @@ -0,0 +1,240 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (c) 2019 MediaTek Inc. + */ + +#ifndef __MT6360_H__ +#define __MT6360_H__ + +#include <linux/regmap.h> + +enum { + MT6360_SLAVE_PMU = 0, + MT6360_SLAVE_PMIC, + MT6360_SLAVE_LDO, + MT6360_SLAVE_TCPC, + MT6360_SLAVE_MAX, +}; + +#define MT6360_PMU_SLAVEID (0x34) +#define MT6360_PMIC_SLAVEID (0x1A) +#define MT6360_LDO_SLAVEID (0x64) +#define MT6360_TCPC_SLAVEID (0x4E) + +struct mt6360_pmu_data { + struct i2c_client *i2c[MT6360_SLAVE_MAX]; + struct device *dev; + struct regmap *regmap; + struct regmap_irq_chip_data *irq_data; + unsigned int chip_rev; +}; + +/* PMU register defininition */ +#define MT6360_PMU_DEV_INFO (0x00) +#define MT6360_PMU_CORE_CTRL1 (0x01) +#define MT6360_PMU_RST1 (0x02) +#define MT6360_PMU_CRCEN (0x03) +#define MT6360_PMU_RST_PAS_CODE1 (0x04) +#define MT6360_PMU_RST_PAS_CODE2 (0x05) +#define MT6360_PMU_CORE_CTRL2 (0x06) +#define MT6360_PMU_TM_PAS_CODE1 (0x07) +#define MT6360_PMU_TM_PAS_CODE2 (0x08) +#define MT6360_PMU_TM_PAS_CODE3 (0x09) +#define MT6360_PMU_TM_PAS_CODE4 (0x0A) +#define MT6360_PMU_IRQ_IND (0x0B) +#define MT6360_PMU_IRQ_MASK (0x0C) +#define MT6360_PMU_IRQ_SET (0x0D) +#define MT6360_PMU_SHDN_CTRL (0x0E) +#define MT6360_PMU_TM_INF (0x0F) +#define MT6360_PMU_I2C_CTRL (0x10) +#define MT6360_PMU_CHG_CTRL1 (0x11) +#define MT6360_PMU_CHG_CTRL2 (0x12) +#define MT6360_PMU_CHG_CTRL3 (0x13) +#define MT6360_PMU_CHG_CTRL4 (0x14) +#define MT6360_PMU_CHG_CTRL5 (0x15) +#define MT6360_PMU_CHG_CTRL6 (0x16) +#define MT6360_PMU_CHG_CTRL7 (0x17) +#define MT6360_PMU_CHG_CTRL8 (0x18) +#define MT6360_PMU_CHG_CTRL9 (0x19) +#define MT6360_PMU_CHG_CTRL10 (0x1A) +#define MT6360_PMU_CHG_CTRL11 (0x1B) +#define MT6360_PMU_CHG_CTRL12 (0x1C) +#define MT6360_PMU_CHG_CTRL13 (0x1D) +#define MT6360_PMU_CHG_CTRL14 (0x1E) +#define MT6360_PMU_CHG_CTRL15 (0x1F) +#define MT6360_PMU_CHG_CTRL16 (0x20) +#define MT6360_PMU_CHG_AICC_RESULT (0x21) +#define MT6360_PMU_DEVICE_TYPE (0x22) +#define MT6360_PMU_QC_CONTROL1 (0x23) +#define MT6360_PMU_QC_CONTROL2 (0x24) +#define MT6360_PMU_QC30_CONTROL1 (0x25) +#define MT6360_PMU_QC30_CONTROL2 (0x26) +#define MT6360_PMU_USB_STATUS1 (0x27) +#define MT6360_PMU_QC_STATUS1 (0x28) +#define MT6360_PMU_QC_STATUS2 (0x29) +#define MT6360_PMU_CHG_PUMP (0x2A) +#define MT6360_PMU_CHG_CTRL17 (0x2B) +#define MT6360_PMU_CHG_CTRL18 (0x2C) +#define MT6360_PMU_CHRDET_CTRL1 (0x2D) +#define MT6360_PMU_CHRDET_CTRL2 (0x2E) +#define MT6360_PMU_DPDN_CTRL (0x2F) +#define MT6360_PMU_CHG_HIDDEN_CTRL1 (0x30) +#define MT6360_PMU_CHG_HIDDEN_CTRL2 (0x31) +#define MT6360_PMU_CHG_HIDDEN_CTRL3 (0x32) +#define MT6360_PMU_CHG_HIDDEN_CTRL4 (0x33) +#define MT6360_PMU_CHG_HIDDEN_CTRL5 (0x34) +#define MT6360_PMU_CHG_HIDDEN_CTRL6 (0x35) +#define MT6360_PMU_CHG_HIDDEN_CTRL7 (0x36) +#define MT6360_PMU_CHG_HIDDEN_CTRL8 (0x37) +#define MT6360_PMU_CHG_HIDDEN_CTRL9 (0x38) +#define MT6360_PMU_CHG_HIDDEN_CTRL10 (0x39) +#define MT6360_PMU_CHG_HIDDEN_CTRL11 (0x3A) +#define MT6360_PMU_CHG_HIDDEN_CTRL12 (0x3B) +#define MT6360_PMU_CHG_HIDDEN_CTRL13 (0x3C) +#define MT6360_PMU_CHG_HIDDEN_CTRL14 (0x3D) +#define MT6360_PMU_CHG_HIDDEN_CTRL15 (0x3E) +#define MT6360_PMU_CHG_HIDDEN_CTRL16 (0x3F) +#define MT6360_PMU_CHG_HIDDEN_CTRL17 (0x40) +#define MT6360_PMU_CHG_HIDDEN_CTRL18 (0x41) +#define MT6360_PMU_CHG_HIDDEN_CTRL19 (0x42) +#define MT6360_PMU_CHG_HIDDEN_CTRL20 (0x43) +#define MT6360_PMU_CHG_HIDDEN_CTRL21 (0x44) +#define MT6360_PMU_CHG_HIDDEN_CTRL22 (0x45) +#define MT6360_PMU_CHG_HIDDEN_CTRL23 (0x46) +#define MT6360_PMU_CHG_HIDDEN_CTRL24 (0x47) +#define MT6360_PMU_CHG_HIDDEN_CTRL25 (0x48) +#define MT6360_PMU_BC12_CTRL (0x49) +#define MT6360_PMU_CHG_STAT (0x4A) +#define MT6360_PMU_RESV1 (0x4B) +#define MT6360_PMU_TYPEC_OTP_TH_SEL_CODEH (0x4E) +#define MT6360_PMU_TYPEC_OTP_TH_SEL_CODEL (0x4F) +#define MT6360_PMU_TYPEC_OTP_HYST_TH (0x50) +#define MT6360_PMU_TYPEC_OTP_CTRL (0x51) +#define MT6360_PMU_ADC_BAT_DATA_H (0x52) +#define MT6360_PMU_ADC_BAT_DATA_L (0x53) +#define MT6360_PMU_IMID_BACKBST_ON (0x54) +#define MT6360_PMU_IMID_BACKBST_OFF (0x55) +#define MT6360_PMU_ADC_CONFIG (0x56) +#define MT6360_PMU_ADC_EN2 (0x57) +#define MT6360_PMU_ADC_IDLE_T (0x58) +#define MT6360_PMU_ADC_RPT_1 (0x5A) +#define MT6360_PMU_ADC_RPT_2 (0x5B) +#define MT6360_PMU_ADC_RPT_3 (0x5C) +#define MT6360_PMU_ADC_RPT_ORG1 (0x5D) +#define MT6360_PMU_ADC_RPT_ORG2 (0x5E) +#define MT6360_PMU_BAT_OVP_TH_SEL_CODEH (0x5F) +#define MT6360_PMU_BAT_OVP_TH_SEL_CODEL (0x60) +#define MT6360_PMU_CHG_CTRL19 (0x61) +#define MT6360_PMU_VDDASUPPLY (0x62) +#define MT6360_PMU_BC12_MANUAL (0x63) +#define MT6360_PMU_CHGDET_FUNC (0x64) +#define MT6360_PMU_FOD_CTRL (0x65) +#define MT6360_PMU_CHG_CTRL20 (0x66) +#define MT6360_PMU_CHG_HIDDEN_CTRL26 (0x67) +#define MT6360_PMU_CHG_HIDDEN_CTRL27 (0x68) +#define MT6360_PMU_RESV2 (0x69) +#define MT6360_PMU_USBID_CTRL1 (0x6D) +#define MT6360_PMU_USBID_CTRL2 (0x6E) +#define MT6360_PMU_USBID_CTRL3 (0x6F) +#define MT6360_PMU_FLED_CFG (0x70) +#define MT6360_PMU_RESV3 (0x71) +#define MT6360_PMU_FLED1_CTRL (0x72) +#define MT6360_PMU_FLED_STRB_CTRL (0x73) +#define MT6360_PMU_FLED1_STRB_CTRL2 (0x74) +#define MT6360_PMU_FLED1_TOR_CTRL (0x75) +#define MT6360_PMU_FLED2_CTRL (0x76) +#define MT6360_PMU_RESV4 (0x77) +#define MT6360_PMU_FLED2_STRB_CTRL2 (0x78) +#define MT6360_PMU_FLED2_TOR_CTRL (0x79) +#define MT6360_PMU_FLED_VMIDTRK_CTRL1 (0x7A) +#define MT6360_PMU_FLED_VMID_RTM (0x7B) +#define MT6360_PMU_FLED_VMIDTRK_CTRL2 (0x7C) +#define MT6360_PMU_FLED_PWSEL (0x7D) +#define MT6360_PMU_FLED_EN (0x7E) +#define MT6360_PMU_FLED_Hidden1 (0x7F) +#define MT6360_PMU_RGB_EN (0x80) +#define MT6360_PMU_RGB1_ISNK (0x81) +#define MT6360_PMU_RGB2_ISNK (0x82) +#define MT6360_PMU_RGB3_ISNK (0x83) +#define MT6360_PMU_RGB_ML_ISNK (0x84) +#define MT6360_PMU_RGB1_DIM (0x85) +#define MT6360_PMU_RGB2_DIM (0x86) +#define MT6360_PMU_RGB3_DIM (0x87) +#define MT6360_PMU_RESV5 (0x88) +#define MT6360_PMU_RGB12_Freq (0x89) +#define MT6360_PMU_RGB34_Freq (0x8A) +#define MT6360_PMU_RGB1_Tr (0x8B) +#define MT6360_PMU_RGB1_Tf (0x8C) +#define MT6360_PMU_RGB1_TON_TOFF (0x8D) +#define MT6360_PMU_RGB2_Tr (0x8E) +#define MT6360_PMU_RGB2_Tf (0x8F) +#define MT6360_PMU_RGB2_TON_TOFF (0x90) +#define MT6360_PMU_RGB3_Tr (0x91) +#define MT6360_PMU_RGB3_Tf (0x92) +#define MT6360_PMU_RGB3_TON_TOFF (0x93) +#define MT6360_PMU_RGB_Hidden_CTRL1 (0x94) +#define MT6360_PMU_RGB_Hidden_CTRL2 (0x95) +#define MT6360_PMU_RESV6 (0x97) +#define MT6360_PMU_SPARE1 (0x9A) +#define MT6360_PMU_SPARE2 (0xA0) +#define MT6360_PMU_SPARE3 (0xB0) +#define MT6360_PMU_SPARE4 (0xC0) +#define MT6360_PMU_CHG_IRQ1 (0xD0) +#define MT6360_PMU_CHG_IRQ2 (0xD1) +#define MT6360_PMU_CHG_IRQ3 (0xD2) +#define MT6360_PMU_CHG_IRQ4 (0xD3) +#define MT6360_PMU_CHG_IRQ5 (0xD4) +#define MT6360_PMU_CHG_IRQ6 (0xD5) +#define MT6360_PMU_QC_IRQ (0xD6) +#define MT6360_PMU_FOD_IRQ (0xD7) +#define MT6360_PMU_BASE_IRQ (0xD8) +#define MT6360_PMU_FLED_IRQ1 (0xD9) +#define MT6360_PMU_FLED_IRQ2 (0xDA) +#define MT6360_PMU_RGB_IRQ (0xDB) +#define MT6360_PMU_BUCK1_IRQ (0xDC) +#define MT6360_PMU_BUCK2_IRQ (0xDD) +#define MT6360_PMU_LDO_IRQ1 (0xDE) +#define MT6360_PMU_LDO_IRQ2 (0xDF) +#define MT6360_PMU_CHG_STAT1 (0xE0) +#define MT6360_PMU_CHG_STAT2 (0xE1) +#define MT6360_PMU_CHG_STAT3 (0xE2) +#define MT6360_PMU_CHG_STAT4 (0xE3) +#define MT6360_PMU_CHG_STAT5 (0xE4) +#define MT6360_PMU_CHG_STAT6 (0xE5) +#define MT6360_PMU_QC_STAT (0xE6) +#define MT6360_PMU_FOD_STAT (0xE7) +#define MT6360_PMU_BASE_STAT (0xE8) +#define MT6360_PMU_FLED_STAT1 (0xE9) +#define MT6360_PMU_FLED_STAT2 (0xEA) +#define MT6360_PMU_RGB_STAT (0xEB) +#define MT6360_PMU_BUCK1_STAT (0xEC) +#define MT6360_PMU_BUCK2_STAT (0xED) +#define MT6360_PMU_LDO_STAT1 (0xEE) +#define MT6360_PMU_LDO_STAT2 (0xEF) +#define MT6360_PMU_CHG_MASK1 (0xF0) +#define MT6360_PMU_CHG_MASK2 (0xF1) +#define MT6360_PMU_CHG_MASK3 (0xF2) +#define MT6360_PMU_CHG_MASK4 (0xF3) +#define MT6360_PMU_CHG_MASK5 (0xF4) +#define MT6360_PMU_CHG_MASK6 (0xF5) +#define MT6360_PMU_QC_MASK (0xF6) +#define MT6360_PMU_FOD_MASK (0xF7) +#define MT6360_PMU_BASE_MASK (0xF8) +#define MT6360_PMU_FLED_MASK1 (0xF9) +#define MT6360_PMU_FLED_MASK2 (0xFA) +#define MT6360_PMU_FAULTB_MASK (0xFB) +#define MT6360_PMU_BUCK1_MASK (0xFC) +#define MT6360_PMU_BUCK2_MASK (0xFD) +#define MT6360_PMU_LDO_MASK1 (0xFE) +#define MT6360_PMU_LDO_MASK2 (0xFF) +#define MT6360_PMU_MAXREG (MT6360_PMU_LDO_MASK2) + +/* MT6360_PMU_IRQ_SET */ +#define MT6360_PMU_IRQ_REGNUM (MT6360_PMU_LDO_IRQ2 - MT6360_PMU_CHG_IRQ1 + 1) +#define MT6360_IRQ_RETRIG BIT(2) + +#define CHIP_VEN_MASK (0xF0) +#define CHIP_VEN_MT6360 (0x50) +#define CHIP_REV_MASK (0x0F) + +#endif /* __MT6360_H__ */ -- 2.7.4 _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2020-03-03 15:27 Gene Chen @ 2020-03-04 14:56 ` Matthias Brugger 0 siblings, 0 replies; 1767+ messages in thread From: Matthias Brugger @ 2020-03-04 14:56 UTC (permalink / raw) To: Gene Chen, lee.jones Cc: gene_chen, linux-kernel, cy_huang, linux-mediatek, Wilma.Wu, linux-arm-kernel, shufan_lee Please resend with appropiate commit message. On 03/03/2020 16:27, Gene Chen wrote: > Add mfd driver for mt6360 pmic chip include > Battery Charger/USB_PD/Flash LED/RGB LED/LDO/Buck > > Signed-off-by: Gene Chen <gene_chen@richtek.com > --- > drivers/mfd/Kconfig | 12 ++ > drivers/mfd/Makefile | 1 + > drivers/mfd/mt6360-core.c | 425 +++++++++++++++++++++++++++++++++++++++++++++ > include/linux/mfd/mt6360.h | 240 +++++++++++++++++++++++++ > 4 files changed, 678 insertions(+) > create mode 100644 drivers/mfd/mt6360-core.c > create mode 100644 include/linux/mfd/mt6360.h > > changelogs between v1 & v2 > - include missing header file > > changelogs between v2 & v3 > - add changelogs > > changelogs between v3 & v4 > - fix Kconfig description > - replace mt6360_pmu_info with mt6360_pmu_data > - replace probe with probe_new > - remove unnecessary irq_chip variable > - remove annotation > - replace MT6360_MFD_CELL with OF_MFD_CELL > > changelogs between v4 & v5 > - remove unnecessary parse dt function > - use devm_i2c_new_dummy_device > - add base-commit message > > changelogs between v5 & v6 > - review return value > - remove i2c id_table > - use GPL license v2 > > changelogs between v6 & v7 > - add author description > - replace MT6360_REGMAP_IRQ_REG by REGMAP_IRQ_REG_LINE > - remove mt6360-private.h > > changelogs between v7 & v8 > - fix kbuild auto reboot by include interrupt header > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 2b20329..0f8c341 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -857,6 +857,18 @@ config MFD_MAX8998 > additional drivers must be enabled in order to use the functionality > of the device. > > +config MFD_MT6360 > + tristate "Mediatek MT6360 SubPMIC" > + select MFD_CORE > + select REGMAP_I2C > + select REGMAP_IRQ > + depends on I2C > + help > + Say Y here to enable MT6360 PMU/PMIC/LDO functional support. > + PMU part includes Charger, Flashlight, RGB LED > + PMIC part includes 2-channel BUCKs and 2-channel LDOs > + LDO part includes 4-channel LDOs > + > config MFD_MT6397 > tristate "MediaTek MT6397 PMIC Support" > select MFD_CORE > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > index b83f172..8c35816 100644 > --- a/drivers/mfd/Makefile > +++ b/drivers/mfd/Makefile > @@ -238,6 +238,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o > obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o > obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o > obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI) += intel_soc_pmic_chtdc_ti.o > +obj-$(CONFIG_MFD_MT6360) += mt6360-core.o > mt6397-objs := mt6397-core.o mt6397-irq.o > obj-$(CONFIG_MFD_MT6397) += mt6397.o > obj-$(CONFIG_INTEL_SOC_PMIC_MRFLD) += intel_soc_pmic_mrfld.o > diff --git a/drivers/mfd/mt6360-core.c b/drivers/mfd/mt6360-core.c > new file mode 100644 > index 0000000..d1168f8 > --- /dev/null > +++ b/drivers/mfd/mt6360-core.c > @@ -0,0 +1,425 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c) 2019 MediaTek Inc. > + * > + * Author: Gene Chen <gene_chen@richtek.com> > + */ > + > +#include <linux/i2c.h> > +#include <linux/init.h> > +#include <linux/interrupt.h> > +#include <linux/kernel.h> > +#include <linux/mfd/core.h> > +#include <linux/module.h> > +#include <linux/of_irq.h> > +#include <linux/of_platform.h> > +#include <linux/version.h> > + > +#include <linux/mfd/mt6360.h> > + > +/* reg 0 -> 0 ~ 7 */ > +#define MT6360_CHG_TREG_EVT (4) > +#define MT6360_CHG_AICR_EVT (5) > +#define MT6360_CHG_MIVR_EVT (6) > +#define MT6360_PWR_RDY_EVT (7) > +/* REG 1 -> 8 ~ 15 */ > +#define MT6360_CHG_BATSYSUV_EVT (9) > +#define MT6360_FLED_CHG_VINOVP_EVT (11) > +#define MT6360_CHG_VSYSUV_EVT (12) > +#define MT6360_CHG_VSYSOV_EVT (13) > +#define MT6360_CHG_VBATOV_EVT (14) > +#define MT6360_CHG_VBUSOV_EVT (15) > +/* REG 2 -> 16 ~ 23 */ > +/* REG 3 -> 24 ~ 31 */ > +#define MT6360_WD_PMU_DET (25) > +#define MT6360_WD_PMU_DONE (26) > +#define MT6360_CHG_TMRI (27) > +#define MT6360_CHG_ADPBADI (29) > +#define MT6360_CHG_RVPI (30) > +#define MT6360_OTPI (31) > +/* REG 4 -> 32 ~ 39 */ > +#define MT6360_CHG_AICCMEASL (32) > +#define MT6360_CHGDET_DONEI (34) > +#define MT6360_WDTMRI (35) > +#define MT6360_SSFINISHI (36) > +#define MT6360_CHG_RECHGI (37) > +#define MT6360_CHG_TERMI (38) > +#define MT6360_CHG_IEOCI (39) > +/* REG 5 -> 40 ~ 47 */ > +#define MT6360_PUMPX_DONEI (40) > +#define MT6360_BAT_OVP_ADC_EVT (41) > +#define MT6360_TYPEC_OTP_EVT (42) > +#define MT6360_ADC_WAKEUP_EVT (43) > +#define MT6360_ADC_DONEI (44) > +#define MT6360_BST_BATUVI (45) > +#define MT6360_BST_VBUSOVI (46) > +#define MT6360_BST_OLPI (47) > +/* REG 6 -> 48 ~ 55 */ > +#define MT6360_ATTACH_I (48) > +#define MT6360_DETACH_I (49) > +#define MT6360_QC30_STPDONE (51) > +#define MT6360_QC_VBUSDET_DONE (52) > +#define MT6360_HVDCP_DET (53) > +#define MT6360_CHGDETI (54) > +#define MT6360_DCDTI (55) > +/* REG 7 -> 56 ~ 63 */ > +#define MT6360_FOD_DONE_EVT (56) > +#define MT6360_FOD_OV_EVT (57) > +#define MT6360_CHRDET_UVP_EVT (58) > +#define MT6360_CHRDET_OVP_EVT (59) > +#define MT6360_CHRDET_EXT_EVT (60) > +#define MT6360_FOD_LR_EVT (61) > +#define MT6360_FOD_HR_EVT (62) > +#define MT6360_FOD_DISCHG_FAIL_EVT (63) > +/* REG 8 -> 64 ~ 71 */ > +#define MT6360_USBID_EVT (64) > +#define MT6360_APWDTRST_EVT (65) > +#define MT6360_EN_EVT (66) > +#define MT6360_QONB_RST_EVT (67) > +#define MT6360_MRSTB_EVT (68) > +#define MT6360_OTP_EVT (69) > +#define MT6360_VDDAOV_EVT (70) > +#define MT6360_SYSUV_EVT (71) > +/* REG 9 -> 72 ~ 79 */ > +#define MT6360_FLED_STRBPIN_EVT (72) > +#define MT6360_FLED_TORPIN_EVT (73) > +#define MT6360_FLED_TX_EVT (74) > +#define MT6360_FLED_LVF_EVT (75) > +#define MT6360_FLED2_SHORT_EVT (78) > +#define MT6360_FLED1_SHORT_EVT (79) > +/* REG 10 -> 80 ~ 87 */ > +#define MT6360_FLED2_STRB_EVT (80) > +#define MT6360_FLED1_STRB_EVT (81) > +#define MT6360_FLED2_STRB_TO_EVT (82) > +#define MT6360_FLED1_STRB_TO_EVT (83) > +#define MT6360_FLED2_TOR_EVT (84) > +#define MT6360_FLED1_TOR_EVT (85) > +/* REG 11 -> 88 ~ 95 */ > +/* REG 12 -> 96 ~ 103 */ > +#define MT6360_BUCK1_PGB_EVT (96) > +#define MT6360_BUCK1_OC_EVT (100) > +#define MT6360_BUCK1_OV_EVT (101) > +#define MT6360_BUCK1_UV_EVT (102) > +/* REG 13 -> 104 ~ 111 */ > +#define MT6360_BUCK2_PGB_EVT (104) > +#define MT6360_BUCK2_OC_EVT (108) > +#define MT6360_BUCK2_OV_EVT (109) > +#define MT6360_BUCK2_UV_EVT (110) > +/* REG 14 -> 112 ~ 119 */ > +#define MT6360_LDO1_OC_EVT (113) > +#define MT6360_LDO2_OC_EVT (114) > +#define MT6360_LDO3_OC_EVT (115) > +#define MT6360_LDO5_OC_EVT (117) > +#define MT6360_LDO6_OC_EVT (118) > +#define MT6360_LDO7_OC_EVT (119) > +/* REG 15 -> 120 ~ 127 */ > +#define MT6360_LDO1_PGB_EVT (121) > +#define MT6360_LDO2_PGB_EVT (122) > +#define MT6360_LDO3_PGB_EVT (123) > +#define MT6360_LDO5_PGB_EVT (125) > +#define MT6360_LDO6_PGB_EVT (126) > +#define MT6360_LDO7_PGB_EVT (127) > + > +static const struct regmap_irq mt6360_pmu_irqs[] = { > + REGMAP_IRQ_REG_LINE(MT6360_CHG_TREG_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_AICR_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_MIVR_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_PWR_RDY_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_BATSYSUV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED_CHG_VINOVP_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_VSYSUV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_VSYSOV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_VBATOV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_VBUSOV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_WD_PMU_DET, 8), > + REGMAP_IRQ_REG_LINE(MT6360_WD_PMU_DONE, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_TMRI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_ADPBADI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_RVPI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_OTPI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_AICCMEASL, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHGDET_DONEI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_WDTMRI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_SSFINISHI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_RECHGI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_TERMI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_IEOCI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_PUMPX_DONEI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_TREG_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BAT_OVP_ADC_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_TYPEC_OTP_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_ADC_WAKEUP_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_ADC_DONEI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BST_BATUVI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BST_VBUSOVI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BST_OLPI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_ATTACH_I, 8), > + REGMAP_IRQ_REG_LINE(MT6360_DETACH_I, 8), > + REGMAP_IRQ_REG_LINE(MT6360_QC30_STPDONE, 8), > + REGMAP_IRQ_REG_LINE(MT6360_QC_VBUSDET_DONE, 8), > + REGMAP_IRQ_REG_LINE(MT6360_HVDCP_DET, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHGDETI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_DCDTI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FOD_DONE_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FOD_OV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHRDET_UVP_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHRDET_OVP_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHRDET_EXT_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FOD_LR_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FOD_HR_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FOD_DISCHG_FAIL_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_USBID_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_APWDTRST_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_EN_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_QONB_RST_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_MRSTB_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_OTP_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_VDDAOV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_SYSUV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED_STRBPIN_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED_TORPIN_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED_TX_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED_LVF_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED2_SHORT_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED1_SHORT_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED2_STRB_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED1_STRB_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED2_STRB_TO_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED1_STRB_TO_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED2_TOR_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED1_TOR_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BUCK1_PGB_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BUCK1_OC_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BUCK1_OV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BUCK1_UV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BUCK2_PGB_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BUCK2_OC_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BUCK2_OV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BUCK2_UV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO1_OC_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO2_OC_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO3_OC_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO5_OC_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO6_OC_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO7_OC_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO1_PGB_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO2_PGB_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO3_PGB_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO5_PGB_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO6_PGB_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO7_PGB_EVT, 8), > +}; > + > +static int mt6360_pmu_handle_post_irq(void *irq_drv_data) > +{ > + struct mt6360_pmu_data *mpd = irq_drv_data; > + > + return regmap_update_bits(mpd->regmap, > + MT6360_PMU_IRQ_SET, MT6360_IRQ_RETRIG, MT6360_IRQ_RETRIG); > +} > + > +static struct regmap_irq_chip mt6360_pmu_irq_chip = { > + .irqs = mt6360_pmu_irqs, > + .num_irqs = ARRAY_SIZE(mt6360_pmu_irqs), > + .num_regs = MT6360_PMU_IRQ_REGNUM, > + .mask_base = MT6360_PMU_CHG_MASK1, > + .status_base = MT6360_PMU_CHG_IRQ1, > + .ack_base = MT6360_PMU_CHG_IRQ1, > + .init_ack_masked = true, > + .use_ack = true, > + .handle_post_irq = mt6360_pmu_handle_post_irq, > +}; > + > +static const struct regmap_config mt6360_pmu_regmap_config = { > + .reg_bits = 8, > + .val_bits = 8, > + .max_register = MT6360_PMU_MAXREG, > +}; > + > +static const struct resource mt6360_adc_resources[] = { > + DEFINE_RES_IRQ_NAMED(MT6360_ADC_DONEI, "adc_donei"), > +}; > + > +static const struct resource mt6360_chg_resources[] = { > + DEFINE_RES_IRQ_NAMED(MT6360_CHG_TREG_EVT, "chg_treg_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_PWR_RDY_EVT, "pwr_rdy_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_CHG_BATSYSUV_EVT, "chg_batsysuv_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VSYSUV_EVT, "chg_vsysuv_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VSYSOV_EVT, "chg_vsysov_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VBATOV_EVT, "chg_vbatov_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VBUSOV_EVT, "chg_vbusov_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_CHG_AICCMEASL, "chg_aiccmeasl"), > + DEFINE_RES_IRQ_NAMED(MT6360_WDTMRI, "wdtmri"), > + DEFINE_RES_IRQ_NAMED(MT6360_CHG_RECHGI, "chg_rechgi"), > + DEFINE_RES_IRQ_NAMED(MT6360_CHG_TERMI, "chg_termi"), > + DEFINE_RES_IRQ_NAMED(MT6360_CHG_IEOCI, "chg_ieoci"), > + DEFINE_RES_IRQ_NAMED(MT6360_PUMPX_DONEI, "pumpx_donei"), > + DEFINE_RES_IRQ_NAMED(MT6360_ATTACH_I, "attach_i"), > + DEFINE_RES_IRQ_NAMED(MT6360_CHRDET_EXT_EVT, "chrdet_ext_evt"), > +}; > + > +static const struct resource mt6360_led_resources[] = { > + DEFINE_RES_IRQ_NAMED(MT6360_FLED_CHG_VINOVP_EVT, "fled_chg_vinovp_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_FLED_LVF_EVT, "fled_lvf_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_FLED2_SHORT_EVT, "fled2_short_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_FLED1_SHORT_EVT, "fled1_short_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_FLED2_STRB_TO_EVT, "fled2_strb_to_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_FLED1_STRB_TO_EVT, "fled1_strb_to_evt"), > +}; > + > +static const struct resource mt6360_pmic_resources[] = { > + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_PGB_EVT, "buck1_pgb_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_OC_EVT, "buck1_oc_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_OV_EVT, "buck1_ov_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_UV_EVT, "buck1_uv_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_PGB_EVT, "buck2_pgb_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_OC_EVT, "buck2_oc_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_OV_EVT, "buck2_ov_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_UV_EVT, "buck2_uv_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_LDO6_OC_EVT, "ldo6_oc_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_LDO7_OC_EVT, "ldo7_oc_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_LDO6_PGB_EVT, "ldo6_pgb_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_LDO7_PGB_EVT, "ldo7_pgb_evt"), > +}; > + > +static const struct resource mt6360_ldo_resources[] = { > + DEFINE_RES_IRQ_NAMED(MT6360_LDO1_OC_EVT, "ldo1_oc_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_LDO2_OC_EVT, "ldo2_oc_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_LDO3_OC_EVT, "ldo3_oc_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_LDO5_OC_EVT, "ldo5_oc_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_LDO1_PGB_EVT, "ldo1_pgb_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_LDO2_PGB_EVT, "ldo2_pgb_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_LDO3_PGB_EVT, "ldo3_pgb_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_LDO5_PGB_EVT, "ldo5_pgb_evt"), > +}; > + > +static const struct mfd_cell mt6360_devs[] = { > + OF_MFD_CELL("mt6360_adc", mt6360_adc_resources, > + NULL, 0, 0, "mediatek,mt6360_adc"), > + OF_MFD_CELL("mt6360_chg", mt6360_chg_resources, > + NULL, 0, 0, "mediatek,mt6360_chg"), > + OF_MFD_CELL("mt6360_led", mt6360_led_resources, > + NULL, 0, 0, "mediatek,mt6360_led"), > + OF_MFD_CELL("mt6360_pmic", mt6360_pmic_resources, > + NULL, 0, 0, "mediatek,mt6360_pmic"), > + OF_MFD_CELL("mt6360_ldo", mt6360_ldo_resources, > + NULL, 0, 0, "mediatek,mt6360_ldo"), > + OF_MFD_CELL("mt6360_tcpc", NULL, > + NULL, 0, 0, "mediatek,mt6360_tcpc"), > +}; > + > +static const unsigned short mt6360_slave_addr[MT6360_SLAVE_MAX] = { > + MT6360_PMU_SLAVEID, > + MT6360_PMIC_SLAVEID, > + MT6360_LDO_SLAVEID, > + MT6360_TCPC_SLAVEID, > +}; > + > +static int mt6360_pmu_probe(struct i2c_client *client) > +{ > + struct mt6360_pmu_data *mpd; > + unsigned int reg_data; > + int i, ret; > + > + mpd = devm_kzalloc(&client->dev, sizeof(*mpd), GFP_KERNEL); > + if (!mpd) > + return -ENOMEM; > + > + mpd->dev = &client->dev; > + i2c_set_clientdata(client, mpd); > + > + mpd->regmap = devm_regmap_init_i2c(client, &mt6360_pmu_regmap_config); > + if (IS_ERR(mpd->regmap)) { > + dev_err(&client->dev, "Failed to register regmap\n"); > + return PTR_ERR(mpd->regmap); > + } > + > + ret = regmap_read(mpd->regmap, MT6360_PMU_DEV_INFO, ®_data); > + if (ret) { > + dev_err(&client->dev, "Device not found\n"); > + return ret; > + } > + > + mpd->chip_rev = reg_data & CHIP_REV_MASK; > + if (mpd->chip_rev != CHIP_VEN_MT6360) { > + dev_err(&client->dev, "Device not supported\n"); > + return -ENODEV; > + } > + > + mt6360_pmu_irq_chip.irq_drv_data = mpd; > + ret = devm_regmap_add_irq_chip(&client->dev, mpd->regmap, client->irq, > + IRQF_TRIGGER_FALLING, 0, > + &mt6360_pmu_irq_chip, &mpd->irq_data); > + if (ret) { > + dev_err(&client->dev, "Failed to add Regmap IRQ Chip\n"); > + return ret; > + } > + > + mpd->i2c[0] = client; > + for (i = 1; i < MT6360_SLAVE_MAX; i++) { > + mpd->i2c[i] = devm_i2c_new_dummy_device(&client->dev, > + client->adapter, > + mt6360_slave_addr[i]); > + if (IS_ERR(mpd->i2c[i])) { > + dev_err(&client->dev, > + "Failed to get new dummy I2C device for address 0x%x", > + mt6360_slave_addr[i]); > + return PTR_ERR(mpd->i2c[i]); > + } > + i2c_set_clientdata(mpd->i2c[i], mpd); > + } > + > + ret = devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_AUTO, > + mt6360_devs, ARRAY_SIZE(mt6360_devs), NULL, > + 0, regmap_irq_get_domain(mpd->irq_data)); > + if (ret) { > + dev_err(&client->dev, > + "Failed to register subordinate devices\n"); > + return ret; > + } > + > + return 0; > +} > + > +static int __maybe_unused mt6360_pmu_suspend(struct device *dev) > +{ > + struct i2c_client *i2c = to_i2c_client(dev); > + > + if (device_may_wakeup(dev)) > + enable_irq_wake(i2c->irq); > + > + return 0; > +} > + > +static int __maybe_unused mt6360_pmu_resume(struct device *dev) > +{ > + > + struct i2c_client *i2c = to_i2c_client(dev); > + > + if (device_may_wakeup(dev)) > + disable_irq_wake(i2c->irq); > + > + return 0; > +} > + > +static SIMPLE_DEV_PM_OPS(mt6360_pmu_pm_ops, > + mt6360_pmu_suspend, mt6360_pmu_resume); > + > +static const struct of_device_id __maybe_unused mt6360_pmu_of_id[] = { > + { .compatible = "mediatek,mt6360_pmu", }, > + {}, > +}; > +MODULE_DEVICE_TABLE(of, mt6360_pmu_of_id); > + > +static struct i2c_driver mt6360_pmu_driver = { > + .driver = { > + .pm = &mt6360_pmu_pm_ops, > + .of_match_table = of_match_ptr(mt6360_pmu_of_id), > + }, > + .probe_new = mt6360_pmu_probe, > +}; > +module_i2c_driver(mt6360_pmu_driver); > + > +MODULE_AUTHOR("Gene Chen <gene_chen@richtek.com>"); > +MODULE_DESCRIPTION("MT6360 PMU I2C Driver"); > +MODULE_LICENSE("GPL v2"); > diff --git a/include/linux/mfd/mt6360.h b/include/linux/mfd/mt6360.h > new file mode 100644 > index 0000000..c03e6d1 > --- /dev/null > +++ b/include/linux/mfd/mt6360.h > @@ -0,0 +1,240 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Copyright (c) 2019 MediaTek Inc. > + */ > + > +#ifndef __MT6360_H__ > +#define __MT6360_H__ > + > +#include <linux/regmap.h> > + > +enum { > + MT6360_SLAVE_PMU = 0, > + MT6360_SLAVE_PMIC, > + MT6360_SLAVE_LDO, > + MT6360_SLAVE_TCPC, > + MT6360_SLAVE_MAX, > +}; > + > +#define MT6360_PMU_SLAVEID (0x34) > +#define MT6360_PMIC_SLAVEID (0x1A) > +#define MT6360_LDO_SLAVEID (0x64) > +#define MT6360_TCPC_SLAVEID (0x4E) > + > +struct mt6360_pmu_data { > + struct i2c_client *i2c[MT6360_SLAVE_MAX]; > + struct device *dev; > + struct regmap *regmap; > + struct regmap_irq_chip_data *irq_data; > + unsigned int chip_rev; > +}; > + > +/* PMU register defininition */ > +#define MT6360_PMU_DEV_INFO (0x00) > +#define MT6360_PMU_CORE_CTRL1 (0x01) > +#define MT6360_PMU_RST1 (0x02) > +#define MT6360_PMU_CRCEN (0x03) > +#define MT6360_PMU_RST_PAS_CODE1 (0x04) > +#define MT6360_PMU_RST_PAS_CODE2 (0x05) > +#define MT6360_PMU_CORE_CTRL2 (0x06) > +#define MT6360_PMU_TM_PAS_CODE1 (0x07) > +#define MT6360_PMU_TM_PAS_CODE2 (0x08) > +#define MT6360_PMU_TM_PAS_CODE3 (0x09) > +#define MT6360_PMU_TM_PAS_CODE4 (0x0A) > +#define MT6360_PMU_IRQ_IND (0x0B) > +#define MT6360_PMU_IRQ_MASK (0x0C) > +#define MT6360_PMU_IRQ_SET (0x0D) > +#define MT6360_PMU_SHDN_CTRL (0x0E) > +#define MT6360_PMU_TM_INF (0x0F) > +#define MT6360_PMU_I2C_CTRL (0x10) > +#define MT6360_PMU_CHG_CTRL1 (0x11) > +#define MT6360_PMU_CHG_CTRL2 (0x12) > +#define MT6360_PMU_CHG_CTRL3 (0x13) > +#define MT6360_PMU_CHG_CTRL4 (0x14) > +#define MT6360_PMU_CHG_CTRL5 (0x15) > +#define MT6360_PMU_CHG_CTRL6 (0x16) > +#define MT6360_PMU_CHG_CTRL7 (0x17) > +#define MT6360_PMU_CHG_CTRL8 (0x18) > +#define MT6360_PMU_CHG_CTRL9 (0x19) > +#define MT6360_PMU_CHG_CTRL10 (0x1A) > +#define MT6360_PMU_CHG_CTRL11 (0x1B) > +#define MT6360_PMU_CHG_CTRL12 (0x1C) > +#define MT6360_PMU_CHG_CTRL13 (0x1D) > +#define MT6360_PMU_CHG_CTRL14 (0x1E) > +#define MT6360_PMU_CHG_CTRL15 (0x1F) > +#define MT6360_PMU_CHG_CTRL16 (0x20) > +#define MT6360_PMU_CHG_AICC_RESULT (0x21) > +#define MT6360_PMU_DEVICE_TYPE (0x22) > +#define MT6360_PMU_QC_CONTROL1 (0x23) > +#define MT6360_PMU_QC_CONTROL2 (0x24) > +#define MT6360_PMU_QC30_CONTROL1 (0x25) > +#define MT6360_PMU_QC30_CONTROL2 (0x26) > +#define MT6360_PMU_USB_STATUS1 (0x27) > +#define MT6360_PMU_QC_STATUS1 (0x28) > +#define MT6360_PMU_QC_STATUS2 (0x29) > +#define MT6360_PMU_CHG_PUMP (0x2A) > +#define MT6360_PMU_CHG_CTRL17 (0x2B) > +#define MT6360_PMU_CHG_CTRL18 (0x2C) > +#define MT6360_PMU_CHRDET_CTRL1 (0x2D) > +#define MT6360_PMU_CHRDET_CTRL2 (0x2E) > +#define MT6360_PMU_DPDN_CTRL (0x2F) > +#define MT6360_PMU_CHG_HIDDEN_CTRL1 (0x30) > +#define MT6360_PMU_CHG_HIDDEN_CTRL2 (0x31) > +#define MT6360_PMU_CHG_HIDDEN_CTRL3 (0x32) > +#define MT6360_PMU_CHG_HIDDEN_CTRL4 (0x33) > +#define MT6360_PMU_CHG_HIDDEN_CTRL5 (0x34) > +#define MT6360_PMU_CHG_HIDDEN_CTRL6 (0x35) > +#define MT6360_PMU_CHG_HIDDEN_CTRL7 (0x36) > +#define MT6360_PMU_CHG_HIDDEN_CTRL8 (0x37) > +#define MT6360_PMU_CHG_HIDDEN_CTRL9 (0x38) > +#define MT6360_PMU_CHG_HIDDEN_CTRL10 (0x39) > +#define MT6360_PMU_CHG_HIDDEN_CTRL11 (0x3A) > +#define MT6360_PMU_CHG_HIDDEN_CTRL12 (0x3B) > +#define MT6360_PMU_CHG_HIDDEN_CTRL13 (0x3C) > +#define MT6360_PMU_CHG_HIDDEN_CTRL14 (0x3D) > +#define MT6360_PMU_CHG_HIDDEN_CTRL15 (0x3E) > +#define MT6360_PMU_CHG_HIDDEN_CTRL16 (0x3F) > +#define MT6360_PMU_CHG_HIDDEN_CTRL17 (0x40) > +#define MT6360_PMU_CHG_HIDDEN_CTRL18 (0x41) > +#define MT6360_PMU_CHG_HIDDEN_CTRL19 (0x42) > +#define MT6360_PMU_CHG_HIDDEN_CTRL20 (0x43) > +#define MT6360_PMU_CHG_HIDDEN_CTRL21 (0x44) > +#define MT6360_PMU_CHG_HIDDEN_CTRL22 (0x45) > +#define MT6360_PMU_CHG_HIDDEN_CTRL23 (0x46) > +#define MT6360_PMU_CHG_HIDDEN_CTRL24 (0x47) > +#define MT6360_PMU_CHG_HIDDEN_CTRL25 (0x48) > +#define MT6360_PMU_BC12_CTRL (0x49) > +#define MT6360_PMU_CHG_STAT (0x4A) > +#define MT6360_PMU_RESV1 (0x4B) > +#define MT6360_PMU_TYPEC_OTP_TH_SEL_CODEH (0x4E) > +#define MT6360_PMU_TYPEC_OTP_TH_SEL_CODEL (0x4F) > +#define MT6360_PMU_TYPEC_OTP_HYST_TH (0x50) > +#define MT6360_PMU_TYPEC_OTP_CTRL (0x51) > +#define MT6360_PMU_ADC_BAT_DATA_H (0x52) > +#define MT6360_PMU_ADC_BAT_DATA_L (0x53) > +#define MT6360_PMU_IMID_BACKBST_ON (0x54) > +#define MT6360_PMU_IMID_BACKBST_OFF (0x55) > +#define MT6360_PMU_ADC_CONFIG (0x56) > +#define MT6360_PMU_ADC_EN2 (0x57) > +#define MT6360_PMU_ADC_IDLE_T (0x58) > +#define MT6360_PMU_ADC_RPT_1 (0x5A) > +#define MT6360_PMU_ADC_RPT_2 (0x5B) > +#define MT6360_PMU_ADC_RPT_3 (0x5C) > +#define MT6360_PMU_ADC_RPT_ORG1 (0x5D) > +#define MT6360_PMU_ADC_RPT_ORG2 (0x5E) > +#define MT6360_PMU_BAT_OVP_TH_SEL_CODEH (0x5F) > +#define MT6360_PMU_BAT_OVP_TH_SEL_CODEL (0x60) > +#define MT6360_PMU_CHG_CTRL19 (0x61) > +#define MT6360_PMU_VDDASUPPLY (0x62) > +#define MT6360_PMU_BC12_MANUAL (0x63) > +#define MT6360_PMU_CHGDET_FUNC (0x64) > +#define MT6360_PMU_FOD_CTRL (0x65) > +#define MT6360_PMU_CHG_CTRL20 (0x66) > +#define MT6360_PMU_CHG_HIDDEN_CTRL26 (0x67) > +#define MT6360_PMU_CHG_HIDDEN_CTRL27 (0x68) > +#define MT6360_PMU_RESV2 (0x69) > +#define MT6360_PMU_USBID_CTRL1 (0x6D) > +#define MT6360_PMU_USBID_CTRL2 (0x6E) > +#define MT6360_PMU_USBID_CTRL3 (0x6F) > +#define MT6360_PMU_FLED_CFG (0x70) > +#define MT6360_PMU_RESV3 (0x71) > +#define MT6360_PMU_FLED1_CTRL (0x72) > +#define MT6360_PMU_FLED_STRB_CTRL (0x73) > +#define MT6360_PMU_FLED1_STRB_CTRL2 (0x74) > +#define MT6360_PMU_FLED1_TOR_CTRL (0x75) > +#define MT6360_PMU_FLED2_CTRL (0x76) > +#define MT6360_PMU_RESV4 (0x77) > +#define MT6360_PMU_FLED2_STRB_CTRL2 (0x78) > +#define MT6360_PMU_FLED2_TOR_CTRL (0x79) > +#define MT6360_PMU_FLED_VMIDTRK_CTRL1 (0x7A) > +#define MT6360_PMU_FLED_VMID_RTM (0x7B) > +#define MT6360_PMU_FLED_VMIDTRK_CTRL2 (0x7C) > +#define MT6360_PMU_FLED_PWSEL (0x7D) > +#define MT6360_PMU_FLED_EN (0x7E) > +#define MT6360_PMU_FLED_Hidden1 (0x7F) > +#define MT6360_PMU_RGB_EN (0x80) > +#define MT6360_PMU_RGB1_ISNK (0x81) > +#define MT6360_PMU_RGB2_ISNK (0x82) > +#define MT6360_PMU_RGB3_ISNK (0x83) > +#define MT6360_PMU_RGB_ML_ISNK (0x84) > +#define MT6360_PMU_RGB1_DIM (0x85) > +#define MT6360_PMU_RGB2_DIM (0x86) > +#define MT6360_PMU_RGB3_DIM (0x87) > +#define MT6360_PMU_RESV5 (0x88) > +#define MT6360_PMU_RGB12_Freq (0x89) > +#define MT6360_PMU_RGB34_Freq (0x8A) > +#define MT6360_PMU_RGB1_Tr (0x8B) > +#define MT6360_PMU_RGB1_Tf (0x8C) > +#define MT6360_PMU_RGB1_TON_TOFF (0x8D) > +#define MT6360_PMU_RGB2_Tr (0x8E) > +#define MT6360_PMU_RGB2_Tf (0x8F) > +#define MT6360_PMU_RGB2_TON_TOFF (0x90) > +#define MT6360_PMU_RGB3_Tr (0x91) > +#define MT6360_PMU_RGB3_Tf (0x92) > +#define MT6360_PMU_RGB3_TON_TOFF (0x93) > +#define MT6360_PMU_RGB_Hidden_CTRL1 (0x94) > +#define MT6360_PMU_RGB_Hidden_CTRL2 (0x95) > +#define MT6360_PMU_RESV6 (0x97) > +#define MT6360_PMU_SPARE1 (0x9A) > +#define MT6360_PMU_SPARE2 (0xA0) > +#define MT6360_PMU_SPARE3 (0xB0) > +#define MT6360_PMU_SPARE4 (0xC0) > +#define MT6360_PMU_CHG_IRQ1 (0xD0) > +#define MT6360_PMU_CHG_IRQ2 (0xD1) > +#define MT6360_PMU_CHG_IRQ3 (0xD2) > +#define MT6360_PMU_CHG_IRQ4 (0xD3) > +#define MT6360_PMU_CHG_IRQ5 (0xD4) > +#define MT6360_PMU_CHG_IRQ6 (0xD5) > +#define MT6360_PMU_QC_IRQ (0xD6) > +#define MT6360_PMU_FOD_IRQ (0xD7) > +#define MT6360_PMU_BASE_IRQ (0xD8) > +#define MT6360_PMU_FLED_IRQ1 (0xD9) > +#define MT6360_PMU_FLED_IRQ2 (0xDA) > +#define MT6360_PMU_RGB_IRQ (0xDB) > +#define MT6360_PMU_BUCK1_IRQ (0xDC) > +#define MT6360_PMU_BUCK2_IRQ (0xDD) > +#define MT6360_PMU_LDO_IRQ1 (0xDE) > +#define MT6360_PMU_LDO_IRQ2 (0xDF) > +#define MT6360_PMU_CHG_STAT1 (0xE0) > +#define MT6360_PMU_CHG_STAT2 (0xE1) > +#define MT6360_PMU_CHG_STAT3 (0xE2) > +#define MT6360_PMU_CHG_STAT4 (0xE3) > +#define MT6360_PMU_CHG_STAT5 (0xE4) > +#define MT6360_PMU_CHG_STAT6 (0xE5) > +#define MT6360_PMU_QC_STAT (0xE6) > +#define MT6360_PMU_FOD_STAT (0xE7) > +#define MT6360_PMU_BASE_STAT (0xE8) > +#define MT6360_PMU_FLED_STAT1 (0xE9) > +#define MT6360_PMU_FLED_STAT2 (0xEA) > +#define MT6360_PMU_RGB_STAT (0xEB) > +#define MT6360_PMU_BUCK1_STAT (0xEC) > +#define MT6360_PMU_BUCK2_STAT (0xED) > +#define MT6360_PMU_LDO_STAT1 (0xEE) > +#define MT6360_PMU_LDO_STAT2 (0xEF) > +#define MT6360_PMU_CHG_MASK1 (0xF0) > +#define MT6360_PMU_CHG_MASK2 (0xF1) > +#define MT6360_PMU_CHG_MASK3 (0xF2) > +#define MT6360_PMU_CHG_MASK4 (0xF3) > +#define MT6360_PMU_CHG_MASK5 (0xF4) > +#define MT6360_PMU_CHG_MASK6 (0xF5) > +#define MT6360_PMU_QC_MASK (0xF6) > +#define MT6360_PMU_FOD_MASK (0xF7) > +#define MT6360_PMU_BASE_MASK (0xF8) > +#define MT6360_PMU_FLED_MASK1 (0xF9) > +#define MT6360_PMU_FLED_MASK2 (0xFA) > +#define MT6360_PMU_FAULTB_MASK (0xFB) > +#define MT6360_PMU_BUCK1_MASK (0xFC) > +#define MT6360_PMU_BUCK2_MASK (0xFD) > +#define MT6360_PMU_LDO_MASK1 (0xFE) > +#define MT6360_PMU_LDO_MASK2 (0xFF) > +#define MT6360_PMU_MAXREG (MT6360_PMU_LDO_MASK2) > + > +/* MT6360_PMU_IRQ_SET */ > +#define MT6360_PMU_IRQ_REGNUM (MT6360_PMU_LDO_IRQ2 - MT6360_PMU_CHG_IRQ1 + 1) > +#define MT6360_IRQ_RETRIG BIT(2) > + > +#define CHIP_VEN_MASK (0xF0) > +#define CHIP_VEN_MT6360 (0x50) > +#define CHIP_REV_MASK (0x0F) > + > +#endif /* __MT6360_H__ */ > _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2020-03-04 14:56 ` Matthias Brugger 0 siblings, 0 replies; 1767+ messages in thread From: Matthias Brugger @ 2020-03-04 14:56 UTC (permalink / raw) To: Gene Chen, lee.jones Cc: gene_chen, linux-kernel, cy_huang, linux-mediatek, Wilma.Wu, linux-arm-kernel, shufan_lee Please resend with appropiate commit message. On 03/03/2020 16:27, Gene Chen wrote: > Add mfd driver for mt6360 pmic chip include > Battery Charger/USB_PD/Flash LED/RGB LED/LDO/Buck > > Signed-off-by: Gene Chen <gene_chen@richtek.com > --- > drivers/mfd/Kconfig | 12 ++ > drivers/mfd/Makefile | 1 + > drivers/mfd/mt6360-core.c | 425 +++++++++++++++++++++++++++++++++++++++++++++ > include/linux/mfd/mt6360.h | 240 +++++++++++++++++++++++++ > 4 files changed, 678 insertions(+) > create mode 100644 drivers/mfd/mt6360-core.c > create mode 100644 include/linux/mfd/mt6360.h > > changelogs between v1 & v2 > - include missing header file > > changelogs between v2 & v3 > - add changelogs > > changelogs between v3 & v4 > - fix Kconfig description > - replace mt6360_pmu_info with mt6360_pmu_data > - replace probe with probe_new > - remove unnecessary irq_chip variable > - remove annotation > - replace MT6360_MFD_CELL with OF_MFD_CELL > > changelogs between v4 & v5 > - remove unnecessary parse dt function > - use devm_i2c_new_dummy_device > - add base-commit message > > changelogs between v5 & v6 > - review return value > - remove i2c id_table > - use GPL license v2 > > changelogs between v6 & v7 > - add author description > - replace MT6360_REGMAP_IRQ_REG by REGMAP_IRQ_REG_LINE > - remove mt6360-private.h > > changelogs between v7 & v8 > - fix kbuild auto reboot by include interrupt header > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 2b20329..0f8c341 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -857,6 +857,18 @@ config MFD_MAX8998 > additional drivers must be enabled in order to use the functionality > of the device. > > +config MFD_MT6360 > + tristate "Mediatek MT6360 SubPMIC" > + select MFD_CORE > + select REGMAP_I2C > + select REGMAP_IRQ > + depends on I2C > + help > + Say Y here to enable MT6360 PMU/PMIC/LDO functional support. > + PMU part includes Charger, Flashlight, RGB LED > + PMIC part includes 2-channel BUCKs and 2-channel LDOs > + LDO part includes 4-channel LDOs > + > config MFD_MT6397 > tristate "MediaTek MT6397 PMIC Support" > select MFD_CORE > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > index b83f172..8c35816 100644 > --- a/drivers/mfd/Makefile > +++ b/drivers/mfd/Makefile > @@ -238,6 +238,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o > obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o > obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o > obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI) += intel_soc_pmic_chtdc_ti.o > +obj-$(CONFIG_MFD_MT6360) += mt6360-core.o > mt6397-objs := mt6397-core.o mt6397-irq.o > obj-$(CONFIG_MFD_MT6397) += mt6397.o > obj-$(CONFIG_INTEL_SOC_PMIC_MRFLD) += intel_soc_pmic_mrfld.o > diff --git a/drivers/mfd/mt6360-core.c b/drivers/mfd/mt6360-core.c > new file mode 100644 > index 0000000..d1168f8 > --- /dev/null > +++ b/drivers/mfd/mt6360-core.c > @@ -0,0 +1,425 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c) 2019 MediaTek Inc. > + * > + * Author: Gene Chen <gene_chen@richtek.com> > + */ > + > +#include <linux/i2c.h> > +#include <linux/init.h> > +#include <linux/interrupt.h> > +#include <linux/kernel.h> > +#include <linux/mfd/core.h> > +#include <linux/module.h> > +#include <linux/of_irq.h> > +#include <linux/of_platform.h> > +#include <linux/version.h> > + > +#include <linux/mfd/mt6360.h> > + > +/* reg 0 -> 0 ~ 7 */ > +#define MT6360_CHG_TREG_EVT (4) > +#define MT6360_CHG_AICR_EVT (5) > +#define MT6360_CHG_MIVR_EVT (6) > +#define MT6360_PWR_RDY_EVT (7) > +/* REG 1 -> 8 ~ 15 */ > +#define MT6360_CHG_BATSYSUV_EVT (9) > +#define MT6360_FLED_CHG_VINOVP_EVT (11) > +#define MT6360_CHG_VSYSUV_EVT (12) > +#define MT6360_CHG_VSYSOV_EVT (13) > +#define MT6360_CHG_VBATOV_EVT (14) > +#define MT6360_CHG_VBUSOV_EVT (15) > +/* REG 2 -> 16 ~ 23 */ > +/* REG 3 -> 24 ~ 31 */ > +#define MT6360_WD_PMU_DET (25) > +#define MT6360_WD_PMU_DONE (26) > +#define MT6360_CHG_TMRI (27) > +#define MT6360_CHG_ADPBADI (29) > +#define MT6360_CHG_RVPI (30) > +#define MT6360_OTPI (31) > +/* REG 4 -> 32 ~ 39 */ > +#define MT6360_CHG_AICCMEASL (32) > +#define MT6360_CHGDET_DONEI (34) > +#define MT6360_WDTMRI (35) > +#define MT6360_SSFINISHI (36) > +#define MT6360_CHG_RECHGI (37) > +#define MT6360_CHG_TERMI (38) > +#define MT6360_CHG_IEOCI (39) > +/* REG 5 -> 40 ~ 47 */ > +#define MT6360_PUMPX_DONEI (40) > +#define MT6360_BAT_OVP_ADC_EVT (41) > +#define MT6360_TYPEC_OTP_EVT (42) > +#define MT6360_ADC_WAKEUP_EVT (43) > +#define MT6360_ADC_DONEI (44) > +#define MT6360_BST_BATUVI (45) > +#define MT6360_BST_VBUSOVI (46) > +#define MT6360_BST_OLPI (47) > +/* REG 6 -> 48 ~ 55 */ > +#define MT6360_ATTACH_I (48) > +#define MT6360_DETACH_I (49) > +#define MT6360_QC30_STPDONE (51) > +#define MT6360_QC_VBUSDET_DONE (52) > +#define MT6360_HVDCP_DET (53) > +#define MT6360_CHGDETI (54) > +#define MT6360_DCDTI (55) > +/* REG 7 -> 56 ~ 63 */ > +#define MT6360_FOD_DONE_EVT (56) > +#define MT6360_FOD_OV_EVT (57) > +#define MT6360_CHRDET_UVP_EVT (58) > +#define MT6360_CHRDET_OVP_EVT (59) > +#define MT6360_CHRDET_EXT_EVT (60) > +#define MT6360_FOD_LR_EVT (61) > +#define MT6360_FOD_HR_EVT (62) > +#define MT6360_FOD_DISCHG_FAIL_EVT (63) > +/* REG 8 -> 64 ~ 71 */ > +#define MT6360_USBID_EVT (64) > +#define MT6360_APWDTRST_EVT (65) > +#define MT6360_EN_EVT (66) > +#define MT6360_QONB_RST_EVT (67) > +#define MT6360_MRSTB_EVT (68) > +#define MT6360_OTP_EVT (69) > +#define MT6360_VDDAOV_EVT (70) > +#define MT6360_SYSUV_EVT (71) > +/* REG 9 -> 72 ~ 79 */ > +#define MT6360_FLED_STRBPIN_EVT (72) > +#define MT6360_FLED_TORPIN_EVT (73) > +#define MT6360_FLED_TX_EVT (74) > +#define MT6360_FLED_LVF_EVT (75) > +#define MT6360_FLED2_SHORT_EVT (78) > +#define MT6360_FLED1_SHORT_EVT (79) > +/* REG 10 -> 80 ~ 87 */ > +#define MT6360_FLED2_STRB_EVT (80) > +#define MT6360_FLED1_STRB_EVT (81) > +#define MT6360_FLED2_STRB_TO_EVT (82) > +#define MT6360_FLED1_STRB_TO_EVT (83) > +#define MT6360_FLED2_TOR_EVT (84) > +#define MT6360_FLED1_TOR_EVT (85) > +/* REG 11 -> 88 ~ 95 */ > +/* REG 12 -> 96 ~ 103 */ > +#define MT6360_BUCK1_PGB_EVT (96) > +#define MT6360_BUCK1_OC_EVT (100) > +#define MT6360_BUCK1_OV_EVT (101) > +#define MT6360_BUCK1_UV_EVT (102) > +/* REG 13 -> 104 ~ 111 */ > +#define MT6360_BUCK2_PGB_EVT (104) > +#define MT6360_BUCK2_OC_EVT (108) > +#define MT6360_BUCK2_OV_EVT (109) > +#define MT6360_BUCK2_UV_EVT (110) > +/* REG 14 -> 112 ~ 119 */ > +#define MT6360_LDO1_OC_EVT (113) > +#define MT6360_LDO2_OC_EVT (114) > +#define MT6360_LDO3_OC_EVT (115) > +#define MT6360_LDO5_OC_EVT (117) > +#define MT6360_LDO6_OC_EVT (118) > +#define MT6360_LDO7_OC_EVT (119) > +/* REG 15 -> 120 ~ 127 */ > +#define MT6360_LDO1_PGB_EVT (121) > +#define MT6360_LDO2_PGB_EVT (122) > +#define MT6360_LDO3_PGB_EVT (123) > +#define MT6360_LDO5_PGB_EVT (125) > +#define MT6360_LDO6_PGB_EVT (126) > +#define MT6360_LDO7_PGB_EVT (127) > + > +static const struct regmap_irq mt6360_pmu_irqs[] = { > + REGMAP_IRQ_REG_LINE(MT6360_CHG_TREG_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_AICR_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_MIVR_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_PWR_RDY_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_BATSYSUV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED_CHG_VINOVP_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_VSYSUV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_VSYSOV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_VBATOV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_VBUSOV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_WD_PMU_DET, 8), > + REGMAP_IRQ_REG_LINE(MT6360_WD_PMU_DONE, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_TMRI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_ADPBADI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_RVPI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_OTPI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_AICCMEASL, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHGDET_DONEI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_WDTMRI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_SSFINISHI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_RECHGI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_TERMI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_IEOCI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_PUMPX_DONEI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHG_TREG_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BAT_OVP_ADC_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_TYPEC_OTP_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_ADC_WAKEUP_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_ADC_DONEI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BST_BATUVI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BST_VBUSOVI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BST_OLPI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_ATTACH_I, 8), > + REGMAP_IRQ_REG_LINE(MT6360_DETACH_I, 8), > + REGMAP_IRQ_REG_LINE(MT6360_QC30_STPDONE, 8), > + REGMAP_IRQ_REG_LINE(MT6360_QC_VBUSDET_DONE, 8), > + REGMAP_IRQ_REG_LINE(MT6360_HVDCP_DET, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHGDETI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_DCDTI, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FOD_DONE_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FOD_OV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHRDET_UVP_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHRDET_OVP_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_CHRDET_EXT_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FOD_LR_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FOD_HR_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FOD_DISCHG_FAIL_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_USBID_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_APWDTRST_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_EN_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_QONB_RST_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_MRSTB_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_OTP_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_VDDAOV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_SYSUV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED_STRBPIN_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED_TORPIN_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED_TX_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED_LVF_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED2_SHORT_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED1_SHORT_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED2_STRB_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED1_STRB_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED2_STRB_TO_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED1_STRB_TO_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED2_TOR_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_FLED1_TOR_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BUCK1_PGB_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BUCK1_OC_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BUCK1_OV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BUCK1_UV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BUCK2_PGB_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BUCK2_OC_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BUCK2_OV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_BUCK2_UV_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO1_OC_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO2_OC_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO3_OC_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO5_OC_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO6_OC_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO7_OC_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO1_PGB_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO2_PGB_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO3_PGB_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO5_PGB_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO6_PGB_EVT, 8), > + REGMAP_IRQ_REG_LINE(MT6360_LDO7_PGB_EVT, 8), > +}; > + > +static int mt6360_pmu_handle_post_irq(void *irq_drv_data) > +{ > + struct mt6360_pmu_data *mpd = irq_drv_data; > + > + return regmap_update_bits(mpd->regmap, > + MT6360_PMU_IRQ_SET, MT6360_IRQ_RETRIG, MT6360_IRQ_RETRIG); > +} > + > +static struct regmap_irq_chip mt6360_pmu_irq_chip = { > + .irqs = mt6360_pmu_irqs, > + .num_irqs = ARRAY_SIZE(mt6360_pmu_irqs), > + .num_regs = MT6360_PMU_IRQ_REGNUM, > + .mask_base = MT6360_PMU_CHG_MASK1, > + .status_base = MT6360_PMU_CHG_IRQ1, > + .ack_base = MT6360_PMU_CHG_IRQ1, > + .init_ack_masked = true, > + .use_ack = true, > + .handle_post_irq = mt6360_pmu_handle_post_irq, > +}; > + > +static const struct regmap_config mt6360_pmu_regmap_config = { > + .reg_bits = 8, > + .val_bits = 8, > + .max_register = MT6360_PMU_MAXREG, > +}; > + > +static const struct resource mt6360_adc_resources[] = { > + DEFINE_RES_IRQ_NAMED(MT6360_ADC_DONEI, "adc_donei"), > +}; > + > +static const struct resource mt6360_chg_resources[] = { > + DEFINE_RES_IRQ_NAMED(MT6360_CHG_TREG_EVT, "chg_treg_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_PWR_RDY_EVT, "pwr_rdy_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_CHG_BATSYSUV_EVT, "chg_batsysuv_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VSYSUV_EVT, "chg_vsysuv_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VSYSOV_EVT, "chg_vsysov_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VBATOV_EVT, "chg_vbatov_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VBUSOV_EVT, "chg_vbusov_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_CHG_AICCMEASL, "chg_aiccmeasl"), > + DEFINE_RES_IRQ_NAMED(MT6360_WDTMRI, "wdtmri"), > + DEFINE_RES_IRQ_NAMED(MT6360_CHG_RECHGI, "chg_rechgi"), > + DEFINE_RES_IRQ_NAMED(MT6360_CHG_TERMI, "chg_termi"), > + DEFINE_RES_IRQ_NAMED(MT6360_CHG_IEOCI, "chg_ieoci"), > + DEFINE_RES_IRQ_NAMED(MT6360_PUMPX_DONEI, "pumpx_donei"), > + DEFINE_RES_IRQ_NAMED(MT6360_ATTACH_I, "attach_i"), > + DEFINE_RES_IRQ_NAMED(MT6360_CHRDET_EXT_EVT, "chrdet_ext_evt"), > +}; > + > +static const struct resource mt6360_led_resources[] = { > + DEFINE_RES_IRQ_NAMED(MT6360_FLED_CHG_VINOVP_EVT, "fled_chg_vinovp_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_FLED_LVF_EVT, "fled_lvf_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_FLED2_SHORT_EVT, "fled2_short_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_FLED1_SHORT_EVT, "fled1_short_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_FLED2_STRB_TO_EVT, "fled2_strb_to_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_FLED1_STRB_TO_EVT, "fled1_strb_to_evt"), > +}; > + > +static const struct resource mt6360_pmic_resources[] = { > + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_PGB_EVT, "buck1_pgb_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_OC_EVT, "buck1_oc_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_OV_EVT, "buck1_ov_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_UV_EVT, "buck1_uv_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_PGB_EVT, "buck2_pgb_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_OC_EVT, "buck2_oc_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_OV_EVT, "buck2_ov_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_UV_EVT, "buck2_uv_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_LDO6_OC_EVT, "ldo6_oc_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_LDO7_OC_EVT, "ldo7_oc_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_LDO6_PGB_EVT, "ldo6_pgb_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_LDO7_PGB_EVT, "ldo7_pgb_evt"), > +}; > + > +static const struct resource mt6360_ldo_resources[] = { > + DEFINE_RES_IRQ_NAMED(MT6360_LDO1_OC_EVT, "ldo1_oc_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_LDO2_OC_EVT, "ldo2_oc_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_LDO3_OC_EVT, "ldo3_oc_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_LDO5_OC_EVT, "ldo5_oc_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_LDO1_PGB_EVT, "ldo1_pgb_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_LDO2_PGB_EVT, "ldo2_pgb_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_LDO3_PGB_EVT, "ldo3_pgb_evt"), > + DEFINE_RES_IRQ_NAMED(MT6360_LDO5_PGB_EVT, "ldo5_pgb_evt"), > +}; > + > +static const struct mfd_cell mt6360_devs[] = { > + OF_MFD_CELL("mt6360_adc", mt6360_adc_resources, > + NULL, 0, 0, "mediatek,mt6360_adc"), > + OF_MFD_CELL("mt6360_chg", mt6360_chg_resources, > + NULL, 0, 0, "mediatek,mt6360_chg"), > + OF_MFD_CELL("mt6360_led", mt6360_led_resources, > + NULL, 0, 0, "mediatek,mt6360_led"), > + OF_MFD_CELL("mt6360_pmic", mt6360_pmic_resources, > + NULL, 0, 0, "mediatek,mt6360_pmic"), > + OF_MFD_CELL("mt6360_ldo", mt6360_ldo_resources, > + NULL, 0, 0, "mediatek,mt6360_ldo"), > + OF_MFD_CELL("mt6360_tcpc", NULL, > + NULL, 0, 0, "mediatek,mt6360_tcpc"), > +}; > + > +static const unsigned short mt6360_slave_addr[MT6360_SLAVE_MAX] = { > + MT6360_PMU_SLAVEID, > + MT6360_PMIC_SLAVEID, > + MT6360_LDO_SLAVEID, > + MT6360_TCPC_SLAVEID, > +}; > + > +static int mt6360_pmu_probe(struct i2c_client *client) > +{ > + struct mt6360_pmu_data *mpd; > + unsigned int reg_data; > + int i, ret; > + > + mpd = devm_kzalloc(&client->dev, sizeof(*mpd), GFP_KERNEL); > + if (!mpd) > + return -ENOMEM; > + > + mpd->dev = &client->dev; > + i2c_set_clientdata(client, mpd); > + > + mpd->regmap = devm_regmap_init_i2c(client, &mt6360_pmu_regmap_config); > + if (IS_ERR(mpd->regmap)) { > + dev_err(&client->dev, "Failed to register regmap\n"); > + return PTR_ERR(mpd->regmap); > + } > + > + ret = regmap_read(mpd->regmap, MT6360_PMU_DEV_INFO, ®_data); > + if (ret) { > + dev_err(&client->dev, "Device not found\n"); > + return ret; > + } > + > + mpd->chip_rev = reg_data & CHIP_REV_MASK; > + if (mpd->chip_rev != CHIP_VEN_MT6360) { > + dev_err(&client->dev, "Device not supported\n"); > + return -ENODEV; > + } > + > + mt6360_pmu_irq_chip.irq_drv_data = mpd; > + ret = devm_regmap_add_irq_chip(&client->dev, mpd->regmap, client->irq, > + IRQF_TRIGGER_FALLING, 0, > + &mt6360_pmu_irq_chip, &mpd->irq_data); > + if (ret) { > + dev_err(&client->dev, "Failed to add Regmap IRQ Chip\n"); > + return ret; > + } > + > + mpd->i2c[0] = client; > + for (i = 1; i < MT6360_SLAVE_MAX; i++) { > + mpd->i2c[i] = devm_i2c_new_dummy_device(&client->dev, > + client->adapter, > + mt6360_slave_addr[i]); > + if (IS_ERR(mpd->i2c[i])) { > + dev_err(&client->dev, > + "Failed to get new dummy I2C device for address 0x%x", > + mt6360_slave_addr[i]); > + return PTR_ERR(mpd->i2c[i]); > + } > + i2c_set_clientdata(mpd->i2c[i], mpd); > + } > + > + ret = devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_AUTO, > + mt6360_devs, ARRAY_SIZE(mt6360_devs), NULL, > + 0, regmap_irq_get_domain(mpd->irq_data)); > + if (ret) { > + dev_err(&client->dev, > + "Failed to register subordinate devices\n"); > + return ret; > + } > + > + return 0; > +} > + > +static int __maybe_unused mt6360_pmu_suspend(struct device *dev) > +{ > + struct i2c_client *i2c = to_i2c_client(dev); > + > + if (device_may_wakeup(dev)) > + enable_irq_wake(i2c->irq); > + > + return 0; > +} > + > +static int __maybe_unused mt6360_pmu_resume(struct device *dev) > +{ > + > + struct i2c_client *i2c = to_i2c_client(dev); > + > + if (device_may_wakeup(dev)) > + disable_irq_wake(i2c->irq); > + > + return 0; > +} > + > +static SIMPLE_DEV_PM_OPS(mt6360_pmu_pm_ops, > + mt6360_pmu_suspend, mt6360_pmu_resume); > + > +static const struct of_device_id __maybe_unused mt6360_pmu_of_id[] = { > + { .compatible = "mediatek,mt6360_pmu", }, > + {}, > +}; > +MODULE_DEVICE_TABLE(of, mt6360_pmu_of_id); > + > +static struct i2c_driver mt6360_pmu_driver = { > + .driver = { > + .pm = &mt6360_pmu_pm_ops, > + .of_match_table = of_match_ptr(mt6360_pmu_of_id), > + }, > + .probe_new = mt6360_pmu_probe, > +}; > +module_i2c_driver(mt6360_pmu_driver); > + > +MODULE_AUTHOR("Gene Chen <gene_chen@richtek.com>"); > +MODULE_DESCRIPTION("MT6360 PMU I2C Driver"); > +MODULE_LICENSE("GPL v2"); > diff --git a/include/linux/mfd/mt6360.h b/include/linux/mfd/mt6360.h > new file mode 100644 > index 0000000..c03e6d1 > --- /dev/null > +++ b/include/linux/mfd/mt6360.h > @@ -0,0 +1,240 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Copyright (c) 2019 MediaTek Inc. > + */ > + > +#ifndef __MT6360_H__ > +#define __MT6360_H__ > + > +#include <linux/regmap.h> > + > +enum { > + MT6360_SLAVE_PMU = 0, > + MT6360_SLAVE_PMIC, > + MT6360_SLAVE_LDO, > + MT6360_SLAVE_TCPC, > + MT6360_SLAVE_MAX, > +}; > + > +#define MT6360_PMU_SLAVEID (0x34) > +#define MT6360_PMIC_SLAVEID (0x1A) > +#define MT6360_LDO_SLAVEID (0x64) > +#define MT6360_TCPC_SLAVEID (0x4E) > + > +struct mt6360_pmu_data { > + struct i2c_client *i2c[MT6360_SLAVE_MAX]; > + struct device *dev; > + struct regmap *regmap; > + struct regmap_irq_chip_data *irq_data; > + unsigned int chip_rev; > +}; > + > +/* PMU register defininition */ > +#define MT6360_PMU_DEV_INFO (0x00) > +#define MT6360_PMU_CORE_CTRL1 (0x01) > +#define MT6360_PMU_RST1 (0x02) > +#define MT6360_PMU_CRCEN (0x03) > +#define MT6360_PMU_RST_PAS_CODE1 (0x04) > +#define MT6360_PMU_RST_PAS_CODE2 (0x05) > +#define MT6360_PMU_CORE_CTRL2 (0x06) > +#define MT6360_PMU_TM_PAS_CODE1 (0x07) > +#define MT6360_PMU_TM_PAS_CODE2 (0x08) > +#define MT6360_PMU_TM_PAS_CODE3 (0x09) > +#define MT6360_PMU_TM_PAS_CODE4 (0x0A) > +#define MT6360_PMU_IRQ_IND (0x0B) > +#define MT6360_PMU_IRQ_MASK (0x0C) > +#define MT6360_PMU_IRQ_SET (0x0D) > +#define MT6360_PMU_SHDN_CTRL (0x0E) > +#define MT6360_PMU_TM_INF (0x0F) > +#define MT6360_PMU_I2C_CTRL (0x10) > +#define MT6360_PMU_CHG_CTRL1 (0x11) > +#define MT6360_PMU_CHG_CTRL2 (0x12) > +#define MT6360_PMU_CHG_CTRL3 (0x13) > +#define MT6360_PMU_CHG_CTRL4 (0x14) > +#define MT6360_PMU_CHG_CTRL5 (0x15) > +#define MT6360_PMU_CHG_CTRL6 (0x16) > +#define MT6360_PMU_CHG_CTRL7 (0x17) > +#define MT6360_PMU_CHG_CTRL8 (0x18) > +#define MT6360_PMU_CHG_CTRL9 (0x19) > +#define MT6360_PMU_CHG_CTRL10 (0x1A) > +#define MT6360_PMU_CHG_CTRL11 (0x1B) > +#define MT6360_PMU_CHG_CTRL12 (0x1C) > +#define MT6360_PMU_CHG_CTRL13 (0x1D) > +#define MT6360_PMU_CHG_CTRL14 (0x1E) > +#define MT6360_PMU_CHG_CTRL15 (0x1F) > +#define MT6360_PMU_CHG_CTRL16 (0x20) > +#define MT6360_PMU_CHG_AICC_RESULT (0x21) > +#define MT6360_PMU_DEVICE_TYPE (0x22) > +#define MT6360_PMU_QC_CONTROL1 (0x23) > +#define MT6360_PMU_QC_CONTROL2 (0x24) > +#define MT6360_PMU_QC30_CONTROL1 (0x25) > +#define MT6360_PMU_QC30_CONTROL2 (0x26) > +#define MT6360_PMU_USB_STATUS1 (0x27) > +#define MT6360_PMU_QC_STATUS1 (0x28) > +#define MT6360_PMU_QC_STATUS2 (0x29) > +#define MT6360_PMU_CHG_PUMP (0x2A) > +#define MT6360_PMU_CHG_CTRL17 (0x2B) > +#define MT6360_PMU_CHG_CTRL18 (0x2C) > +#define MT6360_PMU_CHRDET_CTRL1 (0x2D) > +#define MT6360_PMU_CHRDET_CTRL2 (0x2E) > +#define MT6360_PMU_DPDN_CTRL (0x2F) > +#define MT6360_PMU_CHG_HIDDEN_CTRL1 (0x30) > +#define MT6360_PMU_CHG_HIDDEN_CTRL2 (0x31) > +#define MT6360_PMU_CHG_HIDDEN_CTRL3 (0x32) > +#define MT6360_PMU_CHG_HIDDEN_CTRL4 (0x33) > +#define MT6360_PMU_CHG_HIDDEN_CTRL5 (0x34) > +#define MT6360_PMU_CHG_HIDDEN_CTRL6 (0x35) > +#define MT6360_PMU_CHG_HIDDEN_CTRL7 (0x36) > +#define MT6360_PMU_CHG_HIDDEN_CTRL8 (0x37) > +#define MT6360_PMU_CHG_HIDDEN_CTRL9 (0x38) > +#define MT6360_PMU_CHG_HIDDEN_CTRL10 (0x39) > +#define MT6360_PMU_CHG_HIDDEN_CTRL11 (0x3A) > +#define MT6360_PMU_CHG_HIDDEN_CTRL12 (0x3B) > +#define MT6360_PMU_CHG_HIDDEN_CTRL13 (0x3C) > +#define MT6360_PMU_CHG_HIDDEN_CTRL14 (0x3D) > +#define MT6360_PMU_CHG_HIDDEN_CTRL15 (0x3E) > +#define MT6360_PMU_CHG_HIDDEN_CTRL16 (0x3F) > +#define MT6360_PMU_CHG_HIDDEN_CTRL17 (0x40) > +#define MT6360_PMU_CHG_HIDDEN_CTRL18 (0x41) > +#define MT6360_PMU_CHG_HIDDEN_CTRL19 (0x42) > +#define MT6360_PMU_CHG_HIDDEN_CTRL20 (0x43) > +#define MT6360_PMU_CHG_HIDDEN_CTRL21 (0x44) > +#define MT6360_PMU_CHG_HIDDEN_CTRL22 (0x45) > +#define MT6360_PMU_CHG_HIDDEN_CTRL23 (0x46) > +#define MT6360_PMU_CHG_HIDDEN_CTRL24 (0x47) > +#define MT6360_PMU_CHG_HIDDEN_CTRL25 (0x48) > +#define MT6360_PMU_BC12_CTRL (0x49) > +#define MT6360_PMU_CHG_STAT (0x4A) > +#define MT6360_PMU_RESV1 (0x4B) > +#define MT6360_PMU_TYPEC_OTP_TH_SEL_CODEH (0x4E) > +#define MT6360_PMU_TYPEC_OTP_TH_SEL_CODEL (0x4F) > +#define MT6360_PMU_TYPEC_OTP_HYST_TH (0x50) > +#define MT6360_PMU_TYPEC_OTP_CTRL (0x51) > +#define MT6360_PMU_ADC_BAT_DATA_H (0x52) > +#define MT6360_PMU_ADC_BAT_DATA_L (0x53) > +#define MT6360_PMU_IMID_BACKBST_ON (0x54) > +#define MT6360_PMU_IMID_BACKBST_OFF (0x55) > +#define MT6360_PMU_ADC_CONFIG (0x56) > +#define MT6360_PMU_ADC_EN2 (0x57) > +#define MT6360_PMU_ADC_IDLE_T (0x58) > +#define MT6360_PMU_ADC_RPT_1 (0x5A) > +#define MT6360_PMU_ADC_RPT_2 (0x5B) > +#define MT6360_PMU_ADC_RPT_3 (0x5C) > +#define MT6360_PMU_ADC_RPT_ORG1 (0x5D) > +#define MT6360_PMU_ADC_RPT_ORG2 (0x5E) > +#define MT6360_PMU_BAT_OVP_TH_SEL_CODEH (0x5F) > +#define MT6360_PMU_BAT_OVP_TH_SEL_CODEL (0x60) > +#define MT6360_PMU_CHG_CTRL19 (0x61) > +#define MT6360_PMU_VDDASUPPLY (0x62) > +#define MT6360_PMU_BC12_MANUAL (0x63) > +#define MT6360_PMU_CHGDET_FUNC (0x64) > +#define MT6360_PMU_FOD_CTRL (0x65) > +#define MT6360_PMU_CHG_CTRL20 (0x66) > +#define MT6360_PMU_CHG_HIDDEN_CTRL26 (0x67) > +#define MT6360_PMU_CHG_HIDDEN_CTRL27 (0x68) > +#define MT6360_PMU_RESV2 (0x69) > +#define MT6360_PMU_USBID_CTRL1 (0x6D) > +#define MT6360_PMU_USBID_CTRL2 (0x6E) > +#define MT6360_PMU_USBID_CTRL3 (0x6F) > +#define MT6360_PMU_FLED_CFG (0x70) > +#define MT6360_PMU_RESV3 (0x71) > +#define MT6360_PMU_FLED1_CTRL (0x72) > +#define MT6360_PMU_FLED_STRB_CTRL (0x73) > +#define MT6360_PMU_FLED1_STRB_CTRL2 (0x74) > +#define MT6360_PMU_FLED1_TOR_CTRL (0x75) > +#define MT6360_PMU_FLED2_CTRL (0x76) > +#define MT6360_PMU_RESV4 (0x77) > +#define MT6360_PMU_FLED2_STRB_CTRL2 (0x78) > +#define MT6360_PMU_FLED2_TOR_CTRL (0x79) > +#define MT6360_PMU_FLED_VMIDTRK_CTRL1 (0x7A) > +#define MT6360_PMU_FLED_VMID_RTM (0x7B) > +#define MT6360_PMU_FLED_VMIDTRK_CTRL2 (0x7C) > +#define MT6360_PMU_FLED_PWSEL (0x7D) > +#define MT6360_PMU_FLED_EN (0x7E) > +#define MT6360_PMU_FLED_Hidden1 (0x7F) > +#define MT6360_PMU_RGB_EN (0x80) > +#define MT6360_PMU_RGB1_ISNK (0x81) > +#define MT6360_PMU_RGB2_ISNK (0x82) > +#define MT6360_PMU_RGB3_ISNK (0x83) > +#define MT6360_PMU_RGB_ML_ISNK (0x84) > +#define MT6360_PMU_RGB1_DIM (0x85) > +#define MT6360_PMU_RGB2_DIM (0x86) > +#define MT6360_PMU_RGB3_DIM (0x87) > +#define MT6360_PMU_RESV5 (0x88) > +#define MT6360_PMU_RGB12_Freq (0x89) > +#define MT6360_PMU_RGB34_Freq (0x8A) > +#define MT6360_PMU_RGB1_Tr (0x8B) > +#define MT6360_PMU_RGB1_Tf (0x8C) > +#define MT6360_PMU_RGB1_TON_TOFF (0x8D) > +#define MT6360_PMU_RGB2_Tr (0x8E) > +#define MT6360_PMU_RGB2_Tf (0x8F) > +#define MT6360_PMU_RGB2_TON_TOFF (0x90) > +#define MT6360_PMU_RGB3_Tr (0x91) > +#define MT6360_PMU_RGB3_Tf (0x92) > +#define MT6360_PMU_RGB3_TON_TOFF (0x93) > +#define MT6360_PMU_RGB_Hidden_CTRL1 (0x94) > +#define MT6360_PMU_RGB_Hidden_CTRL2 (0x95) > +#define MT6360_PMU_RESV6 (0x97) > +#define MT6360_PMU_SPARE1 (0x9A) > +#define MT6360_PMU_SPARE2 (0xA0) > +#define MT6360_PMU_SPARE3 (0xB0) > +#define MT6360_PMU_SPARE4 (0xC0) > +#define MT6360_PMU_CHG_IRQ1 (0xD0) > +#define MT6360_PMU_CHG_IRQ2 (0xD1) > +#define MT6360_PMU_CHG_IRQ3 (0xD2) > +#define MT6360_PMU_CHG_IRQ4 (0xD3) > +#define MT6360_PMU_CHG_IRQ5 (0xD4) > +#define MT6360_PMU_CHG_IRQ6 (0xD5) > +#define MT6360_PMU_QC_IRQ (0xD6) > +#define MT6360_PMU_FOD_IRQ (0xD7) > +#define MT6360_PMU_BASE_IRQ (0xD8) > +#define MT6360_PMU_FLED_IRQ1 (0xD9) > +#define MT6360_PMU_FLED_IRQ2 (0xDA) > +#define MT6360_PMU_RGB_IRQ (0xDB) > +#define MT6360_PMU_BUCK1_IRQ (0xDC) > +#define MT6360_PMU_BUCK2_IRQ (0xDD) > +#define MT6360_PMU_LDO_IRQ1 (0xDE) > +#define MT6360_PMU_LDO_IRQ2 (0xDF) > +#define MT6360_PMU_CHG_STAT1 (0xE0) > +#define MT6360_PMU_CHG_STAT2 (0xE1) > +#define MT6360_PMU_CHG_STAT3 (0xE2) > +#define MT6360_PMU_CHG_STAT4 (0xE3) > +#define MT6360_PMU_CHG_STAT5 (0xE4) > +#define MT6360_PMU_CHG_STAT6 (0xE5) > +#define MT6360_PMU_QC_STAT (0xE6) > +#define MT6360_PMU_FOD_STAT (0xE7) > +#define MT6360_PMU_BASE_STAT (0xE8) > +#define MT6360_PMU_FLED_STAT1 (0xE9) > +#define MT6360_PMU_FLED_STAT2 (0xEA) > +#define MT6360_PMU_RGB_STAT (0xEB) > +#define MT6360_PMU_BUCK1_STAT (0xEC) > +#define MT6360_PMU_BUCK2_STAT (0xED) > +#define MT6360_PMU_LDO_STAT1 (0xEE) > +#define MT6360_PMU_LDO_STAT2 (0xEF) > +#define MT6360_PMU_CHG_MASK1 (0xF0) > +#define MT6360_PMU_CHG_MASK2 (0xF1) > +#define MT6360_PMU_CHG_MASK3 (0xF2) > +#define MT6360_PMU_CHG_MASK4 (0xF3) > +#define MT6360_PMU_CHG_MASK5 (0xF4) > +#define MT6360_PMU_CHG_MASK6 (0xF5) > +#define MT6360_PMU_QC_MASK (0xF6) > +#define MT6360_PMU_FOD_MASK (0xF7) > +#define MT6360_PMU_BASE_MASK (0xF8) > +#define MT6360_PMU_FLED_MASK1 (0xF9) > +#define MT6360_PMU_FLED_MASK2 (0xFA) > +#define MT6360_PMU_FAULTB_MASK (0xFB) > +#define MT6360_PMU_BUCK1_MASK (0xFC) > +#define MT6360_PMU_BUCK2_MASK (0xFD) > +#define MT6360_PMU_LDO_MASK1 (0xFE) > +#define MT6360_PMU_LDO_MASK2 (0xFF) > +#define MT6360_PMU_MAXREG (MT6360_PMU_LDO_MASK2) > + > +/* MT6360_PMU_IRQ_SET */ > +#define MT6360_PMU_IRQ_REGNUM (MT6360_PMU_LDO_IRQ2 - MT6360_PMU_CHG_IRQ1 + 1) > +#define MT6360_IRQ_RETRIG BIT(2) > + > +#define CHIP_VEN_MASK (0xF0) > +#define CHIP_VEN_MT6360 (0x50) > +#define CHIP_REV_MASK (0x0F) > + > +#endif /* __MT6360_H__ */ > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-03-04 14:56 ` Re: Matthias Brugger @ 2020-03-04 15:15 ` Lee Jones -1 siblings, 0 replies; 1767+ messages in thread From: Lee Jones @ 2020-03-04 15:15 UTC (permalink / raw) To: Matthias Brugger Cc: gene_chen, linux-kernel, cy_huang, linux-mediatek, Gene Chen, Wilma.Wu, linux-arm-kernel, shufan_lee On Wed, 04 Mar 2020, Matthias Brugger wrote: > Please resend with appropiate commit message. Please refrain from top-posting and don't forget to snip. > On 03/03/2020 16:27, Gene Chen wrote: > > Add mfd driver for mt6360 pmic chip include Looks like your formatting is off. How was this patch sent? Best practice is to use `git send-email`. > > Battery Charger/USB_PD/Flash LED/RGB LED/LDO/Buck > > > > Signed-off-by: Gene Chen <gene_chen@richtek.com > > --- > > drivers/mfd/Kconfig | 12 ++ > > drivers/mfd/Makefile | 1 + > > drivers/mfd/mt6360-core.c | 425 +++++++++++++++++++++++++++++++++++++++++++++ > > include/linux/mfd/mt6360.h | 240 +++++++++++++++++++++++++ > > 4 files changed, 678 insertions(+) > > create mode 100644 drivers/mfd/mt6360-core.c > > create mode 100644 include/linux/mfd/mt6360.h -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2020-03-04 15:15 ` Lee Jones 0 siblings, 0 replies; 1767+ messages in thread From: Lee Jones @ 2020-03-04 15:15 UTC (permalink / raw) To: Matthias Brugger Cc: gene_chen, linux-kernel, cy_huang, linux-mediatek, Gene Chen, Wilma.Wu, linux-arm-kernel, shufan_lee On Wed, 04 Mar 2020, Matthias Brugger wrote: > Please resend with appropiate commit message. Please refrain from top-posting and don't forget to snip. > On 03/03/2020 16:27, Gene Chen wrote: > > Add mfd driver for mt6360 pmic chip include Looks like your formatting is off. How was this patch sent? Best practice is to use `git send-email`. > > Battery Charger/USB_PD/Flash LED/RGB LED/LDO/Buck > > > > Signed-off-by: Gene Chen <gene_chen@richtek.com > > --- > > drivers/mfd/Kconfig | 12 ++ > > drivers/mfd/Makefile | 1 + > > drivers/mfd/mt6360-core.c | 425 +++++++++++++++++++++++++++++++++++++++++++++ > > include/linux/mfd/mt6360.h | 240 +++++++++++++++++++++++++ > > 4 files changed, 678 insertions(+) > > create mode 100644 drivers/mfd/mt6360-core.c > > create mode 100644 include/linux/mfd/mt6360.h -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-03-04 15:15 ` Re: Lee Jones @ 2020-03-04 18:00 ` Matthias Brugger -1 siblings, 0 replies; 1767+ messages in thread From: Matthias Brugger @ 2020-03-04 18:00 UTC (permalink / raw) To: Lee Jones Cc: gene_chen, linux-kernel, cy_huang, linux-mediatek, Gene Chen, Wilma.Wu, linux-arm-kernel, shufan_lee On 04/03/2020 16:15, Lee Jones wrote: > On Wed, 04 Mar 2020, Matthias Brugger wrote: > >> Please resend with appropiate commit message. > > Please refrain from top-posting and don't forget to snip. > It's difficult to write something below a missing subject line without top-posting. ;) Sorry for forgetting to snip. Regards, Matthias _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2020-03-04 18:00 ` Matthias Brugger 0 siblings, 0 replies; 1767+ messages in thread From: Matthias Brugger @ 2020-03-04 18:00 UTC (permalink / raw) To: Lee Jones Cc: gene_chen, linux-kernel, cy_huang, linux-mediatek, Gene Chen, Wilma.Wu, linux-arm-kernel, shufan_lee On 04/03/2020 16:15, Lee Jones wrote: > On Wed, 04 Mar 2020, Matthias Brugger wrote: > >> Please resend with appropiate commit message. > > Please refrain from top-posting and don't forget to snip. > It's difficult to write something below a missing subject line without top-posting. ;) Sorry for forgetting to snip. Regards, Matthias _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2020-02-26 11:57 Ville Syrjälä
2020-02-26 12:08 ` Linus Walleij
0 siblings, 1 reply; 1767+ messages in thread
From: Ville Syrjälä @ 2020-02-26 11:57 UTC (permalink / raw)
To: Linus Walleij
Cc: Josh Wu, Bhuvanchandra DV, Neil Armstrong, Eric Anholt, nouveau,
Guido Günther, open list:DRM PANEL DRIVERS,
Gustaf Lindström, Andrzej Hajda, Laurent Pinchart,
Philipp Zabel, Sam Ravnborg, Marian-Cristian Rotariu, Jagan Teki,
Thomas Hellstrom, Joonyoung Shim, Jonathan Marek,
Stefan Mavrodiev, Adam Ford, Jerry Han
[-- Attachment #1: Type: text/plain, Size: 1850 bytes --]
Subject: Re: [PATCH 04/12] drm: Nuke mode->vrefresh
Message-ID: <20200226115708.GH13686@intel.com>
References: <20200219203544.31013-1-ville.syrjala@linux.intel.com>
<CGME20200219203620eucas1p24b4990a91e758dbcf3e9b943669b0c8f@eucas1p2.samsung.com>
<20200219203544.31013-5-ville.syrjala@linux.intel.com>
<0f278771-79ce-fe23-e72c-3935dbe82d24@samsung.com>
<20200225112114.GA13686@intel.com>
<3ca785f2-9032-aaf9-0965-8657d31116ba@samsung.com>
<20200225154506.GF13686@intel.com>
<20200225192720.GG13686@intel.com>
<CACRpkdZk9QEy+Kzkmy4BXiHB+aq9hprf=dmA_-R23yqH3NCt1g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CACRpkdZk9QEy+Kzkmy4BXiHB+aq9hprf=dmA_-R23yqH3NCt1g@mail.gmail.com>
X-Patchwork-Hint: comment
User-Agent: Mutt/1.10.1 (2018-07-13)
On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote:
> On Tue, Feb 25, 2020 at 8:27 PM Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
>
> > OK, so I went ahead a wrote a bit of cocci [1] to find the bad apples.
>
> That's impressive :D
>
> > Unfortunately it found a lot of strange stuff:
>
> I will answer for the weirdness I caused.
>
> I have long suspected that a whole bunch of the "simple" displays
> are not simple but contains a display controller and memory.
> That means that the speed over the link to the display and
> actual refresh rate on the actual display is asymmetric because
> well we are just updating a RAM, the resolution just limits how
> much data we are sending, the clock limits the speed on the
> bus over to the RAM on the other side.
IMO even in command mode mode->clock should probably be the actual
dotclock used by the display. If there's another clock for the bus
speed/etc. it should be stored somewhere else.
--
Ville Syrjälä
Intel
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2020-02-26 11:57 (no subject) Ville Syrjälä @ 2020-02-26 12:08 ` Linus Walleij 2020-02-26 14:34 ` Re: Ville Syrjälä 0 siblings, 1 reply; 1767+ messages in thread From: Linus Walleij @ 2020-02-26 12:08 UTC (permalink / raw) To: Ville Syrjälä Cc: Josh Wu, Bhuvanchandra DV, Neil Armstrong, Eric Anholt, nouveau, Guido Günther, Paul Kocialkowski, open list:DRM PANEL DRIVERS, Gustaf Lindström, Andrzej Hajda, Thierry Reding, Laurent Pinchart, Philipp Zabel, Sam Ravnborg, Marian-Cristian Rotariu, Jagan Teki, Thomas Hellstrom, Joonyoung Shim, Jonathan Marek, Stefan Mavrodiev, Adam Ford, Jerry Han, VMware Graphics, Ben Skeggs, H. Nikolaus Schaller, Robert Chiras, Heiko Schocher, Icenowy Zheng, Jonas Karlman, intel-gfx, Maxime Ripard, Alexandre Courbot, Fabio Estevam, open list:ARM/Amlogic Meson..., Vincent Abriou, Andreas Pretzsch, Jernej Skrabec, Alex Gonzalez, Purism Kernel Team, Boris Brezillon, Seung-Woo Kim, Christoph Fritz, Kyungmin Park, Heiko Stuebner, Eugen Hristev, Giulio Benetti On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > > I have long suspected that a whole bunch of the "simple" displays > > are not simple but contains a display controller and memory. > > That means that the speed over the link to the display and > > actual refresh rate on the actual display is asymmetric because > > well we are just updating a RAM, the resolution just limits how > > much data we are sending, the clock limits the speed on the > > bus over to the RAM on the other side. > > IMO even in command mode mode->clock should probably be the actual > dotclock used by the display. If there's another clock for the bus > speed/etc. it should be stored somewhere else. Good point. For the DSI panels we have the field hs_rate for the HS clock in struct mipi_dsi_device which is based on exactly this reasoning. And that is what I actually use for setting the HS clock. The problem is however that we in many cases have so substandard documentation of these panels that we have absolutely no idea about the dotclock. Maybe we should just set it to 0 in these cases? Yours, Linus Walleij _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-02-26 12:08 ` Linus Walleij @ 2020-02-26 14:34 ` Ville Syrjälä 2020-02-26 14:56 ` Re: Linus Walleij 0 siblings, 1 reply; 1767+ messages in thread From: Ville Syrjälä @ 2020-02-26 14:34 UTC (permalink / raw) To: Linus Walleij Cc: Josh Wu, Bhuvanchandra DV, Neil Armstrong, Eric Anholt, nouveau, Guido Günther, Paul Kocialkowski, open list:DRM PANEL DRIVERS, Gustaf Lindström, Andrzej Hajda, Thierry Reding, Laurent Pinchart, Philipp Zabel, Sam Ravnborg, Marian-Cristian Rotariu, Jagan Teki, Thomas Hellstrom, Joonyoung Shim, Jonathan Marek, Stefan Mavrodiev, Adam Ford, Jerry Han, VMware Graphics, Ben Skeggs, H. Nikolaus Schaller, Robert Chiras, Heiko Schocher, Icenowy Zheng, Jonas Karlman, intel-gfx, Maxime Ripard, Alexandre Courbot, Fabio Estevam, open list:ARM/Amlogic Meson..., Vincent Abriou, Andreas Pretzsch, Jernej Skrabec, Alex Gonzalez, Purism Kernel Team, Boris Brezillon, Seung-Woo Kim, Christoph Fritz, Kyungmin Park, Heiko Stuebner, Eugen Hristev, Giulio Benetti On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote: > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä > <ville.syrjala@linux.intel.com> wrote: > > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > > > > I have long suspected that a whole bunch of the "simple" displays > > > are not simple but contains a display controller and memory. > > > That means that the speed over the link to the display and > > > actual refresh rate on the actual display is asymmetric because > > > well we are just updating a RAM, the resolution just limits how > > > much data we are sending, the clock limits the speed on the > > > bus over to the RAM on the other side. > > > > IMO even in command mode mode->clock should probably be the actual > > dotclock used by the display. If there's another clock for the bus > > speed/etc. it should be stored somewhere else. > > Good point. For the DSI panels we have the field hs_rate > for the HS clock in struct mipi_dsi_device which is based > on exactly this reasoning. And that is what I actually use for > setting the HS clock. > > The problem is however that we in many cases have so > substandard documentation of these panels that we have > absolutely no idea about the dotclock. Maybe we should > just set it to 0 in these cases? Don't you always have a TE interrupt or something like that available? Could just measure it from that if no better information is available? -- Ville Syrjälä Intel _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-02-26 14:34 ` Re: Ville Syrjälä @ 2020-02-26 14:56 ` Linus Walleij 2020-02-26 15:08 ` Re: Ville Syrjälä 0 siblings, 1 reply; 1767+ messages in thread From: Linus Walleij @ 2020-02-26 14:56 UTC (permalink / raw) To: Ville Syrjälä Cc: Josh Wu, Bhuvanchandra DV, Neil Armstrong, Eric Anholt, nouveau, Guido Günther, Paul Kocialkowski, open list:DRM PANEL DRIVERS, Gustaf Lindström, Andrzej Hajda, Thierry Reding, Laurent Pinchart, Philipp Zabel, Sam Ravnborg, Marian-Cristian Rotariu, Jagan Teki, Thomas Hellstrom, Joonyoung Shim, Jonathan Marek, Stefan Mavrodiev, Adam Ford, Jerry Han, VMware Graphics, Ben Skeggs, H. Nikolaus Schaller, Robert Chiras, Heiko Schocher, Icenowy Zheng, Jonas Karlman, intel-gfx, Maxime Ripard, Alexandre Courbot, Fabio Estevam, open list:ARM/Amlogic Meson..., Vincent Abriou, Andreas Pretzsch, Jernej Skrabec, Alex Gonzalez, Purism Kernel Team, Boris Brezillon, Seung-Woo Kim, Christoph Fritz, Kyungmin Park, Heiko Stuebner, Eugen Hristev, Giulio Benetti On Wed, Feb 26, 2020 at 3:34 PM Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote: > > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä > > <ville.syrjala@linux.intel.com> wrote: > > > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > > > > > > I have long suspected that a whole bunch of the "simple" displays > > > > are not simple but contains a display controller and memory. > > > > That means that the speed over the link to the display and > > > > actual refresh rate on the actual display is asymmetric because > > > > well we are just updating a RAM, the resolution just limits how > > > > much data we are sending, the clock limits the speed on the > > > > bus over to the RAM on the other side. > > > > > > IMO even in command mode mode->clock should probably be the actual > > > dotclock used by the display. If there's another clock for the bus > > > speed/etc. it should be stored somewhere else. > > > > Good point. For the DSI panels we have the field hs_rate > > for the HS clock in struct mipi_dsi_device which is based > > on exactly this reasoning. And that is what I actually use for > > setting the HS clock. > > > > The problem is however that we in many cases have so > > substandard documentation of these panels that we have > > absolutely no idea about the dotclock. Maybe we should > > just set it to 0 in these cases? > > Don't you always have a TE interrupt or something like that > available? Could just measure it from that if no better > information is available? Yes and I did exactly that, so that is why this comment is in the driver: static const struct drm_display_mode sony_acx424akp_cmd_mode = { (...) /* * Some desired refresh rate, experiments at the maximum "pixel" * clock speed (HS clock 420 MHz) yields around 117Hz. */ .vrefresh = 60, I got a review comment at the time saying 117 Hz was weird. We didn't reach a proper conclusion on this: https://lore.kernel.org/dri-devel/CACRpkdYW3YNPSNMY3A44GQn8DqK-n9TLvr7uipF7LM_DHZ5=Lg@mail.gmail.com/ Thierry wasn't sure if 60Hz was good or not, so I just had to go with something. We could calculate the resulting pixel clock for ~117 Hz with this resolution and put that in the clock field but ... don't know what is the best? Yours, Linus Walleij _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2020-02-26 14:56 ` Re: Linus Walleij @ 2020-02-26 15:08 ` Ville Syrjälä 0 siblings, 0 replies; 1767+ messages in thread From: Ville Syrjälä @ 2020-02-26 15:08 UTC (permalink / raw) To: Linus Walleij Cc: Josh Wu, Bhuvanchandra DV, Neil Armstrong, Eric Anholt, nouveau, Guido Günther, Paul Kocialkowski, open list:DRM PANEL DRIVERS, Gustaf Lindström, Andrzej Hajda, Thierry Reding, Laurent Pinchart, Philipp Zabel, Sam Ravnborg, Marian-Cristian Rotariu, Jagan Teki, Thomas Hellstrom, Joonyoung Shim, Jonathan Marek, Stefan Mavrodiev, Adam Ford, Jerry Han, VMware Graphics, Ben Skeggs, H. Nikolaus Schaller, Robert Chiras, Heiko Schocher, Icenowy Zheng, Jonas Karlman, intel-gfx, Maxime Ripard, Alexandre Courbot, Fabio Estevam, open list:ARM/Amlogic Meson..., Vincent Abriou, Andreas Pretzsch, Jernej Skrabec, Alex Gonzalez, Purism Kernel Team, Boris Brezillon, Seung-Woo Kim, Christoph Fritz, Kyungmin Park, Heiko Stuebner, Eugen Hristev, Giulio Benetti On Wed, Feb 26, 2020 at 03:56:36PM +0100, Linus Walleij wrote: > On Wed, Feb 26, 2020 at 3:34 PM Ville Syrjälä > <ville.syrjala@linux.intel.com> wrote: > > On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote: > > > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä > > > <ville.syrjala@linux.intel.com> wrote: > > > > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > > > > > > > > I have long suspected that a whole bunch of the "simple" displays > > > > > are not simple but contains a display controller and memory. > > > > > That means that the speed over the link to the display and > > > > > actual refresh rate on the actual display is asymmetric because > > > > > well we are just updating a RAM, the resolution just limits how > > > > > much data we are sending, the clock limits the speed on the > > > > > bus over to the RAM on the other side. > > > > > > > > IMO even in command mode mode->clock should probably be the actual > > > > dotclock used by the display. If there's another clock for the bus > > > > speed/etc. it should be stored somewhere else. > > > > > > Good point. For the DSI panels we have the field hs_rate > > > for the HS clock in struct mipi_dsi_device which is based > > > on exactly this reasoning. And that is what I actually use for > > > setting the HS clock. > > > > > > The problem is however that we in many cases have so > > > substandard documentation of these panels that we have > > > absolutely no idea about the dotclock. Maybe we should > > > just set it to 0 in these cases? > > > > Don't you always have a TE interrupt or something like that > > available? Could just measure it from that if no better > > information is available? > > Yes and I did exactly that, so that is why this comment is in > the driver: > > static const struct drm_display_mode sony_acx424akp_cmd_mode = { > (...) > /* > * Some desired refresh rate, experiments at the maximum "pixel" > * clock speed (HS clock 420 MHz) yields around 117Hz. > */ > .vrefresh = 60, > > I got a review comment at the time saying 117 Hz was weird. > We didn't reach a proper conclusion on this: > https://lore.kernel.org/dri-devel/CACRpkdYW3YNPSNMY3A44GQn8DqK-n9TLvr7uipF7LM_DHZ5=Lg@mail.gmail.com/ > > Thierry wasn't sure if 60Hz was good or not, so I just had to > go with something. > > We could calculate the resulting pixel clock for ~117 Hz with > this resolution and put that in the clock field but ... don't know > what is the best? I would vote for that approach. -- Ville Syrjälä Intel _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <20200224173733.16323-1-axboe@kernel.dk>]
* Re: [not found] <20200224173733.16323-1-axboe@kernel.dk> @ 2020-02-24 17:38 ` Jens Axboe 0 siblings, 0 replies; 1767+ messages in thread From: Jens Axboe @ 2020-02-24 17:38 UTC (permalink / raw) To: io-uring On 2/24/20 10:37 AM, Jens Axboe wrote: > Here's v3 of the poll async retry patchset. Changes since v2: > > - Rebase on for-5.7/io_uring > - Get rid of REQ_F_WORK bit > - Improve the tracing additions > - Fix linked_timeout case > - Fully restore work from async task handler > - Credentials now fixed > - Fix task_works running from SQPOLL > - Remove task cancellation stuff, we don't need it > - fdinfo print improvements > > I think this is getting pretty close to mergeable, I haven't found > any issues with the test cases. Gah, wrong directory, resending it. Ignore this thread. -- Jens Axboe ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (unknown)
@ 2020-02-11 22:34 Rajat Jain
[not found] ` <20200211223400.107604-1-rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 1767+ messages in thread
From: Rajat Jain @ 2020-02-11 22:34 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Mark Brown,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Evan Green, rajatja-hpIqsD4AKlfQT0dZR+AlfA,
rajatxjain-Re5JQEeQqe8AvxtiuMwx3w, evgreen-hpIqsD4AKlfQT0dZR+AlfA,
shobhit.srivastava-ral2JQCrhuEAvxtiuMwx3w,
porselvan.muthukrishnan-ral2JQCrhuEAvxtiuMwx3w
From: Evan Green <evgreen-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Date: Wed, 29 Jan 2020 13:54:16 -0800
Subject: [PATCH] spi: pxa2xx: Add CS control clock quirk
In some circumstances on Intel LPSS controllers, toggling the LPSS
CS control register doesn't actually cause the CS line to toggle.
This seems to be failure of dynamic clock gating that occurs after
going through a suspend/resume transition, where the controller
is sent through a reset transition. This ruins SPI transactions
that either rely on delay_usecs, or toggle the CS line without
sending data.
Whenever CS is toggled, momentarily set the clock gating register
to "Force On" to poke the controller into acting on CS.
Signed-off-by: Evan Green <evgreen-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Rajat Jain <rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
---
drivers/spi/spi-pxa2xx.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 4c7a71f0fb3e..2e318158fca9 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -70,6 +70,10 @@ MODULE_ALIAS("platform:pxa2xx-spi");
#define LPSS_CAPS_CS_EN_SHIFT 9
#define LPSS_CAPS_CS_EN_MASK (0xf << LPSS_CAPS_CS_EN_SHIFT)
+#define LPSS_PRIV_CLOCK_GATE 0x38
+#define LPSS_PRIV_CLOCK_GATE_CLK_CTL_MASK 0x3
+#define LPSS_PRIV_CLOCK_GATE_CLK_CTL_FORCE_ON 0x3
+
struct lpss_config {
/* LPSS offset from drv_data->ioaddr */
unsigned offset;
@@ -86,6 +90,8 @@ struct lpss_config {
unsigned cs_sel_shift;
unsigned cs_sel_mask;
unsigned cs_num;
+ /* Quirks */
+ unsigned cs_clk_stays_gated : 1;
};
/* Keep these sorted with enum pxa_ssp_type */
@@ -156,6 +162,7 @@ static const struct lpss_config lpss_platforms[] = {
.tx_threshold_hi = 56,
.cs_sel_shift = 8,
.cs_sel_mask = 3 << 8,
+ .cs_clk_stays_gated = true,
},
};
@@ -383,6 +390,22 @@ static void lpss_ssp_cs_control(struct spi_device *spi, bool enable)
else
value |= LPSS_CS_CONTROL_CS_HIGH;
__lpss_ssp_write_priv(drv_data, config->reg_cs_ctrl, value);
+ if (config->cs_clk_stays_gated) {
+ u32 clkgate;
+
+ /*
+ * Changing CS alone when dynamic clock gating is on won't
+ * actually flip CS at that time. This ruins SPI transfers
+ * that specify delays, or have no data. Toggle the clock mode
+ * to force on briefly to poke the CS pin to move.
+ */
+ clkgate = __lpss_ssp_read_priv(drv_data, LPSS_PRIV_CLOCK_GATE);
+ value = (clkgate & ~LPSS_PRIV_CLOCK_GATE_CLK_CTL_MASK) |
+ LPSS_PRIV_CLOCK_GATE_CLK_CTL_FORCE_ON;
+
+ __lpss_ssp_write_priv(drv_data, LPSS_PRIV_CLOCK_GATE, value);
+ __lpss_ssp_write_priv(drv_data, LPSS_PRIV_CLOCK_GATE, clkgate);
+ }
}
static void cs_assert(struct spi_device *spi)
--
2.25.0.225.g125e21ebc7-goog
^ permalink raw reply related [flat|nested] 1767+ messages in thread[parent not found: <20200211223400.107604-1-rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>]
* Re: 2020-02-11 22:34 (unknown) Rajat Jain @ 2020-02-12 9:30 ` Jarkko Nikula 0 siblings, 0 replies; 1767+ messages in thread From: Jarkko Nikula @ 2020-02-12 9:30 UTC (permalink / raw) To: Rajat Jain, Daniel Mack, Haojian Zhuang, Robert Jarzmik, Mark Brown, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-spi-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA Cc: Evan Green, rajatxjain-Re5JQEeQqe8AvxtiuMwx3w, evgreen-hpIqsD4AKlfQT0dZR+AlfA, shobhit.srivastava-ral2JQCrhuEAvxtiuMwx3w, porselvan.muthukrishnan-ral2JQCrhuEAvxtiuMwx3w, Andy Shevchenko Hi + Andy On 2/12/20 12:34 AM, Rajat Jain wrote: > From: Evan Green <evgreen-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> > > Date: Wed, 29 Jan 2020 13:54:16 -0800 > Subject: [PATCH] spi: pxa2xx: Add CS control clock quirk > This patch subject is missing from mail subject. > In some circumstances on Intel LPSS controllers, toggling the LPSS > CS control register doesn't actually cause the CS line to toggle. > This seems to be failure of dynamic clock gating that occurs after > going through a suspend/resume transition, where the controller > is sent through a reset transition. This ruins SPI transactions > that either rely on delay_usecs, or toggle the CS line without > sending data. > > Whenever CS is toggled, momentarily set the clock gating register > to "Force On" to poke the controller into acting on CS. > Could you share the test case how to trigger this? What's the platform here? I'd like to check does this reproduce on other Intel LPSS platforms so is there need to add quirk for them too. > Signed-off-by: Evan Green <evgreen-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> > Signed-off-by: Rajat Jain <rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> > --- > drivers/spi/spi-pxa2xx.c | 23 +++++++++++++++++++++++ > 1 file changed, 23 insertions(+) > > diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c > index 4c7a71f0fb3e..2e318158fca9 100644 > --- a/drivers/spi/spi-pxa2xx.c > +++ b/drivers/spi/spi-pxa2xx.c > @@ -70,6 +70,10 @@ MODULE_ALIAS("platform:pxa2xx-spi"); > #define LPSS_CAPS_CS_EN_SHIFT 9 > #define LPSS_CAPS_CS_EN_MASK (0xf << LPSS_CAPS_CS_EN_SHIFT) > > +#define LPSS_PRIV_CLOCK_GATE 0x38 > +#define LPSS_PRIV_CLOCK_GATE_CLK_CTL_MASK 0x3 > +#define LPSS_PRIV_CLOCK_GATE_CLK_CTL_FORCE_ON 0x3 > + > struct lpss_config { > /* LPSS offset from drv_data->ioaddr */ > unsigned offset; > @@ -86,6 +90,8 @@ struct lpss_config { > unsigned cs_sel_shift; > unsigned cs_sel_mask; > unsigned cs_num; > + /* Quirks */ > + unsigned cs_clk_stays_gated : 1; > }; > > /* Keep these sorted with enum pxa_ssp_type */ > @@ -156,6 +162,7 @@ static const struct lpss_config lpss_platforms[] = { > .tx_threshold_hi = 56, > .cs_sel_shift = 8, > .cs_sel_mask = 3 << 8, > + .cs_clk_stays_gated = true, > }, > }; > > @@ -383,6 +390,22 @@ static void lpss_ssp_cs_control(struct spi_device *spi, bool enable) > else > value |= LPSS_CS_CONTROL_CS_HIGH; > __lpss_ssp_write_priv(drv_data, config->reg_cs_ctrl, value); > + if (config->cs_clk_stays_gated) { > + u32 clkgate; > + > + /* > + * Changing CS alone when dynamic clock gating is on won't > + * actually flip CS at that time. This ruins SPI transfers > + * that specify delays, or have no data. Toggle the clock mode > + * to force on briefly to poke the CS pin to move. > + */ > + clkgate = __lpss_ssp_read_priv(drv_data, LPSS_PRIV_CLOCK_GATE); > + value = (clkgate & ~LPSS_PRIV_CLOCK_GATE_CLK_CTL_MASK) | > + LPSS_PRIV_CLOCK_GATE_CLK_CTL_FORCE_ON; > + > + __lpss_ssp_write_priv(drv_data, LPSS_PRIV_CLOCK_GATE, value); > + __lpss_ssp_write_priv(drv_data, LPSS_PRIV_CLOCK_GATE, clkgate); > + } > } > I wonder is it enough to have this quick toggling only or is time or actually number of clock cycles dependent? Now there is no delay between but I'm thinking if it needs certain number cycles does this still work when using low ssp_clk rates similar than in commit d0283eb2dbc1 ("spi: pxa2xx: Add output control for multiple Intel LPSS chip selects"). I'm thinking can this be done only once after resume and may other LPSS blocks need the same? I.e. should this be done in drivers/mfd/intel-lpss.c? Jarkko ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2020-02-12 9:30 ` Jarkko Nikula 0 siblings, 0 replies; 1767+ messages in thread From: Jarkko Nikula @ 2020-02-12 9:30 UTC (permalink / raw) To: Rajat Jain, Daniel Mack, Haojian Zhuang, Robert Jarzmik, Mark Brown, linux-arm-kernel, linux-spi, linux-kernel Cc: rajatxjain, shobhit.srivastava, Evan Green, evgreen, porselvan.muthukrishnan, Andy Shevchenko Hi + Andy On 2/12/20 12:34 AM, Rajat Jain wrote: > From: Evan Green <evgreen@chromium.org> > > Date: Wed, 29 Jan 2020 13:54:16 -0800 > Subject: [PATCH] spi: pxa2xx: Add CS control clock quirk > This patch subject is missing from mail subject. > In some circumstances on Intel LPSS controllers, toggling the LPSS > CS control register doesn't actually cause the CS line to toggle. > This seems to be failure of dynamic clock gating that occurs after > going through a suspend/resume transition, where the controller > is sent through a reset transition. This ruins SPI transactions > that either rely on delay_usecs, or toggle the CS line without > sending data. > > Whenever CS is toggled, momentarily set the clock gating register > to "Force On" to poke the controller into acting on CS. > Could you share the test case how to trigger this? What's the platform here? I'd like to check does this reproduce on other Intel LPSS platforms so is there need to add quirk for them too. > Signed-off-by: Evan Green <evgreen@chromium.org> > Signed-off-by: Rajat Jain <rajatja@google.com> > --- > drivers/spi/spi-pxa2xx.c | 23 +++++++++++++++++++++++ > 1 file changed, 23 insertions(+) > > diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c > index 4c7a71f0fb3e..2e318158fca9 100644 > --- a/drivers/spi/spi-pxa2xx.c > +++ b/drivers/spi/spi-pxa2xx.c > @@ -70,6 +70,10 @@ MODULE_ALIAS("platform:pxa2xx-spi"); > #define LPSS_CAPS_CS_EN_SHIFT 9 > #define LPSS_CAPS_CS_EN_MASK (0xf << LPSS_CAPS_CS_EN_SHIFT) > > +#define LPSS_PRIV_CLOCK_GATE 0x38 > +#define LPSS_PRIV_CLOCK_GATE_CLK_CTL_MASK 0x3 > +#define LPSS_PRIV_CLOCK_GATE_CLK_CTL_FORCE_ON 0x3 > + > struct lpss_config { > /* LPSS offset from drv_data->ioaddr */ > unsigned offset; > @@ -86,6 +90,8 @@ struct lpss_config { > unsigned cs_sel_shift; > unsigned cs_sel_mask; > unsigned cs_num; > + /* Quirks */ > + unsigned cs_clk_stays_gated : 1; > }; > > /* Keep these sorted with enum pxa_ssp_type */ > @@ -156,6 +162,7 @@ static const struct lpss_config lpss_platforms[] = { > .tx_threshold_hi = 56, > .cs_sel_shift = 8, > .cs_sel_mask = 3 << 8, > + .cs_clk_stays_gated = true, > }, > }; > > @@ -383,6 +390,22 @@ static void lpss_ssp_cs_control(struct spi_device *spi, bool enable) > else > value |= LPSS_CS_CONTROL_CS_HIGH; > __lpss_ssp_write_priv(drv_data, config->reg_cs_ctrl, value); > + if (config->cs_clk_stays_gated) { > + u32 clkgate; > + > + /* > + * Changing CS alone when dynamic clock gating is on won't > + * actually flip CS at that time. This ruins SPI transfers > + * that specify delays, or have no data. Toggle the clock mode > + * to force on briefly to poke the CS pin to move. > + */ > + clkgate = __lpss_ssp_read_priv(drv_data, LPSS_PRIV_CLOCK_GATE); > + value = (clkgate & ~LPSS_PRIV_CLOCK_GATE_CLK_CTL_MASK) | > + LPSS_PRIV_CLOCK_GATE_CLK_CTL_FORCE_ON; > + > + __lpss_ssp_write_priv(drv_data, LPSS_PRIV_CLOCK_GATE, value); > + __lpss_ssp_write_priv(drv_data, LPSS_PRIV_CLOCK_GATE, clkgate); > + } > } > I wonder is it enough to have this quick toggling only or is time or actually number of clock cycles dependent? Now there is no delay between but I'm thinking if it needs certain number cycles does this still work when using low ssp_clk rates similar than in commit d0283eb2dbc1 ("spi: pxa2xx: Add output control for multiple Intel LPSS chip selects"). I'm thinking can this be done only once after resume and may other LPSS blocks need the same? I.e. should this be done in drivers/mfd/intel-lpss.c? Jarkko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <b3397374-0cb8-cf6c-0555-34541a1c108c-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>]
* Re: 2020-02-12 9:30 ` Re: Jarkko Nikula @ 2020-02-12 10:24 ` Andy Shevchenko -1 siblings, 0 replies; 1767+ messages in thread From: Andy Shevchenko @ 2020-02-12 10:24 UTC (permalink / raw) To: Jarkko Nikula Cc: Rajat Jain, Daniel Mack, Haojian Zhuang, Robert Jarzmik, Mark Brown, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-spi-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Evan Green, rajatxjain-Re5JQEeQqe8AvxtiuMwx3w, evgreen-hpIqsD4AKlfQT0dZR+AlfA, shobhit.srivastava-ral2JQCrhuEAvxtiuMwx3w, porselvan.muthukrishnan-ral2JQCrhuEAvxtiuMwx3w On Wed, Feb 12, 2020 at 11:30:51AM +0200, Jarkko Nikula wrote: > On 2/12/20 12:34 AM, Rajat Jain wrote: > This patch subject is missing from mail subject. > I'm thinking can this be done only once after resume and may other LPSS > blocks need the same? I.e. should this be done in drivers/mfd/intel-lpss.c? On resume we restore the previously saved context, can we be sure that values we saved during suspend are correct? If above won't show any issue, it might be best place to have this quirk applied in intel_lpss_suspend() / intel_lpss_resume() callbacks as Jarkko suggested. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2020-02-12 10:24 ` Andy Shevchenko 0 siblings, 0 replies; 1767+ messages in thread From: Andy Shevchenko @ 2020-02-12 10:24 UTC (permalink / raw) To: Jarkko Nikula Cc: Evan Green, rajatxjain, shobhit.srivastava, linux-kernel, Haojian Zhuang, linux-spi, Mark Brown, evgreen, Daniel Mack, Rajat Jain, Robert Jarzmik, linux-arm-kernel, porselvan.muthukrishnan On Wed, Feb 12, 2020 at 11:30:51AM +0200, Jarkko Nikula wrote: > On 2/12/20 12:34 AM, Rajat Jain wrote: > This patch subject is missing from mail subject. > I'm thinking can this be done only once after resume and may other LPSS > blocks need the same? I.e. should this be done in drivers/mfd/intel-lpss.c? On resume we restore the previously saved context, can we be sure that values we saved during suspend are correct? If above won't show any issue, it might be best place to have this quirk applied in intel_lpss_suspend() / intel_lpss_resume() callbacks as Jarkko suggested. -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2020-02-06 6:36 Viviane Jose Pereira 0 siblings, 0 replies; 1767+ messages in thread From: Viviane Jose Pereira @ 2020-02-06 6:36 UTC (permalink / raw) -- Hallo, ich entschuldige mich dafür, dass ich deine Privatsphäre gestört habe. Ich kontaktiere Sie für eine äußerst dringende und vertrauliche Angelegenheit. Ihnen wurde eine Spende von 15.000.000,00 EUR angeboten Kontakt: cristtom063@gmail.com für weitere Informationen. Dies ist keine Spam-Nachricht, sondern eine wichtige Mitteilung an Sie. Antworten Sie auf die obige E-Mail, um immer mehr Informationen über die Spende und den Erhalt von Geldern zu erhalten. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2020-02-06 2:24 Viviane Jose Pereira 0 siblings, 0 replies; 1767+ messages in thread From: Viviane Jose Pereira @ 2020-02-06 2:24 UTC (permalink / raw) -- Hallo, ich entschuldige mich dafür, dass ich deine Privatsphäre gestört habe. Ich kontaktiere Sie für eine äußerst dringende und vertrauliche Angelegenheit. Ihnen wurde eine Spende von 15.000.000,00 EUR angeboten Kontakt: cristtom063@gmail.com für weitere Informationen. Dies ist keine Spam-Nachricht, sondern eine wichtige Mitteilung an Sie. Antworten Sie auf die obige E-Mail, um immer mehr Informationen über die Spende und den Erhalt von Geldern zu erhalten. ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <mailman.6.1579205674.8101.b.a.t.m.a.n@lists.open-mesh.org>]
* Re: [not found] <mailman.6.1579205674.8101.b.a.t.m.a.n@lists.open-mesh.org> @ 2020-01-17 7:44 ` Simon Wunderlich 0 siblings, 0 replies; 1767+ messages in thread From: Simon Wunderlich @ 2020-01-17 7:44 UTC (permalink / raw) To: b.a.t.m.a.n; +Cc: Martin, Jeremy J CIV USARMY CCDC C5ISR (USA) [-- Attachment #1: Type: text/plain, Size: 1424 bytes --] Hi Jeremy, On Thursday, January 16, 2020 9:06:50 PM CET Martin, Jeremy J CIV USARMY CCDC C5ISR (USA) via B.A.T.M.A.N wrote: > My/My Teams intent is to have 4 radios in total, 2 on one pc and two on > another. Our plan is to have Batman take care of the switching between > which radio to use in order to transmit data between these two PC's. One > radio is high frequency radio (60 Ghz) and the other would be a lower > frequency radio and the idea is to have batman switch between these radios > once the higher frequency radio is dropping between a certain TQ. BATMAN will switch by default when one link has a better TQ (towards the final destination) than the other link, so I believe this should happen by default. > My > primary questions regarding this scenario would be, 1) Are there specific > standards the radio chipsets would need to support in order for them to > work in this scenario?. Normally you would want IBSS mode or 802.11s mode work. BATMAN can also work in AP/Sta mode, although the packet loss counting may be biased since broadcast handling works a bit different than in IBSS/11s. But for point-to- point links it might just work. > 2) Would Batman-adv be adequate enough to be able > to handle a 1Gb/s data transmission and be able to swap accordingly to the > lower frequency radio? If your radio and CPU are powerful enough, batman-adv is able to handle it, yes. Cheers, Simon [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [alsa-devel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples
@ 2019-12-20 17:06 Ben Dooks
2019-12-22 17:08 ` Dmitry Osipenko
0 siblings, 1 reply; 1767+ messages in thread
From: Ben Dooks @ 2019-12-20 17:06 UTC (permalink / raw)
To: Dmitry Osipenko, Jon Hunter, linux-tegra, alsa-devel,
Jaroslav Kysela, Takashi Iwai, Liam Girdwood, Mark Brown,
Thierry Reding
Cc: linux-kernel, Edward Cragg
On 20/12/2019 16:40, Dmitry Osipenko wrote:
> 20.12.2019 18:25, Ben Dooks пишет:
>> On 20/12/2019 15:02, Dmitry Osipenko wrote:
>>> 20.12.2019 17:56, Ben Dooks пишет:
>>>> On 20/12/2019 14:43, Dmitry Osipenko wrote:
>>>>> 20.12.2019 16:57, Jon Hunter пишет:
>>>>>>
>>>>>> On 20/12/2019 11:38, Ben Dooks wrote:
>>>>>>> On 20/12/2019 11:30, Jon Hunter wrote:
>>>>>>>>
>>>>>>>> On 25/11/2019 17:28, Dmitry Osipenko wrote:
>>>>>>>>> 25.11.2019 20:22, Dmitry Osipenko пишет:
>>>>>>>>>> 25.11.2019 13:37, Ben Dooks пишет:
>>>>>>>>>>> On 23/11/2019 21:09, Dmitry Osipenko wrote:
>>>>>>>>>>>> 18.10.2019 18:48, Ben Dooks пишет:
>>>>>>>>>>>>> From: Edward Cragg <edward.cragg@codethink.co.uk>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The tegra3 audio can support 24 and 32 bit sample sizes so add
>>>>>>>>>>>>> the
>>>>>>>>>>>>> option to the tegra30_i2s_hw_params to configure the S24_LE or
>>>>>>>>>>>>> S32_LE
>>>>>>>>>>>>> formats when requested.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Edward Cragg <edward.cragg@codethink.co.uk>
>>>>>>>>>>>>> [ben.dooks@codethink.co.uk: fixup merge of 24 and 32bit]
>>>>>>>>>>>>> [ben.dooks@codethink.co.uk: add pm calls around ytdm config]
>>>>>>>>>>>>> [ben.dooks@codethink.co.uk: drop debug printing to dev_dbg]
>>>>>>>>>>>>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> squash 5aeca5a055fd ASoC: tegra: i2s: pm_runtime_get_sync() is
>>>>>>>>>>>>> needed
>>>>>>>>>>>>> in tdm code
>>>>>>>>>>>>>
>>>>>>>>>>>>> ASoC: tegra: i2s: pm_runtime_get_sync() is needed in tdm code
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> sound/soc/tegra/tegra30_i2s.c | 25
>>>>>>>>>>>>> ++++++++++++++++++++-----
>>>>>>>>>>>>> 1 file changed, 20 insertions(+), 5 deletions(-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/sound/soc/tegra/tegra30_i2s.c
>>>>>>>>>>>>> b/sound/soc/tegra/tegra30_i2s.c
>>>>>>>>>>>>> index 73f0dddeaef3..063f34c882af 100644
>>>>>>>>>>>>> --- a/sound/soc/tegra/tegra30_i2s.c
>>>>>>>>>>>>> +++ b/sound/soc/tegra/tegra30_i2s.c
>>>>>>>>>>>>> @@ -127,7 +127,7 @@ static int tegra30_i2s_hw_params(struct
>>>>>>>>>>>>> snd_pcm_substream *substream,
>>>>>>>>>>>>> struct device *dev = dai->dev;
>>>>>>>>>>>>> struct tegra30_i2s *i2s =
>>>>>>>>>>>>> snd_soc_dai_get_drvdata(dai);
>>>>>>>>>>>>> unsigned int mask, val, reg;
>>>>>>>>>>>>> - int ret, sample_size, srate, i2sclock, bitcnt;
>>>>>>>>>>>>> + int ret, sample_size, srate, i2sclock, bitcnt, audio_bits;
>>>>>>>>>>>>> struct tegra30_ahub_cif_conf cif_conf;
>>>>>>>>>>>>> if (params_channels(params) != 2)
>>>>>>>>>>>>> @@ -137,8 +137,19 @@ static int tegra30_i2s_hw_params(struct
>>>>>>>>>>>>> snd_pcm_substream *substream,
>>>>>>>>>>>>> switch (params_format(params)) {
>>>>>>>>>>>>> case SNDRV_PCM_FORMAT_S16_LE:
>>>>>>>>>>>>> val = TEGRA30_I2S_CTRL_BIT_SIZE_16;
>>>>>>>>>>>>> + audio_bits = TEGRA30_AUDIOCIF_BITS_16;
>>>>>>>>>>>>> sample_size = 16;
>>>>>>>>>>>>> break;
>>>>>>>>>>>>> + case SNDRV_PCM_FORMAT_S24_LE:
>>>>>>>>>>>>> + val = TEGRA30_I2S_CTRL_BIT_SIZE_24;
>>>>>>>>>>>>> + audio_bits = TEGRA30_AUDIOCIF_BITS_24;
>>>>>>>>>>>>> + sample_size = 24;
>>>>>>>>>>>>> + break;
>>>>>>>>>>>>> + case SNDRV_PCM_FORMAT_S32_LE:
>>>>>>>>>>>>> + val = TEGRA30_I2S_CTRL_BIT_SIZE_32;
>>>>>>>>>>>>> + audio_bits = TEGRA30_AUDIOCIF_BITS_32;
>>>>>>>>>>>>> + sample_size = 32;
>>>>>>>>>>>>> + break;
>>>>>>>>>>>>> default:
>>>>>>>>>>>>> return -EINVAL;
>>>>>>>>>>>>> }
>>>>>>>>>>>>> @@ -170,8 +181,8 @@ static int tegra30_i2s_hw_params(struct
>>>>>>>>>>>>> snd_pcm_substream *substream,
>>>>>>>>>>>>> cif_conf.threshold = 0;
>>>>>>>>>>>>> cif_conf.audio_channels = 2;
>>>>>>>>>>>>> cif_conf.client_channels = 2;
>>>>>>>>>>>>> - cif_conf.audio_bits = TEGRA30_AUDIOCIF_BITS_16;
>>>>>>>>>>>>> - cif_conf.client_bits = TEGRA30_AUDIOCIF_BITS_16;
>>>>>>>>>>>>> + cif_conf.audio_bits = audio_bits;
>>>>>>>>>>>>> + cif_conf.client_bits = audio_bits;
>>>>>>>>>>>>> cif_conf.expand = 0;
>>>>>>>>>>>>> cif_conf.stereo_conv = 0;
>>>>>>>>>>>>> cif_conf.replicate = 0;
>>>>>>>>>>>>> @@ -306,14 +317,18 @@ static const struct snd_soc_dai_driver
>>>>>>>>>>>>> tegra30_i2s_dai_template = {
>>>>>>>>>>>>> .channels_min = 2,
>>>>>>>>>>>>> .channels_max = 2,
>>>>>>>>>>>>> .rates = SNDRV_PCM_RATE_8000_96000,
>>>>>>>>>>>>> - .formats = SNDRV_PCM_FMTBIT_S16_LE,
>>>>>>>>>>>>> + .formats = SNDRV_PCM_FMTBIT_S32_LE |
>>>>>>>>>>>>> + SNDRV_PCM_FMTBIT_S24_LE |
>>>>>>>>>>>>> + SNDRV_PCM_FMTBIT_S16_LE,
>>>>>>>>>>>>> },
>>>>>>>>>>>>> .capture = {
>>>>>>>>>>>>> .stream_name = "Capture",
>>>>>>>>>>>>> .channels_min = 2,
>>>>>>>>>>>>> .channels_max = 2,
>>>>>>>>>>>>> .rates = SNDRV_PCM_RATE_8000_96000,
>>>>>>>>>>>>> - .formats = SNDRV_PCM_FMTBIT_S16_LE,
>>>>>>>>>>>>> + .formats = SNDRV_PCM_FMTBIT_S32_LE |
>>>>>>>>>>>>> + SNDRV_PCM_FMTBIT_S24_LE |
>>>>>>>>>>>>> + SNDRV_PCM_FMTBIT_S16_LE,
>>>>>>>>>>>>> },
>>>>>>>>>>>>> .ops = &tegra30_i2s_dai_ops,
>>>>>>>>>>>>> .symmetric_rates = 1,
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> This patch breaks audio on Tegra30. I don't see errors
>>>>>>>>>>>> anywhere, but
>>>>>>>>>>>> there is no audio and reverting this patch helps. Please fix it.
>>>>>>>>>>>
>>>>>>>>>>> What is the failure mode? I can try and take a look at this some
>>>>>>>>>>> time
>>>>>>>>>>> this week, but I am not sure if I have any boards with an actual
>>>>>>>>>>> useful
>>>>>>>>>>> audio output?
>>>>>>>>>>
>>>>>>>>>> The failure mode is that there no sound. I also noticed that video
>>>>>>>>>> playback stutters a lot if movie file has audio track, seems
>>>>>>>>>> something
>>>>>>>>>> times out during of the audio playback. For now I don't have any
>>>>>>>>>> more info.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Oh, I didn't say how to reproduce it.. for example simply playing
>>>>>>>>> big_buck_bunny_720p_h264.mov in MPV has the audio problem.
>>>>>>>>>
>>>>>>>>> https://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_720p_h264.mov
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Given that the audio drivers uses regmap, it could be good to
>>>>>>>> dump the
>>>>>>>> I2S/AHUB registers while the clip if playing with and without this
>>>>>>>> patch
>>>>>>>> to see the differences. I am curious if the audio is now being
>>>>>>>> played as
>>>>>>>> 24 or 32-bit instead of 16-bit now these are available.
>>>>>>>>
>>>>>>>> You could also dump the hw_params to see the format while playing as
>>>>>>>> well ...
>>>>>>>>
>>>>>>>> $ /proc/asound/<scard-name>/pcm0p/sub0/hw_params
>>>>>>>
>>>>>>> I suppose it is also possible that the codec isn't properly doing >16
>>>>>>> bits and the fact we now offer 24 and 32 could be an issue. I've not
>>>>>>> got anything with an audio output on it that would be easy to test.
>>>>>>
>>>>>> I thought I had tested on a Jetson TK1 (Tegra124) but it was sometime
>>>>>> back. However, admittedly I may have only done simple 16-bit testing
>>>>>> with speaker-test.
>>>>>>
>>>>>> We do verify that all soundcards are detected and registered as
>>>>>> expected
>>>>>> during daily testing, but at the moment we don't have anything that
>>>>>> verifies actual playback.
>>>>>
>>>>> Please take a look at the attached logs.
>>>>
>>>> I wonder if we are falling into FIFO configuration issues with the
>>>> non-16 bit case.
>>>>
>>>> Can you try adding the following two patches?
>>>
>>> It is much better now! There is no horrible noise and no stuttering, but
>>> audio still has a "robotic" effect, like freq isn't correct.
>>
>> I wonder if there's an issue with FIFO stoking? I should also possibly
>> add the correctly stop FIFOs patch as well.
>
> I'll be happy to try more patches.
>
> Meanwhile sound on v5.5+ is broken and thus the incomplete patches
> should be reverted.
Have you checked if just removing the 24/32 bits from .formats in
the dai template and see if the problem continues? I will try and
see if I can find the code that does the fifo level checking and
see if the problem is in the FIFO fill or something else in the
audio hub setup.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: [alsa-devel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples 2019-12-20 17:06 [alsa-devel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples Ben Dooks @ 2019-12-22 17:08 ` Dmitry Osipenko 2020-01-05 0:04 ` Ben Dooks 0 siblings, 1 reply; 1767+ messages in thread From: Dmitry Osipenko @ 2019-12-22 17:08 UTC (permalink / raw) To: Ben Dooks, Jon Hunter, linux-tegra, alsa-devel, Jaroslav Kysela, Takashi Iwai, Liam Girdwood, Mark Brown, Thierry Reding Cc: linux-kernel, Edward Cragg 20.12.2019 20:06, Ben Dooks пишет: > On 20/12/2019 16:40, Dmitry Osipenko wrote: >> 20.12.2019 18:25, Ben Dooks пишет: >>> On 20/12/2019 15:02, Dmitry Osipenko wrote: >>>> 20.12.2019 17:56, Ben Dooks пишет: >>>>> On 20/12/2019 14:43, Dmitry Osipenko wrote: >>>>>> 20.12.2019 16:57, Jon Hunter пишет: >>>>>>> >>>>>>> On 20/12/2019 11:38, Ben Dooks wrote: >>>>>>>> On 20/12/2019 11:30, Jon Hunter wrote: >>>>>>>>> >>>>>>>>> On 25/11/2019 17:28, Dmitry Osipenko wrote: >>>>>>>>>> 25.11.2019 20:22, Dmitry Osipenko пишет: >>>>>>>>>>> 25.11.2019 13:37, Ben Dooks пишет: >>>>>>>>>>>> On 23/11/2019 21:09, Dmitry Osipenko wrote: >>>>>>>>>>>>> 18.10.2019 18:48, Ben Dooks пишет: >>>>>>>>>>>>>> From: Edward Cragg <edward.cragg@codethink.co.uk> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The tegra3 audio can support 24 and 32 bit sample sizes so >>>>>>>>>>>>>> add >>>>>>>>>>>>>> the >>>>>>>>>>>>>> option to the tegra30_i2s_hw_params to configure the >>>>>>>>>>>>>> S24_LE or >>>>>>>>>>>>>> S32_LE >>>>>>>>>>>>>> formats when requested. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Signed-off-by: Edward Cragg <edward.cragg@codethink.co.uk> >>>>>>>>>>>>>> [ben.dooks@codethink.co.uk: fixup merge of 24 and 32bit] >>>>>>>>>>>>>> [ben.dooks@codethink.co.uk: add pm calls around ytdm config] >>>>>>>>>>>>>> [ben.dooks@codethink.co.uk: drop debug printing to dev_dbg] >>>>>>>>>>>>>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> squash 5aeca5a055fd ASoC: tegra: i2s: >>>>>>>>>>>>>> pm_runtime_get_sync() is >>>>>>>>>>>>>> needed >>>>>>>>>>>>>> in tdm code >>>>>>>>>>>>>> >>>>>>>>>>>>>> ASoC: tegra: i2s: pm_runtime_get_sync() is needed in tdm code >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> sound/soc/tegra/tegra30_i2s.c | 25 >>>>>>>>>>>>>> ++++++++++++++++++++----- >>>>>>>>>>>>>> 1 file changed, 20 insertions(+), 5 deletions(-) >>>>>>>>>>>>>> >>>>>>>>>>>>>> diff --git a/sound/soc/tegra/tegra30_i2s.c >>>>>>>>>>>>>> b/sound/soc/tegra/tegra30_i2s.c >>>>>>>>>>>>>> index 73f0dddeaef3..063f34c882af 100644 >>>>>>>>>>>>>> --- a/sound/soc/tegra/tegra30_i2s.c >>>>>>>>>>>>>> +++ b/sound/soc/tegra/tegra30_i2s.c >>>>>>>>>>>>>> @@ -127,7 +127,7 @@ static int tegra30_i2s_hw_params(struct >>>>>>>>>>>>>> snd_pcm_substream *substream, >>>>>>>>>>>>>> struct device *dev = dai->dev; >>>>>>>>>>>>>> struct tegra30_i2s *i2s = >>>>>>>>>>>>>> snd_soc_dai_get_drvdata(dai); >>>>>>>>>>>>>> unsigned int mask, val, reg; >>>>>>>>>>>>>> - int ret, sample_size, srate, i2sclock, bitcnt; >>>>>>>>>>>>>> + int ret, sample_size, srate, i2sclock, bitcnt, >>>>>>>>>>>>>> audio_bits; >>>>>>>>>>>>>> struct tegra30_ahub_cif_conf cif_conf; >>>>>>>>>>>>>> if (params_channels(params) != 2) >>>>>>>>>>>>>> @@ -137,8 +137,19 @@ static int tegra30_i2s_hw_params(struct >>>>>>>>>>>>>> snd_pcm_substream *substream, >>>>>>>>>>>>>> switch (params_format(params)) { >>>>>>>>>>>>>> case SNDRV_PCM_FORMAT_S16_LE: >>>>>>>>>>>>>> val = TEGRA30_I2S_CTRL_BIT_SIZE_16; >>>>>>>>>>>>>> + audio_bits = TEGRA30_AUDIOCIF_BITS_16; >>>>>>>>>>>>>> sample_size = 16; >>>>>>>>>>>>>> break; >>>>>>>>>>>>>> + case SNDRV_PCM_FORMAT_S24_LE: >>>>>>>>>>>>>> + val = TEGRA30_I2S_CTRL_BIT_SIZE_24; >>>>>>>>>>>>>> + audio_bits = TEGRA30_AUDIOCIF_BITS_24; >>>>>>>>>>>>>> + sample_size = 24; >>>>>>>>>>>>>> + break; >>>>>>>>>>>>>> + case SNDRV_PCM_FORMAT_S32_LE: >>>>>>>>>>>>>> + val = TEGRA30_I2S_CTRL_BIT_SIZE_32; >>>>>>>>>>>>>> + audio_bits = TEGRA30_AUDIOCIF_BITS_32; >>>>>>>>>>>>>> + sample_size = 32; >>>>>>>>>>>>>> + break; >>>>>>>>>>>>>> default: >>>>>>>>>>>>>> return -EINVAL; >>>>>>>>>>>>>> } >>>>>>>>>>>>>> @@ -170,8 +181,8 @@ static int tegra30_i2s_hw_params(struct >>>>>>>>>>>>>> snd_pcm_substream *substream, >>>>>>>>>>>>>> cif_conf.threshold = 0; >>>>>>>>>>>>>> cif_conf.audio_channels = 2; >>>>>>>>>>>>>> cif_conf.client_channels = 2; >>>>>>>>>>>>>> - cif_conf.audio_bits = TEGRA30_AUDIOCIF_BITS_16; >>>>>>>>>>>>>> - cif_conf.client_bits = TEGRA30_AUDIOCIF_BITS_16; >>>>>>>>>>>>>> + cif_conf.audio_bits = audio_bits; >>>>>>>>>>>>>> + cif_conf.client_bits = audio_bits; >>>>>>>>>>>>>> cif_conf.expand = 0; >>>>>>>>>>>>>> cif_conf.stereo_conv = 0; >>>>>>>>>>>>>> cif_conf.replicate = 0; >>>>>>>>>>>>>> @@ -306,14 +317,18 @@ static const struct snd_soc_dai_driver >>>>>>>>>>>>>> tegra30_i2s_dai_template = { >>>>>>>>>>>>>> .channels_min = 2, >>>>>>>>>>>>>> .channels_max = 2, >>>>>>>>>>>>>> .rates = SNDRV_PCM_RATE_8000_96000, >>>>>>>>>>>>>> - .formats = SNDRV_PCM_FMTBIT_S16_LE, >>>>>>>>>>>>>> + .formats = SNDRV_PCM_FMTBIT_S32_LE | >>>>>>>>>>>>>> + SNDRV_PCM_FMTBIT_S24_LE | >>>>>>>>>>>>>> + SNDRV_PCM_FMTBIT_S16_LE, >>>>>>>>>>>>>> }, >>>>>>>>>>>>>> .capture = { >>>>>>>>>>>>>> .stream_name = "Capture", >>>>>>>>>>>>>> .channels_min = 2, >>>>>>>>>>>>>> .channels_max = 2, >>>>>>>>>>>>>> .rates = SNDRV_PCM_RATE_8000_96000, >>>>>>>>>>>>>> - .formats = SNDRV_PCM_FMTBIT_S16_LE, >>>>>>>>>>>>>> + .formats = SNDRV_PCM_FMTBIT_S32_LE | >>>>>>>>>>>>>> + SNDRV_PCM_FMTBIT_S24_LE | >>>>>>>>>>>>>> + SNDRV_PCM_FMTBIT_S16_LE, >>>>>>>>>>>>>> }, >>>>>>>>>>>>>> .ops = &tegra30_i2s_dai_ops, >>>>>>>>>>>>>> .symmetric_rates = 1, >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> This patch breaks audio on Tegra30. I don't see errors >>>>>>>>>>>>> anywhere, but >>>>>>>>>>>>> there is no audio and reverting this patch helps. Please >>>>>>>>>>>>> fix it. >>>>>>>>>>>> >>>>>>>>>>>> What is the failure mode? I can try and take a look at this >>>>>>>>>>>> some >>>>>>>>>>>> time >>>>>>>>>>>> this week, but I am not sure if I have any boards with an >>>>>>>>>>>> actual >>>>>>>>>>>> useful >>>>>>>>>>>> audio output? >>>>>>>>>>> >>>>>>>>>>> The failure mode is that there no sound. I also noticed that >>>>>>>>>>> video >>>>>>>>>>> playback stutters a lot if movie file has audio track, seems >>>>>>>>>>> something >>>>>>>>>>> times out during of the audio playback. For now I don't have any >>>>>>>>>>> more info. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Oh, I didn't say how to reproduce it.. for example simply playing >>>>>>>>>> big_buck_bunny_720p_h264.mov in MPV has the audio problem. >>>>>>>>>> >>>>>>>>>> https://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_720p_h264.mov >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Given that the audio drivers uses regmap, it could be good to >>>>>>>>> dump the >>>>>>>>> I2S/AHUB registers while the clip if playing with and without this >>>>>>>>> patch >>>>>>>>> to see the differences. I am curious if the audio is now being >>>>>>>>> played as >>>>>>>>> 24 or 32-bit instead of 16-bit now these are available. >>>>>>>>> >>>>>>>>> You could also dump the hw_params to see the format while >>>>>>>>> playing as >>>>>>>>> well ... >>>>>>>>> >>>>>>>>> $ /proc/asound/<scard-name>/pcm0p/sub0/hw_params >>>>>>>> >>>>>>>> I suppose it is also possible that the codec isn't properly >>>>>>>> doing >16 >>>>>>>> bits and the fact we now offer 24 and 32 could be an issue. I've >>>>>>>> not >>>>>>>> got anything with an audio output on it that would be easy to test. >>>>>>> >>>>>>> I thought I had tested on a Jetson TK1 (Tegra124) but it was >>>>>>> sometime >>>>>>> back. However, admittedly I may have only done simple 16-bit testing >>>>>>> with speaker-test. >>>>>>> >>>>>>> We do verify that all soundcards are detected and registered as >>>>>>> expected >>>>>>> during daily testing, but at the moment we don't have anything that >>>>>>> verifies actual playback. >>>>>> >>>>>> Please take a look at the attached logs. >>>>> >>>>> I wonder if we are falling into FIFO configuration issues with the >>>>> non-16 bit case. >>>>> >>>>> Can you try adding the following two patches? >>>> >>>> It is much better now! There is no horrible noise and no stuttering, >>>> but >>>> audio still has a "robotic" effect, like freq isn't correct. >>> >>> I wonder if there's an issue with FIFO stoking? I should also possibly >>> add the correctly stop FIFOs patch as well. >> >> I'll be happy to try more patches. >> >> Meanwhile sound on v5.5+ is broken and thus the incomplete patches >> should be reverted. > > Have you checked if just removing the 24/32 bits from .formats in > the dai template and see if the problem continues? It works. > I will try and > see if I can find the code that does the fifo level checking and > see if the problem is in the FIFO fill or something else in the > audio hub setup. Ok _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [alsa-devel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples 2019-12-22 17:08 ` Dmitry Osipenko @ 2020-01-05 0:04 ` Ben Dooks 2020-01-05 1:48 ` Dmitry Osipenko 0 siblings, 1 reply; 1767+ messages in thread From: Ben Dooks @ 2020-01-05 0:04 UTC (permalink / raw) To: Dmitry Osipenko, Jon Hunter, linux-tegra, alsa-devel, Jaroslav Kysela, Takashi Iwai, Liam Girdwood, Mark Brown, Thierry Reding Cc: linux-kernel, Edward Cragg [snip] I've just gone through testing. Some simple data tests show 16 and 32-bits work. The 24 bit case seems to be weird, it looks like the 24-bit expects 24 bit samples in 32 bit words. I can't see any packing options to do 24 bit in 24 bit, so we may have to remove 24 bit sample support (which is a shame) My preference is to remove the 24-bit support and keep the 32 bit in. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [alsa-devel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples 2020-01-05 0:04 ` Ben Dooks @ 2020-01-05 1:48 ` Dmitry Osipenko 2020-01-05 10:53 ` Ben Dooks 0 siblings, 1 reply; 1767+ messages in thread From: Dmitry Osipenko @ 2020-01-05 1:48 UTC (permalink / raw) To: Ben Dooks, Jon Hunter, linux-tegra, alsa-devel, Jaroslav Kysela, Takashi Iwai, Liam Girdwood, Mark Brown, Thierry Reding Cc: linux-kernel, Edward Cragg 05.01.2020 03:04, Ben Dooks пишет: > [snip] > > I've just gone through testing. > > Some simple data tests show 16 and 32-bits work. > > The 24 bit case seems to be weird, it looks like the 24-bit expects > 24 bit samples in 32 bit words. I can't see any packing options to > do 24 bit in 24 bit, so we may have to remove 24 bit sample support > (which is a shame) > > My preference is to remove the 24-bit support and keep the 32 bit in. > Interesting.. Jon, could you please confirm that 24bit format isn't usable on T30? _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [alsa-devel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples 2020-01-05 1:48 ` Dmitry Osipenko @ 2020-01-05 10:53 ` Ben Dooks 2020-01-06 19:00 ` [alsa-devel] [Linux-kernel] " Ben Dooks 0 siblings, 1 reply; 1767+ messages in thread From: Ben Dooks @ 2020-01-05 10:53 UTC (permalink / raw) To: Dmitry Osipenko Cc: linux-kernel, alsa-devel, Takashi Iwai, Liam Girdwood, Mark Brown, Thierry Reding, Edward Cragg, linux-tegra, Jon Hunter On 2020-01-05 01:48, Dmitry Osipenko wrote: > 05.01.2020 03:04, Ben Dooks пишет: >> [snip] >> >> I've just gone through testing. >> >> Some simple data tests show 16 and 32-bits work. >> >> The 24 bit case seems to be weird, it looks like the 24-bit expects >> 24 bit samples in 32 bit words. I can't see any packing options to >> do 24 bit in 24 bit, so we may have to remove 24 bit sample support >> (which is a shame) >> >> My preference is to remove the 24-bit support and keep the 32 bit in. >> > > Interesting.. Jon, could you please confirm that 24bit format isn't > usable on T30? If there is an option of 24 packed into 32, then I think that would work. I can try testing that with raw data on Monday. -- Ben _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [alsa-devel] [Linux-kernel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples 2020-01-05 10:53 ` Ben Dooks @ 2020-01-06 19:00 ` Ben Dooks 2020-01-07 1:39 ` Dmitry Osipenko 0 siblings, 1 reply; 1767+ messages in thread From: Ben Dooks @ 2020-01-06 19:00 UTC (permalink / raw) To: Dmitry Osipenko Cc: linux-kernel, alsa-devel, Liam Girdwood, Takashi Iwai, Mark Brown, Thierry Reding, Edward Cragg, linux-tegra, Jon Hunter On 05/01/2020 10:53, Ben Dooks wrote: > > > On 2020-01-05 01:48, Dmitry Osipenko wrote: >> 05.01.2020 03:04, Ben Dooks пишет: >>> [snip] >>> >>> I've just gone through testing. >>> >>> Some simple data tests show 16 and 32-bits work. >>> >>> The 24 bit case seems to be weird, it looks like the 24-bit expects >>> 24 bit samples in 32 bit words. I can't see any packing options to >>> do 24 bit in 24 bit, so we may have to remove 24 bit sample support >>> (which is a shame) >>> >>> My preference is to remove the 24-bit support and keep the 32 bit in. >>> >> >> Interesting.. Jon, could you please confirm that 24bit format isn't >> usable on T30? > > If there is an option of 24 packed into 32, then I think that would work. > > I can try testing that with raw data on Monday. I need to check some things, I assumed 24 was 24 packed bits, it looks like the default is 24 in 32 bits so we may be ok. However I need to re-write my test case which assumed it was 24bits in 3 bytes (S24_3LE). I'll follow up later, -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [alsa-devel] [Linux-kernel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples 2020-01-06 19:00 ` [alsa-devel] [Linux-kernel] " Ben Dooks @ 2020-01-07 1:39 ` Dmitry Osipenko 2020-01-23 19:38 ` Ben Dooks 0 siblings, 1 reply; 1767+ messages in thread From: Dmitry Osipenko @ 2020-01-07 1:39 UTC (permalink / raw) To: Ben Dooks Cc: linux-kernel, alsa-devel, Liam Girdwood, Takashi Iwai, Mark Brown, Thierry Reding, Edward Cragg, linux-tegra, Jon Hunter 06.01.2020 22:00, Ben Dooks пишет: > On 05/01/2020 10:53, Ben Dooks wrote: >> >> >> On 2020-01-05 01:48, Dmitry Osipenko wrote: >>> 05.01.2020 03:04, Ben Dooks пишет: >>>> [snip] >>>> >>>> I've just gone through testing. >>>> >>>> Some simple data tests show 16 and 32-bits work. >>>> >>>> The 24 bit case seems to be weird, it looks like the 24-bit expects >>>> 24 bit samples in 32 bit words. I can't see any packing options to >>>> do 24 bit in 24 bit, so we may have to remove 24 bit sample support >>>> (which is a shame) >>>> >>>> My preference is to remove the 24-bit support and keep the 32 bit in. >>>> >>> >>> Interesting.. Jon, could you please confirm that 24bit format isn't >>> usable on T30? >> >> If there is an option of 24 packed into 32, then I think that would work. >> >> I can try testing that with raw data on Monday. > > I need to check some things, I assumed 24 was 24 packed bits, it looks > like the default is 24 in 32 bits so we may be ok. However I need to > re-write my test case which assumed it was 24bits in 3 bytes (S24_3LE). > > I'll follow up later, Okay, the S24_3LE isn't supported by RT5640 codec in my case. I briefly looked through the TRM doc and got impression that AHUB could re-pack data stream into something that codec supports, but maybe it's a wrong impression. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [alsa-devel] [Linux-kernel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples 2020-01-07 1:39 ` Dmitry Osipenko @ 2020-01-23 19:38 ` Ben Dooks 2020-01-24 16:50 ` Jon Hunter 0 siblings, 1 reply; 1767+ messages in thread From: Ben Dooks @ 2020-01-23 19:38 UTC (permalink / raw) To: Dmitry Osipenko Cc: linux-kernel, alsa-devel, Liam Girdwood, Takashi Iwai, Mark Brown, Thierry Reding, Edward Cragg, linux-tegra, Jon Hunter On 07/01/2020 01:39, Dmitry Osipenko wrote: > 06.01.2020 22:00, Ben Dooks пишет: >> On 05/01/2020 10:53, Ben Dooks wrote: >>> >>> >>> On 2020-01-05 01:48, Dmitry Osipenko wrote: >>>> 05.01.2020 03:04, Ben Dooks пишет: >>>>> [snip] >>>>> >>>>> I've just gone through testing. >>>>> >>>>> Some simple data tests show 16 and 32-bits work. >>>>> >>>>> The 24 bit case seems to be weird, it looks like the 24-bit expects >>>>> 24 bit samples in 32 bit words. I can't see any packing options to >>>>> do 24 bit in 24 bit, so we may have to remove 24 bit sample support >>>>> (which is a shame) >>>>> >>>>> My preference is to remove the 24-bit support and keep the 32 bit in. >>>>> >>>> >>>> Interesting.. Jon, could you please confirm that 24bit format isn't >>>> usable on T30? >>> >>> If there is an option of 24 packed into 32, then I think that would work. >>> >>> I can try testing that with raw data on Monday. >> >> I need to check some things, I assumed 24 was 24 packed bits, it looks >> like the default is 24 in 32 bits so we may be ok. However I need to >> re-write my test case which assumed it was 24bits in 3 bytes (S24_3LE). >> >> I'll follow up later, > > Okay, the S24_3LE isn't supported by RT5640 codec in my case. I briefly > looked through the TRM doc and got impression that AHUB could re-pack > data stream into something that codec supports, but maybe it's a wrong > impression. > _________________________________ I did a quick test with the following: sox -n -b 16 -c 2 -r 44100 /tmp/tmp.wav synth sine 500 vol 0.5 sox -n -b 24 -c 2 -r 44100 /tmp/tmp.wav synth sine 500 vol 0.5 sox -n -b 32 -c 2 -r 44100 /tmp/tmp.wav synth sine 500 vol 0.5 The 16 and 32 work fine, the 24 is showing a playback output freq of 440Hz instead of 500Hz... this suggests the clock is off, or there is something else weird going on... -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [alsa-devel] [Linux-kernel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples 2020-01-23 19:38 ` Ben Dooks @ 2020-01-24 16:50 ` Jon Hunter 2020-01-27 19:20 ` Dmitry Osipenko 0 siblings, 1 reply; 1767+ messages in thread From: Jon Hunter @ 2020-01-24 16:50 UTC (permalink / raw) To: Ben Dooks, Dmitry Osipenko Cc: linux-kernel, alsa-devel, Liam Girdwood, Takashi Iwai, Mark Brown, Thierry Reding, Edward Cragg, linux-tegra On 23/01/2020 19:38, Ben Dooks wrote: > On 07/01/2020 01:39, Dmitry Osipenko wrote: >> 06.01.2020 22:00, Ben Dooks пишет: >>> On 05/01/2020 10:53, Ben Dooks wrote: >>>> >>>> >>>> On 2020-01-05 01:48, Dmitry Osipenko wrote: >>>>> 05.01.2020 03:04, Ben Dooks пишет: >>>>>> [snip] >>>>>> >>>>>> I've just gone through testing. >>>>>> >>>>>> Some simple data tests show 16 and 32-bits work. >>>>>> >>>>>> The 24 bit case seems to be weird, it looks like the 24-bit expects >>>>>> 24 bit samples in 32 bit words. I can't see any packing options to >>>>>> do 24 bit in 24 bit, so we may have to remove 24 bit sample support >>>>>> (which is a shame) >>>>>> >>>>>> My preference is to remove the 24-bit support and keep the 32 bit in. >>>>>> >>>>> >>>>> Interesting.. Jon, could you please confirm that 24bit format isn't >>>>> usable on T30? >>>> >>>> If there is an option of 24 packed into 32, then I think that would >>>> work. >>>> >>>> I can try testing that with raw data on Monday. >>> >>> I need to check some things, I assumed 24 was 24 packed bits, it looks >>> like the default is 24 in 32 bits so we may be ok. However I need to >>> re-write my test case which assumed it was 24bits in 3 bytes (S24_3LE). >>> >>> I'll follow up later, >> >> Okay, the S24_3LE isn't supported by RT5640 codec in my case. I briefly >> looked through the TRM doc and got impression that AHUB could re-pack >> data stream into something that codec supports, but maybe it's a wrong >> impression. >> _________________________________ > > I did a quick test with the following: > > sox -n -b 16 -c 2 -r 44100 /tmp/tmp.wav synth sine 500 vol 0.5 > sox -n -b 24 -c 2 -r 44100 /tmp/tmp.wav synth sine 500 vol 0.5 > sox -n -b 32 -c 2 -r 44100 /tmp/tmp.wav synth sine 500 vol 0.5 > > The 16 and 32 work fine, the 24 is showing a playback output freq > of 440Hz instead of 500Hz... this suggests the clock is off, or there > is something else weird going on... I was looking at using sox to create such as file, but the above command generates a S24_3LE file and not S24_LE file. The codec on Jetson-TK1 supports S24_LE but does not support S24_3LE and so I cannot test this. Anyway, we really need to test S24_LE and not S24_3LE because this is the problem that Dmitry is having. Ben is S24_3LE what you really need to support? Dmitry, does the following fix your problem? diff --git a/sound/soc/tegra/tegra30_i2s.c b/sound/soc/tegra/tegra30_i2s.c index dbed3c5408e7..92845c4b63f4 100644 --- a/sound/soc/tegra/tegra30_i2s.c +++ b/sound/soc/tegra/tegra30_i2s.c @@ -140,7 +140,7 @@ static int tegra30_i2s_hw_params(struct snd_pcm_substream *substream, audio_bits = TEGRA30_AUDIOCIF_BITS_16; sample_size = 16; break; - case SNDRV_PCM_FORMAT_S24_LE: + case SNDRV_PCM_FORMAT_S24_3LE: val = TEGRA30_I2S_CTRL_BIT_SIZE_24; audio_bits = TEGRA30_AUDIOCIF_BITS_24; sample_size = 24; @@ -318,7 +318,7 @@ static const struct snd_soc_dai_driver tegra30_i2s_dai_template = { .channels_max = 2, .rates = SNDRV_PCM_RATE_8000_96000, .formats = SNDRV_PCM_FMTBIT_S32_LE | - SNDRV_PCM_FMTBIT_S24_LE | + SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S16_LE, }, .capture = { @@ -327,7 +327,7 @@ static const struct snd_soc_dai_driver tegra30_i2s_dai_template = { .channels_max = 2, .rates = SNDRV_PCM_RATE_8000_96000, .formats = SNDRV_PCM_FMTBIT_S32_LE | - SNDRV_PCM_FMTBIT_S24_LE | + SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S16_LE, }, .ops = &tegra30_i2s_dai_ops, Jon -- nvpublic _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: [alsa-devel] [Linux-kernel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples 2020-01-24 16:50 ` Jon Hunter @ 2020-01-27 19:20 ` Dmitry Osipenko 2020-01-28 12:13 ` Mark Brown 0 siblings, 1 reply; 1767+ messages in thread From: Dmitry Osipenko @ 2020-01-27 19:20 UTC (permalink / raw) To: Jon Hunter, Ben Dooks Cc: linux-kernel, alsa-devel, Liam Girdwood, Takashi Iwai, Mark Brown, Thierry Reding, Edward Cragg, linux-tegra 24.01.2020 19:50, Jon Hunter пишет: > > On 23/01/2020 19:38, Ben Dooks wrote: >> On 07/01/2020 01:39, Dmitry Osipenko wrote: >>> 06.01.2020 22:00, Ben Dooks пишет: >>>> On 05/01/2020 10:53, Ben Dooks wrote: >>>>> >>>>> >>>>> On 2020-01-05 01:48, Dmitry Osipenko wrote: >>>>>> 05.01.2020 03:04, Ben Dooks пишет: >>>>>>> [snip] >>>>>>> >>>>>>> I've just gone through testing. >>>>>>> >>>>>>> Some simple data tests show 16 and 32-bits work. >>>>>>> >>>>>>> The 24 bit case seems to be weird, it looks like the 24-bit expects >>>>>>> 24 bit samples in 32 bit words. I can't see any packing options to >>>>>>> do 24 bit in 24 bit, so we may have to remove 24 bit sample support >>>>>>> (which is a shame) >>>>>>> >>>>>>> My preference is to remove the 24-bit support and keep the 32 bit in. >>>>>>> >>>>>> >>>>>> Interesting.. Jon, could you please confirm that 24bit format isn't >>>>>> usable on T30? >>>>> >>>>> If there is an option of 24 packed into 32, then I think that would >>>>> work. >>>>> >>>>> I can try testing that with raw data on Monday. >>>> >>>> I need to check some things, I assumed 24 was 24 packed bits, it looks >>>> like the default is 24 in 32 bits so we may be ok. However I need to >>>> re-write my test case which assumed it was 24bits in 3 bytes (S24_3LE). >>>> >>>> I'll follow up later, >>> >>> Okay, the S24_3LE isn't supported by RT5640 codec in my case. I briefly >>> looked through the TRM doc and got impression that AHUB could re-pack >>> data stream into something that codec supports, but maybe it's a wrong >>> impression. >>> _________________________________ >> >> I did a quick test with the following: >> >> sox -n -b 16 -c 2 -r 44100 /tmp/tmp.wav synth sine 500 vol 0.5 >> sox -n -b 24 -c 2 -r 44100 /tmp/tmp.wav synth sine 500 vol 0.5 >> sox -n -b 32 -c 2 -r 44100 /tmp/tmp.wav synth sine 500 vol 0.5 >> >> The 16 and 32 work fine, the 24 is showing a playback output freq >> of 440Hz instead of 500Hz... this suggests the clock is off, or there >> is something else weird going on... > > I was looking at using sox to create such as file, but the above command > generates a S24_3LE file and not S24_LE file. The codec on Jetson-TK1 > supports S24_LE but does not support S24_3LE and so I cannot test this. > Anyway, we really need to test S24_LE and not S24_3LE because this is > the problem that Dmitry is having. > > Ben is S24_3LE what you really need to support? > > Dmitry, does the following fix your problem? > > diff --git a/sound/soc/tegra/tegra30_i2s.c b/sound/soc/tegra/tegra30_i2s.c > index dbed3c5408e7..92845c4b63f4 100644 > --- a/sound/soc/tegra/tegra30_i2s.c > +++ b/sound/soc/tegra/tegra30_i2s.c > @@ -140,7 +140,7 @@ static int tegra30_i2s_hw_params(struct > snd_pcm_substream *substream, > audio_bits = TEGRA30_AUDIOCIF_BITS_16; > sample_size = 16; > break; > - case SNDRV_PCM_FORMAT_S24_LE: > + case SNDRV_PCM_FORMAT_S24_3LE: > val = TEGRA30_I2S_CTRL_BIT_SIZE_24; > audio_bits = TEGRA30_AUDIOCIF_BITS_24; > sample_size = 24; > @@ -318,7 +318,7 @@ static const struct snd_soc_dai_driver > tegra30_i2s_dai_template = { > .channels_max = 2, > .rates = SNDRV_PCM_RATE_8000_96000, > .formats = SNDRV_PCM_FMTBIT_S32_LE | > - SNDRV_PCM_FMTBIT_S24_LE | > + SNDRV_PCM_FMTBIT_S24_3LE | > SNDRV_PCM_FMTBIT_S16_LE, > }, > .capture = { > @@ -327,7 +327,7 @@ static const struct snd_soc_dai_driver > tegra30_i2s_dai_template = { > .channels_max = 2, > .rates = SNDRV_PCM_RATE_8000_96000, > .formats = SNDRV_PCM_FMTBIT_S32_LE | > - SNDRV_PCM_FMTBIT_S24_LE | > + SNDRV_PCM_FMTBIT_S24_3LE | > SNDRV_PCM_FMTBIT_S16_LE, > }, > .ops = &tegra30_i2s_dai_ops, > > Jon > It should solve the problem in my particular case, but I'm not sure that the solution is correct. The v5.5 kernel is released now with the broken audio and apparently getting 24bit to work won't be trivial (if possible at all). Ben, could you please send a patch to fix v5.5 by removing the S24 support advertisement from the driver? _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [alsa-devel] [Linux-kernel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples 2020-01-27 19:20 ` Dmitry Osipenko @ 2020-01-28 12:13 ` Mark Brown 2020-01-28 17:42 ` Dmitry Osipenko 0 siblings, 1 reply; 1767+ messages in thread From: Mark Brown @ 2020-01-28 12:13 UTC (permalink / raw) To: Dmitry Osipenko Cc: linux-kernel, alsa-devel, Takashi Iwai, Liam Girdwood, Ben Dooks, Thierry Reding, Edward Cragg, linux-tegra, Jon Hunter [-- Attachment #1.1: Type: text/plain, Size: 1209 bytes --] On Mon, Jan 27, 2020 at 10:20:25PM +0300, Dmitry Osipenko wrote: > 24.01.2020 19:50, Jon Hunter пишет: > > .rates = SNDRV_PCM_RATE_8000_96000, > > .formats = SNDRV_PCM_FMTBIT_S32_LE | > > - SNDRV_PCM_FMTBIT_S24_LE | > > + SNDRV_PCM_FMTBIT_S24_3LE | > It should solve the problem in my particular case, but I'm not sure that > the solution is correct. If the format implemented by the driver is S24_3LE the driver should advertise S24_3LE. > The v5.5 kernel is released now with the broken audio and apparently > getting 24bit to work won't be trivial (if possible at all). Ben, could > you please send a patch to fix v5.5 by removing the S24 support > advertisement from the driver? Why is that the best fix rather than just advertising the format implemented by the driver? I really don't understand why this is all taking so long, this thread just seems to be going round in interminable circles long after it looked like the issue was understood. I have to admit I've not read every single message in the thread but it's difficult to see why it doesn't seem to be making any progress. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 161 bytes --] _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [alsa-devel] [Linux-kernel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples 2020-01-28 12:13 ` Mark Brown @ 2020-01-28 17:42 ` Dmitry Osipenko 2020-01-28 18:19 ` Jon Hunter 0 siblings, 1 reply; 1767+ messages in thread From: Dmitry Osipenko @ 2020-01-28 17:42 UTC (permalink / raw) To: Mark Brown Cc: linux-kernel, alsa-devel, Takashi Iwai, Liam Girdwood, Ben Dooks, Thierry Reding, Edward Cragg, linux-tegra, Jon Hunter 28.01.2020 15:13, Mark Brown пишет: > On Mon, Jan 27, 2020 at 10:20:25PM +0300, Dmitry Osipenko wrote: >> 24.01.2020 19:50, Jon Hunter пишет: > >>> .rates = SNDRV_PCM_RATE_8000_96000, >>> .formats = SNDRV_PCM_FMTBIT_S32_LE | >>> - SNDRV_PCM_FMTBIT_S24_LE | >>> + SNDRV_PCM_FMTBIT_S24_3LE | > >> It should solve the problem in my particular case, but I'm not sure that >> the solution is correct. > > If the format implemented by the driver is S24_3LE the driver should > advertise S24_3LE. It should be S24_LE, but seems we still don't know for sure. >> The v5.5 kernel is released now with the broken audio and apparently >> getting 24bit to work won't be trivial (if possible at all). Ben, could >> you please send a patch to fix v5.5 by removing the S24 support >> advertisement from the driver? > > Why is that the best fix rather than just advertising the format > implemented by the driver? The currently supported format that is known to work well is S16_LE. I'm suggesting to drop the S24_LE and S32_LE that were added by the applied patches simply because this series wasn't tested properly before it was sent out and turned out that it doesn't work well. > I really don't understand why this is all taking so long, this thread > just seems to be going round in interminable circles long after it > looked like the issue was understood. I have to admit I've not read > every single message in the thread but it's difficult to see why it > doesn't seem to be making any progress. Ben was trying to make a fix for the introduced problem, but it's not easy as we see now. Perhaps the best solution should be to revert all of the three applied patches and try again later on, once all current problems will be resolved. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [alsa-devel] [Linux-kernel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples 2020-01-28 17:42 ` Dmitry Osipenko @ 2020-01-28 18:19 ` Jon Hunter 2020-01-29 0:17 ` Dmitry Osipenko 0 siblings, 1 reply; 1767+ messages in thread From: Jon Hunter @ 2020-01-28 18:19 UTC (permalink / raw) To: Dmitry Osipenko, Mark Brown Cc: linux-kernel, alsa-devel, Liam Girdwood, Takashi Iwai, Ben Dooks, Thierry Reding, Edward Cragg, linux-tegra On 28/01/2020 17:42, Dmitry Osipenko wrote: > 28.01.2020 15:13, Mark Brown пишет: >> On Mon, Jan 27, 2020 at 10:20:25PM +0300, Dmitry Osipenko wrote: >>> 24.01.2020 19:50, Jon Hunter пишет: >> >>>> .rates = SNDRV_PCM_RATE_8000_96000, >>>> .formats = SNDRV_PCM_FMTBIT_S32_LE | >>>> - SNDRV_PCM_FMTBIT_S24_LE | >>>> + SNDRV_PCM_FMTBIT_S24_3LE | >> >>> It should solve the problem in my particular case, but I'm not sure that >>> the solution is correct. >> >> If the format implemented by the driver is S24_3LE the driver should >> advertise S24_3LE. > > It should be S24_LE, but seems we still don't know for sure. Why? >>> The v5.5 kernel is released now with the broken audio and apparently >>> getting 24bit to work won't be trivial (if possible at all). Ben, could >>> you please send a patch to fix v5.5 by removing the S24 support >>> advertisement from the driver? >> >> Why is that the best fix rather than just advertising the format >> implemented by the driver? > > The currently supported format that is known to work well is S16_LE. > > I'm suggesting to drop the S24_LE and S32_LE that were added by the > applied patches simply because this series wasn't tested properly before > it was sent out and turned out that it doesn't work well. S32_LE should be fine, however, I do have some concerns about S24_LE. Jon -- nvpublic _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [alsa-devel] [Linux-kernel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples 2020-01-28 18:19 ` Jon Hunter @ 2020-01-29 0:17 ` Dmitry Osipenko [not found] ` <2ff97414-f0a5-7224-0e53-6cad2ed0ccd2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 1767+ messages in thread From: Dmitry Osipenko @ 2020-01-29 0:17 UTC (permalink / raw) To: Jon Hunter, Mark Brown Cc: linux-kernel, alsa-devel, Liam Girdwood, Takashi Iwai, Ben Dooks, Thierry Reding, Edward Cragg, linux-tegra 28.01.2020 21:19, Jon Hunter пишет: > > On 28/01/2020 17:42, Dmitry Osipenko wrote: >> 28.01.2020 15:13, Mark Brown пишет: >>> On Mon, Jan 27, 2020 at 10:20:25PM +0300, Dmitry Osipenko wrote: >>>> 24.01.2020 19:50, Jon Hunter пишет: >>> >>>>> .rates = SNDRV_PCM_RATE_8000_96000, >>>>> .formats = SNDRV_PCM_FMTBIT_S32_LE | >>>>> - SNDRV_PCM_FMTBIT_S24_LE | >>>>> + SNDRV_PCM_FMTBIT_S24_3LE | >>> >>>> It should solve the problem in my particular case, but I'm not sure that >>>> the solution is correct. >>> >>> If the format implemented by the driver is S24_3LE the driver should >>> advertise S24_3LE. >> >> It should be S24_LE, but seems we still don't know for sure. > > Why? /I think/ sound should be much more distorted if it was S24_3LE, but maybe I'm wrong. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <2ff97414-f0a5-7224-0e53-6cad2ed0ccd2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: [not found] ` <2ff97414-f0a5-7224-0e53-6cad2ed0ccd2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2020-01-30 8:05 ` Ben Dooks 0 siblings, 0 replies; 1767+ messages in thread From: Ben Dooks @ 2020-01-30 8:05 UTC (permalink / raw) To: Dmitry Osipenko, Jon Hunter, Mark Brown Cc: linux-kernel-81qHHgoATdFT9dQujB1mzip2UmYkHbXO, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Liam Girdwood, Takashi Iwai, Thierry Reding, Edward Cragg, linux-tegra-u79uwXL29TY76Z2rM5mHXA On 29/01/2020 00:17, Dmitry Osipenko wrote: > 28.01.2020 21:19, Jon Hunter пишет: >> >> On 28/01/2020 17:42, Dmitry Osipenko wrote: >>> 28.01.2020 15:13, Mark Brown пишет: >>>> On Mon, Jan 27, 2020 at 10:20:25PM +0300, Dmitry Osipenko wrote: >>>>> 24.01.2020 19:50, Jon Hunter пишет: >>>> >>>>>> .rates = SNDRV_PCM_RATE_8000_96000, >>>>>> .formats = SNDRV_PCM_FMTBIT_S32_LE | >>>>>> - SNDRV_PCM_FMTBIT_S24_LE | >>>>>> + SNDRV_PCM_FMTBIT_S24_3LE | >>>> >>>>> It should solve the problem in my particular case, but I'm not sure that >>>>> the solution is correct. >>>> >>>> If the format implemented by the driver is S24_3LE the driver should >>>> advertise S24_3LE. >>> >>> It should be S24_LE, but seems we still don't know for sure. >> >> Why? > /I think/ sound should be much more distorted if it was S24_3LE, but > maybe I'm wrong. S24_3LE is IICC the wrong thing and we can't support it on the tegra3 -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2019-12-19 12:31 liming wu 2019-12-20 1:13 ` Andreas Dilger 0 siblings, 1 reply; 1767+ messages in thread From: liming wu @ 2019-12-19 12:31 UTC (permalink / raw) To: linux-ext4 Hi Who can help analyze the following message . Or give me some advice, I will appreciate it very much. Dec 17 22:14:42 bdsitdb222 kernel: Buffer I/O error on device dm-7, logical block 810449 Dec 17 22:14:42 bdsitdb222 kernel: lost page write due to I/O error on dm-7 Dec 17 22:14:48 bdsitdb222 kernel: Buffer I/O error on device dm-7, logical block 283536 Dec 17 22:14:48 bdsitdb222 kernel: lost page write due to I/O error on dm-7 Dec 17 22:14:48 bdsitdb222 kernel: Buffer I/O error on device dm-7, logical block 283537 Dec 17 22:14:48 bdsitdb222 kernel: lost page write due to I/O error on dm-7 Dec 17 22:14:48 bdsitdb222 kernel: JBD: Detected IO errors while flushing file data on dm-7 Dec 17 22:15:42 bdsitdb222 kernel: Buffer I/O error on device dm-8, logical block 127859 Dec 17 22:15:42 bdsitdb222 kernel: lost page write due to I/O error on dm-8 Dec 17 22:15:42 bdsitdb222 kernel: JBD: Detected IO errors while flushing file data on dm-8 Dec 17 22:15:48 bdsitdb222 kernel: Aborting journal on device dm-7. Dec 17 22:15:48 bdsitdb222 kernel: EXT3-fs (dm-7): error in ext3_new_blocks: Journal has aborted Dec 17 22:15:48 bdsitdb222 kernel: EXT3-fs (dm-7): error in ext3_reserve_inode_write: Journal has aborted Dec 17 22:16:42 bdsitdb222 kernel: Aborting journal on device dm-8. Dec 17 22:16:42 bdsitdb222 kernel: EXT3-fs (dm-7): error: ext3_journal_start_sb: Detected aborted journal Dec 17 22:16:42 bdsitdb222 kernel: EXT3-fs (dm-7): error: remounting filesystem read-only Dec 17 22:16:48 bdsitdb222 kernel: Buffer I/O error on device dm-7, logical block 23527938 Dec 17 22:16:48 bdsitdb222 kernel: lost page write due to I/O error on dm-7 Dec 17 22:16:48 bdsitdb222 kernel: Buffer I/O error on device dm-7, logical block 0 Dec 17 22:16:48 bdsitdb222 kernel: lost page write due to I/O error on dm-7 Dec 17 22:16:48 bdsitdb222 kernel: JBD: I/O error detected when updating journal superblock for dm-7. Dec 17 22:17:05 bdsitdb222 kernel: EXT3-fs (dm-7): error in ext3_orphan_add: Journal has aborted Dec 17 22:17:05 bdsitdb222 kernel: __journal_remove_journal_head: freeing b_committed_data plus info: it's KVM # uname -a Linux bdsitdb222 2.6.32-279.19.1.el6.62.x86_64 #6 SMP Mon Dec 3 22:54:25 CST 2018 x86_64 x86_64 x86_64 GNU/Linux1 # cat /proc/mounts rootfs / rootfs rw 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 devtmpfs /dev devtmpfs rw,nosuid,relatime,size=8157352k,nr_inodes=2039338,mode=755 0 0 devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0 /dev/mapper/systemvg-rootlv / ext4 rw,relatime,barrier=1,data=ordered 0 0 /proc/bus/usb /proc/bus/usb usbfs rw,relatime 0 0 /dev/vda1 /boot ext4 rw,relatime,barrier=1,data=ordered 0 0 /dev/mapper/systemvg-homelv /home ext4 rw,relatime,barrier=1,data=ordered 0 0 /dev/mapper/systemvg-optlv /opt ext3 rw,relatime,errors=continue,barrier=1,data=ordered 0 0 /dev/mapper/systemvg-tmplv /tmp ext3 rw,relatime,errors=continue,barrier=1,data=ordered 0 0 /dev/mapper/systemvg-usrlv /usr ext4 rw,relatime,barrier=1,data=ordered 0 0 /dev/mapper/systemvg-varlv /var ext4 rw,relatime,barrier=1,data=ordered 0 0 /dev/mapper/datavg-datalv /mysql/data ext3 rw,relatime,errors=continue,barrier=1,data=ordered 0 0 /dev/mapper/datavg-binloglv /mysql/binlog ext3 rw,relatime,errors=continue,barrier=1,data=ordered 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0 sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0 none /sys/kernel/debug debugfs rw,relatime 0 0 # ll /dev/mapper/ total 0 crw-rw---- 1 root root 10, 58 Dec 19 19:21 control lrwxrwxrwx 1 root root 7 Dec 19 19:21 datavg-binloglv -> ../dm-3 lrwxrwxrwx 1 root root 7 Dec 19 19:21 datavg-datalv -> ../dm-2 lrwxrwxrwx 1 root root 7 Dec 19 19:21 systemvg-homelv -> ../dm-4 lrwxrwxrwx 1 root root 7 Dec 19 19:21 systemvg-optlv -> ../dm-7 lrwxrwxrwx 1 root root 7 Dec 19 19:21 systemvg-rootlv -> ../dm-1 lrwxrwxrwx 1 root root 7 Dec 19 19:21 systemvg-swaplv -> ../dm-0 lrwxrwxrwx 1 root root 7 Dec 19 19:21 systemvg-tmplv -> ../dm-6 lrwxrwxrwx 1 root root 7 Dec 19 19:21 systemvg-usrlv -> ../dm-8 lrwxrwxrwx 1 root root 7 Dec 19 19:21 systemvg-varlv -> ../dm-5 ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2019-12-19 12:31 liming wu @ 2019-12-20 1:13 ` Andreas Dilger 0 siblings, 0 replies; 1767+ messages in thread From: Andreas Dilger @ 2019-12-20 1:13 UTC (permalink / raw) To: liming wu; +Cc: Ext4 Developers List [-- Attachment #1: Type: text/plain, Size: 4753 bytes --] These messages indicate your storage is not working properly. It doesn't have anything to do with ext3/ext4. > On Dec 19, 2019, at 5:31 AM, liming wu <wu860403@gmail.com> wrote: > > Hi > > > Who can help analyze the following message . Or give me some advice, I > will appreciate it very much. > > Dec 17 22:14:42 bdsitdb222 kernel: Buffer I/O error on device dm-7, > logical block 810449 > Dec 17 22:14:42 bdsitdb222 kernel: lost page write due to I/O error on dm-7 > Dec 17 22:14:48 bdsitdb222 kernel: Buffer I/O error on device dm-7, > logical block 283536 > Dec 17 22:14:48 bdsitdb222 kernel: lost page write due to I/O error on dm-7 > Dec 17 22:14:48 bdsitdb222 kernel: Buffer I/O error on device dm-7, > logical block 283537 > Dec 17 22:14:48 bdsitdb222 kernel: lost page write due to I/O error on dm-7 > Dec 17 22:14:48 bdsitdb222 kernel: JBD: Detected IO errors while > flushing file data on dm-7 > Dec 17 22:15:42 bdsitdb222 kernel: Buffer I/O error on device dm-8, > logical block 127859 > Dec 17 22:15:42 bdsitdb222 kernel: lost page write due to I/O error on dm-8 > Dec 17 22:15:42 bdsitdb222 kernel: JBD: Detected IO errors while > flushing file data on dm-8 > Dec 17 22:15:48 bdsitdb222 kernel: Aborting journal on device dm-7. > Dec 17 22:15:48 bdsitdb222 kernel: EXT3-fs (dm-7): error in > ext3_new_blocks: Journal has aborted > Dec 17 22:15:48 bdsitdb222 kernel: EXT3-fs (dm-7): error in > ext3_reserve_inode_write: Journal has aborted > Dec 17 22:16:42 bdsitdb222 kernel: Aborting journal on device dm-8. > Dec 17 22:16:42 bdsitdb222 kernel: EXT3-fs (dm-7): error: > ext3_journal_start_sb: Detected aborted journal > Dec 17 22:16:42 bdsitdb222 kernel: EXT3-fs (dm-7): error: remounting > filesystem read-only > Dec 17 22:16:48 bdsitdb222 kernel: Buffer I/O error on device dm-7, > logical block 23527938 > Dec 17 22:16:48 bdsitdb222 kernel: lost page write due to I/O error on dm-7 > Dec 17 22:16:48 bdsitdb222 kernel: Buffer I/O error on device dm-7, > logical block 0 > Dec 17 22:16:48 bdsitdb222 kernel: lost page write due to I/O error on dm-7 > Dec 17 22:16:48 bdsitdb222 kernel: JBD: I/O error detected when > updating journal superblock for dm-7. > Dec 17 22:17:05 bdsitdb222 kernel: EXT3-fs (dm-7): error in > ext3_orphan_add: Journal has aborted > Dec 17 22:17:05 bdsitdb222 kernel: __journal_remove_journal_head: > freeing b_committed_data > > plus info: > it's KVM > # uname -a > Linux bdsitdb222 2.6.32-279.19.1.el6.62.x86_64 #6 SMP Mon Dec 3 > 22:54:25 CST 2018 x86_64 x86_64 x86_64 GNU/Linux1 > > # cat /proc/mounts > rootfs / rootfs rw 0 0 > proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 > sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 > devtmpfs /dev devtmpfs > rw,nosuid,relatime,size=8157352k,nr_inodes=2039338,mode=755 0 0 > devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0 > tmpfs /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0 > /dev/mapper/systemvg-rootlv / ext4 rw,relatime,barrier=1,data=ordered 0 0 > /proc/bus/usb /proc/bus/usb usbfs rw,relatime 0 0 > /dev/vda1 /boot ext4 rw,relatime,barrier=1,data=ordered 0 0 > /dev/mapper/systemvg-homelv /home ext4 rw,relatime,barrier=1,data=ordered 0 0 > /dev/mapper/systemvg-optlv /opt ext3 > rw,relatime,errors=continue,barrier=1,data=ordered 0 0 > /dev/mapper/systemvg-tmplv /tmp ext3 > rw,relatime,errors=continue,barrier=1,data=ordered 0 0 > /dev/mapper/systemvg-usrlv /usr ext4 rw,relatime,barrier=1,data=ordered 0 0 > /dev/mapper/systemvg-varlv /var ext4 rw,relatime,barrier=1,data=ordered 0 0 > /dev/mapper/datavg-datalv /mysql/data ext3 > rw,relatime,errors=continue,barrier=1,data=ordered 0 0 > /dev/mapper/datavg-binloglv /mysql/binlog ext3 > rw,relatime,errors=continue,barrier=1,data=ordered 0 0 > none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0 > sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0 > none /sys/kernel/debug debugfs rw,relatime 0 0 > > # ll /dev/mapper/ > total 0 > crw-rw---- 1 root root 10, 58 Dec 19 19:21 control > lrwxrwxrwx 1 root root 7 Dec 19 19:21 datavg-binloglv -> ../dm-3 > lrwxrwxrwx 1 root root 7 Dec 19 19:21 datavg-datalv -> ../dm-2 > lrwxrwxrwx 1 root root 7 Dec 19 19:21 systemvg-homelv -> ../dm-4 > lrwxrwxrwx 1 root root 7 Dec 19 19:21 systemvg-optlv -> ../dm-7 > lrwxrwxrwx 1 root root 7 Dec 19 19:21 systemvg-rootlv -> ../dm-1 > lrwxrwxrwx 1 root root 7 Dec 19 19:21 systemvg-swaplv -> ../dm-0 > lrwxrwxrwx 1 root root 7 Dec 19 19:21 systemvg-tmplv -> ../dm-6 > lrwxrwxrwx 1 root root 7 Dec 19 19:21 systemvg-usrlv -> ../dm-8 > lrwxrwxrwx 1 root root 7 Dec 19 19:21 systemvg-varlv -> ../dm-5 Cheers, Andreas [-- Attachment #2: Message signed with OpenPGP --] [-- Type: application/pgp-signature, Size: 873 bytes --] ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <20191205030032.GA26925@ray.huang@amd.com>]
* RE: [not found] <20191205030032.GA26925@ray.huang@amd.com> @ 2019-12-09 1:26 ` Quan, Evan 0 siblings, 0 replies; 1767+ messages in thread From: Quan, Evan @ 2019-12-09 1:26 UTC (permalink / raw) To: Huang, Ray, Wang, Kevin(Yang) Cc: Deucher, Alexander, amd-gfx@lists.freedesktop.org I actually do not see any problem with this change. 1. if smu_read_smc_arg() always return 0, I do not see any meaning to keep "return 0". Making it a "void" API is more reasonable. 2. Making " WREG32_SOC15(MP1, 0, mmMP1_SMN_C2PMSG_66, msg);" a separate API is ridiculous while " WREG32_SOC15(MP1, 0, mmMP1_SMN_C2PMSG_90, 0);" and " WREG32_SOC15(MP1, 0, mmMP1_SMN_C2PMSG_82, param);" did not. Actually these three combined together makes a real "message sending". Anyway it's fine with me if you guys can live with original poor code. > -----Original Message----- > From: Huang Rui <ray.huang@amd.com> > Sent: Thursday, December 5, 2019 11:01 AM > To: Wang, Kevin(Yang) <Kevin1.Wang@amd.com> > Cc: Quan, Evan <Evan.Quan@amd.com>; amd-gfx@lists.freedesktop.org; > Deucher, Alexander <Alexander.Deucher@amd.com> > Subject: > > Bcc: > Subject: Re: [PATCH 1/2] drm/amd/powerplay: drop unnecessary API wrapper > and return value > Reply-To: > In-Reply-To: > <MN2PR12MB32961EFFD79528A4EFF4BF5AA25D0@MN2PR12MB3296.nampr > d12.prod.outlook.com> > > On Wed, Dec 04, 2019 at 08:41:00PM +0800, Wang, Kevin(Yang) wrote: > > [AMD Official Use Only - Internal Distribution Only] > > > > this change doesn't make sense, and if you really think the return > > value is useless. > > It is more reasonable to accept parameters with return value, not > > parameter. > > I think these two patches make the code look worse, unless there's a > > bug in it. > > add [1]@Huang, Ray double check. > > Best Regards, > > Kevin > > > > > ________________________________________________________________ > __ > > > > From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> on behalf of Evan > > Quan <evan.quan@amd.com> > > Sent: Wednesday, December 4, 2019 5:53 PM > > To: amd-gfx@lists.freedesktop.org <amd-gfx@lists.freedesktop.org> > > Cc: Quan, Evan <Evan.Quan@amd.com> > > Subject: [PATCH 1/2] drm/amd/powerplay: drop unnecessary API wrapper > > and return value > > > > Some minor cosmetic fixes. > > Change-Id: I3ec217289f4cb491720430f2d0b0b4efe5e2b9aa > > Signed-off-by: Evan Quan <evan.quan@amd.com> > > --- > > drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 12 ++---- > > .../gpu/drm/amd/powerplay/inc/amdgpu_smu.h | 2 +- > > drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h | 2 +- > > drivers/gpu/drm/amd/powerplay/inc/smu_v12_0.h | 2 +- > > drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 39 +++++-------------- > > drivers/gpu/drm/amd/powerplay/smu_v12_0.c | 22 ++--------- > > 6 files changed, 19 insertions(+), 60 deletions(-) > > diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c > > b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c > > index 2dd960e85a24..00a0df9b41c9 100644 > > --- a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c > > +++ b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c > > @@ -198,9 +198,7 @@ int smu_get_smc_version(struct smu_context *smu, > > uint32_t *if_version, uint32_t > > if (ret) > > return ret; > > > > - ret = smu_read_smc_arg(smu, if_version); > > - if (ret) > > - return ret; > > + smu_read_smc_arg(smu, if_version); > > } > > > > if (smu_version) { > > @@ -208,9 +206,7 @@ int smu_get_smc_version(struct smu_context *smu, > > uint32_t *if_version, uint32_t > > if (ret) > > return ret; > > > > - ret = smu_read_smc_arg(smu, smu_version); > > - if (ret) > > - return ret; > > + smu_read_smc_arg(smu, smu_version); > > } > > > > return ret; > > @@ -339,9 +335,7 @@ int smu_get_dpm_freq_by_index(struct > smu_context > > *smu, enum smu_clk_type clk_typ > > if (ret) > > return ret; > > > > - ret = smu_read_smc_arg(smu, ¶m); > > - if (ret) > > - return ret; > > + smu_read_smc_arg(smu, ¶m); > > > > /* BIT31: 0 - Fine grained DPM, 1 - Dicrete DPM > > * now, we un-support it */ > > diff --git a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h > > b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h > > index ca3fdc6777cf..e7b18b209bc7 100644 > > --- a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h > > +++ b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h > > @@ -502,7 +502,7 @@ struct pptable_funcs { > > int (*system_features_control)(struct smu_context *smu, bool > > en); > > int (*send_smc_msg_with_param)(struct smu_context *smu, > > enum smu_message_type msg, > > uint32_t param); > > - int (*read_smc_arg)(struct smu_context *smu, uint32_t *arg); > > + void (*read_smc_arg)(struct smu_context *smu, uint32_t *arg); > > int (*init_display_count)(struct smu_context *smu, uint32_t > > count); > > int (*set_allowed_mask)(struct smu_context *smu); > > int (*get_enabled_mask)(struct smu_context *smu, uint32_t > > *feature_mask, uint32_t num); > > diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h > > b/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h > > index 610e301a5fce..4160147a03f3 100644 > > --- a/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h > > +++ b/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h > > @@ -183,7 +183,7 @@ smu_v11_0_send_msg_with_param(struct > smu_context > > *smu, > > enum smu_message_type msg, > > uint32_t param); > > > > -int smu_v11_0_read_arg(struct smu_context *smu, uint32_t *arg); > > +void smu_v11_0_read_arg(struct smu_context *smu, uint32_t *arg); > > > > int smu_v11_0_init_display_count(struct smu_context *smu, uint32_t > > count); > > > > diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu_v12_0.h > > b/drivers/gpu/drm/amd/powerplay/inc/smu_v12_0.h > > index 922973b7e29f..710af2860a8f 100644 > > --- a/drivers/gpu/drm/amd/powerplay/inc/smu_v12_0.h > > +++ b/drivers/gpu/drm/amd/powerplay/inc/smu_v12_0.h > > @@ -40,7 +40,7 @@ struct smu_12_0_cmn2aisc_mapping { > > int smu_v12_0_send_msg_without_waiting(struct smu_context *smu, > > uint16_t msg); > > > > -int smu_v12_0_read_arg(struct smu_context *smu, uint32_t *arg); > > +void smu_v12_0_read_arg(struct smu_context *smu, uint32_t *arg); > > > > int smu_v12_0_wait_for_response(struct smu_context *smu); > > > > diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c > > b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c > > index 8683e0678b56..325ec4864f90 100644 > > --- a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c > > +++ b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c > > @@ -53,20 +53,11 @@ MODULE_FIRMWARE("amdgpu/navi12_smc.bin"); > > > > #define SMU11_VOLTAGE_SCALE 4 > > > > -static int smu_v11_0_send_msg_without_waiting(struct smu_context *smu, > > - uint16_t msg) > > -{ > > - struct amdgpu_device *adev = smu->adev; > > - WREG32_SOC15(MP1, 0, mmMP1_SMN_C2PMSG_66, msg); > > - return 0; > > -} > > - > > -int smu_v11_0_read_arg(struct smu_context *smu, uint32_t *arg) > > +void smu_v11_0_read_arg(struct smu_context *smu, uint32_t *arg) > > { > > struct amdgpu_device *adev = smu->adev; > > > > *arg = RREG32_SOC15(MP1, 0, mmMP1_SMN_C2PMSG_82); > > - return 0; > > } > > > > static int smu_v11_0_wait_for_response(struct smu_context *smu) > > @@ -109,7 +100,7 @@ smu_v11_0_send_msg_with_param(struct > smu_context > > *smu, > > > > WREG32_SOC15(MP1, 0, mmMP1_SMN_C2PMSG_82, param); > > > > - smu_v11_0_send_msg_without_waiting(smu, (uint16_t)index); > > + WREG32_SOC15(MP1, 0, mmMP1_SMN_C2PMSG_66, > (uint16_t)index); > > > > ret = smu_v11_0_wait_for_response(smu); > > if (ret) > > @@ -843,16 +834,12 @@ int smu_v11_0_get_enabled_mask(struct > smu_context > > *smu, > > ret = smu_send_smc_msg(smu, > > SMU_MSG_GetEnabledSmuFeaturesHigh); > > if (ret) > > return ret; > > - ret = smu_read_smc_arg(smu, &feature_mask_high); > > - if (ret) > > - return ret; > > + smu_read_smc_arg(smu, &feature_mask_high); > > > > ret = smu_send_smc_msg(smu, > SMU_MSG_GetEnabledSmuFeaturesLow); > > if (ret) > > return ret; > > - ret = smu_read_smc_arg(smu, &feature_mask_low); > > - if (ret) > > - return ret; > > + smu_read_smc_arg(smu, &feature_mask_low); > > > > feature_mask[0] = feature_mask_low; > > feature_mask[1] = feature_mask_high; > > @@ -924,9 +911,7 @@ smu_v11_0_get_max_sustainable_clock(struct > > smu_context *smu, uint32_t *clock, > > return ret; > > } > > > > - ret = smu_read_smc_arg(smu, clock); > > - if (ret) > > - return ret; > > + smu_read_smc_arg(smu, clock); > > > > if (*clock != 0) > > return 0; > > @@ -939,7 +924,7 @@ smu_v11_0_get_max_sustainable_clock(struct > > smu_context *smu, uint32_t *clock, > > return ret; > > } > > > > - ret = smu_read_smc_arg(smu, clock); > > + smu_read_smc_arg(smu, clock); > > > > return ret; > > } > > @@ -1107,9 +1092,7 @@ int smu_v11_0_get_current_clk_freq(struct > > smu_context *smu, > > if (ret) > > return ret; > > > > - ret = smu_read_smc_arg(smu, &freq); > > - if (ret) > > - return ret; > > + smu_read_smc_arg(smu, &freq); > > } > > > > freq *= 100; > > @@ -1749,18 +1732,14 @@ int smu_v11_0_get_dpm_ultimate_freq(struct > > smu_context *smu, enum smu_clk_type c > > ret = smu_send_smc_msg_with_param(smu, > > SMU_MSG_GetMaxDpmFreq, param); > > if (ret) > > goto failed; > > - ret = smu_read_smc_arg(smu, max); > > - if (ret) > > - goto failed; > > + smu_read_smc_arg(smu, max); > > } > > > > if (min) { > > ret = smu_send_smc_msg_with_param(smu, > > SMU_MSG_GetMinDpmFreq, param); > > if (ret) > > goto failed; > > - ret = smu_read_smc_arg(smu, min); > > - if (ret) > > - goto failed; > > + smu_read_smc_arg(smu, min); > > } > > > > failed: > > diff --git a/drivers/gpu/drm/amd/powerplay/smu_v12_0.c > > b/drivers/gpu/drm/amd/powerplay/smu_v12_0.c > > index 269a7d73b58d..7f5f7e12a41e 100644 > > --- a/drivers/gpu/drm/amd/powerplay/smu_v12_0.c > > +++ b/drivers/gpu/drm/amd/powerplay/smu_v12_0.c > > @@ -41,21 +41,11 @@ > > #define SMUIO_GFX_MISC_CNTL__PWR_GFXOFF_STATUS_MASK > > 0x00000006L > > #define SMUIO_GFX_MISC_CNTL__PWR_GFXOFF_STATUS__SHIFT 0x1 > > > > -int smu_v12_0_send_msg_without_waiting(struct smu_context *smu, > > - uint16_t msg) > > -{ > > - struct amdgpu_device *adev = smu->adev; > > - > > - WREG32_SOC15(MP1, 0, mmMP1_SMN_C2PMSG_66, msg); > > - return 0; > > -} > > - > > -int smu_v12_0_read_arg(struct smu_context *smu, uint32_t *arg) > > +void smu_v12_0_read_arg(struct smu_context *smu, uint32_t *arg) > > { > > struct amdgpu_device *adev = smu->adev; > > > > *arg = RREG32_SOC15(MP1, 0, mmMP1_SMN_C2PMSG_82); > > - return 0; > > } > > > > int smu_v12_0_wait_for_response(struct smu_context *smu) > > @@ -98,7 +88,7 @@ smu_v12_0_send_msg_with_param(struct > smu_context > > *smu, > > > > WREG32_SOC15(MP1, 0, mmMP1_SMN_C2PMSG_82, param); > > > > - smu_v12_0_send_msg_without_waiting(smu, (uint16_t)index); > > + WREG32_SOC15(MP1, 0, mmMP1_SMN_C2PMSG_66, > (uint16_t)index); > > smu_v12_0_send_msg_without_waiting() function is more readable than using > raw register programming. > > Thanks, > Ray > > > > > ret = smu_v12_0_wait_for_response(smu); > > if (ret) > > @@ -352,9 +342,7 @@ int smu_v12_0_get_dpm_ultimate_freq(struct > > smu_context *smu, enum smu_clk_type c > > pr_err("Attempt to get max GX > > frequency from SMC Failed !\n"); > > goto failed; > > } > > - ret = smu_read_smc_arg(smu, max); > > - if (ret) > > - goto failed; > > + smu_read_smc_arg(smu, max); > > break; > > case SMU_UCLK: > > case SMU_FCLK: > > @@ -383,9 +371,7 @@ int smu_v12_0_get_dpm_ultimate_freq(struct > > smu_context *smu, enum smu_clk_type c > > pr_err("Attempt to get min GX > > frequency from SMC Failed !\n"); > > goto failed; > > } > > - ret = smu_read_smc_arg(smu, min); > > - if (ret) > > - goto failed; > > + smu_read_smc_arg(smu, min); > > break; > > case SMU_UCLK: > > case SMU_FCLK: > > -- > > 2.24.0 > > _______________________________________________ > > amd-gfx mailing list > > amd-gfx@lists.freedesktop.org > > [2]https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > > sts.freedesktop.org%2Fmailman%2Flistinfo%2Famd- > gfx&data=02%7C01%7CK > > > evin1.Wang%40amd.com%7Cb2381beaed6e4f83074608d7789fe6ef%7C3dd896 > 1fe4884 > > > e608e11a82d994e183d%7C0%7C0%7C637110500489978071&sdata=U15c > qXp2n00L > > RZDeu2482cwoZmEIrXWHCgF4NFap%2BkQ%3D&reserved=0 > > > > References > > > > 1. mailto:Ray.Huang@amd.com > > 2. > > https://nam11.safelinks.protection.outlook.com/?url=https://lists.free > > desktop.org/mailman/listinfo/amd- > gfx&data=02|01|Kevin1.Wang@amd.co > > > m|b2381beaed6e4f83074608d7789fe6ef|3dd8961fe4884e608e11a82d994e183 > d|0| > > > 0|637110500489978071&sdata=U15cqXp2n00LRZDeu2482cwoZmEIrXWH > CgF4NFa > > p+kQ=&reserved=0 _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2019-11-15 16:03 Martin Nicolay 2019-11-15 16:29 ` Martin Ågren 0 siblings, 1 reply; 1767+ messages in thread From: Martin Nicolay @ 2019-11-15 16:03 UTC (permalink / raw) To: git; +Cc: pclouds, mhagger, gitster, yuelinho777 From 7f5bb47a3b5b7a5443009078d936ab62dfa1fd85 Mon Sep 17 00:00:00 2001 From: Martin Nicolay <m.nicolay@osm-ag.de> Date: Fri, 15 Nov 2019 16:41:20 +0100 Subject: [PATCH] enable a timeout for hold_lock_file_for_update The new funktion get_files_lock_timeout_ms reads the config core.fileslocktimeout analog get_files_ref_lock_timeout_ms. This value is used in hold_lock_file_for_update instead of the fixed value 0. --- While working with complex scripts invoking git multiple times my editor detects the changes and calls "git status". This leads to aborts in "git-stash". With this patch and an appropriate value core.fileslocktimeout this problem goes away. lockfile.c | 15 +++++++++++++++ lockfile.h | 4 +++- 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/lockfile.c b/lockfile.c index 8e8ab4f29f..ac19de8937 100644 --- a/lockfile.c +++ b/lockfile.c @@ -145,6 +145,21 @@ static int lock_file_timeout(struct lock_file *lk, const char *path, } } +long get_files_lock_timeout_ms(void) +{ + static int configured = 0; + + /* The default timeout is 100 ms: */ + static int timeout_ms = 100; + + if (!configured) { + git_config_get_int("core.fileslocktimeout", &timeout_ms); + configured = 1; + } + + return timeout_ms; +} + void unable_to_lock_message(const char *path, int err, struct strbuf *buf) { if (err == EEXIST) { diff --git a/lockfile.h b/lockfile.h index 9843053ce8..a0520e6a7b 100644 --- a/lockfile.h +++ b/lockfile.h @@ -163,6 +163,8 @@ int hold_lock_file_for_update_timeout( struct lock_file *lk, const char *path, int flags, long timeout_ms); +long get_files_lock_timeout_ms(void); + /* * Attempt to create a lockfile for the file at `path` and return a * file descriptor for writing to it, or -1 on error. The flags @@ -172,7 +174,7 @@ static inline int hold_lock_file_for_update( struct lock_file *lk, const char *path, int flags) { - return hold_lock_file_for_update_timeout(lk, path, flags, 0); + return hold_lock_file_for_update_timeout(lk, path, flags, get_files_lock_timeout_ms() ); } /* -- 2.13.7 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2019-11-15 16:03 Martin Nicolay @ 2019-11-15 16:29 ` Martin Ågren 2019-11-15 16:37 ` Re: Martin Ågren 0 siblings, 1 reply; 1767+ messages in thread From: Martin Ågren @ 2019-11-15 16:29 UTC (permalink / raw) To: Martin Nicolay Cc: Git Mailing List, Nguyễn Thái Ngọc Duy, Michael Haggerty, Junio C Hamano, yuelinho777 Hi Martin On Fri, 15 Nov 2019 at 17:17, Martin Nicolay <martin@wsmn.osm-gmbh.de> wrote: > While working with complex scripts invoking git multiple times my > editor detects the changes and calls "git status". This leads to > aborts in "git-stash". With this patch and an appropriate value > core.fileslocktimeout this problem goes away. Are you able to patch your editor to call git --no-optional-locks status instead? See the bottom of git-status(1) ("BACKGROUND REFRESH") for more on this. > +long get_files_lock_timeout_ms(void) > +{ > + static int configured = 0; > + > + /* The default timeout is 100 ms: */ > + static int timeout_ms = 100; > + > + if (!configured) { > + git_config_get_int("core.fileslocktimeout", &timeout_ms); > + configured = 1; > + } > + > + return timeout_ms; > +} > + > @@ -172,7 +174,7 @@ static inline int hold_lock_file_for_update( > struct lock_file *lk, const char *path, > int flags) > { > - return hold_lock_file_for_update_timeout(lk, path, flags, 0); > + return hold_lock_file_for_update_timeout(lk, path, flags, get_files_lock_timeout_ms() ); > } This looks like it changes the default from 0 ("try exactly once") to 100ms. Maybe we should stick with 0 for those who don't jump onto this new config knob? Martin ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2019-11-15 16:29 ` Martin Ågren @ 2019-11-15 16:37 ` Martin Ågren 0 siblings, 0 replies; 1767+ messages in thread From: Martin Ågren @ 2019-11-15 16:37 UTC (permalink / raw) To: Martin Nicolay Cc: Git Mailing List, Nguyễn Thái Ngọc Duy, Michael Haggerty, Junio C Hamano, yuelinho777 [Trying with another e-mail address for Martin Nicolay. Maybe the one from the in-body From header works better. wsmn.osm-gmbh.de couldn't be found.] On Fri, 15 Nov 2019 at 17:29, Martin Ågren <martin.agren@gmail.com> wrote: > > Hi Martin > > On Fri, 15 Nov 2019 at 17:17, Martin Nicolay <martin@wsmn.osm-gmbh.de> wrote: > > > While working with complex scripts invoking git multiple times my > > editor detects the changes and calls "git status". This leads to > > aborts in "git-stash". With this patch and an appropriate value > > core.fileslocktimeout this problem goes away. > > Are you able to patch your editor to call > git --no-optional-locks status > instead? See the bottom of git-status(1) ("BACKGROUND REFRESH") for more > on this. > > > +long get_files_lock_timeout_ms(void) > > +{ > > + static int configured = 0; > > + > > + /* The default timeout is 100 ms: */ > > + static int timeout_ms = 100; > > + > > + if (!configured) { > > + git_config_get_int("core.fileslocktimeout", &timeout_ms); > > + configured = 1; > > + } > > + > > + return timeout_ms; > > +} > > + > > > @@ -172,7 +174,7 @@ static inline int hold_lock_file_for_update( > > struct lock_file *lk, const char *path, > > int flags) > > { > > - return hold_lock_file_for_update_timeout(lk, path, flags, 0); > > + return hold_lock_file_for_update_timeout(lk, path, flags, get_files_lock_timeout_ms() ); > > } > > This looks like it changes the default from 0 ("try exactly once") to > 100ms. Maybe we should stick with 0 for those who don't jump onto this > new config knob? > > Martin ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2019-11-14 11:37 SGV INVESTMENT 0 siblings, 0 replies; 1767+ messages in thread From: SGV INVESTMENT @ 2019-11-14 11:37 UTC (permalink / raw) To: linux-nvdimm Did you receive our business proposal email ? _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2019-10-27 21:47 Margaret Kwan Wing Han 0 siblings, 0 replies; 1767+ messages in thread From: Margaret Kwan Wing Han @ 2019-10-27 21:47 UTC (permalink / raw) To: linux-xfs I need a partner for a legal deal worth $30,500,000 if interested reply me for more details. Regards, Margaret Kwan Wing ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <CAGkTAxsV0zS_E64criQM-WtPKpSyW2PL=+fjACvnx2=m7piwXg@mail.gmail.com>]
* Re: [not found] <CAGkTAxsV0zS_E64criQM-WtPKpSyW2PL=+fjACvnx2=m7piwXg@mail.gmail.com> @ 2019-09-27 6:37 ` Michael Kerrisk (man-pages) 0 siblings, 0 replies; 1767+ messages in thread From: Michael Kerrisk (man-pages) @ 2019-09-27 6:37 UTC (permalink / raw) To: nilsocket; +Cc: linux-man Hello On Fri, 27 Sep 2019 at 08:26, nilsocket <nilsocket@gmail.com> wrote: > > In http://man7.org/linux/man-pages/man2/epoll_pwait.2.html#NOTES , > through out this section `epoll_wait()` is used. but only once > `epoll_pwait()` is used, I think it's a typo mistake. > > Current: > While one thread is blocked in a call to epoll_pwait() > > Expected Change: > While one thread is blocked in a call to epoll_wait() Thanks. Fixed! Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH] Revert "asm-generic: Remove unneeded __ARCH_WANT_SYS_LLSEEK macro"
@ 2019-08-30 19:54 Arnd Bergmann
[not found] ` <20190830202959.3539-1-msuchanek@suse.de>
0 siblings, 1 reply; 1767+ messages in thread
From: Arnd Bergmann @ 2019-08-30 19:54 UTC (permalink / raw)
To: Michal Suchanek
Cc: Rich Felker, Linux-sh list, Benjamin Herrenschmidt,
Heiko Carstens, linux-mips, James E.J. Bottomley, Max Filippov,
Guo Ren, H. Peter Anvin, sparclinux, Vincenzo Frascino,
Will Deacon, linux-arch, linux-s390, Yoshinori Sato,
Michael Ellerman, Helge Deller, the arch/x86 maintainers,
Russell King, Christian Borntraeger, Ingo Molnar,
Geert Uytterhoeven
On Fri, Aug 30, 2019 at 9:46 PM Michal Suchanek <msuchanek@suse.de> wrote:
>
> This reverts commit caf6f9c8a326cffd1d4b3ff3f1cfba75d159d70b.
>
> Maybe it was needed after all.
>
> When CONFIG_COMPAT is disabled on ppc64 the kernel does not build.
>
> There is resistance to both removing the llseek syscall from the 64bit
> syscall tables and building the llseek interface unconditionally.
>
> Link: https://lore.kernel.org/lkml/20190828151552.GA16855@infradead.org/
> Link: https://lore.kernel.org/lkml/20190829214319.498c7de2@naga/
>
> Signed-off-by: Michal Suchanek <msuchanek@suse.de>
This seems like the right idea in principle.
> index 5bbf587f5bc1..2f3c4bb138c4 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -331,7 +331,7 @@ COMPAT_SYSCALL_DEFINE3(lseek, unsigned int, fd, compat_off_t, offset, unsigned i
> }
> #endif
>
> -#if !defined(CONFIG_64BIT) || defined(CONFIG_COMPAT)
> +#ifdef __ARCH_WANT_SYS_LLSEEK
> SYSCALL_DEFINE5(llseek, unsigned int, fd, unsigned long, offset_high,
> unsigned long, offset_low, loff_t __user *, result,
> unsigned int, whence)
However, only reverting the patch will now break all newly added
32-bit architectures that don't define __ARCH_WANT_SYS_LLSEEK:
at least nds32 and riscv32 come to mind, not sure if there is another.
I think the easiest way however would be to combine the two checks
above and make it
#if !defined(CONFIG_64BIT) || defined(CONFIG_COMPAT) ||
defined(__ARCH_WANT_SYS_LLSEEK)
and then only set __ARCH_WANT_SYS_LLSEEK for powerpc.
Arnd
^ permalink raw reply [flat|nested] 1767+ messages in thread[parent not found: <20190830202959.3539-1-msuchanek@suse.de>]
* Re: [not found] ` <20190830202959.3539-1-msuchanek@suse.de> @ 2019-08-30 20:32 ` Arnd Bergmann 0 siblings, 0 replies; 1767+ messages in thread From: Arnd Bergmann @ 2019-08-30 20:32 UTC (permalink / raw) To: Michal Suchanek Cc: Heiko Carstens, Allison Randal, Linux Kernel Mailing List, Paul Mackerras, Alexander Viro, Greg Kroah-Hartman, Linux FS-devel Mailing List, Firoz Khan, Thomas Gleixner, linuxppc-dev, Christian Brauner On Fri, Aug 30, 2019 at 10:30 PM Michal Suchanek <msuchanek@suse.de> wrote: > > Subject: [PATCH] powerpc: Add back __ARCH_WANT_SYS_LLSEEK macro > > This partially reverts commit caf6f9c8a326 ("asm-generic: Remove > unneeded __ARCH_WANT_SYS_LLSEEK macro") > > When CONFIG_COMPAT is disabled on ppc64 the kernel does not build. > > There is resistance to both removing the llseek syscall from the 64bit > syscall tables and building the llseek interface unconditionally. > > Link: https://lore.kernel.org/lkml/20190828151552.GA16855@infradead.org/ > Link: https://lore.kernel.org/lkml/20190829214319.498c7de2@naga/ > > Signed-off-by: Michal Suchanek <msuchanek@suse.de> Reviewed-by: Arnd Bergmann <arnd@arndb.de> ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2019-08-20 17:23 William Baker 2019-08-20 17:27 ` Yagnatinsky, Mark 0 siblings, 1 reply; 1767+ messages in thread From: William Baker @ 2019-08-20 17:23 UTC (permalink / raw) To: git subscribe git ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: 2019-08-20 17:23 William Baker @ 2019-08-20 17:27 ` Yagnatinsky, Mark 0 siblings, 0 replies; 1767+ messages in thread From: Yagnatinsky, Mark @ 2019-08-20 17:27 UTC (permalink / raw) To: 'William Baker', git@vger.kernel.org No, not like that. See here: https://git.wiki.kernel.org/index.php/GitCommunity The email address you send the "subscribe" message to is NOT the mailing list itself. What you just did is send the words "subscribe git" to everyone already on the mailing list :) -----Original Message----- From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of William Baker Sent: Tuesday, August 20, 2019 1:23 PM To: git@vger.kernel.org Subject: subscribe git ---------------------------------------------------------------------- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <20190703063132.GA27292@ls3530.dellerweb.de>]
* Re: [not found] <20190703063132.GA27292@ls3530.dellerweb.de> @ 2019-07-03 6:38 ` Helge Deller 0 siblings, 0 replies; 1767+ messages in thread From: Helge Deller @ 2019-07-03 6:38 UTC (permalink / raw) To: Linus Torvalds, linux-parisc, James Bottomley, John David Anglin Please ignore the last mail. Somehow a newly-installed mutt misbehaved and sent out an empty email. Helge ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <DM5PR19MB165765D43BE979AB51A9897E9EEB0@DM5PR19MB1657.namprd19.prod.outlook.com>]
* Re: [not found] <DM5PR19MB165765D43BE979AB51A9897E9EEB0@DM5PR19MB1657.namprd19.prod.outlook.com> @ 2019-06-18 9:41 ` Enrico Weigelt, metux IT consult 0 siblings, 0 replies; 1767+ messages in thread From: Enrico Weigelt, metux IT consult @ 2019-06-18 9:41 UTC (permalink / raw) To: Grim, Dennis, linux-iio@vger.kernel.org On 17.06.19 16:58, Grim, Dennis wrote: > Is Industrial IO considered to be stable in kernel-3.6.0? > What exactly are you trying to achieve ? 3.6 is *very* old and completely unmaintained. And it's likely to miss lots of things you'll probably want, sooner or later. And backporting such far is anything but practical. (I recently had a client who asked me to backport recent BT features onto some old 3.15 vendor kernel - that would have taken years to get anythings stable). Seriously, don't try to use such old code in production systems. It's better to rebase your individual customizations onto recent mainline releases. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@metux.net -- +49-151-27565287 ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2019-06-13 7:02 Erling Persson Foundation 0 siblings, 0 replies; 1767+ messages in thread From: Erling Persson Foundation @ 2019-06-13 7:02 UTC (permalink / raw) To: sparclinux Message from Stefan Erling Persson, owner of Erling-Persson family philanthropic foundation and you have been selected as benefactor of 3.5 Million Euro from our personal donation in the year 2019. Reply for claim. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH v6 0/3] add new ima hook ima_kexec_cmdline to measure kexec boot cmdline args
@ 2019-05-21 0:06 Prakhar Srivastava
2019-05-21 0:06 ` [PATCH v6 2/3] add a new ima template field buf Prakhar Srivastava
0 siblings, 1 reply; 1767+ messages in thread
From: Prakhar Srivastava @ 2019-05-21 0:06 UTC (permalink / raw)
To: linux-integrity, linux-security-module, linux-kernel
Cc: mjg59, zohar, roberto.sassu, vgoyal, Prakhar Srivastava
The motive behind the patch series is to measure the boot cmdline args
used for soft reboot/kexec case.
For secure boot attestation, it is necessary to measure the kernel
command line and the kernel version. For cold boot, the boot loader
can be enhanced to measure these parameters.
(https://mjg59.dreamwidth.org/48897.html)
However, for attestation across soft reboot boundary, these values
also need to be measured during kexec_file_load.
Currently for Kexec(kexec_file_load)/soft reboot scenario the boot cmdline
args for the next kernel are not measured. For
normal case of boot/hardreboot the cmdline args are measured into the TPM.
The hash of boot command line is calculated and added to the current
running kernel's measurement list. On a soft reboot like kexec, the PCRs
are not reset to zero. Refer to commit 94c3aac567a9 ("ima: on soft
reboot, restore the measurement list") patch description.
To achive the above the patch series does the following
-adds a new ima hook: ima_kexec_cmdline which measures the cmdline args
into the ima log, behind a new ima policy entry KEXEC_CMDLINE.
-since the cmldine args cannot be appraised, a new template field(buf) is
added. The template field contains the buffer passed(cmldine args), which
can be used to appraise/attest at a later stage.
-call the ima_kexec_cmdline(...) hook from kexec_file_load call.
The ima logs need to carried over to the next kernel, which will be followed
up by other patchsets for x86_64 and arm64.
Changelog:
V6:
-add a new ima hook and policy to measure the cmdline
args(ima_kexec_cmdline)
-add a new template field buf to contain the buffer measured.
[suggested by Mimi Zohar]
add new fields to ima_event_data to store/read buffer data.
[suggested by Roberto]
-call ima_kexec_cmdline from kexec_file_load path
v5:
-add a new ima hook and policy to measure the cmdline
args(ima_kexec_cmdline)
-add a new template field buf to contain the buffer measured.
[suggested by Mimi Zohar]
-call ima_kexec_cmdline from kexec_file_load path
v4:
- per feedback from LSM community, removed the LSM hook and renamed the
IMA policy to KEXEC_CMDLINE
v3: (rebase changes to next-general)
- Add policy checks for buffer[suggested by Mimi Zohar]
- use the IMA_XATTR to add buffer
- Add kexec_cmdline used for kexec file load
- Add an LSM hook to allow usage by other LSM.[suggestd by Mimi Zohar]
v2:
- Add policy checks for buffer[suggested by Mimi Zohar]
- Add an LSM hook to allow usage by other LSM.[suggestd by Mimi Zohar]
- use the IMA_XATTR to add buffer instead of sig template
v1:
-Add kconfigs to control the ima_buffer_check
-measure the cmdline args suffixed with the kernel file name
-add the buffer to the template sig field.
Prakhar Srivastava (3):
Add a new ima hook ima_kexec_cmdline to measure cmdline args
add a new ima template field buf
call ima_kexec_cmdline to measure the cmdline args
Documentation/ABI/testing/ima_policy | 1 +
Documentation/security/IMA-templates.rst | 2 +-
include/linux/ima.h | 2 +
kernel/kexec_file.c | 8 ++-
security/integrity/ima/ima.h | 3 +
security/integrity/ima/ima_api.c | 5 +-
security/integrity/ima/ima_init.c | 2 +-
security/integrity/ima/ima_main.c | 80 +++++++++++++++++++++++
security/integrity/ima/ima_policy.c | 9 +++
security/integrity/ima/ima_template.c | 2 +
security/integrity/ima/ima_template_lib.c | 20 ++++++
security/integrity/ima/ima_template_lib.h | 4 ++
12 files changed, 131 insertions(+), 7 deletions(-)
--
2.17.1
^ permalink raw reply [flat|nested] 1767+ messages in thread* [PATCH v6 2/3] add a new ima template field buf 2019-05-21 0:06 [PATCH v6 0/3] add new ima hook ima_kexec_cmdline to measure kexec boot cmdline args Prakhar Srivastava @ 2019-05-21 0:06 ` Prakhar Srivastava 2019-05-24 15:12 ` Mimi Zohar 0 siblings, 1 reply; 1767+ messages in thread From: Prakhar Srivastava @ 2019-05-21 0:06 UTC (permalink / raw) To: linux-integrity, linux-security-module, linux-kernel Cc: mjg59, zohar, roberto.sassu, vgoyal, Prakhar Srivastava A buffer(cmdline args) measured into ima cannot be appraised without already being aware of the buffer contents.Since we don't know what cmdline args will be passed (or need to validate what was passed) it is not possible to appraise it. Since hashs are non reversible the raw buffer is needed to recompute the hash. To regenrate the hash of the buffer and appraise the same the contents of the buffer need to be available. A new template field buf is added to the existing ima template fields, which can be used to store/read the buffer itself. Two new fields are added to the ima_event_data to carry the buf and buf_len whenever necessary. Updated the process_buffer_measurement call to add the buf to the ima_event_data. process_buffer_measurement added in "Add a new ima hook ima_kexec_cmdline to measure cmdline args" - Add a new template field 'buf' to be used to store/read the buffer data. - Added two new fields to ima_event_data to hold the buf and buf_len [Suggested by Roberto] -Updated process_buffer_meaurement to add the buffer to ima_event_data Signed-off-by: Prakhar Srivastava <prsriva02@gmail.com> --- Documentation/security/IMA-templates.rst | 2 +- security/integrity/ima/ima.h | 2 ++ security/integrity/ima/ima_api.c | 4 ++-- security/integrity/ima/ima_init.c | 2 +- security/integrity/ima/ima_main.c | 4 +++- security/integrity/ima/ima_template.c | 2 ++ security/integrity/ima/ima_template_lib.c | 20 ++++++++++++++++++++ security/integrity/ima/ima_template_lib.h | 4 ++++ 8 files changed, 35 insertions(+), 5 deletions(-) diff --git a/Documentation/security/IMA-templates.rst b/Documentation/security/IMA-templates.rst index 2cd0e273cc9a..9cddb66727ee 100644 --- a/Documentation/security/IMA-templates.rst +++ b/Documentation/security/IMA-templates.rst @@ -70,7 +70,7 @@ descriptors by adding their identifier to the format string prefix is shown only if the hash algorithm is not SHA1 or MD5); - 'n-ng': the name of the event, without size limitations; - 'sig': the file signature. - + - 'buf': the buffer data that was used to generate the hash without size limitations. Below, there is the list of defined template descriptors: diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h index 226a26d8de09..4a82541dc3b6 100644 --- a/security/integrity/ima/ima.h +++ b/security/integrity/ima/ima.h @@ -65,6 +65,8 @@ struct ima_event_data { struct evm_ima_xattr_data *xattr_value; int xattr_len; const char *violation; + const void *buf; + int buf_len; }; /* IMA template field data definition */ diff --git a/security/integrity/ima/ima_api.c b/security/integrity/ima/ima_api.c index 800d965232e5..c12f1cd38f8f 100644 --- a/security/integrity/ima/ima_api.c +++ b/security/integrity/ima/ima_api.c @@ -134,7 +134,7 @@ void ima_add_violation(struct file *file, const unsigned char *filename, struct ima_template_entry *entry; struct inode *inode = file_inode(file); struct ima_event_data event_data = {iint, file, filename, NULL, 0, - cause}; + cause, NULL, 0}; int violation = 1; int result; @@ -286,7 +286,7 @@ void ima_store_measurement(struct integrity_iint_cache *iint, struct inode *inode = file_inode(file); struct ima_template_entry *entry; struct ima_event_data event_data = {iint, file, filename, xattr_value, - xattr_len, NULL}; + xattr_len, NULL, NULL, 0}; int violation = 0; if (iint->measured_pcrs & (0x1 << pcr)) diff --git a/security/integrity/ima/ima_init.c b/security/integrity/ima/ima_init.c index 6c9295449751..0c34d3100b5b 100644 --- a/security/integrity/ima/ima_init.c +++ b/security/integrity/ima/ima_init.c @@ -50,7 +50,7 @@ static int __init ima_add_boot_aggregate(void) struct ima_template_entry *entry; struct integrity_iint_cache tmp_iint, *iint = &tmp_iint; struct ima_event_data event_data = {iint, NULL, boot_aggregate_name, - NULL, 0, NULL}; + NULL, 0, NULL, NULL, 0}; int result = -ENOMEM; int violation = 0; struct { diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c index a88c28918a63..6c5691b65b84 100644 --- a/security/integrity/ima/ima_main.c +++ b/security/integrity/ima/ima_main.c @@ -594,7 +594,7 @@ static void process_buffer_measurement(const void *buf, int size, struct ima_template_entry *entry = NULL; struct integrity_iint_cache tmp_iint, *iint = &tmp_iint; struct ima_event_data event_data = {iint, NULL, NULL, - NULL, 0, NULL}; + NULL, 0, NULL, NULL, 0}; struct { struct ima_digest_data hdr; char digest[IMA_MAX_DIGEST_SIZE]; @@ -611,6 +611,8 @@ static void process_buffer_measurement(const void *buf, int size, memset(&hash, 0, sizeof(hash)); event_data.filename = eventname; + event_data.buf = buf; + event_data.buf_len = size; iint->ima_hash = &hash.hdr; iint->ima_hash->algo = ima_hash_algo; diff --git a/security/integrity/ima/ima_template.c b/security/integrity/ima/ima_template.c index b631b8bc7624..a76d1c04162a 100644 --- a/security/integrity/ima/ima_template.c +++ b/security/integrity/ima/ima_template.c @@ -43,6 +43,8 @@ static const struct ima_template_field supported_fields[] = { .field_show = ima_show_template_string}, {.field_id = "sig", .field_init = ima_eventsig_init, .field_show = ima_show_template_sig}, + {.field_id = "buf", .field_init = ima_eventbuf_init, + .field_show = ima_show_template_buf}, }; #define MAX_TEMPLATE_NAME_LEN 15 diff --git a/security/integrity/ima/ima_template_lib.c b/security/integrity/ima/ima_template_lib.c index 513b457ae900..43d1404141c1 100644 --- a/security/integrity/ima/ima_template_lib.c +++ b/security/integrity/ima/ima_template_lib.c @@ -162,6 +162,12 @@ void ima_show_template_sig(struct seq_file *m, enum ima_show_type show, ima_show_template_field_data(m, show, DATA_FMT_HEX, field_data); } +void ima_show_template_buf(struct seq_file *m, enum ima_show_type show, + struct ima_field_data *field_data) +{ + ima_show_template_field_data(m, show, DATA_FMT_HEX, field_data); +} + /** * ima_parse_buf() - Parses lengths and data from an input buffer * @bufstartp: Buffer start address. @@ -389,3 +395,17 @@ int ima_eventsig_init(struct ima_event_data *event_data, return ima_write_template_field_data(xattr_value, event_data->xattr_len, DATA_FMT_HEX, field_data); } + +/* + * ima_eventbuf_init - include the buffer(kexec-cmldine) as part of the + * template data. + */ +int ima_eventbuf_init(struct ima_event_data *event_data, + struct ima_field_data *field_data) +{ + if ((!event_data->buf) || (event_data->buf_len == 0)) + return 0; + + return ima_write_template_field_data(event_data->buf, event_data->buf_len, + DATA_FMT_HEX, field_data); +} diff --git a/security/integrity/ima/ima_template_lib.h b/security/integrity/ima/ima_template_lib.h index 6a3d8b831deb..f0178bc60c55 100644 --- a/security/integrity/ima/ima_template_lib.h +++ b/security/integrity/ima/ima_template_lib.h @@ -29,6 +29,8 @@ void ima_show_template_string(struct seq_file *m, enum ima_show_type show, struct ima_field_data *field_data); void ima_show_template_sig(struct seq_file *m, enum ima_show_type show, struct ima_field_data *field_data); +void ima_show_template_buf(struct seq_file *m, enum ima_show_type show, + struct ima_field_data *field_data); int ima_parse_buf(void *bufstartp, void *bufendp, void **bufcurp, int maxfields, struct ima_field_data *fields, int *curfields, unsigned long *len_mask, int enforce_mask, char *bufname); @@ -42,4 +44,6 @@ int ima_eventname_ng_init(struct ima_event_data *event_data, struct ima_field_data *field_data); int ima_eventsig_init(struct ima_event_data *event_data, struct ima_field_data *field_data); +int ima_eventbuf_init(struct ima_event_data *event_data, + struct ima_field_data *field_data); #endif /* __LINUX_IMA_TEMPLATE_LIB_H */ -- 2.17.1 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: [PATCH v6 2/3] add a new ima template field buf 2019-05-21 0:06 ` [PATCH v6 2/3] add a new ima template field buf Prakhar Srivastava @ 2019-05-24 15:12 ` Mimi Zohar 2019-05-24 15:42 ` Roberto Sassu 0 siblings, 1 reply; 1767+ messages in thread From: Mimi Zohar @ 2019-05-24 15:12 UTC (permalink / raw) To: Prakhar Srivastava, linux-integrity, linux-security-module, linux-kernel Cc: mjg59, roberto.sassu, vgoyal On Mon, 2019-05-20 at 17:06 -0700, Prakhar Srivastava wrote: > A buffer(cmdline args) measured into ima cannot be appraised > without already being aware of the buffer contents.Since we > don't know what cmdline args will be passed (or need to validate > what was passed) it is not possible to appraise it. > > Since hashs are non reversible the raw buffer is needed to > recompute the hash. > To regenrate the hash of the buffer and appraise the same > the contents of the buffer need to be available. > > A new template field buf is added to the existing ima template > fields, which can be used to store/read the buffer itself. > Two new fields are added to the ima_event_data to carry the > buf and buf_len whenever necessary. > > Updated the process_buffer_measurement call to add the buf > to the ima_event_data. > process_buffer_measurement added in "Add a new ima hook > ima_kexec_cmdline to measure cmdline args" > > - Add a new template field 'buf' to be used to store/read > the buffer data. > - Added two new fields to ima_event_data to hold the buf and > buf_len [Suggested by Roberto] > -Updated process_buffer_meaurement to add the buffer to > ima_event_data This patch description can be written more concisely. Patch 1/3 in this series introduces measuring the kexec boot command line. This patch defines a new template field for storing the kexec boot command line in the measurement list in order for a remote attestation server to verify. As mentioned, the first patch description should include a shell command for verifying the digest in the kexec boot command line measurement list record against /proc/cmdline. This patch description should include a shell command showing how to verify the digest based on the new field. Should the new field in the ascii measurement list be displayed as a string, not hex? Mimi ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2019-05-24 15:12 ` Mimi Zohar @ 2019-05-24 15:42 ` Roberto Sassu 2019-05-24 15:47 ` Re: Roberto Sassu 0 siblings, 1 reply; 1767+ messages in thread From: Roberto Sassu @ 2019-05-24 15:42 UTC (permalink / raw) To: Mimi Zohar, Prakhar Srivastava, linux-integrity, linux-security-module, linux-kernel Cc: mjg59, vgoyal On 5/24/2019 5:12 PM, Mimi Zohar wrote: > On Mon, 2019-05-20 at 17:06 -0700, Prakhar Srivastava wrote: >> A buffer(cmdline args) measured into ima cannot be appraised >> without already being aware of the buffer contents.Since we >> don't know what cmdline args will be passed (or need to validate >> what was passed) it is not possible to appraise it. >> >> Since hashs are non reversible the raw buffer is needed to >> recompute the hash. >> To regenrate the hash of the buffer and appraise the same >> the contents of the buffer need to be available. >> >> A new template field buf is added to the existing ima template >> fields, which can be used to store/read the buffer itself. >> Two new fields are added to the ima_event_data to carry the >> buf and buf_len whenever necessary. >> >> Updated the process_buffer_measurement call to add the buf >> to the ima_event_data. >> process_buffer_measurement added in "Add a new ima hook >> ima_kexec_cmdline to measure cmdline args" >> >> - Add a new template field 'buf' to be used to store/read >> the buffer data. >> - Added two new fields to ima_event_data to hold the buf and >> buf_len [Suggested by Roberto] >> -Updated process_buffer_meaurement to add the buffer to >> ima_event_data > > This patch description can be written more concisely. > > Patch 1/3 in this series introduces measuring the kexec boot command > line. This patch defines a new template field for storing the kexec > boot command line in the measurement list in order for a remote > attestation server to verify. > > As mentioned, the first patch description should include a shell > command for verifying the digest in the kexec boot command line > measurement list record against /proc/cmdline. This patch description > should include a shell command showing how to verify the digest based > on the new field. Should the new field in the ascii measurement list > be displayed as a string, not hex? We should define a new type. If the type is DATA_FMT_STRING, spaces are replaced with '_'. Roberto -- HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Bo PENG, Jian LI, Yanli SHI ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2019-05-24 15:42 ` Roberto Sassu @ 2019-05-24 15:47 ` Roberto Sassu 2019-05-24 18:09 ` Re: Mimi Zohar 0 siblings, 1 reply; 1767+ messages in thread From: Roberto Sassu @ 2019-05-24 15:47 UTC (permalink / raw) To: Mimi Zohar, Prakhar Srivastava, linux-integrity, linux-security-module, linux-kernel Cc: mjg59, vgoyal On 5/24/2019 5:42 PM, Roberto Sassu wrote: > On 5/24/2019 5:12 PM, Mimi Zohar wrote: >> On Mon, 2019-05-20 at 17:06 -0700, Prakhar Srivastava wrote: >>> A buffer(cmdline args) measured into ima cannot be appraised >>> without already being aware of the buffer contents.Since we >>> don't know what cmdline args will be passed (or need to validate >>> what was passed) it is not possible to appraise it. >>> >>> Since hashs are non reversible the raw buffer is needed to >>> recompute the hash. >>> To regenrate the hash of the buffer and appraise the same >>> the contents of the buffer need to be available. >>> >>> A new template field buf is added to the existing ima template >>> fields, which can be used to store/read the buffer itself. >>> Two new fields are added to the ima_event_data to carry the >>> buf and buf_len whenever necessary. >>> >>> Updated the process_buffer_measurement call to add the buf >>> to the ima_event_data. >>> process_buffer_measurement added in "Add a new ima hook >>> ima_kexec_cmdline to measure cmdline args" >>> >>> - Add a new template field 'buf' to be used to store/read >>> the buffer data. >>> - Added two new fields to ima_event_data to hold the buf and >>> buf_len [Suggested by Roberto] >>> -Updated process_buffer_meaurement to add the buffer to >>> ima_event_data >> >> This patch description can be written more concisely. >> >> Patch 1/3 in this series introduces measuring the kexec boot command >> line. This patch defines a new template field for storing the kexec >> boot command line in the measurement list in order for a remote >> attestation server to verify. >> >> As mentioned, the first patch description should include a shell >> command for verifying the digest in the kexec boot command line >> measurement list record against /proc/cmdline. This patch description >> should include a shell command showing how to verify the digest based >> on the new field. Should the new field in the ascii measurement list >> be displayed as a string, not hex? > > We should define a new type. If the type is DATA_FMT_STRING, spaces are > replaced with '_'. Or better. Leave it as hex, otherwise there would be a parsing problem if there are spaces in the data for a field. Roberto -- HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Bo PENG, Jian LI, Yanli SHI ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: Re: 2019-05-24 15:47 ` Re: Roberto Sassu @ 2019-05-24 18:09 ` Mimi Zohar 2019-05-24 19:00 ` Re: prakhar srivastava 0 siblings, 1 reply; 1767+ messages in thread From: Mimi Zohar @ 2019-05-24 18:09 UTC (permalink / raw) To: Roberto Sassu, Prakhar Srivastava, linux-integrity, linux-security-module, linux-kernel Cc: mjg59, vgoyal > >> As mentioned, the first patch description should include a shell > >> command for verifying the digest in the kexec boot command line > >> measurement list record against /proc/cmdline. This patch description > >> should include a shell command showing how to verify the digest based > >> on the new field. Should the new field in the ascii measurement list > >> be displayed as a string, not hex? > > > > We should define a new type. If the type is DATA_FMT_STRING, spaces are > > replaced with '_'. > > Or better. Leave it as hex, otherwise there would be a parsing problem > if there are spaces in the data for a field. After making a few changes, the measurement list contains the following kexec-cmdline data: 10 edc32d1e3a5ba7272280a395b6fb56a5ef7c78c3 ima-buf sha256:4f43b7db850e 88c49dfeffd4b1eb4f021d78033dfb05b07e45eec8d0b45275 kexec-cmdline 726f6f 743d2f6465762f7364613420726f2072642e6c756b732e757569643d6c756b73 2d6637 3633643737632d653236622d343431642d613734652d62363633636334643832 656120 696d615f706f6c6963793d7463627c61707072616973655f746362 There's probably a better shell command, but the following works to verify the digest locally against the /proc/cmdline: $ echo -n -e `cat /proc/cmdline | sed 's/^.*root=/root=/'` | sha256sum 4f43b7db850e88c49dfeffd4b1eb4f021d78033dfb05b07e45eec8d0b4527f65 - If we leave the "buf" field as ascii-hex, what would the shell command look like when verifying the digest based on the "buf" field? Mimi ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: Re: 2019-05-24 18:09 ` Re: Mimi Zohar @ 2019-05-24 19:00 ` prakhar srivastava 2019-05-24 19:15 ` Re: Mimi Zohar 0 siblings, 1 reply; 1767+ messages in thread From: prakhar srivastava @ 2019-05-24 19:00 UTC (permalink / raw) To: Mimi Zohar Cc: Roberto Sassu, linux-integrity, linux-security-module, linux-kernel, Matthew Garrett, vgoyal On Fri, May 24, 2019 at 11:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > >> As mentioned, the first patch description should include a shell > > >> command for verifying the digest in the kexec boot command line > > >> measurement list record against /proc/cmdline. This patch description > > >> should include a shell command showing how to verify the digest based > > >> on the new field. Should the new field in the ascii measurement list > > >> be displayed as a string, not hex? > > > > > > We should define a new type. If the type is DATA_FMT_STRING, spaces are > > > replaced with '_'. > > > > Or better. Leave it as hex, otherwise there would be a parsing problem > > if there are spaces in the data for a field. > > After making a few changes, the measurement list contains the > following kexec-cmdline data: > > 10 edc32d1e3a5ba7272280a395b6fb56a5ef7c78c3 ima-buf > sha256:4f43b7db850e > 88c49dfeffd4b1eb4f021d78033dfb05b07e45eec8d0b45275 > kexec-cmdline > 726f6f > 743d2f6465762f7364613420726f2072642e6c756b732e757569643d6c756b73 > 2d6637 > 3633643737632d653236622d343431642d613734652d62363633636334643832 > 656120 > 696d615f706f6c6963793d7463627c61707072616973655f746362 > > There's probably a better shell command, but the following works to > verify the digest locally against the /proc/cmdline: > > $ echo -n -e `cat /proc/cmdline | sed 's/^.*root=/root=/'` | sha256sum > 4f43b7db850e88c49dfeffd4b1eb4f021d78033dfb05b07e45eec8d0b4527f65 - > > If we leave the "buf" field as ascii-hex, what would the shell command > look like when verifying the digest based on the "buf" field? > > Mimi > To quickly test the sha256 i used the my /proc/cmdline ro quiet splash vt.handoff=1 ima_policy=tcb ima_appraise=fix ima_template_fmt=n-ng|d-ng|sig|buf ima_hash=sha256 export $VAL= 726f2071756965742073706c6173682076742e68616e646f66663d3120 696d615f706f6c6963793d74636220696d615f61707072616973653d666 97820696d615f74656d706c6174655f666d743d6e2d6e677c642d6e677c 7369677c62756620696d615f686173683d736861323536 echo -n -e $VAL | xxd -r -p | sha256sum 0d0b891bb730120d9593799cba1a7b3febf68f2bb81fb1304b0c963f95f6bc58 - I will run it through the code as well, but the shell command should work. Thanks, Prakhar Srivastava ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: Re: 2019-05-24 19:00 ` Re: prakhar srivastava @ 2019-05-24 19:15 ` Mimi Zohar 0 siblings, 0 replies; 1767+ messages in thread From: Mimi Zohar @ 2019-05-24 19:15 UTC (permalink / raw) To: prakhar srivastava Cc: Roberto Sassu, linux-integrity, linux-security-module, linux-kernel, Matthew Garrett, vgoyal On Fri, 2019-05-24 at 12:00 -0700, prakhar srivastava wrote: > On Fri, May 24, 2019 at 11:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > > >> As mentioned, the first patch description should include a shell > > > >> command for verifying the digest in the kexec boot command line > > > >> measurement list record against /proc/cmdline. This patch description > > > >> should include a shell command showing how to verify the digest based > > > >> on the new field. Should the new field in the ascii measurement list > > > >> be displayed as a string, not hex? > > > > > > > > We should define a new type. If the type is DATA_FMT_STRING, spaces are > > > > replaced with '_'. > > > > > > Or better. Leave it as hex, otherwise there would be a parsing problem > > > if there are spaces in the data for a field. > > > > After making a few changes, the measurement list contains the > > following kexec-cmdline data: > > > > 10 edc32d1e3a5ba7272280a395b6fb56a5ef7c78c3 ima-buf > > sha256:4f43b7db850e > > 88c49dfeffd4b1eb4f021d78033dfb05b07e45eec8d0b45275 > > kexec-cmdline > > 726f6f > > 743d2f6465762f7364613420726f2072642e6c756b732e757569643d6c756b73 > > 2d6637 > > 3633643737632d653236622d343431642d613734652d62363633636334643832 > > 656120 > > 696d615f706f6c6963793d7463627c61707072616973655f746362 > > > > There's probably a better shell command, but the following works to > > verify the digest locally against the /proc/cmdline: > > > > $ echo -n -e `cat /proc/cmdline | sed 's/^.*root=/root=/'` | sha256sum > > 4f43b7db850e88c49dfeffd4b1eb4f021d78033dfb05b07e45eec8d0b4527f65 - > > > > If we leave the "buf" field as ascii-hex, what would the shell command > > look like when verifying the digest based on the "buf" field? > > > > Mimi > > > To quickly test the sha256 i used the my /proc/cmdline > ro quiet splash vt.handoff=1 ima_policy=tcb ima_appraise=fix > ima_template_fmt=n-ng|d-ng|sig|buf ima_hash=sha256 > > export $VAL= > 726f2071756965742073706c6173682076742e68616e646f66663d3120 > 696d615f706f6c6963793d74636220696d615f61707072616973653d666 > 97820696d615f74656d706c6174655f666d743d6e2d6e677c642d6e677c > 7369677c62756620696d615f686173683d736861323536 > > echo -n -e $VAL | xxd -r -p | sha256sum > 0d0b891bb730120d9593799cba1a7b3febf68f2bb81fb1304b0c963f95f6bc58 - > > I will run it through the code as well, but the shell command should work. Yes, that works. sudo cat /sys/kernel/security/integrity/ima/ascii_runtime_measurements | grep kexec-cmdline | cut -d' ' -f 6 | xxd -r -p | sha256sum Mimi ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [GSoC][PATCH v2 3/3] t3600: use helpers to replace test -d/f/e/s <path>
@ 2019-03-05 14:57 Eric Sunshine
2019-03-05 23:38 ` Rohit Ashiwal
0 siblings, 1 reply; 1767+ messages in thread
From: Eric Sunshine @ 2019-03-05 14:57 UTC (permalink / raw)
To: Rohit Ashiwal
Cc: Johannes Schindelin, Christian Couder, Git List, Junio C Hamano,
Thomas Gummerer
On Tue, Mar 5, 2019 at 9:22 AM Rohit Ashiwal <rohit.ashiwal265@gmail.com> wrote:
> I was asking if this patch is good enough to be added to the
> existing code? Does this patch look good?
I didn't review the patch with a critical-enough eye to be able to say
that every change maintains fidelity with the original code. As
mentioned in [1]:
[...] an important reason for limiting the scope of this change
[...] is to ease the burden on people who review your submission.
Large patch series tend to tax reviewers heavily, even (and often)
when repetitive and simple, like replacing `test -d` with
`test_path_is_dir()`. The shorter and more concise a patch series
is, the more likely that it will receive quality reviews.
This patch, due to its length and repetitive nature, falls under the
category of being tedious to review, which makes it all the more
likely that a reviewer will overlook a problem.
And, it's not always obvious at a glance that a change is correct. For
instance, taking a look at the final patch band:
- ! test -d submod &&
- ! test -d submod/subsubmod/.git &&
+ test_path_is_missing submod &&
+ test_path_is_missing submod/subsubmod/.git &&
Superficially, the transformation seems straightforward. However, that
doesn't mean it maintains fidelity with the original or even means the
same thing. To review this change properly requires understanding the
original intent of "! test -d".
The meaning of that expression can vary depending upon the context. Is
it checking that that path is not a directory (but it is okay if a
plain file exists there)? Or does it merely care about existence
(neither directory nor any other type of entry)? If the latter, then
the transformation is probably correct, however, if the former, then
it likely isn't correct. So, understanding the overall context of the
test is important for judging if a particular change is correct, and
many (volunteer) reviewers simply don't have the time to delve that
deeply to make a proper judgment.
[1]: https://public-inbox.org/git/CAPig+cSZZaCT0G3hysmjn_tNvZmYGp=5cXpZHkdphbWXnONSVQ@mail.gmail.com/
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2019-03-05 14:57 [GSoC][PATCH v2 3/3] t3600: use helpers to replace test -d/f/e/s <path> Eric Sunshine @ 2019-03-05 23:38 ` Rohit Ashiwal 0 siblings, 0 replies; 1767+ messages in thread From: Rohit Ashiwal @ 2019-03-05 23:38 UTC (permalink / raw) To: sunshine Cc: Johannes.Schindelin, christian.couder, git, gitster, rohit.ashiwal265, t.gummerer Hey Eric On Tue, 5 Mar 2019 09:57:40 -0500 Eric Sunshine <sunshine@sunshineco.com> wrote: > This patch, due to its length and repetitive nature, falls under the > category of being tedious to review, which makes it all the more > likely that a reviewer will overlook a problem. Yes, I clearly understand that this patch has become too big to review. It will require time to carefully review and reviewers are doing their best to maintain the utmost quality of code. > And, it's not always obvious at a glance that a change is correct. For > instance, taking a look at the final patch band: > > - ! test -d submod && > - ! test -d submod/subsubmod/.git && > + test_path_is_missing submod && > + test_path_is_missing submod/subsubmod/.git && Duy actually confirms that this transformation is correct in this[1] email. (I know that, it was given as an example, but I'll leave the link anyway). Thanks Rohit [1]: https://public-inbox.org/git/CACsJy8BYeLvB7BSM_Jt4vwfGsEBuhaCZfzGPOHe=B=7cvnRwrg@mail.gmail.com/ ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2019-02-19 2:20 Pablo Mancilla 0 siblings, 0 replies; 1767+ messages in thread From: Pablo Mancilla @ 2019-02-19 2:20 UTC (permalink / raw) To: sparclinux Good day, I did send you an email on charity works and I dont know if you got it.Please reach me for updates or let me know if to resend Pablo Mancilla ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2019-02-18 23:41 Pablo Mancilla 0 siblings, 0 replies; 1767+ messages in thread From: Pablo Mancilla @ 2019-02-18 23:41 UTC (permalink / raw) Good day, I did send you an email on charity works and I dont know if you got it.Please reach me for updates or let me know if to resend Pablo Mancilla ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re; @ 2019-02-16 4:17 Richard Wahl 0 siblings, 0 replies; 1767+ messages in thread From: Richard Wahl @ 2019-02-16 4:17 UTC (permalink / raw) To: sparclinux I am Richard Wahl $1,900,000.00USD Has Been Granted To You As A Donation, Kindly reply for claim. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2019-02-16 0:08 Graham Loan Firm 0 siblings, 0 replies; 1767+ messages in thread From: Graham Loan Firm @ 2019-02-16 0:08 UTC (permalink / raw) * Sie brauchen eine Art Darlehen? Brauchen Sie dringend Kredite, um Ihre Schulden zu konsolidieren? Benötigen Sie ein Auto, ein Geschäft oder ein Darlehen, um Rechnungen zu bezahlen? Setzen Sie sich noch heute mit uns in Verbindung und holen Sie sich den Kredit, den Sie benötigen. * * Kontakt Email: grahamloanfirm01@gmail.com BORROWER DETAILS Namen: Adresse: Telefonnummer: Betrag nötig: Dauer: Alter: Sex: * * Email: grahamloanfirm01@gmail.com ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2019-01-23 10:50 Christopher Hagler 2019-01-23 14:16 ` Cody Kratzer 0 siblings, 1 reply; 1767+ messages in thread From: Christopher Hagler @ 2019-01-23 10:50 UTC (permalink / raw) To: git Unsubscribe git Sent from my iPhone ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2019-01-23 10:50 Christopher Hagler @ 2019-01-23 14:16 ` Cody Kratzer 2019-01-23 14:25 ` Re: Thomas Braun ` (2 more replies) 0 siblings, 3 replies; 1767+ messages in thread From: Cody Kratzer @ 2019-01-23 14:16 UTC (permalink / raw) To: Christopher Hagler; +Cc: git I've sent this same email 3 times. I don't think it works. I'm researching this morning how to unsubscribe from this git group. CODY KRATZER WEB DEVELOPMENT MANAGER 866-344-3875 x145 CODY@LIGHTINGNEWYORK.COM M - F 9 - 5:30 On Wed, Jan 23, 2019 at 5:51 AM Christopher Hagler <haglerchristopher@gmail.com> wrote: > > Unsubscribe git > > Sent from my iPhone ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2019-01-23 14:16 ` Cody Kratzer @ 2019-01-23 14:25 ` Thomas Braun 2019-01-23 16:00 ` Re: Christopher Hagler 2019-01-24 17:11 ` Johannes Schindelin 2 siblings, 0 replies; 1767+ messages in thread From: Thomas Braun @ 2019-01-23 14:25 UTC (permalink / raw) To: Cody Kratzer; +Cc: GIT Mailing-list Am 23.01.2019 um 15:16 schrieb Cody Kratzer: > I've sent this same email 3 times. I don't think it works. I'm > researching this morning how to unsubscribe from this git group. Hi Cody, https://git-scm.com/community says to subscribe you should send an email with body content subscribe git to majordomo@vger.kernel.org so maybe sending unsubscribe git to *that* address does unsubscribe you. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2019-01-23 14:16 ` Cody Kratzer 2019-01-23 14:25 ` Re: Thomas Braun @ 2019-01-23 16:00 ` Christopher Hagler 2019-01-23 16:35 ` Randall S. Becker 2019-01-24 17:11 ` Johannes Schindelin 2 siblings, 1 reply; 1767+ messages in thread From: Christopher Hagler @ 2019-01-23 16:00 UTC (permalink / raw) To: Cody Kratzer; +Cc: git Send the email to this address Majordomo@vger.kernel.org and it will work Sent from my iPhone > On Jan 23, 2019, at 8:16 AM, Cody Kratzer <cody@lightingnewyork.com> wrote: > > I've sent this same email 3 times. I don't think it works. I'm > researching this morning how to unsubscribe from this git group. > > CODY KRATZER WEB DEVELOPMENT MANAGER > 866-344-3875 x145 > CODY@LIGHTINGNEWYORK.COM > M - F 9 - 5:30 > > > On Wed, Jan 23, 2019 at 5:51 AM Christopher Hagler > <haglerchristopher@gmail.com> wrote: >> >> Unsubscribe git >> >> Sent from my iPhone ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: 2019-01-23 16:00 ` Re: Christopher Hagler @ 2019-01-23 16:35 ` Randall S. Becker 0 siblings, 0 replies; 1767+ messages in thread From: Randall S. Becker @ 2019-01-23 16:35 UTC (permalink / raw) To: 'Christopher Hagler', 'Cody Kratzer'; +Cc: git On January 23, 2019 11:00, Christopher Hagler wrote: > Send the email to this address > Majordomo@vger.kernel.org and it will work > > On Jan 23, 2019, at 8:16 AM, Cody Kratzer <cody@lightingnewyork.com> > > I've sent this same email 3 times. I don't think it works. I'm > > researching this morning how to unsubscribe from this git group. > > > > CODY KRATZER WEB DEVELOPMENT MANAGER > > 866-344-3875 x145 > > CODY@LIGHTINGNEWYORK.COM > > M - F 9 - 5:30 > > On Wed, Jan 23, 2019 at 5:51 AM Christopher Hagler > > <haglerchristopher@gmail.com> wrote: > >> > >> Unsubscribe git Reference information to the mailing lists are available here: http://vger.kernel.org/vger-lists.html#git ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2019-01-23 14:16 ` Cody Kratzer 2019-01-23 14:25 ` Re: Thomas Braun 2019-01-23 16:00 ` Re: Christopher Hagler @ 2019-01-24 17:11 ` Johannes Schindelin 2 siblings, 0 replies; 1767+ messages in thread From: Johannes Schindelin @ 2019-01-24 17:11 UTC (permalink / raw) To: Cody Kratzer; +Cc: Christopher Hagler, git Hi, don't send this to git@vger.kernel.org. Send it to majordomo@vger.kernel.org instead. Thanks, Johannes On Wed, 23 Jan 2019, Cody Kratzer wrote: > I've sent this same email 3 times. I don't think it works. I'm > researching this morning how to unsubscribe from this git group. > > CODY KRATZER WEB DEVELOPMENT MANAGER > 866-344-3875 x145 > CODY@LIGHTINGNEWYORK.COM > M - F 9 - 5:30 > > > On Wed, Jan 23, 2019 at 5:51 AM Christopher Hagler > <haglerchristopher@gmail.com> wrote: > > > > Unsubscribe git > > > > Sent from my iPhone > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* [PATCH] arch/arm/mm: Remove duplicate header @ 2019-01-07 17:28 Souptick Joarder 2019-01-17 11:23 ` Souptick Joarder 0 siblings, 1 reply; 1767+ messages in thread From: Souptick Joarder @ 2019-01-07 17:28 UTC (permalink / raw) To: linux, mhocko, rppt, akpm Cc: sabyasachi.linux, linux-kernel, linux-arm-kernel, brajeswar.linux Remove duplicate headers which are included twice. Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> --- arch/arm/mm/mmu.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c index f5cc1cc..dde3032 100644 --- a/arch/arm/mm/mmu.c +++ b/arch/arm/mm/mmu.c @@ -23,7 +23,6 @@ #include <asm/sections.h> #include <asm/cachetype.h> #include <asm/fixmap.h> -#include <asm/sections.h> #include <asm/setup.h> #include <asm/smp_plat.h> #include <asm/tlb.h> @@ -36,7 +35,6 @@ #include <asm/mach/arch.h> #include <asm/mach/map.h> #include <asm/mach/pci.h> -#include <asm/fixmap.h> #include "fault.h" #include "mm.h" -- 1.9.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: [PATCH] arch/arm/mm: Remove duplicate header 2019-01-07 17:28 [PATCH] arch/arm/mm: Remove duplicate header Souptick Joarder @ 2019-01-17 11:23 ` Souptick Joarder 2019-01-17 11:28 ` Mike Rapoport 0 siblings, 1 reply; 1767+ messages in thread From: Souptick Joarder @ 2019-01-17 11:23 UTC (permalink / raw) To: Russell King - ARM Linux, Michal Hocko, rppt, Andrew Morton Cc: Sabyasachi Gupta, linux-kernel, linux-arm-kernel, Brajeswar Ghosh On Mon, Jan 7, 2019 at 10:54 PM Souptick Joarder <jrdr.linux@gmail.com> wrote: > > Remove duplicate headers which are included twice. > > Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Any comment on this patch ? > --- > arch/arm/mm/mmu.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c > index f5cc1cc..dde3032 100644 > --- a/arch/arm/mm/mmu.c > +++ b/arch/arm/mm/mmu.c > @@ -23,7 +23,6 @@ > #include <asm/sections.h> > #include <asm/cachetype.h> > #include <asm/fixmap.h> > -#include <asm/sections.h> > #include <asm/setup.h> > #include <asm/smp_plat.h> > #include <asm/tlb.h> > @@ -36,7 +35,6 @@ > #include <asm/mach/arch.h> > #include <asm/mach/map.h> > #include <asm/mach/pci.h> > -#include <asm/fixmap.h> > > #include "fault.h" > #include "mm.h" > -- > 1.9.1 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH] arch/arm/mm: Remove duplicate header 2019-01-17 11:23 ` Souptick Joarder @ 2019-01-17 11:28 ` Mike Rapoport 2019-01-31 5:54 ` Souptick Joarder 0 siblings, 1 reply; 1767+ messages in thread From: Mike Rapoport @ 2019-01-17 11:28 UTC (permalink / raw) To: Souptick Joarder Cc: Michal Hocko, Sabyasachi Gupta, Russell King - ARM Linux, linux-kernel, rppt, Brajeswar Ghosh, Andrew Morton, linux-arm-kernel On Thu, Jan 17, 2019 at 04:53:44PM +0530, Souptick Joarder wrote: > On Mon, Jan 7, 2019 at 10:54 PM Souptick Joarder <jrdr.linux@gmail.com> wrote: > > > > Remove duplicate headers which are included twice. > > > > Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Acked-by: Mike Rapoport <rppt@linux.ibm.com> > Any comment on this patch ? > > > --- > > arch/arm/mm/mmu.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c > > index f5cc1cc..dde3032 100644 > > --- a/arch/arm/mm/mmu.c > > +++ b/arch/arm/mm/mmu.c > > @@ -23,7 +23,6 @@ > > #include <asm/sections.h> > > #include <asm/cachetype.h> > > #include <asm/fixmap.h> > > -#include <asm/sections.h> > > #include <asm/setup.h> > > #include <asm/smp_plat.h> > > #include <asm/tlb.h> > > @@ -36,7 +35,6 @@ > > #include <asm/mach/arch.h> > > #include <asm/mach/map.h> > > #include <asm/mach/pci.h> > > -#include <asm/fixmap.h> > > > > #include "fault.h" > > #include "mm.h" > > -- > > 1.9.1 > > > -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH] arch/arm/mm: Remove duplicate header 2019-01-17 11:28 ` Mike Rapoport @ 2019-01-31 5:54 ` Souptick Joarder 2019-01-31 12:58 ` Vladimir Murzin 0 siblings, 1 reply; 1767+ messages in thread From: Souptick Joarder @ 2019-01-31 5:54 UTC (permalink / raw) To: Mike Rapoport Cc: Michal Hocko, Sabyasachi Gupta, Russell King - ARM Linux, linux-kernel, rppt, Brajeswar Ghosh, Andrew Morton, linux-arm-kernel On Thu, Jan 17, 2019 at 4:58 PM Mike Rapoport <rppt@linux.ibm.com> wrote: > > On Thu, Jan 17, 2019 at 04:53:44PM +0530, Souptick Joarder wrote: > > On Mon, Jan 7, 2019 at 10:54 PM Souptick Joarder <jrdr.linux@gmail.com> wrote: > > > > > > Remove duplicate headers which are included twice. > > > > > > Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> > > Acked-by: Mike Rapoport <rppt@linux.ibm.com> > > > Any comment on this patch ? If no further comment, can we get this patch in queue for 5.1 ? > > > > > --- > > > arch/arm/mm/mmu.c | 2 -- > > > 1 file changed, 2 deletions(-) > > > > > > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c > > > index f5cc1cc..dde3032 100644 > > > --- a/arch/arm/mm/mmu.c > > > +++ b/arch/arm/mm/mmu.c > > > @@ -23,7 +23,6 @@ > > > #include <asm/sections.h> > > > #include <asm/cachetype.h> > > > #include <asm/fixmap.h> > > > -#include <asm/sections.h> > > > #include <asm/setup.h> > > > #include <asm/smp_plat.h> > > > #include <asm/tlb.h> > > > @@ -36,7 +35,6 @@ > > > #include <asm/mach/arch.h> > > > #include <asm/mach/map.h> > > > #include <asm/mach/pci.h> > > > -#include <asm/fixmap.h> > > > > > > #include "fault.h" > > > #include "mm.h" > > > -- > > > 1.9.1 > > > > > > > -- > Sincerely yours, > Mike. > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2019-01-31 5:54 ` Souptick Joarder @ 2019-01-31 12:58 ` Vladimir Murzin 2019-02-01 12:32 ` Re: Souptick Joarder 0 siblings, 1 reply; 1767+ messages in thread From: Vladimir Murzin @ 2019-01-31 12:58 UTC (permalink / raw) To: Souptick Joarder, Mike Rapoport Cc: Michal Hocko, Sabyasachi Gupta, linux-kernel, Russell King - ARM Linux, rppt, Brajeswar Ghosh, Andrew Morton, linux-arm-kernel Hi Souptick, On 1/31/19 5:54 AM, Souptick Joarder wrote: > On Thu, Jan 17, 2019 at 4:58 PM Mike Rapoport <rppt@linux.ibm.com> wrote: >> >> On Thu, Jan 17, 2019 at 04:53:44PM +0530, Souptick Joarder wrote: >>> On Mon, Jan 7, 2019 at 10:54 PM Souptick Joarder <jrdr.linux@gmail.com> wrote: >>>> >>>> Remove duplicate headers which are included twice. >>>> >>>> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> >> >> Acked-by: Mike Rapoport <rppt@linux.ibm.com> >> >>> Any comment on this patch ? > > If no further comment, can we get this patch in queue for 5.1 ? I'd be nice to use proper tags in subject line. I'd suggest [PATCH] ARM: mm: Remove duplicate header but you can get some inspiration form git log --oneline --no-merges arch/arm/mm/ In case you want to route it via ARM tree you need to drop it into Russell's patch system [1]. [1] https://www.armlinux.org.uk/developer/patches/ Cheers Vladimir _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2019-01-31 12:58 ` Vladimir Murzin @ 2019-02-01 12:32 ` Souptick Joarder 2019-02-01 12:36 ` Re: Vladimir Murzin 0 siblings, 1 reply; 1767+ messages in thread From: Souptick Joarder @ 2019-02-01 12:32 UTC (permalink / raw) To: Vladimir Murzin Cc: Michal Hocko, Sabyasachi Gupta, Russell King - ARM Linux, linux-kernel, rppt, Brajeswar Ghosh, Andrew Morton, Mike Rapoport, linux-arm-kernel On Thu, Jan 31, 2019 at 6:28 PM Vladimir Murzin <vladimir.murzin@arm.com> wrote: > > Hi Souptick, > > On 1/31/19 5:54 AM, Souptick Joarder wrote: > > On Thu, Jan 17, 2019 at 4:58 PM Mike Rapoport <rppt@linux.ibm.com> wrote: > >> > >> On Thu, Jan 17, 2019 at 04:53:44PM +0530, Souptick Joarder wrote: > >>> On Mon, Jan 7, 2019 at 10:54 PM Souptick Joarder <jrdr.linux@gmail.com> wrote: > >>>> > >>>> Remove duplicate headers which are included twice. > >>>> > >>>> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> > >> > >> Acked-by: Mike Rapoport <rppt@linux.ibm.com> > >> > >>> Any comment on this patch ? > > > > If no further comment, can we get this patch in queue for 5.1 ? > > I'd be nice to use proper tags in subject > line. I'd suggest > > [PATCH] ARM: mm: Remove duplicate header > > but you can get some inspiration form > > git log --oneline --no-merges arch/arm/mm/ > > In case you want to route it via ARM tree you need to drop it into > Russell's patch system [1]. How to drop it to Russell's patch system other than posting it to mailing list ? I don't know. > > [1] https://www.armlinux.org.uk/developer/patches/ > > Cheers > Vladimir _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2019-02-01 12:32 ` Re: Souptick Joarder @ 2019-02-01 12:36 ` Vladimir Murzin 2019-02-01 12:41 ` Re: Souptick Joarder 0 siblings, 1 reply; 1767+ messages in thread From: Vladimir Murzin @ 2019-02-01 12:36 UTC (permalink / raw) To: Souptick Joarder Cc: Michal Hocko, Sabyasachi Gupta, Russell King - ARM Linux, linux-kernel, rppt, Brajeswar Ghosh, Andrew Morton, Mike Rapoport, linux-arm-kernel On 2/1/19 12:32 PM, Souptick Joarder wrote: > On Thu, Jan 31, 2019 at 6:28 PM Vladimir Murzin <vladimir.murzin@arm.com> wrote: >> >> Hi Souptick, >> >> On 1/31/19 5:54 AM, Souptick Joarder wrote: >>> On Thu, Jan 17, 2019 at 4:58 PM Mike Rapoport <rppt@linux.ibm.com> wrote: >>>> >>>> On Thu, Jan 17, 2019 at 04:53:44PM +0530, Souptick Joarder wrote: >>>>> On Mon, Jan 7, 2019 at 10:54 PM Souptick Joarder <jrdr.linux@gmail.com> wrote: >>>>>> >>>>>> Remove duplicate headers which are included twice. >>>>>> >>>>>> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> >>>> >>>> Acked-by: Mike Rapoport <rppt@linux.ibm.com> >>>> >>>>> Any comment on this patch ? >>> >>> If no further comment, can we get this patch in queue for 5.1 ? >> >> I'd be nice to use proper tags in subject >> line. I'd suggest >> >> [PATCH] ARM: mm: Remove duplicate header >> >> but you can get some inspiration form >> >> git log --oneline --no-merges arch/arm/mm/ >> >> In case you want to route it via ARM tree you need to drop it into >> Russell's patch system [1]. > > How to drop it to Russell's patch system other than posting it to > mailing list ? I don't know. https://www.armlinux.org.uk/developer/patches/info.php Vladimir >> >> [1] https://www.armlinux.org.uk/developer/patches/ >> >> Cheers >> Vladimir > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2019-02-01 12:36 ` Re: Vladimir Murzin @ 2019-02-01 12:41 ` Souptick Joarder 2019-02-01 13:02 ` Re: Vladimir Murzin 2019-02-01 15:15 ` Re: Russell King - ARM Linux admin 0 siblings, 2 replies; 1767+ messages in thread From: Souptick Joarder @ 2019-02-01 12:41 UTC (permalink / raw) To: Vladimir Murzin Cc: Michal Hocko, Sabyasachi Gupta, Russell King - ARM Linux, linux-kernel, rppt, Brajeswar Ghosh, Andrew Morton, Mike Rapoport, linux-arm-kernel On Fri, Feb 1, 2019 at 6:06 PM Vladimir Murzin <vladimir.murzin@arm.com> wrote: > > On 2/1/19 12:32 PM, Souptick Joarder wrote: > > On Thu, Jan 31, 2019 at 6:28 PM Vladimir Murzin <vladimir.murzin@arm.com> wrote: > >> > >> Hi Souptick, > >> > >> On 1/31/19 5:54 AM, Souptick Joarder wrote: > >>> On Thu, Jan 17, 2019 at 4:58 PM Mike Rapoport <rppt@linux.ibm.com> wrote: > >>>> > >>>> On Thu, Jan 17, 2019 at 04:53:44PM +0530, Souptick Joarder wrote: > >>>>> On Mon, Jan 7, 2019 at 10:54 PM Souptick Joarder <jrdr.linux@gmail.com> wrote: > >>>>>> > >>>>>> Remove duplicate headers which are included twice. > >>>>>> > >>>>>> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> > >>>> > >>>> Acked-by: Mike Rapoport <rppt@linux.ibm.com> > >>>> > >>>>> Any comment on this patch ? > >>> > >>> If no further comment, can we get this patch in queue for 5.1 ? > >> > >> I'd be nice to use proper tags in subject > >> line. I'd suggest > >> > >> [PATCH] ARM: mm: Remove duplicate header > >> > >> but you can get some inspiration form > >> > >> git log --oneline --no-merges arch/arm/mm/ > >> > >> In case you want to route it via ARM tree you need to drop it into > >> Russell's patch system [1]. > > > > How to drop it to Russell's patch system other than posting it to > > mailing list ? I don't know. > > https://www.armlinux.org.uk/developer/patches/info.php This link is not reachable. > > Vladimir > > >> > >> [1] https://www.armlinux.org.uk/developer/patches/ > >> > >> Cheers > >> Vladimir > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2019-02-01 12:41 ` Re: Souptick Joarder @ 2019-02-01 13:02 ` Vladimir Murzin 2019-02-01 15:15 ` Re: Russell King - ARM Linux admin 1 sibling, 0 replies; 1767+ messages in thread From: Vladimir Murzin @ 2019-02-01 13:02 UTC (permalink / raw) To: Souptick Joarder Cc: Michal Hocko, Sabyasachi Gupta, Russell King - ARM Linux, linux-kernel, rppt, Brajeswar Ghosh, Andrew Morton, Mike Rapoport, linux-arm-kernel On 2/1/19 12:41 PM, Souptick Joarder wrote: > On Fri, Feb 1, 2019 at 6:06 PM Vladimir Murzin <vladimir.murzin@arm.com> wrote: >> >> On 2/1/19 12:32 PM, Souptick Joarder wrote: >>> On Thu, Jan 31, 2019 at 6:28 PM Vladimir Murzin <vladimir.murzin@arm.com> wrote: >>>> >>>> Hi Souptick, >>>> >>>> On 1/31/19 5:54 AM, Souptick Joarder wrote: >>>>> On Thu, Jan 17, 2019 at 4:58 PM Mike Rapoport <rppt@linux.ibm.com> wrote: >>>>>> >>>>>> On Thu, Jan 17, 2019 at 04:53:44PM +0530, Souptick Joarder wrote: >>>>>>> On Mon, Jan 7, 2019 at 10:54 PM Souptick Joarder <jrdr.linux@gmail.com> wrote: >>>>>>>> >>>>>>>> Remove duplicate headers which are included twice. >>>>>>>> >>>>>>>> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> >>>>>> >>>>>> Acked-by: Mike Rapoport <rppt@linux.ibm.com> >>>>>> >>>>>>> Any comment on this patch ? >>>>> >>>>> If no further comment, can we get this patch in queue for 5.1 ? >>>> >>>> I'd be nice to use proper tags in subject >>>> line. I'd suggest >>>> >>>> [PATCH] ARM: mm: Remove duplicate header >>>> >>>> but you can get some inspiration form >>>> >>>> git log --oneline --no-merges arch/arm/mm/ >>>> >>>> In case you want to route it via ARM tree you need to drop it into >>>> Russell's patch system [1]. >>> >>> How to drop it to Russell's patch system other than posting it to >>> mailing list ? I don't know. >> >> https://www.armlinux.org.uk/developer/patches/info.php > > This link is not reachable. > Bad luck :( Vladimir >> >> Vladimir >> >>>> >>>> [1] https://www.armlinux.org.uk/developer/patches/ >>>> >>>> Cheers >>>> Vladimir >>> >> > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2019-02-01 12:41 ` Re: Souptick Joarder 2019-02-01 13:02 ` Re: Vladimir Murzin @ 2019-02-01 15:15 ` Russell King - ARM Linux admin 2019-02-01 15:22 ` Re: Russell King - ARM Linux admin 1 sibling, 1 reply; 1767+ messages in thread From: Russell King - ARM Linux admin @ 2019-02-01 15:15 UTC (permalink / raw) To: Souptick Joarder Cc: Vladimir Murzin, Sabyasachi Gupta, Michal Hocko, linux-kernel, Mike Rapoport, rppt, Brajeswar Ghosh, Andrew Morton, linux-arm-kernel On Fri, Feb 01, 2019 at 06:11:21PM +0530, Souptick Joarder wrote: > On Fri, Feb 1, 2019 at 6:06 PM Vladimir Murzin <vladimir.murzin@arm.com> wrote: > > > > On 2/1/19 12:32 PM, Souptick Joarder wrote: > > > On Thu, Jan 31, 2019 at 6:28 PM Vladimir Murzin <vladimir.murzin@arm.com> wrote: > > >> > > >> Hi Souptick, > > >> > > >> On 1/31/19 5:54 AM, Souptick Joarder wrote: > > >>> On Thu, Jan 17, 2019 at 4:58 PM Mike Rapoport <rppt@linux.ibm.com> wrote: > > >>>> > > >>>> On Thu, Jan 17, 2019 at 04:53:44PM +0530, Souptick Joarder wrote: > > >>>>> On Mon, Jan 7, 2019 at 10:54 PM Souptick Joarder <jrdr.linux@gmail.com> wrote: > > >>>>>> > > >>>>>> Remove duplicate headers which are included twice. > > >>>>>> > > >>>>>> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> > > >>>> > > >>>> Acked-by: Mike Rapoport <rppt@linux.ibm.com> > > >>>> > > >>>>> Any comment on this patch ? > > >>> > > >>> If no further comment, can we get this patch in queue for 5.1 ? > > >> > > >> I'd be nice to use proper tags in subject > > >> line. I'd suggest > > >> > > >> [PATCH] ARM: mm: Remove duplicate header > > >> > > >> but you can get some inspiration form > > >> > > >> git log --oneline --no-merges arch/arm/mm/ > > >> > > >> In case you want to route it via ARM tree you need to drop it into > > >> Russell's patch system [1]. > > > > > > How to drop it to Russell's patch system other than posting it to > > > mailing list ? I don't know. > > > > https://www.armlinux.org.uk/developer/patches/info.php > > This link is not reachable. In what way? The site is certainly getting hits over ipv4 and ipv6. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2019-02-01 15:15 ` Re: Russell King - ARM Linux admin @ 2019-02-01 15:22 ` Russell King - ARM Linux admin 0 siblings, 0 replies; 1767+ messages in thread From: Russell King - ARM Linux admin @ 2019-02-01 15:22 UTC (permalink / raw) To: Souptick Joarder Cc: Vladimir Murzin, Sabyasachi Gupta, Michal Hocko, linux-kernel, Mike Rapoport, rppt, Brajeswar Ghosh, Andrew Morton, linux-arm-kernel On Fri, Feb 01, 2019 at 03:15:11PM +0000, Russell King - ARM Linux admin wrote: > On Fri, Feb 01, 2019 at 06:11:21PM +0530, Souptick Joarder wrote: > > On Fri, Feb 1, 2019 at 6:06 PM Vladimir Murzin <vladimir.murzin@arm.com> wrote: > > > > > > On 2/1/19 12:32 PM, Souptick Joarder wrote: > > > > On Thu, Jan 31, 2019 at 6:28 PM Vladimir Murzin <vladimir.murzin@arm.com> wrote: > > > >> > > > >> Hi Souptick, > > > >> > > > >> On 1/31/19 5:54 AM, Souptick Joarder wrote: > > > >>> On Thu, Jan 17, 2019 at 4:58 PM Mike Rapoport <rppt@linux.ibm.com> wrote: > > > >>>> > > > >>>> On Thu, Jan 17, 2019 at 04:53:44PM +0530, Souptick Joarder wrote: > > > >>>>> On Mon, Jan 7, 2019 at 10:54 PM Souptick Joarder <jrdr.linux@gmail.com> wrote: > > > >>>>>> > > > >>>>>> Remove duplicate headers which are included twice. > > > >>>>>> > > > >>>>>> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> > > > >>>> > > > >>>> Acked-by: Mike Rapoport <rppt@linux.ibm.com> > > > >>>> > > > >>>>> Any comment on this patch ? > > > >>> > > > >>> If no further comment, can we get this patch in queue for 5.1 ? > > > >> > > > >> I'd be nice to use proper tags in subject > > > >> line. I'd suggest > > > >> > > > >> [PATCH] ARM: mm: Remove duplicate header > > > >> > > > >> but you can get some inspiration form > > > >> > > > >> git log --oneline --no-merges arch/arm/mm/ > > > >> > > > >> In case you want to route it via ARM tree you need to drop it into > > > >> Russell's patch system [1]. > > > > > > > > How to drop it to Russell's patch system other than posting it to > > > > mailing list ? I don't know. > > > > > > https://www.armlinux.org.uk/developer/patches/info.php > > > > This link is not reachable. > > In what way? The site is certainly getting hits over ipv4 and ipv6. Ah, I see - the site is accessible over IPv6 using port 80 only, but port 443 is blocked. Problem is, I can't test IPv6 from "outside", so I rely on people *reporting* when things stop working. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2018-12-21 15:22 kenneth johansson 2018-12-22 8:18 ` Richard Weinberger 0 siblings, 1 reply; 1767+ messages in thread From: kenneth johansson @ 2018-12-21 15:22 UTC (permalink / raw) To: linux-mtd >From 9815710fa078241c683de1b49d9a0c9631502e17 Mon Sep 17 00:00:00 2001 From: Kenneth Johansson <kenjo@kenjo.org> Date: Fri, 21 Dec 2018 15:46:24 +0100 Subject: [PATCH] mtd: rawnand: nandsim: Add support to disable subpage writes. X-IMAPbase: 1545405463 2 Status: O X-UID: 1 This is needed if you try to use an already existing ubifs image that is created for hardware that do not support subpage write. It is not enough that you can select what nandchip to emulate as the subpage support might not exist in the actual nand driver. Signed-off-by: Kenneth Johansson <ken@kenjo.org> --- drivers/mtd/nand/raw/nandsim.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/mtd/nand/raw/nandsim.c b/drivers/mtd/nand/raw/nandsim.c index c452819..858ef30b 100644 --- a/drivers/mtd/nand/raw/nandsim.c +++ b/drivers/mtd/nand/raw/nandsim.c @@ -110,6 +110,7 @@ static unsigned int overridesize = 0; static char *cache_file = NULL; static unsigned int bbt; static unsigned int bch; +static unsigned int no_subpage; static u_char id_bytes[8] = { [0] = CONFIG_NANDSIM_FIRST_ID_BYTE, [1] = CONFIG_NANDSIM_SECOND_ID_BYTE, @@ -142,6 +143,7 @@ module_param(overridesize, uint, 0400); module_param(cache_file, charp, 0400); module_param(bbt, uint, 0400); module_param(bch, uint, 0400); +module_param(no_subpage, uint, 0400); MODULE_PARM_DESC(id_bytes, "The ID bytes returned by NAND Flash 'read ID' command"); MODULE_PARM_DESC(first_id_byte, "The first byte returned by NAND Flash 'read ID' command (manufacturer ID) (obsolete)"); @@ -177,6 +179,7 @@ MODULE_PARM_DESC(cache_file, "File to use to cache nand pages instead of mem MODULE_PARM_DESC(bbt, "0 OOB, 1 BBT with marker in OOB, 2 BBT with marker in data area"); MODULE_PARM_DESC(bch, "Enable BCH ecc and set how many bits should " "be correctable in 512-byte blocks"); +MODULE_PARM_DESC(no_subpage, "Disable use of subpage write"); /* The largest possible page size */ #define NS_LARGEST_PAGE_SIZE 4096 @@ -2260,6 +2263,10 @@ static int __init ns_init_module(void) /* and 'badblocks' parameters to work */ chip->options |= NAND_SKIP_BBTSCAN; + /* turn off subpage to be able to read ubifs images created for hardware without subpage support */ + if (no_subpage) + chip->options |= NAND_NO_SUBPAGE_WRITE; + switch (bbt) { case 2: chip->bbt_options |= NAND_BBT_NO_OOB; -- 2.7.4 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2018-12-21 15:22 kenneth johansson @ 2018-12-22 8:18 ` Richard Weinberger 0 siblings, 0 replies; 1767+ messages in thread From: Richard Weinberger @ 2018-12-22 8:18 UTC (permalink / raw) To: kenneth johansson; +Cc: linux-mtd On Fri, Dec 21, 2018 at 4:24 PM kenneth johansson <kenjo@kenjo.org> wrote: > > From 9815710fa078241c683de1b49d9a0c9631502e17 Mon Sep 17 00:00:00 2001 > From: Kenneth Johansson <kenjo@kenjo.org> > Date: Fri, 21 Dec 2018 15:46:24 +0100 > Subject: [PATCH] mtd: rawnand: nandsim: Add support to disable subpage writes. > X-IMAPbase: 1545405463 2 > Status: O > X-UID: 1 > > This is needed if you try to use an already existing ubifs image that > is created for hardware that do not support subpage write. > > It is not enough that you can select what nandchip to emulate as the > subpage support might not exist in the actual nand driver. Is this really needed? Usually using ubiattach's -O parameter does the trick. -- Thanks, //richard ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE, @ 2018-12-04 2:28 Ms Sharifah Ahmad Mustahfa 0 siblings, 0 replies; 1767+ messages in thread From: Ms Sharifah Ahmad Mustahfa @ 2018-12-04 2:28 UTC (permalink / raw) -- Hello, First of all i will like to apologies for my manner of communication because you do not know me personally, its due to the fact that i have a very important proposal for you. ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <20181130011234.32674-1-axboe@kernel.dk>]
* Re: [not found] <20181130011234.32674-1-axboe@kernel.dk> @ 2018-11-30 2:09 ` Jens Axboe 0 siblings, 0 replies; 1767+ messages in thread From: Jens Axboe @ 2018-11-30 2:09 UTC (permalink / raw) To: linux-block, osandov On 11/29/18 6:12 PM, Jens Axboe wrote: > Three patches here: > > 1) Ensure that we align ->map properly > > 2) v2 of the sbitmap clear cost ammortization. Updated to do a wakeup > check AFTER we're done swapping free/cleared masks. Kept the > separate alignment for ->word, as it is faster in testing. > > 3) Cost reduction of having to do wait queue checks. Ignore this one, see v3 posted. -- Jens Axboe ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE, @ 2018-11-24 14:19 Miss Sharifah Ahmad Mustahfa 0 siblings, 0 replies; 1767+ messages in thread From: Miss Sharifah Ahmad Mustahfa @ 2018-11-24 14:19 UTC (permalink / raw) To: Recipients Hello, First of all i will like to apologies for my manner of communication because you do not know me personally, its due to the fact that i have a very important proposal for you. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE, @ 2018-11-24 14:16 Miss Sharifah Ahmad Mustahfa 0 siblings, 0 replies; 1767+ messages in thread From: Miss Sharifah Ahmad Mustahfa @ 2018-11-24 14:16 UTC (permalink / raw) To: Recipients Hello, First of all i will like to apologies for my manner of communication because you do not know me personally, its due to the fact that i have a very important proposal for you. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE, @ 2018-11-24 14:16 Miss Sharifah Ahmad Mustahfa 0 siblings, 0 replies; 1767+ messages in thread From: Miss Sharifah Ahmad Mustahfa @ 2018-11-24 14:16 UTC (permalink / raw) To: Recipients Hello, First of all i will like to apologies for my manner of communication because you do not know me personally, its due to the fact that i have a very important proposal for you. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE, @ 2018-11-24 14:03 Miss Sharifah Ahmad Mustahfa 0 siblings, 0 replies; 1767+ messages in thread From: Miss Sharifah Ahmad Mustahfa @ 2018-11-24 14:03 UTC (permalink / raw) To: Recipients Hello, First of all i will like to apologies for my manner of communication because you do not know me personally, its due to the fact that i have a very important proposal for you. ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <CAJUWh6qyHerKg=-oaFN+USa10_Aag5+SYjBOeLCX1qM+WcDUwA@mail.gmail.com>]
* Re: [not found] <CAJUWh6qyHerKg=-oaFN+USa10_Aag5+SYjBOeLCX1qM+WcDUwA@mail.gmail.com> @ 2018-11-23 7:52 ` Chris Murphy 2018-11-23 9:34 ` Re: Andy Leadbetter 0 siblings, 1 reply; 1767+ messages in thread From: Chris Murphy @ 2018-11-23 7:52 UTC (permalink / raw) To: andy.leadbetter, Btrfs BTRFS On Thu, Nov 22, 2018 at 11:41 PM Andy Leadbetter <andy.leadbetter@theleadbetters.com> wrote: > > I have a failing 2TB disk that is part of a 4 disk RAID 6 system. I > have added a new 2TB disk to the computer, and started a BTRFS replace > for the old and new disk. The process starts correctly however some > hours into the job, there is an error and kernel oops. relevant log > below. The relevant log is the entire dmesg, not a snippet. It's decently likely there's more than one thing going on here. We also need full output of 'smartctl -x' for all four drives, and also 'smartctl -l scterc' for all four drives, and also 'cat /sys/block/sda/device/timeout' for all four drives. And which bcache mode you're using. The call trace provided is from kernel 4.15 which is sufficiently long ago I think any dev working on raid56 might want to see where it's getting tripped up on something a lot newer, and this is why: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/fs/btrfs/raid56.c?id=v4.19.3&id2=v4.15.1 That's a lot of changes in just the raid56 code between 4.15 and 4.19. And then in you call trace, btrfs_dev_replace_start is found in dev-replace.c which likewise has a lot of changes. But then also, I think 4.15 might still be in the era where it was not recommended to use 'btrfs dev replace' for raid56, only non-raid56. I'm not sure if the problems with device replace were fixed, and if they were fixed kernel or progs side. Anyway, the latest I recall, it was recommended on raid56 to 'btrfs dev add' then 'btrfs dev remove'. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/fs/btrfs/dev-replace.c?id=v4.19.3&id2=v4.15.1 And that's only a few hundred changes for each. Check out inode.c - there are over 2000 changes. > The disks are configured on top of bcache, in 5 arrays with a small > 128GB SSD cache shared. The system in this configuration has worked > perfectly for 3 years, until 2 weeks ago csum errors started > appearing. I have a crashplan backup of all files on the disk, so I > am not concerned about data loss, but I would like to avoid rebuild > the system. btrfs-progs 4.17 still considers raid56 experimental, not for production use. And three years ago, the current upstream kernel released was 4.3 so I'm gonna guess the kernel history of this file system goes back older than that, very close to raid56 code birth. And then adding bcache to this mix just makes it all the more complicated. > > btrfs dev stats shows > [/dev/bcache0].write_io_errs 0 > [/dev/bcache0].read_io_errs 0 > [/dev/bcache0].flush_io_errs 0 > [/dev/bcache0].corruption_errs 0 > [/dev/bcache0].generation_errs 0 > [/dev/bcache1].write_io_errs 0 > [/dev/bcache1].read_io_errs 20 > [/dev/bcache1].flush_io_errs 0 > [/dev/bcache1].corruption_errs 0 > [/dev/bcache1].generation_errs 14 > [/dev/bcache3].write_io_errs 0 > [/dev/bcache3].read_io_errs 0 > [/dev/bcache3].flush_io_errs 0 > [/dev/bcache3].corruption_errs 0 > [/dev/bcache3].generation_errs 19 > [/dev/bcache2].write_io_errs 0 > [/dev/bcache2].read_io_errs 0 > [/dev/bcache2].flush_io_errs 0 > [/dev/bcache2].corruption_errs 0 > [/dev/bcache2].generation_errs 2 3 of 4 drives have at least one generation error. While there are no corruptions reported, generation errors can be really tricky to recover from at all. If only one device had only read errors, this would be a lot less difficult. > I've tried the latest kernel, and the latest tools, but nothing will > allow me to replace, or delete the failed disk. If the file system is mounted, I would try to make a local backup ASAP before you lose the whole volume. Whether it's LVM pool of two drives (linear/concat) with XFS, or if you go with Btrfs -dsingle -mraid1 (also basically a concat) doesn't really matter, but I'd get whatever you can off the drive. I expect avoiding a rebuild in some form or another is very wishful thinking and not very likely. The more changes are made to the file system, repair attempts or otherwise writing to it, decreases the chance of recovery. -- Chris Murphy ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2018-11-23 7:52 ` Chris Murphy @ 2018-11-23 9:34 ` Andy Leadbetter 0 siblings, 0 replies; 1767+ messages in thread From: Andy Leadbetter @ 2018-11-23 9:34 UTC (permalink / raw) To: lists; +Cc: linux-btrfs Will capture all of that this evening, and try it with the latest kernel and tools. Thanks for the input on what info is relevant, with gather it asap. On Fri, 23 Nov 2018 at 07:53, Chris Murphy <lists@colorremedies.com> wrote: > > On Thu, Nov 22, 2018 at 11:41 PM Andy Leadbetter > <andy.leadbetter@theleadbetters.com> wrote: > > > > I have a failing 2TB disk that is part of a 4 disk RAID 6 system. I > > have added a new 2TB disk to the computer, and started a BTRFS replace > > for the old and new disk. The process starts correctly however some > > hours into the job, there is an error and kernel oops. relevant log > > below. > > The relevant log is the entire dmesg, not a snippet. It's decently > likely there's more than one thing going on here. We also need full > output of 'smartctl -x' for all four drives, and also 'smartctl -l > scterc' for all four drives, and also 'cat > /sys/block/sda/device/timeout' for all four drives. And which bcache > mode you're using. > > The call trace provided is from kernel 4.15 which is sufficiently long > ago I think any dev working on raid56 might want to see where it's > getting tripped up on something a lot newer, and this is why: > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/fs/btrfs/raid56.c?id=v4.19.3&id2=v4.15.1 > > That's a lot of changes in just the raid56 code between 4.15 and 4.19. > And then in you call trace, btrfs_dev_replace_start is found in > dev-replace.c which likewise has a lot of changes. But then also, I > think 4.15 might still be in the era where it was not recommended to > use 'btrfs dev replace' for raid56, only non-raid56. I'm not sure if > the problems with device replace were fixed, and if they were fixed > kernel or progs side. Anyway, the latest I recall, it was recommended > on raid56 to 'btrfs dev add' then 'btrfs dev remove'. > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/fs/btrfs/dev-replace.c?id=v4.19.3&id2=v4.15.1 > > And that's only a few hundred changes for each. Check out inode.c - > there are over 2000 changes. > > > > The disks are configured on top of bcache, in 5 arrays with a small > > 128GB SSD cache shared. The system in this configuration has worked > > perfectly for 3 years, until 2 weeks ago csum errors started > > appearing. I have a crashplan backup of all files on the disk, so I > > am not concerned about data loss, but I would like to avoid rebuild > > the system. > > btrfs-progs 4.17 still considers raid56 experimental, not for > production use. And three years ago, the current upstream kernel > released was 4.3 so I'm gonna guess the kernel history of this file > system goes back older than that, very close to raid56 code birth. And > then adding bcache to this mix just makes it all the more complicated. > > > > > > > btrfs dev stats shows > > [/dev/bcache0].write_io_errs 0 > > [/dev/bcache0].read_io_errs 0 > > [/dev/bcache0].flush_io_errs 0 > > [/dev/bcache0].corruption_errs 0 > > [/dev/bcache0].generation_errs 0 > > [/dev/bcache1].write_io_errs 0 > > [/dev/bcache1].read_io_errs 20 > > [/dev/bcache1].flush_io_errs 0 > > [/dev/bcache1].corruption_errs 0 > > [/dev/bcache1].generation_errs 14 > > [/dev/bcache3].write_io_errs 0 > > [/dev/bcache3].read_io_errs 0 > > [/dev/bcache3].flush_io_errs 0 > > [/dev/bcache3].corruption_errs 0 > > [/dev/bcache3].generation_errs 19 > > [/dev/bcache2].write_io_errs 0 > > [/dev/bcache2].read_io_errs 0 > > [/dev/bcache2].flush_io_errs 0 > > [/dev/bcache2].corruption_errs 0 > > [/dev/bcache2].generation_errs 2 > > > 3 of 4 drives have at least one generation error. While there are no > corruptions reported, generation errors can be really tricky to > recover from at all. If only one device had only read errors, this > would be a lot less difficult. > > > > I've tried the latest kernel, and the latest tools, but nothing will > > allow me to replace, or delete the failed disk. > > If the file system is mounted, I would try to make a local backup ASAP > before you lose the whole volume. Whether it's LVM pool of two drives > (linear/concat) with XFS, or if you go with Btrfs -dsingle -mraid1 > (also basically a concat) doesn't really matter, but I'd get whatever > you can off the drive. I expect avoiding a rebuild in some form or > another is very wishful thinking and not very likely. > > The more changes are made to the file system, repair attempts or > otherwise writing to it, decreases the chance of recovery. > > -- > Chris Murphy ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <CACikiw1uNCYKzo9vjG=AZHpARWv-nzkCX=D-aWBssM7vYZrQdQ@mail.gmail.com>]
* Re: [not found] <CACikiw1uNCYKzo9vjG=AZHpARWv-nzkCX=D-aWBssM7vYZrQdQ@mail.gmail.com> @ 2018-11-12 10:09 ` Ravi Kumar 2018-11-15 13:11 ` Re: Ondrej Mosnacek 1 sibling, 0 replies; 1767+ messages in thread From: Ravi Kumar @ 2018-11-12 10:09 UTC (permalink / raw) To: selinux <<Sorry re-sending in plan text >> Hi team , On android- with latest kernels 4.14 we are seeing some denials which seem to be very much genuine to be address . Where kernel is trying to kill its own created process ( might be for maintenance) . These are seen in long Stress testing . But I dont see any one adding such rule in general so the question is do we see any risk which made us not to add such rules ? 1. avc: denied { kill } for pid=2432 comm="irq/66-90b6300." capability=5 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0 2. avc: denied { kill } for pid=69 comm="rcuop/6" capability=5 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0 3. avc: denied { kill } for pid=0 comm="swapper/1" capability=5 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0 4. avc: denied { kill } for pid=4185 comm="kworker/0:4" capability=5 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0 This is self capability any one in kernel context should be able to do such operations I guess. Regards, Ravi ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [not found] <CACikiw1uNCYKzo9vjG=AZHpARWv-nzkCX=D-aWBssM7vYZrQdQ@mail.gmail.com> 2018-11-12 10:09 ` Re: Ravi Kumar @ 2018-11-15 13:11 ` Ondrej Mosnacek 1 sibling, 0 replies; 1767+ messages in thread From: Ondrej Mosnacek @ 2018-11-15 13:11 UTC (permalink / raw) To: nxp.ravi; +Cc: selinux, Paul Moore, Stephen Smalley, SElinux list On Mon, Nov 12, 2018 at 7:56 AM Ravi Kumar <nxp.ravi@gmail.com> wrote: > Hi team , > > On android- with latest kernels 4.14 we are seeing some denials which seem to be very much genuine to be address . Where kernel is trying to kill its own created process ( might be for maintenance) . > These are seen in long Stress testing . But I dont see any one adding such rule in general so the question is do we see any risk which made us not to add such rules ? > > 1. avc: denied { kill } for pid=2432 comm="irq/66-90b6300." capability=5 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0 > 2. avc: denied { kill } for pid=69 comm="rcuop/6" capability=5 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0 > 3. avc: denied { kill } for pid=0 comm="swapper/1" capability=5 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0 > 4. avc: denied { kill } for pid=4185 comm="kworker/0:4" capability=5 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0 > > This is self capability any one in kernel context should be able to do such operations I guess. The reference policy does contain a rule that allows this kind of operations, see: https://github.com/SELinuxProject/refpolicy/blob/master/policy/modules/kernel/kernel.te#L203 It is also present in the Fedora policy on my system: $ sesearch -A -s kernel_t -t kernel_t -c capability -p kill allow kernel_t kernel_t:capability { audit_control audit_write chown dac_override dac_read_search fowner fsetid ipc_lock ipc_owner kill lease linux_immutable mknod net_admin net_bind_service net_broadcast net_raw setfcap setgid setpcap s etuid sys_admin sys_boot sys_chroot sys_nice sys_pacct sys_ptrace sys_rawio sys_resource sys_time sys_tty_config }; Therefore I would say it is perfectly fine to add such rule to your policy as well. Cheers, -- Ondrej Mosnacek <omosnace at redhat dot com> Associate Software Engineer, Security Technologies Red Hat, Inc. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE, @ 2018-11-11 4:20 Miss Juliet Muhammad 0 siblings, 0 replies; 1767+ messages in thread From: Miss Juliet Muhammad @ 2018-11-11 4:20 UTC (permalink / raw) To: Recipients I have a deal for you, in your region. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE, @ 2018-11-06 1:21 Miss Juliet Muhammad 0 siblings, 0 replies; 1767+ messages in thread From: Miss Juliet Muhammad @ 2018-11-06 1:21 UTC (permalink / raw) To: Recipients I have a deal for you, in your region. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re:
@ 2018-10-29 14:20 Beierl, Mark
2018-10-29 14:37 ` Re: Mohanraj B
0 siblings, 1 reply; 1767+ messages in thread
From: Beierl, Mark @ 2018-10-29 14:20 UTC (permalink / raw)
To: Jens Axboe, Mohanraj B, fio@vger.kernel.org
On 2018-10-27, 12:55, "fio-owner@vger.kernel.org on behalf of Jens Axboe" <fio-owner@vger.kernel.org on behalf of axboe@kernel.dk> wrote:
[EXTERNAL EMAIL]
Please report any suspicious attachments, links, or requests for sensitive information.
On 10/26/18 6:54 AM, Mohanraj B wrote:
> Hello,
>
> I am trying to check how option --clocksource works.
>
>
> bash# fio --name job1 --size 10m --clocksource 2
> valid values: gettimeofday Use gettimeofday(2) for timing
> : clock_gettime Use clock_gettime(2) for timing
> : cpu Use CPU private clock
>
> fio: failed parsing clocksource=2
>
> bash# fio --name job1 --size 10m --clocksource gettimeofday(2)
> bash: syntax error near unexpected token `('
>
> Below command works fine.
> bash# fio --name job1 --size 10m --clocksource gettimeofday
>
> It runs without error but quiet not sure how to see the effect of this
> option. also tried other options - clock_gettime, cpu gettimeofday and
> dont see any difference.
>
> Also is there any error in documentation passing gettimeofday(2)
> throws parse error.
The format is 'value' 'help', so you'd want to do:
--clocksource=gettimeofday
for instance.
--
Jens Axboe
Hello, Mohanraj
The help output that you see above states that using --clocksource=gettimeofday will use the gettimeofday function as defined in the man page in the section (2), which is where all the system calls manuals are stored. The (2) is not meant to be part of the command line, it is part of the description of the help text, which tells you where to find more information on what is being used to implement the clocksource.
Hope that helps clarify the help text.
Regards,
Mark
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2018-10-29 14:20 Beierl, Mark @ 2018-10-29 14:37 ` Mohanraj B 0 siblings, 0 replies; 1767+ messages in thread From: Mohanraj B @ 2018-10-29 14:37 UTC (permalink / raw) To: Beierl, Mark; +Cc: Jens Axboe, fio [-- Attachment #1: Type: text/plain, Size: 2053 bytes --] Thanks Axboe and Mark. On Mon 29 Oct, 2018, 7:50 PM Beierl, Mark, <Mark.Beierl@dell.com> wrote: > On 2018-10-27, 12:55, "fio-owner@vger.kernel.org on behalf of Jens Axboe" > <fio-owner@vger.kernel.org on behalf of axboe@kernel.dk> wrote: > > [EXTERNAL EMAIL] > Please report any suspicious attachments, links, or requests for > sensitive information. > > > On 10/26/18 6:54 AM, Mohanraj B wrote: > > Hello, > > > > I am trying to check how option --clocksource works. > > > > > > bash# fio --name job1 --size 10m --clocksource 2 > > valid values: gettimeofday Use gettimeofday(2) for timing > > : clock_gettime Use clock_gettime(2) for timing > > : cpu Use CPU private clock > > > > fio: failed parsing clocksource=2 > > > > bash# fio --name job1 --size 10m --clocksource gettimeofday(2) > > bash: syntax error near unexpected token `(' > > > > Below command works fine. > > bash# fio --name job1 --size 10m --clocksource gettimeofday > > > > It runs without error but quiet not sure how to see the effect of > this > > option. also tried other options - clock_gettime, cpu gettimeofday > and > > dont see any difference. > > > > Also is there any error in documentation passing gettimeofday(2) > > throws parse error. > > The format is 'value' 'help', so you'd want to do: > > --clocksource=gettimeofday > > for instance. > > -- > Jens Axboe > > Hello, Mohanraj > > The help output that you see above states that using > --clocksource=gettimeofday will use the gettimeofday function as defined in > the man page in the section (2), which is where all the system calls > manuals are stored. The (2) is not meant to be part of the command line, > it is part of the description of the help text, which tells you where to > find more information on what is being used to implement the clocksource. > > Hope that helps clarify the help text. > > Regards, > Mark > > > > [-- Attachment #2: Type: text/html, Size: 2895 bytes --] ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2018-10-26 12:54 Mohanraj B
2018-10-27 16:55 ` Jens Axboe
0 siblings, 1 reply; 1767+ messages in thread
From: Mohanraj B @ 2018-10-26 12:54 UTC (permalink / raw)
To: fio
Hello,
I am trying to check how option --clocksource works.
bash# fio --name job1 --size 10m --clocksource 2
valid values: gettimeofday Use gettimeofday(2) for timing
: clock_gettime Use clock_gettime(2) for timing
: cpu Use CPU private clock
fio: failed parsing clocksource=2
bash# fio --name job1 --size 10m --clocksource gettimeofday(2)
bash: syntax error near unexpected token `('
Below command works fine.
bash# fio --name job1 --size 10m --clocksource gettimeofday
It runs without error but quiet not sure how to see the effect of this
option. also tried other options - clock_gettime, cpu gettimeofday and
dont see any difference.
Also is there any error in documentation passing gettimeofday(2)
throws parse error.
Thanks and Regards,
Mohan
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2018-10-26 12:54 Mohanraj B @ 2018-10-27 16:55 ` Jens Axboe 0 siblings, 0 replies; 1767+ messages in thread From: Jens Axboe @ 2018-10-27 16:55 UTC (permalink / raw) To: Mohanraj B, fio On 10/26/18 6:54 AM, Mohanraj B wrote: > Hello, > > I am trying to check how option --clocksource works. > > > bash# fio --name job1 --size 10m --clocksource 2 > valid values: gettimeofday Use gettimeofday(2) for timing > : clock_gettime Use clock_gettime(2) for timing > : cpu Use CPU private clock > > fio: failed parsing clocksource=2 > > bash# fio --name job1 --size 10m --clocksource gettimeofday(2) > bash: syntax error near unexpected token `(' > > Below command works fine. > bash# fio --name job1 --size 10m --clocksource gettimeofday > > It runs without error but quiet not sure how to see the effect of this > option. also tried other options - clock_gettime, cpu gettimeofday and > dont see any difference. > > Also is there any error in documentation passing gettimeofday(2) > throws parse error. The format is 'value' 'help', so you'd want to do: --clocksource=gettimeofday for instance. -- Jens Axboe ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2018-10-08 13:33 Netravnen 2018-10-08 13:34 ` Inderpreet Saini 0 siblings, 1 reply; 1767+ messages in thread From: Netravnen @ 2018-10-08 13:33 UTC (permalink / raw) To: git unsubscribe git ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: 2018-10-08 13:33 Netravnen @ 2018-10-08 13:34 ` Inderpreet Saini 0 siblings, 0 replies; 1767+ messages in thread From: Inderpreet Saini @ 2018-10-08 13:34 UTC (permalink / raw) To: git@vger.kernel.org unsubscribe git ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2018-08-28 17:34 Bills, Jason M
2018-08-28 17:59 ` Brad Bishop
0 siblings, 1 reply; 1767+ messages in thread
From: Bills, Jason M @ 2018-08-28 17:34 UTC (permalink / raw)
To: openbmc@lists.ozlabs.org
I just added a comment to a github discussion about the IPMI SEL and thought I should share it here as well:
I have been working on a proof-of-concept to move the IPMI SEL entries out of D-Bus into journald instead.
Since journald allows custom metadata for log entries, I've thought of having the SEL message logged to the journal and using metadata to store the necessary IPMI info associated with the entry. Here is an example of logging a type 0x02 system event entry to journald:
sd_journal_send("MESSAGE=%s", message.c_str(),
"PRIORITY=%i", selPriority,
"MESSAGE_ID=%s", selMessageId,
"IPMI_SEL_RECORD_ID=%d", recordId,
"IPMI_SEL_RECORD_TYPE=%x", selSystemType,
"IPMI_SEL_GENERATOR_ID=%x", genId,
"IPMI_SEL_SENSOR_PATH=%s", path.c_str(),
"IPMI_SEL_EVENT_DIR=%x", assert,
"IPMI_SEL_DATA=%s", selDataStr,
NULL);
Using journald should allow for scaling to more SEL entries which should also enable us to support more generic IPMI behavior such as the Add SEL command.
-Jason
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2018-08-28 17:34 Bills, Jason M @ 2018-08-28 17:59 ` Brad Bishop 2018-08-28 23:26 ` Bills, Jason M 0 siblings, 1 reply; 1767+ messages in thread From: Brad Bishop @ 2018-08-28 17:59 UTC (permalink / raw) To: Bills, Jason M; +Cc: openbmc@lists.ozlabs.org > On Aug 28, 2018, at 1:34 PM, Bills, Jason M <jason.m.bills@intel.com> wrote: > > I just added a comment to a github discussion about the IPMI SEL and thought I should share it here as well: Can you send a link to the issue? > > I have been working on a proof-of-concept to move the IPMI SEL entries out of D-Bus into journald instead. > > Since journald allows custom metadata for log entries, I've thought of having the SEL message logged to the journal and using metadata to store the necessary IPMI info associated with the entry. Here is an example of logging a type 0x02 system event entry to journald: > > sd_journal_send("MESSAGE=%s", message.c_str(), > "PRIORITY=%i", selPriority, > "MESSAGE_ID=%s", selMessageId, > "IPMI_SEL_RECORD_ID=%d", recordId, > "IPMI_SEL_RECORD_TYPE=%x", selSystemType, > "IPMI_SEL_GENERATOR_ID=%x", genId, > "IPMI_SEL_SENSOR_PATH=%s", path.c_str(), > "IPMI_SEL_EVENT_DIR=%x", assert, > "IPMI_SEL_DATA=%s", selDataStr, > NULL); > Using journald should allow for scaling to more SEL entries which should also enable us to support more generic IPMI behavior such as the Add SEL command. A design point of OpenBMC from day one was to not design it around IPMI. At a glance this feels counter to that goal. I’m not immediately opposed to moving our error logs out of DBus, but can you provide an extendible abstraction? Not everyone uses SEL, or IPMI even. At a minimum please drop the letters ‘ipmi’ and ‘sel’ :-) from the base design, and save those for something that translates to IPMI-speak. As some background, our systems tend towards fewer ‘error logs’ with much more data per log (4-16k), and yes I admit the current design is biased towards that and does not scale when we approach 1000s of small SEL entries. thx - brad > > -Jason ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: 2018-08-28 17:59 ` Brad Bishop @ 2018-08-28 23:26 ` Bills, Jason M 2018-09-04 20:46 ` Brad Bishop 0 siblings, 1 reply; 1767+ messages in thread From: Bills, Jason M @ 2018-08-28 23:26 UTC (permalink / raw) To: Brad Bishop; +Cc: openbmc@lists.ozlabs.org Here is a link to the issue: https://github.com/openbmc/openbmc/issues/3283#issuecomment-414361325. The main things that started this proof-of-concept are that we have requirements to be fully IPMI compliant and to support 4000+ SEL entries. Our attempts to scale the D-Bus logs to that level were not successful, so we started considering directly accessing journald as an alternative. So far, I've been focused only on IPMI SEL, so I hadn't considered extending the change to non-IPMI error logs; however, these IPMI SEL entries should still fit in well as a subset of all other error logs which could also be moved to the journal. My goal is to align with the OpenBMC design and keep anything IPMI-related isolated only to things that care about IPMI. My thinking was that the metadata is a bit like background info, so it is a good place to hide data that only matters to the minority, such as the IPMI-specific data. With this, the IPMI SEL logs can be included among all the existing error logs but still have the metadata for additional IPMI stuff that doesn't matter for anyone else. So, for writing logs: A. non-IPMI error logs can be written as normal B. IPMI SEL entries are written with the IPMI-specific metadata populated For reading logs: A. non-IPMI readers see IPMI SEL entries as normal text logs B. IPMI readers dump just the IPMI SEL entries and get the associated IPMI-specific info from the metadata Thanks, -Jason -----Original Message----- From: Brad Bishop <bradleyb@fuzziesquirrel.com> Sent: Tuesday, August 28, 2018 10:59 AM To: Bills, Jason M <jason.m.bills@intel.com> Cc: openbmc@lists.ozlabs.org Subject: Re: > On Aug 28, 2018, at 1:34 PM, Bills, Jason M <jason.m.bills@intel.com> wrote: > > I just added a comment to a github discussion about the IPMI SEL and thought I should share it here as well: Can you send a link to the issue? > > I have been working on a proof-of-concept to move the IPMI SEL entries out of D-Bus into journald instead. > > Since journald allows custom metadata for log entries, I've thought of having the SEL message logged to the journal and using metadata to store the necessary IPMI info associated with the entry. Here is an example of logging a type 0x02 system event entry to journald: > > sd_journal_send("MESSAGE=%s", message.c_str(), > "PRIORITY=%i", selPriority, > "MESSAGE_ID=%s", selMessageId, > "IPMI_SEL_RECORD_ID=%d", recordId, > "IPMI_SEL_RECORD_TYPE=%x", selSystemType, > "IPMI_SEL_GENERATOR_ID=%x", genId, > "IPMI_SEL_SENSOR_PATH=%s", path.c_str(), > "IPMI_SEL_EVENT_DIR=%x", assert, > "IPMI_SEL_DATA=%s", selDataStr, > NULL); > Using journald should allow for scaling to more SEL entries which should also enable us to support more generic IPMI behavior such as the Add SEL command. A design point of OpenBMC from day one was to not design it around IPMI. At a glance this feels counter to that goal. I’m not immediately opposed to moving our error logs out of DBus, but can you provide an extendible abstraction? Not everyone uses SEL, or IPMI even. At a minimum please drop the letters ‘ipmi’ and ‘sel’ :-) from the base design, and save those for something that translates to IPMI-speak. As some background, our systems tend towards fewer ‘error logs’ with much more data per log (4-16k), and yes I admit the current design is biased towards that and does not scale when we approach 1000s of small SEL entries. thx - brad > > -Jason ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2018-08-28 23:26 ` Bills, Jason M @ 2018-09-04 20:46 ` Brad Bishop 2018-09-04 21:28 ` Re: Ed Tanous 0 siblings, 1 reply; 1767+ messages in thread From: Brad Bishop @ 2018-09-04 20:46 UTC (permalink / raw) To: Bills, Jason M, Deepak Kodihalli; +Cc: openbmc@lists.ozlabs.org > On Aug 28, 2018, at 7:26 PM, Bills, Jason M <jason.m.bills@intel.com> wrote: > > Here is a link to the issue: https://github.com/openbmc/openbmc/issues/3283#issuecomment-414361325. > > The main things that started this proof-of-concept are that we have requirements to be fully IPMI compliant and to support 4000+ SEL entries. Our attempts to scale the D-Bus logs to that level were not successful, so we started considering directly accessing journald as an alternative. > > So far, I've been focused only on IPMI SEL, so I hadn't considered extending the change to non-IPMI error logs; however, these IPMI SEL entries should still fit in well as a subset of all other error logs which could also be moved to the journal. > > My goal is to align with the OpenBMC design and keep anything IPMI-related isolated only to things that care about IPMI. But it seems like you are proposing that every application that wants to make a log needs to have the logic to translate its internal data model to IPMI speak, so it can make a journal call with all the IPMI metadata populated. Am I understanding correctly? That doesn’t seem aligned with keeping IPMI isolated. A concrete example - phosphor-hwmon. How do you intend to figure out something like IPMI_SEL_SENSOR_PATH in the phosphor-hwmon application? Actually it would help quite a bit to understand how each of the fields in your sample below would be determined by an arbitrary dbus application (like phosphor-hwmon). Further, if you expand this approach to further log formats other than SEL, won’t the applications become a mess of translation logic from the applications data mode <-> log format in use? > My thinking was that the metadata is a bit like background info, so it is a good place to hide data that only matters to the minority, such as the IPMI-specific data. With this, the IPMI SEL logs can be included among all the existing error logs but still have the metadata for additional IPMI stuff that doesn't matter for anyone else. > > So, for writing logs: > A. non-IPMI error logs can be written as normal > B. IPMI SEL entries are written with the IPMI-specific metadata populated > > For reading logs: > A. non-IPMI readers see IPMI SEL entries as normal text logs > B. IPMI readers dump just the IPMI SEL entries and get the associated IPMI-specific info from the metadata I’d rather have a single approach that works for everyone; although, I’m not sure how that would look. > > Thanks, > -Jason This is called top posting, please try to avoid when using the mail-list. It makes threaded conversation hard to follow and respond to. thx. > > -----Original Message----- > From: Brad Bishop <bradleyb@fuzziesquirrel.com> > Sent: Tuesday, August 28, 2018 10:59 AM > To: Bills, Jason M <jason.m.bills@intel.com> > Cc: openbmc@lists.ozlabs.org > Subject: Re: > > > >> On Aug 28, 2018, at 1:34 PM, Bills, Jason M <jason.m.bills@intel.com> wrote: >> >> I just added a comment to a github discussion about the IPMI SEL and thought I should share it here as well: > > Can you send a link to the issue? > >> >> I have been working on a proof-of-concept to move the IPMI SEL entries out of D-Bus into journald instead. >> >> Since journald allows custom metadata for log entries, I've thought of having the SEL message logged to the journal and using metadata to store the necessary IPMI info associated with the entry. Here is an example of logging a type 0x02 system event entry to journald: >> >> sd_journal_send("MESSAGE=%s", message.c_str(), >> "PRIORITY=%i", selPriority, >> "MESSAGE_ID=%s", selMessageId, >> "IPMI_SEL_RECORD_ID=%d", recordId, >> "IPMI_SEL_RECORD_TYPE=%x", selSystemType, >> "IPMI_SEL_GENERATOR_ID=%x", genId, >> "IPMI_SEL_SENSOR_PATH=%s", path.c_str(), >> "IPMI_SEL_EVENT_DIR=%x", assert, >> "IPMI_SEL_DATA=%s", selDataStr, >> NULL); >> Using journald should allow for scaling to more SEL entries which should also enable us to support more generic IPMI behavior such as the Add SEL command. > > A design point of OpenBMC from day one was to not design it around IPMI. > At a glance this feels counter to that goal. > > I’m not immediately opposed to moving our error logs out of DBus, but can you provide an extendible abstraction? Not everyone uses SEL, or IPMI even. At a minimum please drop the letters ‘ipmi’ and ‘sel’ :-) from the base design, and save those for something that translates to IPMI-speak. > > As some background, our systems tend towards fewer ‘error logs’ with much more data per log (4-16k), and yes I admit the current design is biased towards that and does not scale when we approach 1000s of small SEL entries. > > thx - brad > >> >> -Jason ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: Re: 2018-09-04 20:46 ` Brad Bishop @ 2018-09-04 21:28 ` Ed Tanous 2018-09-04 22:34 ` Re: Brad Bishop 0 siblings, 1 reply; 1767+ messages in thread From: Ed Tanous @ 2018-09-04 21:28 UTC (permalink / raw) To: openbmc On 09/04/2018 01:46 PM, Brad Bishop wrote: > > But it seems like you are proposing that every application that wants to make > a log needs to have the logic to translate its internal data model to IPMI speak, > so it can make a journal call with all the IPMI metadata populated. Am I > understanding correctly? That doesn’t seem aligned with keeping IPMI isolated. > I think a key here is that not all logs will be implicitly converted to IPMI logs. Having them be identical was the design that we started with, and abandoned because IPMI has some requirements that don't cleanly map from a standard syslog/text style to IPMI. > A concrete example - phosphor-hwmon. How do you intend to figure out something > like IPMI_SEL_SENSOR_PATH in the phosphor-hwmon application? Actually it would > help quite a bit to understand how each of the fields in your sample below would > be determined by an arbitrary dbus application (like phosphor-hwmon). I'm not really understanding the root of the question. If phosphor-hwmon is generating a threshold crossing log that stemmed from the /xyz/openbmc_project/sensors/my_super_awesome_temp_sensor, then it would simply fill that path into the IPMI_SEL_SENSOR_PATH field. This is the same kind of mapping that the associations produce today, but captured in journald instead of the mapper. Our thinking was that we could build either a static library, or a dbus daemon to simplify producing IPMI logs. Because of the IPMI requirements around unique record ids, right now we're leaning toward the dbus interface with a single daemon responsible for IPMI SEL creation. While technically it could be a part of phosphor-logging, we really want it to be easily removable for future platforms that have no need for IPMI, so the thought at this time it to keep it separate. > > Further, if you expand this approach to further log formats other than SEL, > won’t the applications become a mess of translation logic from the applications > data mode <-> log format in use? > I'm not really following this question. Are there other binary log formats that we expect to come in the future that aren't text based, and could just be a journald translation? So far as I know, IPMI SEL is the only one on my road map that has weird requirements, and needs some translation. I don't expect it to be a mess, and I'm running under the assumption that _most_ daemons won't care about or support IPMI given its limitations. You're right, this isn't intended to be a general solution for all binary logging formats, it's intended to be a short term hack while the industry transitions away from IPMI and toward something easier to generate arbitrarily. > > I’d rather have a single approach that works for everyone; although, I’m > not sure how that would look. > The single approach is where we started, and weren't able to come up with anything that even came close to working in a production sense. If you have ideas here on how this could be built that are cleaner than what we're proposing, we're very much interested. > > This is called top posting, please try to avoid when using the mail-list. > It makes threaded conversation hard to follow and respond to. thx. > (Ed beats Jason with very big stick) ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2018-09-04 21:28 ` Re: Ed Tanous @ 2018-09-04 22:34 ` Brad Bishop 2018-09-04 23:18 ` Re: Ed Tanous 0 siblings, 1 reply; 1767+ messages in thread From: Brad Bishop @ 2018-09-04 22:34 UTC (permalink / raw) To: Ed Tanous; +Cc: OpenBMC Maillist, Deepak Kodihalli > On Sep 4, 2018, at 5:28 PM, Ed Tanous <ed.tanous@intel.com> wrote: > > On 09/04/2018 01:46 PM, Brad Bishop wrote: >> But it seems like you are proposing that every application that wants to make >> a log needs to have the logic to translate its internal data model to IPMI speak, >> so it can make a journal call with all the IPMI metadata populated. Am I >> understanding correctly? That doesn’t seem aligned with keeping IPMI isolated. > > I think a key here is that not all logs will be implicitly converted to IPMI logs. Having them be identical was the design that we started with, and abandoned because IPMI has some requirements that don't cleanly map from a standard syslog/text style to IPMI. > > >> A concrete example - phosphor-hwmon. How do you intend to figure out something >> like IPMI_SEL_SENSOR_PATH in the phosphor-hwmon application? Actually it would >> help quite a bit to understand how each of the fields in your sample below would >> be determined by an arbitrary dbus application (like phosphor-hwmon). > > I'm not really understanding the root of the question. If phosphor-hwmon is generating a threshold crossing log that stemmed from the /xyz/openbmc_project/sensors/my_super_awesome_temp_sensor, then it would simply fill that path into the IPMI_SEL_SENSOR_PATH field. ok, then this is my ignorance of IPMI showing. I thought IPMI_SEL_SENSOR_PATH was an IPMI construct... If this is the case then why not just call it SENSOR_PATH? Then other logging formats could use that metadata key without it being weird that it has ‘ipmi_sel’ in the name of it. And can we apply the same logic to the other keys or do some of the other keys have more complicated translation logic (than none at all as in the case of the sensor path) ? > This is the same kind of mapping that the associations produce today, but captured in journald instead of the mapper. > > Our thinking was that we could build either a static library, or a dbus daemon to simplify producing IPMI logs. Because of the IPMI requirements around unique record ids, right now we're leaning toward the dbus interface with a single daemon responsible for IPMI SEL creation. Thats great! This is similar to how the phosphor-logging daemon creates dbus error objects today. Would you mind elaborating on this daemon and its dbus API? I’m guessing it would probably clear up any concerns I have. > While technically it could be a part of phosphor-logging, That isn’t what I was going for. If you plan to implement a (separate) daemon that acts on the journald metadata I think that is right approach too. > we really want it to be easily removable for future platforms that have no need for IPMI, so the thought at this time it to keep it separate. Agreed. > >> Further, if you expand this approach to further log formats other than SEL, >> won’t the applications become a mess of translation logic from the applications >> data mode <-> log format in use? > > I'm not really following this question. Are there other binary log formats that we expect to come in the future that aren't text based, and could just be a journald translation? Yes. We have a binary format called PEL. I doubt anyone would be interested in using it but we need a foundation in OpenBMC that enables us to use it... > So far as I know, IPMI SEL is the only one on my road map that has weird requirements, and needs some translation. Where is the translation happening? In the new ipmi-sel daemon? Or somewhere else? > I don't expect it to be a mess, and I'm running under the assumption that _most_ daemons won't care about or support IPMI given its limitations. Well _all_ daemons already support IPMI SEL today. The problem is just that the implementation doesn’t scale. I’m confused by _most_ daemons wouldn’t support IPMI? > You're right, this isn't intended to be a general solution for all binary logging formats, it's intended to be a short term hack while the industry transitions away from IPMI and toward something easier to generate arbitrarily. > >> I’d rather have a single approach that works for everyone; although, I’m >> not sure how that would look. > The single approach is where we started, and weren't able to come up with anything that even came close to working in a production sense. If you have ideas here on how this could be built that are cleaner than what we're proposing, we're very much interested. I’m still trying to understand what is being proposed. > >> This is called top posting, please try to avoid when using the mail-list. >> It makes threaded conversation hard to follow and respond to. thx. > > (Ed beats Jason with very big stick) ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: Re: 2018-09-04 22:34 ` Re: Brad Bishop @ 2018-09-04 23:18 ` Ed Tanous 2018-09-04 23:42 ` Re: Brad Bishop 0 siblings, 1 reply; 1767+ messages in thread From: Ed Tanous @ 2018-09-04 23:18 UTC (permalink / raw) To: Brad Bishop; +Cc: OpenBMC Maillist, Deepak Kodihalli On 09/04/2018 03:34 PM, Brad Bishop wrote: > > ok, then this is my ignorance of IPMI showing. I thought IPMI_SEL_SENSOR_PATH was > an IPMI construct... > > If this is the case then why not just call it SENSOR_PATH? Then other logging formats > could use that metadata key without it being weird that it has ‘ipmi_sel’ in the name > of it. And can we apply the same logic to the other keys or do some of the other keys > have more complicated translation logic (than none at all as in the case of the sensor > path) ? The thinking was that we would namespace all the parameters using IPMI_SEL to make it clear that was the only place they were used, and to avoid someone else using it inadvertently. With that said, I could understand how it could be confusing. Jason, any objections to un-namespacing the parameters? > > Thats great! This is similar to how the phosphor-logging daemon creates dbus error > objects today. > > Would you mind elaborating on this daemon and its dbus API? I’m guessing it would probably > clear up any concerns I have. > Patches to phosphor-dbus-interfaces for a suggested interface are being put together as we speak. Hopefully that will clarify it a little bit. >> While technically it could be a part of phosphor-logging, > > That isn’t what I was going for. If you plan to implement a (separate) daemon that acts on > the journald metadata I think that is right approach too. > Agreed. >> we really want it to be easily removable for future platforms that have no need for IPMI, so the thought at this time it to keep it separate. > > Agreed. > >> >>> Further, if you expand this approach to further log formats other than SEL, >>> won’t the applications become a mess of translation logic from the applications >>> data mode <-> log format in use? >> >> I'm not really following this question. Are there other binary log formats that we expect to come in the future that aren't text based, and could just be a journald translation? > > Yes. We have a binary format called PEL. I doubt anyone would be interested in using > it but we need a foundation in OpenBMC that enables us to use it... > That makes more sense now. A quick google on PEL makes it look like it could follow a similar model to what we're doing with IPMI by adding the extra metadata to journald when needed, while still producing the string versions for the basic cases. By foundation do you mean shared code? A quick skim of the implementation makes me suspect that there isn't going to be a lot of shared code, although they could share a similar design with a different implementation. >> So far as I know, IPMI SEL is the only one on my road map that has weird requirements, and needs some translation. > > Where is the translation happening? In the new ipmi-sel daemon? Or somewhere else? The translation would happen on the "addSel" IPMI command that gets used in-band by most BIOS implementations. The ipmi-sel daemon will translate the raw bytes to a string, to be used in most modern loggers, along with the IPMI metadata, to be used in IPMI to source the various "get" SEL entry commands. > >> I don't expect it to be a mess, and I'm running under the assumption that _most_ daemons won't care about or support IPMI given its limitations. > > Well _all_ daemons already support IPMI SEL today. The problem is just that the > implementation doesn’t scale. I’m confused by _most_ daemons wouldn’t support > IPMI? > That should've clarified that most daemons won't care about IPMI _SEL_, given the extra calls and metadata that needs to be provided to implement it correctly. My teams intention was to support the minimum subset of SEL that we can for backward compatibility, while providing the advanced logging (journald/syslog/redfish LogService) for a greater level of detail and capability. If this assumption turns out to not be true, and we end up adding IPMI SEL logging to all the daemons, so be it, I think it will still scale, but I really hope that's not the path we go down. >> You're right, this isn't intended to be a general solution for all binary logging formats, it's intended to be a short term hack while the industry transitions away from IPMI and toward something easier to generate arbitrarily. >> >>> I’d rather have a single approach that works for everyone; although, I’m >>> not sure how that would look. >> The single approach is where we started, and weren't able to come up with anything that even came close to working in a production sense. If you have ideas here on how this could be built that are cleaner than what we're proposing, we're very much interested. > > I’m still trying to understand what is being proposed. > >> >>> This is called top posting, please try to avoid when using the mail-list. >>> It makes threaded conversation hard to follow and respond to. thx. >> >> (Ed beats Jason with very big stick) ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2018-09-04 23:18 ` Re: Ed Tanous @ 2018-09-04 23:42 ` Brad Bishop 2018-09-05 21:20 ` Re: Bills, Jason M 0 siblings, 1 reply; 1767+ messages in thread From: Brad Bishop @ 2018-09-04 23:42 UTC (permalink / raw) To: Ed Tanous; +Cc: OpenBMC Maillist, Deepak Kodihalli > On Sep 4, 2018, at 7:18 PM, Ed Tanous <ed.tanous@intel.com> wrote: > > On 09/04/2018 03:34 PM, Brad Bishop wrote: >> ok, then this is my ignorance of IPMI showing. I thought IPMI_SEL_SENSOR_PATH was >> an IPMI construct... >> If this is the case then why not just call it SENSOR_PATH? Then other logging formats >> could use that metadata key without it being weird that it has ‘ipmi_sel’ in the name >> of it. And can we apply the same logic to the other keys or do some of the other keys >> have more complicated translation logic (than none at all as in the case of the sensor >> path) ? > > The thinking was that we would namespace all the parameters using IPMI_SEL to make it clear that was the only place they were used, and to avoid someone else using it inadvertently. > With that said, I could understand how it could be confusing. Jason, any objections to un-namespacing the parameters? Thanks for being flexible on this but lets wait until we are on the same page before changing anything. Why would you want to discourage it from being used in another context? > >> Thats great! This is similar to how the phosphor-logging daemon creates dbus error >> objects today. >> Would you mind elaborating on this daemon and its dbus API? I’m guessing it would probably >> clear up any concerns I have. > > Patches to phosphor-dbus-interfaces for a suggested interface are being put together as we speak. Hopefully that will clarify it a little bit. Great, thank you. > >>> While technically it could be a part of phosphor-logging, >> That isn’t what I was going for. If you plan to implement a (separate) daemon that acts on >> the journald metadata I think that is right approach too. > Agreed. > >>> we really want it to be easily removable for future platforms that have no need for IPMI, so the thought at this time it to keep it separate. >> Agreed. >>> >>>> Further, if you expand this approach to further log formats other than SEL, >>>> won’t the applications become a mess of translation logic from the applications >>>> data mode <-> log format in use? >>> >>> I'm not really following this question. Are there other binary log formats that we expect to come in the future that aren't text based, and could just be a journald translation? >> Yes. We have a binary format called PEL. I doubt anyone would be interested in using >> it but we need a foundation in OpenBMC that enables us to use it... > > That makes more sense now. A quick google on PEL makes it look like it could follow a similar model to what we're doing with IPMI by adding the extra metadata to journald when needed, while still producing the string versions for the basic cases. By foundation do you mean shared code? A quick skim of the implementation makes me suspect that there isn't going to be a lot of shared code, although they could share a similar design with a different implementation. By foundation I simply mean we need a way to support multiple logging formats that doesn’t require every OpenBMC application to know how to translate from its internal data model (usually dbus) to N logging formats. > >>> So far as I know, IPMI SEL is the only one on my road map that has weird requirements, and needs some translation. >> Where is the translation happening? In the new ipmi-sel daemon? Or somewhere else? > > The translation would happen on the "addSel" IPMI command that gets used in-band by most BIOS implementations. The ipmi-sel daemon will translate the raw bytes to a string, to be used in most modern loggers, along with the IPMI metadata, to be used in IPMI to source the various "get" SEL entry commands. That all sounds fine. But what about applications on the BMC creating SELs for their own errors? Do you want to do that? How will that work? > >>> I don't expect it to be a mess, and I'm running under the assumption that _most_ daemons won't care about or support IPMI given its limitations. >> Well _all_ daemons already support IPMI SEL today. The problem is just that the >> implementation doesn’t scale. I’m confused by _most_ daemons wouldn’t support >> IPMI? > > That should've clarified that most daemons won't care about IPMI _SEL_, given the extra calls and metadata that needs to be provided to implement it correctly. My teams intention was to support the minimum subset of SEL that we can for backward compatibility, while providing the advanced logging (journald/syslog/redfish LogService) for a greater level of detail and capability. > If this assumption turns out to not be true, and we end up adding IPMI SEL logging to all the daemons, so be it, I think it will still scale, but I really hope that's not the path we go down. Oh. Does this mean you intend for code like Jason originally proposed to _only_ appear in the ipmi-sel daemon? And not in applications like phosphor-hwmon? ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2018-09-04 23:42 ` Re: Brad Bishop @ 2018-09-05 21:20 ` Bills, Jason M 0 siblings, 0 replies; 1767+ messages in thread From: Bills, Jason M @ 2018-09-05 21:20 UTC (permalink / raw) To: openbmc >>> ok, then this is my ignorance of IPMI showing. I thought IPMI_SEL_SENSOR_PATH was >>> an IPMI construct... >>> If this is the case then why not just call it SENSOR_PATH? Then other logging formats >>> could use that metadata key without it being weird that it has ‘ipmi_sel’ in the name >>> of it. And can we apply the same logic to the other keys or do some of the other keys >>> have more complicated translation logic (than none at all as in the case of the sensor >>> path) ? >> >> The thinking was that we would namespace all the parameters using IPMI_SEL to make it clear that was the only place they were used, and to avoid someone else using it inadvertently. >> With that said, I could understand how it could be confusing. Jason, any objections to un-namespacing the parameters? > > Thanks for being flexible on this but lets wait until we are on the same page before > changing anything. Why would you want to discourage it from being used in another > context? > Except for the sensor path, all of the proposed IPMI metadata is specific for IPMI: "IPMI_SEL_RECORD_ID" = Two byte unique ID number for each SEL entry "IPMI_SEL_RECORD_TYPE" = The type of SEL entry (system or OEM) which determines the definition of the remaining bytes "IPMI_SEL_GENERATOR_ID" = The IPMI Generator ID (usually the IPMB Slave Address) of the SEL entry requester "IPMI_SEL_SENSOR_PATH" = Path of the sensor used to find IPMI data (such as sensor number) for the sensor "IPMI_SEL_EVENT_DIR" = Whether the sensor is asserting or de-asserting "IPMI_SEL_DATA" = Raw binary data included in the SEL entry I named them all as IPMI_SEL as a group so they would be clearly separate and easy to remove in the future. However, if any of the metadata would be useful elsewhere, the names can be more generic. >> >>> Thats great! This is similar to how the phosphor-logging daemon creates dbus error >>> objects today. >>> Would you mind elaborating on this daemon and its dbus API? I’m guessing it would probably >>> clear up any concerns I have. >> >> Patches to phosphor-dbus-interfaces for a suggested interface are being put together as we speak. Hopefully that will clarify it a little bit. > > Great, thank you. > I have pushed a suggestion for the interface here: https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-dbus-interfaces/+/12494/ >> >>>> While technically it could be a part of phosphor-logging, >>> That isn’t what I was going for. If you plan to implement a (separate) daemon that acts on >>> the journald metadata I think that is right approach too. >> Agreed. >> >>>> we really want it to be easily removable for future platforms that have no need for IPMI, so the thought at this time it to keep it separate. >>> Agreed. >>>> >>>>> Further, if you expand this approach to further log formats other than SEL, >>>>> won’t the applications become a mess of translation logic from the applications >>>>> data mode <-> log format in use? >>>> >>>> I'm not really following this question. Are there other binary log formats that we expect to come in the future that aren't text based, and could just be a journald translation? >>> Yes. We have a binary format called PEL. I doubt anyone would be interested in using >>> it but we need a foundation in OpenBMC that enables us to use it... >> >> That makes more sense now. A quick google on PEL makes it look like it could follow a similar model to what we're doing with IPMI by adding the extra metadata to journald when needed, while still producing the string versions for the basic cases. By foundation do you mean shared code? A quick skim of the implementation makes me suspect that there isn't going to be a lot of shared code, although they could share a similar design with a different implementation. > > By foundation I simply mean we need a way to support multiple logging formats that doesn’t > require every OpenBMC application to know how to translate from its internal data model > (usually dbus) to N logging formats. > >> >>>> So far as I know, IPMI SEL is the only one on my road map that has weird requirements, and needs some translation. >>> Where is the translation happening? In the new ipmi-sel daemon? Or somewhere else? >> >> The translation would happen on the "addSel" IPMI command that gets used in-band by most BIOS implementations. The ipmi-sel daemon will translate the raw bytes to a string, to be used in most modern loggers, along with the IPMI metadata, to be used in IPMI to source the various "get" SEL entry commands. > > That all sounds fine. But what about applications on the BMC creating SELs for their > own errors? Do you want to do that? How will that work? > An application on the BMC that needs to create a SEL can call the IpmiSelAdd method to request a new SEL entry in the journal. >> >>>> I don't expect it to be a mess, and I'm running under the assumption that _most_ daemons won't care about or support IPMI given its limitations. >>> Well _all_ daemons already support IPMI SEL today. The problem is just that the >>> implementation doesn’t scale. I’m confused by _most_ daemons wouldn’t support >>> IPMI? >> >> That should've clarified that most daemons won't care about IPMI _SEL_, given the extra calls and metadata that needs to be provided to implement it correctly. My teams intention was to support the minimum subset of SEL that we can for backward compatibility, while providing the advanced logging (journald/syslog/redfish LogService) for a greater level of detail and capability. >> If this assumption turns out to not be true, and we end up adding IPMI SEL logging to all the daemons, so be it, I think it will still scale, but I really hope that's not the path we go down. > > Oh. Does this mean you intend for code like Jason originally proposed to _only_ appear in > the ipmi-sel daemon? And not in applications like phosphor-hwmon? > Yes, the original proposed code: sd_journal_send("MESSAGE=%s", message.c_str(), "PRIORITY=%i", selPriority, "MESSAGE_ID=%s", selMessageId, "IPMI_SEL_RECORD_ID=%d", recordId, "IPMI_SEL_RECORD_TYPE=%x", selSystemType, "IPMI_SEL_GENERATOR_ID=%x", genId, "IPMI_SEL_SENSOR_PATH=%s", path.c_str(), "IPMI_SEL_EVENT_DIR=%x", assert, "IPMI_SEL_DATA=%s", selDataStr, NULL); will only be in the ipmi-sel daemon. Applications like phosphor-hwmon would use the IpmiSelAdd method to request SEL entries. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH v3 2/3] merge: Add merge.renames config setting @ 2018-04-27 0:54 Ben Peart 2018-04-27 18:19 ` Elijah Newren 0 siblings, 1 reply; 1767+ messages in thread From: Ben Peart @ 2018-04-27 0:54 UTC (permalink / raw) To: Elijah Newren, Ben Peart Cc: git@vger.kernel.org, peff@peff.net, gitster@pobox.com, pclouds@gmail.com, vmiklos@frugalware.org, Kevin Willford, Johannes.Schindelin@gmx.de, eckhard.s.maass@googlemail.com On 4/26/2018 6:52 PM, Elijah Newren wrote: > On Thu, Apr 26, 2018 at 1:52 PM, Ben Peart <Ben.Peart@microsoft.com> wrote: > >> +merge.renames:: >> + Whether and how Git detects renames. If set to "false", >> + rename detection is disabled. If set to "true", basic rename >> + detection is enabled. If set to "copies" or "copy", Git will >> + detect copies, as well. Defaults to the value of diff.renames. >> + > > We shouldn't allow users to force copy detection on for merges The > diff side of the code will detect them correctly but the code in > merge-recursive will mishandle the copy pairs. I think fixing it is > somewhere between big can of worms and > it's-a-configuration-that-doesn't-even-make-sense, but it's been a > while since I thought about it. Color me puzzled. :) The consensus was that the default value for merge.renames come from diff.renames. diff.renames supports copy detection which means that merge.renames will inherit that value. My assumption was that is what was intended so when I reimplemented it, I fully implemented it that way. Are you now requesting to only use diff.renames as the default if the value is true or false but not if it is copy? What should happen if diff.renames is actually set to copy? Should merge silently change that to true, display a warning, error out, or something else? Do you have some other behavior for how to handle copy being inherited from diff.renames you'd like to see? Can you write the documentation that clearly explains the exact behavior you want? That would kill two birds with one stone... :) > >> diff --git a/merge-recursive.h b/merge-recursive.h >> index 80d69d1401..0c5f7eff98 100644 >> --- a/merge-recursive.h >> +++ b/merge-recursive.h >> @@ -17,7 +17,8 @@ struct merge_options { >> unsigned renormalize : 1; >> long xdl_opts; >> int verbosity; >> - int detect_rename; >> + int diff_detect_rename; >> + int merge_detect_rename; >> int diff_rename_limit; >> int merge_rename_limit; >> int rename_score; >> @@ -28,6 +29,11 @@ struct merge_options { >> struct hashmap current_file_dir_set; >> struct string_list df_conflict_file_set; >> }; >> +inline int merge_detect_rename(struct merge_options *o) >> +{ >> + return o->merge_detect_rename >= 0 ? o->merge_detect_rename : >> + o->diff_detect_rename >= 0 ? o->diff_detect_rename : 1; >> +} > > Why did you split o->detect_rename into two fields? You then > recombine them in merge_detect_rename(), and after initial setup only > ever access them through that function. Having two fields worries me > that people will accidentally introduce bugs by using one of them > instead of the merge_detect_rename() function. Is there a reason you > decided against having the initial setup just set a single value and > then use it directly? > The setup of this value is split into 3 places that may or may not all get called. The initial values, the values that come from the config settings and then any values passed on the command line. Because the merge value can now inherit from the diff value, you only know the final value after you have received all possible inputs. That makes it necessary to be a calculated value. If you look at diff_rename_limit/merge_rename_limit, detect_rename follow the same pattern for the same reasons. It turns out detect_rename was a little more complex because it is used in 3 different locations (vs just one) which is why I wrapped the inheritance logic into the helper function merge_detect_rename(). ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) 2018-04-27 0:54 [PATCH v3 2/3] merge: Add merge.renames config setting Ben Peart @ 2018-04-27 18:19 ` Elijah Newren 2018-04-30 13:11 ` Ben Peart 0 siblings, 1 reply; 1767+ messages in thread From: Elijah Newren @ 2018-04-27 18:19 UTC (permalink / raw) To: peartben Cc: Ben.Peart, Johannes.Schindelin, eckhard.s.maass, git, gitster, kewillf, pclouds, peff, vmiklos, Elijah Newren From: Elijah Newren <newren@gmail.com> On Thu, Apr 26, 2018 at 5:54 PM, Ben Peart <peartben@gmail.com> wrote: > Can you write the documentation that clearly explains the exact behavior you > want? That would kill two birds with one stone... :) Sure, something like the following is what I envision, and I've tried to include the suggestion from Junio to document the copy behavior in the merge-recursive documentation. -- 8< -- Subject: [PATCH] fixup! merge: Add merge.renames config setting --- Documentation/merge-config.txt | 3 +-- Documentation/merge-strategies.txt | 5 +++-- merge-recursive.c | 8 ++++++++ 3 files changed, 12 insertions(+), 4 deletions(-) diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt index 59848e5634..662c2713ca 100644 --- a/Documentation/merge-config.txt +++ b/Documentation/merge-config.txt @@ -41,8 +41,7 @@ merge.renameLimit:: merge.renames:: Whether and how Git detects renames. If set to "false", rename detection is disabled. If set to "true", basic rename - detection is enabled. If set to "copies" or "copy", Git will - detect copies, as well. Defaults to the value of diff.renames. + detection is enabled. Defaults to the value of diff.renames. merge.renormalize:: Tell Git that canonical representation of files in the diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt index 1e0728aa12..aa66cbe41e 100644 --- a/Documentation/merge-strategies.txt +++ b/Documentation/merge-strategies.txt @@ -23,8 +23,9 @@ recursive:: causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development history. Additionally this can detect and handle merges involving - renames. This is the default merge strategy when - pulling or merging one branch. + renames, but currently cannot make use of detected + copies. This is the default merge strategy when pulling + or merging one branch. + The 'recursive' strategy can take the following options: diff --git a/merge-recursive.c b/merge-recursive.c index 6cc4404144..b618f134d2 100644 --- a/merge-recursive.c +++ b/merge-recursive.c @@ -564,6 +564,14 @@ static struct string_list *get_renames(struct merge_options *o, opts.flags.recursive = 1; opts.flags.rename_empty = 0; opts.detect_rename = merge_detect_rename(o); + /* + * We do not have logic to handle the detection of copies. In + * fact, it may not even make sense to add such logic: would we + * really want a change to a base file to be propagated through + * multiple other files by a merge? + */ + if (opts.detect_rename > DIFF_DETECT_RENAME) + opts.detect_rename = DIFF_DETECT_RENAME; opts.rename_limit = o->merge_rename_limit >= 0 ? o->merge_rename_limit : o->diff_rename_limit >= 0 ? o->diff_rename_limit : 1000; -- 2.17.0.294.g8e3b83c0e3 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2018-04-27 18:19 ` Elijah Newren @ 2018-04-30 13:11 ` Ben Peart 2018-04-30 16:12 ` Re: Elijah Newren 0 siblings, 1 reply; 1767+ messages in thread From: Ben Peart @ 2018-04-30 13:11 UTC (permalink / raw) To: Elijah Newren Cc: Ben.Peart, Johannes.Schindelin, eckhard.s.maass, git, gitster, kewillf, pclouds, peff, vmiklos, Elijah Newren On 4/27/2018 2:19 PM, Elijah Newren wrote: > From: Elijah Newren <newren@gmail.com> > > On Thu, Apr 26, 2018 at 5:54 PM, Ben Peart <peartben@gmail.com> wrote: > >> Can you write the documentation that clearly explains the exact behavior you >> want? That would kill two birds with one stone... :) > > Sure, something like the following is what I envision, and I've tried to > include the suggestion from Junio to document the copy behavior in the > merge-recursive documentation. > > -- 8< -- > Subject: [PATCH] fixup! merge: Add merge.renames config setting > > --- > Documentation/merge-config.txt | 3 +-- > Documentation/merge-strategies.txt | 5 +++-- > merge-recursive.c | 8 ++++++++ > 3 files changed, 12 insertions(+), 4 deletions(-) > > diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt > index 59848e5634..662c2713ca 100644 > --- a/Documentation/merge-config.txt > +++ b/Documentation/merge-config.txt > @@ -41,8 +41,7 @@ merge.renameLimit:: > merge.renames:: > Whether and how Git detects renames. If set to "false", > rename detection is disabled. If set to "true", basic rename > - detection is enabled. If set to "copies" or "copy", Git will > - detect copies, as well. Defaults to the value of diff.renames. > + detection is enabled. Defaults to the value of diff.renames. > > merge.renormalize:: > Tell Git that canonical representation of files in the > diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt > index 1e0728aa12..aa66cbe41e 100644 > --- a/Documentation/merge-strategies.txt > +++ b/Documentation/merge-strategies.txt > @@ -23,8 +23,9 @@ recursive:: > causing mismerges by tests done on actual merge commits > taken from Linux 2.6 kernel development history. > Additionally this can detect and handle merges involving > - renames. This is the default merge strategy when > - pulling or merging one branch. > + renames, but currently cannot make use of detected > + copies. This is the default merge strategy when pulling > + or merging one branch. > + > The 'recursive' strategy can take the following options: > > diff --git a/merge-recursive.c b/merge-recursive.c > index 6cc4404144..b618f134d2 100644 > --- a/merge-recursive.c > +++ b/merge-recursive.c > @@ -564,6 +564,14 @@ static struct string_list *get_renames(struct merge_options *o, > opts.flags.recursive = 1; > opts.flags.rename_empty = 0; > opts.detect_rename = merge_detect_rename(o); > + /* > + * We do not have logic to handle the detection of copies. In > + * fact, it may not even make sense to add such logic: would we > + * really want a change to a base file to be propagated through > + * multiple other files by a merge? > + */ > + if (opts.detect_rename > DIFF_DETECT_RENAME) > + opts.detect_rename = DIFF_DETECT_RENAME; > opts.rename_limit = o->merge_rename_limit >= 0 ? o->merge_rename_limit : > o->diff_rename_limit >= 0 ? o->diff_rename_limit : > 1000; > Thanks Elijah. I've applied this patch and reviewed and tested it. It works and addresses the concerns around the settings inheritance from diff.renames. I still _prefer_ the simpler model that doesn't do the partial inheritance but I can use this model as well. I'm unsure on the protocol here. Should I incorporate this patch and submit a reroll or can it just be applied as is? ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2018-04-30 13:11 ` Ben Peart @ 2018-04-30 16:12 ` Elijah Newren 2018-05-02 14:33 ` Re: Ben Peart 0 siblings, 1 reply; 1767+ messages in thread From: Elijah Newren @ 2018-04-30 16:12 UTC (permalink / raw) To: Ben Peart Cc: Elijah Newren, Ben Peart, Johannes Schindelin, Eckhard Maaß, Git Mailing List, Junio C Hamano, Kevin Willford, Nguyễn Thái Ngọc, Jeff King, Miklos Vajna On Mon, Apr 30, 2018 at 6:11 AM, Ben Peart <peartben@gmail.com> wrote: > On 4/27/2018 2:19 PM, Elijah Newren wrote: >> >> From: Elijah Newren <newren@gmail.com> >> >> On Thu, Apr 26, 2018 at 5:54 PM, Ben Peart <peartben@gmail.com> wrote: >> >>> Can you write the documentation that clearly explains the exact behavior >>> you >>> want? That would kill two birds with one stone... :) >> >> >> Sure, something like the following is what I envision, and I've tried to >> include the suggestion from Junio to document the copy behavior in the >> merge-recursive documentation. >> <snip> > > Thanks Elijah. I've applied this patch and reviewed and tested it. It works > and addresses the concerns around the settings inheritance from > diff.renames. I still _prefer_ the simpler model that doesn't do the > partial inheritance but I can use this model as well. > > I'm unsure on the protocol here. Should I incorporate this patch and submit > a reroll or can it just be applied as is? I suspect you'll want to re-roll anyway, to base your series on en/rename-directory-detection-reboot instead of on master. (Junio plans to merge it down to next, and your series has four different merge conflicts with it.) There are two other loose ends with this series that Junio will need to weigh in on: - I'm obviously a strong proponent of the inherited setting, but Junio may change his mind after reading Dscho's arguments against it (or after reading my arguments for it). - I like the setting as-is, and think we could allow a "copy" setting for merge.renames to specify that the post-merge diffstat should detect copies (not part of your series, but a useful addition I'd like to tackle afterwards). However, Junio had comments in xmqqwox19ohw.fsf@gitster-ct.c.googlers.com about merge.renames handling the scoring as well, like -Xfind-renames. Those sound incompatible to me for a single setting, and I'm unsure if Junio would resolve them the way I do or still feels strongly about the scoring. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2018-04-30 16:12 ` Re: Elijah Newren @ 2018-05-02 14:33 ` Ben Peart 0 siblings, 0 replies; 1767+ messages in thread From: Ben Peart @ 2018-05-02 14:33 UTC (permalink / raw) To: Elijah Newren Cc: Elijah Newren, Ben Peart, Johannes Schindelin, Eckhard Maaß, Git Mailing List, Junio C Hamano, Kevin Willford, Nguyễn Thái Ngọc, Jeff King, Miklos Vajna On 4/30/2018 12:12 PM, Elijah Newren wrote: > On Mon, Apr 30, 2018 at 6:11 AM, Ben Peart <peartben@gmail.com> wrote: >> On 4/27/2018 2:19 PM, Elijah Newren wrote: >>> >>> From: Elijah Newren <newren@gmail.com> >>> >>> On Thu, Apr 26, 2018 at 5:54 PM, Ben Peart <peartben@gmail.com> wrote: >>> >>>> Can you write the documentation that clearly explains the exact behavior >>>> you >>>> want? That would kill two birds with one stone... :) >>> >>> >>> Sure, something like the following is what I envision, and I've tried to >>> include the suggestion from Junio to document the copy behavior in the >>> merge-recursive documentation. >>> > <snip> >> >> Thanks Elijah. I've applied this patch and reviewed and tested it. It works >> and addresses the concerns around the settings inheritance from >> diff.renames. I still _prefer_ the simpler model that doesn't do the >> partial inheritance but I can use this model as well. >> >> I'm unsure on the protocol here. Should I incorporate this patch and submit >> a reroll or can it just be applied as is? > > I suspect you'll want to re-roll anyway, to base your series on > en/rename-directory-detection-reboot instead of on master. (Junio > plans to merge it down to next, and your series has four different > merge conflicts with it.) > > There are two other loose ends with this series that Junio will need > to weigh in on: > > - I'm obviously a strong proponent of the inherited setting, but Junio > may change his mind after reading Dscho's arguments against it (or > after reading my arguments for it). > > - I like the setting as-is, and think we could allow a "copy" setting > for merge.renames to specify that the post-merge diffstat should > detect copies (not part of your series, but a useful addition I'd like > to tackle afterwards). However, Junio had comments in > xmqqwox19ohw.fsf@gitster-ct.c.googlers.com about merge.renames > handling the scoring as well, like -Xfind-renames. Those sound > incompatible to me for a single setting, and I'm unsure if Junio would > resolve them the way I do or still feels strongly about the scoring. > I think this patch series (including Elijah's fixup!) improves the situation from where we were and it provides the necessary functionality to solve the problem I started out to solve. While there are other changes that could be made, I think they should be done in separate follow up patches. I'm happy to reroll this incorporating the fixup! so that we can make progress. Junio, would you prefer I reroll this based on en/rename-directory-detection-reboot or master? ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <CAAEAJfB76xseRqnYQfRihXY6g0Jyqwt8zfddU1W7CXDg3xEFFg@mail.gmail.com>]
* Re: [not found] <CAAEAJfB76xseRqnYQfRihXY6g0Jyqwt8zfddU1W7CXDg3xEFFg@mail.gmail.com> @ 2018-04-02 11:20 ` Ratheendran R 2018-04-02 17:19 ` Re: Steve deRosier 0 siblings, 1 reply; 1767+ messages in thread From: Ratheendran R @ 2018-04-02 11:20 UTC (permalink / raw) To: Ezequiel Garcia; +Cc: backports Hi All, I am doing a mt7601 backport 4.14 on linux 2.6.37 kernel. Now when I build the backorts aganist the 2.6.37 linux build I am getting the below error. 'error: bit-field =E2=80=98<anonymous>=E2=80=99 width not an integer consta= nt' compilation error actuals /home/hitem//software/source/wifi-drivers/backports-4.14-rc2-1/drivers/net/= wireless/mediatek/mt7601u/main.c:181:3: error: bit-field =E2=80=98<anonymous>=E2=80=99 width not an integer constan= t /home/hitem//software/source/wifi-drivers/backports-4.14-rc2-1/drivers/net/= wireless/mediatek/mt7601u/main.c: In function =E2=80=98mt7601u_set_rts_threshold=E2=80=99: /home/hitem//software/source/wifi-drivers/backports-4.14-rc2-1/drivers/net/= wireless/mediatek/mt7601u/main.c:329:2: error: bit-field =E2=80=98<anonymous>=E2=80=99 width not an integer constan= t make[8]: *** [/home/hitem//software/source/wifi-drivers/backports-4.14-rc2-= 1/drivers/net/wireless/mediatek/mt7601u/main.o] Error 1 Can anyone let me know how to fix this. Thanks in Advance. Ratheendran On 3/15/17, Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> wrote: > subscribe backports > -- > To unsubscribe from this list: send the line "unsubscribe backports" in > -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2018-04-02 11:20 ` Re: Ratheendran R @ 2018-04-02 17:19 ` Steve deRosier 2018-04-04 7:31 ` Re: Arend van Spriel 0 siblings, 1 reply; 1767+ messages in thread From: Steve deRosier @ 2018-04-02 17:19 UTC (permalink / raw) To: Ratheendran R; +Cc: Ezequiel Garcia, backports I apologize for the resend... backports ML didn't pick it up because apparently there's no way to set my tablet's email client to NOT send HTML emails. Live and learn. Hi Ratheendran, On Mon, Apr 2, 2018 at 4:21 AM Ratheendran R <ratheendran.s@gmail.com> wrot= e: > > Hi All, > > I am doing a mt7601 backport 4.14 on linux 2.6.37 kernel. > > Now when I build the backorts aganist the 2.6.37 linux build I am > getting the below error. > 'error: bit-field =E2=80=98<anonymous>=E2=80=99 width not an integer cons= tant' > > compilation error actuals > /home/hitem//software/source/wifi-drivers/backports-4.14-rc2-1/drivers/ne= t/wireless/mediatek/mt7601u/main.c:181:3: > error: bit-field =E2=80=98<anonymous>=E2=80=99 width not an integer const= ant > /home/hitem//software/source/wifi-drivers/backports-4.14-rc2-1/drivers/ne= t/wireless/mediatek/mt7601u/main.c: > In function =E2=80=98mt7601u_set_rts_threshold=E2=80=99: > /home/hitem//software/source/wifi-drivers/backports-4.14-rc2-1/drivers/ne= t/wireless/mediatek/mt7601u/main.c:329:2: > error: bit-field =E2=80=98<anonymous>=E2=80=99 width not an integer const= ant > make[8]: *** [/home/hitem//software/source/wifi-drivers/backports-4.14-rc= 2-1/drivers/net/wireless/mediatek/mt7601u/main.o] > Error 1 In order to backport 4.14, I assume you=E2=80=99re using a current backport= s build. I=E2=80=99m sorry to tell you, but the current version of backports isn=E2=80=99t supported to backport that far. The backports wiki say we support only back to 3.0, and IIRC, in more recent descusions, we abandoned support even back that far. Though I honestly don=E2=80=99t recal= l to which version we=E2=80=99re testing for anymore. No one ever likes this answer (including me), but perhaps you might consider upgrading your base kernel release. 2.6.37 was released eight years ago and 37 major version releases happened between there and 4.14. Your version of the kernel is missing support for some major features and gobs of security fixes. It=E2=80=99ll be hard work to push it forward eight years, but once you get there, keeping the kernel up-to-date is pretty easy. You might get it to work against such an old kernel, but it might take a bit of work and ingenuity. Good luck, - Steve -- Steve deRosier Cal-Sierra Consulting LLC https://www.cal-sierra.com/ -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2018-04-02 17:19 ` Re: Steve deRosier @ 2018-04-04 7:31 ` Arend van Spriel 0 siblings, 0 replies; 1767+ messages in thread From: Arend van Spriel @ 2018-04-04 7:31 UTC (permalink / raw) To: Steve deRosier, Ratheendran R; +Cc: Ezequiel Garcia, backports On 4/2/2018 7:19 PM, Steve deRosier wrote: > I apologize for the resend... backports ML didn't pick it up because > apparently there's no way to set my tablet's email client to NOT send > HTML emails. Live and learn. > > Hi Ratheendran, > > On Mon, Apr 2, 2018 at 4:21 AM Ratheendran R <ratheendran.s@gmail.com> wrote: >> >> Hi All, >> >> I am doing a mt7601 backport 4.14 on linux 2.6.37 kernel. >> >> Now when I build the backorts aganist the 2.6.37 linux build I am >> getting the below error. >> 'error: bit-field ‘<anonymous>’ width not an integer constant' >> >> compilation error actuals >> /home/hitem//software/source/wifi-drivers/backports-4.14-rc2-1/drivers/net/wireless/mediatek/mt7601u/main.c:181:3: >> error: bit-field ‘<anonymous>’ width not an integer constant >> /home/hitem//software/source/wifi-drivers/backports-4.14-rc2-1/drivers/net/wireless/mediatek/mt7601u/main.c: >> In function ‘mt7601u_set_rts_threshold’: >> /home/hitem//software/source/wifi-drivers/backports-4.14-rc2-1/drivers/net/wireless/mediatek/mt7601u/main.c:329:2: >> error: bit-field ‘<anonymous>’ width not an integer constant >> make[8]: *** [/home/hitem//software/source/wifi-drivers/backports-4.14-rc2-1/drivers/net/wireless/mediatek/mt7601u/main.o] >> Error 1 > > > In order to backport 4.14, I assume you’re using a current backports > build. I’m sorry to tell you, but the current version of backports > isn’t supported to backport that far. The backports wiki say we > support only back to 3.0, and IIRC, in more recent descusions, we > abandoned support even back that far. Though I honestly don’t recall > to which version we’re testing for anymore. If my recollection is correct we currently support backports to 3.10 and above. Actually, it is in the README. Now the README also refers to the wiki for "more-up-to date" information, but for this particular piece of information that is not true. > No one ever likes this answer (including me), but perhaps you might > consider upgrading your base kernel release. 2.6.37 was released eight > years ago and 37 major version releases happened between there and > 4.14. Your version of the kernel is missing support for some major > features and gobs of security fixes. It’ll be hard work to push it > forward eight years, but once you get there, keeping the kernel > up-to-date is pretty easy. > > You might get it to work against such an old kernel, but it might take > a bit of work and ingenuity. You could try to include mt7601 into a backports-3.14 package, which support backporting to 2.6.26. It depends what ieee80211_hw ops it implements and what linux infrastructure is used. The bitfields stuff would need backporting, which you can probably get from the latest backports package. It is going to be a lot more work to get it going so the easier path is upgrading your kernel. Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <CABxXbAeQTGbiAEaFHK4RUTFGxt0A+KnCCmhJNU9XDivW5=SL-Q@mail.gmail.com>]
* (no subject) [not found] <CABxXbAeQTGbiAEaFHK4RUTFGxt0A+KnCCmhJNU9XDivW5=SL-Q@mail.gmail.com> @ 2018-03-08 18:23 ` Ivan Lapuz 2018-03-08 18:33 ` Tommy Bowditch 2018-03-08 18:36 ` Re: Ibrahim Tachijian 0 siblings, 2 replies; 1767+ messages in thread From: Ivan Lapuz @ 2018-03-08 18:23 UTC (permalink / raw) To: wireguard [-- Attachment #1: Type: text/plain, Size: 90 bytes --] Hi there pls can you help me how to set up correctly for my wireguard interface..thankyou [-- Attachment #2: Type: text/html, Size: 112 bytes --] ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2018-03-08 18:23 ` Ivan Lapuz @ 2018-03-08 18:33 ` Tommy Bowditch 2018-03-08 18:36 ` Re: Ibrahim Tachijian 1 sibling, 0 replies; 1767+ messages in thread From: Tommy Bowditch @ 2018-03-08 18:33 UTC (permalink / raw) To: Ivan Lapuz; +Cc: wireguard [-- Attachment #1: Type: text/plain, Size: 390 bytes --] What step do you need help with? What are you stuck on? T On Thu, Mar 8, 2018 at 6:23 PM, Ivan Lapuz <ivanlapuz9@gmail.com> wrote: > Hi there pls can you help me how to set up correctly for my wireguard > interface..thankyou > > _______________________________________________ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard > > [-- Attachment #2: Type: text/html, Size: 897 bytes --] ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2018-03-08 18:23 ` Ivan Lapuz 2018-03-08 18:33 ` Tommy Bowditch @ 2018-03-08 18:36 ` Ibrahim Tachijian 1 sibling, 0 replies; 1767+ messages in thread From: Ibrahim Tachijian @ 2018-03-08 18:36 UTC (permalink / raw) To: Ivan Lapuz; +Cc: wireguard [-- Attachment #1: Type: text/plain, Size: 413 bytes --] Sure we can. You can follow the instructions here: https://www.wireguard.com/quickstart/ On Thu, Mar 8, 2018, 19:26 Ivan Lapuz <ivanlapuz9@gmail.com> wrote: > Hi there pls can you help me how to set up correctly for my wireguard > interface..thankyou > _______________________________________________ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard > [-- Attachment #2: Type: text/html, Size: 1005 bytes --] ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <[PATCH xf86-video-amdgpu 0/3] Add non-desktop and leasing support>]
* (unknown), [not found] <[PATCH xf86-video-amdgpu 0/3] Add non-desktop and leasing support> @ 2018-03-03 4:49 ` Keith Packard [not found] ` <20180303044931.6902-1-keithp-aN4HjG94KOLQT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 1767+ messages in thread From: Keith Packard @ 2018-03-03 4:49 UTC (permalink / raw) To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW Cc: michel-otUistvHUpPR7s880joybQ, keithp-aN4HjG94KOLQT0dZR+AlfA Here are the patches to the modesetting driver amended for the amdgpu driver. -keith _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <20180303044931.6902-1-keithp-aN4HjG94KOLQT0dZR+AlfA@public.gmane.org>]
* Re: [not found] ` <20180303044931.6902-1-keithp-aN4HjG94KOLQT0dZR+AlfA@public.gmane.org> @ 2018-03-05 10:02 ` Michel Dänzer [not found] ` <82fc592b-f680-c663-1a0f-7b522ca932d2-otUistvHUpPR7s880joybQ@public.gmane.org> 0 siblings, 1 reply; 1767+ messages in thread From: Michel Dänzer @ 2018-03-05 10:02 UTC (permalink / raw) To: Keith Packard; +Cc: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW On 2018-03-03 05:49 AM, Keith Packard wrote: > Here are the patches to the modesetting driver amended for the amdgpu > driver. Thanks for the patches. Unfortunately, since this driver still has to compile and work with xserver >= 1.13, at least patches 1 & 3 cannot be applied as is. I was going to port these and take care of that anyway, though I might not get around to it before April. If it can't wait that long, I can give you details about what needs to be done. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <82fc592b-f680-c663-1a0f-7b522ca932d2-otUistvHUpPR7s880joybQ@public.gmane.org>]
* Re: [not found] ` <82fc592b-f680-c663-1a0f-7b522ca932d2-otUistvHUpPR7s880joybQ@public.gmane.org> @ 2018-03-05 16:41 ` Keith Packard 0 siblings, 0 replies; 1767+ messages in thread From: Keith Packard @ 2018-03-05 16:41 UTC (permalink / raw) To: Michel Dänzer; +Cc: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW [-- Attachment #1.1: Type: text/plain, Size: 749 bytes --] Michel Dänzer <michel-otUistvHUpPR7s880joybQ@public.gmane.org> writes: > On 2018-03-03 05:49 AM, Keith Packard wrote: >> Here are the patches to the modesetting driver amended for the amdgpu >> driver. > > Thanks for the patches. Unfortunately, since this driver still has to > compile and work with xserver >= 1.13, at least patches 1 & 3 cannot be > applied as is. > > I was going to port these and take care of that anyway, though I might > not get around to it before April. If it can't wait that long, I can > give you details about what needs to be done. I'm good with that -- I needed this to test amdgpu vs modesetting for some applications, and just having the patches with support is good enough for me. -- -keith [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] [-- Attachment #2: Type: text/plain, Size: 154 bytes --] _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [Outreachy kernel] Help with Mutt @ 2018-03-02 18:01 Julia Lawall 2018-03-03 18:27 ` Nishka Dasgupta 0 siblings, 1 reply; 1767+ messages in thread From: Julia Lawall @ 2018-03-02 18:01 UTC (permalink / raw) To: Nishka Dasgupta; +Cc: outreachy-kernel On Fri, 2 Mar 2018, Nishka Dasgupta wrote: > This is with response to your email: I think you will need to give more > information. Do you get some error message? Does nothing happen? Does it > crash? What did you do before, in terms of setting up configuration > files? etc. Any particular thing about the situation that you can think > of. > > My response to your email is as follows: I followed the instructions at > OutreachyfirstpatchSetup and Outreachyfirstpatch at Linux kernel > newbies. The instructions said to "say 'no' to creating an inbox for > now". That is what I did. If I send an email to myself from within mutt > (using the "m" command) it shows up in the inbox; but no other email > sent to my account is visible. (Up until now I have been viewing emails > and responses in a browser and composing replies in vim.) > > In accordance with the instructions, my muttrc file contains the > following lines: > set sendmail="/usr/bin/esmtp" > set envelope_from=yes > set from="Nishka Dasgupta <nishka....ashoka.edu.in>" > set use_from=yes > set edit_headers=yes > > My smtp and git appear to be set up fine, since those are how I have > been sending emails so far. However, I don't know how to ensure that > emails sent to my email account show up in mutt. How can I address this? Maybe this will be helpful: https://www.linux.com/news/fetching-email-mutt julia > > Thank you for your time. > > Regards, > Nishka Dasgupta > > -- > You received this message because you are subscribed to the Google Groups "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@googlegroups.com. > To post to this group, send email to outreachy-kernel@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/1519937773-28053-1-git-send-email-nishka.dasgupta_ug18%40ashoka.edu.in. > For more options, visit https://groups.google.com/d/optout. > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2018-03-02 18:01 [Outreachy kernel] Help with Mutt Julia Lawall @ 2018-03-03 18:27 ` Nishka Dasgupta 2018-03-03 18:38 ` Re: Julia Lawall 0 siblings, 1 reply; 1767+ messages in thread From: Nishka Dasgupta @ 2018-03-03 18:27 UTC (permalink / raw) To: julia.lawall, outreachy-kernel This is with reference to your link with instructions on how to load my inbox in mutt. The instructions worked and I should be able to access all future correspondence in mutt. (The most recent emails, however, failed to load in mutt, which is why I am still not replying inline.) Thank you for your help! Regards, Nishka Dasgupta ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2018-03-03 18:27 ` Nishka Dasgupta @ 2018-03-03 18:38 ` Julia Lawall 0 siblings, 0 replies; 1767+ messages in thread From: Julia Lawall @ 2018-03-03 18:38 UTC (permalink / raw) To: Nishka Dasgupta; +Cc: outreachy-kernel On Sat, 3 Mar 2018, Nishka Dasgupta wrote: > This is with reference to your link with instructions on how to load my inbox in mutt. The instructions worked and I should be able to access all future correspondence in mutt. (The most recent emails, however, failed to load in mutt, which is why I am still not replying inline.) OK, it's great that you got the problem solved :) julia ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2018-03-01 21:17 Nishka Dasgupta 0 siblings, 0 replies; 1767+ messages in thread From: Nishka Dasgupta @ 2018-03-01 21:17 UTC (permalink / raw) To: outreachy-kernel, julia.lawall; +Cc: gregkh This is with response to your message that you don't see any spaces in the staging tree. Yes, the commit "remove spaces after typecast to int" was an unnecessary commit since I added the spaces in the first place. This patch was submitted before I read your email regarding not submitting patches to fix the incorrect changes I have proposed. Sorry about that. Will focus on new patches from next time. Thank you for your time, and apologies for the confusion. Regards, Nishka Dasgupta ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [Outreachy kernel] [PATCH v2] staging: ks7010: Remove spaces after typecast to int @ 2018-03-01 20:04 Julia Lawall 2018-03-01 21:20 ` Nishka Dasgupta 0 siblings, 1 reply; 1767+ messages in thread From: Julia Lawall @ 2018-03-01 20:04 UTC (permalink / raw) To: Nishka Dasgupta; +Cc: gregkh, outreachy-kernel On Fri, 2 Mar 2018, Nishka Dasgupta wrote: > Remove spaces after typecast. Issue found with checkpatch. I don't see any spaces in the staging tree. Maybe a previous change of yours added them, or maybe someone else already fixed the issue. julia > > Signed-off-by: Nishka Dasgupta <nishka.dasgupta_ug18@ashoka.edu.in> > --- > Changes in v2: > - Revert to typecasting after removing in version 1. > - Remove space after typecasting. > > drivers/staging/ks7010/ks_wlan_net.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/ks7010/ks_wlan_net.c b/drivers/staging/ks7010/ks_wlan_net.c > index 482af50..91acf87 100644 > --- a/drivers/staging/ks7010/ks_wlan_net.c > +++ b/drivers/staging/ks7010/ks_wlan_net.c > @@ -208,7 +208,7 @@ static int ks_wlan_set_freq(struct net_device *dev, > /* for SLEEP MODE */ > /* If setting by frequency, convert to a channel */ > if ((fwrq->e == 1) && > - (fwrq->m >= (int) 2.412e8) && (fwrq->m <= (int) 2.487e8)) { > + (fwrq->m >= (int)2.412e8) && (fwrq->m <= (int)2.487e8)) { > int f = fwrq->m / 100000; > int c = 0; > > -- > 1.9.1 > > -- > You received this message because you are subscribed to the Google Groups "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@googlegroups.com. > To post to this group, send email to outreachy-kernel@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/1519931110-2763-1-git-send-email-nishka.dasgupta_ug18%40ashoka.edu.in. > For more options, visit https://groups.google.com/d/optout. > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2018-03-01 20:04 [Outreachy kernel] [PATCH v2] staging: ks7010: Remove spaces after typecast to int Julia Lawall @ 2018-03-01 21:20 ` Nishka Dasgupta 0 siblings, 0 replies; 1767+ messages in thread From: Nishka Dasgupta @ 2018-03-01 21:20 UTC (permalink / raw) To: outreachy-kernel, julia.lawall This is with response to your message that you don't see any spaces in the staging tree. Yes, the commit "remove spaces after typecast to int" was an unnecessary commit since I added the spaces in the first place. This patch was submitted before I read your email regarding not submitting patches to fix the incorrect changes I have proposed. Sorry about that. Will focus on new patches from next time. Thank you for your time, and apologies for the confusion. Regards, Nishka Dasgupta ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH v2] staging: vc04_services: bcm2835-camera: Add blank line
@ 2018-03-01 19:33 Greg KH
2018-03-01 20:20 ` Nishka Dasgupta
0 siblings, 1 reply; 1767+ messages in thread
From: Greg KH @ 2018-03-01 19:33 UTC (permalink / raw)
To: Nishka Dasgupta
Cc: eric, stefan.wahren, f.fainelli, rjui, sbranden,
bcm-kernel-feedback-list, outreachy-kernel
On Fri, Mar 02, 2018 at 12:45:48AM +0530, Nishka Dasgupta wrote:
> Checkpatch suggested two warnings for this file in consecutive lines: "static VCHI_CONNECTION_T *vchi_connection;" and "static VCHI_INSTANCE_T vchi_instance;". Both warnings said to add a blank line after the declaration. If checkpatch was wrong, is it okay if I submit a version 2 with a blank line only after "vchi_instance" and not below "*vchi_connection" (effectively undoing one of my commits)?
First off, I have no context as to what you are responding to here,
please always quote the email you are responding to properly. Reviewers
deal with hundreds of emails a day, and not having context for what you
say doesn't really work :(
Also, properly wrap your email lines at 72 columns, your email client
should do this for you, right?
Please respond to the email with the correct context and I will be glad
to respond. Right now, I have no idea what you are referring to.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2018-03-01 19:33 [PATCH v2] staging: vc04_services: bcm2835-camera: Add blank line Greg KH @ 2018-03-01 20:20 ` Nishka Dasgupta 2018-03-01 20:31 ` Re: Greg KH 0 siblings, 1 reply; 1767+ messages in thread From: Nishka Dasgupta @ 2018-03-01 20:20 UTC (permalink / raw) To: gregkh, outreachy-kernel Cc: eric, stefan.wahren, f.fainelli, rjui, sbranden, bcm-kernel-feedback-list This is with reference to your last email pointing out that you have no context for what I am responding to. Unfortunately, I have been unable to get mutt to load my inbox, so I could not and cannot quote text directly. I have done my best to reproduce the conversation below in a coherent fashion; nonetheless, I apologise for any persisting lack of clarity. An hour ago I submitted the following commit with respect to drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c: [PATCH v2] staging: vc04_services: bcm2835-camera: Add blank line Your reply: Checkpatch is wrong here, don't you think? Are you sure this is actually doing what you think it is? My reply: Checkpatch suggested two warnings for this file in consecutive lines: "static VCHI_CONNECTION_T *vchi_connection;" and "static VCHI_INSTANCE_T vchi_instance;". Both warnings said to add a blank line after the declaration. If checkpatch was wrong, is it okay if I submit a version 2 with a blank line only after "vchi_instance" and not below "*vchi_connection" (effectively undoing one of my commits)? Your response: First off, I have no context as to what you are responding to here, please always quote the email you are responding to properly. Reviewers deal with hundreds of emails a day, and not having context for what you say doesn't really work :( Also, properly wrap your email lines at 72 columns, your email client should do this for you, right? Please respond to the email with the correct context and I will be glad to respond. Right now, I have no idea what you are referring to. (I am sorry for the suboptimal formatting. I think I managed to linewrap this email properly, however.) My question remains: may I submit a revised commit that effectively undoes the first "add blank line" commit, i.e. the one that added a line between "static VCHI_CONNECTION_T *vchi_connection" and "static VCHI_INSTANCE_T vchi_instance"? Thank you for your time, and apologies again for the confusion. Regards, Nishka Dasgupta ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2018-03-01 20:20 ` Nishka Dasgupta @ 2018-03-01 20:31 ` Greg KH 2018-03-08 18:23 ` Re: Nishka Dasgupta 0 siblings, 1 reply; 1767+ messages in thread From: Greg KH @ 2018-03-01 20:31 UTC (permalink / raw) To: Nishka Dasgupta Cc: outreachy-kernel, eric, stefan.wahren, f.fainelli, rjui, sbranden, bcm-kernel-feedback-list On Fri, Mar 02, 2018 at 01:50:10AM +0530, Nishka Dasgupta wrote: > This is with reference to your last email pointing out that you have no > context for what I am responding to. Unfortunately, I have been unable > to get mutt to load my inbox, so I could not and cannot quote text > directly. I have done my best to reproduce the conversation below in a > coherent fashion; nonetheless, I apologise for any persisting lack of > clarity. If mutt can't read your inbox, how are you reading it at all? :) > An hour ago I submitted the following commit with respect to > drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c: [PATCH v2] > staging: vc04_services: bcm2835-camera: Add blank line > > Your reply: Checkpatch is wrong here, don't you think? Are you sure this > is actually doing what you think it is? > > My reply: Checkpatch suggested two warnings for this file in consecutive > lines: "static VCHI_CONNECTION_T *vchi_connection;" and "static > VCHI_INSTANCE_T vchi_instance;". Both warnings said to add a blank line > after the declaration. If checkpatch was wrong, is it okay if I submit a > version 2 with a blank line only after "vchi_instance" and not below > "*vchi_connection" (effectively undoing one of my commits)? Look at the code, and see what checkpatch is telling you and see if that actually matches with what the code shows. Then make the change that you know is correct based on your knowledge of C, and how the code should look. Hint, checkpatch is wrong here, but the code is also wrong as-is. thanks, greg k-h ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2018-03-01 20:31 ` Re: Greg KH @ 2018-03-08 18:23 ` Nishka Dasgupta 2018-03-08 18:33 ` Re: Greg KH 0 siblings, 1 reply; 1767+ messages in thread From: Nishka Dasgupta @ 2018-03-08 18:23 UTC (permalink / raw) To: gregkh Cc: outreachy-kernel, eric, stefan.wahren, f.fainelli, rjui, sbranden, bcm-kernel-feedback-list This is with reference to the Patch I submitted for staging/vc04_services/bcm2835-camera: Add blank line. (Since the last message on that thread, I have managed to configure mutt, but several of the more recent emails, however, failed to load in mutt, which is why I am still not replying inline. I should be able to respond to all future emails inline, however.) The last email on the thread ended: > Look at the code, and see what checkpatch is telling you and see if > that actually matches with what the code shows. Then make the change > that you know is correct based on your knowledge of C, and how the > code should look. Hint, checkpatch is wrong here, but the code is also > wrong as-is. > > thanks, greg k-h I am afraid I still have not been able to locate the error. Is it a problem of too many or too few asterisks in the line "static VCHI_CONNECTION_T *vchi_connection"? Thank you for your help! Regards, Nishka Dasgupta ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2018-03-08 18:23 ` Re: Nishka Dasgupta @ 2018-03-08 18:33 ` Greg KH 0 siblings, 0 replies; 1767+ messages in thread From: Greg KH @ 2018-03-08 18:33 UTC (permalink / raw) To: Nishka Dasgupta Cc: outreachy-kernel, eric, stefan.wahren, f.fainelli, rjui, sbranden, bcm-kernel-feedback-list On Thu, Mar 08, 2018 at 11:53:22PM +0530, Nishka Dasgupta wrote: > The last email on the thread ended: > > Look at the code, and see what checkpatch is telling you and see if > > that actually matches with what the code shows. Then make the change > > that you know is correct based on your knowledge of C, and how the > > code should look. Hint, checkpatch is wrong here, but the code is also > > wrong as-is. > > > > thanks, greg k-h > > I am afraid I still have not been able to locate the error. Is it a > problem of too many or too few asterisks in the line "static > VCHI_CONNECTION_T *vchi_connection"? I have no context at all here, to know what you are talking about, and your emails are long-gone from my queue, sorry. That being said, asterisks mean special things in the C language. Be sure you understand what they are, how they work, and when they are needed. Perhaps some more C language experience is needed here before you work on the kernel? thanks, greg k-h ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [Outreachy kernel] Re: 2018-02-27 13:53 ` Nishka Dasgupta @ 2018-02-27 13:58 Julia Lawall 2018-02-27 14:07 ` Re: Nishka Dasgupta -1 siblings, 1 reply; 1767+ messages in thread From: Julia Lawall @ 2018-02-27 13:58 UTC (permalink / raw) To: Nishka Dasgupta; +Cc: outreachy-kernel On Tue, 27 Feb 2018, Nishka Dasgupta wrote: > Hi, > Weren't the original values already integers because of the "e8" appended? > If this was an unnecessary patch, I will try to do better next time. I think that they remain floats. julia > Thanking you, > Nishka Dasgupta > > -- > You received this message because you are subscribed to the Google Groups "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@googlegroups.com. > To post to this group, send email to outreachy-kernel@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/1519739588-3783-1-git-send-email-nishka.dasgupta_ug18%40ashoka.edu.in. > For more options, visit https://groups.google.com/d/optout. > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2018-02-27 13:58 [Outreachy kernel] Re: Julia Lawall @ 2018-02-27 14:07 ` Nishka Dasgupta 0 siblings, 0 replies; 1767+ messages in thread From: Nishka Dasgupta @ 2018-02-27 14:07 UTC (permalink / raw) To: outreachy-kernel Hi, Thank you for the clarification! Regards, Nishka Dasgupta ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [Outreachy kernel] Re: Re: [PATCH] h [Patch] Fixed unnecessary typecasting to in. Error found with checkpatch. Signed-off-by: Nishka Dasgupta <nishka.dasgupta_ug18@ashoka.edu.in>
@ 2018-02-27 13:39 Julia Lawall
2018-02-27 13:53 ` Nishka Dasgupta
0 siblings, 1 reply; 1767+ messages in thread
From: Julia Lawall @ 2018-02-27 13:39 UTC (permalink / raw)
To: Nishka Dasgupta; +Cc: outreachy-kernel
On Tue, 27 Feb 2018, Nishka Dasgupta wrote:
> Hi,
> Thank you for pointing out the formatting errors. I have deleted the unnecessary [Patch] and added the driver information.
> I could not, however, work out how to separate the subject line from the body of the text.
> I sent the commit to the maintainer of the patch in a separate email as I was (and am) not comfortable with git send-email, though I am doing my best to learn. I have sent him the revised patch, however.
> I don't know why a and b are prepended, unless you are referring to the variables that I added, in which case I would like to clarify that I did not want to use names as generic and vague as a and b for the new variables, so I appended part of their respective values after the initial character for ease of understanding. Should I have used more descriptive variable names?
> Finally, I did compile the this particular driver (make path/ as on the website) and an output file was generated for the modified file, so I took that to mean it was working as it should. Was I wrong?
I think that the code is actually better as is. Normally, there are not
floating point numbers in kernel code, so it is nice to see the int cast,
and to see what the numbers are being used for. Checkpatch is not always
correct...
julia
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2018-02-27 13:39 [Outreachy kernel] Re: Re: [PATCH] h [Patch] Fixed unnecessary typecasting to in. Error found with checkpatch. Signed-off-by: Nishka Dasgupta <nishka.dasgupta_ug18@ashoka.edu.in> Julia Lawall @ 2018-02-27 13:53 ` Nishka Dasgupta 0 siblings, 0 replies; 1767+ messages in thread From: Nishka Dasgupta @ 2018-02-27 13:53 UTC (permalink / raw) To: outreachy-kernel Hi, Weren't the original values already integers because of the "e8" appended? If this was an unnecessary patch, I will try to do better next time. Thanking you, Nishka Dasgupta ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2018-02-27 1:18 Alan Gage 2018-02-27 10:26 ` René Scharfe 0 siblings, 1 reply; 1767+ messages in thread From: Alan Gage @ 2018-02-27 1:18 UTC (permalink / raw) To: git Hello, I recently noticed a bug involving GitBash and Python. I was running a function that would post the system time once every second using a while loop but the text was only sent after the while loop ended due to a timer I had set. Essesntially, instead of it being entered every second into the terminal, it was entered all at once, when the loop ended. I tried this with the Command Line, among other things, and it worked as intended, with the text being entered every second. This is on Windows 10 Pro with the Fall Creators Update and the most recent version of GitBash. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2018-02-27 1:18 Alan Gage @ 2018-02-27 10:26 ` René Scharfe 0 siblings, 0 replies; 1767+ messages in thread From: René Scharfe @ 2018-02-27 10:26 UTC (permalink / raw) To: Alan Gage; +Cc: git Am 27.02.2018 um 02:18 schrieb Alan Gage: > Hello, I recently noticed a bug involving GitBash and Python. I was > running a function that would post the system time once every second > using a while loop but the text was only sent after the while loop > ended due to a timer I had set. Essesntially, instead of it being > entered every second into the terminal, it was entered all at once, > when the loop ended. I tried this with the Command Line, among other > things, and it worked as intended, with the text being entered every > second. This is on Windows 10 Pro with the Fall Creators Update and > the most recent version of GitBash. Python buffers its output by default. On terminals it enables line buffering, i.e. the accumulated output is flushed when a newline character is reached. Otherwise it uses a system-dependent buffer size in the range of a few kilobytes. You can check if your output is a terminal e.g. with: python -c "import sys; print(sys.stdout.isatty())" You can disable buffering by running your script with "python -u". This discussion mentions more options: https://stackoverflow.com/questions/107705/disable-output-buffering You can also start bash on the command line. I do wonder why Git CMD seems to be started in what passes as a terminal, while Git BASH is not, though. You may want to check out https://gitforwindows.org/ and report your findings using their issue tracker. (This mailing list here, git@vger.kernel.org, is mostly used for discussing Git itself, not so much about extra tools like bash or Python that are packaged with Git for Windows.) René ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2018-01-27 3:56 Emile Kenold 0 siblings, 0 replies; 1767+ messages in thread From: Emile Kenold @ 2018-01-27 3:56 UTC (permalink / raw) -- This is Mrs. Emile Kenold contacting you for missionary work and i pray you will be kind enough to deliver my £7 million donation to the less privileged ones. I am a widow suffering of lung cancer which has damaged my liver and back bone, i decided to entrust this fund to a God fearing person that will use it for Charity works and i want your sincere reply to know if you will be able to execute this project, I will give you more information on how the fund will be transferred to you immediately I receive your positive response. Thanks and God bless you. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2018-01-24 22:11 Amy Riddering 0 siblings, 0 replies; 1767+ messages in thread From: Amy Riddering @ 2018-01-24 22:11 UTC (permalink / raw) -- Mrs. Amy Riddering contacting you for missionary work and i pray you will be kind enough to deliver my $7 million donation to the less privileged ones and God will bless your generation for doing this humanitarian assignment. I am a widow suffering of lung cancer which has damaged my liver and back bone, i decided to entrust $7M Dollars to a God fearing person that will use it for Charity works since i do not have any child who will inherit this money after i die. Please i want your urgent reply to know if you can handle this project and I will relocate this fund to you. Thanks and remain blessed. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2018-01-24 19:54 Amy Riddering 0 siblings, 0 replies; 1767+ messages in thread From: Amy Riddering @ 2018-01-24 19:54 UTC (permalink / raw) -- Mrs. Amy Riddering contacting you for missionary work and i pray you will be kind enough to deliver my $7 million donation to the less privileged ones in your country and God will bless your generation for doing this humanitarian work. I am a widow suffering of lung cancer which has damaged my liver and back bone, i decided to entrust this fund to a God fearing person that will use it for Charity works since i do not have any child who will inherit this money after i die. Please i want your sincere reply to know if you will be able to execute this project, and I will give you more information on how the fund will be transferred to your bank account. I am waiting for your reply. Thanks and God bless you. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2017-11-20 15:10 Viet Nguyen 2017-11-20 20:07 ` Stefan Beller 0 siblings, 1 reply; 1767+ messages in thread From: Viet Nguyen @ 2017-11-20 15:10 UTC (permalink / raw) To: git unsubscribe git ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2017-11-20 15:10 Viet Nguyen @ 2017-11-20 20:07 ` Stefan Beller 0 siblings, 0 replies; 1767+ messages in thread From: Stefan Beller @ 2017-11-20 20:07 UTC (permalink / raw) To: Viet Nguyen; +Cc: git did you mean majordomo@kernel.org instead? On Mon, Nov 20, 2017 at 7:10 AM, Viet Nguyen <ntviet18@gmail.com> wrote: > unsubscribe git ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 15:04 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 15:04 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 15:01 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 15:01 UTC (permalink / raw) To: target-devel Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 15:00 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 15:00 UTC (permalink / raw) To: sparclinux Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:57 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:57 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:56 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:56 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) To: linux-security-module Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 ` Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 ` Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:55 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:44 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:44 UTC (permalink / raw) To: keyrings Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-11-13 14:42 Amos Kalonzo 0 siblings, 0 replies; 1767+ messages in thread From: Amos Kalonzo @ 2017-11-13 14:42 UTC (permalink / raw) Attn: I am wondering why You haven't respond to my email for some days now. reference to my client's contract balance payment of (11.7M,USD) Kindly get back to me for more details. Best Regards Amos Kalonzo -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2017-11-12 2:21 hsed 2017-11-13 18:56 ` Stefan Beller 0 siblings, 1 reply; 1767+ messages in thread From: hsed @ 2017-11-12 2:21 UTC (permalink / raw) To: git subscribe git ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2017-11-12 2:21 hsed @ 2017-11-13 18:56 ` Stefan Beller 0 siblings, 0 replies; 1767+ messages in thread From: Stefan Beller @ 2017-11-13 18:56 UTC (permalink / raw) To: hsed; +Cc: git To subscribe to the git mailing list, send the email to majordomo@vger.kernel.org, not the mailing list itself. On Sat, Nov 11, 2017 at 6:21 PM, <hsed@unimetic.com> wrote: > subscribe git ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE:: @ 2017-11-01 14:57 Mrs Hsu Wealther 0 siblings, 0 replies; 1767+ messages in thread From: Mrs Hsu Wealther @ 2017-11-01 14:57 UTC (permalink / raw) To: linux-sparse Are you available at your desk? I need you to please check your email box for a business letter. With Regards, Ms. Hui Weather ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-10-18 14:31 Mrs. Marie Angèle O 0 siblings, 0 replies; 1767+ messages in thread From: Mrs. Marie Angèle O @ 2017-10-18 14:31 UTC (permalink / raw) -- I solicit for your partnership to claim $11 million. You will be entitled to 40% of the sum reply for more details. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-10-01 10:53 Pierre 0 siblings, 0 replies; 1767+ messages in thread From: Pierre @ 2017-10-01 10:53 UTC (permalink / raw) To: sparclinux Do you need a loan ,You want to pay off bills,Expand your business ?,Look no further we offer all kinds of loans both long and short term loan,for only 3% interest.If yes you need a loan Please email : pierrewolf07@gmail.com now to apply for a secured loan with the Applicant form below , Name : Age: Country: State: Loan amount : Loan duration : Phone number : --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE:
@ 2017-09-24 16:59 Estrin, Alex
[not found] ` <F3529576D8E232409F431C309E29399336CD9886-8k97q/ur5Z1cIJlls4ac1rfspsVTdybXVpNB7YpNyf8@public.gmane.org>
0 siblings, 1 reply; 1767+ messages in thread
From: Estrin, Alex @ 2017-09-24 16:59 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Leon,
The only intention I had with that note was to try to help with the process of screening patches
to maintain and improve the quality of common rdma code.
As it was taken as an insult I apologize for that. Never had in mind.
I should have scripted it better.
Perhaps, put the note through the checkpatch :)
And yes, as a member of rdma list I accept my share of blame for missing that bug.
Thanks,
Alex.
P.S.
My apologies to the community for the spam.
> On Sat, Sep 23, 2017 at 07:20:53PM +0000, Estrin, Alex wrote:
> > > > Hello,
> > > >
> > > > One minor note regarding the original commit 523633359224
> > > > that broke the core.
> > > > It seem it was let through without trivial validation,
> > > > otherwise it wouldn't pass the checkpatch.
> > >
> > > Can you be more specific? Are you referring to "WARNING: line over 80
> > > characters" or to something else? If yes, I feel really bad for you and
> > > your workplace.
> > Please don't be. Keep doing a great job at your workplace, I will do the same at
> mine.
> >
> > > Readability is a first priority for the submitted code.
> > I can agree with you on that, considering easy readable submitted code
> > does not introduce a trivial bugs.
>
> It will be very helpful to everyone if you stop to throw claims without any actual
> support.
> 1. Doug allows enough time to respond on the patches and neither you and
> neither your
> colleagues didn't see such "trivial bug" back then.
> 2. It fixed another "trivial bug" introduced by your colleague which
> broke RoCE (one of the most popular fabric in the stack) and we didn't
> cry other the internet about it.
>
> Before you are rushing to reply me, please consult with Denny, he can
> give you a short update on how hard the recent OPA changes in AH and
> LIDs broke the stack and RoCE/IB devices.
>
> >
> > > ➜ linux-rdma git:(rdma-rc) git fp -1 523633359224 -o /tmp/
> > > /tmp/0001-IB-core-Fix-the-validations-of-a-multicast-LID-in-at.patch
> > > ➜ linux-rdma git:(rdma-rc) ./scripts/checkpatch.pl --strict /tmp/0001-IB-core-
> Fix-
> > > the-validations-of-a-multicast-LID-in-at.patch
> > > WARNING: line over 80 characters
> > > #45: FILE: drivers/infiniband/core/verbs.c:1584:
> > > + if (qp->device->get_link_layer(qp->device, attr.port_num) !=
> > >
> > > total: 0 errors, 1 warnings, 0 checks, 62 lines checked
> > >
> > > NOTE: For some of the reported defects, checkpatch may be able to
> > > mechanically convert to the typical style using --fix or --fix-inplace.
> > >
> > > /tmp/0001-IB-core-Fix-the-validations-of-a-multicast-LID-in-at.patch has
> style
> > > problems, please review.
> > >
> > > NOTE: If any of the errors are false positives, please report
> > > them to the maintainer, see CHECKPATCH in MAINTAINERS.
> > >
> > >
> > > >
> > > > Thanks,
> > > > Alex.
> > > >
> > > > > On Fri, Sep 22, 2017 at 06:42:41PM -0400, Doug Ledford wrote:
> > > > > > On Fri, 2017-09-22 at 15:17 -0600, Jason Gunthorpe wrote:
> > > > > > > On Fri, Sep 22, 2017 at 05:06:26PM -0400, Doug Ledford wrote:
> > > > > > >
> > > > > > > > Sure, I get that, but I was already out on PTO on the 30th. What
> > > > > > > > sucks
> > > > > > > > is that it landed right after I was out. But I plan to have the
> > > > > > > > pull
> > > > > > > > request in before EOB today, so the difference between the 20th
> and
> > > > > > > > today is neglible. Especially since lots of people doing QA
> > > > > > > > testing
> > > > > > > > prefer to take -rc tags, in that case, the difference is non-
> > > > > > > > existent.
> > > > > > >
> > > > > > > My thinking was that people should test -rc,
> > > > > >
> > > > > > Great, with you here...
> > > > > >
> > > > > > > but if they have problems
> > > > > > > they could grab your for-rc branch and check if their issue is
> > > > > > > already
> > > > > > > fixed..
> > > > > >
> > > > > > They can do this too...
> > > > > >
> > > > > > But if that still doesn't resolve their problem, a quick check of the
> > > > > > mailing list contents isn't out of the question either. In that case,
> > > > > > they would have found the solution to their problem. But, when you
> get
> > > > > > right down to it, only one person reported it in addition to the
> > > > > > original poster, so either other people saw the original post and
> > > > > > compensated in their own testing, or (the more likely I think), most
> > > > > > people don't start testing -rcs until after -rc2.
> > > > >
> > > > > I don't know about other people, but our testing of -rc starts on -rc1
> > > > > and we are not waiting for -rc2. From my observe of netdev, they also
> > > > > start to test -rc immediately.
> > > > >
> > > > > Otherwise, what is the point of the week between -rc1 and -rc2?
> > > > >
> > > > > > Which is why I try to set -rc2 as a milestone for several purposes.
> > > > > > For getting in the bulk of the known fixes, but also as a branching
> > > > > > point for for-next.
> > > > > >
> > > > > > --
> > > > > > Doug Ledford <dledford@redhat.com>
> > > > > > GPG KeyID: B826A3330E572FDD
> > > > > > Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333
> 0E57
> > > 2FDD
> > > > > >
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> > > > the body of a message to majordomo@vger.kernel.org
> > > > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 1767+ messages in thread[parent not found: <F3529576D8E232409F431C309E29399336CD9886-8k97q/ur5Z1cIJlls4ac1rfspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* Re: [not found] ` <F3529576D8E232409F431C309E29399336CD9886-8k97q/ur5Z1cIJlls4ac1rfspsVTdybXVpNB7YpNyf8@public.gmane.org> @ 2017-09-25 5:48 ` Leon Romanovsky 0 siblings, 0 replies; 1767+ messages in thread From: Leon Romanovsky @ 2017-09-25 5:48 UTC (permalink / raw) To: Estrin, Alex; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [-- Attachment #1: Type: text/plain, Size: 606 bytes --] On Sun, Sep 24, 2017 at 04:59:55PM +0000, Estrin, Alex wrote: > Leon, > > The only intention I had with that note was to try to help with the process of screening patches > to maintain and improve the quality of common rdma code. > As it was taken as an insult I apologize for that. Never had in mind. > I should have scripted it better. > Perhaps, put the note through the checkpatch :) > And yes, as a member of rdma list I accept my share of blame for missing that bug. Thanks Alex for putting up with me at the mailing list. > > Thanks, > Alex. > > P.S. > My apologies to the community for the spam. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-07-27 1:12 Marie Angèle Ouattara 0 siblings, 0 replies; 1767+ messages in thread From: Marie Angèle Ouattara @ 2017-07-27 1:12 UTC (permalink / raw) I need your cooperation in a profitable transaction and details will be disclosed to you once i receive your reply. Thanks, Mrs. Marie. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-07-19 8:03 Lynne Smith 0 siblings, 0 replies; 1767+ messages in thread From: Lynne Smith @ 2017-07-19 8:03 UTC (permalink / raw) To: sparclinux My Name is lynne Smith please i really need your help? ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-07-19 8:03 Lynne Smith 0 siblings, 0 replies; 1767+ messages in thread From: Lynne Smith @ 2017-07-19 8:03 UTC (permalink / raw) My Name is lynne Smith please i really need your help? ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-07-07 17:04 Mrs Alice Walton 0 siblings, 0 replies; 1767+ messages in thread From: Mrs Alice Walton @ 2017-07-07 17:04 UTC (permalink / raw) -- my name is Mrs. Alice Walton, a business woman an America Citizen and the heiress to the fortune of Walmart stores, born October 7, 1949. I have a mission for you worth $100,000,000.00(Hundred Million United State Dollars) which I intend using for CHARITY PROJECT to help the less privilege and orphanage ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <20170519213731.21484-1-mrugiero@gmail.com>]
* Re: [not found] <20170519213731.21484-1-mrugiero@gmail.com> @ 2017-05-20 8:48 ` Boris Brezillon 0 siblings, 0 replies; 1767+ messages in thread From: Boris Brezillon @ 2017-05-20 8:48 UTC (permalink / raw) To: Mario J. Rugiero Cc: "linux-mtd, computersforpeace, marek.vasut, richard, cyrille.pitchen Hi Mario, Not sure how you created this patchset, but you miss a Subject, and the diff-stat. Please use git format-patch -o <output-dir> -3 --cover-letter to generate patches, then fill the cover letter in. Once your cover letter is ready, you can send the patches with git send-email --to ... --cc ... <output-dir>/*.patch Regards, Boris Le Fri, 19 May 2017 18:37:28 -0300, "Mario J. Rugiero" <mrugiero@gmail.com> a écrit : > Some manufacturers use different layouts than MTD for the NAND, creating > incompatibilities when going from a vendor-specific kernel to mainline. > In particular, NAND devices for AllWinner boards write non-FF values to > the bad block marker, and thus false positives arise when detecting bad > blocks with the MTD driver. Sometimes there are enough false positives > to make the device unusable. > A proposed solution is NAND scrubbing, something a user who knows what > she's doing (TM) could do to avoid this. It consists in erasing blocks > disregarding the BBM. Since the user must know what she's doing, the > only way to enable this feature is through a per-chip debugfs entry. > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-05-16 22:46 USPS Parcels Delivery 0 siblings, 0 replies; 1767+ messages in thread From: USPS Parcels Delivery @ 2017-05-16 22:46 UTC (permalink / raw) To: linux-nvdimm-y27Ovi1pjclAfugRpC6u6w Hello, Your item has arrived at the USPS Post Office at Wed, 17 May 2017 00:46:58 +0200, but the courier was unable to deliver parcel to you. You can download the shipment label attached! Yours respectfully. Mellicent Northan - USPS Operation Manager. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-05-04 23:57 Tammy 0 siblings, 0 replies; 1767+ messages in thread From: Tammy @ 2017-05-04 23:57 UTC (permalink / raw) To: Recipients Hello, I am Maj Gen. Tammy Smith. I would like to discuss with you privately. Contact me via my personal email below for further information. Maj Gen. Tammy Smith MajGenTammySm-1ViLX0X+lBJBDgjK7y7TUQ@public.gmane.org -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <CAMj-D2DO_CfvD77izsGfggoKP45HSC9aD6auUPAYC9Yeq_aX7w@mail.gmail.com>]
* Re: [not found] <CAMj-D2DO_CfvD77izsGfggoKP45HSC9aD6auUPAYC9Yeq_aX7w@mail.gmail.com> @ 2017-05-04 16:44 ` gengdongjiu 0 siblings, 0 replies; 1767+ messages in thread From: gengdongjiu @ 2017-05-04 16:44 UTC (permalink / raw) To: mtsirkin, kvm, Tyler Baicar, qemu-devel, Xiongfeng Wang, ben, linux, kvmarm, huangshaoyu, lersek, songwenjun, wuquanming, Marc Zyngier, qemu-arm, imammedo, linux-arm-kernel, Ard Biesheuvel, pbonzini, James Morse Dear James, Thanks a lot for your review and comments. I am very sorry for the late response. 2017-05-04 23:42 GMT+08:00 gengdongjiu <gengdj.1984@gmail.com>: > Hi Dongjiu Geng, > > On 30/04/17 06:37, Dongjiu Geng wrote: >> when happen SEA, deliver signal bus and handle the ioctl that >> inject SEA abort to guest, so that guest can handle the SEA error. > >> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c >> index 105b6ab..a96594f 100644 >> --- a/arch/arm/kvm/mmu.c >> +++ b/arch/arm/kvm/mmu.c >> @@ -20,8 +20,10 @@ >> @@ -1238,6 +1240,36 @@ static void coherent_cache_guest_page(struct kvm_vcpu *vcpu, kvm_pfn_t pfn, >> __coherent_cache_guest_page(vcpu, pfn, size); >> } >> >> +static void kvm_send_signal(unsigned long address, bool hugetlb, bool hwpoison) >> +{ >> + siginfo_t info; >> + >> + info.si_signo = SIGBUS; >> + info.si_errno = 0; >> + if (hwpoison) >> + info.si_code = BUS_MCEERR_AR; >> + else >> + info.si_code = 0; >> + >> + info.si_addr = (void __user *)address; >> + if (hugetlb) >> + info.si_addr_lsb = PMD_SHIFT; >> + else >> + info.si_addr_lsb = PAGE_SHIFT; >> + >> + send_sig_info(SIGBUS, &info, current); >> +} >> + > « [hide part of quote] > > Punit reviewed the other version of this patch, this PMD_SHIFT is not the right > thing to do, it needs a more accurate set of calls and shifts as there may be > hugetlbfs pages other than PMD_SIZE. > > https://www.spinics.net/lists/arm-kernel/msg568919.html > > I haven't posted a new version of that patch because I was still hunting a bug > in the hugepage/hwpoison code, even with Punit's fixes series I see -EFAULT > returned to userspace instead of this hwpoison code being invoked. Ok, got it, thanks for your information. > > Please avoid duplicating functionality between patches, it wastes reviewers > time, especially when we know there are problems with this approach. > > >> +static void kvm_handle_bad_page(unsigned long address, >> + bool hugetlb, bool hwpoison) >> +{ >> + /* handle both hwpoison and other synchronous external Abort */ >> + if (hwpoison) >> + kvm_send_signal(address, hugetlb, true); >> + else >> + kvm_send_signal(address, hugetlb, false); >> +} > > Why the extra level of indirection? We only want to signal userspace like this > from KVM for hwpoison. Signals for RAS related reasons should come from the bits > of the kernel that decoded the error. For the SEA, the are maily two types: 0b010000 Synchronous External Abort on memory access. 0b0101xx Synchronous External Abort on page table walk. DFSC[1:0] encode the level. hwpoison should belong to the "Synchronous External Abort on memory access" if the SEA type is not hwpoison, such as page table walk, do you mean KVM do not deliver the SIGBUS? If so, how the KVM handle the SEA type other than hwpoison? > > (hwpoison for KVM is a corner case as Qemu's memory effectively has two users, > Qemu and KVM. This isn't the example of how user-space gets signalled.) > > >> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c >> index b37446a..780e3c4 100644 >> --- a/arch/arm64/kvm/guest.c >> +++ b/arch/arm64/kvm/guest.c >> @@ -277,6 +277,13 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu, >> return -EINVAL; >> } >> >> +int kvm_vcpu_ioctl_sea(struct kvm_vcpu *vcpu) >> +{ >> + kvm_inject_dabt(vcpu, kvm_vcpu_get_hfar(vcpu)); >> + >> + return 0; >> +} > >> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h >> index bb02909..1d2e2e7 100644 >> --- a/include/uapi/linux/kvm.h >> +++ b/include/uapi/linux/kvm.h >> @@ -1306,6 +1306,7 @@ struct kvm_s390_ucas_mapping { >> #define KVM_S390_GET_IRQ_STATE _IOW(KVMIO, 0xb6, struct kvm_s390_irq_state) >> /* Available with KVM_CAP_X86_SMM */ >> #define KVM_SMI _IO(KVMIO, 0xb7) >> +#define KVM_ARM_SEA _IO(KVMIO, 0xb8) >> >> #define KVM_DEV_ASSIGN_ENABLE_IOMMU (1 << 0) >> #define KVM_DEV_ASSIGN_PCI_2_3 (1 << 1) >> > > Why do we need a userspace API for SEA? It can also be done by using > KVM_{G,S}ET_ONE_REG to change the vcpu registers. The advantage of doing it this > way is you can choose which ESR value to use. > > Adding a new API call to do something you could do with an old one doesn't look > right. James, I considered your suggestion before that use the KVM_{G,S}ET_ONE_REG to change the vcpu registers. but I found it does not have difference to use the alread existed KVM API. so may be changing the vcpu registers in qemu will duplicate with the KVM APIs. injection a SEA is no more than setting some registers: elr_el1, PC, PSTATE, SPSR_el1, far_el1, esr_el1 I seen this KVM API do the same thing as Qemu. do you found call this API will have issue and necessary to choose another ESR value? I pasted the alread existed KVM API code: static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned long addr) { unsigned long cpsr = *vcpu_cpsr(vcpu); bool is_aarch32 = vcpu_mode_is_32bit(vcpu); u32 esr = 0; *vcpu_elr_el1(vcpu) = *vcpu_pc(vcpu); *vcpu_pc(vcpu) = get_except_vector(vcpu, except_type_sync); *vcpu_cpsr(vcpu) = PSTATE_FAULT_BITS_64; *vcpu_spsr(vcpu) = cpsr; vcpu_sys_reg(vcpu, FAR_EL1) = addr; /* * Build an {i,d}abort, depending on the level and the * instruction set. Report an external synchronous abort. */ if (kvm_vcpu_trap_il_is32bit(vcpu)) esr |= ESR_ELx_IL; /* * Here, the guest runs in AArch64 mode when in EL1. If we get * an AArch32 fault, it means we managed to trap an EL0 fault. */ if (is_aarch32 || (cpsr & PSR_MODE_MASK) == PSR_MODE_EL0t) esr |= (ESR_ELx_EC_IABT_LOW << ESR_ELx_EC_SHIFT); else esr |= (ESR_ELx_EC_IABT_CUR << ESR_ELx_EC_SHIFT); if (!is_iabt) esr |= ESR_ELx_EC_DABT_LOW << ESR_ELx_EC_SHIFT; vcpu_sys_reg(vcpu, ESR_EL1) = esr | ESR_ELx_FSC_EXTABT; } static void inject_abt32(struct kvm_vcpu *vcpu, bool is_pabt, unsigned long addr) { u32 vect_offset; u32 *far, *fsr; bool is_lpae; if (is_pabt) { vect_offset = 12; far = &vcpu_cp15(vcpu, c6_IFAR); fsr = &vcpu_cp15(vcpu, c5_IFSR); } else { /* !iabt */ vect_offset = 16; far = &vcpu_cp15(vcpu, c6_DFAR); fsr = &vcpu_cp15(vcpu, c5_DFSR); } prepare_fault32(vcpu, COMPAT_PSR_MODE_ABT | COMPAT_PSR_A_BIT, vect_offset); *far = addr; /* Give the guest an IMPLEMENTATION DEFINED exception */ is_lpae = (vcpu_cp15(vcpu, c2_TTBCR) >> 31); if (is_lpae) *fsr = 1 << 9 | 0x34; else *fsr = 0x14; } /** * kvm_inject_dabt - inject a data abort into the guest * @vcpu: The VCPU to receive the undefined exception * @addr: The address to report in the DFAR * * It is assumed that this code is called from the VCPU thread and that the * VCPU therefore is not currently executing guest code. */ void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr) { if (!(vcpu->arch.hcr_el2 & HCR_RW)) inject_abt32(vcpu, false, addr); else inject_abt64(vcpu, false, addr); } > > > Thanks, > > James _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-05-03 11:26 Paul Lopez-Bravo 0 siblings, 0 replies; 1767+ messages in thread From: Paul Lopez-Bravo @ 2017-05-03 11:26 UTC (permalink / raw) -- Hallo, Erlauben Sie mir, diese sehr wichtige Anfrage durch diesen Median aufgrund seiner vertraulichen Natur zu machen. Mein Name ist Herr Paul Lopez-Bravo, ein Rechtsanwalt in Spanien. Ich vertrete Late Philip, der vor seinem Tod im Jahr 2009 ein reicher Unternehmer war. Ich vertraue dir in einer dringenden Angelegenheit an, die sich auf eine Kaution bezieht, die von diesem besonderen Klienten von mir vor seinem Tod gemacht wurde. Ich suche für Ihre Zustimmung, mich zu ermächtigen, Ihnen als seinen Erben zu präsentieren, um seine Bank zu veranlassen, die Summe von $ 7.5Million (Sieben Million Fünfhundert Tausend Dollar), die in einem suspendierten Bankkonto hinterlegt werden, zu übergeben. Seine Bank hat mir ein letztes Ultimatum als sein Anwalt ausgegeben, um seinen Erben zu präsentieren, da die gesetzlich zulässige Zeit für eine solche Forderung abgelaufen ist, sonst wird der Fonds beschlagnahmt. Die beabsichtigte Transaktion wird unter einer legitimen Art und Weise durchgeführt, die Sie und ich vor jeglicher Rechtsverletzung schützen wird. Ich werde meine Position als Mandantenanwalt nutzen, um die Bearbeitung der benötigten rechtlichen Dokumentationen und die erfolgreiche Durchführung dieser Transaktion zu gewährleisten. Alles was ich verlange ist Ihr Verständnis und ehrliche Zusammenarbeit für den Erfolg. Beachten Sie, dass nach der erfolgreichen Durchführung der Transaktion, halten Sie 40% des gesamten Fonds nach allen Kosten. Ich gebe Ihnen ausführliche Details, wenn Sie Ihr Interesse bestätigen. Ich hoffe, von Ihnen bald zu hören. Mit freundlichen Grüßen Paul Lopez-Bravo Esq Tel: +34692899384 ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-05-03 6:23 H.A 0 siblings, 0 replies; 1767+ messages in thread From: H.A @ 2017-05-03 6:23 UTC (permalink / raw) To: Recipients With profound love in my heart, I Kindly Oblige your interest to very important proposal.. It is Truly Divine and require your utmost attention.......... S hlubokou láskou v mém srdci, Laskave jsem prinutit svuj zájem k návrhu .. Je velmi duležité, skutecne Divine a vyžadují vaši nejvyšší pozornost. Kontaktujte me prímo pres: helenaroberts99@gmail.com pro úplné podrobnosti.complete. HELINA .A ROBERTS --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-05-03 6:23 H.A 0 siblings, 0 replies; 1767+ messages in thread From: H.A @ 2017-05-03 6:23 UTC (permalink / raw) To: Recipients With profound love in my heart, I Kindly Oblige your interest to very important proposal.. It is Truly Divine and require your utmost attention.......... S hlubokou láskou v mém srdci, Laskave jsem prinutit svuj zájem k návrhu .. Je velmi duležité, skutecne Divine a vyžadují vaši nejvyšší pozornost. Kontaktujte me prímo pres: helenaroberts99@gmail.com pro úplné podrobnosti.complete. HELINA .A ROBERTS --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-05-03 6:23 H.A 0 siblings, 0 replies; 1767+ messages in thread From: H.A @ 2017-05-03 6:23 UTC (permalink / raw) To: Recipients With profound love in my heart, I Kindly Oblige your interest to very important proposal.. It is Truly Divine and require your utmost attention.......... S hlubokou láskou v mém srdci, Laskave jsem prinutit svuj zájem k návrhu .. Je velmi duležité, skutecne Divine a vyžadují vaši nejvyšší pozornost. Kontaktujte me prímo pres: helenaroberts99@gmail.com pro úplné podrobnosti.complete. HELINA .A ROBERTS --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-05-03 6:23 H.A 0 siblings, 0 replies; 1767+ messages in thread From: H.A @ 2017-05-03 6:23 UTC (permalink / raw) To: Recipients With profound love in my heart, I Kindly Oblige your interest to very important proposal.. It is Truly Divine and require your utmost attention.......... S hlubokou láskou v mém srdci, Laskave jsem prinutit svuj zájem k návrhu .. Je velmi duležité, skutecne Divine a vyžadují vaši nejvyšší pozornost. Kontaktujte me prímo pres: helenaroberts99@gmail.com pro úplné podrobnosti.complete. HELINA .A ROBERTS --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-05-03 6:23 H.A 0 siblings, 0 replies; 1767+ messages in thread From: H.A @ 2017-05-03 6:23 UTC (permalink / raw) To: Recipients With profound love in my heart, I Kindly Oblige your interest to very important proposal.. It is Truly Divine and require your utmost attention.......... S hlubokou láskou v mém srdci, Laskave jsem prinutit svuj zájem k návrhu .. Je velmi duležité, skutecne Divine a vyžadují vaši nejvyšší pozornost. Kontaktujte me prímo pres: helenaroberts99@gmail.com pro úplné podrobnosti.complete. HELINA .A ROBERTS --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-05-03 6:23 H.A 0 siblings, 0 replies; 1767+ messages in thread From: H.A @ 2017-05-03 6:23 UTC (permalink / raw) To: Recipients With profound love in my heart, I Kindly Oblige your interest to very important proposal.. It is Truly Divine and require your utmost attention.......... S hlubokou láskou v mém srdci, Laskave jsem prinutit svuj zájem k návrhu .. Je velmi duležité, skutecne Divine a vyžadují vaši nejvyšší pozornost. Kontaktujte me prímo pres: helenaroberts99@gmail.com pro úplné podrobnosti.complete. HELINA .A ROBERTS --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-05-03 6:23 H.A 0 siblings, 0 replies; 1767+ messages in thread From: H.A @ 2017-05-03 6:23 UTC (permalink / raw) To: Recipients With profound love in my heart, I Kindly Oblige your interest to very important proposal.. It is Truly Divine and require your utmost attention.......... S hlubokou láskou v mém srdci, Laskave jsem prinutit svuj zájem k návrhu .. Je velmi duležité, skutecne Divine a vyžadují vaši nejvyšší pozornost. Kontaktujte me prímo pres: helenaroberts99@gmail.com pro úplné podrobnosti.complete. HELINA .A ROBERTS --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-05-03 5:59 H.A 0 siblings, 0 replies; 1767+ messages in thread From: H.A @ 2017-05-03 5:59 UTC (permalink / raw) To: kernel-janitors With profound love in my heart, I Kindly Oblige your interest to very important proposal.. It is Truly Divine and require your utmost attention.......... S hlubokou láskou v mém srdci, Laskave jsem prinutit svuj zájem k návrhu .. Je velmi duležité, skutecne Divine a vyžadují vaši nejvyšší pozornost. Kontaktujte me prímo pres: helenaroberts99@gmail.com pro úplné podrobnosti.complete. HELINA .A ROBERTS --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-04-29 22:53 USPS Station Management 0 siblings, 0 replies; 1767+ messages in thread From: USPS Station Management @ 2017-04-29 22:53 UTC (permalink / raw) To: linux-nvdimm-y27Ovi1pjclAfugRpC6u6w Hello, Your item has arrived at the USPS Post Office at Sat, 29 Apr 2017 15:53:09 -0700, but the courier was unable to deliver parcel to you. You can find more details in this e-mail attachment! With thanks and appreciation. Fermina Khan - USPS Support Agent. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-04-28 18:27 USPS Ground Support 0 siblings, 0 replies; 1767+ messages in thread From: USPS Ground Support @ 2017-04-28 18:27 UTC (permalink / raw) To: linux-nvdimm-y27Ovi1pjclAfugRpC6u6w Hello, Your item has arrived at the USPS Post Office at Fri, 28 Apr 2017 11:27:27 -0700, but the courier was unable to deliver parcel to you. You can download the shipment label attached! With gratitude. Lashan Simmering - USPS Support Manager. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (unknown), @ 2017-04-28 8:20 Anatolij Gustschin 2017-04-28 8:43 ` Linus Walleij 0 siblings, 1 reply; 1767+ messages in thread From: Anatolij Gustschin @ 2017-04-28 8:20 UTC (permalink / raw) To: linus.walleij, gnurou; +Cc: andy.shevchenko, linux-gpio, linux-kernel Subject: [PATCH v3] gpiolib: Add stubs for gpiod lookup table interface Add stubs for gpiod_add_lookup_table() and gpiod_remove_lookup_table() for the !GPIOLIB case to prevent build errors. Also add prototypes. Signed-off-by: Anatolij Gustschin <agust@denx.de> --- Changes in v3: - add stubs for !GPIOLIB case. Drop prototypes, these are already in gpio/machine.h Changes in v2: - move gpiod_lookup_table out of #ifdef include/linux/gpio/consumer.h | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h index 8f702fc..cf3fee2 100644 --- a/include/linux/gpio/consumer.h +++ b/include/linux/gpio/consumer.h @@ -41,6 +41,8 @@ enum gpiod_flags { GPIOD_FLAGS_BIT_DIR_VAL, }; +struct gpiod_lookup_table; + #ifdef CONFIG_GPIOLIB /* Return the number of GPIOs associated with a device / function */ @@ -435,6 +437,12 @@ struct gpio_desc *devm_fwnode_get_index_gpiod_from_child(struct device *dev, return ERR_PTR(-ENOSYS); } +static inline +void gpiod_add_lookup_table(struct gpiod_lookup_table *table) {} + +static inline +void gpiod_remove_lookup_table(struct gpiod_lookup_table *table) {} + #endif /* CONFIG_GPIOLIB */ static inline -- 2.7.4 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2017-04-28 8:20 (unknown), Anatolij Gustschin @ 2017-04-28 8:43 ` Linus Walleij 2017-04-28 9:26 ` Re: Anatolij Gustschin 0 siblings, 1 reply; 1767+ messages in thread From: Linus Walleij @ 2017-04-28 8:43 UTC (permalink / raw) To: Anatolij Gustschin Cc: Alexandre Courbot, Andy Shevchenko, linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org On Fri, Apr 28, 2017 at 10:20 AM, Anatolij Gustschin <agust@denx.de> wrote: > Subject: [PATCH v3] gpiolib: Add stubs for gpiod lookup table interface > > Add stubs for gpiod_add_lookup_table() and gpiod_remove_lookup_table() > for the !GPIOLIB case to prevent build errors. Also add prototypes. > > Signed-off-by: Anatolij Gustschin <agust@denx.de> > --- > Changes in v3: > - add stubs for !GPIOLIB case. Drop prototypes, these are > already in gpio/machine.h Yeah... > --- a/include/linux/gpio/consumer.h > +++ b/include/linux/gpio/consumer.h So why should the stubs be in <linux/gpio/consumer.h> and not in <linux/gpio/machine.h>? Yours, Linus Walleij ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2017-04-28 8:43 ` Linus Walleij @ 2017-04-28 9:26 ` Anatolij Gustschin 0 siblings, 0 replies; 1767+ messages in thread From: Anatolij Gustschin @ 2017-04-28 9:26 UTC (permalink / raw) To: Linus Walleij Cc: Alexandre Courbot, Andy Shevchenko, linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org On Fri, 28 Apr 2017 10:43:19 +0200 Linus Walleij linus.walleij@linaro.org wrote: ... >> --- a/include/linux/gpio/consumer.h >> +++ b/include/linux/gpio/consumer.h > >So why should the stubs be in <linux/gpio/consumer.h> >and not in <linux/gpio/machine.h>? good question. I'll move them to machine.h. Thanks, Anatolij ^ permalink raw reply [flat|nested] 1767+ messages in thread
[parent not found: <CALDO+SZPQGmp4VH0LvCh95uXWvwzAoj+wN-rm0pGu5e0wCcyNw@mail.gmail.com>]
* Re: [not found] <CALDO+SZPQGmp4VH0LvCh95uXWvwzAoj+wN-rm0pGu5e0wCcyNw@mail.gmail.com> @ 2017-04-19 18:13 ` Joe Stringer 0 siblings, 0 replies; 1767+ messages in thread From: Joe Stringer @ 2017-04-19 18:13 UTC (permalink / raw) To: William Tu; +Cc: xdp-newbies On 19 April 2017 at 11:12, William Tu <u9012063@gmail.com> wrote: > subscribe xdp-newbies You'll need to send this to majordomo@vger.kernel.org :-) http://vger.kernel.org/vger-lists.html ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (unknown),
@ 2017-04-13 15:58 Scott Ellentuch
[not found] ` <CAK2H+efb3iKA5P3yd7uRqJomci6ENvrB1JRBBmtQEpEvyPMe7w@mail.gmail.com>
0 siblings, 1 reply; 1767+ messages in thread
From: Scott Ellentuch @ 2017-04-13 15:58 UTC (permalink / raw)
To: linux-raid
for disk in a b c d g h i j k l m n
do
disklist="${disklist} /dev/sd${disk}1"
done
mdadm --create --verbose /dev/md2 --level=5 --raid=devices=12 ${disklist}
But its telling me :
mdadm: invalid number of raid devices: devices=12
I can't find any definition of a limit anywhere.
Thank you, Tuc
^ permalink raw reply [flat|nested] 1767+ messages in thread[parent not found: <CAK2H+efb3iKA5P3yd7uRqJomci6ENvrB1JRBBmtQEpEvyPMe7w@mail.gmail.com>]
* Re: [not found] ` <CAK2H+efb3iKA5P3yd7uRqJomci6ENvrB1JRBBmtQEpEvyPMe7w@mail.gmail.com> @ 2017-04-13 16:38 ` Scott Ellentuch 0 siblings, 0 replies; 1767+ messages in thread From: Scott Ellentuch @ 2017-04-13 16:38 UTC (permalink / raw) To: Mark Knecht; +Cc: Linux-RAID DOH! Stared at it for a while... Thanks. Tuc On Thu, Apr 13, 2017 at 12:22 PM, Mark Knecht <markknecht@gmail.com> wrote: > > > On Thu, Apr 13, 2017 at 8:58 AM, Scott Ellentuch <tuctboh@gmail.com> wrote: >> >> for disk in a b c d g h i j k l m n >> do >> >> disklist="${disklist} /dev/sd${disk}1" >> >> done >> >> mdadm --create --verbose /dev/md2 --level=5 --raid=devices=12 ${disklist} >> >> But its telling me : >> >> mdadm: invalid number of raid devices: devices=12 >> >> >> I can't find any definition of a limit anywhere. >> >> Thank you, Tuc >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-raid" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Try > > --raid-devices=12 > > not > > --raid=devices=12 ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-04-11 14:37 USPS Priority Delivery 0 siblings, 0 replies; 1767+ messages in thread From: USPS Priority Delivery @ 2017-04-11 14:37 UTC (permalink / raw) To: linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw Hello, We can not deliver your parcel arrived at Tue, 11 Apr 2017 15:37:40 +0100. Please click on the link for more details. http://uspswoiugue62677104.ideliverys.com/iq5866671 With anticipation. Sophie Wadkins - USPS Chief Office Manager. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-04-10 3:17 Qin Yan jun 0 siblings, 0 replies; 1767+ messages in thread From: Qin Yan jun @ 2017-04-10 3:17 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2017-04-01 5:31 USPS Delivery 0 siblings, 0 replies; 1767+ messages in thread From: USPS Delivery @ 2017-04-01 5:31 UTC (permalink / raw) To: linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw Hello, Your item has arrived at Sat, 01 Apr 2017 06:31:34 +0100, but our courier was not able to deliver the parcel. Review the document that is attached to this e-mail! Most sincerely. Gertruda Hendry - USPS Mail Delivery Agent. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2017-03-19 15:00 Ilan Schwarts 2017-03-23 17:12 ` Jeff Mahoney 0 siblings, 1 reply; 1767+ messages in thread From: Ilan Schwarts @ 2017-03-19 15:00 UTC (permalink / raw) To: linux-btrfs Hi, sorry if this is a newbie question. I am newbie. In my kernel driver, I get device id by converting struct inode struct to btrfs_inode, I use the code: struct btrfs_inode *btrfsInode; btrfsInode = BTRFS_I(inode); I usually download kernel-headers rpm package, this is not enough. it fails to find the btrfs header files. I had to download them not via rpm package and declare: #include "/data/kernel/linux-4.1.21-x86_64/fs/btrfs/ctree.h" #include "/data/kernel/linux-4.1.21-x86_64/fs/btrfs/btrfs_inode.h" This is not good, why ctree.h and btrfs_inode.h are not in kernel headers? Is there another package i need to download in order to get them, in addition to kernel-headers? ? I see they are not provided in kernel-header package, e.g: https://rpmfind.net/linux/RPM/fedora/23/x86_64/k/kernel-headers-4.2.3-300.fc23.x86_64.html Thanks! ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2017-03-19 15:00 Ilan Schwarts @ 2017-03-23 17:12 ` Jeff Mahoney 0 siblings, 0 replies; 1767+ messages in thread From: Jeff Mahoney @ 2017-03-23 17:12 UTC (permalink / raw) To: Ilan Schwarts, linux-btrfs [-- Attachment #1.1: Type: text/plain, Size: 1289 bytes --] On 3/19/17 11:00 AM, Ilan Schwarts wrote: > Hi, > sorry if this is a newbie question. I am newbie. > > In my kernel driver, I get device id by converting struct inode struct > to btrfs_inode, I use the code: > struct btrfs_inode *btrfsInode; > btrfsInode = BTRFS_I(inode); > > I usually download kernel-headers rpm package, this is not enough. it > fails to find the btrfs header files. > > I had to download them not via rpm package and declare: > #include "/data/kernel/linux-4.1.21-x86_64/fs/btrfs/ctree.h" > #include "/data/kernel/linux-4.1.21-x86_64/fs/btrfs/btrfs_inode.h" > > This is not good, why ctree.h and btrfs_inode.h are not in kernel headers? > Is there another package i need to download in order to get them, in > addition to kernel-headers? ? > > > I see they are not provided in kernel-header package, e.g: > https://rpmfind.net/linux/RPM/fedora/23/x86_64/k/kernel-headers-4.2.3-300.fc23.x86_64.html I don't know what Fedora package you'd use, but the core problem is that you're trying to use internal structures in an external module. We've properly exported the constants and structures required for userspace to interact with btrfs, but there are no plans to export internal structures. -Jeff -- Jeff Mahoney SUSE Labs [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:15 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:15 UTC (permalink / raw) To: sparclinux How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:13 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:13 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:10 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:10 UTC (permalink / raw) ---- How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 ` Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 ` Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) To: linux-sctp How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 ` Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) To: linux-sh How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 ` Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 ` Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 ` Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) To: linux-fbdev How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 ` Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* RE: @ 2017-02-23 15:09 Qin's Yanjun 0 siblings, 0 replies; 1767+ messages in thread From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw) To: kernel-janitors How are you today and your family? I require your attention and honest co-operation about some issues which i will really want to discuss with you which. Looking forward to read from you soon. Qin's ______________________________ Sky Silk, http://aknet.kz ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2017-02-16 19:41 simran singhal 2017-02-16 19:44 ` SIMRAN SINGHAL 0 siblings, 1 reply; 1767+ messages in thread From: simran singhal @ 2017-02-16 19:41 UTC (permalink / raw) To: gregkh; +Cc: outreachy-kernel, devel linux-kernel@vger.kernel.org Bcc: Subject: [PATCH 1/3] staging: rtl8192u: Replace symbolic permissions with octal permissions Reply-To: WARNING: Symbolic permissions 'S_IRUGO | S_IWUSR' are not preferred. Consider using octal permissions '0644'. This warning is detected by checkpatch.pl Signed-off-by: simran singhal <singhalsimran0@gmail.com> --- drivers/staging/rtl8192u/ieee80211/ieee80211_module.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c index a9a92d8..2ebc320 100644 --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c @@ -283,7 +283,7 @@ int __init ieee80211_debug_init(void) " proc directory\n"); return -EIO; } - e = proc_create("debug_level", S_IRUGO | S_IWUSR, + e = proc_create("debug_level", 0644, ieee80211_proc, &fops); if (!e) { remove_proc_entry(DRV_NAME, init_net.proc_net); -- 2.7.4 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2017-02-16 19:41 simran singhal @ 2017-02-16 19:44 ` SIMRAN SINGHAL 0 siblings, 0 replies; 1767+ messages in thread From: SIMRAN SINGHAL @ 2017-02-16 19:44 UTC (permalink / raw) To: outreachy-kernel [-- Attachment #1.1: Type: text/plain, Size: 1333 bytes --] On Friday, February 17, 2017 at 1:11:19 AM UTC+5:30, SIMRAN SINGHAL wrote: > > linux-kernel@vger.kernel.org > Bcc: > Subject: [PATCH 1/3] staging: rtl8192u: Replace symbolic permissions with > octal permissions > Reply-To: > > WARNING: Symbolic permissions 'S_IRUGO | S_IWUSR' are not preferred. > Consider using octal permissions '0644'. > This warning is detected by checkpatch.pl > > Signed-off-by: simran singhal <singhalsimran0@gmail.com> > --- > drivers/staging/rtl8192u/ieee80211/ieee80211_module.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c > b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c > index a9a92d8..2ebc320 100644 > --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c > +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c > @@ -283,7 +283,7 @@ int __init ieee80211_debug_init(void) > " proc directory\n"); > return -EIO; > } > - e = proc_create("debug_level", S_IRUGO | S_IWUSR, > + e = proc_create("debug_level", 0644, > ieee80211_proc, &fops); > if (!e) { > remove_proc_entry(DRV_NAME, init_net.proc_net); > -- > 2.7.4 > > Sorry, Ignore this. [-- Attachment #1.2: Type: text/html, Size: 2679 bytes --] ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: [PATCH 7/7] completion: recognize more long-options @ 2017-01-25 0:11 Cornelius Weig 2017-01-25 0:21 ` Stefan Beller 0 siblings, 1 reply; 1767+ messages in thread From: Cornelius Weig @ 2017-01-25 0:11 UTC (permalink / raw) To: Stefan Beller Cc: Junio C Hamano, Johannes Sixt, bitte.keine.werbung.einwerfen, git@vger.kernel.org, thomas.braun, John Keeping On 01/25/2017 12:43 AM, Stefan Beller wrote: > On Tue, Jan 24, 2017 at 3:33 PM, Cornelius Weig > <cornelius.weig@tngtech.com> wrote: >> On 01/25/2017 12:24 AM, Junio C Hamano wrote: >>> Cornelius Weig <cornelius.weig@tngtech.com> writes: >>> >>>>> Please study item (5) "Sign your work" in >>>>> Documentation/SubmittingPatches and sign off your work. >>>> >>>> I followed the recommendations to submitting work, and in the first >>>> round signing is discouraged. >>> >>> Just this point. You found a bug in our documentation if that is >>> the case; it should not be giving that impression to you. >>> >> >> Well, I am referring to par. (4) of Documentation/SubmittingPatches >> (emphasis mine): >> >> <<<<<<<<<<<<<< >> *Do not PGP sign your patch, at least for now*. Most likely, your >> maintainer or other people on the list would not have your PGP >> key and would not bother obtaining it anyway. Your patch is not >> judged by who you are; a good patch from an unknown origin has a >> far better chance of being accepted than a patch from a known, >> respected origin that is done poorly or does incorrect things. >> <<<<<<<<<<<<<< >> >> If first submissions should be signed as well, then I find this quite >> misleading. >> > > Please read on; While this part addresses PGP signing, > which is discouraged at any round, > later on we talk about another type of signing. > (not cryptographic strong signing, but signing the intent;) > the DCO in the commit message. > > So no PGP signing (in any round of the patch). > > But DCO signed (in anything that you deem useful for the > project and that you are allowed to contribute) > Right, it's crystal clear now. What confused me was the combination of > Do not PGP sign your patch, at least *for now*. (...) and then the section with heading > (5) *Sign* your work So I didn't even bother to read (5) because I deemed it irrelevant. I think if it had said `(5) *Certify* your work` this would not have happened. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) 2017-01-25 0:11 [PATCH 7/7] completion: recognize more long-options Cornelius Weig @ 2017-01-25 0:21 ` Stefan Beller 2017-01-25 0:43 ` Cornelius Weig 2017-01-25 0:54 ` Re: Linus Torvalds 0 siblings, 2 replies; 1767+ messages in thread From: Stefan Beller @ 2017-01-25 0:21 UTC (permalink / raw) To: cornelius.weig Cc: j6t, bitte.keine.werbung.einwerfen, git, gitster, thomas.braun, john, Stefan Beller > >> Do not PGP sign your patch, at least *for now*. (...) > And maybe these 2 small words are the bug in the documentation? Shall we drop the "at least for now" part, like so: ---8<--- From 2c4fe0e67451892186ff6257b20c53e088c9ec67 Mon Sep 17 00:00:00 2001 From: Stefan Beller <sbeller@google.com> Date: Tue, 24 Jan 2017 16:19:13 -0800 Subject: [PATCH] SubmittingPatches: drop temporal reference for PGP signing Signed-off-by: Stefan Beller <sbeller@google.com> --- Documentation/SubmittingPatches | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 08352deaae..28da4ad2d4 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -216,12 +216,12 @@ that it will be postponed. Exception: If your mailer is mangling patches then someone may ask you to re-send them using MIME, that is OK. -Do not PGP sign your patch, at least for now. Most likely, your -maintainer or other people on the list would not have your PGP -key and would not bother obtaining it anyway. Your patch is not -judged by who you are; a good patch from an unknown origin has a -far better chance of being accepted than a patch from a known, -respected origin that is done poorly or does incorrect things. +Do not PGP sign your patch. Most likely, your maintainer or other +people on the list would not have your PGP key and would not bother +obtaining it anyway. Your patch is not judged by who you are; a good +patch from an unknown origin has a far better chance of being accepted +than a patch from a known, respected origin that is done poorly or +does incorrect things. If you really really really really want to do a PGP signed patch, format it as "multipart/signed", not a text/plain message -- 2.11.0.495.g04f60290a0.dirty ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2017-01-25 0:21 ` Stefan Beller @ 2017-01-25 0:43 ` Cornelius Weig 2017-01-25 0:52 ` Re: Stefan Beller 2017-01-25 0:54 ` Re: Linus Torvalds 1 sibling, 1 reply; 1767+ messages in thread From: Cornelius Weig @ 2017-01-25 0:43 UTC (permalink / raw) To: Stefan Beller Cc: j6t, bitte.keine.werbung.einwerfen, git, gitster, thomas.braun, john On 01/25/2017 01:21 AM, Stefan Beller wrote: >> >>> Do not PGP sign your patch, at least *for now*. (...) >> > > And maybe these 2 small words are the bug in the documentation? > Shall we drop the "at least for now" part, like so: > > ---8<--- > From 2c4fe0e67451892186ff6257b20c53e088c9ec67 Mon Sep 17 00:00:00 2001 > From: Stefan Beller <sbeller@google.com> > Date: Tue, 24 Jan 2017 16:19:13 -0800 > Subject: [PATCH] SubmittingPatches: drop temporal reference for PGP signing > > Signed-off-by: Stefan Beller <sbeller@google.com> > --- > Documentation/SubmittingPatches | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches > index 08352deaae..28da4ad2d4 100644 > --- a/Documentation/SubmittingPatches > +++ b/Documentation/SubmittingPatches > @@ -216,12 +216,12 @@ that it will be postponed. > Exception: If your mailer is mangling patches then someone may ask > you to re-send them using MIME, that is OK. > > -Do not PGP sign your patch, at least for now. Most likely, your > -maintainer or other people on the list would not have your PGP > -key and would not bother obtaining it anyway. Your patch is not > -judged by who you are; a good patch from an unknown origin has a > -far better chance of being accepted than a patch from a known, > -respected origin that is done poorly or does incorrect things. > +Do not PGP sign your patch. Most likely, your maintainer or other > +people on the list would not have your PGP key and would not bother > +obtaining it anyway. Your patch is not judged by who you are; a good > +patch from an unknown origin has a far better chance of being accepted > +than a patch from a known, respected origin that is done poorly or > +does incorrect things. > > If you really really really really want to do a PGP signed > patch, format it as "multipart/signed", not a text/plain message > It definitely is an improvement. Though it would still leave me puzzled when finding a section about signing just below. Is changing heading (5) too big a change? Like so: diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 08352de..71898dc 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -246,7 +246,7 @@ patch. *2* The mailing list: git@vger.kernel.org -(5) Sign your work +(5) Certify your work by signing off. To improve tracking of who did what, we've borrowed the "sign-off" procedure from the Linux kernel project on patches ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2017-01-25 0:43 ` Cornelius Weig @ 2017-01-25 0:52 ` Stefan Beller 0 siblings, 0 replies; 1767+ messages in thread From: Stefan Beller @ 2017-01-25 0:52 UTC (permalink / raw) To: Cornelius Weig Cc: Johannes Sixt, bitte.keine.werbung.einwerfen, git@vger.kernel.org, Junio C Hamano, thomas.braun, John Keeping On Tue, Jan 24, 2017 at 4:43 PM, Cornelius Weig <cornelius.weig@tngtech.com> wrote: > -(5) Sign your work > +(5) Certify your work by signing off. That sounds better than what I proposed. Thanks, Stefan ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2017-01-25 0:21 ` Stefan Beller 2017-01-25 0:43 ` Cornelius Weig @ 2017-01-25 0:54 ` Linus Torvalds 2017-01-25 1:32 ` Re: Eric Wong 1 sibling, 1 reply; 1767+ messages in thread From: Linus Torvalds @ 2017-01-25 0:54 UTC (permalink / raw) To: Stefan Beller Cc: cornelius.weig, Johannes Sixt, bitte.keine.werbung.einwerfen, Git Mailing List, Junio C Hamano, thomas.braun, John Keeping On Tue, Jan 24, 2017 at 4:21 PM, Stefan Beller <sbeller@google.com> wrote: > > +Do not PGP sign your patch. Most likely, your maintainer or other > +people on the list would not have your PGP key and would not bother > +obtaining it anyway. I think even that could be further simplified - by just removing all comments about pgp email Because it's not that the PGP keys would be hard to get, it's that PGP-signed email is an abject failure, and nobody sane does it. Google for "phil zimmerman doesn't use pgp email". It's dead. So I'm not sure it's worth mentioning at all. You might as well talk about how you shouldn't use EBCDIC encoding for your patches, or about why git assumes that an email address has an '@' sign in it, instead of being an UUCP bang path address. Linus ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2017-01-25 0:54 ` Re: Linus Torvalds @ 2017-01-25 1:32 ` Eric Wong 0 siblings, 0 replies; 1767+ messages in thread From: Eric Wong @ 2017-01-25 1:32 UTC (permalink / raw) To: Linus Torvalds Cc: Stefan Beller, cornelius.weig, Johannes Sixt, bitte.keine.werbung.einwerfen, git, Junio C Hamano, thomas.braun, John Keeping Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Jan 24, 2017 at 4:21 PM, Stefan Beller <sbeller@google.com> wrote: > > > > +Do not PGP sign your patch. Most likely, your maintainer or other > > +people on the list would not have your PGP key and would not bother > > +obtaining it anyway. > > I think even that could be further simplified - by just removing all > comments about pgp email > > Because it's not that the PGP keys would be hard to get, it's that > PGP-signed email is an abject failure, and nobody sane does it. > > Google for "phil zimmerman doesn't use pgp email". > > It's dead. So I'm not sure it's worth mentioning at all. I disagree, we still see it, and Debian still advocates it. In fact, we may also want to mention S/MIME in the same breath: https://public-inbox.org/git/20170110004031.57985-2-hansenr@google.com/ Richard's more recent mails seem to indicate he's reformed :) ^ permalink raw reply [flat|nested] 1767+ messages in thread
* re: @ 2016-11-15 4:40 Apply 0 siblings, 0 replies; 1767+ messages in thread From: Apply @ 2016-11-15 4:40 UTC (permalink / raw) To: Recipients Do you need loan?we offer all kinds of loan from minimum amount of $5,000 to maximum of $2,000,000 if you are interested contact us via:internationalloanplc1@gmail.com with the information below: Full Name: Country: Loan Amount: Loan Duration: Mobile phone number: Sex: Thanks, Dr Scott. ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2016-11-09 17:55 bepi
2016-11-10 6:57 ` Alex Powell
0 siblings, 1 reply; 1767+ messages in thread
From: bepi @ 2016-11-09 17:55 UTC (permalink / raw)
To: linux-btrfs
Hi.
I'm making a script for managing btrfs.
To perform the scrub, to create and send (even to a remote system) of the backup
snapshot (or for one copy of the current state of the data).
The script is designed to:
- Be easy to use:
- The preparation is carried out automatically.
- Autodetect of the subvolume mounted.
- Be safe and robust:
- Check that not exist a another btrfs managing already started.
- Subvolume for created and received snapshot are mounted and accessible only
for the time necessary to perform the requested operation.
- Verify that the snapshot and sending snapshot are been executed completely.
- Progressive numbering of the snapshots for identify with certainty
the latest snapshot.
Are also available command for view the list of snaphost present, command for
delete the snapshots.
For example:
btrsfManage SCRUB /
btrsfManage SNAPSHOT /
btrsfManage SEND / /dev/sda1
btrsfManage SEND / root@gdb.exnet.it/dev/sda1
btrsfManage SNAPLIST /dev/sda1
btrsfManage SNAPDEL /dev/sda1 "root-2016-11*"
You are interested?
Gdb
----------------------------------------------------
This mail has been sent using Alpikom webmail system
http://www.alpikom.it
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2016-11-09 17:55 bepi @ 2016-11-10 6:57 ` Alex Powell 2016-11-10 13:00 ` Re: bepi 0 siblings, 1 reply; 1767+ messages in thread From: Alex Powell @ 2016-11-10 6:57 UTC (permalink / raw) To: bepi; +Cc: linux-btrfs Hi, It would be good but perhaps each task should be created via cronjobs instead of having a script running all the time or one script via one cronjob Working in the enterprise environment for a major bank, we quickly learn that these sort of daily tasks should be split up Kind Regards, Alex On Thu, Nov 10, 2016 at 4:25 AM, <bepi@adria.it> wrote: > Hi. > > I'm making a script for managing btrfs. > > To perform the scrub, to create and send (even to a remote system) of the backup > snapshot (or for one copy of the current state of the data). > > The script is designed to: > - Be easy to use: > - The preparation is carried out automatically. > - Autodetect of the subvolume mounted. > - Be safe and robust: > - Check that not exist a another btrfs managing already started. > - Subvolume for created and received snapshot are mounted and accessible only > for the time necessary to perform the requested operation. > - Verify that the snapshot and sending snapshot are been executed completely. > - Progressive numbering of the snapshots for identify with certainty > the latest snapshot. > > Are also available command for view the list of snaphost present, command for > delete the snapshots. > > For example: > > btrsfManage SCRUB / > btrsfManage SNAPSHOT / > btrsfManage SEND / /dev/sda1 > btrsfManage SEND / root@gdb.exnet.it/dev/sda1 > btrsfManage SNAPLIST /dev/sda1 > btrsfManage SNAPDEL /dev/sda1 "root-2016-11*" > > You are interested? > > Gdb > > > ---------------------------------------------------- > This mail has been sent using Alpikom webmail system > http://www.alpikom.it > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2016-11-10 6:57 ` Alex Powell @ 2016-11-10 13:00 ` bepi 0 siblings, 0 replies; 1767+ messages in thread From: bepi @ 2016-11-10 13:00 UTC (permalink / raw) To: Alex Powell; +Cc: linux-btrfs Hi. P.S. Sorry for the double sending and for the blank email subject. Yes. The various controls are designed to be used separated, and to be launched both as cronjobs and manually. For example you can create a series of snapshots btrsfManage SNAPSHOT / and send the new snapshots (incremental stream) btrsfManage SEND / /dev/sda1 in cronjobs or manually, it is indifferent. Best regards. Gdb Scrive Alex Powell <alexj.powellalt@googlemail.com>: > Hi, > It would be good but perhaps each task should be created via cronjobs > instead of having a script running all the time or one script via one > cronjob > > Working in the enterprise environment for a major bank, we quickly > learn that these sort of daily tasks should be split up > > Kind Regards, > Alex > > On Thu, Nov 10, 2016 at 4:25 AM, <bepi@adria.it> wrote: > > Hi. > > > > I'm making a script for managing btrfs. > > > > To perform the scrub, to create and send (even to a remote system) of the > backup > > snapshot (or for one copy of the current state of the data). > > > > The script is designed to: > > - Be easy to use: > > - The preparation is carried out automatically. > > - Autodetect of the subvolume mounted. > > - Be safe and robust: > > - Check that not exist a another btrfs managing already started. > > - Subvolume for created and received snapshot are mounted and accessible > only > > for the time necessary to perform the requested operation. > > - Verify that the snapshot and sending snapshot are been executed > completely. > > - Progressive numbering of the snapshots for identify with certainty > > the latest snapshot. > > > > Are also available command for view the list of snaphost present, command > for > > delete the snapshots. > > > > For example: > > > > btrsfManage SCRUB / > > btrsfManage SNAPSHOT / > > btrsfManage SEND / /dev/sda1 > > btrsfManage SEND / root@gdb.exnet.it/dev/sda1 > > btrsfManage SNAPLIST /dev/sda1 > > btrsfManage SNAPDEL /dev/sda1 "root-2016-11*" > > > > You are interested? > > > > Gdb > > > > > > ---------------------------------------------------- > > This mail has been sent using Alpikom webmail system > > http://www.alpikom.it > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > ---------------------------------------------------- This mail has been sent using Alpikom webmail system http://www.alpikom.it ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (unknown), @ 2016-11-06 21:00 Dennis Dataopslag 2016-11-07 16:50 ` Wols Lists 2016-11-17 20:33 ` Re: Dennis Dataopslag 0 siblings, 2 replies; 1767+ messages in thread From: Dennis Dataopslag @ 2016-11-06 21:00 UTC (permalink / raw) To: linux-raid Help wanted very much! My setup: Thecus N5550 NAS with 5 1TB drives installed. MD0: RAID 5 config of 4 drives (SD[ABCD]2) MD10: RAID 1 config of all 5 drives (SD..1), system generated array MD50: RAID 1 config of 4 drives (SD[ABCD]3), system generated array 1 drive (SDE) set as global hot spare. What happened: This weekend I thought it might be a good idea to do a SMART test for the drives in my NAS. I started the test on 1 drive and after it ran for a while I started the other ones. While the test was running drive 3 failed. I got a message the RAID was degraded and started rebuilding. (My assumption is that at this moment the global hot spare will automatically be added to the array) I stopped the SMART tests of all drives at this moment since it seemed logical to me the SMART test (or the outcomes) made the drive fail. In stopping the tests, drive 1 also failed!! I let it for a little but the admin interface kept telling me it was degraded, did not seem to take any actions to start rebuilding. At this point I started googling and found I should remove and reseat the drives. This is also what I did but nothing seemd to happen. The turned up as new drives in the admin interface and I re-added them to the array, they were added as spares. Even after adding them the array didn't start rebuilding. I checked stat in mdadm and it told me clean FAILED opposed to the degraded in the admin interface. I rebooted the NAS since it didn't seem to be doing anything I might interrupt. after rebooting it seemed as if the entire array had disappeared!! I started looking for options in MDADM and tried every "normal"option to rebuild the array (--assemble --scan for example) Unfortunately I cannot produce a complete list since I cannot find how to get it from the logging. Finally I mdadm --create a new array with the original 4 drives with all the right settings. (Got them from 1 of the original volumes) The creation worked but after creation it doesn't seem to have a valid partition table. This is the point where I realized I probably fucked it up big-time and should call in the help squad!!! What I think went wrong is that I re-created an array with the original 4 drives from before the first failure but the hot-spare was already added? The most important data from the array is saved in an offline backup luckily but I would very much like it if there is any way I could restore the data from the array. Is there any way I could get it back online? ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2016-11-06 21:00 (unknown), Dennis Dataopslag @ 2016-11-07 16:50 ` Wols Lists 2016-11-07 17:13 ` Re: Wols Lists 2016-11-17 20:33 ` Re: Dennis Dataopslag 1 sibling, 1 reply; 1767+ messages in thread From: Wols Lists @ 2016-11-07 16:50 UTC (permalink / raw) To: Dennis Dataopslag, linux-raid On 06/11/16 21:00, Dennis Dataopslag wrote: > Help wanted very much! Quick response ... > > My setup: > Thecus N5550 NAS with 5 1TB drives installed. > > MD0: RAID 5 config of 4 drives (SD[ABCD]2) > MD10: RAID 1 config of all 5 drives (SD..1), system generated array > MD50: RAID 1 config of 4 drives (SD[ABCD]3), system generated array > > 1 drive (SDE) set as global hot spare. > Bit late now, but you would probably have been better with raid-6. > > What happened: > This weekend I thought it might be a good idea to do a SMART test for > the drives in my NAS. > I started the test on 1 drive and after it ran for a while I started > the other ones. > While the test was running drive 3 failed. I got a message the RAID > was degraded and started rebuilding. (My assumption is that at this > moment the global hot spare will automatically be added to the array) > > I stopped the SMART tests of all drives at this moment since it seemed > logical to me the SMART test (or the outcomes) made the drive fail. > In stopping the tests, drive 1 also failed!! > I let it for a little but the admin interface kept telling me it was > degraded, did not seem to take any actions to start rebuilding. It can't - there's no spare drive to rebuild on, and there aren't enough drives to build a working array. > At this point I started googling and found I should remove and reseat > the drives. This is also what I did but nothing seemd to happen. > The turned up as new drives in the admin interface and I re-added them > to the array, they were added as spares. > Even after adding them the array didn't start rebuilding. > I checked stat in mdadm and it told me clean FAILED opposed to the > degraded in the admin interface. Yup. You've only got two drives of a four-drive raid 5. Where did you google? Did you read the linux raid wiki? https://raid.wiki.kernel.org/index.php/Linux_Raid > > I rebooted the NAS since it didn't seem to be doing anything I might interrupt. > after rebooting it seemed as if the entire array had disappeared!! > I started looking for options in MDADM and tried every "normal"option > to rebuild the array (--assemble --scan for example) > Unfortunately I cannot produce a complete list since I cannot find how > to get it from the logging. > > Finally I mdadm --create a new array with the original 4 drives with > all the right settings. (Got them from 1 of the original volumes) OUCH OUCH OUCH! Are you sure you've got the right settings? A lot of "hidden" settings have changed their values over the years. Do you know which mdadm was used to create the array in the first place? > The creation worked but after creation it doesn't seem to have a valid > partition table. This is the point where I realized I probably fucked > it up big-time and should call in the help squad!!! > What I think went wrong is that I re-created an array with the > original 4 drives from before the first failure but the hot-spare was > already added? Nope. You've probably used a newer version of mdadm. That's assuming the array is still all the original drives. If some of them have been replaced you've got a still messier problem. > > The most important data from the array is saved in an offline backup > luckily but I would very much like it if there is any way I could > restore the data from the array. > > Is there any way I could get it back online? You're looking at a big forensic job. I've moved the relevant page to the archaeology area - probably a bit too soon - but you need to read the following page https://raid.wiki.kernel.org/index.php/Reconstruction Especially the bit about overlays. And wait for the experts to chime in about how to do a hexdump and work out the values you need to pass to mdadm to get the array back. It's a lot of work and you could be looking at a week what with the delays as you wait for replies. I think it's recoverable. Is it worth it? Cheers, Wol ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2016-11-07 16:50 ` Wols Lists @ 2016-11-07 17:13 ` Wols Lists 0 siblings, 0 replies; 1767+ messages in thread From: Wols Lists @ 2016-11-07 17:13 UTC (permalink / raw) To: Dennis Dataopslag, linux-raid On 07/11/16 16:50, Wols Lists wrote: > You're looking at a big forensic job. I've moved the relevant page to > the archaeology area - probably a bit too soon - but you need to read > the following page > > https://raid.wiki.kernel.org/index.php/Reconstruction > > Especially the bit about overlays. And wait for the experts to chime in > about how to do a hexdump and work out the values you need to pass to > mdadm to get the array back. It's a lot of work and you could be looking > at a week what with the delays as you wait for replies. Whoops, sorry. Wrong page, you need this one ... https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID Cheers, Wol ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2016-11-06 21:00 (unknown), Dennis Dataopslag 2016-11-07 16:50 ` Wols Lists @ 2016-11-17 20:33 ` Dennis Dataopslag 2016-11-17 22:12 ` Re: Wols Lists 1 sibling, 1 reply; 1767+ messages in thread From: Dennis Dataopslag @ 2016-11-17 20:33 UTC (permalink / raw) To: linux-raid CHeers for the reaction and sorry for my late response, I've been out for business. Trying to rebuild this RAID is definately worth it for me. The learning experience alone already makes it worth. I did read the wiki page and tried several steps that are on there but it didn't seem to get me out of trouble. I used this information from the drive, obviously didn't search for any "hidden" settings: " Magic : a92b4efc Version : 1.2 Feature Map : 0x0 Array UUID : 36fdeb4b:c5360009:0958ad1e:17da451b Name : TRD106:0 (local to host TRD106) Creation Time : Fri Oct 10 12:27:27 2014 Raid Level : raid5 Raid Devices : 4 Avail Dev Size : 1948250112 (929.00 GiB 997.50 GB) Array Size : 5844750336 (2786.99 GiB 2992.51 GB) Data Offset : 2048 sectors Super Offset : 8 sectors State : clean Device UUID : b49e2752:d37dac6c:8764c52a:372277bd Update Time : Sat Nov 5 14:40:33 2016 Checksum : d47a9ad4 - correct Events : 14934 Layout : left-symmetric Chunk Size : 64K Device Role : Active device 0 Array State : AAAA ('A' == active, '.' == missing)" Anybody that can give me a little extra push? On 06/11/16 21:00, Dennis Dataopslag wrote: > Help wanted very much! Quick response ... > > My setup: > Thecus N5550 NAS with 5 1TB drives installed. > > MD0: RAID 5 config of 4 drives (SD[ABCD]2) > MD10: RAID 1 config of all 5 drives (SD..1), system generated array > MD50: RAID 1 config of 4 drives (SD[ABCD]3), system generated array > > 1 drive (SDE) set as global hot spare. > Bit late now, but you would probably have been better with raid-6. > > What happened: > This weekend I thought it might be a good idea to do a SMART test for > the drives in my NAS. > I started the test on 1 drive and after it ran for a while I started > the other ones. > While the test was running drive 3 failed. I got a message the RAID > was degraded and started rebuilding. (My assumption is that at this > moment the global hot spare will automatically be added to the array) > > I stopped the SMART tests of all drives at this moment since it seemed > logical to me the SMART test (or the outcomes) made the drive fail. > In stopping the tests, drive 1 also failed!! > I let it for a little but the admin interface kept telling me it was > degraded, did not seem to take any actions to start rebuilding. It can't - there's no spare drive to rebuild on, and there aren't enough drives to build a working array. > At this point I started googling and found I should remove and reseat > the drives. This is also what I did but nothing seemd to happen. > The turned up as new drives in the admin interface and I re-added them > to the array, they were added as spares. > Even after adding them the array didn't start rebuilding. > I checked stat in mdadm and it told me clean FAILED opposed to the > degraded in the admin interface. Yup. You've only got two drives of a four-drive raid 5. Where did you google? Did you read the linux raid wiki? https://raid.wiki.kernel.org/index.php/Linux_Raid > > I rebooted the NAS since it didn't seem to be doing anything I might interrupt. > after rebooting it seemed as if the entire array had disappeared!! > I started looking for options in MDADM and tried every "normal"option > to rebuild the array (--assemble --scan for example) > Unfortunately I cannot produce a complete list since I cannot find how > to get it from the logging. > > Finally I mdadm --create a new array with the original 4 drives with > all the right settings. (Got them from 1 of the original volumes) OUCH OUCH OUCH! Are you sure you've got the right settings? A lot of "hidden" settings have changed their values over the years. Do you know which mdadm was used to create the array in the first place? > The creation worked but after creation it doesn't seem to have a valid > partition table. This is the point where I realized I probably fucked > it up big-time and should call in the help squad!!! > What I think went wrong is that I re-created an array with the > original 4 drives from before the first failure but the hot-spare was > already added? Nope. You've probably used a newer version of mdadm. That's assuming the array is still all the original drives. If some of them have been replaced you've got a still messier problem. > > The most important data from the array is saved in an offline backup > luckily but I would very much like it if there is any way I could > restore the data from the array. > > Is there any way I could get it back online? You're looking at a big forensic job. I've moved the relevant page to the archaeology area - probably a bit too soon - but you need to read the following page https://raid.wiki.kernel.org/index.php/Reconstruction Especially the bit about overlays. And wait for the experts to chime in about how to do a hexdump and work out the values you need to pass to mdadm to get the array back. It's a lot of work and you could be looking at a week what with the delays as you wait for replies. I think it's recoverable. Is it worth it? Cheers, Wol On Sun, Nov 6, 2016 at 10:00 PM, Dennis Dataopslag <dennisdataopslag@gmail.com> wrote: > Help wanted very much! > > My setup: > Thecus N5550 NAS with 5 1TB drives installed. > > MD0: RAID 5 config of 4 drives (SD[ABCD]2) > MD10: RAID 1 config of all 5 drives (SD..1), system generated array > MD50: RAID 1 config of 4 drives (SD[ABCD]3), system generated array > > 1 drive (SDE) set as global hot spare. > > > What happened: > This weekend I thought it might be a good idea to do a SMART test for > the drives in my NAS. > I started the test on 1 drive and after it ran for a while I started > the other ones. > While the test was running drive 3 failed. I got a message the RAID > was degraded and started rebuilding. (My assumption is that at this > moment the global hot spare will automatically be added to the array) > > I stopped the SMART tests of all drives at this moment since it seemed > logical to me the SMART test (or the outcomes) made the drive fail. > In stopping the tests, drive 1 also failed!! > I let it for a little but the admin interface kept telling me it was > degraded, did not seem to take any actions to start rebuilding. > At this point I started googling and found I should remove and reseat > the drives. This is also what I did but nothing seemd to happen. > The turned up as new drives in the admin interface and I re-added them > to the array, they were added as spares. > Even after adding them the array didn't start rebuilding. > I checked stat in mdadm and it told me clean FAILED opposed to the > degraded in the admin interface. > > I rebooted the NAS since it didn't seem to be doing anything I might interrupt. > after rebooting it seemed as if the entire array had disappeared!! > I started looking for options in MDADM and tried every "normal"option > to rebuild the array (--assemble --scan for example) > Unfortunately I cannot produce a complete list since I cannot find how > to get it from the logging. > > Finally I mdadm --create a new array with the original 4 drives with > all the right settings. (Got them from 1 of the original volumes) > The creation worked but after creation it doesn't seem to have a valid > partition table. This is the point where I realized I probably fucked > it up big-time and should call in the help squad!!! > What I think went wrong is that I re-created an array with the > original 4 drives from before the first failure but the hot-spare was > already added? > > The most important data from the array is saved in an offline backup > luckily but I would very much like it if there is any way I could > restore the data from the array. > > Is there any way I could get it back online? ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2016-11-17 20:33 ` Re: Dennis Dataopslag @ 2016-11-17 22:12 ` Wols Lists 0 siblings, 0 replies; 1767+ messages in thread From: Wols Lists @ 2016-11-17 22:12 UTC (permalink / raw) To: Dennis Dataopslag, linux-raid On 17/11/16 20:33, Dennis Dataopslag wrote: > CHeers for the reaction and sorry for my late response, I've been out > for business. > > Trying to rebuild this RAID is definately worth it for me. The > learning experience alone already makes it worth. > > I did read the wiki page and tried several steps that are on there but > it didn't seem to get me out of trouble. > > I used this information from the drive, obviously didn't search for > any "hidden" settings: > " Magic : a92b4efc > Version : 1.2 > Feature Map : 0x0 > Array UUID : 36fdeb4b:c5360009:0958ad1e:17da451b > Name : TRD106:0 (local to host TRD106) > Creation Time : Fri Oct 10 12:27:27 2014 > Raid Level : raid5 > Raid Devices : 4 > > Avail Dev Size : 1948250112 (929.00 GiB 997.50 GB) > Array Size : 5844750336 (2786.99 GiB 2992.51 GB) > Data Offset : 2048 sectors > Super Offset : 8 sectors > State : clean > Device UUID : b49e2752:d37dac6c:8764c52a:372277bd > > Update Time : Sat Nov 5 14:40:33 2016 > Checksum : d47a9ad4 - correct > Events : 14934 > > Layout : left-symmetric > Chunk Size : 64K > > Device Role : Active device 0 > Array State : AAAA ('A' == active, '.' == missing)" > > Anybody that can give me a little extra push? > Others will be able to help better than me, but you might want to look for the thread "RAID10 with 2 drives auto-assembled as RAID1". This will give you some information about how to run hexdump and find where your filesystems are on the array. There's plenty of other threads with this sort of information, but this will give you a starting point. If Phil Turmel sees this, he'll chime in with better detail. Cheers, Wol ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject) @ 2016-09-27 16:50 Rajat Jain 2016-09-27 16:57 ` Rajat Jain 0 siblings, 1 reply; 1767+ messages in thread From: Rajat Jain @ 2016-09-27 16:50 UTC (permalink / raw) To: Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo, linux-wireless, netdev Cc: Wei-Ning Huang, Brian Norris, Eric Caruso, rajatxjain, Rajat Jain From: Wei-Ning Huang <wnhuang@google.com> Date: Thu, 17 Mar 2016 11:43:16 +0800 Subject: [PATCH] mwifiex: report wakeup for wowlan Enable notifying wakeup source to the PM core. This allow darkresume to correctly track wakeup source and mark mwifiex_plt as 'automatic' wakeup source. Signed-off-by: Wei-Ning Huang <wnhuang@google.com> Signed-off-by: Rajat Jain <rajatja@google.com> Tested-by: Wei-Ning Huang <wnhuang@chromium.org> Reviewed-by: Eric Caruso <ejcaruso@chromium.org> --- drivers/net/wireless/marvell/mwifiex/sdio.c | 8 ++++++++ drivers/net/wireless/marvell/mwifiex/sdio.h | 1 + 2 files changed, 9 insertions(+) diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c index d3e1561..a5f63e4 100644 --- a/drivers/net/wireless/marvell/mwifiex/sdio.c +++ b/drivers/net/wireless/marvell/mwifiex/sdio.c @@ -89,6 +89,9 @@ static irqreturn_t mwifiex_wake_irq_wifi(int irq, void *priv) disable_irq_nosync(irq); } + /* Notify PM core we are wakeup source */ + pm_wakeup_event(cfg->dev, 0); + return IRQ_HANDLED; } @@ -112,6 +115,7 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card) GFP_KERNEL); cfg = card->plt_wake_cfg; if (cfg && card->plt_of_node) { + cfg->dev = dev; cfg->irq_wifi = irq_of_parse_and_map(card->plt_of_node, 0); if (!cfg->irq_wifi) { dev_dbg(dev, @@ -130,6 +134,10 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card) } } + ret = device_init_wakeup(dev, true); + if (ret) + dev_err(dev, "fail to init wakeup for mwifiex"); + return 0; } diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h b/drivers/net/wireless/marvell/mwifiex/sdio.h index db837f1..07cdd23 100644 --- a/drivers/net/wireless/marvell/mwifiex/sdio.h +++ b/drivers/net/wireless/marvell/mwifiex/sdio.h @@ -155,6 +155,7 @@ } while (0) struct mwifiex_plt_wake_cfg { + struct device *dev; int irq_wifi; bool wake_by_wifi; }; -- 2.8.0.rc3.226.g39d4020 ^ permalink raw reply related [flat|nested] 1767+ messages in thread
* Re: 2016-09-27 16:50 Rajat Jain @ 2016-09-27 16:57 ` Rajat Jain 0 siblings, 0 replies; 1767+ messages in thread From: Rajat Jain @ 2016-09-27 16:57 UTC (permalink / raw) To: Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo, linux-wireless, netdev Cc: Wei-Ning Huang, Brian Norris, Eric Caruso, Rajat Jain, Rajat Jain Please ignore, not sure why this landed without a subject. On Tue, Sep 27, 2016 at 9:50 AM, Rajat Jain <rajatja@google.com> wrote: > From: Wei-Ning Huang <wnhuang@google.com> > > Date: Thu, 17 Mar 2016 11:43:16 +0800 > Subject: [PATCH] mwifiex: report wakeup for wowlan > > Enable notifying wakeup source to the PM core. This allow darkresume to > correctly track wakeup source and mark mwifiex_plt as 'automatic' wakeup > source. > > Signed-off-by: Wei-Ning Huang <wnhuang@google.com> > Signed-off-by: Rajat Jain <rajatja@google.com> > Tested-by: Wei-Ning Huang <wnhuang@chromium.org> > Reviewed-by: Eric Caruso <ejcaruso@chromium.org> > --- > drivers/net/wireless/marvell/mwifiex/sdio.c | 8 ++++++++ > drivers/net/wireless/marvell/mwifiex/sdio.h | 1 + > 2 files changed, 9 insertions(+) > > diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c > index d3e1561..a5f63e4 100644 > --- a/drivers/net/wireless/marvell/mwifiex/sdio.c > +++ b/drivers/net/wireless/marvell/mwifiex/sdio.c > @@ -89,6 +89,9 @@ static irqreturn_t mwifiex_wake_irq_wifi(int irq, void *priv) > disable_irq_nosync(irq); > } > > + /* Notify PM core we are wakeup source */ > + pm_wakeup_event(cfg->dev, 0); > + > return IRQ_HANDLED; > } > > @@ -112,6 +115,7 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card) > GFP_KERNEL); > cfg = card->plt_wake_cfg; > if (cfg && card->plt_of_node) { > + cfg->dev = dev; > cfg->irq_wifi = irq_of_parse_and_map(card->plt_of_node, 0); > if (!cfg->irq_wifi) { > dev_dbg(dev, > @@ -130,6 +134,10 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card) > } > } > > + ret = device_init_wakeup(dev, true); > + if (ret) > + dev_err(dev, "fail to init wakeup for mwifiex"); > + > return 0; > } > > diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h b/drivers/net/wireless/marvell/mwifiex/sdio.h > index db837f1..07cdd23 100644 > --- a/drivers/net/wireless/marvell/mwifiex/sdio.h > +++ b/drivers/net/wireless/marvell/mwifiex/sdio.h > @@ -155,6 +155,7 @@ > } while (0) > > struct mwifiex_plt_wake_cfg { > + struct device *dev; > int irq_wifi; > bool wake_by_wifi; > }; > -- > 2.8.0.rc3.226.g39d4020 > ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: @ 2016-09-10 21:51 Michelle Ouellette 0 siblings, 0 replies; 1767+ messages in thread From: Michelle Ouellette @ 2016-09-10 21:51 UTC (permalink / raw) To: barebox Hello,My name is Gloria Mackenzie, i have a donation to make for less privilege, am writing you with a friend's email, please contact me on gloria.mackenzie001@rogers.com _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 1767+ messages in thread
* (no subject)
@ 2016-09-01 2:02 Fennec Fox
2016-09-01 3:10 ` Jeff Mahoney
0 siblings, 1 reply; 1767+ messages in thread
From: Fennec Fox @ 2016-09-01 2:02 UTC (permalink / raw)
To: linux-btrfs
Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37 UTC
2016 x86_64 GNU/Linux
btrfs-progs v4.7
Data, single: total=30.01GiB, used=18.95GiB
System, single: total=4.00MiB, used=16.00KiB
Metadata, single: total=1.01GiB, used=422.17MiB
GlobalReserve, single: total=144.00MiB, used=0.00B
{02:50} Wed Aug 31
[fennectech@Titanium ~]$ sudo fstrim -v /
[sudo] password for fennectech:
Sorry, try again.
[sudo] password for fennectech:
/: 99.8 GiB (107167244288 bytes) trimmed
{03:08} Wed Aug 31
[fennectech@Titanium ~]$ sudo fstrim -v /
[sudo] password for fennectech:
/: 99.9 GiB (107262181376 bytes) trimmed
I ran these commands minutes after echother ane each time it is
trimming the entire free space
Anyone else seen this? the filesystem is the root FS and is compressed
--
Fennec
^ permalink raw reply [flat|nested] 1767+ messages in thread* Re: 2016-09-01 2:02 Fennec Fox @ 2016-09-01 3:10 ` Jeff Mahoney 2016-09-01 19:32 ` Re: Kai Krakow 0 siblings, 1 reply; 1767+ messages in thread From: Jeff Mahoney @ 2016-09-01 3:10 UTC (permalink / raw) To: Fennec Fox, linux-btrfs [-- Attachment #1.1: Type: text/plain, Size: 1087 bytes --] On 8/31/16 10:02 PM, Fennec Fox wrote: > Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37 UTC > 2016 x86_64 GNU/Linux > btrfs-progs v4.7 > > Data, single: total=30.01GiB, used=18.95GiB > System, single: total=4.00MiB, used=16.00KiB > Metadata, single: total=1.01GiB, used=422.17MiB > GlobalReserve, single: total=144.00MiB, used=0.00B > > {02:50} Wed Aug 31 > [fennectech@Titanium ~]$ sudo fstrim -v / > [sudo] password for fennectech: > Sorry, try again. > [sudo] password for fennectech: > /: 99.8 GiB (107167244288 bytes) trimmed > > {03:08} Wed Aug 31 > [fennectech@Titanium ~]$ sudo fstrim -v / > [sudo] password for fennectech: > /: 99.9 GiB (107262181376 bytes) trimmed > > I ran these commands minutes after echother ane each time it is > trimming the entire free space > > Anyone else seen this? the filesystem is the root FS and is compressed > Yes. It's working as intended. We don't track what space has already been trimmed anywhere, so it trims all unallocated space. -Jeff -- Jeff Mahoney SUSE Labs [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 827 bytes --] ^ permalink raw reply [flat|nested] 1767+ messages in thread
* Re: 2016-09-01 3:10 ` Jeff Mahoney @ 2016-09-01 19:32 ` Kai Krakow 0 siblings, 0 replies; 1767+ messages in thread From: Kai Krakow @ 2016-09-01 19:32 UTC (permalink / raw) To: linux-btrfs [-- Attachment #1: Type: text/plain, Size: 1823 bytes --] Am Wed, 31 Aug 2016 23:10:13 -0400 schrieb Jeff Mahoney <jeffm@suse.com>: > On 8/31/16 10:02 PM, Fennec Fox wrote: > > Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37 > > UTC 2016 x86_64 GNU/Linux > > btrfs-progs v4.7 > > > > Data, single: total=30.01GiB, used=18.95GiB > > System, single: total=4.00MiB, used=16.00KiB > > Metadata, single: total=1.01GiB, used=422.17MiB > > GlobalReserve, single: total=144.00MiB, used=0.00B > > > > {02:50} Wed Aug 31 > > [fennectech@Titanium ~]$ sudo fstrim -v / > > [sudo] password for fennectech: > > Sorry, try again. > > [sudo] password for fennectech: > > /: 99.8 GiB (107167244288 bytes) trimmed > > > > {03:08} Wed Aug 31 > > [fennectech@Titanium ~]$ sudo fstrim -v / > > [sudo] password for fennectech: > > /: 99.9 GiB (107262181376 bytes) trimmed > > > > I ran these commands minutes after echother ane each time it is > > trimming the entire free space > > > > Anyone else seen this? the filesystem is the root FS and is > > compressed > > Yes. It's working as intended. We don't track what space has already > been trimmed anywhere, so it trims all unallocated space. I wonder, does it work in a multi device scenario? When btrfs pools multiple devices together? I ask because fstrim seems to always report the estimated free space, not the raw free space, as trimmed. OTOH, this may simply be because btrfs reports 1.08 TiB unallocated while fstrim reports 1.2 TB trimmed (and not TiB) - which when "converted" (1.08 * 1024^4 / 1000^4 ~= 1.18) perfectly rounds to 1.2. Coincidence is free estimated space is 1.19 TiB for me (which would also round to 1.2) and these numbers, as they are in the TB range, won't change so fast for me. -- Regards, Kai Replies to list-only preferred. [-- Attachment #2: Digitale Signatur von OpenPGP --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 1767+ messages in thread
end of thread, other threads:[~2026-05-09 18:07 UTC | newest]
Thread overview: 1767+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-08-12 17:43 [PATCH 6.15 000/480] 6.15.10-rc1 review Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 001/480] drm/radeon: Do not hold console lock while suspending clients Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 002/480] ASoC: amd: yc: Add DMI quirk for HP Laptop 17 cp-2033dx Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 003/480] ethernet: intel: fix building with large NR_CPUS Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 004/480] ASoC: amd: yc: Add DMI entries to support HP 15-fb1xxx Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 005/480] ALSA: hda/cs35l56: Workaround bad dev-index on Lenovo Yoga Book 9i GenX Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 006/480] ALSA: hda/realtek: Support mute LED for Yoga with ALC287 Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 007/480] ASoC: Intel: fix SND_SOC_SOF dependencies Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 008/480] ASoC: amd: yc: add DMI quirk for ASUS M6501RM Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 009/480] audit,module: restore audit logging in load failure case Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 010/480] [ceph] parse_longname(): strrchr() expects NUL-terminated string Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 011/480] fs_context: fix parameter name in infofc() macro Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 012/480] selftests/landlock: Fix readlink check Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 013/480] selftests/landlock: Fix build of audit_test Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 014/480] fs/ntfs3: cancle set bad inode after removing name fails Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 015/480] landlock: Fix warning from KUnit tests Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 016/480] ublk: use vmalloc for ublk_devices __queues Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 017/480] hfsplus: make splice write available again Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 018/480] hfs: " Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 019/480] hfsplus: remove mutex_lock check in hfsplus_free_extents Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 020/480] Revert "fs/ntfs3: Replace inode_trylock with inode_lock" Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 021/480] block: mtip32xx: Fix usage of dma_map_sg() Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 022/480] gfs2: Minor do_xmote cancelation fix Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 023/480] md: allow removing faulty rdev during resync Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 024/480] kunit/fortify: Add back "volatile" for sizeof() constants Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 025/480] gfs2: No more self recovery Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 026/480] block: sanitize chunk_sectors for atomic write limits Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 027/480] io_uring: fix breakage in EXPERT menu Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 028/480] btrfs: remove partial support for lowest level from btrfs_search_forward() Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 029/480] ASoC: soc-dai: tidyup return value of snd_soc_xlate_tdm_slot_mask() Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 030/480] ASoC: amd: acp: Fix pointer assignments for snd_soc_acpi_mach structures Greg Kroah-Hartman
2025-08-12 17:43 ` [PATCH 6.15 031/480] ASoC: ops: dynamically allocate struct snd_ctl_elem_value Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 032/480] ASoC: mediatek: use reserved memory or enable buffer pre-allocation Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 033/480] arm64: dts: freescale: imx93-tqma9352: Limit BUCK2 to 600mV Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 034/480] selftests: Fix errno checking in syscall_user_dispatch test Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 035/480] soc: qcom: QMI encoding/decoding for big endian Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 036/480] arm64: dts: qcom: qcs615: fix a crash issue caused by infinite loop for Coresight Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 037/480] arm64: dts: qcom: sdm845: Expand IMEM region Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 038/480] arm64: dts: qcom: sc7180: " Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 039/480] arm64: dts: qcom: qcs615: disable the CTI device of the camera block Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 040/480] arm64: dts: exynos: gs101: Add local-timer-stop to cpuidle nodes Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 041/480] arm64: dts: qcom: sa8775p: Correct the interrupt for remoteproc Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 042/480] arm64: dts: qcom: msm8976: Make blsp_dma controlled-remotely Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 043/480] pm: cpupower: Fix printing of CORE, CPU fields in cpupower-monitor Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 044/480] ARM: dts: vfxxx: Correctly use two tuples for timer address Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 045/480] usb: host: xhci-plat: fix incorrect type for of_match variable in xhci_plat_probe() Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 046/480] usb: misc: apple-mfi-fastcharge: Make power supply names unique Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 047/480] arm64: dts: ti: k3-am642-phyboard-electra: Fix PRU-ICSSG Ethernet ports Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 048/480] arm64: dts: ti: k3-am62p-j722s: fix pinctrl-single size Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 049/480] ARM: dts: microchip: sama7d65: Add clock name property Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 050/480] ARM: dts: microchip: sam9x7: " Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 051/480] cpufreq: armada-8k: make both cpu masks static Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 052/480] firmware: arm_scmi: Fix up turbo frequencies selection Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 053/480] usb: typec: ucsi: yoga-c630: fix error and remove paths Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 054/480] mei: vsc: Dont re-init VSC from mei_vsc_hw_reset() on stop Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 055/480] mei: vsc: Destroy mutex after freeing the IRQ Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 056/480] mei: vsc: Event notifier fixes Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 057/480] mei: vsc: Unset the event callback on remove and probe errors Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 058/480] spi: stm32: Check for cfg availability in stm32_spi_probe Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 059/480] drivers: misc: sram: fix up some const issues with recent attribute changes Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 060/480] power: sequencing: qcom-wcn: fix bluetooth-wifi copypasta for WCN6855 Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 061/480] arm64: dts: rockchip: Enable eMMC HS200 mode on Radxa E20C Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 062/480] staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc() Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 063/480] rust: miscdevice: clarify invariant for `MiscDeviceRegistration` Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 064/480] vmci: Prevent the dispatching of uninitialized payloads Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 065/480] pps: fix poll support Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 066/480] arm64: dts: imx8mp-venice-gw74xx: update name of M2SKT_WDIS2# gpio Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 067/480] selftests: vDSO: chacha: Correctly skip test if necessary Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 068/480] Revert "vmci: Prevent the dispatching of uninitialized payloads" Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 069/480] powercap: dtpm_cpu: Fix NULL pointer dereference in get_pd_power_uw() Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 070/480] usb: early: xhci-dbc: Fix early_ioremap leak Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 071/480] arm: dts: ti: omap: Fixup pinheader typo Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 072/480] staging: gpib: Fix error code in board_type_ioctl() Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 073/480] staging: gpib: Fix error handling paths in cb_gpib_probe() Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 074/480] soc/tegra: cbb: Clear ERR_FORCE register with ERR_STATUS Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 075/480] arm64: dts: rockchip: fix PHY handling for ROCK 4D Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 076/480] arm64: dts: st: fix timer used for ticks Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 077/480] selftests: breakpoints: use suspend_stats to reliably check suspend success Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 078/480] ARM: dts: imx6ul-kontron-bl-common: Fix RTS polarity for RS485 interface Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 079/480] arm64: dts: imx8mm-beacon: Fix HS400 USDHC clock speed Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 080/480] arm64: dts: imx8mn-beacon: " Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 081/480] arm64: dts: rockchip: Fix pinctrl node names for RK3528 Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 082/480] PM / devfreq: Check governor before using governor->name Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 083/480] PM / devfreq: Fix a index typo in trans_stat Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 084/480] cpufreq: intel_pstate: Always use HWP_DESIRED_PERF in passive mode Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 085/480] cpufreq: Initialize cpufreq-based frequency-invariance later Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 086/480] cpufreq: Init policy->rwsem before it may be possibly used Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 087/480] ASoC: SDCA: Allow read-only controls to be deferrable Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 088/480] staging: greybus: gbphy: fix up const issue with the match callback Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 089/480] samples: mei: Fix building on musl libc Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 090/480] soc: qcom: pmic_glink: fix OF node leak Greg Kroah-Hartman
2025-08-12 17:44 ` [PATCH 6.15 091/480] interconnect: qcom: sc8280xp: specify num_links for qnm_a1noc_cfg Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 092/480] interconnect: qcom: sc8180x: specify num_nodes Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 093/480] interconnect: qcom: qcs615: Drop IP0 interconnects Greg Kroah-Hartman
2025-08-13 8:57 ` Konrad Dybcio
2025-08-12 17:45 ` [PATCH 6.15 094/480] bus: mhi: host: pci_generic: Fix the modem name of Foxconn T99W640 Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 095/480] drm/xe: Correct the rev value for the DVSEC entries Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 096/480] drm/xe: Correct BMG VSEC header sizing Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 097/480] staging: nvec: Fix incorrect null termination of battery manufacturer Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 098/480] selftests/tracing: Fix false failure of subsystem event test Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 099/480] drm/rockchip: cleanup fb when drm_gem_fb_afbc_init failed Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 100/480] drm/connector: hdmi: Evaluate limited range after computing format Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 101/480] drm/panfrost: Fix panfrost device variable name in devfreq Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 102/480] drm/panthor: Add missing explicit padding in drm_panthor_gpu_info Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 103/480] wifi: rtw89: fix EHT 20MHz TX rate for non-AP STA Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 104/480] bpf, sockmap: Fix psock incorrectly pointing to sk Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 105/480] netconsole: Only register console drivers when targets are configured Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 106/480] bpf, ktls: Fix data corruption when using bpf_msg_pop_data() in ktls Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 107/480] selftests/bpf: fix signedness bug in redir_partial() Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 108/480] bpf: handle jset (if a & b ...) as a jump in CFG computation Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 109/480] selftests/bpf: Fix unintentional switch case fall through Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 110/480] net: ipv6: ip6mr: Fix in/out netdev to pass to the FORWARD chain Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 111/480] drm/vmwgfx: Fix Host-Backed userspace on Guest-Backed kernel Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 112/480] slub: Fix a documentation build error for krealloc() Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 113/480] drm/amdgpu: Remove nbiov7.9 replay count reporting Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 114/480] bpftool: Fix memory leak in dump_xx_nlmsg on realloc failure Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 115/480] powerpc/pseries/dlpar: Search DRC index from ibm,drc-indexes for IO add Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 116/480] wifi: ath12k: Avoid accessing uninitialized arvif->ar during beacon miss Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 117/480] wifi: ath12k: Fix double budget decrement while reaping monitor ring Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 118/480] wifi: ath12k: Pass ab pointer directly to ath12k_dp_tx_get_encap_type() Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 119/480] caif: reduce stack size, again Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 120/480] wifi: rtw89: avoid NULL dereference when RX problematic packet on unsupported 6 GHz band Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 121/480] wifi: rtl818x: Kill URBs before clearing tx status queue Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 122/480] wifi: iwlwifi: Fix memory leak in iwl_mvm_init() Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 123/480] iwlwifi: Add missing check for alloc_ordered_workqueue Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 124/480] team: replace team lock with rtnl lock Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 125/480] wifi: ath11k: clear initialized flag for deinit-ed srng lists Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 126/480] wifi: ath12k: Clear auth flag only for actual association in security mode Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 127/480] tcp: fix tcp_ofo_queue() to avoid including too much DUP SACK range Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 128/480] net/mlx5: Check device memory pointer before usage Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 129/480] net: dst: annotate data-races around dst->input Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 130/480] net: dst: annotate data-races around dst->output Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 131/480] net: dst: add four helpers to annotate data-races around dst->dev Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 132/480] wifi: iwlwifi: Fix error code in iwl_op_mode_dvm_start() Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 133/480] kselftest/arm64: Fix check for setting new VLs in sve-ptrace Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 134/480] bpf: Ensure RCU lock is held around bpf_prog_ksym_find Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 135/480] drm/msm/dpu: Fill in min_prefill_lines for SC8180X Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 136/480] m68k: Dont unregister boot console needlessly Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 137/480] refscale: Check that nreaders and loops multiplication doesnt overflow Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 138/480] wifi: mt76: mt7996: Fix secondary link lookup in mt7996_mcu_sta_mld_setup_tlv() Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 139/480] wifi: mt76: mt7996: Fix possible OOB access in mt7996_tx() Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 140/480] wifi: mt76: mt7996: Fix valid_links bitmask in mt7996_mac_sta_{add,remove} Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 141/480] drm/amd/pm/powerplay/hwmgr/smu_helper: fix order of mask and value Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 142/480] wifi: ath12k: Block radio bring-up in FTM mode Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 143/480] drm/rockchip: vop2: fail cleanly if missing a primary plane for a video-port Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 144/480] drm/rockchip: vop2: Fix the update of LAYER/PORT select registers when there are multi display output on rk3588/rk3568 Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 145/480] sched/psi: Optimize psi_group_change() cpu_clock() usage Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 146/480] sched/deadline: Less agressive dl_server handling Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 147/480] fbcon: Fix outdated registered_fb reference in comment Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 148/480] netfilter: nf_tables: Drop dead code from fill_*_info routines Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 149/480] netfilter: nf_tables: adjust lockdep assertions handling Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 150/480] arch: powerpc: defconfig: Drop obsolete CONFIG_NET_CLS_TCINDEX Greg Kroah-Hartman
2025-08-12 17:45 ` [PATCH 6.15 151/480] um: rtc: Avoid shadowing err in uml_rtc_start() Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 152/480] iommu/amd: Enable PASID and ATS capabilities in the correct order Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 153/480] net/sched: Restrict conditions for adding duplicating netems to qdisc tree Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 154/480] net_sched: act_ctinfo: use atomic64_t for three counters Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 155/480] RDMA/mlx5: Fix UMR modifying of mkey page size Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 156/480] xen: fix UAF in dmabuf_exp_from_pages() Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 157/480] sched/deadline: Initialize dl_servers after SMP Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 158/480] sched/deadline: Reset extra_bw to max_bw when clearing root domains Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 159/480] iommu/vt-d: Do not wipe out the page table NID when devices detach Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 160/480] iommu/arm-smmu: disable PRR on SM8250 Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 161/480] xen/gntdev: remove struct gntdev_copy_batch from stack Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 162/480] tcp: call tcp_measure_rcv_mss() for ooo packets Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 163/480] wifi: rtl8xxxu: Fix RX skb size for aggregation disabled Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 164/480] wifi: rtw88: Fix macid assigned to TDLS station Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 165/480] mwl8k: Add missing check after DMA map Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 166/480] wifi: ath12k: Use HTT_TCL_METADATA_VER_V1 in FTM mode Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 167/480] wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask() Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 168/480] drm/amdgpu/gfx9: fix kiq locking in KCQ reset Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 169/480] drm/amdgpu/gfx9.4.3: " Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 170/480] drm/amdgpu/gfx10: " Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 171/480] selftests/bpf: fix implementation of smp_mb() Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 172/480] iommu/amd: Fix geometry.aperture_end for V2 tables Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 173/480] rcu: Fix delayed execution of hurry callbacks Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 174/480] wifi: mac80211: reject TDLS operations when station is not associated Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 175/480] wifi: plfxlc: Fix error handling in usb driver probe Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 176/480] wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac() Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 177/480] wifi: mac80211: Do not schedule stopped TXQs Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 178/480] wifi: mac80211: Dont call fq_flow_idx() for management frames Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 179/480] wifi: mac80211: Check 802.11 encaps offloading in ieee80211_tx_h_select_key() Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 180/480] Reapply "wifi: mac80211: Update skbs control block key in ieee80211_tx_dequeue()" Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 181/480] wifi: ath12k: fix endianness handling while accessing wmi service bit Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 182/480] wifi: brcmfmac: fix P2P discovery failure in P2P peer due to missing P2P IE Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 183/480] PM: cpufreq: powernv/tracing: Move powernv_throttle trace event Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 184/480] wifi: mac80211: Write cnt before copying in ieee80211_copy_rnr_beacon() Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 185/480] wifi: nl80211: Set num_sub_specs before looping through sub_specs Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 186/480] ring-buffer: Remove ring_buffer_read_prepare_sync() Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 187/480] kcsan: test: Initialize dummy variable Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 188/480] memcg_slabinfo: Fix use of PG_slab Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 189/480] wifi: mac80211: fix WARN_ON for monitor mode on some devices Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 190/480] arm64/gcs: task_gcs_el0_enable() should use passed task Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 191/480] wifi: iwlwifi: mld: decode EOF bit for AMPDUs Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 192/480] Bluetooth: hci_sync: fix double free in hci_discovery_filter_clear() Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 193/480] Bluetooth: hci_devcd_dump: fix out-of-bounds via dev_coredumpv Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 194/480] Bluetooth: hci_event: Mask data status from LE ext adv reports Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 195/480] bpf: Disable migration in nf_hook_run_bpf() Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 196/480] tools/rv: Do not skip idle in trace Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 197/480] selftests: drv-net: Fix remote command checking in require_cmd() Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 198/480] selftests: drv-net: tso: enable test cases based on hw_features Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 199/480] selftests: drv-net: tso: fix vxlan tunnel flags to get correct gso_type Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 200/480] selftests: drv-net: tso: fix non-tunneled tso6 test case name Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 201/480] can: peak_usb: fix USB FD devices potential malfunction Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 202/480] can: kvaser_pciefd: Store device channel index Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 203/480] can: kvaser_usb: Assign netdev.dev_port based on " Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 204/480] netfilter: xt_nfacct: dont assume acct name is null-terminated Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 205/480] net/mlx5e: Clear Read-Only port buffer size in PBMC before update Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 206/480] net/mlx5e: Remove skb secpath if xfrm state is not found Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 207/480] macsec: set IFF_UNICAST_FLT priv flag Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 208/480] net: dsa: microchip: Fix wrong rx drop MIB counter for KSZ8863 Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 209/480] neighbour: Fix null-ptr-deref in neigh_flush_dev() Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 210/480] stmmac: xsk: fix negative overflow of budget in zerocopy mode Greg Kroah-Hartman
2025-08-12 17:46 ` [PATCH 6.15 211/480] igb: xsk: solve negative overflow of nb_pkts " Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 212/480] selftests: rtnetlink.sh: remove esp4_offload after test Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 213/480] vrf: Drop existing dst reference in vrf_ip6_input_dst Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 214/480] ipv6: prevent infinite loop in rt6_nlmsg_size() Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 215/480] ipv6: fix possible infinite loop in fib6_info_uses_dev() Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 216/480] ipv6: annotate data-races around rt->fib6_nsiblings Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 217/480] bpf/preload: Dont select USERMODE_DRIVER Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 218/480] bpf, arm64: Fix fp initialization for exception boundary Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 219/480] RISC-V: KVM: Fix inclusion of Smnpm in the guest ISA bitmap Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 220/480] rv: Adjust monitor dependencies Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 221/480] staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int() Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 222/480] fortify: Fix incorrect reporting of read buffer size Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 223/480] remoteproc: qcom: pas: Conclude the rename from adsp Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 224/480] PCI: rockchip-host: Fix "Unexpected Completion" log message Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 225/480] clk: renesas: rzv2h: Fix missing CLK_SET_RATE_PARENT flag for ddiv clocks Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 226/480] crypto: sun8i-ce - fix nents passed to dma_unmap_sg() Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 227/480] crypto: qat - use unmanaged allocation for dc_data Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 228/480] crypto: marvell/cesa - Fix engine load inaccuracy Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 229/480] padata: Fix pd UAF once and for all Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 230/480] crypto: qat - allow enabling VFs in the absence of IOMMU Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 231/480] crypto: qat - fix state restore for banks with exceptions Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 232/480] mtd: fix possible integer overflow in erase_xfer() Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 233/480] clk: davinci: Add NULL check in davinci_lpsc_clk_register() Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 234/480] media: v4l2-ctrls: Fix H264 SEPARATE_COLOUR_PLANE check Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 235/480] perf parse-events: Set default GH modifier properly Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 236/480] clk: xilinx: vcu: unregister pll_post only if registered correctly Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 237/480] power: supply: cpcap-charger: Fix null check for power_supply_get_by_name Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 238/480] power: supply: max14577: Handle NULL pdata when CONFIG_OF is not set Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 239/480] power: supply: qcom_pmi8998_charger: fix wakeirq Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 240/480] power: supply: max1720x correct capacity computation Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 241/480] crypto: arm/aes-neonbs - work around gcc-15 warning Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 242/480] PCI: endpoint: pci-epf-vntb: Return -ENOENT if pci_epc_get_next_free_bar() fails Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 243/480] pinctrl: sunxi: Fix memory leak on krealloc failure Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 244/480] pinctrl: berlin: fix memory leak in berlin_pinctrl_build_state() Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 245/480] pinctrl: canaan: k230: add NULL check in DT parse Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 246/480] pinctrl: canaan: k230: Fix order of DT parse and pinctrl register Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 247/480] PCI: Adjust the position of reading the Link Control 2 register Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 248/480] soundwire: Correct some property names Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 249/480] dmaengine: mmp: Fix again Wvoid-pointer-to-enum-cast warning Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 250/480] soundwire: debugfs: move debug statement outside of error handling Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 251/480] phy: qualcomm: phy-qcom-eusb2-repeater: Dont zero-out registers Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 252/480] fanotify: sanitize handle_type values when reporting fid Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 253/480] clk: clk-axi-clkgen: fix fpfd_max frequency for zynq Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 254/480] Fix dma_unmap_sg() nents value Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 255/480] perf tools: Fix use-after-free in help_unknown_cmd() Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 256/480] perf dso: Add missed dso__put to dso__load_kcore Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 257/480] mtd: spi-nor: spansion: Fixup params->set_4byte_addr_mode for SEMPER Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 258/480] perf sched: Make sure it frees the usage string Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 259/480] perf sched: Free thread->priv using priv_destructor Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 260/480] perf sched: Fix memory leaks in perf sched map Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 261/480] perf sched: Fix thread leaks in perf sched timehist Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 262/480] perf sched: Fix memory leaks for evsel->priv in timehist Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 263/480] perf sched: Use RC_CHK_EQUAL() to compare pointers Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 264/480] perf sched: Fix memory leaks in perf sched latency Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 265/480] RDMA/hns: Fix double destruction of rsv_qp Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 266/480] RDMA/hns: Fix HW configurations not cleared in error flow Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 267/480] crypto: ccp - Fix locking on alloc failure handling Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 268/480] crypto: inside-secure - Fix `dma_unmap_sg()` nents value Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 269/480] crypto: ccp - Fix crash when rebind ccp device for ccp.ko Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 270/480] RDMA/hns: Get message length of ack_req from FW Greg Kroah-Hartman
2025-08-12 17:47 ` [PATCH 6.15 271/480] RDMA/hns: Fix accessing uninitialized resources Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 272/480] RDMA/hns: Drop GFP_NOWARN Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 273/480] RDMA/hns: Fix -Wframe-larger-than issue Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 274/480] tracing: Use queue_rcu_work() to free filters Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 275/480] kernel: trace: preemptirq_delay_test: use offstack cpu mask Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 276/480] proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 277/480] pinmux: fix race causing mux_owner NULL with active mux_usecount Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 278/480] perf tests bp_account: Fix leaked file descriptor Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 279/480] perf hwmon_pmu: Avoid shortening hwmon PMU name Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 280/480] RDMA/mana_ib: Fix DSCP value in modify QP Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 281/480] clk: thead: th1520-ap: Correctly refer the parent of osc_12m Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 282/480] clk: sunxi-ng: v3s: Fix de clock definition Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 283/480] scsi: ibmvscsi_tgt: Fix dma_unmap_sg() nents value Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 284/480] scsi: elx: efct: " Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 285/480] scsi: mvsas: " Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 286/480] scsi: isci: " Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 287/480] PCI: Fix driver_managed_dma check Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 288/480] watchdog: ziirave_wdt: check record length in ziirave_firm_verify() Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 289/480] ext4: fix inode use after free in ext4_end_io_rsv_work() Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 290/480] ext4: Make sure BH_New bit is cleared in ->write_end handler Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 291/480] clk: at91: sam9x7: update pll clk ranges Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 292/480] hwrng: mtk - handle devm_pm_runtime_enable errors Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 293/480] crypto: keembay - Fix dma_unmap_sg() nents value Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 294/480] crypto: img-hash " Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 295/480] crypto: qat - disable ZUC-256 capability for QAT GEN5 Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 296/480] crypto: krb5 - Fix memory leak in krb5_test_one_prf() Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 297/480] soundwire: stream: restore params when prepare ports fail Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 298/480] PCI: endpoint: pci-epf-vntb: Fix the incorrect usage of __iomem attribute Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 299/480] clk: imx95-blk-ctl: Fix synchronous abort Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 300/480] remoteproc: xlnx: Disable unsupported features Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 301/480] fs/orangefs: Allow 2 more characters in do_c_string() Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 302/480] tools subcmd: Tighten the filename size in check_if_command_finished Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 303/480] dmaengine: mv_xor: Fix missing check after DMA map and missing unmap Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 304/480] dmaengine: nbpfaxi: Add missing check after DMA map Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 305/480] mfd: tps65219: Update TPS65214 MFD cells GPIO compatible string Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 306/480] ASoC: SDCA: Fix some holes in the regmap readable/writeable helpers Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 307/480] ASoC: fsl_xcvr: get channel status data when PHY is not exists Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 308/480] ASoC: fsl_xcvr: get channel status data with firmware exists Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 309/480] sh: Do not use hyphen in exported variable name Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 310/480] perf tools: Remove libtraceevent in .gitignore Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 311/480] clk: clocking-wizard: Fix the round rate handling for versal Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 312/480] crypto: qat - fix DMA direction for compression on GEN2 devices Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 313/480] crypto: qat - fix seq_file position update in adf_ring_next() Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 314/480] fbdev: imxfb: Check fb_add_videomode to prevent null-ptr-deref Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 315/480] smb: client: allow parsing zero-length AV pairs Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 316/480] jfs: fix metapage reference count leak in dbAllocCtl Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 317/480] mtd: rawnand: atmel: Fix dma_mapping_error() address Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 318/480] mtd: rawnand: rockchip: Add missing check after DMA map Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 319/480] mtd: rawnand: atmel: set pmecc data setup time Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 320/480] drm/xe/vf: Disable CSC support on VF Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 321/480] selftests: ALSA: fix memory leak in utimer test Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 322/480] ALSA: usb: scarlett2: Fix missing NULL check Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 323/480] perf record: Cache build-ID of hit DSOs only Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 324/480] vdpa/mlx5: Fix needs_teardown flag calculation Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 325/480] vhost-scsi: Fix log flooding with target does not exist errors Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 326/480] vhost-scsi: Fix check for inline_sg_cnt exceeding preallocated limit Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 327/480] vdpa/mlx5: Fix release of uninitialized resources on error path Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 328/480] vdpa: Fix IDR memory leak in VDUSE module exit Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 329/480] vhost: Reintroduce kthread API and add mode selection Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 330/480] bpf: Check flow_dissector ctx accesses are aligned Greg Kroah-Hartman
2025-08-12 17:48 ` [PATCH 6.15 331/480] bpf: Check netfilter " Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 332/480] apparmor: ensure WB_HISTORY_SIZE value is a power of 2 Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 333/480] apparmor: fix loop detection used in conflicting attachment resolution Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 334/480] scripts: gdb: move MNT_* constants to gdb-parsed Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 335/480] apparmor: Fix unaligned memory accesses in KUnit test Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 336/480] i3c: master: svc: Fix npcm845 FIFO_EMPTY quirk Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 337/480] module: Restore the moduleparam prefix length check Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 338/480] ucount: fix atomic_long_inc_below() argument type Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 339/480] rtc: ds1307: fix incorrect maximum clock rate handling Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 340/480] rtc: hym8563: " Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 341/480] rtc: nct3018y: " Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 342/480] rtc: pcf85063: " Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 343/480] rtc: pcf8563: " Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 344/480] rtc: rv3028: " Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 345/480] f2fs: turn off one_time when forcibly set to foreground GC Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 346/480] f2fs: fix bio memleak when committing super block Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 347/480] f2fs: fix to avoid invalid wait context issue Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 348/480] f2fs: fix KMSAN uninit-value in extent_info usage Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 349/480] f2fs: fix to check upper boundary for value of gc_boost_zoned_gc_percent Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 350/480] f2fs: fix to check upper boundary for gc_valid_thresh_ratio Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 351/480] f2fs: fix to check upper boundary for gc_no_zoned_gc_percent Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 352/480] f2fs: doc: fix wrong quota mount option description Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 353/480] f2fs: fix to avoid UAF in f2fs_sync_inode_meta() Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 354/480] f2fs: fix to avoid panic in f2fs_evict_inode Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 355/480] f2fs: fix to avoid out-of-boundary access in devs.path Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 356/480] f2fs: vm_unmap_ram() may be called from an invalid context Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 357/480] f2fs: fix to update upper_p in __get_secs_required() correctly Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 358/480] f2fs: fix to calculate dirty data during has_not_enough_free_secs() Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 359/480] f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 360/480] exfat: fdatasync flag should be same like generic_write_sync() Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 361/480] i2c: muxes: mule: Fix an error handling path in mule_i2c_mux_probe() Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 362/480] vfio: Fix unbalanced vfio_df_close call in no-iommu mode Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 363/480] vfio: Prevent open_count decrement to negative Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 364/480] vfio/pds: Fix missing detach_ioas op Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 365/480] vfio/pci: Separate SR-IOV VF dev_set Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 366/480] scsi: mpt3sas: Fix a fw_event memory leak Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 367/480] scsi: Revert "scsi: iscsi: Fix HW conn removal use after free" Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 368/480] scsi: ufs: core: Use link recovery when h8 exit fails during runtime resume Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 369/480] scsi: sd: Make sd shutdown issue START STOP UNIT appropriately Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 370/480] kconfig: qconf: fix ConfigList::updateListAllforAll() Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 371/480] vfio/pci: Do vf_token checks for VFIO_DEVICE_BIND_IOMMUFD Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 372/480] sched/psi: Fix psi_seq initialization Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 373/480] padata: Remove comment for reorder_work Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 374/480] PCI: pnv_php: Clean up allocated IRQs on unplug Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 375/480] PCI: pnv_php: Work around switches with broken presence detection Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 376/480] powerpc/eeh: Export eeh_unfreeze_pe() Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 377/480] powerpc/eeh: Make EEH driver device hotplug safe Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 378/480] PCI: pnv_php: Fix surprise plug detection and recovery Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 379/480] tools/power turbostat: regression fix: --show C1E% Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 380/480] pNFS/flexfiles: dont attempt pnfs on fatal DS errors Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 381/480] NFS: Fix wakeup of __nfs_lookup_revalidate() in unblock_revalidate() Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 382/480] NFS: Fix filehandle bounds checking in nfs_fh_to_dentry() Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 383/480] NFSv4.2: another fix for listxattr Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 384/480] NFS: Fixup allocation flags for nfsiods __GFP_NORETRY Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 385/480] md/md-cluster: handle REMOVE message earlier Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 386/480] netpoll: prevent hanging NAPI when netcons gets enabled Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 387/480] phy: mscc: Fix parsing of unicast frames Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 388/480] net: ipa: add IPA v5.1 and v5.5 to ipa_version_string() Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 389/480] pptp: ensure minimal skb length in pptp_xmit() Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 390/480] nvmet: initialize discovery subsys after debugfs is initialized Greg Kroah-Hartman
2025-08-12 17:49 ` [PATCH 6.15 391/480] s390/ap: Unmask SLCF bit in card and queue ap functions sysfs Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 392/480] s390/mm: Set high_memory at the end of the identity mapping Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 393/480] netlink: specs: ethtool: fix module EEPROM input/output arguments Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 394/480] block: Fix default IO priority if there is no IO context Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 395/480] block: ensure discard_granularity is zero when discard is not supported Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 396/480] ASoC: tas2781: Fix the wrong step for TLV on tas2781 Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 397/480] spi: cs42l43: Property entry should be a null-terminated array Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 398/480] net/mlx5: Correctly set gso_segs when LRO is used Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 399/480] ipv6: reject malicious packets in ipv6_gso_segment() Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 400/480] net: mdio: mdio-bcm-unimac: Correct rate fallback logic Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 401/480] net: drop UFO packets in udp_rcv_segment() Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 402/480] net/sched: taprio: enforce minimum value for picos_per_byte Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 403/480] sunrpc: fix client side handling of tls alerts Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 404/480] drm/xe/pf: Disable PF restart worker on device removal Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 405/480] x86/irq: Plug vector setup race Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 406/480] eth: fbnic: unlink NAPIs from queues on error to open Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 407/480] net: airoha: npu: Add missing MODULE_FIRMWARE macros Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 408/480] benet: fix BUG when creating VFs Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 409/480] net/sched: mqprio: fix stack out-of-bounds write in tc entry parsing Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 410/480] s390/mm: Allocate page table with PAGE_SIZE granularity Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 411/480] eth: fbnic: remove the debugging trick of super high page bias Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 412/480] NFS/localio: nfs_close_local_fh() fix check for file closed Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 413/480] NFS/localio: nfs_uuid_put() fix races with nfs_open/close_local_fh() Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 414/480] NFS/localio: nfs_uuid_put() fix the wake up after unlinking the file Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 415/480] net: ti: icssg-prueth: Fix skb handling for XDP_PASS Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 416/480] irqchip: Build IMX_MU_MSI only on ARM Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 417/480] ASoC: SOF: Intel: hda-sdw-bpt: fix SND_SOF_SOF_HDA_SDW_BPT dependencies Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 418/480] ALSA: hda/ca0132: Fix missing error handling in ca0132_alt_select_out() Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 419/480] s390/boot: Fix startup debugging log Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 420/480] smb: server: remove separate empty_recvmsg_queue Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 421/480] smb: server: make sure we call ib_dma_unmap_single() only if we called ib_dma_map_single already Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 422/480] smb: server: let recv_done() consistently call put_recvmsg/smb_direct_disconnect_rdma_connection Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 423/480] smb: server: let recv_done() avoid touching data_transfer after cleanup/move Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 424/480] smb: client: let send_done() cleanup before calling smbd_disconnect_rdma_connection() Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 425/480] smb: client: remove separate empty_packet_queue Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 426/480] smb: client: make sure we call ib_dma_unmap_single() only if we called ib_dma_map_single already Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 427/480] smb: client: let recv_done() cleanup before notifying the callers Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 428/480] smb: client: let recv_done() avoid touching data_transfer after cleanup/move Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 429/480] nvmet: exit debugfs after discovery subsystem exits Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 430/480] pptp: fix pptp_xmit() error path Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 431/480] smb: client: return an error if rdma_connect does not return within 5 seconds Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 432/480] tools/power turbostat: Fix bogus SysWatt for forked program Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 433/480] nfsd: dont set the ctime on delegated atime updates Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 434/480] nfsd: avoid ref leak in nfsd_open_local_fh() Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 435/480] sunrpc: fix handling of server side tls alerts Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 436/480] perf/core: Preserve AUX buffer allocation failure result Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 437/480] perf/core: Dont leak AUX buffer refcount on allocation failure Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 438/480] perf/core: Exit early on perf_mmap() fail Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 439/480] perf/core: Handle buffer mapping fail correctly in perf_mmap() Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 440/480] perf/core: Prevent VMA split of buffer mappings Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 441/480] selftests/perf_events: Add a mmap() correctness test Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 442/480] net/packet: fix a race in packet_set_ring() and packet_notifier() Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 443/480] vsock: Do not allow binding to VMADDR_PORT_ANY Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 444/480] ksmbd: fix null pointer dereference error in generate_encryptionkey Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 445/480] ksmbd: fix Preauh_HashValue race condition Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 446/480] ksmbd: fix corrupted mtime and ctime in smb2_open Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 447/480] smb: client: fix netns refcount leak after net_passive changes Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 448/480] smb: client: set symlink type as native for POSIX mounts Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 449/480] smb: client: default to nonativesocket under " Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 450/480] ksmbd: limit repeated connections from clients with the same IP Greg Kroah-Hartman
2025-08-12 17:50 ` [PATCH 6.15 451/480] smb: server: Fix extension string in ksmbd_extract_shortname() Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 452/480] USB: serial: option: add Foxconn T99W709 Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 453/480] Bluetooth: btusb: Add USB ID 3625:010b for TP-LINK Archer TX10UB Nano Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 454/480] net: usbnet: Avoid potential RCU stall on LINK_CHANGE event Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 455/480] net: usbnet: Fix the wrong netif_carrier_on() call Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 456/480] x86/sev: Evict cache lines during SNP memory validation Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 457/480] ALSA: intel_hdmi: Fix off-by-one error in __hdmi_lpe_audio_probe() Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 458/480] ALSA: scarlett2: Add retry on -EPROTO from scarlett2_usb_tx() Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 459/480] ALSA: hda/realtek - Fix mute LED for HP Victus 16-r1xxx Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 460/480] ALSA: hda/realtek - Fix mute LED for HP Victus 16-s0xxx Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 461/480] ALSA: hda/realtek - Fix mute LED for HP Victus 16-d1xxx (MB 8A26) Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 462/480] platform/x86/intel/pmt: fix a crashlog NULL pointer access Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 463/480] x86/fpu: Delay instruction pointer fixup until after warning Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 464/480] KVM: VMX: Allow guest to set DEBUGCTL.RTM_DEBUG if RTM is supported Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 465/480] s390/mm: Remove possible false-positive warning in pte_free_defer() Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 466/480] MIPS: mm: tlb-r4k: Uniquify TLB entries on init Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 467/480] mm/hmm: move pmd_to_hmm_pfn_flags() to the respective #ifdeffery Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 468/480] mm: swap: correctly use maxpages in swapon syscall to avoid potential deadloop Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 469/480] mm: swap: fix potential buffer overflow in setup_clusters() Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 470/480] mm: swap: move nr_swap_pages counter decrement from folio_alloc_swap() to swap_range_alloc() Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 471/480] mm: shmem: fix the shmem large folio allocation for the i915 driver Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 472/480] usb: gadget: uvc: Initialize frame-based format color matching descriptor Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 473/480] perf/arm-ni: Set initial IRQ affinity Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 474/480] media: ti: j721e-csi2rx: fix list_del corruption Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 475/480] HID: apple: validate feature-report field count to prevent NULL pointer dereference Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 476/480] USB: gadget: f_hid: Fix memory leak in hidg_bind error path Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 477/480] HID: core: Harden s32ton() against conversion to 0 bits Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 478/480] HID: apple: avoid setting up battery timer for devices without battery Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 479/480] usb: gadget : fix use-after-free in composite_dev_cleanup() Greg Kroah-Hartman
2025-08-12 17:51 ` [PATCH 6.15 480/480] mm: fix a UAF when vma->mm is freed after vma->vm_refcnt got dropped Greg Kroah-Hartman
2025-08-12 19:57 ` [PATCH 6.15 000/480] 6.15.10-rc1 review Brett A C Sheffield
2025-08-12 20:22 ` Pavel Machek
2025-08-12 21:09 ` Achill Gilgenast
2025-08-12 21:47 ` Florian Fainelli
2025-08-13 3:48 ` Peter Schneider
2025-08-13 13:57 ` Mark Brown
2025-08-13 15:07 ` Shuah Khan
2025-08-13 15:48 ` Jon Hunter
2025-08-13 17:25 ` Jon Hunter
2025-08-13 22:07 ` [PATCH 6.15 000/480] 6.15.10-rc1 review Ron Economos
2025-08-14 15:36 ` Greg KH
2025-08-15 16:20 ` Re: Jon Hunter
2025-08-15 16:53 ` Re: Greg KH
2025-08-13 20:15 ` [PATCH 6.15 000/480] 6.15.10-rc1 review Justin Forbes
2025-08-13 21:33 ` Ron Economos
2025-08-14 6:18 ` Naresh Kamboju
2025-08-14 14:50 ` Miguel Ojeda
-- strict thread matches above, loose matches on Subject: below --
2026-05-09 18:01 Andrea Righi
2026-05-09 18:07 ` Andrea Righi
2026-04-28 18:24 Fabio M. De Francesco
2026-05-01 22:01 ` Dave Jiang
2026-04-23 16:06 [PATCH] usb: cdns3: gadget: fix request skipping after clearing halt Yongchao Wu
2026-04-27 1:22 ` Peter Chen (CIX)
2026-04-27 9:01 ` Pawel Laszczak
2026-04-27 22:59 ` Peter Chen (CIX)
2026-04-27 23:59 ` Yongchao Wu
2026-04-28 9:58 ` Pawel Laszczak
2026-04-28 14:48 ` Yongchao Wu
2026-05-04 9:15 ` Pawel Laszczak
2026-04-12 13:42 Re; Erick Lorch
2026-04-12 10:09 Re; Erick Lorch
2026-04-12 6:24 Re; Erick Lorch
2026-03-31 10:05 [PATCH] net: ns83820: check DMA mapping errors in hard_start_xmit Paolo Abeni
2026-03-31 11:14 ` Wang Jun
2026-03-31 12:09 ` Eric Dumazet
2026-03-13 10:11 ezcap401 needs USB_QUIRK_NO_BOS to function on 10gbs usb speed Greg KH
2026-03-13 11:01 ` Vyacheslav Vahnenko
2026-03-13 12:04 ` Greg KH
2026-02-25 19:40 [PATCH v5 0/3] iio: frequency: ad9523: fix checkpatch warnings Bhargav Joshi
2026-02-25 19:40 ` Bhargav Joshi
2026-02-25 19:43 ` Andy Shevchenko
2026-02-02 10:53 Anshumali Gaur
2026-02-03 0:34 ` Jacob Keller
2026-01-11 21:10 Wesley B
2026-01-12 13:28 ` Miguel Ojeda
2025-11-05 3:38 niklaus.liu
2025-11-05 8:56 ` AngeloGioacchino Del Regno
2025-11-04 9:22 Michael Roach
2025-11-04 10:24 ` Kristoffer Haugsbakk
2025-11-05 14:55 ` Re: Lucas Seiki Oshiro
2025-11-05 15:01 ` Re: Kristoffer Haugsbakk
2025-11-06 0:05 ` Re: Lucas Seiki Oshiro
2025-11-06 8:09 ` Re: Michael Roach
2025-10-06 10:51 [PATCH] counter: microchip-tcb-capture: Allow shared IRQ for multi-channel TCBs Dharma Balasubiramani
2025-10-08 7:06 ` Kamel Bouhara
2025-10-08 20:46 ` Bence Csókás
2025-10-05 14:16 ssrane_b23
2025-10-05 14:16 ` syzbot
2025-09-16 21:23 Jay Vosburgh
2025-09-16 21:56 ` Jay Vosburgh
2025-09-15 19:52 Yury Norov (NVIDIA)
2025-09-16 14:48 ` Simon Horman
2025-09-16 15:22 ` Re: Yury Norov
2025-08-29 2:01 xinpeng.wang
2025-08-29 2:42 ` bluez.test.bot
2025-08-27 6:48 [PATCH] net/netfilter/ipvs: Fix data-race in ip_vs_add_service / ip_vs_out_hook Julian Anastasov
2025-08-27 14:43 ` Zhang Tengfei
2025-08-27 21:37 ` Pablo Neira Ayuso
2025-08-23 22:53 [RFC PATCH] time: introduce BOOT_TIME_TRACKER and minimal boot timestamp Thomas Gleixner
2025-09-01 4:05 ` Kaiwan N Billimoria
2025-09-01 5:57 ` Kaiwan N Billimoria
2025-08-20 14:33 Christian König
2025-08-20 15:23 ` David Hildenbrand
2025-08-21 8:10 ` Re: Christian König
2025-08-25 19:10 ` Re: David Hildenbrand
2025-08-26 8:38 ` Re: Christian König
2025-08-26 8:46 ` Re: David Hildenbrand
2025-08-26 9:00 ` Re: Christian König
2025-08-26 9:17 ` Re: David Hildenbrand
2025-08-26 9:56 ` Re: Christian König
2025-08-26 12:07 ` Re: David Hildenbrand
2025-08-26 16:09 ` Re: Christian König
2025-08-26 14:27 ` Re: Thomas Hellström
2025-08-26 12:37 ` Re: David Hildenbrand
2025-08-18 16:08 [PATCH] documentation/arm64 : kdump fixed typo errors Jonathan Corbet
2025-09-08 9:54 ` hariconscious
2025-09-08 13:23 ` Jonathan Corbet
2025-08-12 13:34 Baoquan He
2025-08-12 13:49 ` Baoquan He
2025-08-06 3:34 Sang-Heon Jeon
2025-08-06 3:44 ` Sang-Heon Jeon
[not found] <CADU64hCr7mshqfBRE2Wp8zf4BHBdJoLLH=VJt2MrHeR+zHOV4w@mail.gmail.com>
2025-07-20 18:26 ` >
2025-07-20 19:30 ` David Lechner
2025-07-20 19:30 ` Re: David Lechner
2025-07-21 6:52 ` Re: Krzysztof Kozlowski
2025-07-21 6:52 ` Re: Krzysztof Kozlowski
[not found] ` <CADU64hDZeyaCpHXBmSG1rtHjpxmjejT7asK9oGBUMF55eYeh4w@mail.gmail.com>
2025-07-21 14:09 ` Re: David Lechner
2025-07-21 14:09 ` Re: David Lechner
2025-07-21 7:52 ` Re: Andy Shevchenko
2025-07-21 7:52 ` Re: Andy Shevchenko
2025-07-01 13:44 Emanuele Ghidoli
2025-07-11 2:21 ` Fabio Estevam
2025-05-14 20:21 Nicolas Pitre
2025-05-15 8:33 ` Jiri Slaby
2025-05-09 17:38 Shawn Anastasio
2025-05-10 19:50 ` Trilok Soni
2025-04-24 0:40 Cong Wang
2025-04-24 0:59 ` Jiayuan Chen
2025-04-24 9:19 ` Re: Jiayuan Chen
2025-04-22 1:53 [PATCH bpf-next] bpf: Remove bpf_get_smp_processor_id_proto Alexei Starovoitov
2025-04-22 8:04 ` Feng Yang
2025-04-22 14:37 ` Alexei Starovoitov
2025-04-18 7:46 Shung-Hsi Yu
2025-04-18 7:49 ` Shung-Hsi Yu
2025-04-23 17:30 ` Re: patchwork-bot+netdevbpf
2025-01-08 13:59 Jiang Liu
2025-01-08 14:10 ` Christian König
2025-01-08 16:33 ` Re: Mario Limonciello
2025-01-09 5:34 ` Re: Gerry Liu
2025-01-09 17:10 ` Re: Mario Limonciello
2025-01-13 1:19 ` Re: Gerry Liu
2025-01-13 21:59 ` Re: Mario Limonciello
2024-11-25 20:13 Re: Robert Harewood
2024-11-25 19:23 Re: Robert Harewood
2024-11-23 1:39 the Hide
2024-11-23 7:32 ` Christoph Biedl
2024-10-17 9:09 Paulo Miguel Almeida
2024-10-17 9:12 ` Paulo Miguel Almeida
2024-10-15 22:48 Daniel Yang
2024-10-16 1:27 ` Jakub Kicinski
2024-10-10 22:44 Re: PRIVATE
2024-09-17 7:10 Akhil P Oommen
2024-09-17 7:24 ` Dmitry Baryshkov
2024-09-13 17:11 David Hunter
2024-09-13 20:39 ` Shuah Khan
2024-08-22 20:54 [PATCH 2/2] scsi: ufs: core: Fix the code for entering hibernation Bao D. Nguyen
2024-08-22 21:08 ` Bart Van Assche
2024-08-23 12:01 ` Manivannan Sadhasivam
2024-08-23 14:23 ` Bart Van Assche
2024-08-23 14:58 ` Manivannan Sadhasivam
2024-08-23 16:07 ` Bart Van Assche
2024-08-23 16:48 ` Manivannan Sadhasivam
2024-08-23 18:05 ` Bart Van Assche
2024-08-24 2:29 ` Manivannan Sadhasivam
2024-08-24 2:48 ` Bart Van Assche
2024-08-24 3:03 ` Manivannan Sadhasivam
2024-08-26 6:48 ` Can Guo
2024-08-16 11:07 Xi Ruoyao
2024-08-19 12:40 ` Huacai Chen
2024-08-19 13:01 ` Re: Jason A. Donenfeld
2024-08-19 15:22 ` Re: Xi Ruoyao
2024-08-19 15:54 ` Re: Xi Ruoyao
2024-08-19 15:22 ` Re: Xi Ruoyao
2024-08-27 9:45 ` Re: Jason A. Donenfeld
2024-08-14 8:03 howard_wang
2024-08-14 15:04 ` Stephen Hemminger
2024-07-15 21:06 Phil Dennis-Jordan
2024-07-16 6:07 ` Akihiko Odaki
2024-07-17 11:16 ` Re: Phil Dennis-Jordan
2024-07-14 19:59 raschupkin.ri
2024-07-15 20:20 ` Joe Lawrence
2024-07-15 22:45 ` Re: Roman Rashchupkin
2024-07-16 9:28 ` Re: Nicolai Stange
[not found] ` <66963d60.170a0220.70a9a.8866SMTPIN_ADDED_BROKEN@mx.google.com>
2024-07-16 9:53 ` Re: Roman Rashchupkin
2024-07-25 14:52 ` Re: Joe Lawrence
2024-07-16 17:33 ` Re: Song Liu
2024-07-06 11:20 [PATCH v2 09/60] i2c: cp2615: reword according to newest specification Wolfram Sang
2024-07-10 6:41 ` [PATCH v3] " Wolfram Sang
2024-07-10 17:51 ` Bence Csókás
2024-06-26 6:11 Totoro W
2024-06-26 7:09 ` Eduard Zingerman
2024-06-11 16:54 Jacob Pan
2024-06-12 2:04 ` Sean Christopherson
2024-06-12 2:55 ` Re: Xin Li
[not found] <CGME20240520102002epcas2p3d0944968114a664556cbd74d53beddee@epcas2p3.samsung.com>
2024-05-20 10:09 ` Minwoo Im
2024-05-20 13:34 ` Vincent Fu
2024-05-21 0:00 ` Re: Minwoo Im
2024-04-23 14:21 [PATCH dovetail] x86: irq_pipeline: Add missing definition for !CONFIG_IRQ_PIPELINE Philippe Gerum
2024-04-24 8:58 ` Fabian Scheler
2024-04-24 9:02 ` Scheler, Fabian
2024-04-19 15:46 George Guo
2024-04-23 16:48 ` Greg KH
2024-03-07 6:07 KR Kim
2024-03-07 8:01 ` Miquel Raynal
2024-03-08 1:27 ` Re: Kyeongrho.Kim
[not found] ` <SE2P216MB210205B301549661575720CC833A2@SE2P216MB2102.KORP216.PROD.OUTLOOK.COM>
2024-03-29 4:41 ` Re: Kyeongrho.Kim
2024-01-24 0:14 [PATCH v3 0/7] net/gve: RSS Support for GVE Driver Joshua Washington
[not found] ` <20240126173317.2779230-1-joshwash@google.com>
2024-01-31 14:58 ` Ferruh Yigit
2024-01-18 22:19 [RFC] [PATCH 0/3] xfs: use large folios for buffers Dave Chinner
2024-01-22 10:13 ` Andi Kleen
2024-01-22 11:53 ` Dave Chinner
2024-01-16 6:46 meir elisha
2024-01-16 7:05 ` Dan Carpenter
2023-12-07 4:40 Emma Tebibyte
2023-12-07 5:00 ` Christoph Anton Mitterer
2023-12-07 5:29 ` Re: Lawrence Velázquez
2023-11-30 21:51 [NDCTL PATCH v3 2/2] cxl: Add check for regions before disabling memdev Dave Jiang
2024-04-17 6:46 ` Yao Xingtao
2024-04-17 18:14 ` Verma, Vishal L
2024-04-22 7:26 ` Re: Xingtao Yao (Fujitsu)
[not found] <c8d43894-7e66-4a01-88fc-10708dc53b6b@amd.com>
[not found] ` <878r7z4kb4.ffs@tglx>
[not found] ` <e79dea49-0c07-4ca2-b359-97dd1bc579c8@amd.com>
[not found] ` <87ttqhcotn.ffs@tglx>
[not found] ` <87v8avawe0.ffs@tglx>
[not found] ` <32bcaa8a-0413-4aa4-97a0-189830da8654@amd.com>
[not found] ` <ZTkzYA3w2p3L4SVA@localhost>
[not found] ` <87jzra6235.ffs@tglx>
[not found] ` <875y2u5s8g.ffs@tglx>
2023-10-25 22:11 ` Re: Mario Limonciello
2023-10-26 9:27 ` Re: Thomas Gleixner
[not found] <TXJgqLzlM6oCfTXKSqrSBk@txt.att.net>
2023-08-09 5:12 ` Re: Luna Jernberg
[not found] <64b09dbb.630a0220.e80b9.e2ed@mx.google.com>
2023-07-14 8:05 ` Re: Andy Shevchenko
2023-06-27 11:10 Alvaro a-m
2023-06-27 11:15 ` Michael Kjörling
[not found] <010d01d999f4$257ae020$7070a060$@mirroredgenetworks.com>
[not found] ` <CAEhhANphwWt5iOMc5Yqp1tT1HGoG_GsCuUWBWeVX4zxL6JwUiw@mail.gmail.com>
[not found] ` <CAEhhANom-MGPCqEk5LXufMkxvnoY0YRUrr0r07s0_7F=eCQH5Q@mail.gmail.com>
2023-06-08 10:51 ` Re: Daniel Little
[not found] <CAKEZqKKdQ9EhRobSmq0sV76arfpk6m5XqA-=XQP_M3VRG=M-eg@mail.gmail.com>
2023-06-08 8:13 ` Re: chenlei0x
2023-05-30 2:46 RE; Olena Shevchenko
2023-05-30 1:31 RE; Olena Shevchenko
2023-05-11 12:58 Ryan Roberts
2023-05-11 13:13 ` Ryan Roberts
2023-03-12 6:52 [PATCH v2] uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS583Gen 2 Greg Kroah-Hartman
2023-03-27 13:54 ` Yaroslav Furman
2023-03-27 14:19 ` Greg Kroah-Hartman
2023-02-28 6:32 Re: Mahmut Akten
[not found] <20230122193117.GA28689@Debian-50-lenny-64-minimal>
2023-01-22 21:42 ` Re: Alejandro Colomar
2023-01-24 20:01 ` Re: Helge Kreutzmann
2023-01-18 20:59 [PATCH v5 0/5] CXL Poison List Retrieval & Tracing alison.schofield
2023-01-27 1:59 ` Dan Williams
2023-01-27 16:10 ` Alison Schofield
2023-01-27 19:16 ` Re: Dan Williams
2023-01-27 21:36 ` Re: Alison Schofield
2023-01-27 22:04 ` Re: Dan Williams
2022-11-21 11:11 Denis Arefev
2022-11-21 14:28 ` Jason Yan
2022-11-18 19:33 Re: Mr. JAMES
2022-11-18 18:11 Re: Mr. JAMES
2022-11-18 2:00 Jiamei Xie
2022-11-18 7:47 ` Michal Orzel
2022-11-18 9:02 ` Re: Julien Grall
2022-11-09 14:34 Denis Arefev
2022-11-09 14:44 ` Greg Kroah-Hartman
2022-09-14 13:12 Amjad Ouled-Ameur
2022-09-14 13:18 ` Amjad Ouled-Ameur
2022-09-14 13:18 ` Re: Amjad Ouled-Ameur
2022-09-12 12:36 Christian König
2022-09-13 2:04 ` Alex Deucher
2022-08-28 21:01 Nick Neumann
2022-09-01 17:44 ` Nick Neumann
2022-08-26 22:03 Zach O'Keefe
2022-08-31 21:47 ` Yang Shi
2022-09-01 0:24 ` Re: Zach O'Keefe
2022-06-06 5:33 Fenil Jain
2022-06-06 5:51 ` Greg Kroah-Hartman
2022-05-15 20:36 [PATCH bpf-next 1/2] cpuidle/rcu: Making arch_cpu_idle and rcu_idle_exit noinstr Jiri Olsa
2023-05-20 9:47 ` Ze Gao
2023-05-21 3:58 ` Yonghong Song
2023-05-21 15:10 ` Re: Ze Gao
2023-05-21 20:26 ` Re: Jiri Olsa
2023-05-22 1:36 ` Re: Masami Hiramatsu
2023-05-22 2:07 ` Re: Ze Gao
2023-05-23 4:38 ` Re: Yonghong Song
2023-05-23 5:30 ` Re: Masami Hiramatsu
2023-05-23 6:59 ` Re: Paul E. McKenney
2023-05-25 0:13 ` Re: Masami Hiramatsu
2023-05-21 8:08 ` Re: Jiri Olsa
2023-05-21 10:09 ` Re: Masami Hiramatsu
2023-05-21 14:19 ` Re: Ze Gao
2022-04-17 17:43 [PATCH v3 00/60] target/arm: Cleanups, new features, new cpus Richard Henderson
2022-04-17 17:43 ` [PATCH v3 06/60] target/arm: Change CPUArchState.aarch64 to bool Richard Henderson
2022-04-19 11:17 ` Alex Bennée
2022-04-05 21:41 rcu_sched self-detected stall on CPU Miguel Ojeda
2022-04-06 9:31 ` Zhouyi Zhou
2022-04-06 17:00 ` Paul E. McKenney
2022-04-08 7:23 ` Michael Ellerman
2022-04-08 14:42 ` Michael Ellerman
2022-04-13 5:11 ` Nicholas Piggin
2022-04-22 15:53 ` Thomas Gleixner
2022-04-22 15:53 ` Re: Thomas Gleixner
2022-04-23 2:29 ` Re: Nicholas Piggin
2022-04-23 2:29 ` Re: Nicholas Piggin
[not found] <Yj1hkpyUqJE9sQ2p@redhat.com>
2022-03-25 7:52 ` Re: Jason Wang
2022-03-25 9:10 ` Re: Michael S. Tsirkin
2022-03-25 9:20 ` Re: Jason Wang
2022-03-25 10:09 ` Re: Michael S. Tsirkin
2022-03-28 4:56 ` Re: Jason Wang
2022-03-28 5:59 ` Re: Michael S. Tsirkin
2022-03-28 6:18 ` Re: Jason Wang
2022-03-28 10:40 ` Re: Michael S. Tsirkin
2022-03-29 7:12 ` Re: Jason Wang
2022-03-29 14:08 ` Re: Michael S. Tsirkin
2022-03-30 2:40 ` Re: Jason Wang
2022-03-30 5:14 ` Re: Michael S. Tsirkin
2022-03-30 5:53 ` Re: Jason Wang
2022-03-29 8:35 ` Re: Thomas Gleixner
2022-03-29 14:37 ` Re: Michael S. Tsirkin
2022-03-29 18:13 ` Re: Thomas Gleixner
2022-03-29 22:04 ` Re: Michael S. Tsirkin
2022-03-30 2:38 ` Re: Jason Wang
2022-03-30 5:09 ` Re: Michael S. Tsirkin
2022-03-30 5:53 ` Re: Jason Wang
2022-04-12 6:55 ` Re: Michael S. Tsirkin
[not found] <20220301070226.2477769-1-jaydeepjd.8914>
2022-03-06 11:10 ` Jaydeep P Das
2022-03-06 11:22 ` Jaydeep Das
2022-03-04 8:47 Re: Harald Hauge
2022-02-13 22:40 Ronnie Sahlberg
2022-02-14 7:52 ` ronnie sahlberg
2022-02-11 15:06 Re: Caine Chen
2022-02-10 7:10 [PATCH] net/failsafe: Fix crash due to global devargs syntax parsing from secondary process madhuker.mythri
2022-02-10 15:00 ` Ferruh Yigit
2022-02-10 16:08 ` Gaëtan Rivet
[not found] <10b1995b392e490aaa2db645f219015e@dji.com>
2022-01-17 12:54 ` 转发: Caine Chen
2022-02-03 11:49 ` Daniel Vacek
2022-01-24 12:43 Arınç ÜNAL
2022-01-25 14:03 ` Sergio Paracuellos
2022-01-25 15:24 ` Re: Arınç ÜNAL
2022-01-25 15:50 ` Re: Sergio Paracuellos
2022-01-20 15:28 Myrtle Shah
2022-01-20 15:37 ` Vitaly Wool
2022-01-20 23:29 ` Re: Damien Le Moal
2022-02-04 21:45 ` Re: Palmer Dabbelt
2022-01-13 17:53 Varun Sethi
2022-01-14 17:17 ` Fabio Estevam
[not found] <20211229092443.GA10533@L-PF27918B-1352.localdomain>
2022-01-05 6:05 ` Re: Jason Wang
2022-01-05 6:27 ` Re: Jason Wang
2021-12-20 6:46 Ralf Beck
2021-12-20 7:55 ` Greg KH
2021-12-20 10:01 ` Re: Oliver Neukum
[not found] <20211126221034.21331-1-lukasz.bartosik@semihalf.com--annotate>
2021-11-29 21:59 ` Re: sean.wang
2021-11-29 21:59 ` Re: sean.wang
[not found] <CAGGnn3JZdc3ETS_AijasaFUqLY9e5Q1ZHK3+806rtsEBnAo5Og@mail.gmail.com>
2021-11-23 17:20 ` Re: Christian COMMARMOND
2021-11-02 9:48 [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data Hans de Goede
2021-11-02 9:49 ` [PATCH v5 05/11] clk: Introduce clk-tps68470 driver Hans de Goede
[not found] ` <163588780885.2993099.2088131017920983969@swboyd.mtv.corp.google.com>
2021-11-25 15:01 ` Hans de Goede
[not found] <20211011231530.GA22856@t>
2021-10-12 1:23 ` James Bottomley
2021-10-12 2:30 ` Bart Van Assche
2021-10-08 1:24 Dmitry Baryshkov
2021-10-12 23:59 ` Linus Walleij
2021-10-13 3:46 ` Re: Dmitry Baryshkov
2021-10-13 23:39 ` Re: Linus Walleij
2021-10-17 16:54 ` Re: Bjorn Andersson
2021-10-17 21:31 ` Re: Linus Walleij
2021-10-17 21:35 ` Re: Linus Walleij
2021-09-03 20:51 Mr. James Khmalo
[not found] <CAKPXbjesQH_k1Z7k4kNwpoAf-jYgbUaPqPCgNTJZ35peVBy_pA@mail.gmail.com>
2021-08-29 12:01 ` Lukas Bulwahn
2021-07-27 2:59 [PATCH v9] iomap: Support file tail packing Gao Xiang
2021-07-27 15:10 ` Darrick J. Wong
2021-07-27 15:23 ` Andreas Grünbacher
2021-07-27 15:30 ` Re: Gao Xiang
2021-07-16 17:07 Subhasmita Swain
2021-07-16 18:15 ` Lukas Bulwahn
[not found] <CAFBCWQJX4Xy8Sot7en5JBTuKrzy=_6xFkc+QgOxJEC7G6x+jzg@mail.gmail.com>
2021-06-12 3:43 ` Re: Ammar Faizi
2021-06-06 19:19 Davidlohr Bueso
2021-06-07 16:02 ` André Almeida
[not found] <60a57e3a.lbqA81rLGmtH2qoy%Radisson97@gmx.de>
2021-05-21 11:04 ` Re: Alejandro Colomar (man-pages)
2021-05-15 22:57 Dmitry Baryshkov
2021-06-02 21:45 ` Dmitry Baryshkov
[not found] <CAJr+-6ZR2oH0J4D_Ou13JvX8HLUUK=MKQwD0Kn53cmvAuT99bg@mail.gmail.com>
2021-04-27 7:56 ` Re: Fox Chen
[not found] <b84772b0-e009-3b68-4e74-525ad8531f95@gmail.com>
2021-04-23 13:57 ` Re: Ivan Koveshnikov
2021-04-23 20:35 ` Re: Kajetan Puchalski
2021-04-15 13:41 Emmanuel Blot
2021-04-15 16:07 ` Palmer Dabbelt
2021-04-15 22:27 ` Re: Alistair Francis
2021-04-05 21:12 David Villasana Jiménez
2021-04-06 5:17 ` Greg KH
2021-04-05 0:01 Mitali Borkar
2021-04-06 7:03 ` Arnd Bergmann
[not found] <CAMCTd2kkax9P-OFNHYYz8nKuaKOOkz-zoJ7h2nZ6maUGmjXC-g@mail.gmail.com>
2021-03-16 12:16 ` Re: westjoshuaalan
2021-01-19 0:10 David Howells
2021-01-20 14:46 ` Jarkko Sakkinen
[not found] <w2q9lf-sait7s-qswxlnzeof4i-7j13q0-zgu9pt-xk3x5enp994p-kewn2p-o86qyug0mutj-91m157sheva0-4k2l8v20kyjp-heu04baxqdc7op987-9zc0bxi0jcgo-wyl26layz5p9-esqncc-g48ass.1610618007875@email.android.com>
2021-01-14 10:09 ` Re: Alexander Kapshuk
2021-01-08 10:35 misono.tomohiro
2021-01-08 10:32 Misono Tomohiro
2021-01-08 12:30 ` Arnd Bergmann
2021-01-08 12:30 ` Re: Arnd Bergmann
[not found] <CAGMNF6W8baS_zLYL8DwVsbfPWTP2ohzRB7xutW0X=MUzv93pbA@mail.gmail.com>
2020-12-02 17:09 ` Re: Kun Yi
2020-12-02 17:09 ` Re: Kun Yi
2020-12-02 1:10 [PATCH] lib/find_bit: Add find_prev_*_bit functions Yun Levi
2020-12-02 9:47 ` Andy Shevchenko
2020-12-02 10:04 ` Rasmus Villemoes
2020-12-02 11:50 ` Yun Levi
[not found] ` <CAAH8bW-jUeFVU-0OrJzK-MuGgKJgZv38RZugEQzFRJHSXFRRDA@mail.gmail.com>
2020-12-02 18:22 ` Yun Levi
2020-12-02 21:26 ` Yury Norov
2020-12-02 22:51 ` Yun Levi
2020-12-03 1:23 ` Yun Levi
2020-12-03 8:33 ` Rasmus Villemoes
2020-12-03 9:47 ` Re: Yun Levi
2020-12-03 18:46 ` Re: Yury Norov
2020-12-03 18:52 ` Re: Willy Tarreau
2020-12-04 1:36 ` Re: Yun Levi
2020-12-04 18:14 ` Re: Yury Norov
2020-12-05 0:45 ` Re: Yun Levi
2020-12-05 11:10 ` Re: Rasmus Villemoes
2020-12-05 18:20 ` Re: Yury Norov
2020-11-30 10:31 Oleksandr Tyshchenko
2020-11-30 16:21 ` Alex Bennée
2020-12-29 15:32 ` Re: Roger Pau Monné
2020-11-06 10:44 Luis Gerhorst
2020-11-06 14:34 ` Pavel Begunkov
2020-08-12 10:54 Re: Alex Anadi
2020-08-05 11:02 [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium) Amit Pundir
2020-08-06 22:31 ` Konrad Dybcio
2020-08-12 13:37 ` Amit Pundir
2020-07-16 21:22 Mauro Rossi
2020-07-20 9:00 ` Christian König
2020-07-20 9:59 ` Re: Mauro Rossi
2020-07-22 2:51 ` Re: Alex Deucher
2020-07-22 7:56 ` Re: Mauro Rossi
2020-07-24 18:31 ` Re: Alex Deucher
2020-07-26 15:31 ` Re: Mauro Rossi
2020-07-27 18:31 ` Re: Alex Deucher
2020-07-27 19:46 ` Re: Mauro Rossi
2020-07-27 19:54 ` Re: Alex Deucher
2020-06-30 17:56 (unknown) Vasiliy Kupriakov
2020-07-10 20:36 ` Andy Shevchenko
2020-06-24 13:54 Re; test02
2020-06-24 13:54 Re; test02
2020-05-21 0:22 STOREBRAND
2020-05-14 8:17 Maksim Iushchenko
2020-05-14 10:29 ` fboehm
2020-05-06 5:52 Jiaxun Yang
2020-05-06 17:17 ` Nick Desaulniers
2020-04-18 12:26 Re: Levi Brown
[not found] <CAPXXXSDVGeEK_NCSkDMwTpuvVxYkWGdQk=L=bz+RN4XLiGZmcg@mail.gmail.com>
[not found] ` <CAPXXXSBYcU1QamovmP-gVTXms67Xi_QpMCV=V3570q1nnuWqNw@mail.gmail.com>
2020-04-04 21:05 ` Re: Ruslan Bilovol
2020-04-05 1:27 ` Re: Alan Stern
2020-04-05 1:27 ` Re: Alan Stern
[not found] ` <CAPXXXSBLHYdHNSS4aM2Ax07+GQSB1WbPziOrk0iVWf-LXLmQRg@mail.gmail.com>
[not found] ` <CAPXXXSAajets4AqcBKt8aRd8V1AL4bjAmCyuBOKr8qBG-AHO1A@mail.gmail.com>
2020-04-05 2:51 ` Re: Colin Williams
2020-03-27 9:20 (unknown) chenanqing
[not found] ` <5e7dc543.vYG3wru8B/me1sOV%chenanqing-Oq79sGaMObY@public.gmane.org>
2020-03-27 15:53 ` Lee Duncan
2020-03-27 15:53 ` Re: Lee Duncan
2020-03-27 8:36 (unknown) chenanqing
2020-03-27 8:59 ` Ilya Dryomov
[not found] <CALeDE9OeBx6v6nGVjeydgF1vpfX1Bus319h3M1=49PMETdaCtw@mail.gmail.com>
2020-03-20 11:49 ` Re: Josh Boyer
2020-03-16 23:07 Sankalp Bhardwaj
2020-03-17 9:13 ` Valdis Klētnieks
2020-03-17 10:10 ` Re: suvrojit
2020-03-08 19:12 Re: Francois Pinault
2020-03-08 17:33 Re: Francois Pinault
2020-03-08 17:33 Re: Francois Pinault
2020-03-08 17:33 ` Re: Francois Pinault
2020-03-08 17:19 Re: Francois Pinault
2020-03-03 15:27 Gene Chen
2020-03-04 14:56 ` Matthias Brugger
2020-03-04 14:56 ` Re: Matthias Brugger
2020-03-04 15:15 ` Re: Lee Jones
2020-03-04 15:15 ` Re: Lee Jones
2020-03-04 18:00 ` Re: Matthias Brugger
2020-03-04 18:00 ` Re: Matthias Brugger
2020-02-26 11:57 (no subject) Ville Syrjälä
2020-02-26 12:08 ` Linus Walleij
2020-02-26 14:34 ` Re: Ville Syrjälä
2020-02-26 14:56 ` Re: Linus Walleij
2020-02-26 15:08 ` Re: Ville Syrjälä
[not found] <20200224173733.16323-1-axboe@kernel.dk>
2020-02-24 17:38 ` Re: Jens Axboe
2020-02-11 22:34 (unknown) Rajat Jain
[not found] ` <20200211223400.107604-1-rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2020-02-12 9:30 ` Jarkko Nikula
2020-02-12 9:30 ` Re: Jarkko Nikula
[not found] ` <b3397374-0cb8-cf6c-0555-34541a1c108c-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2020-02-12 10:24 ` Re: Andy Shevchenko
2020-02-12 10:24 ` Re: Andy Shevchenko
2020-02-06 6:36 Re: Viviane Jose Pereira
2020-02-06 2:24 Re: Viviane Jose Pereira
[not found] <mailman.6.1579205674.8101.b.a.t.m.a.n@lists.open-mesh.org>
2020-01-17 7:44 ` Re: Simon Wunderlich
2019-12-20 17:06 [alsa-devel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples Ben Dooks
2019-12-22 17:08 ` Dmitry Osipenko
2020-01-05 0:04 ` Ben Dooks
2020-01-05 1:48 ` Dmitry Osipenko
2020-01-05 10:53 ` Ben Dooks
2020-01-06 19:00 ` [alsa-devel] [Linux-kernel] " Ben Dooks
2020-01-07 1:39 ` Dmitry Osipenko
2020-01-23 19:38 ` Ben Dooks
2020-01-24 16:50 ` Jon Hunter
2020-01-27 19:20 ` Dmitry Osipenko
2020-01-28 12:13 ` Mark Brown
2020-01-28 17:42 ` Dmitry Osipenko
2020-01-28 18:19 ` Jon Hunter
2020-01-29 0:17 ` Dmitry Osipenko
[not found] ` <2ff97414-f0a5-7224-0e53-6cad2ed0ccd2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-01-30 8:05 ` Ben Dooks
2019-12-19 12:31 liming wu
2019-12-20 1:13 ` Andreas Dilger
[not found] <20191205030032.GA26925@ray.huang@amd.com>
2019-12-09 1:26 ` Quan, Evan
2019-11-15 16:03 Martin Nicolay
2019-11-15 16:29 ` Martin Ågren
2019-11-15 16:37 ` Re: Martin Ågren
2019-11-14 11:37 SGV INVESTMENT
2019-10-27 21:47 Margaret Kwan Wing Han
[not found] <CAGkTAxsV0zS_E64criQM-WtPKpSyW2PL=+fjACvnx2=m7piwXg@mail.gmail.com>
2019-09-27 6:37 ` Re: Michael Kerrisk (man-pages)
2019-08-30 19:54 [PATCH] Revert "asm-generic: Remove unneeded __ARCH_WANT_SYS_LLSEEK macro" Arnd Bergmann
[not found] ` <20190830202959.3539-1-msuchanek@suse.de>
2019-08-30 20:32 ` Arnd Bergmann
2019-08-20 17:23 William Baker
2019-08-20 17:27 ` Yagnatinsky, Mark
[not found] <20190703063132.GA27292@ls3530.dellerweb.de>
2019-07-03 6:38 ` Helge Deller
[not found] <DM5PR19MB165765D43BE979AB51A9897E9EEB0@DM5PR19MB1657.namprd19.prod.outlook.com>
2019-06-18 9:41 ` Re: Enrico Weigelt, metux IT consult
2019-06-13 7:02 Re: Erling Persson Foundation
2019-05-21 0:06 [PATCH v6 0/3] add new ima hook ima_kexec_cmdline to measure kexec boot cmdline args Prakhar Srivastava
2019-05-21 0:06 ` [PATCH v6 2/3] add a new ima template field buf Prakhar Srivastava
2019-05-24 15:12 ` Mimi Zohar
2019-05-24 15:42 ` Roberto Sassu
2019-05-24 15:47 ` Re: Roberto Sassu
2019-05-24 18:09 ` Re: Mimi Zohar
2019-05-24 19:00 ` Re: prakhar srivastava
2019-05-24 19:15 ` Re: Mimi Zohar
2019-03-05 14:57 [GSoC][PATCH v2 3/3] t3600: use helpers to replace test -d/f/e/s <path> Eric Sunshine
2019-03-05 23:38 ` Rohit Ashiwal
2019-02-19 2:20 Re: Pablo Mancilla
2019-02-18 23:41 Re: Pablo Mancilla
2019-02-16 4:17 Re; Richard Wahl
2019-02-16 0:08 Graham Loan Firm
2019-01-23 10:50 Christopher Hagler
2019-01-23 14:16 ` Cody Kratzer
2019-01-23 14:25 ` Re: Thomas Braun
2019-01-23 16:00 ` Re: Christopher Hagler
2019-01-23 16:35 ` Randall S. Becker
2019-01-24 17:11 ` Johannes Schindelin
2019-01-07 17:28 [PATCH] arch/arm/mm: Remove duplicate header Souptick Joarder
2019-01-17 11:23 ` Souptick Joarder
2019-01-17 11:28 ` Mike Rapoport
2019-01-31 5:54 ` Souptick Joarder
2019-01-31 12:58 ` Vladimir Murzin
2019-02-01 12:32 ` Re: Souptick Joarder
2019-02-01 12:36 ` Re: Vladimir Murzin
2019-02-01 12:41 ` Re: Souptick Joarder
2019-02-01 13:02 ` Re: Vladimir Murzin
2019-02-01 15:15 ` Re: Russell King - ARM Linux admin
2019-02-01 15:22 ` Re: Russell King - ARM Linux admin
2018-12-21 15:22 kenneth johansson
2018-12-22 8:18 ` Richard Weinberger
2018-12-04 2:28 RE, Ms Sharifah Ahmad Mustahfa
[not found] <20181130011234.32674-1-axboe@kernel.dk>
2018-11-30 2:09 ` Jens Axboe
2018-11-24 14:19 RE, Miss Sharifah Ahmad Mustahfa
2018-11-24 14:16 RE, Miss Sharifah Ahmad Mustahfa
2018-11-24 14:16 RE, Miss Sharifah Ahmad Mustahfa
2018-11-24 14:03 RE, Miss Sharifah Ahmad Mustahfa
[not found] <CAJUWh6qyHerKg=-oaFN+USa10_Aag5+SYjBOeLCX1qM+WcDUwA@mail.gmail.com>
2018-11-23 7:52 ` Chris Murphy
2018-11-23 9:34 ` Re: Andy Leadbetter
[not found] <CACikiw1uNCYKzo9vjG=AZHpARWv-nzkCX=D-aWBssM7vYZrQdQ@mail.gmail.com>
2018-11-12 10:09 ` Re: Ravi Kumar
2018-11-15 13:11 ` Re: Ondrej Mosnacek
2018-11-11 4:20 RE, Miss Juliet Muhammad
2018-11-06 1:21 RE, Miss Juliet Muhammad
2018-10-29 14:20 Beierl, Mark
2018-10-29 14:37 ` Re: Mohanraj B
2018-10-26 12:54 Mohanraj B
2018-10-27 16:55 ` Jens Axboe
2018-10-08 13:33 Netravnen
2018-10-08 13:34 ` Inderpreet Saini
2018-08-28 17:34 Bills, Jason M
2018-08-28 17:59 ` Brad Bishop
2018-08-28 23:26 ` Bills, Jason M
2018-09-04 20:46 ` Brad Bishop
2018-09-04 21:28 ` Re: Ed Tanous
2018-09-04 22:34 ` Re: Brad Bishop
2018-09-04 23:18 ` Re: Ed Tanous
2018-09-04 23:42 ` Re: Brad Bishop
2018-09-05 21:20 ` Re: Bills, Jason M
2018-04-27 0:54 [PATCH v3 2/3] merge: Add merge.renames config setting Ben Peart
2018-04-27 18:19 ` Elijah Newren
2018-04-30 13:11 ` Ben Peart
2018-04-30 16:12 ` Re: Elijah Newren
2018-05-02 14:33 ` Re: Ben Peart
[not found] <CAAEAJfB76xseRqnYQfRihXY6g0Jyqwt8zfddU1W7CXDg3xEFFg@mail.gmail.com>
2018-04-02 11:20 ` Re: Ratheendran R
2018-04-02 17:19 ` Re: Steve deRosier
2018-04-04 7:31 ` Re: Arend van Spriel
[not found] <CABxXbAeQTGbiAEaFHK4RUTFGxt0A+KnCCmhJNU9XDivW5=SL-Q@mail.gmail.com>
2018-03-08 18:23 ` Ivan Lapuz
2018-03-08 18:33 ` Tommy Bowditch
2018-03-08 18:36 ` Re: Ibrahim Tachijian
[not found] <[PATCH xf86-video-amdgpu 0/3] Add non-desktop and leasing support>
2018-03-03 4:49 ` (unknown), Keith Packard
[not found] ` <20180303044931.6902-1-keithp-aN4HjG94KOLQT0dZR+AlfA@public.gmane.org>
2018-03-05 10:02 ` Michel Dänzer
[not found] ` <82fc592b-f680-c663-1a0f-7b522ca932d2-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-03-05 16:41 ` Re: Keith Packard
2018-03-02 18:01 [Outreachy kernel] Help with Mutt Julia Lawall
2018-03-03 18:27 ` Nishka Dasgupta
2018-03-03 18:38 ` Re: Julia Lawall
2018-03-01 21:17 Re: Nishka Dasgupta
2018-03-01 20:04 [Outreachy kernel] [PATCH v2] staging: ks7010: Remove spaces after typecast to int Julia Lawall
2018-03-01 21:20 ` Nishka Dasgupta
2018-03-01 19:33 [PATCH v2] staging: vc04_services: bcm2835-camera: Add blank line Greg KH
2018-03-01 20:20 ` Nishka Dasgupta
2018-03-01 20:31 ` Re: Greg KH
2018-03-08 18:23 ` Re: Nishka Dasgupta
2018-03-08 18:33 ` Re: Greg KH
2018-02-27 13:58 [Outreachy kernel] Re: Julia Lawall
2018-02-27 14:07 ` Re: Nishka Dasgupta
2018-02-27 13:39 [Outreachy kernel] Re: Re: [PATCH] h [Patch] Fixed unnecessary typecasting to in. Error found with checkpatch. Signed-off-by: Nishka Dasgupta <nishka.dasgupta_ug18@ashoka.edu.in> Julia Lawall
2018-02-27 13:53 ` Nishka Dasgupta
2018-02-27 1:18 Alan Gage
2018-02-27 10:26 ` René Scharfe
2018-01-27 3:56 Re: Emile Kenold
2018-01-24 22:11 Re: Amy Riddering
2018-01-24 19:54 Re: Amy Riddering
2017-11-20 15:10 Viet Nguyen
2017-11-20 20:07 ` Stefan Beller
2017-11-13 15:04 Re: Amos Kalonzo
2017-11-13 15:01 Re: Amos Kalonzo
2017-11-13 15:00 Re: Amos Kalonzo
2017-11-13 14:57 Re: Amos Kalonzo
2017-11-13 14:56 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 ` Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:55 Re: Amos Kalonzo
2017-11-13 14:44 Re: Amos Kalonzo
2017-11-13 14:42 Re: Amos Kalonzo
2017-11-12 2:21 hsed
2017-11-13 18:56 ` Stefan Beller
2017-11-01 14:57 Mrs Hsu Wealther
2017-10-18 14:31 Mrs. Marie Angèle O
2017-10-01 10:53 Pierre
2017-09-24 16:59 RE: Estrin, Alex
[not found] ` <F3529576D8E232409F431C309E29399336CD9886-8k97q/ur5Z1cIJlls4ac1rfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2017-09-25 5:48 ` Leon Romanovsky
2017-07-27 1:12 Re: Marie Angèle Ouattara
2017-07-19 8:03 Re: Lynne Smith
2017-07-19 8:03 Re: Lynne Smith
2017-07-07 17:04 Mrs Alice Walton
[not found] <20170519213731.21484-1-mrugiero@gmail.com>
2017-05-20 8:48 ` Boris Brezillon
2017-05-16 22:46 Re: USPS Parcels Delivery
2017-05-04 23:57 Re: Tammy
[not found] <CAMj-D2DO_CfvD77izsGfggoKP45HSC9aD6auUPAYC9Yeq_aX7w@mail.gmail.com>
2017-05-04 16:44 ` Re: gengdongjiu
2017-05-03 11:26 Re: Paul Lopez-Bravo
2017-05-03 6:23 Re: H.A
2017-05-03 6:23 Re: H.A
2017-05-03 6:23 Re: H.A
2017-05-03 6:23 Re: H.A
2017-05-03 6:23 Re: H.A
2017-05-03 6:23 Re: H.A
2017-05-03 6:23 Re: H.A
2017-05-03 5:59 Re: H.A
2017-04-29 22:53 Re: USPS Station Management
2017-04-28 18:27 Re: USPS Ground Support
2017-04-28 8:20 (unknown), Anatolij Gustschin
2017-04-28 8:43 ` Linus Walleij
2017-04-28 9:26 ` Re: Anatolij Gustschin
[not found] <CALDO+SZPQGmp4VH0LvCh95uXWvwzAoj+wN-rm0pGu5e0wCcyNw@mail.gmail.com>
2017-04-19 18:13 ` Re: Joe Stringer
2017-04-13 15:58 (unknown), Scott Ellentuch
[not found] ` <CAK2H+efb3iKA5P3yd7uRqJomci6ENvrB1JRBBmtQEpEvyPMe7w@mail.gmail.com>
2017-04-13 16:38 ` Scott Ellentuch
2017-04-11 14:37 Re: USPS Priority Delivery
2017-04-10 3:17 Qin Yan jun
2017-04-01 5:31 USPS Delivery
2017-03-19 15:00 Ilan Schwarts
2017-03-23 17:12 ` Jeff Mahoney
2017-02-23 15:15 Qin's Yanjun
2017-02-23 15:13 RE: Qin's Yanjun
2017-02-23 15:10 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 ` RE: Qin's Yanjun
2017-02-23 15:09 ` RE: Qin's Yanjun
2017-02-23 15:09 ` RE: Qin's Yanjun
2017-02-23 15:09 ` RE: Qin's Yanjun
2017-02-23 15:09 ` RE: Qin's Yanjun
2017-02-23 15:09 ` RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-23 15:09 RE: Qin's Yanjun
2017-02-16 19:41 simran singhal
2017-02-16 19:44 ` SIMRAN SINGHAL
2017-01-25 0:11 [PATCH 7/7] completion: recognize more long-options Cornelius Weig
2017-01-25 0:21 ` Stefan Beller
2017-01-25 0:43 ` Cornelius Weig
2017-01-25 0:52 ` Re: Stefan Beller
2017-01-25 0:54 ` Re: Linus Torvalds
2017-01-25 1:32 ` Re: Eric Wong
2016-11-15 4:40 Apply
2016-11-09 17:55 bepi
2016-11-10 6:57 ` Alex Powell
2016-11-10 13:00 ` Re: bepi
2016-11-06 21:00 (unknown), Dennis Dataopslag
2016-11-07 16:50 ` Wols Lists
2016-11-07 17:13 ` Re: Wols Lists
2016-11-17 20:33 ` Re: Dennis Dataopslag
2016-11-17 22:12 ` Re: Wols Lists
2016-09-27 16:50 Rajat Jain
2016-09-27 16:57 ` Rajat Jain
2016-09-10 21:51 Re: Michelle Ouellette
2016-09-01 2:02 Fennec Fox
2016-09-01 3:10 ` Jeff Mahoney
2016-09-01 19:32 ` Re: Kai Krakow
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.