linux-ext4 - Re: [PATCH v10 0/5] add support for direct I/O with fscrypt using blk-crypto

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: <YgMUa2Cdr/QoMTPh@sol.localdomain>
Date:   Tue, 8 Feb 2022 17:10:03 -0800
From:   Eric Biggers <ebiggers@...nel.org>
To:     Dave Chinner <david@...morbit.com>
Cc:     "Darrick J. Wong" <djwong@...nel.org>,
        Christoph Hellwig <hch@...radead.org>,
        linux-fscrypt@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
        linux-xfs@...r.kernel.org, Theodore Ts'o <tytso@....edu>,
        Jaegeuk Kim <jaegeuk@...nel.org>, Chao Yu <chao@...nel.org>
Subject: Re: [PATCH v10 0/5] add support for direct I/O with fscrypt using
 blk-crypto

On Mon, Jan 24, 2022 at 10:03:32AM +1100, Dave Chinner wrote:
> > 
> > 	/* 0xa0 */
> > 
> > 	/* File range alignment needed for best performance, in bytes. */
> > 	__u32	stx_dio_fpos_align_opt;
> 
> This is a common property of both DIO and buffered IO, so no need
> for it to be dio-only property.
> 
> 	__u32	stx_offset_align_optimal;
> 

Looking at this more closely: will stx_offset_align_optimal actually be useful,
given that st[x]_blksize already exists?

>From the stat(2) and statx(2) man pages:

	st_blksize
		This field  gives  the  "preferred"  block  size  for  efficient
		filesystem I/O.

	stx_blksize
		The "preferred" block size for efficient filesystem I/O.  (Writ‐
		ing  to  a file in smaller chunks may cause an inefficient read-
		modify-rewrite.)

File offsets aren't explicitly mentioned, but I think it's implied they should
be a multiple of st[x]_blksize, just like the I/O size.  Otherwise, the I/O
would obviously require reading/writing partial blocks.

So, the proposed stx_offset_align_optimal field sounds like the same thing to
me.  Is there anything I'm misunderstanding?

Putting stx_offset_align_optimal behind the STATX_DIRECTIO flag would also be
confusing if it would apply to both direct and buffered I/O.

- Eric