Linux-ext4 Archive on lore.kernel.org
 help / color / Atom feed
From: Zhang Yi <yi.zhang@huawei.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: <linux-ext4@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>,
	<tytso@mit.edu>, <adilger.kernel@dilger.ca>, <jack@suse.cz>,
	<yukuai3@huawei.com>
Subject: Re: [RFC PATCH v2 6/7] fs: introduce a usage count into the superblock
Date: Fri, 16 Apr 2021 16:00:35 +0800
Message-ID: <a35319b2-8d5d-2a32-9284-d1828ec4d9df@huawei.com> (raw)
In-Reply-To: <20210415144056.GA2069063@infradead.org>

Hi, Christoph

On 2021/4/15 22:40, Christoph Hellwig wrote:
> On Wed, Apr 14, 2021 at 09:47:36PM +0800, Zhang Yi wrote:
>> Commit <87d8fe1ee6b8> ("add releasepage hooks to block devices which can
>> be used by file systems") introduce a hook that used by ext4 filesystem
>> to release journal buffers, but it doesn't add corresponding concurrency
>> protection that ->bdev_try_to_free_page() could be raced by umount
>> filesystem concurrently. This patch add a usage count on superblock that
>> filesystem can use it to prevent above race and make invoke
>> ->bdev_try_to_free_page() safe.
> 
> We already have two refcounts in the superblock: s_active which counts
> the active refernce, and s_count which prevents the data structures
> from beeing freed.  I don't think we need yet another one.
> .
> 

Thanks you for your response. I checked the s_count and s_active refcounts,
but it seems that we could not use these two refcounts directly.

For the s_active. If we get s_active refcount in blkdev_releasepage(), we may
put the final refcount when doing umount concurrently and have to do resource
recycling, but we got page locked here and lead to deadlock. Maybe we could do
async resource recycling through kworker, but I think it's not a good way.

For the s_count, it is operated under the global sb_lock now, so get this
refcount will serialize page release and affect performance. Besides, It's
semantics are different from the 'usage count' by private fileststem, and we
have to cooperate with sb->s_umount mutex lock to close the above race.

So I introduce another refcount. Am I missing something or any suggestions?

Thanks,
Yi.

  reply index

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-14 13:47 [RFC PATCH v2 0/7] ext4, jbd2: fix 3 issues about bdev_try_to_free_page() Zhang Yi
2021-04-14 13:47 ` [RFC PATCH v2 1/7] jbd2: remove the out label in __jbd2_journal_remove_checkpoint() Zhang Yi
2021-04-21 10:01   ` Jan Kara
2021-04-14 13:47 ` [RFC PATCH v2 2/7] jbd2: ensure abort the journal if detect IO error when writing original buffer back Zhang Yi
2021-04-21 13:20   ` Jan Kara
2021-04-14 13:47 ` [RFC PATCH v2 3/7] jbd2: don't abort the journal when freeing buffers Zhang Yi
2021-04-21 13:23   ` Jan Kara
2021-04-14 13:47 ` [RFC PATCH v2 4/7] jbd2: do not free buffers in jbd2_journal_try_to_free_buffers() Zhang Yi
2021-04-15 14:46   ` Christoph Hellwig
2021-04-14 13:47 ` [RFC PATCH v2 5/7] ext4: use RCU to protect accessing superblock in blkdev_releasepage() Zhang Yi
2021-04-15 14:48   ` Christoph Hellwig
2021-04-14 13:47 ` [RFC PATCH v2 6/7] fs: introduce a usage count into the superblock Zhang Yi
2021-04-15 14:40   ` Christoph Hellwig
2021-04-16  8:00     ` Zhang Yi [this message]
2021-04-14 13:47 ` [RFC PATCH v2 7/7] ext4: fix race between blkdev_releasepage() and ext4_put_super() Zhang Yi
2021-04-15 14:52   ` Christoph Hellwig
2021-04-16  8:00     ` Zhang Yi
2021-04-20 13:08       ` Christoph Hellwig
2021-04-21 13:46         ` Jan Kara
2021-04-21 16:57           ` Theodore Ts'o
2021-04-22  9:04             ` Jan Kara
2021-04-23 11:39               ` Zhang Yi
2021-04-23 16:06                 ` Jan Kara
2021-04-23 14:40               ` Theodore Ts'o

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=a35319b2-8d5d-2a32-9284-d1828ec4d9df@huawei.com \
    --to=yi.zhang@huawei.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --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

Linux-ext4 Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-ext4/0 linux-ext4/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-ext4 linux-ext4/ https://lore.kernel.org/linux-ext4 \
		linux-ext4@vger.kernel.org
	public-inbox-index linux-ext4

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-ext4


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git