From: Jan Kara <jack@suse.cz>
To: zhangshida <starzhangzsd@gmail.com>
Cc: tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.com,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
zhangshida@kylinos.cn, Jan Kara <jack@suse.cz>
Subject: Re: [RFC PATCH V2 2/2] ext4: Replace the __block_write_begin with ext4_block_write_begin
Date: Fri, 9 Aug 2024 18:55:48 +0200 [thread overview]
Message-ID: <20240809165548.nlhsovccmn3kmouw@quack3> (raw)
In-Reply-To: <20240809064606.3490994-3-zhangshida@kylinos.cn>
On Fri 09-08-24 14:46:06, zhangshida wrote:
> From: Shida Zhang <zhangshida@kylinos.cn>
>
> Using __block_write_begin() make it inconvenient to journal the
> user data dirty process. We can't tell the block layer maintainer,
> ‘Hey, we want to trace the dirty user data in ext4, can we add some
> special code for ext4 in __block_write_begin?’:P
>
> So use ext4_block_write_begin() instead.
>
> The two functions are basically doing the same thing except for the
> fscrypt related code. Narrow the scope of CONFIG_FS_ENCRYPTION
> so as to allow ext4_block_write_begin() to function like
> __block_write_begin when the config is disabled.
>
> Suggested-by: Jan Kara <jack@suse.cz>
> Signed-off-by: Shida Zhang <zhangshida@kylinos.cn>
There are three more calls to __block_write_begin() in fs/ext4/inline.c.
Please convert them as well. We don't allow inline data and data
journalling combination but it is unexpected surprise that those places
still use __block_write_begin().
Honza
> ---
> fs/ext4/inode.c | 19 ++++---------------
> 1 file changed, 4 insertions(+), 15 deletions(-)
>
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index de46c0a6842a..31389633086a 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -1046,7 +1046,6 @@ int do_journal_get_write_access(handle_t *handle, struct inode *inode,
> return ret;
> }
>
> -#ifdef CONFIG_FS_ENCRYPTION
> static int ext4_block_write_begin(handle_t *handle, struct folio *folio,
> loff_t pos, unsigned len,
> get_block_t *get_block)
> @@ -1135,7 +1134,9 @@ static int ext4_block_write_begin(handle_t *handle, struct folio *folio,
> from, to);
> else
> folio_zero_new_buffers(folio, from, to);
> - } else if (fscrypt_inode_uses_fs_layer_crypto(inode)) {
> + }
> +#ifdef CONFIG_FS_ENCRYPTION
> + else if (fscrypt_inode_uses_fs_layer_crypto(inode)) {
> for (i = 0; i < nr_wait; i++) {
> int err2;
>
> @@ -1147,10 +1148,10 @@ static int ext4_block_write_begin(handle_t *handle, struct folio *folio,
> }
> }
> }
> +#endif
>
> return err;
> }
> -#endif
>
> /*
> * To preserve ordering, it is essential that the hole instantiation and
> @@ -1232,20 +1233,12 @@ static int ext4_write_begin(struct file *file, struct address_space *mapping,
> /* In case writeback began while the folio was unlocked */
> folio_wait_stable(folio);
>
> -#ifdef CONFIG_FS_ENCRYPTION
> if (ext4_should_dioread_nolock(inode))
> ret = ext4_block_write_begin(handle, folio, pos, len,
> ext4_get_block_unwritten);
> else
> ret = ext4_block_write_begin(handle, folio, pos, len,
> ext4_get_block);
> -#else
> - if (ext4_should_dioread_nolock(inode))
> - ret = __block_write_begin(&folio->page, pos, len,
> - ext4_get_block_unwritten);
> - else
> - ret = __block_write_begin(&folio->page, pos, len, ext4_get_block);
> -#endif
> if (!ret && ext4_should_journal_data(inode)) {
> ret = ext4_walk_page_buffers(handle, inode,
> folio_buffers(folio), from, to,
> @@ -2978,12 +2971,8 @@ static int ext4_da_write_begin(struct file *file, struct address_space *mapping,
> if (IS_ERR(folio))
> return PTR_ERR(folio);
>
> -#ifdef CONFIG_FS_ENCRYPTION
> ret = ext4_block_write_begin(NULL, folio, pos, len,
> ext4_da_get_block_prep);
> -#else
> - ret = __block_write_begin(&folio->page, pos, len, ext4_da_get_block_prep);
> -#endif
> if (ret < 0) {
> folio_unlock(folio);
> folio_put(folio);
> --
> 2.33.0
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
prev parent reply other threads:[~2024-08-09 16:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-09 6:46 [RFC PATCH v2 0/2] Fix an error caused by improperly dirtied buffer zhangshida
2024-08-09 6:46 ` [RFC PATCH V2 1/2] ext4: fix a potential assertion failure due to " zhangshida
2024-08-09 17:10 ` Jan Kara
2024-08-09 6:46 ` [RFC PATCH V2 2/2] ext4: Replace the __block_write_begin with ext4_block_write_begin zhangshida
2024-08-09 16:55 ` Jan Kara [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=20240809165548.nlhsovccmn3kmouw@quack3 \
--to=jack@suse.cz \
--cc=adilger.kernel@dilger.ca \
--cc=jack@suse.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=starzhangzsd@gmail.com \
--cc=tytso@mit.edu \
--cc=zhangshida@kylinos.cn \
/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.