fs: ext4_mballoc_test: Internal error: Oops: map_id_range_down (kernel/user_namespace.c:318)
Kunit ext4_mballoc_test tests found following kernel oops on Linux next. All ways reproducible on all the architectures and steps to reproduce shared in the bottom of this email.
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Test log: --------- <6>[ 14.297909] KTAP version 1 <6>[ 14.298306] # Subtest: ext4_mballoc_test <6>[ 14.299114] # module: ext4 <6>[ 14.300048] 1..6 <6>[ 14.301204] KTAP version 1 <6>[ 14.301853] # Subtest: test_new_blocks_simple <1>[ 14.308203] Unable to handle kernel paging request at virtual address dfff800000000000 <1>[ 14.309700] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] <1>[ 14.310671] Mem abort info: <1>[ 14.311141] ESR = 0x0000000096000004 <1>[ 14.312969] EC = 0x25: DABT (current EL), IL = 32 bits <1>[ 14.313566] SET = 0, FnV = 0 <1>[ 14.314228] EA = 0, S1PTW = 0 <1>[ 14.314750] FSC = 0x04: level 0 translation fault <1>[ 14.316382] Data abort info: <1>[ 14.316838] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 <1>[ 14.317742] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 <1>[ 14.318637] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 <1>[ 14.319975] [dfff800000000000] address between user and kernel address ranges <0>[ 14.322307] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP <4>[ 14.324184] Modules linked in: <4>[ 14.326693] CPU: 1 PID: 104 Comm: kunit_try_catch Tainted: G N 6.8.0-rc6-next-20240228 #1 <4>[ 14.327913] Hardware name: linux,dummy-virt (DT) <4>[ 14.329173] pstate: 11400009 (nzcV daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) <4>[ 14.330117] pc : map_id_range_down (kernel/user_namespace.c:318) <4>[ 14.331618] lr : make_kuid (kernel/user_namespace.c:415) <trim> <4>[ 14.344145] Call trace: <4>[ 14.344565] map_id_range_down (kernel/user_namespace.c:318) <4>[ 14.345378] make_kuid (kernel/user_namespace.c:415) <4>[ 14.345998] inode_init_always (include/linux/fs.h:1375 fs/inode.c:174) <4>[ 14.346696] alloc_inode (fs/inode.c:268) <4>[ 14.347353] new_inode_pseudo (fs/inode.c:1007) <4>[ 14.348016] new_inode (fs/inode.c:1033) <4>[ 14.348644] ext4_mb_init (fs/ext4/mballoc.c:3404 fs/ext4/mballoc.c:3719) <4>[ 14.349312] mbt_kunit_init (fs/ext4/mballoc-test.c:57 fs/ext4/mballoc-test.c:314) <4>[ 14.349983] kunit_try_run_case (lib/kunit/test.c:388 lib/kunit/test.c:443) <4>[ 14.350696] kunit_generic_run_threadfn_adapter (lib/kunit/try-catch.c:30) <4>[ 14.351530] kthread (kernel/kthread.c:388) <4>[ 14.352168] ret_from_fork (arch/arm64/kernel/entry.S:861) <0>[ 14.353385] Code: 52808004 b8236ae7 72be5e44 b90004c4 (38e368a1) All code ======== 0: 52808004 mov w4, #0x400 // #1024 4: b8236ae7 str w7, [x23, x3] 8: 72be5e44 movk w4, #0xf2f2, lsl #16 c: b90004c4 str w4, [x6, #4] 10:* 38e368a1 ldrsb w1, [x5, x3] <-- trapping instruction
Code starting with the faulting instruction =========================================== 0: 38e368a1 ldrsb w1, [x5, x3] <4>[ 14.354545] ---[ end trace 0000000000000000 ]---
Links: - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20240228/tes... - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20240228/tes... - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20240228/tes...
Steps to reproduce: - https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/2czN4PCDk4B...
-- Linaro LKFT https://lkft.linaro.org
Hello!
On Wed, 28 Feb 2024 at 12:19, Naresh Kamboju naresh.kamboju@linaro.org wrote:
Kunit ext4_mballoc_test tests found following kernel oops on Linux next. All ways reproducible on all the architectures and steps to reproduce shared in the bottom of this email.
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Test log:
<6>[ 14.297909] KTAP version 1 <6>[ 14.298306] # Subtest: ext4_mballoc_test <6>[ 14.299114] # module: ext4 <6>[ 14.300048] 1..6 <6>[ 14.301204] KTAP version 1 <6>[ 14.301853] # Subtest: test_new_blocks_simple <1>[ 14.308203] Unable to handle kernel paging request at virtual address dfff800000000000 <1>[ 14.309700] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] <1>[ 14.310671] Mem abort info: <1>[ 14.311141] ESR = 0x0000000096000004 <1>[ 14.312969] EC = 0x25: DABT (current EL), IL = 32 bits <1>[ 14.313566] SET = 0, FnV = 0 <1>[ 14.314228] EA = 0, S1PTW = 0 <1>[ 14.314750] FSC = 0x04: level 0 translation fault <1>[ 14.316382] Data abort info: <1>[ 14.316838] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 <1>[ 14.317742] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 <1>[ 14.318637] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 <1>[ 14.319975] [dfff800000000000] address between user and kernel address ranges <0>[ 14.322307] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP <4>[ 14.324184] Modules linked in: <4>[ 14.326693] CPU: 1 PID: 104 Comm: kunit_try_catch Tainted: G N 6.8.0-rc6-next-20240228 #1 <4>[ 14.327913] Hardware name: linux,dummy-virt (DT) <4>[ 14.329173] pstate: 11400009 (nzcV daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) <4>[ 14.330117] pc : map_id_range_down (kernel/user_namespace.c:318) <4>[ 14.331618] lr : make_kuid (kernel/user_namespace.c:415)
<trim> <4>[ 14.344145] Call trace: <4>[ 14.344565] map_id_range_down (kernel/user_namespace.c:318) <4>[ 14.345378] make_kuid (kernel/user_namespace.c:415) <4>[ 14.345998] inode_init_always (include/linux/fs.h:1375 fs/inode.c:174) <4>[ 14.346696] alloc_inode (fs/inode.c:268) <4>[ 14.347353] new_inode_pseudo (fs/inode.c:1007) <4>[ 14.348016] new_inode (fs/inode.c:1033) <4>[ 14.348644] ext4_mb_init (fs/ext4/mballoc.c:3404 fs/ext4/mballoc.c:3719) <4>[ 14.349312] mbt_kunit_init (fs/ext4/mballoc-test.c:57 fs/ext4/mballoc-test.c:314) <4>[ 14.349983] kunit_try_run_case (lib/kunit/test.c:388 lib/kunit/test.c:443) <4>[ 14.350696] kunit_generic_run_threadfn_adapter (lib/kunit/try-catch.c:30) <4>[ 14.351530] kthread (kernel/kthread.c:388) <4>[ 14.352168] ret_from_fork (arch/arm64/kernel/entry.S:861) <0>[ 14.353385] Code: 52808004 b8236ae7 72be5e44 b90004c4 (38e368a1) All code ======== 0: 52808004 mov w4, #0x400 // #1024 4: b8236ae7 str w7, [x23, x3] 8: 72be5e44 movk w4, #0xf2f2, lsl #16 c: b90004c4 str w4, [x6, #4] 10:* 38e368a1 ldrsb w1, [x5, x3] <-- trapping instruction
Code starting with the faulting instruction
0: 38e368a1 ldrsb w1, [x5, x3] <4>[ 14.354545] ---[ end trace 0000000000000000 ]---
Links:
- https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20240228/tes...
- https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20240228/tes...
- https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20240228/tes...
Steps to reproduce:
+Guenter. Just the thing we were talking about, at about the same time.
Greetings!
Daniel Díaz daniel.diaz@linaro.org
On 2/28/24 11:26, Daniel Díaz wrote:
Hello!
On Wed, 28 Feb 2024 at 12:19, Naresh Kamboju naresh.kamboju@linaro.org wrote:
Kunit ext4_mballoc_test tests found following kernel oops on Linux next. All ways reproducible on all the architectures and steps to reproduce shared in the bottom of this email.
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
[ ... ]
+Guenter. Just the thing we were talking about, at about the same time.
Good that others see the same problem. Thanks a lot for reporting!
Guenter
On Wed, Feb 28, 2024 at 11:33:36AM -0800, Guenter Roeck wrote:
On 2/28/24 11:26, Daniel Díaz wrote:
Hello!
On Wed, 28 Feb 2024 at 12:19, Naresh Kamboju naresh.kamboju@linaro.org wrote:
Kunit ext4_mballoc_test tests found following kernel oops on Linux next. All ways reproducible on all the architectures and steps to reproduce shared in the bottom of this email.
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
[ ... ]
+Guenter. Just the thing we were talking about, at about the same time.
Good that others see the same problem. Thanks a lot for reporting!
Hm...
static struct super_block *mbt_ext4_alloc_super_block(void) { struct ext4_super_block *es = kzalloc(sizeof(*es), GFP_KERNEL); struct ext4_sb_info *sbi = kzalloc(sizeof(*sbi), GFP_KERNEL); struct mbt_ext4_super_block *fsb = kzalloc(sizeof(*fsb), GFP_KERNEL);
if (fsb == NULL || sbi == NULL || es == NULL) goto out;
sbi->s_es = es; fsb->sb.s_fs_info = sbi; return &fsb->sb;
out: kfree(fsb); kfree(sbi); kfree(es); return NULL; }
That VFS level struct super_block that is returned from this function is never really initialized afaict? Therefore, sb->s_user_ns == NULL:
i_uid_write(sb, ...) -> NULL = i_user_ns(sb) -> make_kuid(NULL) -> map_id_range_down(NULL)
Outside of this test this can never be the case. See alloc_super() in fs/super.c. So to stop the bleeding this needs something like:
static struct super_block *mbt_ext4_alloc_super_block(void) { struct ext4_super_block *es = kzalloc(sizeof(*es), GFP_KERNEL); struct ext4_sb_info *sbi = kzalloc(sizeof(*sbi), GFP_KERNEL); struct mbt_ext4_super_block *fsb = kzalloc(sizeof(*fsb), GFP_KERNEL);
if (fsb == NULL || sbi == NULL || es == NULL) goto out;
sbi->s_es = es; fsb->sb.s_fs_info = sbi; + fsb.sb.s_user_ns = &init_user_ns; return &fsb->sb;
out: kfree(fsb); kfree(sbi); kfree(es); return NULL; }
on 2/29/2024 6:09 PM, Christian Brauner wrote:
On Wed, Feb 28, 2024 at 11:33:36AM -0800, Guenter Roeck wrote:
On 2/28/24 11:26, Daniel Díaz wrote:
Hello!
On Wed, 28 Feb 2024 at 12:19, Naresh Kamboju naresh.kamboju@linaro.org wrote:
Kunit ext4_mballoc_test tests found following kernel oops on Linux next. All ways reproducible on all the architectures and steps to reproduce shared in the bottom of this email.
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
[ ... ]
+Guenter. Just the thing we were talking about, at about the same time.
Good that others see the same problem. Thanks a lot for reporting!
Hm...
static struct super_block *mbt_ext4_alloc_super_block(void) { struct ext4_super_block *es = kzalloc(sizeof(*es), GFP_KERNEL); struct ext4_sb_info *sbi = kzalloc(sizeof(*sbi), GFP_KERNEL); struct mbt_ext4_super_block *fsb = kzalloc(sizeof(*fsb), GFP_KERNEL);
if (fsb == NULL || sbi == NULL || es == NULL) goto out; sbi->s_es = es; fsb->sb.s_fs_info = sbi; return &fsb->sb;out: kfree(fsb); kfree(sbi); kfree(es); return NULL; }
That VFS level struct super_block that is returned from this function is never really initialized afaict? Therefore, sb->s_user_ns == NULL:
i_uid_write(sb, ...) -> NULL = i_user_ns(sb) -> make_kuid(NULL) -> map_id_range_down(NULL)
Outside of this test this can never be the case. See alloc_super() in fs/super.c. So to stop the bleeding this needs something like:
static struct super_block *mbt_ext4_alloc_super_block(void) { struct ext4_super_block *es = kzalloc(sizeof(*es), GFP_KERNEL); struct ext4_sb_info *sbi = kzalloc(sizeof(*sbi), GFP_KERNEL); struct mbt_ext4_super_block *fsb = kzalloc(sizeof(*fsb), GFP_KERNEL);
if (fsb == NULL || sbi == NULL || es == NULL) goto out; sbi->s_es = es; fsb->sb.s_fs_info = sbi;
fsb.sb.s_user_ns = &init_user_ns; return &fsb->sb;out: kfree(fsb); kfree(sbi); kfree(es); return NULL; }
Hi Christian, Thanks for the information. I'm looking at this too and I also found root cause is sb.s_user_ns is NULL. I'm considering to get a super_block with VFS level api sget_fc to fix this to avoid similar problem when new unit tests are added or new member is added to super_block. Would like to hear more from you. Thanks!
on 2/29/2024 3:33 AM, Guenter Roeck wrote:
On 2/28/24 11:26, Daniel Díaz wrote:
Hello!
On Wed, 28 Feb 2024 at 12:19, Naresh Kamboju naresh.kamboju@linaro.org wrote:
Kunit ext4_mballoc_test tests found following kernel oops on Linux next. All ways reproducible on all the architectures and steps to reproduce shared in the bottom of this email.
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
[ ... ]
+Guenter. Just the thing we were talking about, at about the same time.
Good that others see the same problem. Thanks a lot for reporting!
Guenter
Hi everyone, thanks for the report. I try to fix the reported issues with [1] which works fine in my vm. Of course, it needs more interview before being applied. Please let me if it works fine in case anyone have interest to test it in advance. Thanks!
Kemeng
[1] https://lore.kernel.org/linux-ext4/20240301120816.22581-1-shikemeng@huaweicl...
-
Christian Brauner -
Daniel Díaz -
Guenter Roeck -
Kemeng Shi -
Naresh Kamboju