public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Nick Piggin <nickpiggin@yahoo.com.au>, Ram Pai <linuxram@us.ibm.com>
Cc: Hugh Dickins <hugh@veritas.com>, Gergely Tamas <dice@mfa.kfki.hu>,
	Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>,
	Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org
Subject: Re: data loss in 2.6.9-rc1-mm1
Date: Sat, 28 Aug 2004 11:44:50 +0200	[thread overview]
Message-ID: <200408281144.50704.rjw@sisk.pl> (raw)
In-Reply-To: <41301E27.2020504@yahoo.com.au>

Well, guys, to make it 100% clear: if I apply the Nick's patch to the 
2.6.9-rc1-mm1 tree, it will fix the data loss issue.  Is that right?

RJW

On Saturday 28 of August 2004 07:54, Nick Piggin wrote:
> Ram Pai wrote:
> > On Fri, 2004-08-27 at 21:35, Nick Piggin wrote:
> >>Ram Pai wrote:
> >>>got it!  Everything got changed to the new convention except that
> >>>the calculation of 'nr' just before the check "nr <= offset" .
> >>>
> >>>I have generated this patch which takes care of that and hence fixes the
> >>>data loss problem as well. I guess it is cleaner too.
> >>>
> >>>This patch is generated w.r.t 2.6.8.1. If everybody blesses this patch I
> >>>will forward it to Andrew.
> >>
> >>It looks like it should be OK... but at what point does it become
> >>simpler to use my patch which just moves the original calculation
> >>up, and does it again if we have to ->readpage()?
> >>
> >>(assuming you agree that it solves the problem)
> >
> > I agree your patch also solves the problem.
> >
> > Either way is fine. Even Hugh's patch almost does the same thing as
> > yours.
>
> Ahh, yep - Hugh just forgot to also move the "nr" calculation
> into the ->readpage path, so it hits twice on the fast path.
>
> > The only advantage with my page is it does the calculation in
> > only one place and does not repeat it. Also I feel its more intuitive to
>
> Well kind of - but you are having to jump through hoops to get there.
> Yours does the following checks:
>
> 	/* fast path, read nr_pages from pagecache */
> 	if (!isize)
> 		goto out;
> 	for (i = 0; i < nr_pages; i++) {
> 		if (index > end_index)
> 			goto out;
> 		if (index == end_index) {
> 			nr = ((isize - 1) & ~PAGE_CACHE_MASK) + 1;
> 			if (nr <= offset) {
> 				page_cache_release(page);
> 				goto out;
> 			}
> 		}
>
> 		/* slowpath, ->readpage */
> 		if (unlikely(!isize || index > end_index)) {
> 			page_cache_release(page);
> 			goto out;
> 		}
> 	}
>
>
> Mine does:
> 	if (index > end_index)
> 		goto out;
> 	for (i = 0; i < pages_to_read; i++) {
> 		if (index == end_index) {
> 			nr = isize & ~PAGE_CACHE_MASK;
> 			if (nr <= offset)
> 				goto out;
> 		}
>
> 		/* slowpath, ->readpage */
> 		if (index > end_index) {
> 			page_cache_release(page);
> 			goto out;
> 		}
> 		if (index == end_index) {
> 			nr = isize & ~PAGE_CACHE_MASK;
> 			if (nr <= offset) {
> 				page_cache_release(page);
> 				goto out;
> 			}
> 		}
> 	}
>
> So my fastpath is surely leaner, while the slowpath isn't a clear loser.
>
> What's more, it looks like mine handles the corner case of reading off the
> end of a non-PAGE_SIZE file (but within the same page). I think yours will
> drop through and do the ->readpage, while mine doesn't...?
>
> > assume that index 0 covers range 0 to 4095 i.e index n covers range
> > n*PAGE_SIZE to ((n+1)*PAGE_SIZE)-1.  Currently the code assumes index 0
> > covers range 1 to 4096  i.e index n covers range (n*PAGE_SIZE)+1 to
> > (n+1)*PAGE_SIZE.
>
> It is definitely a pretty ugly function all round. I like the 0-4095 thing
> better too, but my counter argument to that is that this is the minimal
> change, and similar to how it has previously worked.
>
> > this is the 4th time we are trying to nail down the same thing. We
> > better get it right this time. So any correct patch is ok with me.
>
> I agree. We'll leave it to someone else to decide, then ;)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
For a successful technology, reality must take precedence over public 
relations, for nature cannot be fooled.
					-- Richard P. Feynman

  reply	other threads:[~2004-08-28  9:34 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-27 10:55 data loss in 2.6.9-rc1-mm1 Gergely Tamas
2004-08-27 11:05 ` Anton Altaparmakov
2004-08-27 11:40   ` Gergely Tamas
2004-08-27 12:35   ` Fabio Coatti
2004-08-27 11:17 ` Tim Schmielau
2004-08-27 11:43   ` Gergely Tamas
2004-08-27 11:37 ` Mikael Pettersson
2004-08-27 11:55 ` Denis Vlasenko
2004-08-27 13:56   ` Hugh Dickins
2004-08-27 14:18     ` Gergely Tamas
2004-08-27 15:36       ` Fabio Coatti
2004-08-27 18:30     ` Ram Pai
2004-08-27 19:08       ` Hugh Dickins
2004-08-27 21:04         ` Ram Pai
2004-08-28  4:35           ` Nick Piggin
2004-08-28  5:01             ` Ram Pai
2004-08-28  5:42               ` Andrew Morton
2004-08-28  5:54               ` Nick Piggin
2004-08-28  9:44                 ` Rafael J. Wysocki [this message]
2004-08-28  9:45                   ` Andrew Morton
2004-08-28 10:18                     ` Nick Piggin
2004-08-28 10:47                       ` Rafael J. Wysocki
2004-08-28 14:52                 ` Hugh Dickins
2004-08-29  1:30                   ` Nick Piggin
2004-08-31  6:25                     ` Ram Pai
2004-08-31  6:39                       ` Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2004-08-28 12:05 Joachim Bremer

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=200408281144.50704.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=akpm@osdl.org \
    --cc=dice@mfa.kfki.hu \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxram@us.ibm.com \
    --cc=nickpiggin@yahoo.com.au \
    --cc=vda@port.imtp.ilyichevsk.odessa.ua \
    /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