linux-kernel - Re: [PATCH 06/16] vfs: Rename generic_file_aio_write

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: <20090903153722.GA19337@lst.de>
Date:	Thu, 3 Sep 2009 17:37:22 +0200
From:	Christoph Hellwig <hch@....de>
To:	Jan Kara <jack@...e.cz>
Cc:	Christoph Hellwig <hch@....de>, linux-fsdevel@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 06/16] vfs: Rename generic_file_aio_write_nolock

On Thu, Sep 03, 2009 at 12:24:36PM +0200, Jan Kara wrote:
> > Move it to fs/block_dev.c, rename it to blkdev_aio_write, export it _GPL
> > only and make it very clear it's only for block devices and raw.
>   Yes, fine with me. I'll replace my patch with yours so that we don't
> rename the function twice unnecessarily.

It's not a replacement, it's ontop of yours.  But folding it into yours
would make a lot of sense.

> > And btw, I'm not actually sure it is the right thing for raw.  Raw is
> > supposed to do direct I/O only, and in fact forced O_DIRECT on.  Because
> > there are no holes it also can't fall back to direct I/O.  So strictly
> > spreaking we could just use __generic_file_aio_write directly.   That
> > is until we care about the hw disk caches..
>   I'm slightly confused with the above - probably you mean it cannot fall
> back to buffered I/O and it could use generic_file_direct_write (because
> __generic_file_aio_write is just blkdev_aio_write without syncing in case
> of O_SYNC).

It can not fall back to buffered I/O, yes.  Any given that it does not
not do buffered I/O and the block/raw device also doesn' have any
inode metadata we could just use __generic_file_aio_write directly.
That is until my patch to flush the disk cache in ->fsync goes in in
which case we'll at least need that one again.  But we might just be
better off to opencode that instead of really using fsync - that avoids
the superflous call to filemap_write_and_wait and performs the cache
flush without i_mutex which we don't need.

That is the story for the block device, now the raw device is more
difficult as I would be surprised if the user of it used fsync on it.
Then again that would require us to find those users first, although
they apparently exist as removal of this horrible raw device feature
was vetoed by the big distros.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/