From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: Christian Brauner <brauner@kernel.org>, Christoph Hellwig <hch@lst.de>
Cc: jack@suse.cz, syzkaller-bugs@googlegroups.com,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
huyue2@coolpad.com,
syzbot <syzbot+69c477e882e44ce41ad9@syzkaller.appspotmail.com>,
sj1557.seo@samsung.com, linux-erofs@lists.ozlabs.org,
linkinjeon@kernel.org
Subject: Re: [syzbot] [erofs?] [fat?] WARNING in erofs_kill_sb
Date: Mon, 31 Jul 2023 21:29:35 +0800 [thread overview]
Message-ID: <9fb82ade-e8a4-8b8a-25f3-b71dadc6dab1@linux.alibaba.com> (raw)
In-Reply-To: <20230731-augapfel-penibel-196c3453f809@brauner>
On 2023/7/31 20:43, Christian Brauner wrote:
> On Mon, Jul 31, 2023 at 01:16:22PM +0200, Christoph Hellwig wrote:
>> On Mon, Jul 31, 2023 at 06:58:14PM +0800, Gao Xiang wrote:
>>> Previously, deactivate_locked_super() or .kill_sb() will only be
>>> called after fill_super is called, and .s_magic will be set at
>>> the very beginning of erofs_fc_fill_super().
>>>
>>> After ("fs: open block device after superblock creation"), such
>>> convension is changed now. Yet at a quick glance,
>>>
>>> WARN_ON(sb->s_magic != EROFS_SUPER_MAGIC);
>>>
>>> in erofs_kill_sb() can be removed since deactivate_locked_super()
>>> will also be called if setup_bdev_super() is falled. I'd suggest
>>> that removing this WARN_ON() in the related commit, or as
>>> a following commit of the related branch of the pull request if
>>> possible.
>>
>> Agreed. I wonder if we should really call into ->kill_sb before
>> calling into fill_super, but I need to carefull look into the
>> details.
>
> I think checking for s_magic in erofs kill sb is wrong as it introduces
> a dependency on both fill_super() having been called and that s_magic is
> initialized first. If someone reorders erofs_kill_sb() such that s_magic
> is only filled in once everything else succeeded it would cause the same
> bug. That doesn't sound nice to me.
Many many years ago, strange .kill_sb called on our smartphone products
without proper call chain. That was why it was added and s_magic was
initialized first and at least it reminds a slight behavior change for
us (this time).
Anyway, I also think it's almost useless upstream so I'm fine to drop
this WARN_ON().
Thanks,
Gao Xiang
>
> I think ->fill_super() should only be called after successfull
> superblock allocation and after the device has been successfully opened.
> Just as this code does now. So ->kill_sb() should only be called after
> we're guaranteed that ->fill_super() has been called.
>
> We already mostly express that logic through the fs_context object.
> Anything that's allocated in fs_context->init_fs_context() is freed in
> fs_context->free() before fill_super() is called. After ->fill_super()
> is called fs_context->s_fs_info will have been transferred to
> sb->s_fs_info and will have to be killed via ->kill_sb().
>
> Does that make sense?
WARNING: multiple messages have this Message-ID (diff)
From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: Christian Brauner <brauner@kernel.org>, Christoph Hellwig <hch@lst.de>
Cc: syzbot <syzbot+69c477e882e44ce41ad9@syzkaller.appspotmail.com>,
chao@kernel.org, huyue2@coolpad.com, jack@suse.cz,
jefflexu@linux.alibaba.com, linkinjeon@kernel.org,
linux-erofs@lists.ozlabs.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, sj1557.seo@samsung.com,
syzkaller-bugs@googlegroups.com, xiang@kernel.org
Subject: Re: [syzbot] [erofs?] [fat?] WARNING in erofs_kill_sb
Date: Mon, 31 Jul 2023 21:29:35 +0800 [thread overview]
Message-ID: <9fb82ade-e8a4-8b8a-25f3-b71dadc6dab1@linux.alibaba.com> (raw)
In-Reply-To: <20230731-augapfel-penibel-196c3453f809@brauner>
On 2023/7/31 20:43, Christian Brauner wrote:
> On Mon, Jul 31, 2023 at 01:16:22PM +0200, Christoph Hellwig wrote:
>> On Mon, Jul 31, 2023 at 06:58:14PM +0800, Gao Xiang wrote:
>>> Previously, deactivate_locked_super() or .kill_sb() will only be
>>> called after fill_super is called, and .s_magic will be set at
>>> the very beginning of erofs_fc_fill_super().
>>>
>>> After ("fs: open block device after superblock creation"), such
>>> convension is changed now. Yet at a quick glance,
>>>
>>> WARN_ON(sb->s_magic != EROFS_SUPER_MAGIC);
>>>
>>> in erofs_kill_sb() can be removed since deactivate_locked_super()
>>> will also be called if setup_bdev_super() is falled. I'd suggest
>>> that removing this WARN_ON() in the related commit, or as
>>> a following commit of the related branch of the pull request if
>>> possible.
>>
>> Agreed. I wonder if we should really call into ->kill_sb before
>> calling into fill_super, but I need to carefull look into the
>> details.
>
> I think checking for s_magic in erofs kill sb is wrong as it introduces
> a dependency on both fill_super() having been called and that s_magic is
> initialized first. If someone reorders erofs_kill_sb() such that s_magic
> is only filled in once everything else succeeded it would cause the same
> bug. That doesn't sound nice to me.
Many many years ago, strange .kill_sb called on our smartphone products
without proper call chain. That was why it was added and s_magic was
initialized first and at least it reminds a slight behavior change for
us (this time).
Anyway, I also think it's almost useless upstream so I'm fine to drop
this WARN_ON().
Thanks,
Gao Xiang
>
> I think ->fill_super() should only be called after successfull
> superblock allocation and after the device has been successfully opened.
> Just as this code does now. So ->kill_sb() should only be called after
> we're guaranteed that ->fill_super() has been called.
>
> We already mostly express that logic through the fs_context object.
> Anything that's allocated in fs_context->init_fs_context() is freed in
> fs_context->free() before fill_super() is called. After ->fill_super()
> is called fs_context->s_fs_info will have been transferred to
> sb->s_fs_info and will have to be killed via ->kill_sb().
>
> Does that make sense?
next prev parent reply other threads:[~2023-07-31 13:29 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-31 7:57 [syzbot] [erofs?] [fat?] WARNING in erofs_kill_sb syzbot
2023-07-31 9:37 ` Christoph Hellwig
2023-07-31 9:37 ` Christoph Hellwig
2023-07-31 10:58 ` Gao Xiang
2023-07-31 10:58 ` Gao Xiang
2023-07-31 11:16 ` Christoph Hellwig
2023-07-31 11:16 ` Christoph Hellwig
2023-07-31 12:43 ` Christian Brauner
2023-07-31 12:43 ` Christian Brauner
2023-07-31 13:22 ` Christian Brauner
2023-07-31 13:22 ` Christian Brauner
2023-07-31 13:53 ` Christoph Hellwig
2023-07-31 13:53 ` Christoph Hellwig
2023-07-31 13:57 ` Christian Brauner
2023-07-31 13:57 ` Christian Brauner
2023-07-31 16:32 ` Christian Brauner
2023-07-31 16:32 ` Christian Brauner
2023-08-01 1:47 ` [PATCH] erofs: drop unnecessary WARN_ON() in erofs_kill_sb() Gao Xiang
2023-08-01 1:47 ` Gao Xiang
2023-08-01 7:19 ` Christian Brauner
2023-08-01 7:19 ` Christian Brauner
2023-08-01 7:51 ` Christoph Hellwig
2023-08-01 7:51 ` Christoph Hellwig
2023-07-31 13:29 ` Gao Xiang [this message]
2023-07-31 13:29 ` [syzbot] [erofs?] [fat?] WARNING in erofs_kill_sb Gao Xiang
2023-08-29 3:40 ` Gao Xiang
2023-08-29 4:14 ` [syzbot] [erofs?] " syzbot
2023-08-29 5:32 ` Gao Xiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9fb82ade-e8a4-8b8a-25f3-b71dadc6dab1@linux.alibaba.com \
--to=hsiangkao@linux.alibaba.com \
--cc=brauner@kernel.org \
--cc=hch@lst.de \
--cc=huyue2@coolpad.com \
--cc=jack@suse.cz \
--cc=linkinjeon@kernel.org \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sj1557.seo@samsung.com \
--cc=syzbot+69c477e882e44ce41ad9@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.