-
Notifications
You must be signed in to change notification settings - Fork 54.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Copyright #349
Closed
Closed
Update Copyright #349
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bgly
pushed a commit
to powervm/ibmvscsis
that referenced
this pull request
Nov 2, 2016
BugLink: http://bugs.launchpad.net/bugs/1614565 Currently we take care to handle I_DIRTY_TIME in vfs_fsync() and queue_io() so that inodes which have only dirty timestamps are properly written on fsync(2) and sync(2). However there are other call sites - most notably going through write_inode_now() - which expect inode to be clean after WB_SYNC_ALL writeback. This is not currently true as we do not clear I_DIRTY_TIME in __writeback_single_inode() even for WB_SYNC_ALL writeback in all the cases. This then resulted in the following oops because bdev_write_inode() did not clean the inode and writeback code later stumbled over a dirty inode with detached wb. general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN Modules linked in: CPU: 3 PID: 32 Comm: kworker/u10:1 Not tainted 4.6.0-rc3+ torvalds#349 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: writeback wb_workfn (flush-11:0) task: ffff88006ccf1840 ti: ffff88006cda8000 task.ti: ffff88006cda8000 RIP: 0010:[<ffffffff818884d2>] [<ffffffff818884d2>] locked_inode_to_wb_and_lock_list+0xa2/0x750 RSP: 0018:ffff88006cdaf7d0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88006ccf2050 RDX: 0000000000000000 RSI: 000000114c8a8484 RDI: 0000000000000286 RBP: ffff88006cdaf820 R08: ffff88006ccf1840 R09: 0000000000000000 R10: 000229915090805f R11: 0000000000000001 R12: ffff88006a72f5e0 R13: dffffc0000000000 R14: ffffed000d4e5eed R15: ffffffff8830cf40 FS: 0000000000000000(0000) GS:ffff88006d500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000003301bf8 CR3: 000000006368f000 CR4: 00000000000006e0 DR0: 0000000000001ec9 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 Stack: ffff88006a72f680 ffff88006a72f768 ffff8800671230d8 03ff88006cdaf948 ffff88006a72f668 ffff88006a72f5e0 ffff8800671230d8 ffff88006cdaf948 ffff880065b90cc8 ffff880067123100 ffff88006cdaf970 ffffffff8188e12e Call Trace: [< inline >] inode_to_wb_and_lock_list fs/fs-writeback.c:309 [<ffffffff8188e12e>] writeback_sb_inodes+0x4de/0x1250 fs/fs-writeback.c:1554 [<ffffffff8188efa4>] __writeback_inodes_wb+0x104/0x1e0 fs/fs-writeback.c:1600 [<ffffffff8188f9ae>] wb_writeback+0x7ce/0xc90 fs/fs-writeback.c:1709 [< inline >] wb_do_writeback fs/fs-writeback.c:1844 [<ffffffff81891079>] wb_workfn+0x2f9/0x1000 fs/fs-writeback.c:1884 [<ffffffff813bcd1e>] process_one_work+0x78e/0x15c0 kernel/workqueue.c:2094 [<ffffffff813bdc2b>] worker_thread+0xdb/0xfc0 kernel/workqueue.c:2228 [<ffffffff813cdeef>] kthread+0x23f/0x2d0 drivers/block/aoe/aoecmd.c:1303 [<ffffffff867bc5d2>] ret_from_fork+0x22/0x50 arch/x86/entry/entry_64.S:392 Code: 05 94 4a a8 06 85 c0 0f 85 03 03 00 00 e8 07 15 d0 ff 41 80 3e 00 0f 85 64 06 00 00 49 8b 9c 24 88 01 00 00 48 89 d8 48 c1 e8 03 <42> 80 3c 28 00 0f 85 17 06 00 00 48 8b 03 48 83 c0 50 48 39 c3 RIP [< inline >] wb_get include/linux/backing-dev-defs.h:212 RIP [<ffffffff818884d2>] locked_inode_to_wb_and_lock_list+0xa2/0x750 fs/fs-writeback.c:281 RSP <ffff88006cdaf7d0> ---[ end trace 986a4d314dcb2694 ]--- Fix the problem by making sure __writeback_single_inode() writes inode only with dirty times in WB_SYNC_ALL mode. Reported-by: Dmitry Vyukov <dvyukov@google.com> Tested-by: Laurent Dufour <ldufour@linux.vnet.ibm.com> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Jens Axboe <axboe@fb.com> (cherry picked from commit dc5ff2b) Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Christopher Arges <chris.j.arges@canonical.com> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Mic92
pushed a commit
to Mic92/linux
that referenced
this pull request
Feb 4, 2019
Since section ro_after_init contains writable data located inside .rodata section (which is read-only), resulting rodata section is writable. Since we don't have implementation of mark_rodata_ro() in our arch, those section keep writable forever. So this commit moves data.ro_after_init section from rodata to the end of sections so that rodata section will be read-only. Without this commit there is no issue, but valgrind somehow puzzled with malformed sections when ro_after_init section used, and results unresolved symbols after a valgrind run. This commit fixes torvalds#349. Fixes: d2ec3f7 ("pty: make ptmx file ops read-only after init") The commit uses (d07a980, s390: add proper __ro_after_init support) as a reference. Signed-off-by: Hajime Tazaki <thehajime@gmail.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 15, 2021
This commit fixes the following checkpatch.pl errors: ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#285: FILE: ./hal/odm.c:285: +void odm_CommonInfoSelfInit(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#287: FILE: ./hal/odm.c:287: +void odm_CommonInfoSelfUpdate(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#289: FILE: ./hal/odm.c:289: +void odm_CmnInfoInit_Debug(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#291: FILE: ./hal/odm.c:291: +void odm_BasicDbgMessage(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#305: FILE: ./hal/odm.c:305: +void odm_RefreshRateAdaptiveMaskCE(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#309: FILE: ./hal/odm.c:309: +void odm_RSSIMonitorInit(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#311: FILE: ./hal/odm.c:311: +void odm_RSSIMonitorCheckCE(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#313: FILE: ./hal/odm.c:313: +void odm_RSSIMonitorCheck(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#315: FILE: ./hal/odm.c:315: +void odm_SwAntDetectInit(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#323: FILE: ./hal/odm.c:323: +void odm_RefreshRateAdaptiveMask(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#325: FILE: ./hal/odm.c:325: +void ODM_TXPowerTrackingCheck(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#327: FILE: ./hal/odm.c:327: +void odm_RateAdaptiveMaskInit(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#330: FILE: ./hal/odm.c:330: +void odm_TXPowerTrackingInit(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#338: FILE: ./hal/odm.c:338: +void odm_InitHybridAntDiv(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#341: FILE: ./hal/odm.c:341: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#349: FILE: ./hal/odm.c:349: +void odm_SetRxIdleAnt(struct DM_ODM_T * pDM_Odm, u8 Ant, bool bDualPath); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#353: FILE: ./hal/odm.c:353: +void odm_HwAntDiv(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#363: FILE: ./hal/odm.c:363: +void ODM_DMInit(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#393: FILE: ./hal/odm.c:393: +void ODM_DMWatchdog(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#420: FILE: ./hal/odm.c:420: + struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#448: FILE: ./hal/odm.c:448: +void ODM_CmnInfoInit(struct DM_ODM_T * pDM_Odm, enum ODM_CMNINFO_E CmnInfo, u32 Value) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#560: FILE: ./hal/odm.c:560: +void ODM_CmnInfoHook(struct DM_ODM_T * pDM_Odm, enum ODM_CMNINFO_E CmnInfo, void *pValue) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#689: FILE: ./hal/odm.c:689: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#717: FILE: ./hal/odm.c:717: +void ODM_CmnInfoUpdate(struct DM_ODM_T * pDM_Odm, u32 CmnInfo, u64 Value) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#831: FILE: ./hal/odm.c:831: +void odm_CommonInfoSelfInit(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#841: FILE: ./hal/odm.c:841: +void odm_CommonInfoSelfUpdate(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#867: FILE: ./hal/odm.c:867: +void odm_CmnInfoInit_Debug(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#888: FILE: ./hal/odm.c:888: +void odm_BasicDbgMessage(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#935: FILE: ./hal/odm.c:935: +void odm_RateAdaptiveMaskInit(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#937: FILE: ./hal/odm.c:937: + struct ODM_RATE_ADAPTIVE * pOdmRA = &pDM_Odm->RateAdaptive; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#953: FILE: ./hal/odm.c:953: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1083: FILE: ./hal/odm.c:1083: +void odm_RefreshRateAdaptiveMask(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1094: FILE: ./hal/odm.c:1094: +void odm_RefreshRateAdaptiveMaskCE(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1131: FILE: ./hal/odm.c:1131: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1137: FILE: ./hal/odm.c:1137: + struct ODM_RATE_ADAPTIVE * pRA = &pDM_Odm->RateAdaptive; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1196: FILE: ./hal/odm.c:1196: +void odm_RSSIMonitorInit(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1198: FILE: ./hal/odm.c:1198: + struct RA_T * pRA_Table = &pDM_Odm->DM_RA_Table; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1204: FILE: ./hal/odm.c:1204: +void odm_RSSIMonitorCheck(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1217: FILE: ./hal/odm.c:1217: + struct DM_ODM_T * pDM_Odm = &(pHalData->odmpriv); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1234: FILE: ./hal/odm.c:1234: +void odm_RSSIMonitorCheckCE(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1243: FILE: ./hal/odm.c:1243: + struct RA_T * pRA_Table = &pDM_Odm->DM_RA_Table; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1306: FILE: ./hal/odm.c:1306: +static u8 getSwingIndex(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1330: FILE: ./hal/odm.c:1330: +void odm_TXPowerTrackingInit(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1374: FILE: ./hal/odm.c:1374: +void ODM_TXPowerTrackingCheck(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1398: FILE: ./hal/odm.c:1398: +void odm_SwAntDetectInit(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1400: FILE: ./hal/odm.c:1400: + struct SWAT_T * pDM_SWAT_Table = &pDM_Odm->DM_SWAT_Table; Signed-off-by: Marco Cesati <marcocesati@gmail.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 16, 2021
This commit fixes the following checkpatch.pl errors: ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#285: FILE: ./hal/odm.c:285: +void odm_CommonInfoSelfInit(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#287: FILE: ./hal/odm.c:287: +void odm_CommonInfoSelfUpdate(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#289: FILE: ./hal/odm.c:289: +void odm_CmnInfoInit_Debug(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#291: FILE: ./hal/odm.c:291: +void odm_BasicDbgMessage(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#305: FILE: ./hal/odm.c:305: +void odm_RefreshRateAdaptiveMaskCE(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#309: FILE: ./hal/odm.c:309: +void odm_RSSIMonitorInit(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#311: FILE: ./hal/odm.c:311: +void odm_RSSIMonitorCheckCE(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#313: FILE: ./hal/odm.c:313: +void odm_RSSIMonitorCheck(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#315: FILE: ./hal/odm.c:315: +void odm_SwAntDetectInit(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#323: FILE: ./hal/odm.c:323: +void odm_RefreshRateAdaptiveMask(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#325: FILE: ./hal/odm.c:325: +void ODM_TXPowerTrackingCheck(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#327: FILE: ./hal/odm.c:327: +void odm_RateAdaptiveMaskInit(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#330: FILE: ./hal/odm.c:330: +void odm_TXPowerTrackingInit(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#338: FILE: ./hal/odm.c:338: +void odm_InitHybridAntDiv(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#341: FILE: ./hal/odm.c:341: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#349: FILE: ./hal/odm.c:349: +void odm_SetRxIdleAnt(struct DM_ODM_T * pDM_Odm, u8 Ant, bool bDualPath); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#353: FILE: ./hal/odm.c:353: +void odm_HwAntDiv(struct DM_ODM_T * pDM_Odm); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#363: FILE: ./hal/odm.c:363: +void ODM_DMInit(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#393: FILE: ./hal/odm.c:393: +void ODM_DMWatchdog(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#420: FILE: ./hal/odm.c:420: + struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#448: FILE: ./hal/odm.c:448: +void ODM_CmnInfoInit(struct DM_ODM_T * pDM_Odm, enum ODM_CMNINFO_E CmnInfo, u32 Value) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#560: FILE: ./hal/odm.c:560: +void ODM_CmnInfoHook(struct DM_ODM_T * pDM_Odm, enum ODM_CMNINFO_E CmnInfo, void *pValue) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#689: FILE: ./hal/odm.c:689: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#717: FILE: ./hal/odm.c:717: +void ODM_CmnInfoUpdate(struct DM_ODM_T * pDM_Odm, u32 CmnInfo, u64 Value) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#831: FILE: ./hal/odm.c:831: +void odm_CommonInfoSelfInit(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#841: FILE: ./hal/odm.c:841: +void odm_CommonInfoSelfUpdate(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#867: FILE: ./hal/odm.c:867: +void odm_CmnInfoInit_Debug(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#888: FILE: ./hal/odm.c:888: +void odm_BasicDbgMessage(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#935: FILE: ./hal/odm.c:935: +void odm_RateAdaptiveMaskInit(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#937: FILE: ./hal/odm.c:937: + struct ODM_RATE_ADAPTIVE * pOdmRA = &pDM_Odm->RateAdaptive; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#953: FILE: ./hal/odm.c:953: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1083: FILE: ./hal/odm.c:1083: +void odm_RefreshRateAdaptiveMask(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1094: FILE: ./hal/odm.c:1094: +void odm_RefreshRateAdaptiveMaskCE(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1131: FILE: ./hal/odm.c:1131: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1137: FILE: ./hal/odm.c:1137: + struct ODM_RATE_ADAPTIVE * pRA = &pDM_Odm->RateAdaptive; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1196: FILE: ./hal/odm.c:1196: +void odm_RSSIMonitorInit(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1198: FILE: ./hal/odm.c:1198: + struct RA_T * pRA_Table = &pDM_Odm->DM_RA_Table; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1204: FILE: ./hal/odm.c:1204: +void odm_RSSIMonitorCheck(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1217: FILE: ./hal/odm.c:1217: + struct DM_ODM_T * pDM_Odm = &(pHalData->odmpriv); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1234: FILE: ./hal/odm.c:1234: +void odm_RSSIMonitorCheckCE(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1243: FILE: ./hal/odm.c:1243: + struct RA_T * pRA_Table = &pDM_Odm->DM_RA_Table; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1306: FILE: ./hal/odm.c:1306: +static u8 getSwingIndex(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1330: FILE: ./hal/odm.c:1330: +void odm_TXPowerTrackingInit(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1374: FILE: ./hal/odm.c:1374: +void ODM_TXPowerTrackingCheck(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1398: FILE: ./hal/odm.c:1398: +void odm_SwAntDetectInit(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1400: FILE: ./hal/odm.c:1400: + struct SWAT_T * pDM_SWAT_Table = &pDM_Odm->DM_SWAT_Table; Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Marco Cesati <marcocesati@gmail.com> Link: https://lore.kernel.org/r/20210315170618.2566-21-marcocesati@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Oct 20, 2022
We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, it is marked as bad_inode in ext4_iget because imode is abnormal. After initialization, imode is set to S_IFREG. In this case, the ext4_ext_check_inode function is used for check, and no issue is triggered. Therefore, we can determine whether an inode needs to be initialized by checking whether the boot loader inode is a bad inode instead of i_nlink. Signed-off-by: Baokun Li <libaokun1@huawei.com>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Oct 21, 2022
We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Oct 26, 2022
We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Dec 7, 2022
We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org
ptr1337
pushed a commit
to CachyOS/linux
that referenced
this pull request
Dec 12, 2022
We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org
torvalds
pushed a commit
that referenced
this pull request
Dec 13, 2022
We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty #349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org
dakkshesh07
pushed a commit
to Neutron-Projects/kernel-dejavu
that referenced
this pull request
Dec 30, 2022
We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Dakkshesh <dakkshesh5@gmail.com>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 4, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 4, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 4, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 4, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 4, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 4, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 4, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 4, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 4, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 4, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 4, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 4, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 4, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 4, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 4, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 4, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 4, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 17, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 17, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 17, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 17, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 17, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 17, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 17, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 17, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 17, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 17, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 17, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
kikei
pushed a commit
to kikei/linux
that referenced
this pull request
Jan 17, 2023
Currently we take care to handle I_DIRTY_TIME in vfs_fsync() and queue_io() so that inodes which have only dirty timestamps are properly written on fsync(2) and sync(2). However there are other call sites - most notably going through write_inode_now() - which expect inode to be clean after WB_SYNC_ALL writeback. This is not currently true as we do not clear I_DIRTY_TIME in __writeback_single_inode() even for WB_SYNC_ALL writeback in all the cases. This then resulted in the following oops because bdev_write_inode() did not clean the inode and writeback code later stumbled over a dirty inode with detached wb. general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN Modules linked in: CPU: 3 PID: 32 Comm: kworker/u10:1 Not tainted 4.6.0-rc3+ torvalds#349 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: writeback wb_workfn (flush-11:0) task: ffff88006ccf1840 ti: ffff88006cda8000 task.ti: ffff88006cda8000 RIP: 0010:[<ffffffff818884d2>] [<ffffffff818884d2>] locked_inode_to_wb_and_lock_list+0xa2/0x750 RSP: 0018:ffff88006cdaf7d0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88006ccf2050 RDX: 0000000000000000 RSI: 000000114c8a8484 RDI: 0000000000000286 RBP: ffff88006cdaf820 R08: ffff88006ccf1840 R09: 0000000000000000 R10: 000229915090805f R11: 0000000000000001 R12: ffff88006a72f5e0 R13: dffffc0000000000 R14: ffffed000d4e5eed R15: ffffffff8830cf40 FS: 0000000000000000(0000) GS:ffff88006d500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000003301bf8 CR3: 000000006368f000 CR4: 00000000000006e0 DR0: 0000000000001ec9 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 Stack: ffff88006a72f680 ffff88006a72f768 ffff8800671230d8 03ff88006cdaf948 ffff88006a72f668 ffff88006a72f5e0 ffff8800671230d8 ffff88006cdaf948 ffff880065b90cc8 ffff880067123100 ffff88006cdaf970 ffffffff8188e12e Call Trace: [< inline >] inode_to_wb_and_lock_list fs/fs-writeback.c:309 [<ffffffff8188e12e>] writeback_sb_inodes+0x4de/0x1250 fs/fs-writeback.c:1554 [<ffffffff8188efa4>] __writeback_inodes_wb+0x104/0x1e0 fs/fs-writeback.c:1600 [<ffffffff8188f9ae>] wb_writeback+0x7ce/0xc90 fs/fs-writeback.c:1709 [< inline >] wb_do_writeback fs/fs-writeback.c:1844 [<ffffffff81891079>] wb_workfn+0x2f9/0x1000 fs/fs-writeback.c:1884 [<ffffffff813bcd1e>] process_one_work+0x78e/0x15c0 kernel/workqueue.c:2094 [<ffffffff813bdc2b>] worker_thread+0xdb/0xfc0 kernel/workqueue.c:2228 [<ffffffff813cdeef>] kthread+0x23f/0x2d0 drivers/block/aoe/aoecmd.c:1303 [<ffffffff867bc5d2>] ret_from_fork+0x22/0x50 arch/x86/entry/entry_64.S:392 Code: 05 94 4a a8 06 85 c0 0f 85 03 03 00 00 e8 07 15 d0 ff 41 80 3e 00 0f 85 64 06 00 00 49 8b 9c 24 88 01 00 00 48 89 d8 48 c1 e8 03 <42> 80 3c 28 00 0f 85 17 06 00 00 48 8b 03 48 83 c0 50 48 39 c3 RIP [< inline >] wb_get include/linux/backing-dev-defs.h:212 RIP [<ffffffff818884d2>] locked_inode_to_wb_and_lock_list+0xa2/0x750 fs/fs-writeback.c:281 RSP <ffff88006cdaf7d0> ---[ end trace 986a4d314dcb2694 ]--- Fix the problem by making sure __writeback_single_inode() writes inode only with dirty times in WB_SYNC_ALL mode. Reported-by: Dmitry Vyukov <dvyukov@google.com> Tested-by: Laurent Dufour <ldufour@linux.vnet.ibm.com> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Jens Axboe <axboe@fb.com>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 18, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 18, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 18, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 18, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 18, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 18, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ThatsItForTheOtherOne
pushed a commit
to Wii-Linux/wii-linux-ngx
that referenced
this pull request
Oct 16, 2023
commit 991ed01 upstream. We got a issue as fllows: ================================================================== kernel BUG at fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty torvalds#349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000 FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ================================================================== In the above issue, ioctl invokes the swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2) the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not S_IFREG, initialize the inode to avoid triggering the BUG. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ulrich Hecht <uli+cip@fpond.eu>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Oct 27, 2023
Enable cpu v4 tests for LoongArch. Currently, we don't have BPF trampoline in LoongArch JIT, so the fentry test `test_ptr_struct_arg` still failed, will followup. Test result attached below: # ./test_progs -t verifier_sdiv,verifier_movsx,verifier_ldsx,verifier_gotol,verifier_bswap torvalds#316/1 verifier_bswap/BSWAP, 16:OK torvalds#316/2 verifier_bswap/BSWAP, 16 @unpriv:OK torvalds#316/3 verifier_bswap/BSWAP, 32:OK torvalds#316/4 verifier_bswap/BSWAP, 32 @unpriv:OK torvalds#316/5 verifier_bswap/BSWAP, 64:OK torvalds#316/6 verifier_bswap/BSWAP, 64 @unpriv:OK torvalds#316 verifier_bswap:OK torvalds#330/1 verifier_gotol/gotol, small_imm:OK torvalds#330/2 verifier_gotol/gotol, small_imm @unpriv:OK torvalds#330 verifier_gotol:OK torvalds#338/1 verifier_ldsx/LDSX, S8:OK torvalds#338/2 verifier_ldsx/LDSX, S8 @unpriv:OK torvalds#338/3 verifier_ldsx/LDSX, S16:OK torvalds#338/4 verifier_ldsx/LDSX, S16 @unpriv:OK torvalds#338/5 verifier_ldsx/LDSX, S32:OK torvalds#338/6 verifier_ldsx/LDSX, S32 @unpriv:OK torvalds#338/7 verifier_ldsx/LDSX, S8 range checking, privileged:OK torvalds#338/8 verifier_ldsx/LDSX, S16 range checking:OK torvalds#338/9 verifier_ldsx/LDSX, S16 range checking @unpriv:OK torvalds#338/10 verifier_ldsx/LDSX, S32 range checking:OK torvalds#338/11 verifier_ldsx/LDSX, S32 range checking @unpriv:OK torvalds#338 verifier_ldsx:OK torvalds#349/1 verifier_movsx/MOV32SX, S8:OK torvalds#349/2 verifier_movsx/MOV32SX, S8 @unpriv:OK torvalds#349/3 verifier_movsx/MOV32SX, S16:OK torvalds#349/4 verifier_movsx/MOV32SX, S16 @unpriv:OK torvalds#349/5 verifier_movsx/MOV64SX, S8:OK torvalds#349/6 verifier_movsx/MOV64SX, S8 @unpriv:OK torvalds#349/7 verifier_movsx/MOV64SX, S16:OK torvalds#349/8 verifier_movsx/MOV64SX, S16 @unpriv:OK torvalds#349/9 verifier_movsx/MOV64SX, S32:OK torvalds#349/10 verifier_movsx/MOV64SX, S32 @unpriv:OK torvalds#349/11 verifier_movsx/MOV32SX, S8, range_check:OK torvalds#349/12 verifier_movsx/MOV32SX, S8, range_check @unpriv:OK torvalds#349/13 verifier_movsx/MOV32SX, S16, range_check:OK torvalds#349/14 verifier_movsx/MOV32SX, S16, range_check @unpriv:OK torvalds#349/15 verifier_movsx/MOV32SX, S16, range_check 2:OK torvalds#349/16 verifier_movsx/MOV32SX, S16, range_check 2 @unpriv:OK torvalds#349/17 verifier_movsx/MOV64SX, S8, range_check:OK torvalds#349/18 verifier_movsx/MOV64SX, S8, range_check @unpriv:OK torvalds#349/19 verifier_movsx/MOV64SX, S16, range_check:OK torvalds#349/20 verifier_movsx/MOV64SX, S16, range_check @unpriv:OK torvalds#349/21 verifier_movsx/MOV64SX, S32, range_check:OK torvalds#349/22 verifier_movsx/MOV64SX, S32, range_check @unpriv:OK torvalds#349/23 verifier_movsx/MOV64SX, S16, R10 Sign Extension:OK torvalds#349/24 verifier_movsx/MOV64SX, S16, R10 Sign Extension @unpriv:OK torvalds#349 verifier_movsx:OK torvalds#361/1 verifier_sdiv/SDIV32, non-zero imm divisor, check 1:OK torvalds#361/2 verifier_sdiv/SDIV32, non-zero imm divisor, check 1 @unpriv:OK torvalds#361/3 verifier_sdiv/SDIV32, non-zero imm divisor, check 2:OK torvalds#361/4 verifier_sdiv/SDIV32, non-zero imm divisor, check 2 @unpriv:OK torvalds#361/5 verifier_sdiv/SDIV32, non-zero imm divisor, check 3:OK torvalds#361/6 verifier_sdiv/SDIV32, non-zero imm divisor, check 3 @unpriv:OK torvalds#361/7 verifier_sdiv/SDIV32, non-zero imm divisor, check 4:OK torvalds#361/8 verifier_sdiv/SDIV32, non-zero imm divisor, check 4 @unpriv:OK torvalds#361/9 verifier_sdiv/SDIV32, non-zero imm divisor, check 5:OK torvalds#361/10 verifier_sdiv/SDIV32, non-zero imm divisor, check 5 @unpriv:OK torvalds#361/11 verifier_sdiv/SDIV32, non-zero imm divisor, check 6:OK torvalds#361/12 verifier_sdiv/SDIV32, non-zero imm divisor, check 6 @unpriv:OK torvalds#361/13 verifier_sdiv/SDIV32, non-zero imm divisor, check 7:OK torvalds#361/14 verifier_sdiv/SDIV32, non-zero imm divisor, check 7 @unpriv:OK torvalds#361/15 verifier_sdiv/SDIV32, non-zero imm divisor, check 8:OK torvalds#361/16 verifier_sdiv/SDIV32, non-zero imm divisor, check 8 @unpriv:OK torvalds#361/17 verifier_sdiv/SDIV32, non-zero reg divisor, check 1:OK torvalds#361/18 verifier_sdiv/SDIV32, non-zero reg divisor, check 1 @unpriv:OK torvalds#361/19 verifier_sdiv/SDIV32, non-zero reg divisor, check 2:OK torvalds#361/20 verifier_sdiv/SDIV32, non-zero reg divisor, check 2 @unpriv:OK torvalds#361/21 verifier_sdiv/SDIV32, non-zero reg divisor, check 3:OK torvalds#361/22 verifier_sdiv/SDIV32, non-zero reg divisor, check 3 @unpriv:OK torvalds#361/23 verifier_sdiv/SDIV32, non-zero reg divisor, check 4:OK torvalds#361/24 verifier_sdiv/SDIV32, non-zero reg divisor, check 4 @unpriv:OK torvalds#361/25 verifier_sdiv/SDIV32, non-zero reg divisor, check 5:OK torvalds#361/26 verifier_sdiv/SDIV32, non-zero reg divisor, check 5 @unpriv:OK torvalds#361/27 verifier_sdiv/SDIV32, non-zero reg divisor, check 6:OK torvalds#361/28 verifier_sdiv/SDIV32, non-zero reg divisor, check 6 @unpriv:OK torvalds#361/29 verifier_sdiv/SDIV32, non-zero reg divisor, check 7:OK torvalds#361/30 verifier_sdiv/SDIV32, non-zero reg divisor, check 7 @unpriv:OK torvalds#361/31 verifier_sdiv/SDIV32, non-zero reg divisor, check 8:OK torvalds#361/32 verifier_sdiv/SDIV32, non-zero reg divisor, check 8 @unpriv:OK torvalds#361/33 verifier_sdiv/SDIV64, non-zero imm divisor, check 1:OK torvalds#361/34 verifier_sdiv/SDIV64, non-zero imm divisor, check 1 @unpriv:OK torvalds#361/35 verifier_sdiv/SDIV64, non-zero imm divisor, check 2:OK torvalds#361/36 verifier_sdiv/SDIV64, non-zero imm divisor, check 2 @unpriv:OK torvalds#361/37 verifier_sdiv/SDIV64, non-zero imm divisor, check 3:OK torvalds#361/38 verifier_sdiv/SDIV64, non-zero imm divisor, check 3 @unpriv:OK torvalds#361/39 verifier_sdiv/SDIV64, non-zero imm divisor, check 4:OK torvalds#361/40 verifier_sdiv/SDIV64, non-zero imm divisor, check 4 @unpriv:OK torvalds#361/41 verifier_sdiv/SDIV64, non-zero imm divisor, check 5:OK torvalds#361/42 verifier_sdiv/SDIV64, non-zero imm divisor, check 5 @unpriv:OK torvalds#361/43 verifier_sdiv/SDIV64, non-zero imm divisor, check 6:OK torvalds#361/44 verifier_sdiv/SDIV64, non-zero imm divisor, check 6 @unpriv:OK torvalds#361/45 verifier_sdiv/SDIV64, non-zero reg divisor, check 1:OK torvalds#361/46 verifier_sdiv/SDIV64, non-zero reg divisor, check 1 @unpriv:OK torvalds#361/47 verifier_sdiv/SDIV64, non-zero reg divisor, check 2:OK torvalds#361/48 verifier_sdiv/SDIV64, non-zero reg divisor, check 2 @unpriv:OK torvalds#361/49 verifier_sdiv/SDIV64, non-zero reg divisor, check 3:OK torvalds#361/50 verifier_sdiv/SDIV64, non-zero reg divisor, check 3 @unpriv:OK torvalds#361/51 verifier_sdiv/SDIV64, non-zero reg divisor, check 4:OK torvalds#361/52 verifier_sdiv/SDIV64, non-zero reg divisor, check 4 @unpriv:OK torvalds#361/53 verifier_sdiv/SDIV64, non-zero reg divisor, check 5:OK torvalds#361/54 verifier_sdiv/SDIV64, non-zero reg divisor, check 5 @unpriv:OK torvalds#361/55 verifier_sdiv/SDIV64, non-zero reg divisor, check 6:OK torvalds#361/56 verifier_sdiv/SDIV64, non-zero reg divisor, check 6 @unpriv:OK torvalds#361/57 verifier_sdiv/SMOD32, non-zero imm divisor, check 1:OK torvalds#361/58 verifier_sdiv/SMOD32, non-zero imm divisor, check 1 @unpriv:OK torvalds#361/59 verifier_sdiv/SMOD32, non-zero imm divisor, check 2:OK torvalds#361/60 verifier_sdiv/SMOD32, non-zero imm divisor, check 2 @unpriv:OK torvalds#361/61 verifier_sdiv/SMOD32, non-zero imm divisor, check 3:OK torvalds#361/62 verifier_sdiv/SMOD32, non-zero imm divisor, check 3 @unpriv:OK torvalds#361/63 verifier_sdiv/SMOD32, non-zero imm divisor, check 4:OK torvalds#361/64 verifier_sdiv/SMOD32, non-zero imm divisor, check 4 @unpriv:OK torvalds#361/65 verifier_sdiv/SMOD32, non-zero imm divisor, check 5:OK torvalds#361/66 verifier_sdiv/SMOD32, non-zero imm divisor, check 5 @unpriv:OK torvalds#361/67 verifier_sdiv/SMOD32, non-zero imm divisor, check 6:OK torvalds#361/68 verifier_sdiv/SMOD32, non-zero imm divisor, check 6 @unpriv:OK torvalds#361/69 verifier_sdiv/SMOD32, non-zero reg divisor, check 1:OK torvalds#361/70 verifier_sdiv/SMOD32, non-zero reg divisor, check 1 @unpriv:OK torvalds#361/71 verifier_sdiv/SMOD32, non-zero reg divisor, check 2:OK torvalds#361/72 verifier_sdiv/SMOD32, non-zero reg divisor, check 2 @unpriv:OK torvalds#361/73 verifier_sdiv/SMOD32, non-zero reg divisor, check 3:OK torvalds#361/74 verifier_sdiv/SMOD32, non-zero reg divisor, check 3 @unpriv:OK torvalds#361/75 verifier_sdiv/SMOD32, non-zero reg divisor, check 4:OK torvalds#361/76 verifier_sdiv/SMOD32, non-zero reg divisor, check 4 @unpriv:OK torvalds#361/77 verifier_sdiv/SMOD32, non-zero reg divisor, check 5:OK torvalds#361/78 verifier_sdiv/SMOD32, non-zero reg divisor, check 5 @unpriv:OK torvalds#361/79 verifier_sdiv/SMOD32, non-zero reg divisor, check 6:OK torvalds#361/80 verifier_sdiv/SMOD32, non-zero reg divisor, check 6 @unpriv:OK torvalds#361/81 verifier_sdiv/SMOD64, non-zero imm divisor, check 1:OK torvalds#361/82 verifier_sdiv/SMOD64, non-zero imm divisor, check 1 @unpriv:OK torvalds#361/83 verifier_sdiv/SMOD64, non-zero imm divisor, check 2:OK torvalds#361/84 verifier_sdiv/SMOD64, non-zero imm divisor, check 2 @unpriv:OK torvalds#361/85 verifier_sdiv/SMOD64, non-zero imm divisor, check 3:OK torvalds#361/86 verifier_sdiv/SMOD64, non-zero imm divisor, check 3 @unpriv:OK torvalds#361/87 verifier_sdiv/SMOD64, non-zero imm divisor, check 4:OK torvalds#361/88 verifier_sdiv/SMOD64, non-zero imm divisor, check 4 @unpriv:OK torvalds#361/89 verifier_sdiv/SMOD64, non-zero imm divisor, check 5:OK torvalds#361/90 verifier_sdiv/SMOD64, non-zero imm divisor, check 5 @unpriv:OK torvalds#361/91 verifier_sdiv/SMOD64, non-zero imm divisor, check 6:OK torvalds#361/92 verifier_sdiv/SMOD64, non-zero imm divisor, check 6 @unpriv:OK torvalds#361/93 verifier_sdiv/SMOD64, non-zero imm divisor, check 7:OK torvalds#361/94 verifier_sdiv/SMOD64, non-zero imm divisor, check 7 @unpriv:OK torvalds#361/95 verifier_sdiv/SMOD64, non-zero imm divisor, check 8:OK torvalds#361/96 verifier_sdiv/SMOD64, non-zero imm divisor, check 8 @unpriv:OK torvalds#361/97 verifier_sdiv/SMOD64, non-zero reg divisor, check 1:OK torvalds#361/98 verifier_sdiv/SMOD64, non-zero reg divisor, check 1 @unpriv:OK torvalds#361/99 verifier_sdiv/SMOD64, non-zero reg divisor, check 2:OK torvalds#361/100 verifier_sdiv/SMOD64, non-zero reg divisor, check 2 @unpriv:OK torvalds#361/101 verifier_sdiv/SMOD64, non-zero reg divisor, check 3:OK torvalds#361/102 verifier_sdiv/SMOD64, non-zero reg divisor, check 3 @unpriv:OK torvalds#361/103 verifier_sdiv/SMOD64, non-zero reg divisor, check 4:OK torvalds#361/104 verifier_sdiv/SMOD64, non-zero reg divisor, check 4 @unpriv:OK torvalds#361/105 verifier_sdiv/SMOD64, non-zero reg divisor, check 5:OK torvalds#361/106 verifier_sdiv/SMOD64, non-zero reg divisor, check 5 @unpriv:OK torvalds#361/107 verifier_sdiv/SMOD64, non-zero reg divisor, check 6:OK torvalds#361/108 verifier_sdiv/SMOD64, non-zero reg divisor, check 6 @unpriv:OK torvalds#361/109 verifier_sdiv/SMOD64, non-zero reg divisor, check 7:OK torvalds#361/110 verifier_sdiv/SMOD64, non-zero reg divisor, check 7 @unpriv:OK torvalds#361/111 verifier_sdiv/SMOD64, non-zero reg divisor, check 8:OK torvalds#361/112 verifier_sdiv/SMOD64, non-zero reg divisor, check 8 @unpriv:OK torvalds#361/113 verifier_sdiv/SDIV32, zero divisor:OK torvalds#361/114 verifier_sdiv/SDIV32, zero divisor @unpriv:OK torvalds#361/115 verifier_sdiv/SDIV64, zero divisor:OK torvalds#361/116 verifier_sdiv/SDIV64, zero divisor @unpriv:OK torvalds#361/117 verifier_sdiv/SMOD32, zero divisor:OK torvalds#361/118 verifier_sdiv/SMOD32, zero divisor @unpriv:OK torvalds#361/119 verifier_sdiv/SMOD64, zero divisor:OK torvalds#361/120 verifier_sdiv/SMOD64, zero divisor @unpriv:OK torvalds#361 verifier_sdiv:OK Summary: 5/163 PASSED, 0 SKIPPED, 0 FAILED # ./test_progs -t ldsx_insn test_map_val_and_probed_memory:PASS:test_ldsx_insn__open 0 nsec test_map_val_and_probed_memory:PASS:test_ldsx_insn__load 0 nsec libbpf: prog 'test_ptr_struct_arg': failed to attach: ERROR: strerror_r(-524)=22 libbpf: prog 'test_ptr_struct_arg': failed to auto-attach: -524 test_map_val_and_probed_memory:FAIL:test_ldsx_insn__attach unexpected error: -524 (errno 524) torvalds#116/1 ldsx_insn/map_val and probed_memory:FAIL torvalds#116/2 ldsx_insn/ctx_member_sign_ext:OK torvalds#116/3 ldsx_insn/ctx_member_narrow_sign_ext:OK torvalds#116 ldsx_insn:FAIL All error logs: test_map_val_and_probed_memory:PASS:test_ldsx_insn__open 0 nsec test_map_val_and_probed_memory:PASS:test_ldsx_insn__load 0 nsec libbpf: prog 'test_ptr_struct_arg': failed to attach: ERROR: strerror_r(-524)=22 libbpf: prog 'test_ptr_struct_arg': failed to auto-attach: -524 test_map_val_and_probed_memory:FAIL:test_ldsx_insn__attach unexpected error: -524 (errno 524) torvalds#116/1 ldsx_insn/map_val and probed_memory:FAIL torvalds#116 ldsx_insn:FAIL Summary: 0/2 PASSED, 0 SKIPPED, 1 FAILED Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Nov 9, 2023
Enable the cpu v4 tests for LoongArch. Currently, we don't have BPF trampoline in LoongArch JIT, so the fentry test `test_ptr_struct_arg` still failed, will followup. Test result attached below: # ./test_progs -t verifier_sdiv,verifier_movsx,verifier_ldsx,verifier_gotol,verifier_bswap torvalds#316/1 verifier_bswap/BSWAP, 16:OK torvalds#316/2 verifier_bswap/BSWAP, 16 @unpriv:OK torvalds#316/3 verifier_bswap/BSWAP, 32:OK torvalds#316/4 verifier_bswap/BSWAP, 32 @unpriv:OK torvalds#316/5 verifier_bswap/BSWAP, 64:OK torvalds#316/6 verifier_bswap/BSWAP, 64 @unpriv:OK torvalds#316 verifier_bswap:OK torvalds#330/1 verifier_gotol/gotol, small_imm:OK torvalds#330/2 verifier_gotol/gotol, small_imm @unpriv:OK torvalds#330 verifier_gotol:OK torvalds#338/1 verifier_ldsx/LDSX, S8:OK torvalds#338/2 verifier_ldsx/LDSX, S8 @unpriv:OK torvalds#338/3 verifier_ldsx/LDSX, S16:OK torvalds#338/4 verifier_ldsx/LDSX, S16 @unpriv:OK torvalds#338/5 verifier_ldsx/LDSX, S32:OK torvalds#338/6 verifier_ldsx/LDSX, S32 @unpriv:OK torvalds#338/7 verifier_ldsx/LDSX, S8 range checking, privileged:OK torvalds#338/8 verifier_ldsx/LDSX, S16 range checking:OK torvalds#338/9 verifier_ldsx/LDSX, S16 range checking @unpriv:OK torvalds#338/10 verifier_ldsx/LDSX, S32 range checking:OK torvalds#338/11 verifier_ldsx/LDSX, S32 range checking @unpriv:OK torvalds#338 verifier_ldsx:OK torvalds#349/1 verifier_movsx/MOV32SX, S8:OK torvalds#349/2 verifier_movsx/MOV32SX, S8 @unpriv:OK torvalds#349/3 verifier_movsx/MOV32SX, S16:OK torvalds#349/4 verifier_movsx/MOV32SX, S16 @unpriv:OK torvalds#349/5 verifier_movsx/MOV64SX, S8:OK torvalds#349/6 verifier_movsx/MOV64SX, S8 @unpriv:OK torvalds#349/7 verifier_movsx/MOV64SX, S16:OK torvalds#349/8 verifier_movsx/MOV64SX, S16 @unpriv:OK torvalds#349/9 verifier_movsx/MOV64SX, S32:OK torvalds#349/10 verifier_movsx/MOV64SX, S32 @unpriv:OK torvalds#349/11 verifier_movsx/MOV32SX, S8, range_check:OK torvalds#349/12 verifier_movsx/MOV32SX, S8, range_check @unpriv:OK torvalds#349/13 verifier_movsx/MOV32SX, S16, range_check:OK torvalds#349/14 verifier_movsx/MOV32SX, S16, range_check @unpriv:OK torvalds#349/15 verifier_movsx/MOV32SX, S16, range_check 2:OK torvalds#349/16 verifier_movsx/MOV32SX, S16, range_check 2 @unpriv:OK torvalds#349/17 verifier_movsx/MOV64SX, S8, range_check:OK torvalds#349/18 verifier_movsx/MOV64SX, S8, range_check @unpriv:OK torvalds#349/19 verifier_movsx/MOV64SX, S16, range_check:OK torvalds#349/20 verifier_movsx/MOV64SX, S16, range_check @unpriv:OK torvalds#349/21 verifier_movsx/MOV64SX, S32, range_check:OK torvalds#349/22 verifier_movsx/MOV64SX, S32, range_check @unpriv:OK torvalds#349/23 verifier_movsx/MOV64SX, S16, R10 Sign Extension:OK torvalds#349/24 verifier_movsx/MOV64SX, S16, R10 Sign Extension @unpriv:OK torvalds#349 verifier_movsx:OK torvalds#361/1 verifier_sdiv/SDIV32, non-zero imm divisor, check 1:OK torvalds#361/2 verifier_sdiv/SDIV32, non-zero imm divisor, check 1 @unpriv:OK torvalds#361/3 verifier_sdiv/SDIV32, non-zero imm divisor, check 2:OK torvalds#361/4 verifier_sdiv/SDIV32, non-zero imm divisor, check 2 @unpriv:OK torvalds#361/5 verifier_sdiv/SDIV32, non-zero imm divisor, check 3:OK torvalds#361/6 verifier_sdiv/SDIV32, non-zero imm divisor, check 3 @unpriv:OK torvalds#361/7 verifier_sdiv/SDIV32, non-zero imm divisor, check 4:OK torvalds#361/8 verifier_sdiv/SDIV32, non-zero imm divisor, check 4 @unpriv:OK torvalds#361/9 verifier_sdiv/SDIV32, non-zero imm divisor, check 5:OK torvalds#361/10 verifier_sdiv/SDIV32, non-zero imm divisor, check 5 @unpriv:OK torvalds#361/11 verifier_sdiv/SDIV32, non-zero imm divisor, check 6:OK torvalds#361/12 verifier_sdiv/SDIV32, non-zero imm divisor, check 6 @unpriv:OK torvalds#361/13 verifier_sdiv/SDIV32, non-zero imm divisor, check 7:OK torvalds#361/14 verifier_sdiv/SDIV32, non-zero imm divisor, check 7 @unpriv:OK torvalds#361/15 verifier_sdiv/SDIV32, non-zero imm divisor, check 8:OK torvalds#361/16 verifier_sdiv/SDIV32, non-zero imm divisor, check 8 @unpriv:OK torvalds#361/17 verifier_sdiv/SDIV32, non-zero reg divisor, check 1:OK torvalds#361/18 verifier_sdiv/SDIV32, non-zero reg divisor, check 1 @unpriv:OK torvalds#361/19 verifier_sdiv/SDIV32, non-zero reg divisor, check 2:OK torvalds#361/20 verifier_sdiv/SDIV32, non-zero reg divisor, check 2 @unpriv:OK torvalds#361/21 verifier_sdiv/SDIV32, non-zero reg divisor, check 3:OK torvalds#361/22 verifier_sdiv/SDIV32, non-zero reg divisor, check 3 @unpriv:OK torvalds#361/23 verifier_sdiv/SDIV32, non-zero reg divisor, check 4:OK torvalds#361/24 verifier_sdiv/SDIV32, non-zero reg divisor, check 4 @unpriv:OK torvalds#361/25 verifier_sdiv/SDIV32, non-zero reg divisor, check 5:OK torvalds#361/26 verifier_sdiv/SDIV32, non-zero reg divisor, check 5 @unpriv:OK torvalds#361/27 verifier_sdiv/SDIV32, non-zero reg divisor, check 6:OK torvalds#361/28 verifier_sdiv/SDIV32, non-zero reg divisor, check 6 @unpriv:OK torvalds#361/29 verifier_sdiv/SDIV32, non-zero reg divisor, check 7:OK torvalds#361/30 verifier_sdiv/SDIV32, non-zero reg divisor, check 7 @unpriv:OK torvalds#361/31 verifier_sdiv/SDIV32, non-zero reg divisor, check 8:OK torvalds#361/32 verifier_sdiv/SDIV32, non-zero reg divisor, check 8 @unpriv:OK torvalds#361/33 verifier_sdiv/SDIV64, non-zero imm divisor, check 1:OK torvalds#361/34 verifier_sdiv/SDIV64, non-zero imm divisor, check 1 @unpriv:OK torvalds#361/35 verifier_sdiv/SDIV64, non-zero imm divisor, check 2:OK torvalds#361/36 verifier_sdiv/SDIV64, non-zero imm divisor, check 2 @unpriv:OK torvalds#361/37 verifier_sdiv/SDIV64, non-zero imm divisor, check 3:OK torvalds#361/38 verifier_sdiv/SDIV64, non-zero imm divisor, check 3 @unpriv:OK torvalds#361/39 verifier_sdiv/SDIV64, non-zero imm divisor, check 4:OK torvalds#361/40 verifier_sdiv/SDIV64, non-zero imm divisor, check 4 @unpriv:OK torvalds#361/41 verifier_sdiv/SDIV64, non-zero imm divisor, check 5:OK torvalds#361/42 verifier_sdiv/SDIV64, non-zero imm divisor, check 5 @unpriv:OK torvalds#361/43 verifier_sdiv/SDIV64, non-zero imm divisor, check 6:OK torvalds#361/44 verifier_sdiv/SDIV64, non-zero imm divisor, check 6 @unpriv:OK torvalds#361/45 verifier_sdiv/SDIV64, non-zero reg divisor, check 1:OK torvalds#361/46 verifier_sdiv/SDIV64, non-zero reg divisor, check 1 @unpriv:OK torvalds#361/47 verifier_sdiv/SDIV64, non-zero reg divisor, check 2:OK torvalds#361/48 verifier_sdiv/SDIV64, non-zero reg divisor, check 2 @unpriv:OK torvalds#361/49 verifier_sdiv/SDIV64, non-zero reg divisor, check 3:OK torvalds#361/50 verifier_sdiv/SDIV64, non-zero reg divisor, check 3 @unpriv:OK torvalds#361/51 verifier_sdiv/SDIV64, non-zero reg divisor, check 4:OK torvalds#361/52 verifier_sdiv/SDIV64, non-zero reg divisor, check 4 @unpriv:OK torvalds#361/53 verifier_sdiv/SDIV64, non-zero reg divisor, check 5:OK torvalds#361/54 verifier_sdiv/SDIV64, non-zero reg divisor, check 5 @unpriv:OK torvalds#361/55 verifier_sdiv/SDIV64, non-zero reg divisor, check 6:OK torvalds#361/56 verifier_sdiv/SDIV64, non-zero reg divisor, check 6 @unpriv:OK torvalds#361/57 verifier_sdiv/SMOD32, non-zero imm divisor, check 1:OK torvalds#361/58 verifier_sdiv/SMOD32, non-zero imm divisor, check 1 @unpriv:OK torvalds#361/59 verifier_sdiv/SMOD32, non-zero imm divisor, check 2:OK torvalds#361/60 verifier_sdiv/SMOD32, non-zero imm divisor, check 2 @unpriv:OK torvalds#361/61 verifier_sdiv/SMOD32, non-zero imm divisor, check 3:OK torvalds#361/62 verifier_sdiv/SMOD32, non-zero imm divisor, check 3 @unpriv:OK torvalds#361/63 verifier_sdiv/SMOD32, non-zero imm divisor, check 4:OK torvalds#361/64 verifier_sdiv/SMOD32, non-zero imm divisor, check 4 @unpriv:OK torvalds#361/65 verifier_sdiv/SMOD32, non-zero imm divisor, check 5:OK torvalds#361/66 verifier_sdiv/SMOD32, non-zero imm divisor, check 5 @unpriv:OK torvalds#361/67 verifier_sdiv/SMOD32, non-zero imm divisor, check 6:OK torvalds#361/68 verifier_sdiv/SMOD32, non-zero imm divisor, check 6 @unpriv:OK torvalds#361/69 verifier_sdiv/SMOD32, non-zero reg divisor, check 1:OK torvalds#361/70 verifier_sdiv/SMOD32, non-zero reg divisor, check 1 @unpriv:OK torvalds#361/71 verifier_sdiv/SMOD32, non-zero reg divisor, check 2:OK torvalds#361/72 verifier_sdiv/SMOD32, non-zero reg divisor, check 2 @unpriv:OK torvalds#361/73 verifier_sdiv/SMOD32, non-zero reg divisor, check 3:OK torvalds#361/74 verifier_sdiv/SMOD32, non-zero reg divisor, check 3 @unpriv:OK torvalds#361/75 verifier_sdiv/SMOD32, non-zero reg divisor, check 4:OK torvalds#361/76 verifier_sdiv/SMOD32, non-zero reg divisor, check 4 @unpriv:OK torvalds#361/77 verifier_sdiv/SMOD32, non-zero reg divisor, check 5:OK torvalds#361/78 verifier_sdiv/SMOD32, non-zero reg divisor, check 5 @unpriv:OK torvalds#361/79 verifier_sdiv/SMOD32, non-zero reg divisor, check 6:OK torvalds#361/80 verifier_sdiv/SMOD32, non-zero reg divisor, check 6 @unpriv:OK torvalds#361/81 verifier_sdiv/SMOD64, non-zero imm divisor, check 1:OK torvalds#361/82 verifier_sdiv/SMOD64, non-zero imm divisor, check 1 @unpriv:OK torvalds#361/83 verifier_sdiv/SMOD64, non-zero imm divisor, check 2:OK torvalds#361/84 verifier_sdiv/SMOD64, non-zero imm divisor, check 2 @unpriv:OK torvalds#361/85 verifier_sdiv/SMOD64, non-zero imm divisor, check 3:OK torvalds#361/86 verifier_sdiv/SMOD64, non-zero imm divisor, check 3 @unpriv:OK torvalds#361/87 verifier_sdiv/SMOD64, non-zero imm divisor, check 4:OK torvalds#361/88 verifier_sdiv/SMOD64, non-zero imm divisor, check 4 @unpriv:OK torvalds#361/89 verifier_sdiv/SMOD64, non-zero imm divisor, check 5:OK torvalds#361/90 verifier_sdiv/SMOD64, non-zero imm divisor, check 5 @unpriv:OK torvalds#361/91 verifier_sdiv/SMOD64, non-zero imm divisor, check 6:OK torvalds#361/92 verifier_sdiv/SMOD64, non-zero imm divisor, check 6 @unpriv:OK torvalds#361/93 verifier_sdiv/SMOD64, non-zero imm divisor, check 7:OK torvalds#361/94 verifier_sdiv/SMOD64, non-zero imm divisor, check 7 @unpriv:OK torvalds#361/95 verifier_sdiv/SMOD64, non-zero imm divisor, check 8:OK torvalds#361/96 verifier_sdiv/SMOD64, non-zero imm divisor, check 8 @unpriv:OK torvalds#361/97 verifier_sdiv/SMOD64, non-zero reg divisor, check 1:OK torvalds#361/98 verifier_sdiv/SMOD64, non-zero reg divisor, check 1 @unpriv:OK torvalds#361/99 verifier_sdiv/SMOD64, non-zero reg divisor, check 2:OK torvalds#361/100 verifier_sdiv/SMOD64, non-zero reg divisor, check 2 @unpriv:OK torvalds#361/101 verifier_sdiv/SMOD64, non-zero reg divisor, check 3:OK torvalds#361/102 verifier_sdiv/SMOD64, non-zero reg divisor, check 3 @unpriv:OK torvalds#361/103 verifier_sdiv/SMOD64, non-zero reg divisor, check 4:OK torvalds#361/104 verifier_sdiv/SMOD64, non-zero reg divisor, check 4 @unpriv:OK torvalds#361/105 verifier_sdiv/SMOD64, non-zero reg divisor, check 5:OK torvalds#361/106 verifier_sdiv/SMOD64, non-zero reg divisor, check 5 @unpriv:OK torvalds#361/107 verifier_sdiv/SMOD64, non-zero reg divisor, check 6:OK torvalds#361/108 verifier_sdiv/SMOD64, non-zero reg divisor, check 6 @unpriv:OK torvalds#361/109 verifier_sdiv/SMOD64, non-zero reg divisor, check 7:OK torvalds#361/110 verifier_sdiv/SMOD64, non-zero reg divisor, check 7 @unpriv:OK torvalds#361/111 verifier_sdiv/SMOD64, non-zero reg divisor, check 8:OK torvalds#361/112 verifier_sdiv/SMOD64, non-zero reg divisor, check 8 @unpriv:OK torvalds#361/113 verifier_sdiv/SDIV32, zero divisor:OK torvalds#361/114 verifier_sdiv/SDIV32, zero divisor @unpriv:OK torvalds#361/115 verifier_sdiv/SDIV64, zero divisor:OK torvalds#361/116 verifier_sdiv/SDIV64, zero divisor @unpriv:OK torvalds#361/117 verifier_sdiv/SMOD32, zero divisor:OK torvalds#361/118 verifier_sdiv/SMOD32, zero divisor @unpriv:OK torvalds#361/119 verifier_sdiv/SMOD64, zero divisor:OK torvalds#361/120 verifier_sdiv/SMOD64, zero divisor @unpriv:OK torvalds#361 verifier_sdiv:OK Summary: 5/163 PASSED, 0 SKIPPED, 0 FAILED # ./test_progs -t ldsx_insn test_map_val_and_probed_memory:PASS:test_ldsx_insn__open 0 nsec test_map_val_and_probed_memory:PASS:test_ldsx_insn__load 0 nsec libbpf: prog 'test_ptr_struct_arg': failed to attach: ERROR: strerror_r(-524)=22 libbpf: prog 'test_ptr_struct_arg': failed to auto-attach: -524 test_map_val_and_probed_memory:FAIL:test_ldsx_insn__attach unexpected error: -524 (errno 524) torvalds#116/1 ldsx_insn/map_val and probed_memory:FAIL torvalds#116/2 ldsx_insn/ctx_member_sign_ext:OK torvalds#116/3 ldsx_insn/ctx_member_narrow_sign_ext:OK torvalds#116 ldsx_insn:FAIL All error logs: test_map_val_and_probed_memory:PASS:test_ldsx_insn__open 0 nsec test_map_val_and_probed_memory:PASS:test_ldsx_insn__load 0 nsec libbpf: prog 'test_ptr_struct_arg': failed to attach: ERROR: strerror_r(-524)=22 libbpf: prog 'test_ptr_struct_arg': failed to auto-attach: -524 test_map_val_and_probed_memory:FAIL:test_ldsx_insn__attach unexpected error: -524 (errno 524) torvalds#116/1 ldsx_insn/map_val and probed_memory:FAIL torvalds#116 ldsx_insn:FAIL Summary: 0/2 PASSED, 0 SKIPPED, 1 FAILED Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
yetist
pushed a commit
to loongarchlinux/linux
that referenced
this pull request
Nov 13, 2023
Enable the cpu v4 tests for LoongArch. Currently, we don't have BPF trampoline in LoongArch JIT, so the fentry test `test_ptr_struct_arg` still failed, will followup. Test result attached below: # ./test_progs -t verifier_sdiv,verifier_movsx,verifier_ldsx,verifier_gotol,verifier_bswap torvalds#316/1 verifier_bswap/BSWAP, 16:OK torvalds#316/2 verifier_bswap/BSWAP, 16 @unpriv:OK torvalds#316/3 verifier_bswap/BSWAP, 32:OK torvalds#316/4 verifier_bswap/BSWAP, 32 @unpriv:OK torvalds#316/5 verifier_bswap/BSWAP, 64:OK torvalds#316/6 verifier_bswap/BSWAP, 64 @unpriv:OK torvalds#316 verifier_bswap:OK torvalds#330/1 verifier_gotol/gotol, small_imm:OK torvalds#330/2 verifier_gotol/gotol, small_imm @unpriv:OK torvalds#330 verifier_gotol:OK torvalds#338/1 verifier_ldsx/LDSX, S8:OK torvalds#338/2 verifier_ldsx/LDSX, S8 @unpriv:OK torvalds#338/3 verifier_ldsx/LDSX, S16:OK torvalds#338/4 verifier_ldsx/LDSX, S16 @unpriv:OK torvalds#338/5 verifier_ldsx/LDSX, S32:OK torvalds#338/6 verifier_ldsx/LDSX, S32 @unpriv:OK torvalds#338/7 verifier_ldsx/LDSX, S8 range checking, privileged:OK torvalds#338/8 verifier_ldsx/LDSX, S16 range checking:OK torvalds#338/9 verifier_ldsx/LDSX, S16 range checking @unpriv:OK torvalds#338/10 verifier_ldsx/LDSX, S32 range checking:OK torvalds#338/11 verifier_ldsx/LDSX, S32 range checking @unpriv:OK torvalds#338 verifier_ldsx:OK torvalds#349/1 verifier_movsx/MOV32SX, S8:OK torvalds#349/2 verifier_movsx/MOV32SX, S8 @unpriv:OK torvalds#349/3 verifier_movsx/MOV32SX, S16:OK torvalds#349/4 verifier_movsx/MOV32SX, S16 @unpriv:OK torvalds#349/5 verifier_movsx/MOV64SX, S8:OK torvalds#349/6 verifier_movsx/MOV64SX, S8 @unpriv:OK torvalds#349/7 verifier_movsx/MOV64SX, S16:OK torvalds#349/8 verifier_movsx/MOV64SX, S16 @unpriv:OK torvalds#349/9 verifier_movsx/MOV64SX, S32:OK torvalds#349/10 verifier_movsx/MOV64SX, S32 @unpriv:OK torvalds#349/11 verifier_movsx/MOV32SX, S8, range_check:OK torvalds#349/12 verifier_movsx/MOV32SX, S8, range_check @unpriv:OK torvalds#349/13 verifier_movsx/MOV32SX, S16, range_check:OK torvalds#349/14 verifier_movsx/MOV32SX, S16, range_check @unpriv:OK torvalds#349/15 verifier_movsx/MOV32SX, S16, range_check 2:OK torvalds#349/16 verifier_movsx/MOV32SX, S16, range_check 2 @unpriv:OK torvalds#349/17 verifier_movsx/MOV64SX, S8, range_check:OK torvalds#349/18 verifier_movsx/MOV64SX, S8, range_check @unpriv:OK torvalds#349/19 verifier_movsx/MOV64SX, S16, range_check:OK torvalds#349/20 verifier_movsx/MOV64SX, S16, range_check @unpriv:OK torvalds#349/21 verifier_movsx/MOV64SX, S32, range_check:OK torvalds#349/22 verifier_movsx/MOV64SX, S32, range_check @unpriv:OK torvalds#349/23 verifier_movsx/MOV64SX, S16, R10 Sign Extension:OK torvalds#349/24 verifier_movsx/MOV64SX, S16, R10 Sign Extension @unpriv:OK torvalds#349 verifier_movsx:OK torvalds#361/1 verifier_sdiv/SDIV32, non-zero imm divisor, check 1:OK torvalds#361/2 verifier_sdiv/SDIV32, non-zero imm divisor, check 1 @unpriv:OK torvalds#361/3 verifier_sdiv/SDIV32, non-zero imm divisor, check 2:OK torvalds#361/4 verifier_sdiv/SDIV32, non-zero imm divisor, check 2 @unpriv:OK torvalds#361/5 verifier_sdiv/SDIV32, non-zero imm divisor, check 3:OK torvalds#361/6 verifier_sdiv/SDIV32, non-zero imm divisor, check 3 @unpriv:OK torvalds#361/7 verifier_sdiv/SDIV32, non-zero imm divisor, check 4:OK torvalds#361/8 verifier_sdiv/SDIV32, non-zero imm divisor, check 4 @unpriv:OK torvalds#361/9 verifier_sdiv/SDIV32, non-zero imm divisor, check 5:OK torvalds#361/10 verifier_sdiv/SDIV32, non-zero imm divisor, check 5 @unpriv:OK torvalds#361/11 verifier_sdiv/SDIV32, non-zero imm divisor, check 6:OK torvalds#361/12 verifier_sdiv/SDIV32, non-zero imm divisor, check 6 @unpriv:OK torvalds#361/13 verifier_sdiv/SDIV32, non-zero imm divisor, check 7:OK torvalds#361/14 verifier_sdiv/SDIV32, non-zero imm divisor, check 7 @unpriv:OK torvalds#361/15 verifier_sdiv/SDIV32, non-zero imm divisor, check 8:OK torvalds#361/16 verifier_sdiv/SDIV32, non-zero imm divisor, check 8 @unpriv:OK torvalds#361/17 verifier_sdiv/SDIV32, non-zero reg divisor, check 1:OK torvalds#361/18 verifier_sdiv/SDIV32, non-zero reg divisor, check 1 @unpriv:OK torvalds#361/19 verifier_sdiv/SDIV32, non-zero reg divisor, check 2:OK torvalds#361/20 verifier_sdiv/SDIV32, non-zero reg divisor, check 2 @unpriv:OK torvalds#361/21 verifier_sdiv/SDIV32, non-zero reg divisor, check 3:OK torvalds#361/22 verifier_sdiv/SDIV32, non-zero reg divisor, check 3 @unpriv:OK torvalds#361/23 verifier_sdiv/SDIV32, non-zero reg divisor, check 4:OK torvalds#361/24 verifier_sdiv/SDIV32, non-zero reg divisor, check 4 @unpriv:OK torvalds#361/25 verifier_sdiv/SDIV32, non-zero reg divisor, check 5:OK torvalds#361/26 verifier_sdiv/SDIV32, non-zero reg divisor, check 5 @unpriv:OK torvalds#361/27 verifier_sdiv/SDIV32, non-zero reg divisor, check 6:OK torvalds#361/28 verifier_sdiv/SDIV32, non-zero reg divisor, check 6 @unpriv:OK torvalds#361/29 verifier_sdiv/SDIV32, non-zero reg divisor, check 7:OK torvalds#361/30 verifier_sdiv/SDIV32, non-zero reg divisor, check 7 @unpriv:OK torvalds#361/31 verifier_sdiv/SDIV32, non-zero reg divisor, check 8:OK torvalds#361/32 verifier_sdiv/SDIV32, non-zero reg divisor, check 8 @unpriv:OK torvalds#361/33 verifier_sdiv/SDIV64, non-zero imm divisor, check 1:OK torvalds#361/34 verifier_sdiv/SDIV64, non-zero imm divisor, check 1 @unpriv:OK torvalds#361/35 verifier_sdiv/SDIV64, non-zero imm divisor, check 2:OK torvalds#361/36 verifier_sdiv/SDIV64, non-zero imm divisor, check 2 @unpriv:OK torvalds#361/37 verifier_sdiv/SDIV64, non-zero imm divisor, check 3:OK torvalds#361/38 verifier_sdiv/SDIV64, non-zero imm divisor, check 3 @unpriv:OK torvalds#361/39 verifier_sdiv/SDIV64, non-zero imm divisor, check 4:OK torvalds#361/40 verifier_sdiv/SDIV64, non-zero imm divisor, check 4 @unpriv:OK torvalds#361/41 verifier_sdiv/SDIV64, non-zero imm divisor, check 5:OK torvalds#361/42 verifier_sdiv/SDIV64, non-zero imm divisor, check 5 @unpriv:OK torvalds#361/43 verifier_sdiv/SDIV64, non-zero imm divisor, check 6:OK torvalds#361/44 verifier_sdiv/SDIV64, non-zero imm divisor, check 6 @unpriv:OK torvalds#361/45 verifier_sdiv/SDIV64, non-zero reg divisor, check 1:OK torvalds#361/46 verifier_sdiv/SDIV64, non-zero reg divisor, check 1 @unpriv:OK torvalds#361/47 verifier_sdiv/SDIV64, non-zero reg divisor, check 2:OK torvalds#361/48 verifier_sdiv/SDIV64, non-zero reg divisor, check 2 @unpriv:OK torvalds#361/49 verifier_sdiv/SDIV64, non-zero reg divisor, check 3:OK torvalds#361/50 verifier_sdiv/SDIV64, non-zero reg divisor, check 3 @unpriv:OK torvalds#361/51 verifier_sdiv/SDIV64, non-zero reg divisor, check 4:OK torvalds#361/52 verifier_sdiv/SDIV64, non-zero reg divisor, check 4 @unpriv:OK torvalds#361/53 verifier_sdiv/SDIV64, non-zero reg divisor, check 5:OK torvalds#361/54 verifier_sdiv/SDIV64, non-zero reg divisor, check 5 @unpriv:OK torvalds#361/55 verifier_sdiv/SDIV64, non-zero reg divisor, check 6:OK torvalds#361/56 verifier_sdiv/SDIV64, non-zero reg divisor, check 6 @unpriv:OK torvalds#361/57 verifier_sdiv/SMOD32, non-zero imm divisor, check 1:OK torvalds#361/58 verifier_sdiv/SMOD32, non-zero imm divisor, check 1 @unpriv:OK torvalds#361/59 verifier_sdiv/SMOD32, non-zero imm divisor, check 2:OK torvalds#361/60 verifier_sdiv/SMOD32, non-zero imm divisor, check 2 @unpriv:OK torvalds#361/61 verifier_sdiv/SMOD32, non-zero imm divisor, check 3:OK torvalds#361/62 verifier_sdiv/SMOD32, non-zero imm divisor, check 3 @unpriv:OK torvalds#361/63 verifier_sdiv/SMOD32, non-zero imm divisor, check 4:OK torvalds#361/64 verifier_sdiv/SMOD32, non-zero imm divisor, check 4 @unpriv:OK torvalds#361/65 verifier_sdiv/SMOD32, non-zero imm divisor, check 5:OK torvalds#361/66 verifier_sdiv/SMOD32, non-zero imm divisor, check 5 @unpriv:OK torvalds#361/67 verifier_sdiv/SMOD32, non-zero imm divisor, check 6:OK torvalds#361/68 verifier_sdiv/SMOD32, non-zero imm divisor, check 6 @unpriv:OK torvalds#361/69 verifier_sdiv/SMOD32, non-zero reg divisor, check 1:OK torvalds#361/70 verifier_sdiv/SMOD32, non-zero reg divisor, check 1 @unpriv:OK torvalds#361/71 verifier_sdiv/SMOD32, non-zero reg divisor, check 2:OK torvalds#361/72 verifier_sdiv/SMOD32, non-zero reg divisor, check 2 @unpriv:OK torvalds#361/73 verifier_sdiv/SMOD32, non-zero reg divisor, check 3:OK torvalds#361/74 verifier_sdiv/SMOD32, non-zero reg divisor, check 3 @unpriv:OK torvalds#361/75 verifier_sdiv/SMOD32, non-zero reg divisor, check 4:OK torvalds#361/76 verifier_sdiv/SMOD32, non-zero reg divisor, check 4 @unpriv:OK torvalds#361/77 verifier_sdiv/SMOD32, non-zero reg divisor, check 5:OK torvalds#361/78 verifier_sdiv/SMOD32, non-zero reg divisor, check 5 @unpriv:OK torvalds#361/79 verifier_sdiv/SMOD32, non-zero reg divisor, check 6:OK torvalds#361/80 verifier_sdiv/SMOD32, non-zero reg divisor, check 6 @unpriv:OK torvalds#361/81 verifier_sdiv/SMOD64, non-zero imm divisor, check 1:OK torvalds#361/82 verifier_sdiv/SMOD64, non-zero imm divisor, check 1 @unpriv:OK torvalds#361/83 verifier_sdiv/SMOD64, non-zero imm divisor, check 2:OK torvalds#361/84 verifier_sdiv/SMOD64, non-zero imm divisor, check 2 @unpriv:OK torvalds#361/85 verifier_sdiv/SMOD64, non-zero imm divisor, check 3:OK torvalds#361/86 verifier_sdiv/SMOD64, non-zero imm divisor, check 3 @unpriv:OK torvalds#361/87 verifier_sdiv/SMOD64, non-zero imm divisor, check 4:OK torvalds#361/88 verifier_sdiv/SMOD64, non-zero imm divisor, check 4 @unpriv:OK torvalds#361/89 verifier_sdiv/SMOD64, non-zero imm divisor, check 5:OK torvalds#361/90 verifier_sdiv/SMOD64, non-zero imm divisor, check 5 @unpriv:OK torvalds#361/91 verifier_sdiv/SMOD64, non-zero imm divisor, check 6:OK torvalds#361/92 verifier_sdiv/SMOD64, non-zero imm divisor, check 6 @unpriv:OK torvalds#361/93 verifier_sdiv/SMOD64, non-zero imm divisor, check 7:OK torvalds#361/94 verifier_sdiv/SMOD64, non-zero imm divisor, check 7 @unpriv:OK torvalds#361/95 verifier_sdiv/SMOD64, non-zero imm divisor, check 8:OK torvalds#361/96 verifier_sdiv/SMOD64, non-zero imm divisor, check 8 @unpriv:OK torvalds#361/97 verifier_sdiv/SMOD64, non-zero reg divisor, check 1:OK torvalds#361/98 verifier_sdiv/SMOD64, non-zero reg divisor, check 1 @unpriv:OK torvalds#361/99 verifier_sdiv/SMOD64, non-zero reg divisor, check 2:OK torvalds#361/100 verifier_sdiv/SMOD64, non-zero reg divisor, check 2 @unpriv:OK torvalds#361/101 verifier_sdiv/SMOD64, non-zero reg divisor, check 3:OK torvalds#361/102 verifier_sdiv/SMOD64, non-zero reg divisor, check 3 @unpriv:OK torvalds#361/103 verifier_sdiv/SMOD64, non-zero reg divisor, check 4:OK torvalds#361/104 verifier_sdiv/SMOD64, non-zero reg divisor, check 4 @unpriv:OK torvalds#361/105 verifier_sdiv/SMOD64, non-zero reg divisor, check 5:OK torvalds#361/106 verifier_sdiv/SMOD64, non-zero reg divisor, check 5 @unpriv:OK torvalds#361/107 verifier_sdiv/SMOD64, non-zero reg divisor, check 6:OK torvalds#361/108 verifier_sdiv/SMOD64, non-zero reg divisor, check 6 @unpriv:OK torvalds#361/109 verifier_sdiv/SMOD64, non-zero reg divisor, check 7:OK torvalds#361/110 verifier_sdiv/SMOD64, non-zero reg divisor, check 7 @unpriv:OK torvalds#361/111 verifier_sdiv/SMOD64, non-zero reg divisor, check 8:OK torvalds#361/112 verifier_sdiv/SMOD64, non-zero reg divisor, check 8 @unpriv:OK torvalds#361/113 verifier_sdiv/SDIV32, zero divisor:OK torvalds#361/114 verifier_sdiv/SDIV32, zero divisor @unpriv:OK torvalds#361/115 verifier_sdiv/SDIV64, zero divisor:OK torvalds#361/116 verifier_sdiv/SDIV64, zero divisor @unpriv:OK torvalds#361/117 verifier_sdiv/SMOD32, zero divisor:OK torvalds#361/118 verifier_sdiv/SMOD32, zero divisor @unpriv:OK torvalds#361/119 verifier_sdiv/SMOD64, zero divisor:OK torvalds#361/120 verifier_sdiv/SMOD64, zero divisor @unpriv:OK torvalds#361 verifier_sdiv:OK Summary: 5/163 PASSED, 0 SKIPPED, 0 FAILED # ./test_progs -t ldsx_insn test_map_val_and_probed_memory:PASS:test_ldsx_insn__open 0 nsec test_map_val_and_probed_memory:PASS:test_ldsx_insn__load 0 nsec libbpf: prog 'test_ptr_struct_arg': failed to attach: ERROR: strerror_r(-524)=22 libbpf: prog 'test_ptr_struct_arg': failed to auto-attach: -524 test_map_val_and_probed_memory:FAIL:test_ldsx_insn__attach unexpected error: -524 (errno 524) torvalds#116/1 ldsx_insn/map_val and probed_memory:FAIL torvalds#116/2 ldsx_insn/ctx_member_sign_ext:OK torvalds#116/3 ldsx_insn/ctx_member_narrow_sign_ext:OK torvalds#116 ldsx_insn:FAIL All error logs: test_map_val_and_probed_memory:PASS:test_ldsx_insn__open 0 nsec test_map_val_and_probed_memory:PASS:test_ldsx_insn__load 0 nsec libbpf: prog 'test_ptr_struct_arg': failed to attach: ERROR: strerror_r(-524)=22 libbpf: prog 'test_ptr_struct_arg': failed to auto-attach: -524 test_map_val_and_probed_memory:FAIL:test_ldsx_insn__attach unexpected error: -524 (errno 524) torvalds#116/1 ldsx_insn/map_val and probed_memory:FAIL torvalds#116 ldsx_insn:FAIL Summary: 0/2 PASSED, 0 SKIPPED, 1 FAILED Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
RevySR
pushed a commit
to RevySR/linux
that referenced
this pull request
Nov 23, 2023
Enable the cpu v4 tests for LoongArch. Currently, we don't have BPF trampoline in LoongArch JIT, so the fentry test `test_ptr_struct_arg` still failed, will followup. Test result attached below: # ./test_progs -t verifier_sdiv,verifier_movsx,verifier_ldsx,verifier_gotol,verifier_bswap torvalds#316/1 verifier_bswap/BSWAP, 16:OK torvalds#316/2 verifier_bswap/BSWAP, 16 @unpriv:OK torvalds#316/3 verifier_bswap/BSWAP, 32:OK torvalds#316/4 verifier_bswap/BSWAP, 32 @unpriv:OK torvalds#316/5 verifier_bswap/BSWAP, 64:OK torvalds#316/6 verifier_bswap/BSWAP, 64 @unpriv:OK torvalds#316 verifier_bswap:OK torvalds#330/1 verifier_gotol/gotol, small_imm:OK torvalds#330/2 verifier_gotol/gotol, small_imm @unpriv:OK torvalds#330 verifier_gotol:OK torvalds#338/1 verifier_ldsx/LDSX, S8:OK torvalds#338/2 verifier_ldsx/LDSX, S8 @unpriv:OK torvalds#338/3 verifier_ldsx/LDSX, S16:OK torvalds#338/4 verifier_ldsx/LDSX, S16 @unpriv:OK torvalds#338/5 verifier_ldsx/LDSX, S32:OK torvalds#338/6 verifier_ldsx/LDSX, S32 @unpriv:OK torvalds#338/7 verifier_ldsx/LDSX, S8 range checking, privileged:OK torvalds#338/8 verifier_ldsx/LDSX, S16 range checking:OK torvalds#338/9 verifier_ldsx/LDSX, S16 range checking @unpriv:OK torvalds#338/10 verifier_ldsx/LDSX, S32 range checking:OK torvalds#338/11 verifier_ldsx/LDSX, S32 range checking @unpriv:OK torvalds#338 verifier_ldsx:OK torvalds#349/1 verifier_movsx/MOV32SX, S8:OK torvalds#349/2 verifier_movsx/MOV32SX, S8 @unpriv:OK torvalds#349/3 verifier_movsx/MOV32SX, S16:OK torvalds#349/4 verifier_movsx/MOV32SX, S16 @unpriv:OK torvalds#349/5 verifier_movsx/MOV64SX, S8:OK torvalds#349/6 verifier_movsx/MOV64SX, S8 @unpriv:OK torvalds#349/7 verifier_movsx/MOV64SX, S16:OK torvalds#349/8 verifier_movsx/MOV64SX, S16 @unpriv:OK torvalds#349/9 verifier_movsx/MOV64SX, S32:OK torvalds#349/10 verifier_movsx/MOV64SX, S32 @unpriv:OK torvalds#349/11 verifier_movsx/MOV32SX, S8, range_check:OK torvalds#349/12 verifier_movsx/MOV32SX, S8, range_check @unpriv:OK torvalds#349/13 verifier_movsx/MOV32SX, S16, range_check:OK torvalds#349/14 verifier_movsx/MOV32SX, S16, range_check @unpriv:OK torvalds#349/15 verifier_movsx/MOV32SX, S16, range_check 2:OK torvalds#349/16 verifier_movsx/MOV32SX, S16, range_check 2 @unpriv:OK torvalds#349/17 verifier_movsx/MOV64SX, S8, range_check:OK torvalds#349/18 verifier_movsx/MOV64SX, S8, range_check @unpriv:OK torvalds#349/19 verifier_movsx/MOV64SX, S16, range_check:OK torvalds#349/20 verifier_movsx/MOV64SX, S16, range_check @unpriv:OK torvalds#349/21 verifier_movsx/MOV64SX, S32, range_check:OK torvalds#349/22 verifier_movsx/MOV64SX, S32, range_check @unpriv:OK torvalds#349/23 verifier_movsx/MOV64SX, S16, R10 Sign Extension:OK torvalds#349/24 verifier_movsx/MOV64SX, S16, R10 Sign Extension @unpriv:OK torvalds#349 verifier_movsx:OK torvalds#361/1 verifier_sdiv/SDIV32, non-zero imm divisor, check 1:OK torvalds#361/2 verifier_sdiv/SDIV32, non-zero imm divisor, check 1 @unpriv:OK torvalds#361/3 verifier_sdiv/SDIV32, non-zero imm divisor, check 2:OK torvalds#361/4 verifier_sdiv/SDIV32, non-zero imm divisor, check 2 @unpriv:OK torvalds#361/5 verifier_sdiv/SDIV32, non-zero imm divisor, check 3:OK torvalds#361/6 verifier_sdiv/SDIV32, non-zero imm divisor, check 3 @unpriv:OK torvalds#361/7 verifier_sdiv/SDIV32, non-zero imm divisor, check 4:OK torvalds#361/8 verifier_sdiv/SDIV32, non-zero imm divisor, check 4 @unpriv:OK torvalds#361/9 verifier_sdiv/SDIV32, non-zero imm divisor, check 5:OK torvalds#361/10 verifier_sdiv/SDIV32, non-zero imm divisor, check 5 @unpriv:OK torvalds#361/11 verifier_sdiv/SDIV32, non-zero imm divisor, check 6:OK torvalds#361/12 verifier_sdiv/SDIV32, non-zero imm divisor, check 6 @unpriv:OK torvalds#361/13 verifier_sdiv/SDIV32, non-zero imm divisor, check 7:OK torvalds#361/14 verifier_sdiv/SDIV32, non-zero imm divisor, check 7 @unpriv:OK torvalds#361/15 verifier_sdiv/SDIV32, non-zero imm divisor, check 8:OK torvalds#361/16 verifier_sdiv/SDIV32, non-zero imm divisor, check 8 @unpriv:OK torvalds#361/17 verifier_sdiv/SDIV32, non-zero reg divisor, check 1:OK torvalds#361/18 verifier_sdiv/SDIV32, non-zero reg divisor, check 1 @unpriv:OK torvalds#361/19 verifier_sdiv/SDIV32, non-zero reg divisor, check 2:OK torvalds#361/20 verifier_sdiv/SDIV32, non-zero reg divisor, check 2 @unpriv:OK torvalds#361/21 verifier_sdiv/SDIV32, non-zero reg divisor, check 3:OK torvalds#361/22 verifier_sdiv/SDIV32, non-zero reg divisor, check 3 @unpriv:OK torvalds#361/23 verifier_sdiv/SDIV32, non-zero reg divisor, check 4:OK torvalds#361/24 verifier_sdiv/SDIV32, non-zero reg divisor, check 4 @unpriv:OK torvalds#361/25 verifier_sdiv/SDIV32, non-zero reg divisor, check 5:OK torvalds#361/26 verifier_sdiv/SDIV32, non-zero reg divisor, check 5 @unpriv:OK torvalds#361/27 verifier_sdiv/SDIV32, non-zero reg divisor, check 6:OK torvalds#361/28 verifier_sdiv/SDIV32, non-zero reg divisor, check 6 @unpriv:OK torvalds#361/29 verifier_sdiv/SDIV32, non-zero reg divisor, check 7:OK torvalds#361/30 verifier_sdiv/SDIV32, non-zero reg divisor, check 7 @unpriv:OK torvalds#361/31 verifier_sdiv/SDIV32, non-zero reg divisor, check 8:OK torvalds#361/32 verifier_sdiv/SDIV32, non-zero reg divisor, check 8 @unpriv:OK torvalds#361/33 verifier_sdiv/SDIV64, non-zero imm divisor, check 1:OK torvalds#361/34 verifier_sdiv/SDIV64, non-zero imm divisor, check 1 @unpriv:OK torvalds#361/35 verifier_sdiv/SDIV64, non-zero imm divisor, check 2:OK torvalds#361/36 verifier_sdiv/SDIV64, non-zero imm divisor, check 2 @unpriv:OK torvalds#361/37 verifier_sdiv/SDIV64, non-zero imm divisor, check 3:OK torvalds#361/38 verifier_sdiv/SDIV64, non-zero imm divisor, check 3 @unpriv:OK torvalds#361/39 verifier_sdiv/SDIV64, non-zero imm divisor, check 4:OK torvalds#361/40 verifier_sdiv/SDIV64, non-zero imm divisor, check 4 @unpriv:OK torvalds#361/41 verifier_sdiv/SDIV64, non-zero imm divisor, check 5:OK torvalds#361/42 verifier_sdiv/SDIV64, non-zero imm divisor, check 5 @unpriv:OK torvalds#361/43 verifier_sdiv/SDIV64, non-zero imm divisor, check 6:OK torvalds#361/44 verifier_sdiv/SDIV64, non-zero imm divisor, check 6 @unpriv:OK torvalds#361/45 verifier_sdiv/SDIV64, non-zero reg divisor, check 1:OK torvalds#361/46 verifier_sdiv/SDIV64, non-zero reg divisor, check 1 @unpriv:OK torvalds#361/47 verifier_sdiv/SDIV64, non-zero reg divisor, check 2:OK torvalds#361/48 verifier_sdiv/SDIV64, non-zero reg divisor, check 2 @unpriv:OK torvalds#361/49 verifier_sdiv/SDIV64, non-zero reg divisor, check 3:OK torvalds#361/50 verifier_sdiv/SDIV64, non-zero reg divisor, check 3 @unpriv:OK torvalds#361/51 verifier_sdiv/SDIV64, non-zero reg divisor, check 4:OK torvalds#361/52 verifier_sdiv/SDIV64, non-zero reg divisor, check 4 @unpriv:OK torvalds#361/53 verifier_sdiv/SDIV64, non-zero reg divisor, check 5:OK torvalds#361/54 verifier_sdiv/SDIV64, non-zero reg divisor, check 5 @unpriv:OK torvalds#361/55 verifier_sdiv/SDIV64, non-zero reg divisor, check 6:OK torvalds#361/56 verifier_sdiv/SDIV64, non-zero reg divisor, check 6 @unpriv:OK torvalds#361/57 verifier_sdiv/SMOD32, non-zero imm divisor, check 1:OK torvalds#361/58 verifier_sdiv/SMOD32, non-zero imm divisor, check 1 @unpriv:OK torvalds#361/59 verifier_sdiv/SMOD32, non-zero imm divisor, check 2:OK torvalds#361/60 verifier_sdiv/SMOD32, non-zero imm divisor, check 2 @unpriv:OK torvalds#361/61 verifier_sdiv/SMOD32, non-zero imm divisor, check 3:OK torvalds#361/62 verifier_sdiv/SMOD32, non-zero imm divisor, check 3 @unpriv:OK torvalds#361/63 verifier_sdiv/SMOD32, non-zero imm divisor, check 4:OK torvalds#361/64 verifier_sdiv/SMOD32, non-zero imm divisor, check 4 @unpriv:OK torvalds#361/65 verifier_sdiv/SMOD32, non-zero imm divisor, check 5:OK torvalds#361/66 verifier_sdiv/SMOD32, non-zero imm divisor, check 5 @unpriv:OK torvalds#361/67 verifier_sdiv/SMOD32, non-zero imm divisor, check 6:OK torvalds#361/68 verifier_sdiv/SMOD32, non-zero imm divisor, check 6 @unpriv:OK torvalds#361/69 verifier_sdiv/SMOD32, non-zero reg divisor, check 1:OK torvalds#361/70 verifier_sdiv/SMOD32, non-zero reg divisor, check 1 @unpriv:OK torvalds#361/71 verifier_sdiv/SMOD32, non-zero reg divisor, check 2:OK torvalds#361/72 verifier_sdiv/SMOD32, non-zero reg divisor, check 2 @unpriv:OK torvalds#361/73 verifier_sdiv/SMOD32, non-zero reg divisor, check 3:OK torvalds#361/74 verifier_sdiv/SMOD32, non-zero reg divisor, check 3 @unpriv:OK torvalds#361/75 verifier_sdiv/SMOD32, non-zero reg divisor, check 4:OK torvalds#361/76 verifier_sdiv/SMOD32, non-zero reg divisor, check 4 @unpriv:OK torvalds#361/77 verifier_sdiv/SMOD32, non-zero reg divisor, check 5:OK torvalds#361/78 verifier_sdiv/SMOD32, non-zero reg divisor, check 5 @unpriv:OK torvalds#361/79 verifier_sdiv/SMOD32, non-zero reg divisor, check 6:OK torvalds#361/80 verifier_sdiv/SMOD32, non-zero reg divisor, check 6 @unpriv:OK torvalds#361/81 verifier_sdiv/SMOD64, non-zero imm divisor, check 1:OK torvalds#361/82 verifier_sdiv/SMOD64, non-zero imm divisor, check 1 @unpriv:OK torvalds#361/83 verifier_sdiv/SMOD64, non-zero imm divisor, check 2:OK torvalds#361/84 verifier_sdiv/SMOD64, non-zero imm divisor, check 2 @unpriv:OK torvalds#361/85 verifier_sdiv/SMOD64, non-zero imm divisor, check 3:OK torvalds#361/86 verifier_sdiv/SMOD64, non-zero imm divisor, check 3 @unpriv:OK torvalds#361/87 verifier_sdiv/SMOD64, non-zero imm divisor, check 4:OK torvalds#361/88 verifier_sdiv/SMOD64, non-zero imm divisor, check 4 @unpriv:OK torvalds#361/89 verifier_sdiv/SMOD64, non-zero imm divisor, check 5:OK torvalds#361/90 verifier_sdiv/SMOD64, non-zero imm divisor, check 5 @unpriv:OK torvalds#361/91 verifier_sdiv/SMOD64, non-zero imm divisor, check 6:OK torvalds#361/92 verifier_sdiv/SMOD64, non-zero imm divisor, check 6 @unpriv:OK torvalds#361/93 verifier_sdiv/SMOD64, non-zero imm divisor, check 7:OK torvalds#361/94 verifier_sdiv/SMOD64, non-zero imm divisor, check 7 @unpriv:OK torvalds#361/95 verifier_sdiv/SMOD64, non-zero imm divisor, check 8:OK torvalds#361/96 verifier_sdiv/SMOD64, non-zero imm divisor, check 8 @unpriv:OK torvalds#361/97 verifier_sdiv/SMOD64, non-zero reg divisor, check 1:OK torvalds#361/98 verifier_sdiv/SMOD64, non-zero reg divisor, check 1 @unpriv:OK torvalds#361/99 verifier_sdiv/SMOD64, non-zero reg divisor, check 2:OK torvalds#361/100 verifier_sdiv/SMOD64, non-zero reg divisor, check 2 @unpriv:OK torvalds#361/101 verifier_sdiv/SMOD64, non-zero reg divisor, check 3:OK torvalds#361/102 verifier_sdiv/SMOD64, non-zero reg divisor, check 3 @unpriv:OK torvalds#361/103 verifier_sdiv/SMOD64, non-zero reg divisor, check 4:OK torvalds#361/104 verifier_sdiv/SMOD64, non-zero reg divisor, check 4 @unpriv:OK torvalds#361/105 verifier_sdiv/SMOD64, non-zero reg divisor, check 5:OK torvalds#361/106 verifier_sdiv/SMOD64, non-zero reg divisor, check 5 @unpriv:OK torvalds#361/107 verifier_sdiv/SMOD64, non-zero reg divisor, check 6:OK torvalds#361/108 verifier_sdiv/SMOD64, non-zero reg divisor, check 6 @unpriv:OK torvalds#361/109 verifier_sdiv/SMOD64, non-zero reg divisor, check 7:OK torvalds#361/110 verifier_sdiv/SMOD64, non-zero reg divisor, check 7 @unpriv:OK torvalds#361/111 verifier_sdiv/SMOD64, non-zero reg divisor, check 8:OK torvalds#361/112 verifier_sdiv/SMOD64, non-zero reg divisor, check 8 @unpriv:OK torvalds#361/113 verifier_sdiv/SDIV32, zero divisor:OK torvalds#361/114 verifier_sdiv/SDIV32, zero divisor @unpriv:OK torvalds#361/115 verifier_sdiv/SDIV64, zero divisor:OK torvalds#361/116 verifier_sdiv/SDIV64, zero divisor @unpriv:OK torvalds#361/117 verifier_sdiv/SMOD32, zero divisor:OK torvalds#361/118 verifier_sdiv/SMOD32, zero divisor @unpriv:OK torvalds#361/119 verifier_sdiv/SMOD64, zero divisor:OK torvalds#361/120 verifier_sdiv/SMOD64, zero divisor @unpriv:OK torvalds#361 verifier_sdiv:OK Summary: 5/163 PASSED, 0 SKIPPED, 0 FAILED # ./test_progs -t ldsx_insn test_map_val_and_probed_memory:PASS:test_ldsx_insn__open 0 nsec test_map_val_and_probed_memory:PASS:test_ldsx_insn__load 0 nsec libbpf: prog 'test_ptr_struct_arg': failed to attach: ERROR: strerror_r(-524)=22 libbpf: prog 'test_ptr_struct_arg': failed to auto-attach: -524 test_map_val_and_probed_memory:FAIL:test_ldsx_insn__attach unexpected error: -524 (errno 524) torvalds#116/1 ldsx_insn/map_val and probed_memory:FAIL torvalds#116/2 ldsx_insn/ctx_member_sign_ext:OK torvalds#116/3 ldsx_insn/ctx_member_narrow_sign_ext:OK torvalds#116 ldsx_insn:FAIL All error logs: test_map_val_and_probed_memory:PASS:test_ldsx_insn__open 0 nsec test_map_val_and_probed_memory:PASS:test_ldsx_insn__load 0 nsec libbpf: prog 'test_ptr_struct_arg': failed to attach: ERROR: strerror_r(-524)=22 libbpf: prog 'test_ptr_struct_arg': failed to auto-attach: -524 test_map_val_and_probed_memory:FAIL:test_ldsx_insn__attach unexpected error: -524 (errno 524) torvalds#116/1 ldsx_insn/map_val and probed_memory:FAIL torvalds#116 ldsx_insn:FAIL Summary: 0/2 PASSED, 0 SKIPPED, 1 FAILED Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
borkmann
added a commit
to cilium/linux
that referenced
this pull request
May 23, 2024
# ./vmtest.sh -- ./test_progs -t netkit [...] ./test_progs -t netkit [ 1.140780] bpf_testmod: loading out-of-tree module taints kernel. [ 1.141127] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel [ 1.284601] tsc: Refined TSC clocksource calibration: 3408.006 MHz [ 1.286672] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x311fd9b189d, max_idle_ns: 440795225691 ns [ 1.290384] clocksource: Switched to clocksource tsc torvalds#345 tc_netkit_basic:OK torvalds#346 tc_netkit_device:OK torvalds#347 tc_netkit_multi_links:OK torvalds#348 tc_netkit_multi_opts:OK torvalds#349 tc_netkit_neigh_links:OK torvalds#350 tc_netkit_pkt_type:OK Summary: 6/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
borkmann
added a commit
to cilium/linux
that referenced
this pull request
May 24, 2024
Add a test case to assert that the skb->pkt_type which was set from the BPF program is retained from the netkit xmit side to the peer's device at tcx ingress location. # ./vmtest.sh -- ./test_progs -t netkit [...] ./test_progs -t netkit [ 1.140780] bpf_testmod: loading out-of-tree module taints kernel. [ 1.141127] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel [ 1.284601] tsc: Refined TSC clocksource calibration: 3408.006 MHz [ 1.286672] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x311fd9b189d, max_idle_ns: 440795225691 ns [ 1.290384] clocksource: Switched to clocksource tsc torvalds#345 tc_netkit_basic:OK torvalds#346 tc_netkit_device:OK torvalds#347 tc_netkit_multi_links:OK torvalds#348 tc_netkit_multi_opts:OK torvalds#349 tc_netkit_neigh_links:OK torvalds#350 tc_netkit_pkt_type:OK Summary: 6/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
borkmann
added a commit
to cilium/linux
that referenced
this pull request
May 24, 2024
Add a test case to assert that the skb->pkt_type which was set from the BPF program is retained from the netkit xmit side to the peer's device at tcx ingress location. # ./vmtest.sh -- ./test_progs -t netkit [...] ./test_progs -t netkit [ 1.140780] bpf_testmod: loading out-of-tree module taints kernel. [ 1.141127] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel [ 1.284601] tsc: Refined TSC clocksource calibration: 3408.006 MHz [ 1.286672] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x311fd9b189d, max_idle_ns: 440795225691 ns [ 1.290384] clocksource: Switched to clocksource tsc torvalds#345 tc_netkit_basic:OK torvalds#346 tc_netkit_device:OK torvalds#347 tc_netkit_multi_links:OK torvalds#348 tc_netkit_multi_opts:OK torvalds#349 tc_netkit_neigh_links:OK torvalds#350 tc_netkit_pkt_type:OK Summary: 6/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
May 24, 2024
Add a test case to assert that the skb->pkt_type which was set from the BPF program is retained from the netkit xmit side to the peer's device at tcx ingress location. # ./vmtest.sh -- ./test_progs -t netkit [...] ./test_progs -t netkit [ 1.140780] bpf_testmod: loading out-of-tree module taints kernel. [ 1.141127] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel [ 1.284601] tsc: Refined TSC clocksource calibration: 3408.006 MHz [ 1.286672] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x311fd9b189d, max_idle_ns: 440795225691 ns [ 1.290384] clocksource: Switched to clocksource tsc torvalds#345 tc_netkit_basic:OK torvalds#346 tc_netkit_device:OK torvalds#347 tc_netkit_multi_links:OK torvalds#348 tc_netkit_multi_opts:OK torvalds#349 tc_netkit_neigh_links:OK torvalds#350 tc_netkit_pkt_type:OK Summary: 6/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
May 26, 2024
Add a test case to assert that the skb->pkt_type which was set from the BPF program is retained from the netkit xmit side to the peer's device at tcx ingress location. # ./vmtest.sh -- ./test_progs -t netkit [...] ./test_progs -t netkit [ 1.140780] bpf_testmod: loading out-of-tree module taints kernel. [ 1.141127] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel [ 1.284601] tsc: Refined TSC clocksource calibration: 3408.006 MHz [ 1.286672] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x311fd9b189d, max_idle_ns: 440795225691 ns [ 1.290384] clocksource: Switched to clocksource tsc torvalds#345 tc_netkit_basic:OK torvalds#346 tc_netkit_device:OK torvalds#347 tc_netkit_multi_links:OK torvalds#348 tc_netkit_multi_opts:OK torvalds#349 tc_netkit_neigh_links:OK torvalds#350 tc_netkit_pkt_type:OK Summary: 6/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/r/20240524163619.26001-4-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov <ast@kernel.org>
adeepn
pushed a commit
to jethome-iot/linux-kernel
that referenced
this pull request
Jun 10, 2024
Add a test case to assert that the skb->pkt_type which was set from the BPF program is retained from the netkit xmit side to the peer's device at tcx ingress location. # ./vmtest.sh -- ./test_progs -t netkit [...] ./test_progs -t netkit [ 1.140780] bpf_testmod: loading out-of-tree module taints kernel. [ 1.141127] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel [ 1.284601] tsc: Refined TSC clocksource calibration: 3408.006 MHz [ 1.286672] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x311fd9b189d, max_idle_ns: 440795225691 ns [ 1.290384] clocksource: Switched to clocksource tsc torvalds#345 tc_netkit_basic:OK torvalds#346 tc_netkit_device:OK torvalds#347 tc_netkit_multi_links:OK torvalds#348 tc_netkit_multi_opts:OK torvalds#349 tc_netkit_neigh_links:OK torvalds#350 tc_netkit_pkt_type:OK Summary: 6/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/r/20240524163619.26001-4-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov <ast@kernel.org>
shipujin
pushed a commit
to shipujin/linux
that referenced
this pull request
Jul 24, 2024
Enable the cpu v4 tests for LoongArch. Currently, we don't have BPF trampoline in LoongArch JIT, so the fentry test `test_ptr_struct_arg` still failed, will followup. Test result attached below: # ./test_progs -t verifier_sdiv,verifier_movsx,verifier_ldsx,verifier_gotol,verifier_bswap torvalds#316/1 verifier_bswap/BSWAP, 16:OK torvalds#316/2 verifier_bswap/BSWAP, 16 @unpriv:OK torvalds#316/3 verifier_bswap/BSWAP, 32:OK torvalds#316/4 verifier_bswap/BSWAP, 32 @unpriv:OK torvalds#316/5 verifier_bswap/BSWAP, 64:OK torvalds#316/6 verifier_bswap/BSWAP, 64 @unpriv:OK torvalds#316 verifier_bswap:OK torvalds#330/1 verifier_gotol/gotol, small_imm:OK torvalds#330/2 verifier_gotol/gotol, small_imm @unpriv:OK torvalds#330 verifier_gotol:OK torvalds#338/1 verifier_ldsx/LDSX, S8:OK torvalds#338/2 verifier_ldsx/LDSX, S8 @unpriv:OK torvalds#338/3 verifier_ldsx/LDSX, S16:OK torvalds#338/4 verifier_ldsx/LDSX, S16 @unpriv:OK torvalds#338/5 verifier_ldsx/LDSX, S32:OK torvalds#338/6 verifier_ldsx/LDSX, S32 @unpriv:OK torvalds#338/7 verifier_ldsx/LDSX, S8 range checking, privileged:OK torvalds#338/8 verifier_ldsx/LDSX, S16 range checking:OK torvalds#338/9 verifier_ldsx/LDSX, S16 range checking @unpriv:OK torvalds#338/10 verifier_ldsx/LDSX, S32 range checking:OK torvalds#338/11 verifier_ldsx/LDSX, S32 range checking @unpriv:OK torvalds#338 verifier_ldsx:OK torvalds#349/1 verifier_movsx/MOV32SX, S8:OK torvalds#349/2 verifier_movsx/MOV32SX, S8 @unpriv:OK torvalds#349/3 verifier_movsx/MOV32SX, S16:OK torvalds#349/4 verifier_movsx/MOV32SX, S16 @unpriv:OK torvalds#349/5 verifier_movsx/MOV64SX, S8:OK torvalds#349/6 verifier_movsx/MOV64SX, S8 @unpriv:OK torvalds#349/7 verifier_movsx/MOV64SX, S16:OK torvalds#349/8 verifier_movsx/MOV64SX, S16 @unpriv:OK torvalds#349/9 verifier_movsx/MOV64SX, S32:OK torvalds#349/10 verifier_movsx/MOV64SX, S32 @unpriv:OK torvalds#349/11 verifier_movsx/MOV32SX, S8, range_check:OK torvalds#349/12 verifier_movsx/MOV32SX, S8, range_check @unpriv:OK torvalds#349/13 verifier_movsx/MOV32SX, S16, range_check:OK torvalds#349/14 verifier_movsx/MOV32SX, S16, range_check @unpriv:OK torvalds#349/15 verifier_movsx/MOV32SX, S16, range_check 2:OK torvalds#349/16 verifier_movsx/MOV32SX, S16, range_check 2 @unpriv:OK torvalds#349/17 verifier_movsx/MOV64SX, S8, range_check:OK torvalds#349/18 verifier_movsx/MOV64SX, S8, range_check @unpriv:OK torvalds#349/19 verifier_movsx/MOV64SX, S16, range_check:OK torvalds#349/20 verifier_movsx/MOV64SX, S16, range_check @unpriv:OK torvalds#349/21 verifier_movsx/MOV64SX, S32, range_check:OK torvalds#349/22 verifier_movsx/MOV64SX, S32, range_check @unpriv:OK torvalds#349/23 verifier_movsx/MOV64SX, S16, R10 Sign Extension:OK torvalds#349/24 verifier_movsx/MOV64SX, S16, R10 Sign Extension @unpriv:OK torvalds#349 verifier_movsx:OK torvalds#361/1 verifier_sdiv/SDIV32, non-zero imm divisor, check 1:OK torvalds#361/2 verifier_sdiv/SDIV32, non-zero imm divisor, check 1 @unpriv:OK torvalds#361/3 verifier_sdiv/SDIV32, non-zero imm divisor, check 2:OK torvalds#361/4 verifier_sdiv/SDIV32, non-zero imm divisor, check 2 @unpriv:OK torvalds#361/5 verifier_sdiv/SDIV32, non-zero imm divisor, check 3:OK torvalds#361/6 verifier_sdiv/SDIV32, non-zero imm divisor, check 3 @unpriv:OK torvalds#361/7 verifier_sdiv/SDIV32, non-zero imm divisor, check 4:OK torvalds#361/8 verifier_sdiv/SDIV32, non-zero imm divisor, check 4 @unpriv:OK torvalds#361/9 verifier_sdiv/SDIV32, non-zero imm divisor, check 5:OK torvalds#361/10 verifier_sdiv/SDIV32, non-zero imm divisor, check 5 @unpriv:OK torvalds#361/11 verifier_sdiv/SDIV32, non-zero imm divisor, check 6:OK torvalds#361/12 verifier_sdiv/SDIV32, non-zero imm divisor, check 6 @unpriv:OK torvalds#361/13 verifier_sdiv/SDIV32, non-zero imm divisor, check 7:OK torvalds#361/14 verifier_sdiv/SDIV32, non-zero imm divisor, check 7 @unpriv:OK torvalds#361/15 verifier_sdiv/SDIV32, non-zero imm divisor, check 8:OK torvalds#361/16 verifier_sdiv/SDIV32, non-zero imm divisor, check 8 @unpriv:OK torvalds#361/17 verifier_sdiv/SDIV32, non-zero reg divisor, check 1:OK torvalds#361/18 verifier_sdiv/SDIV32, non-zero reg divisor, check 1 @unpriv:OK torvalds#361/19 verifier_sdiv/SDIV32, non-zero reg divisor, check 2:OK torvalds#361/20 verifier_sdiv/SDIV32, non-zero reg divisor, check 2 @unpriv:OK torvalds#361/21 verifier_sdiv/SDIV32, non-zero reg divisor, check 3:OK torvalds#361/22 verifier_sdiv/SDIV32, non-zero reg divisor, check 3 @unpriv:OK torvalds#361/23 verifier_sdiv/SDIV32, non-zero reg divisor, check 4:OK torvalds#361/24 verifier_sdiv/SDIV32, non-zero reg divisor, check 4 @unpriv:OK torvalds#361/25 verifier_sdiv/SDIV32, non-zero reg divisor, check 5:OK torvalds#361/26 verifier_sdiv/SDIV32, non-zero reg divisor, check 5 @unpriv:OK torvalds#361/27 verifier_sdiv/SDIV32, non-zero reg divisor, check 6:OK torvalds#361/28 verifier_sdiv/SDIV32, non-zero reg divisor, check 6 @unpriv:OK torvalds#361/29 verifier_sdiv/SDIV32, non-zero reg divisor, check 7:OK torvalds#361/30 verifier_sdiv/SDIV32, non-zero reg divisor, check 7 @unpriv:OK torvalds#361/31 verifier_sdiv/SDIV32, non-zero reg divisor, check 8:OK torvalds#361/32 verifier_sdiv/SDIV32, non-zero reg divisor, check 8 @unpriv:OK torvalds#361/33 verifier_sdiv/SDIV64, non-zero imm divisor, check 1:OK torvalds#361/34 verifier_sdiv/SDIV64, non-zero imm divisor, check 1 @unpriv:OK torvalds#361/35 verifier_sdiv/SDIV64, non-zero imm divisor, check 2:OK torvalds#361/36 verifier_sdiv/SDIV64, non-zero imm divisor, check 2 @unpriv:OK torvalds#361/37 verifier_sdiv/SDIV64, non-zero imm divisor, check 3:OK torvalds#361/38 verifier_sdiv/SDIV64, non-zero imm divisor, check 3 @unpriv:OK torvalds#361/39 verifier_sdiv/SDIV64, non-zero imm divisor, check 4:OK torvalds#361/40 verifier_sdiv/SDIV64, non-zero imm divisor, check 4 @unpriv:OK torvalds#361/41 verifier_sdiv/SDIV64, non-zero imm divisor, check 5:OK torvalds#361/42 verifier_sdiv/SDIV64, non-zero imm divisor, check 5 @unpriv:OK torvalds#361/43 verifier_sdiv/SDIV64, non-zero imm divisor, check 6:OK torvalds#361/44 verifier_sdiv/SDIV64, non-zero imm divisor, check 6 @unpriv:OK torvalds#361/45 verifier_sdiv/SDIV64, non-zero reg divisor, check 1:OK torvalds#361/46 verifier_sdiv/SDIV64, non-zero reg divisor, check 1 @unpriv:OK torvalds#361/47 verifier_sdiv/SDIV64, non-zero reg divisor, check 2:OK torvalds#361/48 verifier_sdiv/SDIV64, non-zero reg divisor, check 2 @unpriv:OK torvalds#361/49 verifier_sdiv/SDIV64, non-zero reg divisor, check 3:OK torvalds#361/50 verifier_sdiv/SDIV64, non-zero reg divisor, check 3 @unpriv:OK torvalds#361/51 verifier_sdiv/SDIV64, non-zero reg divisor, check 4:OK torvalds#361/52 verifier_sdiv/SDIV64, non-zero reg divisor, check 4 @unpriv:OK torvalds#361/53 verifier_sdiv/SDIV64, non-zero reg divisor, check 5:OK torvalds#361/54 verifier_sdiv/SDIV64, non-zero reg divisor, check 5 @unpriv:OK torvalds#361/55 verifier_sdiv/SDIV64, non-zero reg divisor, check 6:OK torvalds#361/56 verifier_sdiv/SDIV64, non-zero reg divisor, check 6 @unpriv:OK torvalds#361/57 verifier_sdiv/SMOD32, non-zero imm divisor, check 1:OK torvalds#361/58 verifier_sdiv/SMOD32, non-zero imm divisor, check 1 @unpriv:OK torvalds#361/59 verifier_sdiv/SMOD32, non-zero imm divisor, check 2:OK torvalds#361/60 verifier_sdiv/SMOD32, non-zero imm divisor, check 2 @unpriv:OK torvalds#361/61 verifier_sdiv/SMOD32, non-zero imm divisor, check 3:OK torvalds#361/62 verifier_sdiv/SMOD32, non-zero imm divisor, check 3 @unpriv:OK torvalds#361/63 verifier_sdiv/SMOD32, non-zero imm divisor, check 4:OK torvalds#361/64 verifier_sdiv/SMOD32, non-zero imm divisor, check 4 @unpriv:OK torvalds#361/65 verifier_sdiv/SMOD32, non-zero imm divisor, check 5:OK torvalds#361/66 verifier_sdiv/SMOD32, non-zero imm divisor, check 5 @unpriv:OK torvalds#361/67 verifier_sdiv/SMOD32, non-zero imm divisor, check 6:OK torvalds#361/68 verifier_sdiv/SMOD32, non-zero imm divisor, check 6 @unpriv:OK torvalds#361/69 verifier_sdiv/SMOD32, non-zero reg divisor, check 1:OK torvalds#361/70 verifier_sdiv/SMOD32, non-zero reg divisor, check 1 @unpriv:OK torvalds#361/71 verifier_sdiv/SMOD32, non-zero reg divisor, check 2:OK torvalds#361/72 verifier_sdiv/SMOD32, non-zero reg divisor, check 2 @unpriv:OK torvalds#361/73 verifier_sdiv/SMOD32, non-zero reg divisor, check 3:OK torvalds#361/74 verifier_sdiv/SMOD32, non-zero reg divisor, check 3 @unpriv:OK torvalds#361/75 verifier_sdiv/SMOD32, non-zero reg divisor, check 4:OK torvalds#361/76 verifier_sdiv/SMOD32, non-zero reg divisor, check 4 @unpriv:OK torvalds#361/77 verifier_sdiv/SMOD32, non-zero reg divisor, check 5:OK torvalds#361/78 verifier_sdiv/SMOD32, non-zero reg divisor, check 5 @unpriv:OK torvalds#361/79 verifier_sdiv/SMOD32, non-zero reg divisor, check 6:OK torvalds#361/80 verifier_sdiv/SMOD32, non-zero reg divisor, check 6 @unpriv:OK torvalds#361/81 verifier_sdiv/SMOD64, non-zero imm divisor, check 1:OK torvalds#361/82 verifier_sdiv/SMOD64, non-zero imm divisor, check 1 @unpriv:OK torvalds#361/83 verifier_sdiv/SMOD64, non-zero imm divisor, check 2:OK torvalds#361/84 verifier_sdiv/SMOD64, non-zero imm divisor, check 2 @unpriv:OK torvalds#361/85 verifier_sdiv/SMOD64, non-zero imm divisor, check 3:OK torvalds#361/86 verifier_sdiv/SMOD64, non-zero imm divisor, check 3 @unpriv:OK torvalds#361/87 verifier_sdiv/SMOD64, non-zero imm divisor, check 4:OK torvalds#361/88 verifier_sdiv/SMOD64, non-zero imm divisor, check 4 @unpriv:OK torvalds#361/89 verifier_sdiv/SMOD64, non-zero imm divisor, check 5:OK torvalds#361/90 verifier_sdiv/SMOD64, non-zero imm divisor, check 5 @unpriv:OK torvalds#361/91 verifier_sdiv/SMOD64, non-zero imm divisor, check 6:OK torvalds#361/92 verifier_sdiv/SMOD64, non-zero imm divisor, check 6 @unpriv:OK torvalds#361/93 verifier_sdiv/SMOD64, non-zero imm divisor, check 7:OK torvalds#361/94 verifier_sdiv/SMOD64, non-zero imm divisor, check 7 @unpriv:OK torvalds#361/95 verifier_sdiv/SMOD64, non-zero imm divisor, check 8:OK torvalds#361/96 verifier_sdiv/SMOD64, non-zero imm divisor, check 8 @unpriv:OK torvalds#361/97 verifier_sdiv/SMOD64, non-zero reg divisor, check 1:OK torvalds#361/98 verifier_sdiv/SMOD64, non-zero reg divisor, check 1 @unpriv:OK torvalds#361/99 verifier_sdiv/SMOD64, non-zero reg divisor, check 2:OK torvalds#361/100 verifier_sdiv/SMOD64, non-zero reg divisor, check 2 @unpriv:OK torvalds#361/101 verifier_sdiv/SMOD64, non-zero reg divisor, check 3:OK torvalds#361/102 verifier_sdiv/SMOD64, non-zero reg divisor, check 3 @unpriv:OK torvalds#361/103 verifier_sdiv/SMOD64, non-zero reg divisor, check 4:OK torvalds#361/104 verifier_sdiv/SMOD64, non-zero reg divisor, check 4 @unpriv:OK torvalds#361/105 verifier_sdiv/SMOD64, non-zero reg divisor, check 5:OK torvalds#361/106 verifier_sdiv/SMOD64, non-zero reg divisor, check 5 @unpriv:OK torvalds#361/107 verifier_sdiv/SMOD64, non-zero reg divisor, check 6:OK torvalds#361/108 verifier_sdiv/SMOD64, non-zero reg divisor, check 6 @unpriv:OK torvalds#361/109 verifier_sdiv/SMOD64, non-zero reg divisor, check 7:OK torvalds#361/110 verifier_sdiv/SMOD64, non-zero reg divisor, check 7 @unpriv:OK torvalds#361/111 verifier_sdiv/SMOD64, non-zero reg divisor, check 8:OK torvalds#361/112 verifier_sdiv/SMOD64, non-zero reg divisor, check 8 @unpriv:OK torvalds#361/113 verifier_sdiv/SDIV32, zero divisor:OK torvalds#361/114 verifier_sdiv/SDIV32, zero divisor @unpriv:OK torvalds#361/115 verifier_sdiv/SDIV64, zero divisor:OK torvalds#361/116 verifier_sdiv/SDIV64, zero divisor @unpriv:OK torvalds#361/117 verifier_sdiv/SMOD32, zero divisor:OK torvalds#361/118 verifier_sdiv/SMOD32, zero divisor @unpriv:OK torvalds#361/119 verifier_sdiv/SMOD64, zero divisor:OK torvalds#361/120 verifier_sdiv/SMOD64, zero divisor @unpriv:OK torvalds#361 verifier_sdiv:OK Summary: 5/163 PASSED, 0 SKIPPED, 0 FAILED # ./test_progs -t ldsx_insn test_map_val_and_probed_memory:PASS:test_ldsx_insn__open 0 nsec test_map_val_and_probed_memory:PASS:test_ldsx_insn__load 0 nsec libbpf: prog 'test_ptr_struct_arg': failed to attach: ERROR: strerror_r(-524)=22 libbpf: prog 'test_ptr_struct_arg': failed to auto-attach: -524 test_map_val_and_probed_memory:FAIL:test_ldsx_insn__attach unexpected error: -524 (errno 524) torvalds#116/1 ldsx_insn/map_val and probed_memory:FAIL torvalds#116/2 ldsx_insn/ctx_member_sign_ext:OK torvalds#116/3 ldsx_insn/ctx_member_narrow_sign_ext:OK torvalds#116 ldsx_insn:FAIL All error logs: test_map_val_and_probed_memory:PASS:test_ldsx_insn__open 0 nsec test_map_val_and_probed_memory:PASS:test_ldsx_insn__load 0 nsec libbpf: prog 'test_ptr_struct_arg': failed to attach: ERROR: strerror_r(-524)=22 libbpf: prog 'test_ptr_struct_arg': failed to auto-attach: -524 test_map_val_and_probed_memory:FAIL:test_ldsx_insn__attach unexpected error: -524 (errno 524) torvalds#116/1 ldsx_insn/map_val and probed_memory:FAIL torvalds#116 ldsx_insn:FAIL Summary: 0/2 PASSED, 0 SKIPPED, 1 FAILED Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.