All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phillip Lougher <phillip@lougher.demon.co.uk>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
	viro@parcelfarce.linux.theplanet.co.uk
Subject: Re: [PATCH] VFS readahead bug in 2.6.8-rc[1-3]
Date: Fri, 06 Aug 2004 20:14:55 +0100	[thread overview]
Message-ID: <4113D8AF.5030803@lougher.demon.co.uk> (raw)
In-Reply-To: <4113D4CD.5080109@yahoo.com.au>

Nick Piggin wrote:
> Phillip Lougher wrote:
> 
>> Nick Piggin wrote:
>>
>>> On second thought, maybe not. I think your filesystem is at fault.
>>
>>
>>
>> No I'm not wrong here. With a read-only filesystem i_size can
>> never change, there are no possible race conditions.  If a too
>> large index is passed it is a VFS bug.  Are you suggesting I should
>> start to code assuming the VFS is broken?
>>
> 
> No, I suggest you start to code assuming this interface does
> what it does. I didn't say there is no bug here, but nobody
> else's filesystem breaks.
> 

Point one: The interface didn't do this UNTIL you changed the code
Point two: Just because no one has reported other filesystem
breakage, it doesn't mean other filesystems have not broken.

Perhaps I should have the check in my code.  However, it is
still stupid to fix an occasional race by ensuring readpage() is
always called with an out of bounds index when files are 0 or a
4K multiple.  The filesystem check may prevent a crash, but it
is needlessly wasteful by design, not through any inadvertant
race condition.

think is it stupid to fix an o.  However, I it
stupid to fix a race co
ll think it stupid to fix a race you en


  reply	other threads:[~2004-08-06 19:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-05 17:50 [PATCH] VFS readahead bug in 2.6.8-rc[1-3] Phillip Lougher
2004-08-06  0:55 ` Nick Piggin
2004-08-06  2:19   ` Nick Piggin
2004-08-06 16:58     ` Phillip Lougher
2004-08-06 18:58       ` Nick Piggin
2004-08-06 19:14         ` Phillip Lougher [this message]
2004-08-06 19:31           ` viro
2004-08-06 19:18         ` Phillip Lougher
2004-08-06 19:46           ` Andrew Morton
2004-08-16  7:55             ` [PATCH] " Ram Pai
2004-08-07 14:21         ` Pozsar Balazs
     [not found] <Pine.LNX.4.44.0408052104420.2241-100000@dyn319181.beaverton.ibm.com>
     [not found] ` <411322E8.4000503@yahoo.com.au>
2004-08-06 10:47   ` Ram
2004-08-06 17:05   ` Phillip Lougher
2004-08-06 18:02     ` Ram Pai
2004-08-06 19:09     ` Nick Piggin
2004-08-06 19:39       ` Phillip Lougher
2004-08-06 20:21         ` Nick Piggin

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=4113D8AF.5030803@lougher.demon.co.uk \
    --to=phillip@lougher.demon.co.uk \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.