From: Zhihao Cheng <chengzhihao1@huawei.com>
To: Qingfang Deng <dqfext@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
Richard Weinberger <richard@nod.at>,
<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] jffs2: fix recursive fs_reclaim deadlock
Date: Tue, 19 Mar 2024 15:56:13 +0800 [thread overview]
Message-ID: <3424d2c5-9e49-6218-7ffe-3cf62a07ac3d@huawei.com> (raw)
In-Reply-To: <CALW65jbQCvkpeoOv275jgQAHf+Tk3QBR0HdwdGhK3s7gF+HVeg@mail.gmail.com>
在 2024/3/19 14:41, Qingfang Deng 写道:
> On Fri, Mar 15, 2024 at 9:00 PM Zhihao Cheng <chengzhihao1@huawei.com> wrote:
>>
>> 在 2024/3/15 20:19, Qingfang Deng 写道:
>>> Hi Zhihao,
>>>
>>> On Fri, Mar 15, 2024 at 7:19 PM Zhihao Cheng <chengzhihao1@huawei.com> wrote:
>>>> I think it's a false positive warning. Jffs2 is trying to get root inode
>>>> in process '#1', which means that the filesystem is not mounted
>>>> yet(Because d_make_root is after jffs2_iget(sb,1), there is no way to
>>>> access other inodes.), so it is impossible that jffs2 inode is being
>>>> evicted in '#0'.
>>>>
>>>
>>> You're right that process '#1' is getting the root inode. However,
>>> lockdep only records the stack of the first unique lock ordering (see
>>> https://docs.kernel.org/locking/lockdep-design.html#performance ), and
>>> there are many occasions where GFP_KERNEL is used inside a
>>> jffs2_inode_info::sem 's critical section.
>>> .
>>>
>> Allocating memory without GFP_NOFS flags under sleeping lock is a normal
>> thing. The vfs_write is an example(eg. ext4), page is allocated with
>> FGP_WRITEBEGIN flag(no FGP_NOFS) when holding inode lock.
>
> If this is a false positive, is there a way to suppress the warning?
> .
>
I can't find a idea either. According to my poor knowledge on lockdep,
it looks like that lockdep traces a class of locks(eg. f->sem in jffs2)
rather than one certain lock, because the key of lock->dep_map is
initialized with a static variable (See mutex_init). In some easy cases,
we can add subclass to solve the false positive warnings(eg.
lock_4_inodes). But now, jffs2 case is different, any
jffs2_do_clear_inode calling could trigger it, and we cannot add limited
subclasses to solve it.
Take a step back, I think we can just ignore the warning,
fs_reclaim_acquire is a public path, other filesystems/modules could
face the same case.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
prev parent reply other threads:[~2024-03-19 7:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-15 7:59 [RFC PATCH] jffs2: fix recursive fs_reclaim deadlock Qingfang Deng
2024-03-15 11:19 ` Zhihao Cheng
2024-03-15 12:19 ` Qingfang Deng
2024-03-15 12:58 ` Zhihao Cheng
2024-03-19 6:41 ` Qingfang Deng
2024-03-19 7:56 ` Zhihao Cheng [this message]
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=3424d2c5-9e49-6218-7ffe-3cf62a07ac3d@huawei.com \
--to=chengzhihao1@huawei.com \
--cc=dqfext@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).