March 2025 - Linux-stable-mirror

[PATCH v2 RESEND] PCI: fix reference leak in pci_register_host_bridge()

by Ma Ke

Once device_register() failed, we should call put_device() to decrement reference count for cleanup. Or it could cause memory leak. device_register() includes device_add(). As comment of device_add() says, 'if device_add() succeeds, you should call device_del() when you want to get rid of it. If device_add() has not succeeded, use only put_device() to drop the reference count'. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 37d6a0a6f470 ("PCI: Add pci_register_host_bridge() interface") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- Changes in v2: - modified the patch description. --- drivers/pci/probe.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 246744d8d268..7b1d7ce3a83e 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1018,8 +1018,10 @@ static int pci_register_host_bridge(struct pci_host_bridge *bridge) name = dev_name(&bus->dev); err = device_register(&bus->dev); - if (err) + if (err) { + put_device(&bus->dev); goto unregister; + } pcibios_add_bus(bus); -- 2.25.1

4 months

2
1
0 0

Regression from 7627a0edef54 ("ata: ahci: Drop low power policy board type") on reboot (but not cold boot)

by Salvatore Bonaccorso

Hi Mario et al, Eric Degenetais reported in Debian (cf. https://bugs.debian.org/1091696) for his report, that after 7627a0edef54 ("ata: ahci: Drop low power policy board type") rebooting the system fails (but system boots fine if cold booted). His report mentions that the SSD is not seen on warm reboots anymore. Does this ring some bell which might be caused by the above bisected[1] commit? #regzbot introduced: 7627a0edef54 #regzbot link: https://bugs.debian.org/1091696 What information to you could be helpful to identify the problem? Regards, Salvatore [1] https://bugs.debian.org/1091696#10

4 months

4
5
0 0

[PATCH vhost v2] vdpa/mlx5: Fix oversized null mkey longer than 32bit

by Dragos Tatulea

From: Si-Wei Liu <si-wei.liu(a)oracle.com> create_user_mr() has correct code to count the number of null keys used to fill in a hole for the memory map. However, fill_indir() does not follow the same to cap the range up to the 1GB limit correspondingly. Fill in more null keys for the gaps in between, so that null keys are correctly populated. Fixes: 94abbccdf291 ("vdpa/mlx5: Add shared memory registration code") Cc: stable(a)vger.kernel.org Reported-by: Cong Meng <cong.meng(a)oracle.com> Signed-off-by: Si-Wei Liu <si-wei.liu(a)oracle.com> Signed-off-by: Dragos Tatulea <dtatulea(a)nvidia.com> Acked-by: Eugenio Pérez <eperezma(a)redhat.com> --- Changes in v2: - Added Reported-by tag. - Fixed typo found during review. --- drivers/vdpa/mlx5/core/mr.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c index 8455f08f5d40..61424342c096 100644 --- a/drivers/vdpa/mlx5/core/mr.c +++ b/drivers/vdpa/mlx5/core/mr.c @@ -190,9 +190,12 @@ static void fill_indir(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_mr *mkey, v klm->bcount = cpu_to_be32(klm_bcount(dmr->end - dmr->start)); preve = dmr->end; } else { + u64 bcount = min_t(u64, dmr->start - preve, MAX_KLM_SIZE); + klm->key = cpu_to_be32(mvdev->res.null_mkey); - klm->bcount = cpu_to_be32(klm_bcount(dmr->start - preve)); - preve = dmr->start; + klm->bcount = cpu_to_be32(klm_bcount(bcount)); + preve += bcount; + goto again; } } -- 2.43.0

4 months

3
2
0 0

[Stable Regression Bisected] Linux 6.13.2 breaks mt7925e

by Caleb Jorden

Hello Kernel team, I discovered that the 6.13.2 kernel breaks my laptop's wireless. Here are the details of my system: - Framework 13 (AMD Ryzen 7840) - mt7925e wireless card (purchased from: https://www.amazon.com/dp/B0DP68GV9V) - Arch Linux, using IWD (3.3) to manage Wireless network connectivity When running the 6.13.0 and 6.13.1 kernels (from Arch), the wireless adapter worked very well. I was able to associate to my Wifi 7 network (Ubiquiti U7 Pros) and operate in the 6GHz spectrum with 160MHz channels. I also have an older wireless network that runs on Google Nest routers. When I upgraded to the 6.13.2 kernel from Arch Linux, my wireless suddenly stopped working. I looked at the kernel logs and saw these messages (wireless addresses changed to make clearer the different points): [ 10.007185] wlan0: authenticate with 28:80:xx:yy:zz:6e (local address=40:1a:58:aa:bb:cc) [ 10.376446] wlan0: send auth to 28:80:xx:yy:zz:6e (try 1/3) [ 10.384610] wlan0: 28:80:xx:yy:zz:6e denied authentication (status 77) [ 10.483900] wlan0: authenticate with 28:80:xx:yy:zz:6e (local address=40:1a:58:aa:bb:cc) [ 10.490138] wlan0: send auth to 28:80:xx:yy:zz:6e (try 1/3) [ 10.507531] wlan0: send auth to 28:80:xx:yy:zz:6e (try 2/3) [ 10.525580] wlan0: send auth to 28:80:xx:yy:zz:6e (try 3/3) [ 10.543048] wlan0: authentication with 28:80:xx:yy:zz:6e timed out [ 10.619423] wlan0: authenticate with 28:80:aa:bb:cc:e1 (local address=40:1a:58:aa:bb:cc) [ 10.749880] wlan0: send auth to 28:80:aa:bb:cc:e1 (try 1/3) [ 10.768530] wlan0: send auth to 28:80:aa:bb:cc:e1 (try 2/3) [ 10.786954] wlan0: send auth to 28:80:aa:bb:cc:e1 (try 3/3) [ 10.805792] wlan0: authentication with 28:80:aa:bb:cc:e1 timed out [ 10.881620] wlan0: authenticate with 28:80:ee:ff:gg:6d (local address=40:1a:58:aa:bb:cc) [ 11.016891] wlan0: send auth to 28:80:ee:ff:gg:6d (try 1/3) [ 11.033622] wlan0: send auth to 28:80:ee:ff:gg:6d (try 2/3) [ 11.050574] wlan0: send auth to 28:80:ee:ff:gg:6d (try 3/3) [ 11.065250] wlan0: authentication with 28:80:ee:ff:gg:6d timed out [ 11.139745] wlan0: authenticate with 2a:80:hh:ii:jj:6f (local address=40:1a:58:aa:bb:cc) [ 11.506205] wlan0: send auth to 2a:80:hh:ii:jj:6f (try 1/3) [ 11.528071] wlan0: send auth to 2a:80:hh:ii:jj:6f (try 2/3) [ 11.550043] wlan0: send auth to 2a:80:hh:ii:jj:6f (try 3/3) [ 11.572005] wlan0: authentication with 2a:80:hh:ii:jj:6f timed out [ 16.312942] wlan0: authenticate with 2a:80:kk:ll:mm:e3 (local address=40:1a:58:aa:bb:cc) [ 16.675865] wlan0: send auth to 2a:80:kk:ll:mm:e3 (try 1/3) [ 16.702328] wlan0: send auth to 2a:80:kk:ll:mm:e3 (try 2/3) [ 16.726162] wlan0: send auth to 2a:80:kk:ll:mm:e3 (try 3/3) [ 16.748958] wlan0: authentication with 2a:80:kk:ll:mm:e3 timed out [ 16.829874] wlan0: authenticate with 2a:80:nn:oo:pp:e2 (local address=40:1a:58:aa:bb:cc) [ 17.196579] wlan0: send auth to 2a:80:nn:oo:pp:e2 (try 1/3) [ 17.214256] wlan0: send auth to 2a:80:nn:oo:pp:e2 (try 2/3) [ 17.231852] wlan0: send auth to 2a:80:nn:oo:pp:e2 (try 3/3) [ 17.250116] wlan0: authentication with 2a:80:nn:oo:pp:e2 timed out Then IWD seems to have stopped attempting to associate for some time. My wireless interface showed link down, and I had no IP address. I attempted to associate to my older Google Nest network, but that also failed with the same behavior (thus showing the problem not to be Wifi 7 or Ubiquiti-specific). I compiled up the mainline 6.13.2 kernel myself and saw the same behavior. I then went back to the Arch 6.13.1 kernel, and the system operated perfectly fine as expected. I bisected the break to this commit: $ git bisect good c76fba3b07c7fb841c4f8f2acc0f01ff3cf73674 is the first bad commit commit c76fba3b07c7fb841c4f8f2acc0f01ff3cf73674 Author: Ming Yen Hsieh <mingyen.hsieh(a)mediatek.com> Date: Tue Dec 10 17:19:25 2024 -0800 wifi: mt76: mt7925: Cleanup MLO settings post-disconnection [ Upstream commit 816161051a039eeb1226fc85e2b38389f508906c ] Clean up MLO settings after disconnection. Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when the firmware supports it") Signed-off-by: Ming Yen Hsieh <mingyen.hsieh(a)mediatek.com> Signed-off-by: Sean Wang <sean.wang(a)mediatek.com> Link: https://patch.msgid.link/20241211011926.5002-16-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd(a)nbd.name> Signed-off-by: Sasha Levin <sashal(a)kernel.org> drivers/net/wireless/mediatek/mt76/mt7925/main.c | 37 +++++++++++++++++++++++++++++++++++-- drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 4 ++-- drivers/net/wireless/mediatek/mt76/mt7925/mcu.h | 2 +- 3 files changed, 38 insertions(+), 5 deletions(-) I attempted to revert this commit on top of 6.13.2, but there are other commits that modify these files, so it can not be reverted by itself. I looked at the commit, and a thought occurred to me that maybe wpa_supplicant might still function even though iwd did not. I set up wpa_supplicant, and found that I was able to associate and pass network traffic. HOWEVER, when running a simple iperf3 test, saw very slow speeds while associated (about 10 times slower than seen with the 6.13.1 kernel). Thus, I think this is quite clearly a regression. My guess is that this wireless adapter is new enough that many people have yet to hit this. Here are the details of the card: # dmesg | grep mt79: [ 12.617246] mt7925e 0000:01:00.0: enabling device (0000 -> 0002) [ 12.622426] mt7925e 0000:01:00.0: ASIC revision: 79250000 [ 12.698681] mt7925e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20241104132949a [ 13.047884] mt7925e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20241104133053 # lspci -vvv (mediatek device): 01:00.0 Network controller: MEDIATEK Corp. Device 7925 (rev 01) Subsystem: Hewlett-Packard Company Device 8c38 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 116 IOMMU group: 12 Region 0: Memory at 90600000 (64-bit, non-prefetchable) [size=2M] Region 2: Memory at 90800000 (64-bit, non-prefetchable) [size=32K] Capabilities: [80] Express (v2) Endpoint, IntMsgNum 0 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 75W TEE-IO- DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd- ExtTag+ PhantFunc- AuxPwr- NoSnoop+ FLReset- MaxPayload 256 bytes, MaxReadReq 512 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <2us, L1 <8us ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM L1 Enabled; RCB 64 bytes, LnkDisable- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 5GT/s, Width x1 TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ NROPrPrP- LTR+ 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt+ EETLPPrefix- EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- TPHComp- ExtTPHComp- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- AtomicOpsCtl: ReqEn- IDOReq- IDOCompl- LTR+ EmergencyPowerReductionReq- 10BitTagReq- OBFF Disabled, EETLPPrefixBlk- LnkCap2: Supported Link Speeds: 2.5-5GT/s, Crosslink- Retimer- 2Retimers- DRS- LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance Preset/De-emphasis: -6dB de-emphasis, 0dB preshoot LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete- EqualizationPhase1- EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- Retimer- 2Retimers- CrosslinkRes: unsupported Capabilities: [e0] MSI: Enable+ Count=1/32 Maskable+ 64bit+ Address: 00000000fee00000 Data: 0000 Masking: fffffffe Pending: 00000000 Capabilities: [f8] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [100 v1] Vendor Specific Information: ID=1556 Rev=1 Len=008 <?> Capabilities: [108 v1] Latency Tolerance Reporting Max snoop latency: 1048576ns Max no snoop latency: 1048576ns Capabilities: [110 v1] L1 PM Substates L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ PortCommonModeRestoreTime=3us PortTPowerOnTime=52us L1SubCtl1: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ T_CommonMode=0us LTR1.2_Threshold=166912ns L1SubCtl2: T_PwrOn=150us Capabilities: [200 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UncorrIntErr- BlockedTLP- AtomicOpBlocked- TLPBlockedErr- PoisonTLPBlocked- DMWrReqBlocked- IDECheck- MisIDETLP- PCRC_CHECK- TLPXlatBlocked- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UncorrIntErr+ BlockedTLP- AtomicOpBlocked- TLPBlockedErr- PoisonTLPBlocked- DMWrReqBlocked- IDECheck- MisIDETLP- PCRC_CHECK- TLPXlatBlocked- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- UncorrIntErr+ BlockedTLP- AtomicOpBlocked- TLPBlockedErr- PoisonTLPBlocked- DMWrReqBlocked- IDECheck- MisIDETLP- PCRC_CHECK- TLPXlatBlocked- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ CorrIntErr- HeaderOF- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ CorrIntErr+ HeaderOF- AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: 00000000 00000000 00000000 00000000 Kernel driver in use: mt7925e Kernel modules: mt7925e On my system, /etc/iwd/main.conf contains: ------------ [Scan] DisablePeriodicScan=true [General] EnableNetworkConfiguration=true Country=US ------------ At this point my suggestion is that the v6.13.2 mt7925 changes should be reverted from the stable series for now, unless a fix can be quickly found. I have not yet tested 6.14-rc2, but would be willing to do so if it would be helpful. Note: I am not subscribed to any of these lists, so please CC me if you want to contact me about this. Respectfully submitted, Caleb Jorden cjorden(a)gmail.com

4 months

3
6
0 0

[PATCH v2] arm64: dts: ti: k3-j784s4-j742s2-main-common: Correct the GICD size

by Keerthy

Currently we get the warning: "GICv3: [Firmware Bug]: GICR region 0x0000000001900000 has overlapping address" As per TRM GICD is 64 KB. Fix it by correcting the size of GICD. Fixes: 9cc161a4509c ("arm64: dts: ti: Refactor J784s4 SoC files to a common file") Signed-off-by: Keerthy <j-keerthy(a)ti.com> Cc: stable(a)vger.kernel.org --- Changes in V2: * Added the fixes tag * Cc: stable arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi index 83bbf94b58d1..3b72fca158ad 100644 --- a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi +++ b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi @@ -193,7 +193,7 @@ ranges; #interrupt-cells = <3>; interrupt-controller; - reg = <0x00 0x01800000 0x00 0x200000>, /* GICD */ + reg = <0x00 0x01800000 0x00 0x10000>, /* GICD */ <0x00 0x01900000 0x00 0x100000>, /* GICR */ <0x00 0x6f000000 0x00 0x2000>, /* GICC */ <0x00 0x6f010000 0x00 0x1000>, /* GICH */ -- 2.17.1

4 months

3
2
0 0

[PATCH for stable 5.10.x] btrfs: bring back the incorrectly removed extent buffer lock recursion support

by fdmanana＠kernel.org

From: Filipe Manana <fdmanana(a)suse.com> Commit 51b03b7473a0 ("btrfs: locking: remove the recursion handling code") from the 5.10.233 stable tree removed the support for extent buffer lock recursion, but we need that code because in 5.10.x we load the free space cache synchronously - while modifying the extent tree and holding a write lock on some extent buffer, we may need to load the free space cache, which requires acquiring read locks on the extent tree and therefore result in a deadlock in case we need to read lock an extent buffer we had write locked while modifying the extent tree. Backporting that commit from Linus' tree is therefore wrong, and was done so in order to backport upstream commit 97e86631bccd ("btrfs: don't set lock_owner when locking extent buffer for reading"). However we should have instead had the commit adapted to the 5.10 stable tree instead. Note that the backport of that dependency is ok only for stable trees 5.11+, because in those tree the space cache loading code is not synchronous anymore, so there is no need to have the lock recursion and indeed there are no users of the extent buffer lock recursion support. In other words, the backport is only valid for kernel releases that have the asynchrounous free space cache loading support, which was introduced in kernel 5.11 with commit e747853cae3a ("btrfs: load free space cache asynchronously"). This was causing deadlocks and reported by a user (see below Link tag). So revert commit 51b03b7473a0 ("btrfs: locking: remove the recursion handling code") while not undoing what commit d5a30a6117ea ("btrfs: don't set lock_owner when locking extent buffer for reading") from the 5.10.x stable tree did. Reported-by: pk <pkoroau(a)gmail.com> Link: https://lore.kernel.org/linux-btrfs/CAMNwjEKH6znTHE5hMc5er2dFs5ypw4Szx6TMDM… Signed-off-by: Filipe Manana <fdmanana(a)suse.com> --- fs/btrfs/locking.c | 68 +++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 64 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/locking.c b/fs/btrfs/locking.c index 3d177ef92ab6..24049d054263 100644 --- a/fs/btrfs/locking.c +++ b/fs/btrfs/locking.c @@ -25,18 +25,43 @@ * - reader/reader sharing * - try-lock semantics for readers and writers * - * The rwsem implementation does opportunistic spinning which reduces number of - * times the locking task needs to sleep. + * Additionally we need one level nesting recursion, see below. The rwsem + * implementation does opportunistic spinning which reduces number of times the + * locking task needs to sleep. + * + * + * Lock recursion + * -------------- + * + * A write operation on a tree might indirectly start a look up on the same + * tree. This can happen when btrfs_cow_block locks the tree and needs to + * lookup free extents. + * + * btrfs_cow_block + * .. + * alloc_tree_block_no_bg_flush + * btrfs_alloc_tree_block + * btrfs_reserve_extent + * .. + * load_free_space_cache + * .. + * btrfs_lookup_file_extent + * btrfs_search_slot + * */ /* * __btrfs_tree_read_lock - lock extent buffer for read * @eb: the eb to be locked * @nest: the nesting level to be used for lockdep - * @recurse: unused + * @recurse: if this lock is able to be recursed * * This takes the read lock on the extent buffer, using the specified nesting * level for lockdep purposes. + * + * If you specify recurse = true, then we will allow this to be taken if we + * currently own the lock already. This should only be used in specific + * usecases, and the subsequent unlock will not change the state of the lock. */ void __btrfs_tree_read_lock(struct extent_buffer *eb, enum btrfs_lock_nesting nest, bool recurse) @@ -46,7 +71,31 @@ void __btrfs_tree_read_lock(struct extent_buffer *eb, enum btrfs_lock_nesting ne if (trace_btrfs_tree_read_lock_enabled()) start_ns = ktime_get_ns(); + if (unlikely(recurse)) { + /* First see if we can grab the lock outright */ + if (down_read_trylock(&eb->lock)) + goto out; + + /* + * Ok still doesn't necessarily mean we are already holding the + * lock, check the owner. + */ + if (eb->lock_owner != current->pid) { + down_read_nested(&eb->lock, nest); + goto out; + } + + /* + * Ok we have actually recursed, but we should only be recursing + * once, so blow up if we're already recursed, otherwise set + * ->lock_recursed and carry on. + */ + BUG_ON(eb->lock_recursed); + eb->lock_recursed = true; + goto out; + } down_read_nested(&eb->lock, nest); +out: trace_btrfs_tree_read_lock(eb, start_ns); } @@ -85,11 +134,22 @@ int btrfs_try_tree_write_lock(struct extent_buffer *eb) } /* - * Release read lock. + * Release read lock. If the read lock was recursed then the lock stays in the + * original state that it was before it was recursively locked. */ void btrfs_tree_read_unlock(struct extent_buffer *eb) { trace_btrfs_tree_read_unlock(eb); + /* + * if we're nested, we have the write lock. No new locking + * is needed as long as we are the lock owner. + * The write unlock will do a barrier for us, and the lock_recursed + * field only matters to the lock owner. + */ + if (eb->lock_recursed && current->pid == eb->lock_owner) { + eb->lock_recursed = false; + return; + } up_read(&eb->lock); } -- 2.45.2

4 months

1
0
0 0

[PATCH] mm: page_frag: Fix refill handling in __page_frag_alloc_align()

by Haiyang Zhang

In commit 8218f62c9c9b ("mm: page_frag: use initial zero offset for page_frag_alloc_align()"), the check for fragsz is moved earlier. So when the cache is used up, and if the fragsz > PAGE_SIZE, it won't try to refill, and just return NULL. I tested it with fragsz:8192, cache-size:32768. After the initial four successful allocations, it failed, even there is plenty of free memory in the system. To fix, revert the refill logic like before: the refill is attempted before the check & return NULL. Cc: linyunsheng(a)huawei.com Cc: stable(a)vger.kernel.org Fixes: 8218f62c9c9b ("mm: page_frag: use initial zero offset for page_frag_alloc_align()") Signed-off-by: Haiyang Zhang <haiyangz(a)microsoft.com> --- mm/page_frag_cache.c | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/mm/page_frag_cache.c b/mm/page_frag_cache.c index d2423f30577e..82935d7e53de 100644 --- a/mm/page_frag_cache.c +++ b/mm/page_frag_cache.c @@ -119,19 +119,6 @@ void *__page_frag_alloc_align(struct page_frag_cache *nc, size = PAGE_SIZE << encoded_page_decode_order(encoded_page); offset = __ALIGN_KERNEL_MASK(nc->offset, ~align_mask); if (unlikely(offset + fragsz > size)) { - if (unlikely(fragsz > PAGE_SIZE)) { - /* - * The caller is trying to allocate a fragment - * with fragsz > PAGE_SIZE but the cache isn't big - * enough to satisfy the request, this may - * happen in low memory conditions. - * We don't release the cache page because - * it could make memory pressure worse - * so we simply return NULL here. - */ - return NULL; - } - page = encoded_page_decode_page(encoded_page); if (!page_ref_sub_and_test(page, nc->pagecnt_bias)) @@ -149,6 +136,19 @@ void *__page_frag_alloc_align(struct page_frag_cache *nc, /* reset page count bias and offset to start of new frag */ nc->pagecnt_bias = PAGE_FRAG_CACHE_MAX_SIZE + 1; offset = 0; + + if (unlikely(fragsz > size)) { + /* + * The caller is trying to allocate a fragment + * with fragsz > size but the cache isn't big + * enough to satisfy the request, this may + * happen in low memory conditions. + * We don't release the cache page because + * it could make memory pressure worse + * so we simply return NULL here. + */ + return NULL; + } } nc->pagecnt_bias--; -- 2.34.1

4 months

2
4
0 0

ADNOC UAE Vendor/Supplies Project -BID-06

by Mr. Adam Ibrahim

Greeting's To You, We are reaching out to invite your esteemed company to participate in the contractors, consultants, maintenance, suppliers, and service providers Expression of Interest (EOI) process. This initiative is focused on selecting experienced service providers within the UAE for upcoming projects in Oil & Gas and construction sectors. Our goal is to identify and shortlist qualified companies to receive Invitations to Bid (ITB) or Requests for Proposal (RFP) for the specified services outlined in the EOI package appendix. This is an excellent opportunity to collaborate with Abu Dhabi National Oil Company (ADNOC) on our 2025/2026 projects. If your company is interested in participating and being shortlisted, please confirm your intention by requesting the Vendor Questionnaire and EOI package. Looking forward to your response. Contact Email: contracts(a)adncprocurementbid.com Best regards, Mr. Adam Ibrahim Abdul Senior Project Manager/ Procurement Support Dept. Abu Dhabi National Oil Company (ADNOC) ADNOC HQ, P O Box. 898, Corniche Road West, Abu Dhabi, UAE United Arab Emirates.

4 months

1
0
0 0

[PATCH] ocfs2: Validate chain list bits per cluster to prevent div-by-zero

by Qasim Ijaz

The call trace shows that the div error occurs on the following line where the code sets the e_cpos member of the extent record while dividing bg_bits by the bits per cluster value from the chain list: rec->e_cpos = cpu_to_le32(le16_to_cpu(bg->bg_bits) / le16_to_cpu(cl->cl_bpc)); Looking at the code disassembly we see the problem occurred during the divw instruction which performs a 16-bit unsigned divide operation. The main ways a divide error can occur is if: 1) the divisor is 0 2) if the quotient is too large for the designated register (overflow). Normally the divisor being 0 is the most common cause for a division error to occur. Focusing on the bits per cluster cl->cl_bpc (since it is the divisor) we see that cl is created in ocfs2_block_group_alloc(), cl is derived from ocfs2_dinode->id2.i_chain. To fix this issue we should verify the cl_bpc member in the chain list to ensure it is valid and non-zero. Looking through the rest of the OCFS2 code it seems like there are other places which could benefit from improved checks of the cl_bpc members of chain lists like the following: In ocfs2_group_extend(): cl_bpc = le16_to_cpu(fe->id2.i_chain.cl_bpc); if (le16_to_cpu(group->bg_bits) / cl_bpc + new_clusters > le16_to_cpu(fe->id2.i_chain.cl_cpg)) { ret = -EINVAL; goto out_unlock; } Reported-by: syzbot <syzbot+e41e83af7a07a4df8051(a)syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=e41e83af7a07a4df8051 Cc: stable(a)vger.kernel.org Signed-off-by: Qasim Ijaz <qasdev00(a)gmail.com> --- fs/ocfs2/resize.c | 4 ++-- fs/ocfs2/suballoc.c | 5 +++++ 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/fs/ocfs2/resize.c b/fs/ocfs2/resize.c index b0733c08ed13..22352c027ecd 100644 --- a/fs/ocfs2/resize.c +++ b/fs/ocfs2/resize.c @@ -329,8 +329,8 @@ int ocfs2_group_extend(struct inode * inode, int new_clusters) group = (struct ocfs2_group_desc *)group_bh->b_data; cl_bpc = le16_to_cpu(fe->id2.i_chain.cl_bpc); - if (le16_to_cpu(group->bg_bits) / cl_bpc + new_clusters > - le16_to_cpu(fe->id2.i_chain.cl_cpg)) { + if (!cl_bpc || le16_to_cpu(group->bg_bits) / cl_bpc + new_clusters > + le16_to_cpu(fe->id2.i_chain.cl_cpg)) { ret = -EINVAL; goto out_unlock; } diff --git a/fs/ocfs2/suballoc.c b/fs/ocfs2/suballoc.c index f7b483f0de2a..844cb36bd7ab 100644 --- a/fs/ocfs2/suballoc.c +++ b/fs/ocfs2/suballoc.c @@ -671,6 +671,11 @@ static int ocfs2_block_group_alloc(struct ocfs2_super *osb, BUG_ON(ocfs2_is_cluster_bitmap(alloc_inode)); cl = &fe->id2.i_chain; + if (!le16_to_cpu(cl->cl_bpc)) { + status = -EINVAL; + goto bail; + } + status = ocfs2_reserve_clusters_with_limit(osb, le16_to_cpu(cl->cl_cpg), max_block, flags, &ac); -- 2.39.5

4 months

1
0
0 0

Reply Request For Embedded World Conference 2025

by Michelle Stone

Hi, I just wanted to check in and see if you had the chance to review my previous email regarding Embedded World Exhibition & Conference 2025. Looking forward to your reply. Kind regards, Michelle Stone _____________________________________________________________________________________ From: Michelle Stone Subject: Embedded World Exhibition & Conference 2025 Hi, I just wanted to check if you’d be interested in acquiring the visitors contact list of Embedded World Exhibition & Conference 2025. We currently have 33,999 verified visitor contacts Additionally, we can also provide the Exhibitors list upon request. Let me know if you would like to see counts and pricing for your review. Regards, Michelle Stone Sr. Marketing Manager If you do not wish to receive this newsletter reply as “Unfollow”

4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2025