All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: linux-fsdevel@vger.kernel.org, linux-aio@kvack.org,
	Christoph Hellwig <hch@lst.de>,
	xfs@oss.sgi.com
Subject: aio completions vs file_accessed race, was: Re: [PATCH 7/8] xfs: split direct I/O and DAX path
Date: Thu, 29 Sep 2016 10:38:24 +0200	[thread overview]
Message-ID: <20160929083824.GA12799@lst.de> (raw)
In-Reply-To: <20160929025351.GB4901@birch.djwong.org>

On Wed, Sep 28, 2016 at 07:53:52PM -0700, Darrick J. Wong wrote:
> So I noticed that generic/323 starts crashing in file_accessed -> touch_atime
> because iocb->ki_filp->f_path.dentry == NULL.  For a while I thought it was
> some weird reflink bug, but I finally had time to go build a vanilla 4.8-rc8
> kernel and that blew up here too.  I'm not sure why this line got inserted
> here, since it wasn't there prior to this patch, AFAICT.

This line was there before near the end of xfs_file_dio_aio_read already,
e.g. line 376 just before the above commit, but it only got introduced
a bit earlier in "xfs: stop using generic_file_read_iter for direct I/O",
which copied it over from generic_file_read_iter.  І think any new
issues in these commits could just be a minor timing change, as
we're not changing struct file refcounting in any way here.

generic/323 reproduces the last struct file reference being dropped
by aio completions, so it seems like we have an issue here, which
I suspect is something in the common code.  I can't reproduce it
locally, but looking at the aio_complete -> kiocb_free callchain
and the lack of other struct file refcounting in aio.c it seems
inherently unsafe to reference struct file once the completion
may have run, that is after (__)blkdev_direct_IO returned.

I'll see if I can come up with a solution for that, most likely
that would involve moving the file_accessed call into __blkdev_direct_IO
before we drop the final reference on the dio structure.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>,
	xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org,
	linux-aio@kvack.org
Subject: aio completions vs file_accessed race, was: Re: [PATCH 7/8] xfs: split direct I/O and DAX path
Date: Thu, 29 Sep 2016 10:38:24 +0200	[thread overview]
Message-ID: <20160929083824.GA12799@lst.de> (raw)
In-Reply-To: <20160929025351.GB4901@birch.djwong.org>

On Wed, Sep 28, 2016 at 07:53:52PM -0700, Darrick J. Wong wrote:
> So I noticed that generic/323 starts crashing in file_accessed -> touch_atime
> because iocb->ki_filp->f_path.dentry == NULL.  For a while I thought it was
> some weird reflink bug, but I finally had time to go build a vanilla 4.8-rc8
> kernel and that blew up here too.  I'm not sure why this line got inserted
> here, since it wasn't there prior to this patch, AFAICT.

This line was there before near the end of xfs_file_dio_aio_read already,
e.g. line 376 just before the above commit, but it only got introduced
a bit earlier in "xfs: stop using generic_file_read_iter for direct I/O",
which copied it over from generic_file_read_iter.  І think any new
issues in these commits could just be a minor timing change, as
we're not changing struct file refcounting in any way here.

generic/323 reproduces the last struct file reference being dropped
by aio completions, so it seems like we have an issue here, which
I suspect is something in the common code.  I can't reproduce it
locally, but looking at the aio_complete -> kiocb_free callchain
and the lack of other struct file refcounting in aio.c it seems
inherently unsafe to reference struct file once the completion
may have run, that is after (__)blkdev_direct_IO returned.

I'll see if I can come up with a solution for that, most likely
that would involve moving the file_accessed call into __blkdev_direct_IO
before we drop the final reference on the dio structure.

  reply	other threads:[~2016-09-29  8:38 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-22 15:27 xfs: untangle the direct I/O and DAX path, fix DAX locking Christoph Hellwig
2016-06-22 15:27 ` Christoph Hellwig
2016-06-22 15:27 ` Christoph Hellwig
     [not found] ` <1466609236-23801-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
2016-06-22 15:27   ` [PATCH 1/8] xfs: don't pass ioflags around in the ioctl path Christoph Hellwig
2016-06-22 15:27     ` Christoph Hellwig
2016-06-22 15:27     ` Christoph Hellwig
2016-06-22 15:27   ` [PATCH 2/8] xfs: kill ioflags Christoph Hellwig
2016-06-22 15:27     ` Christoph Hellwig
2016-06-22 15:27     ` Christoph Hellwig
2016-06-22 15:27   ` [PATCH 3/8] xfs: remove s_maxbytes enforcement in xfs_file_read_iter Christoph Hellwig
2016-06-22 15:27     ` Christoph Hellwig
2016-06-22 15:27     ` Christoph Hellwig
2016-06-22 15:27   ` [PATCH 4/8] xfs: split xfs_file_read_iter into buffered and direct I/O helpers Christoph Hellwig
2016-06-22 15:27     ` Christoph Hellwig
2016-06-22 15:27     ` Christoph Hellwig
2016-06-22 15:27   ` [PATCH 5/8] xfs: stop using generic_file_read_iter for direct I/O Christoph Hellwig
2016-06-22 15:27     ` Christoph Hellwig
2016-06-22 15:27     ` Christoph Hellwig
2016-06-22 15:27   ` [PATCH 6/8] xfs: direct calls in the direct I/O path Christoph Hellwig
2016-06-22 15:27     ` Christoph Hellwig
2016-06-22 15:27     ` Christoph Hellwig
2016-06-22 15:27   ` [PATCH 7/8] xfs: split direct I/O and DAX path Christoph Hellwig
2016-06-22 15:27     ` Christoph Hellwig
2016-06-22 15:27     ` Christoph Hellwig
     [not found]     ` <1466609236-23801-8-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
2016-09-29  2:53       ` Darrick J. Wong
2016-09-29  2:53         ` Darrick J. Wong
2016-09-29  2:53         ` Darrick J. Wong
2016-09-29  8:38         ` Christoph Hellwig [this message]
2016-09-29  8:38           ` aio completions vs file_accessed race, was: " Christoph Hellwig
2016-09-29 20:18           ` Christoph Hellwig
2016-09-29 20:18             ` Christoph Hellwig
2016-09-29 20:18             ` Christoph Hellwig
2016-09-29 20:18               ` Christoph Hellwig
2016-09-29 20:33               ` Darrick J. Wong
2016-09-29 20:33                 ` Darrick J. Wong
2016-06-22 15:27   ` [PATCH 8/8] xfs: fix locking for DAX writes Christoph Hellwig
2016-06-22 15:27     ` Christoph Hellwig
2016-06-22 15:27     ` Christoph Hellwig
2016-06-23 14:22     ` Boaz Harrosh
2016-06-23 14:22       ` Boaz Harrosh
2016-06-23 23:24   ` xfs: untangle the direct I/O and DAX path, fix DAX locking Dave Chinner
2016-06-23 23:24     ` Dave Chinner
2016-06-23 23:24     ` Dave Chinner
2016-06-24  1:14     ` Dan Williams
2016-06-24  1:14       ` Dan Williams
2016-06-24  7:13       ` Dave Chinner
2016-06-24  7:13         ` Dave Chinner
2016-06-24  7:31         ` Christoph Hellwig
2016-06-24  7:31           ` Christoph Hellwig
2016-06-24  7:26     ` Christoph Hellwig
2016-06-24  7:26       ` Christoph Hellwig
2016-06-24  7:26       ` Christoph Hellwig
2016-06-24 23:00       ` Dave Chinner
2016-06-24 23:00         ` Dave Chinner
2016-06-28 13:10         ` Christoph Hellwig
2016-06-28 13:10           ` Christoph Hellwig
2016-06-28 13:10           ` Christoph Hellwig
     [not found]           ` <20160628131059.GA30475-jcswGhMUV9g@public.gmane.org>
2016-06-28 13:27             ` Boaz Harrosh
2016-06-28 13:27               ` Boaz Harrosh
2016-06-28 13:27               ` Boaz Harrosh
     [not found]               ` <57727B27.7060104-/8YdC2HfS5554TAoqtyWWQ@public.gmane.org>
2016-06-28 13:39                 ` Christoph Hellwig
2016-06-28 13:39                   ` Christoph Hellwig
2016-06-28 13:39                   ` Christoph Hellwig
     [not found]                   ` <20160628133928.GB31283-jcswGhMUV9g@public.gmane.org>
2016-06-28 13:56                     ` Boaz Harrosh
2016-06-28 13:56                       ` Boaz Harrosh
2016-06-28 13:56                       ` Boaz Harrosh
     [not found]                       ` <5772820E.2080403-/8YdC2HfS5554TAoqtyWWQ@public.gmane.org>
2016-06-28 15:39                         ` Christoph Hellwig
2016-06-28 15:39                           ` Christoph Hellwig
2016-06-28 15:39                           ` Christoph Hellwig
     [not found]                           ` <20160628153925.GA2643-jcswGhMUV9g@public.gmane.org>
2016-06-29 12:23                             ` Boaz Harrosh
2016-06-29 12:23                               ` Boaz Harrosh
2016-06-29 12:23                               ` Boaz Harrosh

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=20160929083824.GA12799@lst.de \
    --to=hch@lst.de \
    --cc=darrick.wong@oracle.com \
    --cc=linux-aio@kvack.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=xfs@oss.sgi.com \
    /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.