mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Charles Edward Lever <chucklever@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Yet another borken page_count() check in invalidate_inode_pages2()....
Date: Wed, 15 Nov 2006 13:12:56 -0800	[thread overview]
Message-ID: <20061115131256.403facca.akpm@osdl.org> (raw)
In-Reply-To: <1163624265.5880.31.camel@lade.trondhjem.org>

On Wed, 15 Nov 2006 15:57:45 -0500
Trond Myklebust <Trond.Myklebust@netapp.com> wrote:

> On Wed, 2006-11-15 at 11:24 -0800, Andrew Morton wrote:
> 
> > The protocol is
> > 
> > 	lock_page()
> > 	set_page_writeback()
> > 	->writepage()
> 
> We're not using ->writepage().

I think you know what I mean.

> > and there are various places which assume that nobody will start new
> > writeout of a locked page.  But I forget where they are - things have always
> > been this way.
> 
> Huh? There has never been a requirement to lock the page if all you want
> to do is call set_page_writeback().

The protocol is, and always has been

	lock_page()
	set_page_writeback();
	start-io
	unlock_page();

end_io:
	end_page_writeback()


and there are places in the VM which rely upon some or all of that.  I'd
need to go on a big hunt to remember where they are.  One of them is
invalidate_inode_pages2(), as you've just discovered.

> The only reason why we want to do
> that at all is to allow the VM to track that the page is under I/O. All
> other operations involved in scheduling writes are protected by internal
> NFS locks.

Well the VM uses lock_page() for this synchronisation.  If NFS has gone and
decided not to do that then we'll need to either

a) Make NFS follow the protocol or

b) Put stuff in NFS to allow the VM to work correctly (until we change it) or

c) Put very-clearly-commented NFS exception code into the VM.


      reply	other threads:[~2006-11-15 21:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-15  5:33 Trond Myklebust
2006-11-15  5:42 ` Andrew Morton
2006-11-15 13:18 ` Trond Myklebust
2006-11-15 16:46   ` Andrew Morton
2006-11-15 18:05     ` Trond Myklebust
2006-11-15 19:24       ` Andrew Morton
2006-11-15 20:57         ` Trond Myklebust
2006-11-15 21:12           ` Andrew Morton [this message]

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=20061115131256.403facca.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=Trond.Myklebust@netapp.com \
    --cc=chucklever@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®