linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: jens.axboe@oracle.com, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	torvalds@linux-foundation.org, akpm@linux-foundation.org,
	hugh@veritas.com, nickpiggin@yahoo.com.au
Subject: Re: [patch 1/2] mm: dont clear PG_uptodate in invalidate_complete_page2()
Date: Wed, 25 Jun 2008 18:16:55 +0400	[thread overview]
Message-ID: <20080625141654.GA4803@2ka.mipt.ru> (raw)
In-Reply-To: <E1KBV7H-0005nv-Gl@pomaz-ex.szeredi.hu>

On Wed, Jun 25, 2008 at 03:32:55PM +0200, Miklos Szeredi (miklos@szeredi.hu) wrote:
> > What about writing path, when page is written after some previous write?
> 
> page->mapping should be checked in the write paths as well.

All we need from mapping here is where to put this page and inode
pointer.

> > Like __block_prepare_write()?
> 
> That's called with the page locked and page->mapping verified.

Only when called via standard codepath. If page was grabbed and page
unlocked and subsequently 'invalidated' via invalidate_complete_page2(),
it still relies on uptodate bit to be set to correctly work.

After all we do not need page mapping to write into given page, that's
why __block_prepare_write() does not check it.

> > > Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
> > > ---
> > >  mm/truncate.c |    1 -
> > >  1 file changed, 1 deletion(-)
> > > 
> > > Index: linux-2.6/mm/truncate.c
> > > ===================================================================
> > > --- linux-2.6.orig/mm/truncate.c	2008-06-24 20:49:25.000000000 +0200
> > > +++ linux-2.6/mm/truncate.c	2008-06-24 23:28:32.000000000 +0200
> > > @@ -356,7 +356,6 @@ invalidate_complete_page2(struct address
> > >  	BUG_ON(PagePrivate(page));
> > >  	__remove_from_page_cache(page);
> > >  	write_unlock_irq(&mapping->tree_lock);
> > > -	ClearPageUptodate(page);
> > >  	page_cache_release(page);	/* pagecache ref */
> > >  	return 1;
> > >  failed:
> > 
> > Don't do that, add new function instead which will do exactly that, if
> > you do need exactly this behaviour.
> 
> I don't see any point in doing that.
> 
> > Also why isn't invalidate_complete_page() enough, if you want to have
> > that page to be half invalidated?
> 
> I want the page fully invalidated, and I also want splice and nfs
> exporting to work as for other filesystems.

Fully invalidated page can not be uptodate, doesnt' it? :)

You destroy existing functionality just because there are some obscure
places, where it is used, so instead of fixing that places, you treat
the symptom. After writing previous mail I found a way to workaround it
even with your changes, but the whole approach of changing
invalidate_complete_page2() is not correct imho.

Your note:
>Let's start with page_cache_pipe_buf_confirm().  How should we deal
>with finding an invalidated page (!PageUptodate(page) &&
>!page->mapping)?

>We could return zero to use the contents even though it was
>invalidated, not good, but if the page was originally uptodate, then
>it should be OK to use the stale data.  But it could have been
>invalidated before becoming uptodate, so the contents could be total
>crap, and that's not good.  So now we have to tweak page invalidation
>to differentiate between was-uptodate and was-never-uptodate pages.

Is this nfs/fuse problem you described:
http://marc.info/?l=linux-fsdevel&m=121396920822693&w=2

Instead of returning error when reading from invalid page, now you
return old content of it? From description on above link it is not the
case, when user reads data into splice pipe and suddenly it becomes
invalidated, which you try to fix with this patch, but it may be
completely different problem though.

-- 
	Evgeniy Polyakov

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2008-06-25 14:16 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-25 12:40 [patch 0/2] splice: fix nfs export of fuse filesystems Miklos Szeredi
2008-06-25 12:40 ` [patch 1/2] mm: dont clear PG_uptodate in invalidate_complete_page2() Miklos Szeredi, Miklos Szeredi
2008-06-25 13:11   ` Evgeniy Polyakov
2008-06-25 13:32     ` Miklos Szeredi
2008-06-25 14:16       ` Evgeniy Polyakov [this message]
2008-06-25 14:41         ` Miklos Szeredi
2008-06-25 15:30           ` Evgeniy Polyakov
2008-06-25 15:59             ` Miklos Szeredi
2008-06-25 16:18               ` Evgeniy Polyakov
2008-06-25 15:47           ` Evgeniy Polyakov
2008-06-25 16:02             ` Miklos Szeredi
2008-06-25 16:19               ` Evgeniy Polyakov
2008-06-25 15:11   ` Linus Torvalds
2008-06-25 15:29     ` Miklos Szeredi
2008-06-25 16:30       ` Linus Torvalds
2008-06-25 16:42         ` Miklos Szeredi
2008-06-25 17:38     ` Jamie Lokier
2008-06-25 18:35       ` Miklos Szeredi
2008-07-07  6:38         ` Nick Piggin
2008-07-07  9:21           ` Miklos Szeredi
2008-07-07 10:12             ` Miklos Szeredi
2008-07-07 11:01               ` Nick Piggin
2008-07-07 12:03                 ` Miklos Szeredi
2008-07-07 12:17                   ` Nick Piggin
2008-07-07 12:52                     ` Miklos Szeredi
2008-07-07 14:28                       ` Nick Piggin
2008-07-07 15:08                         ` Miklos Szeredi
2008-07-08  2:22                           ` Nick Piggin
2008-07-07 10:43             ` Nick Piggin
2008-06-25 12:40 ` [patch 2/2] splice: fix generic_file_splice_read() race with page invalidation Miklos Szeredi, Miklos Szeredi
2008-06-25 13:00   ` Jens Axboe

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=20080625141654.GA4803@2ka.mipt.ru \
    --to=johnpol@2ka.mipt.ru \
    --cc=akpm@linux-foundation.org \
    --cc=hugh@veritas.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=miklos@szeredi.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=torvalds@linux-foundation.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