On Thu, 22 Aug 2024, Christian Brauner wrote:
> Port the __I_NEW mechanism to use the new var event mechanism.
>
> Signed-off-by: Christian Brauner <brauner@xxxxxxxxxx>
> ---
> fs/bcachefs/fs.c | 10 ++++++----
> fs/dcache.c | 3 +--
> fs/inode.c | 18 ++++++++----------
> include/linux/writeback.h | 3 ++-
> 4 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/fs/bcachefs/fs.c b/fs/bcachefs/fs.c
> index 94c392abef65..c0900c0c0f8a 100644
> --- a/fs/bcachefs/fs.c
> +++ b/fs/bcachefs/fs.c
> @@ -1644,14 +1644,16 @@ void bch2_evict_subvolume_inodes(struct bch_fs *c, snapshot_id_list *s)
> break;
> }
> } else if (clean_pass && this_pass_clean) {
> - wait_queue_head_t *wq = bit_waitqueue(&inode->v.i_state, __I_NEW);
> - DEFINE_WAIT_BIT(wait, &inode->v.i_state, __I_NEW);
> + struct wait_bit_queue_entry wqe;
> + struct wait_queue_head *wq_head;
>
> - prepare_to_wait(wq, &wait.wq_entry, TASK_UNINTERRUPTIBLE);
> + wq_head = inode_bit_waitqueue(&wqe, &inode->v, __I_NEW);
I don't think you EXPORT inode_bit_waitqueue() so you cannot use it in
this module.
And maybe it would be good to not export it so that this code can get
cleaned up.
Maybe I'm missing something obvious but it seems weird.
Earlier in this file a comment tells use that bcache doesn't use I_NEW,
but here is bcache explicitly waiting for it.
If bch2_inode_insert() called unlock_new_inode() immediately *before*
adding the inode to vfs_inodes_list instead of just after, this loop
that walks vfs_inodes_list would never need to wait for I_NEW to be
cleared.
I wonder if I am missing something.
NeilBrown
