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
| ||
|
Date: Tue, 22 Oct 2019 13:07:17 +1100 From: Matthew Bobrowski <mbobrowski@...browski.org> To: Jan Kara <jack@...e.cz> Cc: tytso@....edu, adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org, hch@...radead.org, david@...morbit.com, darrick.wong@...cle.com Subject: Re: [PATCH v5 09/12] ext4: move inode extension/truncate code out from ->iomap_end() callback On Mon, Oct 21, 2019 at 03:53:37PM +0200, Jan Kara wrote: > On Mon 21-10-19 20:18:56, Matthew Bobrowski wrote: > > In preparation for implementing the iomap direct I/O modifications, > > the inode extension/truncate code needs to be moved out from the > > ext4_iomap_end() callback. For direct I/O, if the current code > > remained, it would behave incorrrectly. Updating the inode size prior > > to converting unwritten extents would potentially allow a racing > > direct I/O read to find unwritten extents before being converted > > correctly. > > > > The inode extension/truncate code now resides within a new helper > > ext4_handle_inode_extension(). This function has been designed so that > > it can accommodate for both DAX and direct I/O extension/truncate > > operations. > > > > Signed-off-by: Matthew Bobrowski <mbobrowski@...browski.org> > > --- > > fs/ext4/file.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++++- > > fs/ext4/inode.c | 48 +-------------------------------- > > 2 files changed, 71 insertions(+), 48 deletions(-) > > > > The patch looks good to me. You can add: > > Reviewed-by: Jan Kara <jack@...e.cz> Thank you! > > +static ssize_t ext4_handle_inode_extension(struct inode *inode, ssize_t written, > > + loff_t offset, size_t count) > > IMHO a bit more logical ordering of arguments would be 'inode, offset, > written, count'... Funnily enough, I originally had the arguments ordered as you've suggested, but then decided to reorder them this way last minute. No objections to reshuffling them around. --<M>--
Powered by blists - more mailing lists