[PATCH v3] fuse: invalidate the page cache after direct write

[PATCH v3] fuse: invalidate the page cache after direct write

[Jingbo Xu]

This fixes xfstests generic/451 (for both O_DIRECT and FOPEN_DIRECT_IO
direct write).

Commit b359af8275a9 ("fuse: Invalidate the page cache after
FOPEN_DIRECT_IO write") tries to fix the similar issue for
FOPEN_DIRECT_IO write, which can be reproduced by xfstests generic/209.
It only fixes the issue for synchronous direct write, while omitting
the case for asynchronous direct write (exactly targeted by
generic/451).

While for O_DIRECT direct write, it's somewhat more complicated.  For
synchronous direct write, generic_file_direct_write() will invalidate
the page cache after the write, and thus it can pass generic/209.  While
for asynchronous direct write, the invalidation in
generic_file_direct_write() is bypassed since the invalidation shall be
done when the asynchronous IO completes.  This is omitted in FUSE and
generic/451 fails whereby.

Fix this by conveying the invalidation for both synchronous and
asynchronous write.

- with FOPEN_DIRECT_IO
  - sync write,  invalidate in fuse_send_write()
  - async write, invalidate in fuse_aio_complete() with FUSE_ASYNC_DIO,
		 fuse_send_write() otherwise
- without FOPEN_DIRECT_IO
  - sync write,  invalidate in generic_file_direct_write()
  - async write, invalidate in fuse_aio_complete() with FUSE_ASYNC_DIO,
		 generic_file_direct_write() otherwise

Reviewed-by: Bernd Schubert <bschubert@ddn.com>
Signed-off-by: Jingbo Xu <jefflexu@linux.alibaba.com>
---
changes:
- drop "|| !ia->io->blocking" in fuse_send_write() (Bernd)
---
 fs/fuse/file.c | 43 ++++++++++++++++++++++++++++++++-----------
 1 file changed, 32 insertions(+), 11 deletions(-)

diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 01bc894e9c2b..625d236b881b 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -667,6 +667,18 @@ static void fuse_aio_complete(struct fuse_io_priv *io, int err, ssize_t pos)
 			struct inode *inode = file_inode(io->iocb->ki_filp);
 			struct fuse_conn *fc = get_fuse_conn(inode);
 			struct fuse_inode *fi = get_fuse_inode(inode);
+			struct address_space *mapping = io->iocb->ki_filp->f_mapping;
+
+			/*
+			 * As in generic_file_direct_write(), invalidate after the
+			 * write, to invalidate read-ahead cache that may have competed
+			 * with the write.
+			 */
+			if (io->write && res && mapping->nrpages) {
+				invalidate_inode_pages2_range(mapping,
+						io->offset >> PAGE_SHIFT,
+						(io->offset + res - 1) >> PAGE_SHIFT);
+			}
 
 			spin_lock(&fi->lock);
 			fi->attr_version = atomic64_inc_return(&fc->attr_version);
@@ -1144,9 +1156,11 @@ static ssize_t fuse_send_write(struct fuse_io_args *ia, loff_t pos,
 {
 	struct kiocb *iocb = ia->io->iocb;
 	struct file *file = iocb->ki_filp;
+	struct address_space *mapping = file->f_mapping;
 	struct fuse_file *ff = file->private_data;
 	struct fuse_mount *fm = ff->fm;
 	struct fuse_write_in *inarg = &ia->write.in;
+	ssize_t written;
 	ssize_t err;
 
 	fuse_write_args_fill(ia, ff, pos, count);
@@ -1160,10 +1174,26 @@ static ssize_t fuse_send_write(struct fuse_io_args *ia, loff_t pos,
 		return fuse_async_req_send(fm, ia, count);
 
 	err = fuse_simple_request(fm, &ia->ap.args);
-	if (!err && ia->write.out.size > count)
+	written = ia->write.out.size;
+	if (!err && written > count)
 		err = -EIO;
 
-	return err ?: ia->write.out.size;
+	/*
+	 * Without FOPEN_DIRECT_IO, generic_file_direct_write() does the
+	 * invalidation for us.
+	 */
+	if (!err && written && mapping->nrpages &&
+	    (ff->open_flags & FOPEN_DIRECT_IO)) {
+		/*
+		 * As in generic_file_direct_write(), invalidate after the
+		 * write, to invalidate read-ahead cache that may have competed
+		 * with the write.
+		 */
+		invalidate_inode_pages2_range(mapping, pos >> PAGE_SHIFT,
+					(pos + written - 1) >> PAGE_SHIFT);
+	}
+
+	return err ?: written;
 }
 
 bool fuse_write_update_attr(struct inode *inode, loff_t pos, ssize_t written)
@@ -1738,15 +1768,6 @@ ssize_t fuse_direct_io(struct fuse_io_priv *io, struct iov_iter *iter,
 	if (res > 0)
 		*ppos = pos;
 
-	if (res > 0 && write && fopen_direct_io) {
-		/*
-		 * As in generic_file_direct_write(), invalidate after the
-		 * write, to invalidate read-ahead cache that may have competed
-		 * with the write.
-		 */
-		invalidate_inode_pages2_range(mapping, idx_from, idx_to);
-	}
-
 	return res > 0 ? res : err;
 }
 EXPORT_SYMBOL_GPL(fuse_direct_io);
-- 
2.19.1.6.gb485710b

Re: [PATCH v3] fuse: invalidate the page cache after direct write

[Markus Elfring]

…
> +++ b/fs/fuse/file.c
> @@ -667,6 +667,18 @@ static void fuse_aio_complete(struct fuse_io_priv *io, int err, ssize_t pos)
>  			struct inode *inode = file_inode(io->iocb->ki_filp);
>  			struct fuse_conn *fc = get_fuse_conn(inode);
>  			struct fuse_inode *fi = get_fuse_inode(inode);
> +			struct address_space *mapping = io->iocb->ki_filp->f_mapping;
> +
> +			/*
> +			 * As in generic_file_direct_write(), invalidate after the
> +			 * write, to invalidate read-ahead cache that may have competed
> +			 * with the write.
> +			 */
> +			if (io->write && res && mapping->nrpages) {
> +				invalidate_inode_pages2_range(mapping,
> +						io->offset >> PAGE_SHIFT,
> +						(io->offset + res - 1) >> PAGE_SHIFT);
> +			}
>  
>  			spin_lock(&fi->lock);
…
> @@ -1160,10 +1174,26 @@ static ssize_t fuse_send_write(struct fuse_io_args *ia, loff_t pos,
…
-	return err ?: ia->write.out.size;
> +	/*
> +	 * Without FOPEN_DIRECT_IO, generic_file_direct_write() does the
> +	 * invalidation for us.
> +	 */
> +	if (!err && written && mapping->nrpages &&
> +	    (ff->open_flags & FOPEN_DIRECT_IO)) {
> +		/*
> +		 * As in generic_file_direct_write(), invalidate after the
> +		 * write, to invalidate read-ahead cache that may have competed
> +		 * with the write.
> +		 */
> +		invalidate_inode_pages2_range(mapping, pos >> PAGE_SHIFT,
> +					(pos + written - 1) >> PAGE_SHIFT);
> +	}
> +
> +	return err ?: written;
…

You may omit curly brackets at selected source code places.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?h=v6.19-rc4#n197

Regards,
Markus

Re: [PATCH v3] fuse: invalidate the page cache after direct write

[Bernd Schubert]

On 1/11/26 09:18, Markus Elfring wrote:
> [You don't often get email from markus.elfring@web.de. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> …
>> +++ b/fs/fuse/file.c
>> @@ -667,6 +667,18 @@ static void fuse_aio_complete(struct fuse_io_priv *io, int err, ssize_t pos)
>>                       struct inode *inode = file_inode(io->iocb->ki_filp);
>>                       struct fuse_conn *fc = get_fuse_conn(inode);
>>                       struct fuse_inode *fi = get_fuse_inode(inode);
>> +                     struct address_space *mapping = io->iocb->ki_filp->f_mapping;
>> +
>> +                     /*
>> +                      * As in generic_file_direct_write(), invalidate after the
>> +                      * write, to invalidate read-ahead cache that may have competed
>> +                      * with the write.
>> +                      */
>> +                     if (io->write && res && mapping->nrpages) {
>> +                             invalidate_inode_pages2_range(mapping,
>> +                                             io->offset >> PAGE_SHIFT,
>> +                                             (io->offset + res - 1) >> PAGE_SHIFT);
>> +                     }
>>
>>                       spin_lock(&fi->lock);
> …
>> @@ -1160,10 +1174,26 @@ static ssize_t fuse_send_write(struct fuse_io_args *ia, loff_t pos,
> …
> -       return err ?: ia->write.out.size;
>> +     /*
>> +      * Without FOPEN_DIRECT_IO, generic_file_direct_write() does the
>> +      * invalidation for us.
>> +      */
>> +     if (!err && written && mapping->nrpages &&
>> +         (ff->open_flags & FOPEN_DIRECT_IO)) {
>> +             /*
>> +              * As in generic_file_direct_write(), invalidate after the
>> +              * write, to invalidate read-ahead cache that may have competed
>> +              * with the write.
>> +              */
>> +             invalidate_inode_pages2_range(mapping, pos >> PAGE_SHIFT,
>> +                                     (pos + written - 1) >> PAGE_SHIFT);
>> +     }
>> +
>> +     return err ?: written;
> …
> 
> You may omit curly brackets at selected source code places.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?h=v6.19-rc4#n197

We could, but we could also concentrate on code correctness instead of
nit-picky debatable code style.

Thanks,
Bernd

Re: [PATCH v3] fuse: invalidate the page cache after direct write

[Jingbo Xu]

On 1/11/26 4:18 PM, Markus Elfring wrote:
> …
>> +++ b/fs/fuse/file.c
>> @@ -667,6 +667,18 @@ static void fuse_aio_complete(struct fuse_io_priv *io, int err, ssize_t pos)
>>  			struct inode *inode = file_inode(io->iocb->ki_filp);
>>  			struct fuse_conn *fc = get_fuse_conn(inode);
>>  			struct fuse_inode *fi = get_fuse_inode(inode);
>> +			struct address_space *mapping = io->iocb->ki_filp->f_mapping;
>> +
>> +			/*
>> +			 * As in generic_file_direct_write(), invalidate after the
>> +			 * write, to invalidate read-ahead cache that may have competed
>> +			 * with the write.
>> +			 */
>> +			if (io->write && res && mapping->nrpages) {
>> +				invalidate_inode_pages2_range(mapping,
>> +						io->offset >> PAGE_SHIFT,
>> +						(io->offset + res - 1) >> PAGE_SHIFT);
>> +			}
>>  
>>  			spin_lock(&fi->lock);
> …
>> @@ -1160,10 +1174,26 @@ static ssize_t fuse_send_write(struct fuse_io_args *ia, loff_t pos,
> …
> -	return err ?: ia->write.out.size;
>> +	/*
>> +	 * Without FOPEN_DIRECT_IO, generic_file_direct_write() does the
>> +	 * invalidation for us.
>> +	 */
>> +	if (!err && written && mapping->nrpages &&
>> +	    (ff->open_flags & FOPEN_DIRECT_IO)) {
>> +		/*
>> +		 * As in generic_file_direct_write(), invalidate after the
>> +		 * write, to invalidate read-ahead cache that may have competed
>> +		 * with the write.
>> +		 */
>> +		invalidate_inode_pages2_range(mapping, pos >> PAGE_SHIFT,
>> +					(pos + written - 1) >> PAGE_SHIFT);
>> +	}
>> +
>> +	return err ?: written;
> …
> 
> You may omit curly brackets at selected source code places.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?h=v6.19-rc4#n197
> 

It's generally true for **simple** single statement.  I would prefer
adding the braces as it's a multi-line statement with a comment block.


-- 
Thanks,
Jingbo

Re: [PATCH v3] fuse: invalidate the page cache after direct write

[Jingbo Xu]

gentle ping

On 1/11/26 3:37 PM, Jingbo Xu wrote:
> This fixes xfstests generic/451 (for both O_DIRECT and FOPEN_DIRECT_IO
> direct write).
> 
> Commit b359af8275a9 ("fuse: Invalidate the page cache after
> FOPEN_DIRECT_IO write") tries to fix the similar issue for
> FOPEN_DIRECT_IO write, which can be reproduced by xfstests generic/209.
> It only fixes the issue for synchronous direct write, while omitting
> the case for asynchronous direct write (exactly targeted by
> generic/451).
> 
> While for O_DIRECT direct write, it's somewhat more complicated.  For
> synchronous direct write, generic_file_direct_write() will invalidate
> the page cache after the write, and thus it can pass generic/209.  While
> for asynchronous direct write, the invalidation in
> generic_file_direct_write() is bypassed since the invalidation shall be
> done when the asynchronous IO completes.  This is omitted in FUSE and
> generic/451 fails whereby.
> 
> Fix this by conveying the invalidation for both synchronous and
> asynchronous write.
> 
> - with FOPEN_DIRECT_IO
>   - sync write,  invalidate in fuse_send_write()
>   - async write, invalidate in fuse_aio_complete() with FUSE_ASYNC_DIO,
> 		 fuse_send_write() otherwise
> - without FOPEN_DIRECT_IO
>   - sync write,  invalidate in generic_file_direct_write()
>   - async write, invalidate in fuse_aio_complete() with FUSE_ASYNC_DIO,
> 		 generic_file_direct_write() otherwise
> 
> Reviewed-by: Bernd Schubert <bschubert@ddn.com>
> Signed-off-by: Jingbo Xu <jefflexu@linux.alibaba.com>
> ---
> changes:
> - drop "|| !ia->io->blocking" in fuse_send_write() (Bernd)
> ---
>  fs/fuse/file.c | 43 ++++++++++++++++++++++++++++++++-----------
>  1 file changed, 32 insertions(+), 11 deletions(-)
> 
> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> index 01bc894e9c2b..625d236b881b 100644
> --- a/fs/fuse/file.c
> +++ b/fs/fuse/file.c
> @@ -667,6 +667,18 @@ static void fuse_aio_complete(struct fuse_io_priv *io, int err, ssize_t pos)
>  			struct inode *inode = file_inode(io->iocb->ki_filp);
>  			struct fuse_conn *fc = get_fuse_conn(inode);
>  			struct fuse_inode *fi = get_fuse_inode(inode);
> +			struct address_space *mapping = io->iocb->ki_filp->f_mapping;
> +
> +			/*
> +			 * As in generic_file_direct_write(), invalidate after the
> +			 * write, to invalidate read-ahead cache that may have competed
> +			 * with the write.
> +			 */
> +			if (io->write && res && mapping->nrpages) {
> +				invalidate_inode_pages2_range(mapping,
> +						io->offset >> PAGE_SHIFT,
> +						(io->offset + res - 1) >> PAGE_SHIFT);
> +			}
>  
>  			spin_lock(&fi->lock);
>  			fi->attr_version = atomic64_inc_return(&fc->attr_version);
> @@ -1144,9 +1156,11 @@ static ssize_t fuse_send_write(struct fuse_io_args *ia, loff_t pos,
>  {
>  	struct kiocb *iocb = ia->io->iocb;
>  	struct file *file = iocb->ki_filp;
> +	struct address_space *mapping = file->f_mapping;
>  	struct fuse_file *ff = file->private_data;
>  	struct fuse_mount *fm = ff->fm;
>  	struct fuse_write_in *inarg = &ia->write.in;
> +	ssize_t written;
>  	ssize_t err;
>  
>  	fuse_write_args_fill(ia, ff, pos, count);
> @@ -1160,10 +1174,26 @@ static ssize_t fuse_send_write(struct fuse_io_args *ia, loff_t pos,
>  		return fuse_async_req_send(fm, ia, count);
>  
>  	err = fuse_simple_request(fm, &ia->ap.args);
> -	if (!err && ia->write.out.size > count)
> +	written = ia->write.out.size;
> +	if (!err && written > count)
>  		err = -EIO;
>  
> -	return err ?: ia->write.out.size;
> +	/*
> +	 * Without FOPEN_DIRECT_IO, generic_file_direct_write() does the
> +	 * invalidation for us.
> +	 */
> +	if (!err && written && mapping->nrpages &&
> +	    (ff->open_flags & FOPEN_DIRECT_IO)) {
> +		/*
> +		 * As in generic_file_direct_write(), invalidate after the
> +		 * write, to invalidate read-ahead cache that may have competed
> +		 * with the write.
> +		 */
> +		invalidate_inode_pages2_range(mapping, pos >> PAGE_SHIFT,
> +					(pos + written - 1) >> PAGE_SHIFT);
> +	}
> +
> +	return err ?: written;
>  }
>  
>  bool fuse_write_update_attr(struct inode *inode, loff_t pos, ssize_t written)
> @@ -1738,15 +1768,6 @@ ssize_t fuse_direct_io(struct fuse_io_priv *io, struct iov_iter *iter,
>  	if (res > 0)
>  		*ppos = pos;
>  
> -	if (res > 0 && write && fopen_direct_io) {
> -		/*
> -		 * As in generic_file_direct_write(), invalidate after the
> -		 * write, to invalidate read-ahead cache that may have competed
> -		 * with the write.
> -		 */
> -		invalidate_inode_pages2_range(mapping, idx_from, idx_to);
> -	}
> -
>  	return res > 0 ? res : err;
>  }
>  EXPORT_SYMBOL_GPL(fuse_direct_io);

-- 
Thanks,
Jingbo

Re: [PATCH v3] fuse: invalidate the page cache after direct write

[Miklos Szeredi]

On Sun, 11 Jan 2026 at 08:37, Jingbo Xu <jefflexu@linux.alibaba.com> wrote:
>
> This fixes xfstests generic/451 (for both O_DIRECT and FOPEN_DIRECT_IO
> direct write).
>
> Commit b359af8275a9 ("fuse: Invalidate the page cache after
> FOPEN_DIRECT_IO write") tries to fix the similar issue for
> FOPEN_DIRECT_IO write, which can be reproduced by xfstests generic/209.
> It only fixes the issue for synchronous direct write, while omitting
> the case for asynchronous direct write (exactly targeted by
> generic/451).
>
> While for O_DIRECT direct write, it's somewhat more complicated.  For
> synchronous direct write, generic_file_direct_write() will invalidate
> the page cache after the write, and thus it can pass generic/209.  While
> for asynchronous direct write, the invalidation in
> generic_file_direct_write() is bypassed since the invalidation shall be
> done when the asynchronous IO completes.  This is omitted in FUSE and
> generic/451 fails whereby.
>
> Fix this by conveying the invalidation for both synchronous and
> asynchronous write.
>
> - with FOPEN_DIRECT_IO
>   - sync write,  invalidate in fuse_send_write()
>   - async write, invalidate in fuse_aio_complete() with FUSE_ASYNC_DIO,
>                  fuse_send_write() otherwise
> - without FOPEN_DIRECT_IO
>   - sync write,  invalidate in generic_file_direct_write()
>   - async write, invalidate in fuse_aio_complete() with FUSE_ASYNC_DIO,
>                  generic_file_direct_write() otherwise
>
> Reviewed-by: Bernd Schubert <bschubert@ddn.com>
> Signed-off-by: Jingbo Xu <jefflexu@linux.alibaba.com>

Applied, thanks.

Miklos

Re: [PATCH v3] fuse: invalidate the page cache after direct write

[Bernd Schubert]

On 2/27/26 16:09, Miklos Szeredi wrote:
> On Sun, 11 Jan 2026 at 08:37, Jingbo Xu <jefflexu@linux.alibaba.com> wrote:
>>
>> This fixes xfstests generic/451 (for both O_DIRECT and FOPEN_DIRECT_IO
>> direct write).
>>
>> Commit b359af8275a9 ("fuse: Invalidate the page cache after
>> FOPEN_DIRECT_IO write") tries to fix the similar issue for
>> FOPEN_DIRECT_IO write, which can be reproduced by xfstests generic/209.
>> It only fixes the issue for synchronous direct write, while omitting
>> the case for asynchronous direct write (exactly targeted by
>> generic/451).
>>
>> While for O_DIRECT direct write, it's somewhat more complicated.  For
>> synchronous direct write, generic_file_direct_write() will invalidate
>> the page cache after the write, and thus it can pass generic/209.  While
>> for asynchronous direct write, the invalidation in
>> generic_file_direct_write() is bypassed since the invalidation shall be
>> done when the asynchronous IO completes.  This is omitted in FUSE and
>> generic/451 fails whereby.
>>
>> Fix this by conveying the invalidation for both synchronous and
>> asynchronous write.
>>
>> - with FOPEN_DIRECT_IO
>>   - sync write,  invalidate in fuse_send_write()
>>   - async write, invalidate in fuse_aio_complete() with FUSE_ASYNC_DIO,
>>                  fuse_send_write() otherwise
>> - without FOPEN_DIRECT_IO
>>   - sync write,  invalidate in generic_file_direct_write()
>>   - async write, invalidate in fuse_aio_complete() with FUSE_ASYNC_DIO,
>>                  generic_file_direct_write() otherwise
>>
>> Reviewed-by: Bernd Schubert <bschubert@ddn.com>
>> Signed-off-by: Jingbo Xu <jefflexu@linux.alibaba.com>
> 
> Applied, thanks.
> 

Hi Miklos,

just back from a week off and we got a QA report last week. This commit
leads to a deadlock. Is there a chance you can revert and not send it
to Linus yet? 

[Wed Feb 25 07:14:29 2026] INFO: task clt_reactor_3:49041 blocked for more than 122 seconds.
[Wed Feb 25 07:14:29 2026]       Tainted: G           OE      6.8.0-79-generic #79-Ubuntu
[Wed Feb 25 07:14:29 2026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[Wed Feb 25 07:14:29 2026] task:clt_reactor_3   state:D stack:0     pid:49041 tgid:49014 ppid:1      flags:0x00000006
[Wed Feb 25 07:14:29 2026] Call Trace:
[Wed Feb 25 07:14:29 2026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[Wed Feb 25 07:14:29 2026] task:clt_reactor_3   state:D stack:0     pid:49041 tgid:49014 ppid:1      flags:0x00000006
[Wed Feb 25 07:14:29 2026] Call Trace:
[Wed Feb 25 07:14:29 2026]  <TASK>
[Wed Feb 25 07:14:29 2026]  __schedule+0x27c/0x6b0
[Wed Feb 25 07:14:29 2026]  schedule+0x33/0x110
[Wed Feb 25 07:14:29 2026]  io_schedule+0x46/0x80
[Wed Feb 25 07:14:29 2026]  folio_wait_bit_common+0x136/0x330
[Wed Feb 25 07:14:29 2026]  __folio_lock+0x17/0x30
[Wed Feb 25 07:14:29 2026]  invalidate_inode_pages2_range+0x1d2/0x4f0
[Wed Feb 25 07:14:29 2026]  fuse_aio_complete+0x258/0x270 [fuse]
[Wed Feb 25 07:14:29 2026]  fuse_aio_complete_req+0x87/0xd0 [fuse]
[Wed Feb 25 07:14:29 2026]  fuse_request_end+0x18e/0x200 [fuse]
[Wed Feb 25 07:14:29 2026]  fuse_uring_req_end+0x87/0xd0 [fuse]
[Wed Feb 25 07:14:29 2026]  fuse_uring_cmd+0x241/0xf20 [fuse]
[Wed Feb 25 07:14:29 2026]  io_uring_cmd+0x9f/0x140
[Wed Feb 25 07:14:29 2026]  io_issue_sqe+0x193/0x410
[Wed Feb 25 07:14:29 2026]  io_submit_sqes+0x128/0x3e0
[Wed Feb 25 07:14:29 2026]  __do_sys_io_uring_enter+0x2ea/0x490
[Wed Feb 25 07:14:29 2026]  __x64_sys_io_uring_enter+0x22/0x40


Issue is that invalidate_inode_pages2_range() might trigger another
write to the same core (in our case a reactor / coroutine) and
then deadlocks.
Cheng suggests to offload that into a worker queue, but FOPEN_DIRECT_IO
code starts to get complex - I'm more inclined to get back to my patches
from about 3 years ago that the unified the DIO handlers and let it go
through the normal vfs handlers.


Thanks,
Bernd

Re: [PATCH v3] fuse: invalidate the page cache after direct write

[Bernd Schubert]

On 3/2/26 20:29, Bernd Schubert wrote:
> 
> 
> On 2/27/26 16:09, Miklos Szeredi wrote:
>> On Sun, 11 Jan 2026 at 08:37, Jingbo Xu <jefflexu@linux.alibaba.com> wrote:
>>>
>>> This fixes xfstests generic/451 (for both O_DIRECT and FOPEN_DIRECT_IO
>>> direct write).
>>>
>>> Commit b359af8275a9 ("fuse: Invalidate the page cache after
>>> FOPEN_DIRECT_IO write") tries to fix the similar issue for
>>> FOPEN_DIRECT_IO write, which can be reproduced by xfstests generic/209.
>>> It only fixes the issue for synchronous direct write, while omitting
>>> the case for asynchronous direct write (exactly targeted by
>>> generic/451).
>>>
>>> While for O_DIRECT direct write, it's somewhat more complicated.  For
>>> synchronous direct write, generic_file_direct_write() will invalidate
>>> the page cache after the write, and thus it can pass generic/209.  While
>>> for asynchronous direct write, the invalidation in
>>> generic_file_direct_write() is bypassed since the invalidation shall be
>>> done when the asynchronous IO completes.  This is omitted in FUSE and
>>> generic/451 fails whereby.
>>>
>>> Fix this by conveying the invalidation for both synchronous and
>>> asynchronous write.
>>>
>>> - with FOPEN_DIRECT_IO
>>>   - sync write,  invalidate in fuse_send_write()
>>>   - async write, invalidate in fuse_aio_complete() with FUSE_ASYNC_DIO,
>>>                  fuse_send_write() otherwise
>>> - without FOPEN_DIRECT_IO
>>>   - sync write,  invalidate in generic_file_direct_write()
>>>   - async write, invalidate in fuse_aio_complete() with FUSE_ASYNC_DIO,
>>>                  generic_file_direct_write() otherwise
>>>
>>> Reviewed-by: Bernd Schubert <bschubert@ddn.com>
>>> Signed-off-by: Jingbo Xu <jefflexu@linux.alibaba.com>
>>
>> Applied, thanks.
>>
> 
> Hi Miklos,
> 
> just back from a week off and we got a QA report last week. This commit
> leads to a deadlock. Is there a chance you can revert and not send it
> to Linus yet? 
> 
> [Wed Feb 25 07:14:29 2026] INFO: task clt_reactor_3:49041 blocked for more than 122 seconds.
> [Wed Feb 25 07:14:29 2026]       Tainted: G           OE      6.8.0-79-generic #79-Ubuntu
> [Wed Feb 25 07:14:29 2026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [Wed Feb 25 07:14:29 2026] task:clt_reactor_3   state:D stack:0     pid:49041 tgid:49014 ppid:1      flags:0x00000006
> [Wed Feb 25 07:14:29 2026] Call Trace:
> [Wed Feb 25 07:14:29 2026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [Wed Feb 25 07:14:29 2026] task:clt_reactor_3   state:D stack:0     pid:49041 tgid:49014 ppid:1      flags:0x00000006
> [Wed Feb 25 07:14:29 2026] Call Trace:
> [Wed Feb 25 07:14:29 2026]  <TASK>
> [Wed Feb 25 07:14:29 2026]  __schedule+0x27c/0x6b0
> [Wed Feb 25 07:14:29 2026]  schedule+0x33/0x110
> [Wed Feb 25 07:14:29 2026]  io_schedule+0x46/0x80
> [Wed Feb 25 07:14:29 2026]  folio_wait_bit_common+0x136/0x330
> [Wed Feb 25 07:14:29 2026]  __folio_lock+0x17/0x30
> [Wed Feb 25 07:14:29 2026]  invalidate_inode_pages2_range+0x1d2/0x4f0
> [Wed Feb 25 07:14:29 2026]  fuse_aio_complete+0x258/0x270 [fuse]
> [Wed Feb 25 07:14:29 2026]  fuse_aio_complete_req+0x87/0xd0 [fuse]
> [Wed Feb 25 07:14:29 2026]  fuse_request_end+0x18e/0x200 [fuse]
> [Wed Feb 25 07:14:29 2026]  fuse_uring_req_end+0x87/0xd0 [fuse]
> [Wed Feb 25 07:14:29 2026]  fuse_uring_cmd+0x241/0xf20 [fuse]
> [Wed Feb 25 07:14:29 2026]  io_uring_cmd+0x9f/0x140
> [Wed Feb 25 07:14:29 2026]  io_issue_sqe+0x193/0x410
> [Wed Feb 25 07:14:29 2026]  io_submit_sqes+0x128/0x3e0
> [Wed Feb 25 07:14:29 2026]  __do_sys_io_uring_enter+0x2ea/0x490
> [Wed Feb 25 07:14:29 2026]  __x64_sys_io_uring_enter+0x22/0x40
> 
> 
> Issue is that invalidate_inode_pages2_range() might trigger another
> write to the same core (in our case a reactor / coroutine) and
> then deadlocks.
> Cheng suggests to offload that into a worker queue, but FOPEN_DIRECT_IO
> code starts to get complex - I'm more inclined to get back to my patches
> from about 3 years ago that the unified the DIO handlers and let it go
> through the normal vfs handlers.
> 

Hmm, maybe in the short term maybe the better solution is to update the
patch (not posted to the list) that Cheng made and to use
i_sb->s_dio_done_wq similar to what iomap_dio_bio_end_io() does.

Re: [PATCH v3] fuse: invalidate the page cache after direct write

[Miklos Szeredi]

On Mon, 2 Mar 2026 at 22:20, Bernd Schubert <bernd@bsbernd.com> wrote:

> Hmm, maybe in the short term maybe the better solution is to update the
> patch (not posted to the list) that Cheng made and to use
> i_sb->s_dio_done_wq similar to what iomap_dio_bio_end_io() does.

Sure.  Thanks for the heads up.

Miklos

Re: [PATCH v3] fuse: invalidate the page cache after direct write

[Jingbo Xu]

Hi Bernd,

Thanks for reporting it!

On 3/3/26 5:19 AM, Bernd Schubert wrote:
> 
> 
> On 3/2/26 20:29, Bernd Schubert wrote:
>>
>>
>> On 2/27/26 16:09, Miklos Szeredi wrote:
>>> On Sun, 11 Jan 2026 at 08:37, Jingbo Xu <jefflexu@linux.alibaba.com> wrote:
>>>>
>>>> This fixes xfstests generic/451 (for both O_DIRECT and FOPEN_DIRECT_IO
>>>> direct write).
>>>>
>>>> Commit b359af8275a9 ("fuse: Invalidate the page cache after
>>>> FOPEN_DIRECT_IO write") tries to fix the similar issue for
>>>> FOPEN_DIRECT_IO write, which can be reproduced by xfstests generic/209.
>>>> It only fixes the issue for synchronous direct write, while omitting
>>>> the case for asynchronous direct write (exactly targeted by
>>>> generic/451).
>>>>
>>>> While for O_DIRECT direct write, it's somewhat more complicated.  For
>>>> synchronous direct write, generic_file_direct_write() will invalidate
>>>> the page cache after the write, and thus it can pass generic/209.  While
>>>> for asynchronous direct write, the invalidation in
>>>> generic_file_direct_write() is bypassed since the invalidation shall be
>>>> done when the asynchronous IO completes.  This is omitted in FUSE and
>>>> generic/451 fails whereby.
>>>>
>>>> Fix this by conveying the invalidation for both synchronous and
>>>> asynchronous write.
>>>>
>>>> - with FOPEN_DIRECT_IO
>>>>   - sync write,  invalidate in fuse_send_write()
>>>>   - async write, invalidate in fuse_aio_complete() with FUSE_ASYNC_DIO,
>>>>                  fuse_send_write() otherwise
>>>> - without FOPEN_DIRECT_IO
>>>>   - sync write,  invalidate in generic_file_direct_write()
>>>>   - async write, invalidate in fuse_aio_complete() with FUSE_ASYNC_DIO,
>>>>                  generic_file_direct_write() otherwise
>>>>
>>>> Reviewed-by: Bernd Schubert <bschubert@ddn.com>
>>>> Signed-off-by: Jingbo Xu <jefflexu@linux.alibaba.com>
>>>
>>> Applied, thanks.
>>>
>>
>> Hi Miklos,
>>
>> just back from a week off and we got a QA report last week. This commit
>> leads to a deadlock. Is there a chance you can revert and not send it
>> to Linus yet? 
>>
>> [Wed Feb 25 07:14:29 2026] INFO: task clt_reactor_3:49041 blocked for more than 122 seconds.
>> [Wed Feb 25 07:14:29 2026]       Tainted: G           OE      6.8.0-79-generic #79-Ubuntu
>> [Wed Feb 25 07:14:29 2026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> [Wed Feb 25 07:14:29 2026] task:clt_reactor_3   state:D stack:0     pid:49041 tgid:49014 ppid:1      flags:0x00000006
>> [Wed Feb 25 07:14:29 2026] Call Trace:
>> [Wed Feb 25 07:14:29 2026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> [Wed Feb 25 07:14:29 2026] task:clt_reactor_3   state:D stack:0     pid:49041 tgid:49014 ppid:1      flags:0x00000006
>> [Wed Feb 25 07:14:29 2026] Call Trace:
>> [Wed Feb 25 07:14:29 2026]  <TASK>
>> [Wed Feb 25 07:14:29 2026]  __schedule+0x27c/0x6b0
>> [Wed Feb 25 07:14:29 2026]  schedule+0x33/0x110
>> [Wed Feb 25 07:14:29 2026]  io_schedule+0x46/0x80
>> [Wed Feb 25 07:14:29 2026]  folio_wait_bit_common+0x136/0x330
>> [Wed Feb 25 07:14:29 2026]  __folio_lock+0x17/0x30
>> [Wed Feb 25 07:14:29 2026]  invalidate_inode_pages2_range+0x1d2/0x4f0
>> [Wed Feb 25 07:14:29 2026]  fuse_aio_complete+0x258/0x270 [fuse]
>> [Wed Feb 25 07:14:29 2026]  fuse_aio_complete_req+0x87/0xd0 [fuse]
>> [Wed Feb 25 07:14:29 2026]  fuse_request_end+0x18e/0x200 [fuse]
>> [Wed Feb 25 07:14:29 2026]  fuse_uring_req_end+0x87/0xd0 [fuse]
>> [Wed Feb 25 07:14:29 2026]  fuse_uring_cmd+0x241/0xf20 [fuse]
>> [Wed Feb 25 07:14:29 2026]  io_uring_cmd+0x9f/0x140
>> [Wed Feb 25 07:14:29 2026]  io_issue_sqe+0x193/0x410
>> [Wed Feb 25 07:14:29 2026]  io_submit_sqes+0x128/0x3e0
>> [Wed Feb 25 07:14:29 2026]  __do_sys_io_uring_enter+0x2ea/0x490
>> [Wed Feb 25 07:14:29 2026]  __x64_sys_io_uring_enter+0x22/0x40

I can reproduce it with xfstests generic/451 with io_uring enabled.


>>
>>
>> Issue is that invalidate_inode_pages2_range() might trigger another
>> write to the same core (in our case a reactor / coroutine) and
>> then deadlocks.
>> Cheng suggests to offload that into a worker queue, but FOPEN_DIRECT_IO
>> code starts to get complex - I'm more inclined to get back to my patches
>> from about 3 years ago that the unified the DIO handlers and let it go
>> through the normal vfs handlers.
>>
> 
> Hmm, maybe in the short term maybe the better solution is to update the
> patch (not posted to the list) that Cheng made and to use
> i_sb->s_dio_done_wq similar to what iomap_dio_bio_end_io() does.

Hi Bernd, would Cheng mind sending the patch out and I could help review
together :)

-- 
Thanks,
Jingbo

Re: [PATCH v3] fuse: invalidate the page cache after direct write

[Jingbo Xu]

On 3/3/26 5:19 AM, Bernd Schubert wrote:
> 
> 
> On 3/2/26 20:29, Bernd Schubert wrote:
>>
>>
>> On 2/27/26 16:09, Miklos Szeredi wrote:
>>> On Sun, 11 Jan 2026 at 08:37, Jingbo Xu <jefflexu@linux.alibaba.com> wrote:
>>>>
>>>> This fixes xfstests generic/451 (for both O_DIRECT and FOPEN_DIRECT_IO
>>>> direct write).
>>>>
>>>> Commit b359af8275a9 ("fuse: Invalidate the page cache after
>>>> FOPEN_DIRECT_IO write") tries to fix the similar issue for
>>>> FOPEN_DIRECT_IO write, which can be reproduced by xfstests generic/209.
>>>> It only fixes the issue for synchronous direct write, while omitting
>>>> the case for asynchronous direct write (exactly targeted by
>>>> generic/451).
>>>>
>>>> While for O_DIRECT direct write, it's somewhat more complicated.  For
>>>> synchronous direct write, generic_file_direct_write() will invalidate
>>>> the page cache after the write, and thus it can pass generic/209.  While
>>>> for asynchronous direct write, the invalidation in
>>>> generic_file_direct_write() is bypassed since the invalidation shall be
>>>> done when the asynchronous IO completes.  This is omitted in FUSE and
>>>> generic/451 fails whereby.
>>>>
>>>> Fix this by conveying the invalidation for both synchronous and
>>>> asynchronous write.
>>>>
>>>> - with FOPEN_DIRECT_IO
>>>>   - sync write,  invalidate in fuse_send_write()
>>>>   - async write, invalidate in fuse_aio_complete() with FUSE_ASYNC_DIO,
>>>>                  fuse_send_write() otherwise
>>>> - without FOPEN_DIRECT_IO
>>>>   - sync write,  invalidate in generic_file_direct_write()
>>>>   - async write, invalidate in fuse_aio_complete() with FUSE_ASYNC_DIO,
>>>>                  generic_file_direct_write() otherwise
>>>>
>>>> Reviewed-by: Bernd Schubert <bschubert@ddn.com>
>>>> Signed-off-by: Jingbo Xu <jefflexu@linux.alibaba.com>
>>>
>>> Applied, thanks.
>>>
>>
>> Hi Miklos,
>>
>> just back from a week off and we got a QA report last week. This commit
>> leads to a deadlock. Is there a chance you can revert and not send it
>> to Linus yet? 
>>
>> [Wed Feb 25 07:14:29 2026] INFO: task clt_reactor_3:49041 blocked for more than 122 seconds.
>> [Wed Feb 25 07:14:29 2026]       Tainted: G           OE      6.8.0-79-generic #79-Ubuntu
>> [Wed Feb 25 07:14:29 2026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> [Wed Feb 25 07:14:29 2026] task:clt_reactor_3   state:D stack:0     pid:49041 tgid:49014 ppid:1      flags:0x00000006
>> [Wed Feb 25 07:14:29 2026] Call Trace:
>> [Wed Feb 25 07:14:29 2026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> [Wed Feb 25 07:14:29 2026] task:clt_reactor_3   state:D stack:0     pid:49041 tgid:49014 ppid:1      flags:0x00000006
>> [Wed Feb 25 07:14:29 2026] Call Trace:
>> [Wed Feb 25 07:14:29 2026]  <TASK>
>> [Wed Feb 25 07:14:29 2026]  __schedule+0x27c/0x6b0
>> [Wed Feb 25 07:14:29 2026]  schedule+0x33/0x110
>> [Wed Feb 25 07:14:29 2026]  io_schedule+0x46/0x80
>> [Wed Feb 25 07:14:29 2026]  folio_wait_bit_common+0x136/0x330
>> [Wed Feb 25 07:14:29 2026]  __folio_lock+0x17/0x30
>> [Wed Feb 25 07:14:29 2026]  invalidate_inode_pages2_range+0x1d2/0x4f0
>> [Wed Feb 25 07:14:29 2026]  fuse_aio_complete+0x258/0x270 [fuse]
>> [Wed Feb 25 07:14:29 2026]  fuse_aio_complete_req+0x87/0xd0 [fuse]
>> [Wed Feb 25 07:14:29 2026]  fuse_request_end+0x18e/0x200 [fuse]
>> [Wed Feb 25 07:14:29 2026]  fuse_uring_req_end+0x87/0xd0 [fuse]
>> [Wed Feb 25 07:14:29 2026]  fuse_uring_cmd+0x241/0xf20 [fuse]
>> [Wed Feb 25 07:14:29 2026]  io_uring_cmd+0x9f/0x140
>> [Wed Feb 25 07:14:29 2026]  io_issue_sqe+0x193/0x410
>> [Wed Feb 25 07:14:29 2026]  io_submit_sqes+0x128/0x3e0
>> [Wed Feb 25 07:14:29 2026]  __do_sys_io_uring_enter+0x2ea/0x490
>> [Wed Feb 25 07:14:29 2026]  __x64_sys_io_uring_enter+0x22/0x40
>>
>>
>> Issue is that invalidate_inode_pages2_range() might trigger another
>> write to the same core (in our case a reactor / coroutine) and
>> then deadlocks.

Besides I don't know why the process hangs in folio_lock() (inside
invalidate_inode_pages2_range()) rather than folio_wait_writeback() in
fuse_launder_folio(), if the root issue is that
invalidate_inode_pages2_range() triggers another write.


>> Cheng suggests to offload that into a worker queue, but FOPEN_DIRECT_IO
>> code starts to get complex - I'm more inclined to get back to my patches
>> from about 3 years ago that the unified the DIO handlers and let it go
>> through the normal vfs handlers.
>>
> 
> Hmm, maybe in the short term maybe the better solution is to update the
> patch (not posted to the list) that Cheng made and to use
> i_sb->s_dio_done_wq similar to what iomap_dio_bio_end_io() does.

BTW I also spent some time on this this morning, as the previous patch
is already pending in our internal release.  Let me know if Cheng would
like to send a patch ;)

-- 
Thanks,
Jingbo