From: Christoph Hellwig <hch@infradead.org>
To: Matthew Bobrowski <mbobrowski@mbobrowski.org>
Cc: tytso@mit.edu, jack@suse.cz, adilger.kernel@dilger.ca,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
david@fromorbit.com, hch@infradead.org, darrick.wong@oracle.com
Subject: Re: [PATCH v3 5/6] ext4: introduce direct IO write path using iomap infrastructure
Date: Mon, 16 Sep 2019 05:12:48 -0700 [thread overview]
Message-ID: <20190916121248.GD4005@infradead.org> (raw)
In-Reply-To: <db33705f9ba35ccbe20fc19b8ecbbf2078beff08.1568282664.git.mbobrowski@mbobrowski.org>
On Thu, Sep 12, 2019 at 09:04:46PM +1000, Matthew Bobrowski wrote:
> @@ -213,12 +214,16 @@ static ssize_t ext4_write_checks(struct kiocb *iocb, struct iov_iter *from)
> struct inode *inode = file_inode(iocb->ki_filp);
> ssize_t ret;
>
> + if (unlikely(IS_IMMUTABLE(inode)))
> + return -EPERM;
> +
> ret = generic_write_checks(iocb, from);
> if (ret <= 0)
> return ret;
>
> - if (unlikely(IS_IMMUTABLE(inode)))
> - return -EPERM;
> + ret = file_modified(iocb->ki_filp);
> + if (ret)
> + return 0;
>
> /*
> * If we have encountered a bitmap-format file, the size limit
Independent of the error return issue you probably want to split
modifying ext4_write_checks into a separate preparation patch.
> +/*
> + * For a write that extends the inode size, ext4_dio_write_iter() will
> + * wait for the write to complete. Consequently, operations performed
> + * within this function are still covered by the inode_lock(). On
> + * success, this function returns 0.
> + */
> +static int ext4_dio_write_end_io(struct kiocb *iocb, ssize_t size, int error,
> + unsigned int flags)
> +{
> + int ret;
> + loff_t offset = iocb->ki_pos;
> + struct inode *inode = file_inode(iocb->ki_filp);
> +
> + if (error) {
> + ret = ext4_handle_failed_inode_extension(inode, offset + size);
> + return ret ? ret : error;
> + }
Just a personal opinion, but I find the use of the ternary operator
here a little weird.
A plain old:
ret = ext4_handle_failed_inode_extension(inode, offset + size);
if (ret)
return ret;
return error;
flow much easier.
> + if (!inode_trylock(inode)) {
> + if (iocb->ki_flags & IOCB_NOWAIT)
> + return -EAGAIN;
> + inode_lock(inode);
> + }
> +
> + if (!ext4_dio_checks(inode)) {
> + inode_unlock(inode);
> + /*
> + * Fallback to buffered IO if the operation on the
> + * inode is not supported by direct IO.
> + */
> + return ext4_buffered_write_iter(iocb, from);
I think you want to lift the locking into the caller of this function
so that you don't have to unlock and relock for the buffered write
fallback.
> + if (offset + count > i_size_read(inode) ||
> + offset + count > EXT4_I(inode)->i_disksize) {
> + ext4_update_i_disksize(inode, inode->i_size);
> + extend = true;
Doesn't the ext4_update_i_disksize need to be under an open journal
handle?
next prev parent reply other threads:[~2019-09-16 12:12 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-12 11:03 [PATCH v3 0/6] ext4: port direct IO to iomap infrastructure Matthew Bobrowski
2019-09-12 11:03 ` [PATCH v3 1/6] ext4: introduce direct IO read path using " Matthew Bobrowski
2019-09-16 12:00 ` Christoph Hellwig
2019-09-16 13:07 ` Matthew Bobrowski
2019-09-12 11:04 ` [PATCH v3 2/6] ext4: move inode extension/truncate code out from ext4_iomap_end() Matthew Bobrowski
2019-09-23 16:21 ` Jan Kara
2019-09-24 9:50 ` Matthew Bobrowski
2019-09-24 13:13 ` Jan Kara
2019-09-12 11:04 ` [PATCH v3 3/6] iomap: split size and error for iomap_dio_rw ->end_io Matthew Bobrowski
2019-09-12 11:04 ` [PATCH v3 4/6] ext4: reorder map.m_flags checks in ext4_iomap_begin() Matthew Bobrowski
2019-09-16 12:05 ` Christoph Hellwig
2019-09-17 12:48 ` Matthew Bobrowski
2019-09-23 15:08 ` Jan Kara
2019-09-24 9:35 ` Matthew Bobrowski
2019-09-12 11:04 ` [PATCH v3 5/6] ext4: introduce direct IO write path using iomap infrastructure Matthew Bobrowski
2019-09-16 4:37 ` Ritesh Harjani
2019-09-16 10:14 ` Matthew Bobrowski
2019-09-16 12:12 ` Christoph Hellwig [this message]
2019-09-16 22:37 ` Matthew Bobrowski
2019-09-17 9:00 ` Ritesh Harjani
2019-09-17 9:02 ` Christoph Hellwig
2019-09-17 10:12 ` Ritesh Harjani
2019-09-17 12:39 ` Matthew Bobrowski
2019-09-24 10:57 ` Jan Kara
2019-09-17 9:06 ` Christoph Hellwig
2019-09-17 11:31 ` Matthew Bobrowski
2019-09-20 13:24 ` Matthew Bobrowski
2019-09-23 21:10 ` Jan Kara
2019-09-24 10:29 ` Matthew Bobrowski
2019-09-24 14:13 ` Jan Kara
2019-09-25 7:14 ` Matthew Bobrowski
2019-09-25 8:40 ` Jan Kara
2019-09-12 11:05 ` [PATCH v3 6/6] ext4: cleanup legacy buffer_head direct IO code Matthew Bobrowski
2019-09-16 12:06 ` Christoph Hellwig
2019-09-16 12:53 ` Matthew Bobrowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190916121248.GD4005@infradead.org \
--to=hch@infradead.org \
--cc=adilger.kernel@dilger.ca \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mbobrowski@mbobrowski.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.