LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Bart Dopheide <dopheide@fmf.nl>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	linux-kernel@vger.kernel.org,
	OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
	Jens Axboe <jens.axboe@oracle.com>,
	Bartlomiej Zolnierkiewicz <mzolnier@gmail.com>
Subject: Re: Kernel BUG at fs/mpage.c:489
Date: Wed, 13 Feb 2008 20:39:25 +1100	[thread overview]
Message-ID: <200802132039.26169.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <20080213013255.b4ea534c.akpm@linux-foundation.org>

On Wednesday 13 February 2008 20:32, Andrew Morton wrote:
> On Wed, 13 Feb 2008 20:24:03 +1100 Nick Piggin <nickpiggin@yahoo.com.au> 
wrote:
> > BTW is it really true that the buffer can never be locked by
> > anything else at this point?
>
> It has been for the past five or six years.  With the page locked, nobody
> else can get at that page.

Hmm OK.


> > What about fsync_buffers_list?
>
> They're metadata buffers, not regular file data.  Things might get ugly if
> IO to /dev/sda went via that path, but it doesn't.

Yeah right... so the BUG_ON is basically because you want to avoid
the overhead of locking the buffer (which would presumably allow it
to work in situations where someone else might lock the buffer without
locking the page?). OK, makes sense.

  reply	other threads:[~2008-02-13  9:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-12 19:45 Bart Dopheide
2008-02-12 21:50 ` Alan Cox
2008-02-13  1:05   ` Nick Piggin
2008-02-13  7:26     ` Bart Dopheide
2008-02-13  9:01       ` Andrew Morton
2008-02-13  9:24         ` Nick Piggin
2008-02-13  9:32           ` Andrew Morton
2008-02-13  9:39             ` Nick Piggin [this message]
2008-02-13 17:40         ` OGAWA Hirofumi

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=200802132039.26169.nickpiggin@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=dopheide@fmf.nl \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mzolnier@gmail.com \
    --subject='Re: Kernel BUG at fs/mpage.c:489' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).