From: Jan Kara <jack@suse.cz>
To: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu, saukad@google.com,
harshads@google.com
Subject: Re: [PATCH v6 07/10] ext4: add nolock mode to ext4_map_blocks()
Date: Fri, 28 Jun 2024 16:18:37 +0200 [thread overview]
Message-ID: <20240628141837.iu3knuvzb7kc7qag@quack3> (raw)
In-Reply-To: <20240529012003.4006535-8-harshadshirwadkar@gmail.com>
On Wed 29-05-24 01:20:00, Harshad Shirwadkar wrote:
> Add nolock flag to ext4_map_blocks() which skips grabbing
> i_data_sem in ext4_map_blocks. In FC commit path, we first
> mark the inode as committing and thereby prevent any mutations
> on it. Thus, it should be safe to call ext4_map_blocks()
> without i_data_sem in this case. This is a workaround to
> the problem mentioned in RFC V4 version cover letter[1] of this
> patch series which pointed out that there is in incosistency between
> ext4_map_blocks() behavior when EXT4_GET_BLOCKS_CACHED_NOWAIT is
> passed. This patch gets rid of the need to call ext4_map_blocks()
> with EXT4_GET_BLOCKS_CACHED_NOWAIT and instead call it with
> EXT4_GET_BLOCKS_NOLOCK. I verified that generic/311 which failed
> in cached_nowait mode passes with nolock mode.
>
> [1] https://lwn.net/Articles/902022/
>
> Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
I'm sorry I forgot since last time - can you remind me why we cannot we
grab i_data_sem from ext4_fc_write_inode_data()? Because as you write
above, nobody should really be holding that lock while inode is
EXT4_STATE_FC_COMMITTING anyway...
Honza
> ---
> fs/ext4/ext4.h | 1 +
> fs/ext4/fast_commit.c | 16 ++++++++--------
> fs/ext4/inode.c | 14 ++++++++++++--
> 3 files changed, 21 insertions(+), 10 deletions(-)
>
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index d802040e94df..196c513f82dd 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -720,6 +720,7 @@ enum {
> #define EXT4_GET_BLOCKS_IO_SUBMIT 0x0400
> /* Caller is in the atomic contex, find extent if it has been cached */
> #define EXT4_GET_BLOCKS_CACHED_NOWAIT 0x0800
> +#define EXT4_GET_BLOCKS_NOLOCK 0x1000
>
> /*
> * The bit position of these flags must not overlap with any of the
> diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c
> index b81b0292aa59..0b7064f8dfa5 100644
> --- a/fs/ext4/fast_commit.c
> +++ b/fs/ext4/fast_commit.c
> @@ -559,13 +559,6 @@ void ext4_fc_track_inode(handle_t *handle, struct inode *inode)
> !list_empty(&ei->i_fc_list))
> return;
>
> - /*
> - * If we come here, we may sleep while waiting for the inode to
> - * commit. We shouldn't be holding i_data_sem in write mode when we go
> - * to sleep since the commit path needs to grab the lock while
> - * committing the inode.
> - */
> - WARN_ON(lockdep_is_held_type(&ei->i_data_sem, 1));
>
> while (ext4_test_inode_state(inode, EXT4_STATE_FC_COMMITTING)) {
> #if (BITS_PER_LONG < 64)
> @@ -898,7 +891,14 @@ static int ext4_fc_write_inode_data(struct inode *inode, u32 *crc)
> while (cur_lblk_off <= new_blk_size) {
> map.m_lblk = cur_lblk_off;
> map.m_len = new_blk_size - cur_lblk_off + 1;
> - ret = ext4_map_blocks(NULL, inode, &map, 0);
> + /*
> + * Given that this inode is being committed,
> + * EXT4_STATE_FC_COMMITTING is already set on this inode.
> + * Which means all the mutations on the inode are paused
> + * until the commit operation is complete. Thus it is safe
> + * call ext4_map_blocks() in no lock mode.
> + */
> + ret = ext4_map_blocks(NULL, inode, &map, EXT4_GET_BLOCKS_NOLOCK);
> if (ret < 0)
> return -ECANCELED;
>
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 61ffbdc2fb16..f00408017c7a 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -546,7 +546,8 @@ int ext4_map_blocks(handle_t *handle, struct inode *inode,
> * Try to see if we can get the block without requesting a new
> * file system block.
> */
> - down_read(&EXT4_I(inode)->i_data_sem);
> + if (!(flags & EXT4_GET_BLOCKS_NOLOCK))
> + down_read(&EXT4_I(inode)->i_data_sem);
> if (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)) {
> retval = ext4_ext_map_blocks(handle, inode, map, 0);
> } else {
> @@ -573,7 +574,15 @@ int ext4_map_blocks(handle_t *handle, struct inode *inode,
> ext4_es_insert_extent(inode, map->m_lblk, map->m_len,
> map->m_pblk, status);
> }
> - up_read((&EXT4_I(inode)->i_data_sem));
> + /*
> + * We should never call ext4_map_blocks() in nolock mode outside
> + * of fast commit path.
> + */
> + WARN_ON((flags & EXT4_GET_BLOCKS_NOLOCK) &&
> + !ext4_test_inode_state(inode,
> + EXT4_STATE_FC_COMMITTING));
> + if (!(flags & EXT4_GET_BLOCKS_NOLOCK))
> + up_read((&EXT4_I(inode)->i_data_sem));
>
> found:
> if (retval > 0 && map->m_flags & EXT4_MAP_MAPPED) {
> @@ -614,6 +623,7 @@ int ext4_map_blocks(handle_t *handle, struct inode *inode,
> * the write lock of i_data_sem, and call get_block()
> * with create == 1 flag.
> */
> + WARN_ON((flags & EXT4_GET_BLOCKS_NOLOCK) != 0);
> down_write(&EXT4_I(inode)->i_data_sem);
>
> /*
> --
> 2.45.1.288.g0e0cd299f1-goog
>
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2024-06-28 14:18 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-29 1:19 [PATCH v6 00/10] Ext4 fast commit performance patch series Harshad Shirwadkar
2024-05-29 1:19 ` [PATCH v6 01/10] ext4: convert i_fc_lock to spinlock Harshad Shirwadkar
2024-06-21 16:19 ` Jan Kara
2024-05-29 1:19 ` [PATCH v6 02/10] ext4: for committing inode, make ext4_fc_track_inode wait Harshad Shirwadkar
2024-06-21 16:33 ` Jan Kara
2024-06-28 14:45 ` Jan Kara
2024-07-01 22:08 ` Theodore Ts'o
2024-07-12 17:09 ` harshad shirwadkar
2024-05-29 1:19 ` [PATCH v6 03/10] ext4: mark inode dirty before grabbing i_data_sem in ext4_setattr Harshad Shirwadkar
2024-06-28 13:15 ` Jan Kara
2024-05-29 1:19 ` [PATCH v6 04/10] ext4: rework fast commit commit path Harshad Shirwadkar
2024-06-28 13:43 ` Jan Kara
2024-07-13 1:38 ` harshad shirwadkar
2024-07-17 12:11 ` Jan Kara
2024-05-29 1:19 ` [PATCH v6 05/10] ext4: drop i_fc_updates from inode fc info Harshad Shirwadkar
2024-05-29 1:19 ` [PATCH v6 06/10] ext4: update code documentation Harshad Shirwadkar
2024-05-29 1:20 ` [PATCH v6 07/10] ext4: add nolock mode to ext4_map_blocks() Harshad Shirwadkar
2024-06-28 14:18 ` Jan Kara [this message]
2024-07-13 2:01 ` harshad shirwadkar
2024-07-17 13:07 ` Jan Kara
2024-05-29 1:20 ` [PATCH v6 08/10] ext4: introduce selective flushing in fast commit Harshad Shirwadkar
2024-06-28 14:33 ` Jan Kara
2024-05-29 1:20 ` [PATCH v6 09/10] ext4: temporarily elevate commit thread priority Harshad Shirwadkar
2024-06-28 14:42 ` Jan Kara
2024-05-29 1:20 ` [PATCH v6 10/10] ext4: make fast commit ineligible on ext4_reserve_inode_write failure Harshad Shirwadkar
2024-06-28 14:47 ` Jan Kara
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=20240628141837.iu3knuvzb7kc7qag@quack3 \
--to=jack@suse.cz \
--cc=harshads@google.com \
--cc=harshadshirwadkar@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=saukad@google.com \
--cc=tytso@mit.edu \
/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