All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Goldwyn Rodrigues <rgoldwyn@suse.de>,
	linux-fsdevel@vger.kernel.org, linux-btrfs@vger.kernel.org,
	david@fromorbit.com, hch@lst.de, johannes.thumshirn@wdc.com,
	dsterba@suse.com, josef@toxicpanda.com,
	Goldwyn Rodrigues <rgoldwyn@suse.com>
Subject: Re: [PATCH 04/14] iomap: Call inode_dio_end() before generic_write_sync()
Date: Mon, 28 Sep 2020 17:04:19 +0200	[thread overview]
Message-ID: <20200928150418.GC6756@twin.jikos.cz> (raw)
In-Reply-To: <20200926015108.GQ7964@magnolia>

On Fri, Sep 25, 2020 at 06:51:08PM -0700, Darrick J. Wong wrote:
> On Thu, Sep 24, 2020 at 11:39:11AM -0500, Goldwyn Rodrigues wrote:
> > From: Goldwyn Rodrigues <rgoldwyn@suse.com>
> > 
> > iomap complete routine can deadlock with btrfs_fallocate because of the
> > call to generic_write_sync().
> > 
> > P0                      P1
> > inode_lock()            fallocate(FALLOC_FL_ZERO_RANGE)
> > __iomap_dio_rw()        inode_lock()
> >                         <block>
> > <submits IO>
> > <completes IO>
> > inode_unlock()
> >                         <gets inode_lock()>
> >                         inode_dio_wait()
> > iomap_dio_complete()
> >   generic_write_sync()
> >     btrfs_file_fsync()
> >       inode_lock()
> >       <deadlock>
> > 
> > inode_dio_end() is used to notify the end of DIO data in order
> > to synchronize with truncate. Call inode_dio_end() before calling
> > generic_write_sync(), so filesystems can lock i_rwsem during a sync.
> > 
> > This matches the way it is done in fs/direct-io.c:dio_complete().
> > 
> > Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
> > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > Reviewed-by: Josef Bacik <josef@toxicpanda.com>
> 
> Looks ok (at least with the fses that use either iomap or ye olde
> directio) to me...
> 
> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
> 
> So, uh, do you want me to pull these two iomap patches in for 5.10?

That would be great, thanks. Once they land in 5.10-rc we'll be able to
base the rest on some master snapshot and target 5.11 for release.

  reply	other threads:[~2020-09-28 15:05 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-24 16:39 [PATCH 0/14 v3] BTRFS DIO inode locking/D_SYNC fix Goldwyn Rodrigues
2020-09-24 16:39 ` [PATCH 01/14] fs: remove dio_end_io() Goldwyn Rodrigues
2020-09-29 12:16   ` David Sterba
2020-09-24 16:39 ` [PATCH 02/14] btrfs: remove BTRFS_INODE_READDIO_NEED_LOCK Goldwyn Rodrigues
2020-09-24 16:39 ` [PATCH 03/14] iomap: Allow filesystem to call iomap_dio_complete without i_rwsem Goldwyn Rodrigues
2020-09-26  1:49   ` Darrick J. Wong
2020-09-24 16:39 ` [PATCH 04/14] iomap: Call inode_dio_end() before generic_write_sync() Goldwyn Rodrigues
2020-09-26  1:51   ` Darrick J. Wong
2020-09-28 15:04     ` David Sterba [this message]
2020-09-28 16:12       ` Darrick J. Wong
2020-09-24 16:39 ` [PATCH 05/14] btrfs: split btrfs_direct_IO to read and write Goldwyn Rodrigues
2020-09-24 16:39 ` [PATCH 06/14] btrfs: Move pos increment and pagecache extension to btrfs_buffered_write() Goldwyn Rodrigues
2020-09-24 16:39 ` [PATCH 07/14] btrfs: Move FS error state bit early during write Goldwyn Rodrigues
2020-09-24 16:39 ` [PATCH 08/14] btrfs: Introduce btrfs_write_check() Goldwyn Rodrigues
2020-10-09 14:21   ` Josef Bacik
2020-09-24 16:39 ` [PATCH 09/14] btrfs: Introduce btrfs_inode_lock()/unlock() Goldwyn Rodrigues
2020-09-24 16:39 ` [PATCH 10/14] btrfs: Push inode locking and unlocking into buffered/direct write Goldwyn Rodrigues
2020-09-24 16:39 ` [PATCH 11/14] btrfs: Use inode_lock_shared() for direct writes within EOF Goldwyn Rodrigues
2020-10-09 14:25   ` Josef Bacik
2020-09-24 16:39 ` [PATCH 12/14] btrfs: Remove dio_sem Goldwyn Rodrigues
2020-09-24 16:39 ` [PATCH 13/14] btrfs: Call iomap_dio_complete() without inode_lock Goldwyn Rodrigues
2020-09-24 16:39 ` [PATCH 14/14] btrfs: Revert 09745ff88d93 ("btrfs: dio iomap DSYNC workaround") Goldwyn Rodrigues

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=20200928150418.GC6756@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=dsterba@suse.com \
    --cc=hch@lst.de \
    --cc=johannes.thumshirn@wdc.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=rgoldwyn@suse.com \
    --cc=rgoldwyn@suse.de \
    /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.