public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: xfs@oss.sgi.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements
Date: Thu, 26 Jun 2008 06:40:09 -0600	[thread overview]
Message-ID: <20080626124009.GY4392@parisc-linux.org> (raw)
In-Reply-To: <20080626122112.GL11558@disturbed>

On Thu, Jun 26, 2008 at 10:21:12PM +1000, Dave Chinner wrote:
> On Thu, Jun 26, 2008 at 05:42:42AM -0600, Matthew Wilcox wrote:
> > Then let's leave it as a semaphore.  You can get rid of the sema_t if
> > you like, but I don't think that turning completions into semaphores is
> > a good idea (because it's confusing).
> 
> So remind me what the point of the semaphore removal tree is again?

To remove the semaphores which don't need to be semaphores any more.

> As Christoph suggested, I can put this under another API that
> is implemented using completions. If I have to do that in XFS,
> so be it....

You could, yes.  But you could just use completions directly ...

> The main reason for this that we've just uncovered the fact that the
> way XFS uses semaphores is completely unsafe [*] on x86/x86_64 for
> kernels prior to the new generic semaphores.
> 
> [*] 2.6.20 panics in up() because of this race when I/O completion
> (the up call) races with a simultaneous down() (iowaiter):
> 
> 	T1		T2
> 	up()		down()
> 			kmem_free()
> 
> When the down() call completes, the up() call can still be
> referencing the semaphore, and hence if we free the structure after
> the down call then the up() will reference freed memory.  This is
> probably the cause of many unexplained log replay or unmount panics
> that we've been hitting for years with buffers that been freed while
> apparently still in use....

This is exactly the kind of thing completions were supposed to be used
for.  T1 should be calling complete() and T2 should be calling
wait_for_completion().

> Hence I'd prefer just to move completely away from semaphores for
> this flush interface.  I'd like to start with getting the upstream
> code fixed in a sane manner so all the backports to older kernels
> start from the same series of commits.

That's sane.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

  reply	other threads:[~2008-06-26 12:39 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-26  4:41 [PATCH 0/6] Remove most users of semaphores from XFS Dave Chinner
2008-06-26  4:41 ` [PATCH 1/6] Extend completions to provide XFS object flush requirements Dave Chinner
2008-06-26  7:46   ` Christoph Hellwig
2008-06-26 11:21     ` Dave Chinner
2008-06-26 13:07       ` Christoph Hellwig
2008-06-26 13:18         ` Dave Chinner
2008-06-26 11:26   ` Matthew Wilcox
2008-06-26 11:32     ` Dave Chinner
2008-06-26 11:42       ` Matthew Wilcox
2008-06-26 12:21         ` Dave Chinner
2008-06-26 12:40           ` Matthew Wilcox [this message]
2008-06-26 12:49             ` Christoph Hellwig
2008-06-26 13:02             ` Dave Chinner
2008-06-26 20:33   ` Daniel Walker
2008-06-27  1:52     ` Dave Chinner
2008-06-27  2:24     ` Matthew Wilcox
2008-06-27  3:26       ` Daniel Walker
2008-06-27  9:15         ` Christoph Hellwig
2008-06-27 14:37           ` Daniel Walker
2008-06-26  4:41 ` [PATCH 2/6] Replace inode flush semaphore with a completion Dave Chinner
2008-06-27  2:30   ` Matthew Wilcox
2008-06-27  4:13     ` Dave Chinner
2008-06-26  4:41 ` [PATCH 3/6] Replace dquot " Dave Chinner
2008-06-26  4:41 ` [PATCH 4/6] Replace the XFS buf iodone " Dave Chinner
2008-06-26  7:41   ` Christoph Hellwig
2008-06-26  4:41 ` [PATCH 5/6] Remove the sema_t from XFS Dave Chinner
2008-06-26  4:41 ` [PATCH 6/6] Clean up stale references to semaphores Dave Chinner
2008-06-26  7:47   ` Christoph Hellwig

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=20080626124009.GY4392@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox