* [syzbot] Monthly lsm report (Sep 2024)
@ 2024-09-23 9:02 syzbot
2024-09-23 12:06 ` Paul Moore
0 siblings, 1 reply; 12+ messages in thread
From: syzbot @ 2024-09-23 9:02 UTC (permalink / raw)
To: linux-kernel, linux-security-module, syzkaller-bugs
Hello lsm maintainers/developers,
This is a 31-day syzbot report for the lsm subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/lsm
During the period, 0 new issues were detected and 0 were fixed.
In total, 4 issues are still open and 27 have been fixed so far.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 306 No INFO: task hung in process_measurement (2)
https://syzkaller.appspot.com/bug?extid=1de5a37cb85a2d536330
<2> 9 No general protection fault in smack_inode_permission
https://syzkaller.appspot.com/bug?extid=4ac565a7081cc43bb185
<3> 3 Yes WARNING in current_check_refer_path
https://syzkaller.appspot.com/bug?extid=34b68f850391452207df
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [syzbot] Monthly lsm report (Sep 2024)
2024-09-23 9:02 [syzbot] Monthly lsm report (Sep 2024) syzbot
@ 2024-09-23 12:06 ` Paul Moore
2024-09-23 16:15 ` Casey Schaufler
2024-09-24 11:53 ` Roberto Sassu
0 siblings, 2 replies; 12+ messages in thread
From: Paul Moore @ 2024-09-23 12:06 UTC (permalink / raw)
To: Mimi Zohar, Roberto Sassu, Casey Schaufler, syzbot
Cc: linux-kernel, linux-security-module, syzkaller-bugs
On Mon, Sep 23, 2024 at 5:02 AM syzbot
<syzbot+listfc277c7cb94932601d96@syzkaller.appspotmail.com> wrote:
>
> Hello lsm maintainers/developers,
>
> This is a 31-day syzbot report for the lsm subsystem.
> All related reports/information can be found at:
> https://syzkaller.appspot.com/upstream/s/lsm
>
> During the period, 0 new issues were detected and 0 were fixed.
> In total, 4 issues are still open and 27 have been fixed so far.
>
> Some of the still happening issues:
>
> Ref Crashes Repro Title
> <1> 306 No INFO: task hung in process_measurement (2)
> https://syzkaller.appspot.com/bug?extid=1de5a37cb85a2d536330
Mimi, Roberto,
Any chance this is this related in any way to this report:
https://lore.kernel.org/linux-security-module/CALAgD-4hkHVcCq2ycdwnA2hYDBMqijLUOfZgvf1WfFpU-8+42w@mail.gmail.com/
Looking at the syzkaller dashboard for this issue, it looks like it
may have been present for some time, just difficult to reproduce
reliably (although it does appear to be occurring more often
recently). Any ideas about a root cause?
> <2> 9 No general protection fault in smack_inode_permission
> https://syzkaller.appspot.com/bug?extid=4ac565a7081cc43bb185
Casey?
> <3> 3 Yes WARNING in current_check_refer_path
> https://syzkaller.appspot.com/bug?extid=34b68f850391452207df
Based on the discussion over the summer I believe the consensus was
that this is a bcachefs/VFS bug, reassigning to bcachefs (or trying to
anyway).
https://lore.kernel.org/all/000000000000a65b35061cffca61@google.com/
--
paul-moore.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [syzbot] Monthly lsm report (Sep 2024)
2024-09-23 12:06 ` Paul Moore
@ 2024-09-23 16:15 ` Casey Schaufler
2024-09-28 0:18 ` Casey Schaufler
2024-09-24 11:53 ` Roberto Sassu
1 sibling, 1 reply; 12+ messages in thread
From: Casey Schaufler @ 2024-09-23 16:15 UTC (permalink / raw)
To: Paul Moore, Mimi Zohar, Roberto Sassu, syzbot
Cc: linux-kernel, linux-security-module, syzkaller-bugs,
Casey Schaufler
On 9/23/2024 5:06 AM, Paul Moore wrote:
> On Mon, Sep 23, 2024 at 5:02 AM syzbot
> <syzbot+listfc277c7cb94932601d96@syzkaller.appspotmail.com> wrote:
>> Hello lsm maintainers/developers,
>>
>> This is a 31-day syzbot report for the lsm subsystem.
>> All related reports/information can be found at:
>> https://syzkaller.appspot.com/upstream/s/lsm
>>
>> During the period, 0 new issues were detected and 0 were fixed.
>> In total, 4 issues are still open and 27 have been fixed so far.
>>
>> Some of the still happening issues:
>>
>> Ref Crashes Repro Title
>> <1> 306 No INFO: task hung in process_measurement (2)
>> https://syzkaller.appspot.com/bug?extid=1de5a37cb85a2d536330
> Mimi, Roberto,
>
> Any chance this is this related in any way to this report:
>
> https://lore.kernel.org/linux-security-module/CALAgD-4hkHVcCq2ycdwnA2hYDBMqijLUOfZgvf1WfFpU-8+42w@mail.gmail.com/
>
> Looking at the syzkaller dashboard for this issue, it looks like it
> may have been present for some time, just difficult to reproduce
> reliably (although it does appear to be occurring more often
> recently). Any ideas about a root cause?
>
>> <2> 9 No general protection fault in smack_inode_permission
>> https://syzkaller.appspot.com/bug?extid=4ac565a7081cc43bb185
> Casey?
Looks like an xattr or mount problem in JFS. I will have a look at it.
>
>> <3> 3 Yes WARNING in current_check_refer_path
>> https://syzkaller.appspot.com/bug?extid=34b68f850391452207df
> Based on the discussion over the summer I believe the consensus was
> that this is a bcachefs/VFS bug, reassigning to bcachefs (or trying to
> anyway).
>
> https://lore.kernel.org/all/000000000000a65b35061cffca61@google.com/
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [syzbot] Monthly lsm report (Sep 2024)
2024-09-23 12:06 ` Paul Moore
2024-09-23 16:15 ` Casey Schaufler
@ 2024-09-24 11:53 ` Roberto Sassu
2024-09-27 12:18 ` Roberto Sassu
1 sibling, 1 reply; 12+ messages in thread
From: Roberto Sassu @ 2024-09-24 11:53 UTC (permalink / raw)
To: Paul Moore, Mimi Zohar, Roberto Sassu, Casey Schaufler, syzbot
Cc: linux-kernel, linux-security-module, syzkaller-bugs
On Mon, 2024-09-23 at 08:06 -0400, Paul Moore wrote:
> On Mon, Sep 23, 2024 at 5:02 AM syzbot
> <syzbot+listfc277c7cb94932601d96@syzkaller.appspotmail.com> wrote:
> >
> > Hello lsm maintainers/developers,
> >
> > This is a 31-day syzbot report for the lsm subsystem.
> > All related reports/information can be found at:
> > https://syzkaller.appspot.com/upstream/s/lsm
> >
> > During the period, 0 new issues were detected and 0 were fixed.
> > In total, 4 issues are still open and 27 have been fixed so far.
> >
> > Some of the still happening issues:
> >
> > Ref Crashes Repro Title
> > <1> 306 No INFO: task hung in process_measurement (2)
> > https://syzkaller.appspot.com/bug?extid=1de5a37cb85a2d536330
>
> Mimi, Roberto,
>
> Any chance this is this related in any way to this report:
>
> https://lore.kernel.org/linux-security-module/CALAgD-4hkHVcCq2ycdwnA2hYDBMqijLUOfZgvf1WfFpU-8+42w@mail.gmail.com/
I reproduced the last, but I got a different result (the kernel crashed
in a different place).
It seems a corruption case, while the former looks more a lock
inversion issue. Will check more.
Roberto
> Looking at the syzkaller dashboard for this issue, it looks like it
> may have been present for some time, just difficult to reproduce
> reliably (although it does appear to be occurring more often
> recently). Any ideas about a root cause?
>
> > <2> 9 No general protection fault in smack_inode_permission
> > https://syzkaller.appspot.com/bug?extid=4ac565a7081cc43bb185
>
> Casey?
>
> > <3> 3 Yes WARNING in current_check_refer_path
> > https://syzkaller.appspot.com/bug?extid=34b68f850391452207df
>
> Based on the discussion over the summer I believe the consensus was
> that this is a bcachefs/VFS bug, reassigning to bcachefs (or trying to
> anyway).
>
> https://lore.kernel.org/all/000000000000a65b35061cffca61@google.com/
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [syzbot] Monthly lsm report (Sep 2024)
2024-09-24 11:53 ` Roberto Sassu
@ 2024-09-27 12:18 ` Roberto Sassu
2024-09-28 0:08 ` Kent Overstreet
0 siblings, 1 reply; 12+ messages in thread
From: Roberto Sassu @ 2024-09-27 12:18 UTC (permalink / raw)
To: Paul Moore, Mimi Zohar, Roberto Sassu, Casey Schaufler, syzbot,
Kent Overstreet
Cc: linux-kernel, linux-security-module, syzkaller-bugs
On Tue, 2024-09-24 at 13:53 +0200, Roberto Sassu wrote:
> On Mon, 2024-09-23 at 08:06 -0400, Paul Moore wrote:
> > On Mon, Sep 23, 2024 at 5:02 AM syzbot
> > <syzbot+listfc277c7cb94932601d96@syzkaller.appspotmail.com> wrote:
> > >
> > > Hello lsm maintainers/developers,
> > >
> > > This is a 31-day syzbot report for the lsm subsystem.
> > > All related reports/information can be found at:
> > > https://syzkaller.appspot.com/upstream/s/lsm
> > >
> > > During the period, 0 new issues were detected and 0 were fixed.
> > > In total, 4 issues are still open and 27 have been fixed so far.
> > >
> > > Some of the still happening issues:
> > >
> > > Ref Crashes Repro Title
> > > <1> 306 No INFO: task hung in process_measurement (2)
> > > https://syzkaller.appspot.com/bug?extid=1de5a37cb85a2d536330
> >
> > Mimi, Roberto,
> >
> > Any chance this is this related in any way to this report:
> >
> > https://lore.kernel.org/linux-security-module/CALAgD-4hkHVcCq2ycdwnA2hYDBMqijLUOfZgvf1WfFpU-8+42w@mail.gmail.com/
>
> I reproduced the last, but I got a different result (the kernel crashed
> in a different place).
>
> It seems a corruption case, while the former looks more a lock
> inversion issue. Will check more.
+ Kent Overstreet
https://syzkaller.appspot.com/bug?extid=1de5a37cb85a2d536330
It happens few times per day, since commit 4a39ac5b7d62 (which is
followed by a lot of merges). The bug has been likely introduced there.
In all recent reports, I noticed that there is always the following
lock sequence:
[ 291.584319][ T30] 5 locks held by syz.0.75/5970:
[ 291.594487][ T30] #0: ffff888064066420 (sb_writers#25){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90
[ 291.603984][ T30] #1: ffff88805d8b0148 (&sb->s_type->i_mutex_key#30){++++}-{3:3}, at: do_truncate+0x20c/0x310
[ 291.614497][ T30] #2: ffff888054700a38 (&c->snapshot_create_lock){.+.+}-{3:3}, at: bch2_truncate+0x16d/0x2c0
[ 291.624871][ T30] #3: ffff888054704398 (&c->btree_trans_barrier){.+.+}-{0:0}, at: __bch2_trans_get+0x7de/0xd20
[ 291.635446][ T30] #4: ffff8880547266d0 (&c->gc_lock){.+.+}-{3:3}, at: bch2_btree_update_start+0x682/0x14e0
IMA is stuck too, since it is waiting for the inode lock to be released:
[ 291.645689][ T30] 1 lock held by syz.0.75/6010:
[ 291.650622][ T30] #0: ffff88805d8b0148 (&sb->s_type->i_mutex_key#30){++++}-{3:3}, at: process_measurement+0x439/0x1fb0
It seems that the super block is locked by someone else, which is not
able to unlock. Maybe, it is related to bch2_journal_reclaim_thread(),
but I don't know for sure.
Kent, do you have time to look at this report?
Thanks!
Roberto
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [syzbot] Monthly lsm report (Sep 2024)
2024-09-27 12:18 ` Roberto Sassu
@ 2024-09-28 0:08 ` Kent Overstreet
2024-09-28 1:25 ` Kent Overstreet
0 siblings, 1 reply; 12+ messages in thread
From: Kent Overstreet @ 2024-09-28 0:08 UTC (permalink / raw)
To: Roberto Sassu
Cc: Paul Moore, Mimi Zohar, Roberto Sassu, Casey Schaufler, syzbot,
linux-kernel, linux-security-module, syzkaller-bugs
On Fri, Sep 27, 2024 at 02:18:10PM GMT, Roberto Sassu wrote:
> On Tue, 2024-09-24 at 13:53 +0200, Roberto Sassu wrote:
> > On Mon, 2024-09-23 at 08:06 -0400, Paul Moore wrote:
> > > On Mon, Sep 23, 2024 at 5:02 AM syzbot
> > > <syzbot+listfc277c7cb94932601d96@syzkaller.appspotmail.com> wrote:
> > > >
> > > > Hello lsm maintainers/developers,
> > > >
> > > > This is a 31-day syzbot report for the lsm subsystem.
> > > > All related reports/information can be found at:
> > > > https://syzkaller.appspot.com/upstream/s/lsm
> > > >
> > > > During the period, 0 new issues were detected and 0 were fixed.
> > > > In total, 4 issues are still open and 27 have been fixed so far.
> > > >
> > > > Some of the still happening issues:
> > > >
> > > > Ref Crashes Repro Title
> > > > <1> 306 No INFO: task hung in process_measurement (2)
> > > > https://syzkaller.appspot.com/bug?extid=1de5a37cb85a2d536330
> > >
> > > Mimi, Roberto,
> > >
> > > Any chance this is this related in any way to this report:
> > >
> > > https://lore.kernel.org/linux-security-module/CALAgD-4hkHVcCq2ycdwnA2hYDBMqijLUOfZgvf1WfFpU-8+42w@mail.gmail.com/
> >
> > I reproduced the last, but I got a different result (the kernel crashed
> > in a different place).
> >
> > It seems a corruption case, while the former looks more a lock
> > inversion issue. Will check more.
>
> + Kent Overstreet
>
> https://syzkaller.appspot.com/bug?extid=1de5a37cb85a2d536330
>
> It happens few times per day, since commit 4a39ac5b7d62 (which is
> followed by a lot of merges). The bug has been likely introduced there.
>
> In all recent reports, I noticed that there is always the following
> lock sequence:
>
> [ 291.584319][ T30] 5 locks held by syz.0.75/5970:
> [ 291.594487][ T30] #0: ffff888064066420 (sb_writers#25){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90
> [ 291.603984][ T30] #1: ffff88805d8b0148 (&sb->s_type->i_mutex_key#30){++++}-{3:3}, at: do_truncate+0x20c/0x310
> [ 291.614497][ T30] #2: ffff888054700a38 (&c->snapshot_create_lock){.+.+}-{3:3}, at: bch2_truncate+0x16d/0x2c0
> [ 291.624871][ T30] #3: ffff888054704398 (&c->btree_trans_barrier){.+.+}-{0:0}, at: __bch2_trans_get+0x7de/0xd20
> [ 291.635446][ T30] #4: ffff8880547266d0 (&c->gc_lock){.+.+}-{3:3}, at: bch2_btree_update_start+0x682/0x14e0
>
> IMA is stuck too, since it is waiting for the inode lock to be released:
>
> [ 291.645689][ T30] 1 lock held by syz.0.75/6010:
> [ 291.650622][ T30] #0: ffff88805d8b0148 (&sb->s_type->i_mutex_key#30){++++}-{3:3}, at: process_measurement+0x439/0x1fb0
>
> It seems that the super block is locked by someone else, which is not
> able to unlock. Maybe, it is related to bch2_journal_reclaim_thread(),
> but I don't know for sure.
>
> Kent, do you have time to look at this report?
If you scroll back in the console log, you see this:
[ 230.372988][ T6772] Allocator stuck? Waited for 30 seconds
[ 230.373025][ T6772] Allocator debug:
[ 230.373039][ T6772] capacity1536
[ 230.373051][ T6772] reserved 31232
[ 230.373064][ T6772] hidden 0
[ 230.373077][ T6772] btree 0
[ 230.373090][ T6772] data 0
[ 230.373102][ T6772] cached 0
[ 230.373114][ T6772] reserved 0
[ 230.373127][ T6772] online_reserved 768
[ 230.373140][ T6772] nr_inodes 0
[ 230.373152][ T6772]
[ 230.373164][ T6772] freelist_wait waiting
[ 230.373176][ T6772] open buckets allocated1
[ 230.373189][ T6772] open buckets total 1024
[ 230.373202][ T6772] open_buckets_wait empty
[ 230.373214][ T6772] open_buckets_btree 0
[ 230.373227][ T6772] open_buckets_user 0
[ 230.373239][ T6772] btree reserve cache 0
[ 230.373251][ T6772]
[ 230.373262][ T6772] Dev 0:
[ 230.373274][ T6772] buckets sectors fragmented
[ 230.373288][ T6772] free 0 0 0
[ 230.373303][ T6772] sb 0 0 0
[ 230.373318][ T6772] journal 0 0 0
[ 230.373332][ T6772] btree 0 0 0
[ 230.373347][ T6772] user 0 0 0
[ 230.373361][ T6772] cached 0 0 0
[ 230.373375][ T6772] parity 0 0 0
[ 230.373390][ T6772] stripe 0 0 0
[ 230.373404][ T6772] need_gc_gens 0 0 0
[ 230.373418][ T6772] need_discard 0 0 0
[ 230.373432][ T6772] unstriped 0 0 0
[ 230.373446][ T6772] capacity 128
[ 230.373459][ T6772]
[ 230.373470][ T6772] reserves:
[ 230.373481][ T6772] stripe 60
[ 230.373494][ T6772] normal 58
[ 230.373506][ T6772] copygc 56
[ 230.373519][ T6772] btree 28
[ 230.373531][ T6772] btree_copygc 0
[ 230.373543][ T6772] reclaim 0
[ 230.373556][ T6772] interior_updates 0
[ 230.373569][ T6772]
[ 230.373580][ T6772] open buckets 0
[ 230.373592][ T6772] buckets to invalidate 0
[ 230.373605][ T6772]
[ 230.373616][ T6772] Copygc debug:
[ 230.373627][ T6772] running: 1
[ 230.373656][ T6772] copygc_wait:0
[ 230.373675][ T6772] copygc_wait_at:0
[ 230.373694][ T6772] Currently waiting for:0 B
[ 230.373708][ T6772] Currently waiting since:644 KiB
[ 230.373722][ T6772] Currently calculated wait:0 B
[ 230.373735][ T6772]
this looks like a bug in bcachefs where alloc counters didn't get
initialized correctly, which makes sense given that 6.11 landed the disk
accounting rewrite. Will dig more as I have time.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [syzbot] Monthly lsm report (Sep 2024)
2024-09-23 16:15 ` Casey Schaufler
@ 2024-09-28 0:18 ` Casey Schaufler
0 siblings, 0 replies; 12+ messages in thread
From: Casey Schaufler @ 2024-09-28 0:18 UTC (permalink / raw)
To: Paul Moore, Mimi Zohar, Roberto Sassu, syzbot
Cc: linux-kernel, linux-security-module, syzkaller-bugs,
Casey Schaufler
On 9/23/2024 9:15 AM, Casey Schaufler wrote:
> On 9/23/2024 5:06 AM, Paul Moore wrote:
>> On Mon, Sep 23, 2024 at 5:02 AM syzbot
>> <syzbot+listfc277c7cb94932601d96@syzkaller.appspotmail.com> wrote:
>>> Hello lsm maintainers/developers,
>>>
>>> This is a 31-day syzbot report for the lsm subsystem.
>>> All related reports/information can be found at:
>>> https://syzkaller.appspot.com/upstream/s/lsm
>>>
>>> During the period, 0 new issues were detected and 0 were fixed.
>>> In total, 4 issues are still open and 27 have been fixed so far.
>>>
>>> Some of the still happening issues:
>>>
>>> Ref Crashes Repro Title
>>> <1> 306 No INFO: task hung in process_measurement (2)
>>> https://syzkaller.appspot.com/bug?extid=1de5a37cb85a2d536330
>> Mimi, Roberto,
>>
>> Any chance this is this related in any way to this report:
>>
>> https://lore.kernel.org/linux-security-module/CALAgD-4hkHVcCq2ycdwnA2hYDBMqijLUOfZgvf1WfFpU-8+42w@mail.gmail.com/
>>
>> Looking at the syzkaller dashboard for this issue, it looks like it
>> may have been present for some time, just difficult to reproduce
>> reliably (although it does appear to be occurring more often
>> recently). Any ideas about a root cause?
>>
>>> <2> 9 No general protection fault in smack_inode_permission
>>> https://syzkaller.appspot.com/bug?extid=4ac565a7081cc43bb185
>> Casey?
> Looks like an xattr or mount problem in JFS. I will have a look at it.
There's a private inode check in SELinux that didn't make it into Smack.
Looks like that should be in the infrastructure instead of the individual
modules. I have a patch in process.
>
>>> <3> 3 Yes WARNING in current_check_refer_path
>>> https://syzkaller.appspot.com/bug?extid=34b68f850391452207df
>> Based on the discussion over the summer I believe the consensus was
>> that this is a bcachefs/VFS bug, reassigning to bcachefs (or trying to
>> anyway).
>>
>> https://lore.kernel.org/all/000000000000a65b35061cffca61@google.com/
>>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [syzbot] Monthly lsm report (Sep 2024)
2024-09-28 0:08 ` Kent Overstreet
@ 2024-09-28 1:25 ` Kent Overstreet
2024-09-28 6:49 ` Tetsuo Handa
0 siblings, 1 reply; 12+ messages in thread
From: Kent Overstreet @ 2024-09-28 1:25 UTC (permalink / raw)
To: Roberto Sassu
Cc: Paul Moore, Mimi Zohar, Roberto Sassu, Casey Schaufler, syzbot,
linux-kernel, linux-security-module, syzkaller-bugs
On Fri, Sep 27, 2024 at 08:08:48PM GMT, Kent Overstreet wrote:
> On Fri, Sep 27, 2024 at 02:18:10PM GMT, Roberto Sassu wrote:
> > On Tue, 2024-09-24 at 13:53 +0200, Roberto Sassu wrote:
> > > On Mon, 2024-09-23 at 08:06 -0400, Paul Moore wrote:
> > > > On Mon, Sep 23, 2024 at 5:02 AM syzbot
> > > > <syzbot+listfc277c7cb94932601d96@syzkaller.appspotmail.com> wrote:
> > > > >
> > > > > Hello lsm maintainers/developers,
> > > > >
> > > > > This is a 31-day syzbot report for the lsm subsystem.
> > > > > All related reports/information can be found at:
> > > > > https://syzkaller.appspot.com/upstream/s/lsm
> > > > >
> > > > > During the period, 0 new issues were detected and 0 were fixed.
> > > > > In total, 4 issues are still open and 27 have been fixed so far.
> > > > >
> > > > > Some of the still happening issues:
> > > > >
> > > > > Ref Crashes Repro Title
> > > > > <1> 306 No INFO: task hung in process_measurement (2)
> > > > > https://syzkaller.appspot.com/bug?extid=1de5a37cb85a2d536330
> > > >
> > > > Mimi, Roberto,
> > > >
> > > > Any chance this is this related in any way to this report:
> > > >
> > > > https://lore.kernel.org/linux-security-module/CALAgD-4hkHVcCq2ycdwnA2hYDBMqijLUOfZgvf1WfFpU-8+42w@mail.gmail.com/
> > >
> > > I reproduced the last, but I got a different result (the kernel crashed
> > > in a different place).
> > >
> > > It seems a corruption case, while the former looks more a lock
> > > inversion issue. Will check more.
> >
> > + Kent Overstreet
> >
> > https://syzkaller.appspot.com/bug?extid=1de5a37cb85a2d536330
> >
> > It happens few times per day, since commit 4a39ac5b7d62 (which is
> > followed by a lot of merges). The bug has been likely introduced there.
> >
> > In all recent reports, I noticed that there is always the following
> > lock sequence:
> >
> > [ 291.584319][ T30] 5 locks held by syz.0.75/5970:
> > [ 291.594487][ T30] #0: ffff888064066420 (sb_writers#25){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90
> > [ 291.603984][ T30] #1: ffff88805d8b0148 (&sb->s_type->i_mutex_key#30){++++}-{3:3}, at: do_truncate+0x20c/0x310
> > [ 291.614497][ T30] #2: ffff888054700a38 (&c->snapshot_create_lock){.+.+}-{3:3}, at: bch2_truncate+0x16d/0x2c0
> > [ 291.624871][ T30] #3: ffff888054704398 (&c->btree_trans_barrier){.+.+}-{0:0}, at: __bch2_trans_get+0x7de/0xd20
> > [ 291.635446][ T30] #4: ffff8880547266d0 (&c->gc_lock){.+.+}-{3:3}, at: bch2_btree_update_start+0x682/0x14e0
> >
> > IMA is stuck too, since it is waiting for the inode lock to be released:
> >
> > [ 291.645689][ T30] 1 lock held by syz.0.75/6010:
> > [ 291.650622][ T30] #0: ffff88805d8b0148 (&sb->s_type->i_mutex_key#30){++++}-{3:3}, at: process_measurement+0x439/0x1fb0
> >
> > It seems that the super block is locked by someone else, which is not
> > able to unlock. Maybe, it is related to bch2_journal_reclaim_thread(),
> > but I don't know for sure.
> >
> > Kent, do you have time to look at this report?
>
> If you scroll back in the console log, you see this:
>
> [ 230.372988][ T6772] Allocator stuck? Waited for 30 seconds
> [ 230.373025][ T6772] Allocator debug:
> [ 230.373039][ T6772] capacity1536
> [ 230.373051][ T6772] reserved 31232
> [ 230.373064][ T6772] hidden 0
> [ 230.373077][ T6772] btree 0
> [ 230.373090][ T6772] data 0
> [ 230.373102][ T6772] cached 0
> [ 230.373114][ T6772] reserved 0
> [ 230.373127][ T6772] online_reserved 768
> [ 230.373140][ T6772] nr_inodes 0
> [ 230.373152][ T6772]
> [ 230.373164][ T6772] freelist_wait waiting
> [ 230.373176][ T6772] open buckets allocated1
> [ 230.373189][ T6772] open buckets total 1024
> [ 230.373202][ T6772] open_buckets_wait empty
> [ 230.373214][ T6772] open_buckets_btree 0
> [ 230.373227][ T6772] open_buckets_user 0
> [ 230.373239][ T6772] btree reserve cache 0
> [ 230.373251][ T6772]
> [ 230.373262][ T6772] Dev 0:
> [ 230.373274][ T6772] buckets sectors fragmented
> [ 230.373288][ T6772] free 0 0 0
> [ 230.373303][ T6772] sb 0 0 0
> [ 230.373318][ T6772] journal 0 0 0
> [ 230.373332][ T6772] btree 0 0 0
> [ 230.373347][ T6772] user 0 0 0
> [ 230.373361][ T6772] cached 0 0 0
> [ 230.373375][ T6772] parity 0 0 0
> [ 230.373390][ T6772] stripe 0 0 0
> [ 230.373404][ T6772] need_gc_gens 0 0 0
> [ 230.373418][ T6772] need_discard 0 0 0
> [ 230.373432][ T6772] unstriped 0 0 0
> [ 230.373446][ T6772] capacity 128
> [ 230.373459][ T6772]
> [ 230.373470][ T6772] reserves:
> [ 230.373481][ T6772] stripe 60
> [ 230.373494][ T6772] normal 58
> [ 230.373506][ T6772] copygc 56
> [ 230.373519][ T6772] btree 28
> [ 230.373531][ T6772] btree_copygc 0
> [ 230.373543][ T6772] reclaim 0
> [ 230.373556][ T6772] interior_updates 0
> [ 230.373569][ T6772]
> [ 230.373580][ T6772] open buckets 0
> [ 230.373592][ T6772] buckets to invalidate 0
> [ 230.373605][ T6772]
> [ 230.373616][ T6772] Copygc debug:
> [ 230.373627][ T6772] running: 1
> [ 230.373656][ T6772] copygc_wait:0
> [ 230.373675][ T6772] copygc_wait_at:0
> [ 230.373694][ T6772] Currently waiting for:0 B
> [ 230.373708][ T6772] Currently waiting since:644 KiB
> [ 230.373722][ T6772] Currently calculated wait:0 B
> [ 230.373735][ T6772]
>
> this looks like a bug in bcachefs where alloc counters didn't get
> initialized correctly, which makes sense given that 6.11 landed the disk
> accounting rewrite. Will dig more as I have time.
And looking further, I don't see anyhting in the console log from when
bcachefs actually mounted (???), which means I don't think I have enough
to go on. It's clearly an upgrade path issue - we didn't run
check_allocations as is required when upgrading to 1.11 - but it's not
reproducing for me when I run tests with old tools.
Can we get some more information about the syzbot reproducer? Exact
tools version, format command and mount command.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [syzbot] Monthly lsm report (Sep 2024)
2024-09-28 1:25 ` Kent Overstreet
@ 2024-09-28 6:49 ` Tetsuo Handa
2024-09-28 8:57 ` Kent Overstreet
0 siblings, 1 reply; 12+ messages in thread
From: Tetsuo Handa @ 2024-09-28 6:49 UTC (permalink / raw)
To: Kent Overstreet, Roberto Sassu
Cc: Paul Moore, Mimi Zohar, Roberto Sassu, Casey Schaufler, syzbot,
linux-kernel, linux-security-module, syzkaller-bugs
On 2024/09/28 10:25, Kent Overstreet wrote:
> And looking further, I don't see anyhting in the console log from when
> bcachefs actually mounted (???), which means I don't think I have enough
> to go on. It's clearly an upgrade path issue - we didn't run
> check_allocations as is required when upgrading to 1.11 - but it's not
> reproducing for me when I run tests with old tools.
>
> Can we get some more information about the syzbot reproducer? Exact
> tools version, format command and mount command.
Reproducer for this bug is not yet found. But syzbot does not use userspace
tools. That is, testing with old (or new) tools will not help. Please note
that syzbot uses crafted (intentionally corrupted) filesystem images. If the
kernel side depends on sanity checks / validations done by the userspace
side, syzbot will find oversights on the kernel side. Please don't make any
assumptions made by the userspace tools.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [syzbot] Monthly lsm report (Sep 2024)
2024-09-28 6:49 ` Tetsuo Handa
@ 2024-09-28 8:57 ` Kent Overstreet
2024-09-28 9:23 ` Tetsuo Handa
0 siblings, 1 reply; 12+ messages in thread
From: Kent Overstreet @ 2024-09-28 8:57 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Roberto Sassu, Paul Moore, Mimi Zohar, Roberto Sassu,
Casey Schaufler, syzbot, linux-kernel, linux-security-module,
syzkaller-bugs
On Sat, Sep 28, 2024 at 03:49:27PM GMT, Tetsuo Handa wrote:
> On 2024/09/28 10:25, Kent Overstreet wrote:
> > And looking further, I don't see anyhting in the console log from when
> > bcachefs actually mounted (???), which means I don't think I have enough
> > to go on. It's clearly an upgrade path issue - we didn't run
> > check_allocations as is required when upgrading to 1.11 - but it's not
> > reproducing for me when I run tests with old tools.
> >
> > Can we get some more information about the syzbot reproducer? Exact
> > tools version, format command and mount command.
>
> Reproducer for this bug is not yet found. But syzbot does not use userspace
> tools. That is, testing with old (or new) tools will not help. Please note
> that syzbot uses crafted (intentionally corrupted) filesystem images. If the
> kernel side depends on sanity checks / validations done by the userspace
> side, syzbot will find oversights on the kernel side. Please don't make any
> assumptions made by the userspace tools.
>
You seem to be confused; how do you expect sysbot to test a filesystem
without the format comand?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [syzbot] Monthly lsm report (Sep 2024)
2024-09-28 8:57 ` Kent Overstreet
@ 2024-09-28 9:23 ` Tetsuo Handa
2024-09-28 17:40 ` Kent Overstreet
0 siblings, 1 reply; 12+ messages in thread
From: Tetsuo Handa @ 2024-09-28 9:23 UTC (permalink / raw)
To: Kent Overstreet
Cc: Roberto Sassu, Paul Moore, Mimi Zohar, Roberto Sassu,
Casey Schaufler, syzbot, linux-kernel, linux-security-module,
syzkaller-bugs
On 2024/09/28 17:57, Kent Overstreet wrote:
> On Sat, Sep 28, 2024 at 03:49:27PM GMT, Tetsuo Handa wrote:
>> On 2024/09/28 10:25, Kent Overstreet wrote:
>>> And looking further, I don't see anyhting in the console log from when
>>> bcachefs actually mounted (???), which means I don't think I have enough
>>> to go on. It's clearly an upgrade path issue - we didn't run
>>> check_allocations as is required when upgrading to 1.11 - but it's not
>>> reproducing for me when I run tests with old tools.
>>>
>>> Can we get some more information about the syzbot reproducer? Exact
>>> tools version, format command and mount command.
>>
>> Reproducer for this bug is not yet found. But syzbot does not use userspace
>> tools. That is, testing with old (or new) tools will not help. Please note
>> that syzbot uses crafted (intentionally corrupted) filesystem images. If the
>> kernel side depends on sanity checks / validations done by the userspace
>> side, syzbot will find oversights on the kernel side. Please don't make any
>> assumptions made by the userspace tools.
>>
>
> You seem to be confused; how do you expect sysbot to test a filesystem
> without the format comand?
Please find syz_mount_image$bcachefs from e.g.
https://syzkaller.appspot.com/text?tag=CrashLog&x=17441e80580000 .
syzbot creates in-memory filesystem image using memfd and mount it
using loopback devices. For example,
https://syzkaller.appspot.com/text?tag=ReproC&x=102e0907980000 is
a C reproducer for an ext4 bug; check how setup_loop_device() and
syz_mount_image() are used for mounting filesystems.
Again, syzbot does not use userspace tools for managing filesystems.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [syzbot] Monthly lsm report (Sep 2024)
2024-09-28 9:23 ` Tetsuo Handa
@ 2024-09-28 17:40 ` Kent Overstreet
0 siblings, 0 replies; 12+ messages in thread
From: Kent Overstreet @ 2024-09-28 17:40 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Roberto Sassu, Paul Moore, Mimi Zohar, Roberto Sassu,
Casey Schaufler, syzbot, linux-kernel, linux-security-module,
syzkaller-bugs
On Sat, Sep 28, 2024 at 06:23:53PM GMT, Tetsuo Handa wrote:
> On 2024/09/28 17:57, Kent Overstreet wrote:
> > On Sat, Sep 28, 2024 at 03:49:27PM GMT, Tetsuo Handa wrote:
> >> On 2024/09/28 10:25, Kent Overstreet wrote:
> >>> And looking further, I don't see anyhting in the console log from when
> >>> bcachefs actually mounted (???), which means I don't think I have enough
> >>> to go on. It's clearly an upgrade path issue - we didn't run
> >>> check_allocations as is required when upgrading to 1.11 - but it's not
> >>> reproducing for me when I run tests with old tools.
> >>>
> >>> Can we get some more information about the syzbot reproducer? Exact
> >>> tools version, format command and mount command.
> >>
> >> Reproducer for this bug is not yet found. But syzbot does not use userspace
> >> tools. That is, testing with old (or new) tools will not help. Please note
> >> that syzbot uses crafted (intentionally corrupted) filesystem images. If the
> >> kernel side depends on sanity checks / validations done by the userspace
> >> side, syzbot will find oversights on the kernel side. Please don't make any
> >> assumptions made by the userspace tools.
> >>
> >
> > You seem to be confused; how do you expect sysbot to test a filesystem
> > without the format comand?
>
> Please find syz_mount_image$bcachefs from e.g.
> https://syzkaller.appspot.com/text?tag=CrashLog&x=17441e80580000 .
>
> syzbot creates in-memory filesystem image using memfd and mount it
> using loopback devices. For example,
> https://syzkaller.appspot.com/text?tag=ReproC&x=102e0907980000 is
> a C reproducer for an ext4 bug; check how setup_loop_device() and
> syz_mount_image() are used for mounting filesystems.
>
> Again, syzbot does not use userspace tools for managing filesystems.
Well, they must have started with /something/, I very much doubt they
wrote their own code for writing a bcachefs superblock.
And if they were using the standard format command I would've gotten the
full contents of the superblock in a nice text format, so I could piece
together what happened.
Since I don't have that, and the part of the dmesg log where bcachefs
mounted doesn't even seem to be there, I don't have anything to go on.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2024-09-28 17:40 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-09-23 9:02 [syzbot] Monthly lsm report (Sep 2024) syzbot
2024-09-23 12:06 ` Paul Moore
2024-09-23 16:15 ` Casey Schaufler
2024-09-28 0:18 ` Casey Schaufler
2024-09-24 11:53 ` Roberto Sassu
2024-09-27 12:18 ` Roberto Sassu
2024-09-28 0:08 ` Kent Overstreet
2024-09-28 1:25 ` Kent Overstreet
2024-09-28 6:49 ` Tetsuo Handa
2024-09-28 8:57 ` Kent Overstreet
2024-09-28 9:23 ` Tetsuo Handa
2024-09-28 17:40 ` Kent Overstreet
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox