linux-ext4 - Re: [PATCH 4/4] hfs: enable uncached buffer io support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9d9d7bbab5443bd1c3dfd7d81d9bc91debecf4ef.camel@dubeyko.com>
Date: Fri, 04 Jul 2025 10:37:52 -0700
From: Viacheslav Dubeyko <slava@...eyko.com>
To: Yangtao Li <frank.li@...o.com>, axboe@...nel.dk,
 aivazian.tigran@...il.com, 	viro@...iv.linux.org.uk, brauner@...nel.org,
 jack@...e.cz, linkinjeon@...nel.org, 	sj1557.seo@...sung.com,
 yuezhang.mo@...y.com, glaubitz@...sik.fu-berlin.de, 	shaggy@...nel.org,
 konishi.ryusuke@...il.com, 	almaz.alexandrovich@...agon-software.com,
 me@...copeland.com, 	willy@...radead.org, josef@...icpanda.com,
 kovalev@...linux.org, dave@...olabs.net, 	mhocko@...e.com,
 chentaotao@...iglobal.com
Cc: linux-block@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org, 
	jfs-discussion@...ts.sourceforge.net, linux-nilfs@...r.kernel.org, 
	ntfs3@...ts.linux.dev, linux-karma-devel@...ts.sourceforge.net, 
	bpf@...r.kernel.org
Subject: Re: [PATCH 4/4] hfs: enable uncached buffer io support

On Thu, 2025-06-26 at 11:30 -0600, Yangtao Li wrote:
> Now cont_write_begin() support DONTCACHE mode, let's set
> FOP_DONTCACHE
> flag to enable uncached buffer io support for hfs.
> 
> Signed-off-by: Yangtao Li <frank.li@...o.com>
> ---
>  fs/hfs/inode.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/hfs/inode.c b/fs/hfs/inode.c
> index 8409e4412366..a62f45e9745d 100644
> --- a/fs/hfs/inode.c
> +++ b/fs/hfs/inode.c
> @@ -695,6 +695,7 @@ static const struct file_operations
> hfs_file_operations = {
>  	.fsync		= hfs_file_fsync,
>  	.open		= hfs_file_open,
>  	.release	= hfs_file_release,
> +	.fop_flags	= FOP_DONTCACHE,
>  };
>  
>  static const struct inode_operations hfs_file_inode_operations = {

Frankly speaking, I am not convinced that HFS really need to support
this feature. It is old and pretty obsolete file system. The main use-
case is simply support the capability to mount HFS volume is created
under Mac OS X, for example, and to access the data there. Of course,
we can support this feature, but what is the point of this?

As far as I can see, the goal of RWF_DONTCACHE feature is:

"Common for both reads and writes with RWF_DONTCACHE is that they use
the page cache for IO. Reads work just like a normal buffered read
would, with the only exception being that the touched ranges will get
pruned after data has been copied. For writes, the ranges will get
writeback kicked off before the syscall returns, and then writeback
completion will prune the range."

So, who would like to see such efficiency in HFS? Do we really need to
support it in HFS? I think that it is not.

Thanks,
Slava.