Le mar. 23 juin 2026, 19:23, Bruce Ashfield <[email protected]> a écrit :
> > > On Tue, Jun 23, 2026 at 1:11 PM Yoann Congal <[email protected]> > wrote: > >> >> >> >> Le mar. 23 juin 2026, 19:00, Bruce Ashfield <[email protected]> a >> écrit : >> >>> >>> >>> On Tue, Jun 23, 2026 at 12:21 PM Yoann Congal <[email protected]> >>> wrote: >>> >>>> On Wed Jun 10, 2026 at 6:49 PM CEST, Bruce Ashfield via >>>> lists.openembedded.org wrote: >>>> > From: Bruce Ashfield <[email protected]> >>>> > >>>> > Updating linux-yocto/6.6 to the latest korg -stable release that >>>> comprises >>>> > the following commits: >>>> > >>>> > c09fbcd31ae6 Linux 6.6.130 >>>> > [...] >>>> > dc7c9b9d03a5 ext4: drop extent cache when splitting extent fails >>>> > f0931a5c1700 ext4: drop extent cache after doing PARTIAL_VALID1 >>>> zeroout >>>> > 67cdb7bd7442 ext4: don't set EXT4_GET_BLOCKS_CONVERT when >>>> splitting before submitting I/O >>>> > 11406eb96a19 ext4: correct the comments place for >>>> EXT4_EXT_MAY_ZEROOUT >>>> >>>> Hello Bruce, >>>> >>>> > ed0096fc86b2 ext4: get rid of ppath in >>>> ext4_ext_handle_unwritten_extents() >>>> > d7b04ea31c6e ext4: get rid of ppath in >>>> ext4_ext_convert_to_initialized() >>>> > c24ce099bea9 ext4: get rid of ppath in >>>> ext4_convert_unwritten_extents_endio() >>>> > 147a6a2725b1 ext4: get rid of ppath in >>>> ext4_split_convert_extents() >>>> > cda8a34348d7 ext4: get rid of ppath in ext4_split_extent() >>>> > 58ddae5d77b1 ext4: don't zero the entire extent if >>>> EXT4_EXT_DATA_PARTIAL_VALID1 >>>> > e766534911b3 ext4: subdivide EXT4_EXT_DATA_VALID1 >>>> > ffb68fc57207 ext4: get rid of ppath in ext4_split_extent_at() >>>> > fb138df7d886 ext4: get rid of ppath in ext4_ext_insert_extent() >>>> > 8f6e910852d8 ext4: get rid of ppath in ext4_ext_create_new_leaf() >>>> > cafb151eb180 ext4: get rid of ppath in ext4_find_extent() >>>> >>>> (The following was found by Gemini, but I've checked it) >>>> >>>> Looks like these commits introduced a bug causing an intermittent LTP >>>> regression: >>>> https://autobuilder.yoctoproject.org/valkyrie/#/builders/98/builds/3837 >>>> -> >>>> https://valkyrie.yocto.io/pub/non-release/20260622-121/testresults/qemuarm64-ltp/core-image-sato/qemu_boot_log.20260623002740 >>>> >>>> [ 6952.500858] Unable to handle kernel paging request at virtual >>>> address ffffffffffffffec >>>> [ 6952.503768] Mem abort info: >>>> [ 6952.504431] ESR = 0x0000000096000005 >>>> [ 6952.505333] EC = 0x25: DABT (current EL), IL = 32 bits >>>> [ 6952.506541] SET = 0, FnV = 0 >>>> [ 6952.507354] EA = 0, S1PTW = 0 >>>> [ 6952.508154] FSC = 0x05: level 1 translation fault >>>> [ 6952.509208] Data abort info: >>>> [ 6952.509849] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 >>>> [ 6952.511175] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 >>>> [ 6952.512372] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 >>>> [ 6952.513667] swapper pgtable: 4k pages, 39-bit VAs, >>>> pgdp=0000000041250000 >>>> [ 6952.514909] [ffffffffffffffec] pgd=0000000000000000, >>>> p4d=0000000000000000, pud=0000000000000000 >>>> [ 6952.516423] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP >>>> [ 6952.517503] Modules linked in: x_tables tun loop [last unloaded: >>>> ip6_tables] >>>> [ 6952.518691] CPU: 1 PID: 1078 Comm: kworker/u12:1 Tainted: G >>>> W 6.6.142-yocto-standard #1 >>>> [ 6952.520269] Hardware name: linux,dummy-virt (DT) >>>> [ 6952.521094] Workqueue: writeback wb_workfn (flush-7:0) >>>> [ 6952.521985] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS >>>> BTYPE=--) >>>> [ 6952.523184] pc : ext4_ext_map_blocks+0x260/0x1860 >>>> [ 6952.524011] lr : ext4_ext_map_blocks+0xdb8/0x1860 >>>> [ 6952.524851] sp : ffffffc086a3b620 >>>> [ 6952.525421] x29: ffffffc086a3b740 x28: ffffffffffffffe4 x27: >>>> 000000000000808c >>>> [ 6952.526624] x26: ffffff8017dd9000 x25: 000000000000808c x24: >>>> 0000000000000002 >>>> [ 6952.527849] x23: ffffff8035e766c8 x22: ffffff802e589690 x21: >>>> 000000000000042f >>>> [ 6952.529087] x20: ffffffc086a3b948 x19: ffffff8035e767f0 x18: >>>> 0000000000000000 >>>> [ 6952.530310] x17: ffffffc081691310 x16: fffffffe001ab548 x15: >>>> 0000005564d4cb48 >>>> [ 6952.531519] x14: 00000000ffffffff x13: 0000000000000000 x12: >>>> ffffffffffffffc0 >>>> [ 6952.532683] x11: 0000000000000040 x10: ffffff8005d81d80 x9 : >>>> ffffffc0803cce14 >>>> [ 6952.533886] x8 : 00000000bab647bc x7 : 0000000000000000 x6 : >>>> 000000000000d847 >>>> [ 6952.535065] x5 : 0000000000000000 x4 : 0000000000316019 x3 : >>>> 0000000000000000 >>>> [ 6952.536264] x2 : 0000000000000000 x1 : 0000000000000000 x0 : >>>> ffffff803deec880 >>>> [ 6952.537425] Call trace: >>>> [ 6952.537860] ext4_ext_map_blocks+0x260/0x1860 >>>> [ 6952.538589] ext4_map_blocks+0x19c/0x598 >>>> [ 6952.539258] ext4_do_writepages+0x5a4/0xbe0 >>>> [ 6952.539977] ext4_writepages+0x84/0x110 >>>> [ 6952.540624] do_writepages+0x94/0x1e0 >>>> [ 6952.541240] __writeback_single_inode+0x60/0x4d8 >>>> [ 6952.542086] writeback_sb_inodes+0x208/0x4b0 >>>> [ 6952.542812] __writeback_inodes_wb+0x58/0x118 >>>> [ 6952.543578] wb_writeback+0x274/0x440 >>>> [ 6952.544198] wb_workfn+0x3b0/0x5c8 >>>> [ 6952.544788] process_one_work+0x16c/0x3e0 >>>> [ 6952.545434] worker_thread+0x1b4/0x378 >>>> [ 6952.546059] kthread+0x118/0x128 >>>> [ 6952.546599] ret_from_fork+0x10/0x20 >>>> [ 6952.547197] Code: 2a0103f9 b9009fe1 b9000e99 b40055fc (79401398) >>>> [ 6952.548170] ---[ end trace 0000000000000000 ]--- >>>> [ 6952.551090] ------------[ cut here ]------------ >>>> >>>> Reading the resulting code in 6.6.142: >>>> fs/ext4/extents.c: >>>> int ext4_ext_map_blocks(handle_t *handle, struct inode *inode, >>>> struct ext4_map_blocks *map, int flags) >>>> { >>>> struct ext4_ext_path *path = NULL; >>>> // ... >>>> >>>> got_allocated_blocks: >>>> path = ext4_ext_insert_extent(handle, inode, path, &newex, >>>> flags); >>>> if (IS_ERR(path)) { >>>> err = PTR_ERR(path); >>>> /* >>>> * Gracefully handle out of space conditions. If the >>>> filesystem >>>> * is inconsistent, we'll just leak allocated blocks to >>>> avoid >>>> * causing even more damage. >>>> */ >>>> // ... >>>> goto out; >>>> } >>>> >>>> // ... >>>> out: >>>> ext4_free_ext_path(path); >>>> >>>> trace_ext4_ext_map_blocks_exit(inode, flags, map, >>>> err ? err : allocated); >>>> return err ? err : allocated; >>>> } >>>> >>>> => Under out of space condition (what LTP does a *LOT*): path is given >>>> unmodified to >>>> ext4_free_ext_path() that only does a NULL check (no IS_ERR) before >>>> dereferencing it. And that produces the oops and then, the LTP failure. >>>> >>>> Notably, master commit 6b854d552711 ("ext4: get rid of ppath in >>>> get_ext_path()") >>>> never got backported to 6.6.y. But does add the IS_ERR_OR_NULL() check >>>> to ext4_free_ext_path: >>>> void ext4_free_ext_path(struct ext4_ext_path *path) >>>> { >>>> + if (IS_ERR_OR_NULL(path)) >>>> + return; >>>> >>>> Bruce, what do you think? Should we backport >>>> 6b854d552711·("ext4:·get·rid·of·ppath·in·get_ext_path()")? Ask for it to >>>> be backported? >>>> >>> >>> It's possible. But without being able to reproduce the issues locally, >>> I'm just >>> guessing. >>> >>> I wouldn't just backport it, I'd suggest that -stable pick it up as >>> well, but then >>> I'm back to not being able to see any issues locally. I wouldn't ask >>> for a >>> backport without knowing it does fix the issues. >>> >>> I'm happy to cherry-pick it as a shot in the dark, but that's all it >>> would be :) >>> >> >> I could setup AB to repeatedly test with/without the cherry-pick (only >> the fs section of ltp). I suspect the frequency of the bug triggering is >> quite high and that would prove the fix, enough to convince you and -stable? >> >> > Even enough runs with no failure is probably enough, given that you've > already been seeing it on the AB. That could be our "before" sample set. > > I can cherry-pick it and send SRCREV bump to the 6.6 recipes in the > scenario I'm suggesting that should be all you need. > Ok, let's do that. Thanks! > Bruce > > > >> >>> Bruce >>> >>> >>> >>>> >>>> Thanks for your help! >>>> -- >>>> Yoann Congal >>>> Smile ECS >>>> >>>> >>> >>> -- >>> - Thou shalt not follow the NULL pointer, for chaos and madness await >>> thee at its end >>> - "Use the force Harry" - Gandalf, Star Trek II >>> >>> > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await thee > at its end > - "Use the force Harry" - Gandalf, Star Trek II > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#239415): https://lists.openembedded.org/g/openembedded-core/message/239415 Mute This Topic: https://lists.openembedded.org/mt/119743065/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
