From: Jan Kara <jack@suse.cz>
To: Baokun Li <libaokun1@huawei.com>
Cc: Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-kernel@vger.kernel.org, yi.zhang@huawei.com,
yangerkun@huawei.com, chengzhihao1@huawei.com,
yukuai3@huawei.com
Subject: Re: [PATCH] quota: fix race condition between dqput() and dquot_mark_dquot_dirty()
Date: Mon, 26 Jun 2023 15:09:57 +0200 [thread overview]
Message-ID: <20230626130957.kvfli23djxc2opkq@quack3> (raw)
In-Reply-To: <b73894fc-0c7a-0503-25ad-ab5a9dfbd852@huawei.com>
Hello!
On Sun 25-06-23 15:56:10, Baokun Li wrote:
> > > I think we can simply focus on the race between the DQ_ACTIVE_B flag and
> > > the DQ_MOD_B flag, which is the core problem, because the same quota
> > > should not have both flags. These two flags are protected by dq_list_lock
> > > and dquot->dq_lock respectively, so it makes sense to add a
> > > wait_on_dquot() to ensure the accuracy of DQ_ACTIVE_B.
> > But the fundamental problem is not only the race with DQ_MOD_B setting. The
> > dquot structure can be completely freed by the time
> > dquot_claim_space_nodirty() calls dquot_mark_dquot_dirty() on it. That's
> > why I think making __dquot_transfer() obey dquot_srcu rules is the right
> > solution.
> Yes, now I also think that making __dquot_transfer() obey dquot_srcu
> rules is a better solution. But with inode->i_lock protection, why would
> the dquot structure be completely freed?
Well, when dquot_claim_space_nodirty() calls mark_all_dquot_dirty() it does
not hold any locks (only dquot_srcu). So nothing prevents dquot_transfer()
to go, swap dquot structure pointers and drop dquot references and after
that mark_all_dquot_dirty() can use a stale pointer to call
mark_dquot_dirty() on already freed memory.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2023-06-26 13:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-16 8:56 [PATCH] quota: fix race condition between dqput() and dquot_mark_dquot_dirty() Baokun Li
2023-06-16 15:28 ` Jan Kara
2023-06-19 6:44 ` Baokun Li
2023-06-22 14:56 ` Jan Kara
2023-06-25 7:56 ` Baokun Li
2023-06-26 13:09 ` Jan Kara [this message]
2023-06-26 13:55 ` Baokun Li
2023-06-27 8:34 ` Jan Kara
2023-06-27 9:08 ` Baokun Li
2023-06-27 9:28 ` Jan Kara
2023-06-27 14:06 ` Baokun Li
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=20230626130957.kvfli23djxc2opkq@quack3 \
--to=jack@suse.cz \
--cc=chengzhihao1@huawei.com \
--cc=libaokun1@huawei.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yukuai3@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox