[syzbot] [f2fs?] WARNING in rcu_sync_dtor

[syzbot] [f2fs?] WARNING in rcu_sync_dtor

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    1722389b0d86 Merge tag 'net-6.11-rc1' of git://git.kernel...
git tree:       upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=14955423980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=b698a1b2fcd7ef5f
dashboard link: https://syzkaller.appspot.com/bug?extid=20d7e439f76bbbd863a7
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1237a1f1980000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=115edac9980000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/e3f4ec8ccf7c/disk-1722389b.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/f19bcd908282/vmlinux-1722389b.xz
kernel image: https://storage.googleapis.com/syzbot-assets/d93604974a98/bzImage-1722389b.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/e0d10e1258f5/mount_0.gz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+20d7e439f76bbbd863a7@syzkaller.appspotmail.com

------------[ cut here ]------------
WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177
Modules linked in:
CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024
Workqueue: events destroy_super_work
RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177
Code: 74 19 e8 86 d5 00 00 43 0f b6 44 25 00 84 c0 0f 85 82 00 00 00 41 83 3f 00 75 1d 5b 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 90 <0f> 0b 90 e9 66 ff ff ff 90 0f 0b 90 eb 89 90 0f 0b 90 eb dd 44 89
RSP: 0018:ffffc9000133fb30 EFLAGS: 00010246
RAX: 0000000000000002 RBX: 1ffff11005324477 RCX: ffff8880163f5a00
RDX: 0000000000000000 RSI: ffffffff8c3f9540 RDI: ffff888029922350
RBP: 0000000000000167 R08: ffffffff82092061 R09: 1ffffffff1cbbbd4
R10: dffffc0000000000 R11: fffffbfff1cbbbd5 R12: dffffc0000000000
R13: 1ffff1100532446a R14: ffff888029922350 R15: ffff888029922350
FS:  0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055557c167738 CR3: 000000007ada8000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42
 destroy_super_work+0xec/0x130 fs/super.c:282
 process_one_work kernel/workqueue.c:3231 [inline]
 process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312
 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390
 kthread+0x2f0/0x390 kernel/kthread.c:389
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
 </TASK>


---
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.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Re: [syzbot] [f2fs?] WARNING in rcu_sync_dtor

[syzbot]

syzbot has bisected this issue to:

commit b62e71be2110d8b52bf5faf3c3ed7ca1a0c113a5
Author: Chao Yu <chao@kernel.org>
Date:   Sun Apr 23 15:49:15 2023 +0000

    f2fs: support errors=remount-ro|continue|panic mountoption

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=119745f1980000
start commit:   1722389b0d86 Merge tag 'net-6.11-rc1' of git://git.kernel...
git tree:       upstream
final oops:     https://syzkaller.appspot.com/x/report.txt?x=139745f1980000
console output: https://syzkaller.appspot.com/x/log.txt?x=159745f1980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=b698a1b2fcd7ef5f
dashboard link: https://syzkaller.appspot.com/bug?extid=20d7e439f76bbbd863a7
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1237a1f1980000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=115edac9980000

Reported-by: syzbot+20d7e439f76bbbd863a7@syzkaller.appspotmail.com
Fixes: b62e71be2110 ("f2fs: support errors=remount-ro|continue|panic mountoption")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Re: [syzbot] [f2fs?] WARNING in rcu_sync_dtor

[Christian Brauner]

On Fri, Jul 26, 2024 at 08:23:02AM GMT, syzbot wrote:
> syzbot has bisected this issue to:
> 
> commit b62e71be2110d8b52bf5faf3c3ed7ca1a0c113a5
> Author: Chao Yu <chao@kernel.org>
> Date:   Sun Apr 23 15:49:15 2023 +0000
> 
>     f2fs: support errors=remount-ro|continue|panic mountoption
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=119745f1980000
> start commit:   1722389b0d86 Merge tag 'net-6.11-rc1' of git://git.kernel...
> git tree:       upstream
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=139745f1980000
> console output: https://syzkaller.appspot.com/x/log.txt?x=159745f1980000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=b698a1b2fcd7ef5f
> dashboard link: https://syzkaller.appspot.com/bug?extid=20d7e439f76bbbd863a7
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1237a1f1980000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=115edac9980000
> 
> Reported-by: syzbot+20d7e439f76bbbd863a7@syzkaller.appspotmail.com
> Fixes: b62e71be2110 ("f2fs: support errors=remount-ro|continue|panic mountoption")
> 
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Thanks to Paul and Oleg for point me in the right direction and
explaining that rcu sync warning.

That patch here is remounting a superblock read-only directly by raising
SB_RDONLY without the involvement of the VFS at all. That's pretty
broken and is likely to cause trouble if done wrong. The rough order of
operations to transition rw->ro usualy include checking that the
filsystem is unfrozen, and marking all mounts read-only, then calling
into the filesystem so it can do whatever it wants to do.

In any case, all of this requires holding sb->s_umount. Not holding
sb->s_umount will end up confusing freeze_super() (Thanks to Oleg for
noticing!). When freeze_super() is called on a non-ro filesystem it will
acquire
percpu_down_write(SB_FREEZE_WRITE+SB_FREEZE_PAGEFAULT+SB_FREEZE_FS) and
thaw_super() needs to call
sb_freeze_unlock(SB_FREEZE_FS+SB_FREEZE_PAGEFAULT+SB_FREEZE_WRITE) but
because you just raise SB_RDONLY you end up causing thaw_super() to skip
that step causing the bug in rcu_sync_dtor() to be noticed.

Btw, ext4 has similar logic where it raises SB_RDONLY without checking
whether the filesystem is frozen.

So I guess, this is technically ok as long as that emergency SB_RDONLY raising
in sb->s_flags is not done while the fs is already frozen. I think ext4 can
probably never do that. Jan?

My guess is that something in f2fs can end up raising SB_RDONLY after
the filesystem is frozen and so it causes this bug. I suspect this is coming
from the gc_thread() which might issue a f2fs_stop_checkpoint() while the fs is
already about to be frozen but before the gc thread is stopped as part of the
freeze.

Re: [syzbot] [f2fs?] WARNING in rcu_sync_dtor

[Jan Kara]

On Mon 29-07-24 11:10:09, Christian Brauner wrote:
> On Fri, Jul 26, 2024 at 08:23:02AM GMT, syzbot wrote:
> > syzbot has bisected this issue to:
> > 
> > commit b62e71be2110d8b52bf5faf3c3ed7ca1a0c113a5
> > Author: Chao Yu <chao@kernel.org>
> > Date:   Sun Apr 23 15:49:15 2023 +0000
> > 
> >     f2fs: support errors=remount-ro|continue|panic mountoption
> > 
> > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=119745f1980000
> > start commit:   1722389b0d86 Merge tag 'net-6.11-rc1' of git://git.kernel...
> > git tree:       upstream
> > final oops:     https://syzkaller.appspot.com/x/report.txt?x=139745f1980000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=159745f1980000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=b698a1b2fcd7ef5f
> > dashboard link: https://syzkaller.appspot.com/bug?extid=20d7e439f76bbbd863a7
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1237a1f1980000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=115edac9980000
> > 
> > Reported-by: syzbot+20d7e439f76bbbd863a7@syzkaller.appspotmail.com
> > Fixes: b62e71be2110 ("f2fs: support errors=remount-ro|continue|panic mountoption")
> > 
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> 
> Thanks to Paul and Oleg for point me in the right direction and
> explaining that rcu sync warning.
> 
> That patch here is remounting a superblock read-only directly by raising
> SB_RDONLY without the involvement of the VFS at all. That's pretty
> broken and is likely to cause trouble if done wrong. The rough order of
> operations to transition rw->ro usualy include checking that the
> filsystem is unfrozen, and marking all mounts read-only, then calling
> into the filesystem so it can do whatever it wants to do.

Yeah, this way of handling filesystem errors dates back to days when the
world was much simpler :) It has been always a bit of a hack (but when you
try to limit damage from corrupted on-disk data structures, a bit of
hackiness is acceptable) but it is doubly so these days.

> In any case, all of this requires holding sb->s_umount. Not holding
> sb->s_umount will end up confusing freeze_super() (Thanks to Oleg for
> noticing!). When freeze_super() is called on a non-ro filesystem it will
> acquire
> percpu_down_write(SB_FREEZE_WRITE+SB_FREEZE_PAGEFAULT+SB_FREEZE_FS) and
> thaw_super() needs to call
> sb_freeze_unlock(SB_FREEZE_FS+SB_FREEZE_PAGEFAULT+SB_FREEZE_WRITE) but
> because you just raise SB_RDONLY you end up causing thaw_super() to skip
> that step causing the bug in rcu_sync_dtor() to be noticed.

Yeah, good spotting.

> Btw, ext4 has similar logic where it raises SB_RDONLY without checking
> whether the filesystem is frozen.
> 
> So I guess, this is technically ok as long as that emergency SB_RDONLY raising
> in sb->s_flags is not done while the fs is already frozen. I think ext4 can
> probably never do that. Jan?

You'd wish (or maybe I'd wish ;) No, ext4 can hit it in the same way f2fs
can. All it takes is for ext4 to hit some metadata corruption on read from
disk while the filesystem is frozen.

> My guess is that something in f2fs can end up raising SB_RDONLY after
> the filesystem is frozen and so it causes this bug. I suspect this is coming
> from the gc_thread() which might issue a f2fs_stop_checkpoint() while the fs is
> already about to be frozen but before the gc thread is stopped as part of the
> freeze.

So in ext4 we have EXT4_FLAGS_SHUTDOWN flag which we now use internally
instead of SB_RDONLY flag for checking whether the filesystem was shutdown
(because otherwise races between remount and hitting fs error were really
messy). However we still *also* set SB_RDONLY so that VFS bails early from
some paths which generally results in less error noise in kernel logs and
also out of caution of not breaking something in this path. That being said
we also support EXT4_IOC_SHUTDOWN ioctl for several years and in that path
we set EXT4_FLAGS_SHUTDOWN without setting SB_RDONLY and nothing seems to
have blown up. So I'm inclined to belive we could remove setting of
SB_RDONLY from ext4 error handling. Ted, what do you think?

Also as the "filesystem shutdown" is spreading across multiple filesystems,
I'm playing with the idea that maybe we could lift a flag like this to VFS
so that we can check it in VFS paths and abort some operations early.  But
so far I'm not convinced the gain is worth the need to iron out various
subtle semantical differences of "shutdown" among filesystems.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [syzbot] [f2fs?] WARNING in rcu_sync_dtor

[Theodore Ts'o]

On Mon, Jul 29, 2024 at 03:27:21PM +0200, Jan Kara wrote:
> 
> So in ext4 we have EXT4_FLAGS_SHUTDOWN flag which we now use
> internally instead of SB_RDONLY flag for checking whether the
> filesystem was shutdown (because otherwise races between remount and
> hitting fs error were really messy). However we still *also* set
> SB_RDONLY so that VFS bails early from some paths which generally
> results in less error noise in kernel logs and also out of caution
> of not breaking something in this path. That being said we also
> support EXT4_IOC_SHUTDOWN ioctl for several years and in that path
> we set EXT4_FLAGS_SHUTDOWN without setting SB_RDONLY and nothing
> seems to have blown up. So I'm inclined to belive we could remove
> setting of SB_RDONLY from ext4 error handling. Ted, what do you
> think?

Well, there are some failures of generic/388 (which involves calling
the shutdown ioctl while running fsstress).  I believe that most of
those failures are file system corruption errors, as opposed to other
sorts of failures, but we don't run KASAN kernels all that often,
especially since generic/388 is now on the exclude list.

The failure rate of generic/388 varies depending on the storage device
involved, but it varies from less than 10% to 50% of the time, if
memory serves correctly.  Since EXT4_IOC_SHUTDOWN is used most of the
time as a debugging/test (although there are some users use it in
production, but the failure rate when you're not doing something
really aggressive like fsstress is very small), this has been on the
"one of these days, when we have tons of free time, we should really
look into this.  The challenge is fixing this in a way that doesn't
involve adding new locking in various file system hotpaths.

So "nothing seems to have blown up" might be a bit strong.  But it's
something we can try doing, and see whether it results in more rather
than less syzbot complaints.

> Also as the "filesystem shutdown" is spreading across multiple
> filesystems, I'm playing with the idea that maybe we could lift a
> flag like this to VFS so that we can check it in VFS paths and abort
> some operations early.  But so far I'm not convinced the gain is
> worth the need to iron out various subtle semantical differences of
> "shutdown" among filesystems.

I think that might be a good idea.  Hopefully subtle semantic
differences are ones that won't matter in terms of the VFS aborting
operations early.

						- Ted

Re: [syzbot] [f2fs?] WARNING in rcu_sync_dtor

[Jan Kara]

On Mon 29-07-24 09:58:47, Theodore Ts'o wrote:
> On Mon, Jul 29, 2024 at 03:27:21PM +0200, Jan Kara wrote:
> > So in ext4 we have EXT4_FLAGS_SHUTDOWN flag which we now use
> > internally instead of SB_RDONLY flag for checking whether the
> > filesystem was shutdown (because otherwise races between remount and
> > hitting fs error were really messy). However we still *also* set
> > SB_RDONLY so that VFS bails early from some paths which generally
> > results in less error noise in kernel logs and also out of caution
> > of not breaking something in this path. That being said we also
> > support EXT4_IOC_SHUTDOWN ioctl for several years and in that path
> > we set EXT4_FLAGS_SHUTDOWN without setting SB_RDONLY and nothing
> > seems to have blown up. So I'm inclined to belive we could remove
> > setting of SB_RDONLY from ext4 error handling. Ted, what do you
> > think?
> 
> Well, there are some failures of generic/388 (which involves calling
> the shutdown ioctl while running fsstress).  I believe that most of
> those failures are file system corruption errors, as opposed to other
> sorts of failures, but we don't run KASAN kernels all that often,
> especially since generic/388 is now on the exclude list.

As far as I remember the reason for those failures were mostly because the
fs shutdown happened in the middle of some operation on another CPU and 
this tickled unusual error handling paths that eventually resulted in
WARN_ONs and similar.

> The failure rate of generic/388 varies depending on the storage device
> involved, but it varies from less than 10% to 50% of the time, if
> memory serves correctly.  Since EXT4_IOC_SHUTDOWN is used most of the
> time as a debugging/test (although there are some users use it in
> production, but the failure rate when you're not doing something
> really aggressive like fsstress is very small), this has been on the
> "one of these days, when we have tons of free time, we should really
> look into this.  The challenge is fixing this in a way that doesn't
> involve adding new locking in various file system hotpaths.
> 
> So "nothing seems to have blown up" might be a bit strong.  But it's
> something we can try doing, and see whether it results in more rather
> than less syzbot complaints.

OK. I don't expect real troubles within the filesystem itself here because
the read-only check currently brings us only the benefit that the
filesystem isn't even entered in a lot of cases. But at latest by the time
we try to start a transaction handle, we get back error and bail out anyway
after the fs was shutdown and this is reasonably well tested path. What might
have larger impact is that userspace will be getting back EIO / EUCLEAN
instead of EROFS. But I hope it won't be a big deal either.

> > Also as the "filesystem shutdown" is spreading across multiple
> > filesystems, I'm playing with the idea that maybe we could lift a
> > flag like this to VFS so that we can check it in VFS paths and abort
> > some operations early.  But so far I'm not convinced the gain is
> > worth the need to iron out various subtle semantical differences of
> > "shutdown" among filesystems.
> 
> I think that might be a good idea.  Hopefully subtle semantic
> differences are ones that won't matter in terms of the VFS aborting
> operations early.

OK, I guess I'll try and see.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [syzbot] [f2fs?] WARNING in rcu_sync_dtor

[Dave Chinner]

On Mon, Jul 29, 2024 at 03:27:21PM +0200, Jan Kara wrote:
> Also as the "filesystem shutdown" is spreading across multiple filesystems,
> I'm playing with the idea that maybe we could lift a flag like this to VFS
> so that we can check it in VFS paths and abort some operations early. 

I've been thinking the same thing since I saw what CIFS was doing a
couple of days ago with shutdowns. It's basically just stopping all
new incoming modification operations if the flag is set. i.e. it's
just a check in each filesystem method, and I suspect that many
other filesystems that support shutdown do the same thing.

It looks like exactly the same implementation as CIFS is about to be
added to exfat - stop all the incoming methods and check in the
writeback method - so having a generic superblock flag and generic
checks before calling into filesystem methods would make it real
easy for all filesystems to have basic ->shutdown support for when
block devices go away suddenly.

I also think that we should be lifting *IOC_SHUTDOWN to the VFS -
the same ioctl is now implemented in 4-5 filesystems and they
largely do the same thing - just set a bit in the internal
filesystem superblock flags. Yes, filesystems like XFS and ext4 do
special stuff with journals, but the generic VFS implemenation could
call the filesystem ->shutdown method to do that....

> But
> so far I'm not convinced the gain is worth the need to iron out various
> subtle semantical differences of "shutdown" among filesystems.

I don't think we need to change how any filesystem behaves when it
is shut down. As long as filesystems follow at least the "no new
modifications when shutdown" behaviour, filesystems can implement
internal shutdown however they want...

-Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: [syzbot] [f2fs?] WARNING in rcu_sync_dtor

[Chao Yu]

#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/chao/linux.git wip

On 2024/7/26 15:54, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    1722389b0d86 Merge tag 'net-6.11-rc1' of git://git.kernel...
> git tree:       upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=14955423980000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=b698a1b2fcd7ef5f
> dashboard link: https://syzkaller.appspot.com/bug?extid=20d7e439f76bbbd863a7
> compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1237a1f1980000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=115edac9980000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/e3f4ec8ccf7c/disk-1722389b.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/f19bcd908282/vmlinux-1722389b.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/d93604974a98/bzImage-1722389b.xz
> mounted in repro: https://storage.googleapis.com/syzbot-assets/e0d10e1258f5/mount_0.gz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+20d7e439f76bbbd863a7@syzkaller.appspotmail.com
> 
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177
> Modules linked in:
> CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024
> Workqueue: events destroy_super_work
> RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177
> Code: 74 19 e8 86 d5 00 00 43 0f b6 44 25 00 84 c0 0f 85 82 00 00 00 41 83 3f 00 75 1d 5b 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 90 <0f> 0b 90 e9 66 ff ff ff 90 0f 0b 90 eb 89 90 0f 0b 90 eb dd 44 89
> RSP: 0018:ffffc9000133fb30 EFLAGS: 00010246
> RAX: 0000000000000002 RBX: 1ffff11005324477 RCX: ffff8880163f5a00
> RDX: 0000000000000000 RSI: ffffffff8c3f9540 RDI: ffff888029922350
> RBP: 0000000000000167 R08: ffffffff82092061 R09: 1ffffffff1cbbbd4
> R10: dffffc0000000000 R11: fffffbfff1cbbbd5 R12: dffffc0000000000
> R13: 1ffff1100532446a R14: ffff888029922350 R15: ffff888029922350
> FS:  0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000055557c167738 CR3: 000000007ada8000 CR4: 00000000003506f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>   <TASK>
>   percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42
>   destroy_super_work+0xec/0x130 fs/super.c:282
>   process_one_work kernel/workqueue.c:3231 [inline]
>   process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312
>   worker_thread+0x86d/0xd40 kernel/workqueue.c:3390
>   kthread+0x2f0/0x390 kernel/kthread.c:389
>   ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
>   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
>   </TASK>
> 
> 
> ---
> 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.
> 
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> 
> If the report is already addressed, let syzbot know by replying with:
> #syz fix: exact-commit-title
> 
> If you want syzbot to run the reproducer, reply with:
> #syz test: git://repo/address.git branch-or-commit-hash
> If you attach or paste a git patch, syzbot will apply it before testing.
> 
> If you want to overwrite report's subsystems, reply with:
> #syz set subsystems: new-subsystem
> (See the list of subsystem names on the web dashboard)
> 
> If the report is a duplicate of another one, reply with:
> #syz dup: exact-subject-of-another-report
> 
> If you want to undo deduplication, reply with:
> #syz undup

Re: [syzbot] [f2fs?] WARNING in rcu_sync_dtor

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+20d7e439f76bbbd863a7@syzkaller.appspotmail.com
Tested-by: syzbot+20d7e439f76bbbd863a7@syzkaller.appspotmail.com

Tested on:

commit:         f3815bfb f2fs: fix to tag STATX_DIOALIGN only if inode..
git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/chao/linux.git wip
console output: https://syzkaller.appspot.com/x/log.txt?x=1319e807980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=9358cc4a2e37fd30
dashboard link: https://syzkaller.appspot.com/bug?extid=20d7e439f76bbbd863a7
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40

Note: no patches were applied.
Note: testing is done by a robot and is best-effort only.