linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: Jan Kara <jack@suse.com>,
	tytso@mit.edu, Andreas Dilger <adilger.kernel@dilger.ca>,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 3/3] ext4: Use generic_quota_read()
Date: Mon, 6 Jun 2022 10:38:14 +0200	[thread overview]
Message-ID: <20220606083814.skjv34b2tjn7l7pi@quack3.lan> (raw)
In-Reply-To: <20220605143815.2330891-4-willy@infradead.org>

On Sun 05-06-22 15:38:15, Matthew Wilcox (Oracle) wrote:
> The comment about the page cache is rather stale; the buffer cache will
> read into the page cache if the buffer isn't present, and the page cache
> will not take any locks if the page is present.
> 
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>

This will not work for couple of reasons, see below. BTW, I don't think the
comment about page cache was stale (but lacking details I admit ;). As far
as I remember (and it was really many years ago - definitely pre-git era)
the problem was (mainly on the write side) that before current state of the
code we were using calls like vfs_read() / vfs_write() to get quota
information and that was indeed prone to deadlocks.

> @@ -6924,20 +6882,21 @@ static ssize_t ext4_quota_write(struct super_block *sb, int type,
>  		return -EIO;
>  	}
>  
> -	do {
> -		bh = ext4_bread(handle, inode, blk,
> -				EXT4_GET_BLOCKS_CREATE |
> -				EXT4_GET_BLOCKS_METADATA_NOFAIL);
> -	} while (PTR_ERR(bh) == -ENOSPC &&
> -		 ext4_should_retry_alloc(inode->i_sb, &retries));
> -	if (IS_ERR(bh))
> -		return PTR_ERR(bh);
> -	if (!bh)
> +	folio = read_mapping_folio(inode->i_mapping, off / PAGE_SIZE, NULL);
> +	if (IS_ERR(folio))
> +		return PTR_ERR(folio);
> +	head = folio_buffers(folio);
> +	if (!head)
> +		head = alloc_page_buffers(&folio->page, sb->s_blocksize, false);
> +	if (!head)
>  		goto out;
> +	bh = head;
> +	while ((bh_offset(bh) + sb->s_blocksize) <= (off % PAGE_SIZE))
> +		bh = bh->b_this_page;

We miss proper handling of blocks that are currently beyond i_size
(we are extending the quota file), plus we also miss any mapping of buffers
to appropriate disk blocks here...

It could be all fixed by replicating what we do in ext4_write_begin() but
I'm not quite convinced using inode's page cache is really worth it...

								Honza

>  	BUFFER_TRACE(bh, "get write access");
>  	err = ext4_journal_get_write_access(handle, sb, bh, EXT4_JTR_NONE);
>  	if (err) {
> -		brelse(bh);
> +		folio_put(folio);
>  		return err;
>  	}
>  	lock_buffer(bh);
> @@ -6945,14 +6904,14 @@ static ssize_t ext4_quota_write(struct super_block *sb, int type,
>  	flush_dcache_page(bh->b_page);
>  	unlock_buffer(bh);
>  	err = ext4_handle_dirty_metadata(handle, NULL, bh);
> -	brelse(bh);
>  out:
> +	folio_put(folio);
> +	if (err)
> +		return err;
>  	if (inode->i_size < off + len) {
>  		i_size_write(inode, off + len);
>  		EXT4_I(inode)->i_disksize = inode->i_size;
> -		err2 = ext4_mark_inode_dirty(handle, inode);
> -		if (unlikely(err2 && !err))
> -			err = err2;
> +		err = ext4_mark_inode_dirty(handle, inode);
>  	}
>  	return err ? err : len;
>  }
> -- 
> 2.35.1
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2022-06-06  8:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-05 14:38 [PATCH 0/3] Cache quota files in the page cache Matthew Wilcox (Oracle)
2022-06-05 14:38 ` [PATCH 1/3] quota: Prevent memory allocation recursion while holding dq_lock Matthew Wilcox (Oracle)
2022-06-06  8:03   ` Jan Kara
2022-06-06 12:42     ` Matthew Wilcox
2022-06-06 13:08       ` Jan Kara
2022-06-05 14:38 ` [PATCH 2/3] quota: Support using the page cache for quota files Matthew Wilcox (Oracle)
2022-06-06  2:53   ` kernel test robot
2022-06-06  4:05   ` kernel test robot
2022-06-06  4:36   ` kernel test robot
2022-06-05 14:38 ` [PATCH 3/3] ext4: Use generic_quota_read() Matthew Wilcox (Oracle)
2022-06-06  8:38   ` Jan Kara [this message]
2022-06-08  1:42     ` Matthew Wilcox
2022-06-08 14:21       ` Jan Kara
2022-06-13  7:59   ` [ext4] fa96490369: WARNING:at_fs/ext4/inode.c:#ext4_invalidate_folio kernel test robot

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=20220606083814.skjv34b2tjn7l7pi@quack3.lan \
    --to=jack@suse.cz \
    --cc=adilger.kernel@dilger.ca \
    --cc=jack@suse.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=willy@infradead.org \
    /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 NNTP newsgroup(s).