linux-ext4 - Re: [PATCH] ext4: set FMODE_CAN_ODIRECT instead of a dummy direct

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: <87wn0853pw.fsf@doe.com>
Date:   Tue, 13 Jun 2023 11:00:19 +0530
From:   Ritesh Harjani (IBM) <ritesh.list@...il.com>
To:     Christoph Hellwig <hch@....de>, tytso@....edu
Cc:     linux-ext4@...r.kernel.org
Subject: Re: [PATCH] ext4: set FMODE_CAN_ODIRECT instead of a dummy direct_IO method

Christoph Hellwig <hch@....de> writes:

> Since commit a2ad63daa88b ("VFS: add FMODE_CAN_ODIRECT file flag") file
> systems can just set the FMODE_CAN_ODIRECT flag at open time instead of
> wiring up a dummy direct_IO method to indicate support for direct I/O.
>
> Do that for ext4 so that noop_direct_IO can eventually be removed.

Looks straight forward change to me. 

However I got some query...

> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 02de439bf1f04e..b9c1cfa1864779 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -3573,7 +3571,6 @@ static const struct address_space_operations ext4_da_aops = {
>  	.bmap			= ext4_bmap,
>  	.invalidate_folio	= ext4_invalidate_folio,
>  	.release_folio		= ext4_release_folio,
> -	.direct_IO		= noop_direct_IO,
>  	.migrate_folio		= buffer_migrate_folio,
>  	.is_partially_uptodate  = block_is_partially_uptodate,
>  	.error_remove_page	= generic_error_remove_page,
> @@ -3582,7 +3579,6 @@ static const struct address_space_operations ext4_da_aops = {
>  
>  static const struct address_space_operations ext4_dax_aops = {
>  	.writepages		= ext4_dax_writepages,
> -	.direct_IO		= noop_direct_IO,
>  	.dirty_folio		= noop_dirty_folio,
>  	.bmap			= ext4_bmap,
>  	.swap_activate		= ext4_iomap_swap_activate,

why do we require .direct_IO function op for any of the dax_aops?
IIUC, any inode if it supports DAX i.e. IS_DAX(inode), then it takes the
separate path in file read/write iter path.

so it should never do ->direct_IO on an inode which supports DAX right?

Maybe I am missing something and I will have to check when does
->direct_IO gets called for DAX... 
   ... Or is it due to CONFIG_FS_DAX?

e.g. 

ext4_file_write_iter(struct kiocb *iocb, struct iov_iter *from)
{
	struct inode *inode = file_inode(iocb->ki_filp);

	if (unlikely(ext4_forced_shutdown(EXT4_SB(inode->i_sb))))
		return -EIO;

#ifdef CONFIG_FS_DAX
	if (IS_DAX(inode))
		return ext4_dax_write_iter(iocb, from);
#endif
	if (iocb->ki_flags & IOCB_DIRECT)
		return ext4_dio_write_iter(iocb, from);
	else
		return ext4_buffered_write_iter(iocb, from);
}

-ritesh