linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: Daniel McNeil <daniel@osdl.org>
Cc: andrea@suse.de, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.5.68 2/2] i_size atomic access
Date: Thu, 24 Apr 2003 18:05:03 -0700	[thread overview]
Message-ID: <20030424180503.2c2a8bea.akpm@digeo.com> (raw)
In-Reply-To: <1051230056.2448.16.camel@ibm-c.pdx.osdl.net>

Daniel McNeil <daniel@osdl.org> wrote:
>
> Andrew, can we get these patches in to -mm?
> 

I don't like them really.

Yes, I know, a bug is a bug is a bug and it should be fixed.  But the fix
is fugly and the bug seems to be very theoretical.  And the patches appear
to not address all the i_size accesses down in filesystems.

The patches add barriers and cache footprint to fastpaths, and we don't get
a lot back.  As far as I know the bug has only been demonstrated when one
CPU is spinning on stat() and the other is waggling the file size across
the 4G boundary.

I'd be interested in seeing if the race is demonstrable anywhere else,
because the stat() problem can be plugged just by taking i_sem in
sys_stat().


So yeah, I know it _should_ be fixed, but it gives me the creeps, and the
fix may not be complete anyway.

And if the race _does_ hit, what is the effect?  Assuming stat() was fixed
with i_sem, I don't think the race has a very serious effect.  We won't
oops, or corrupt filesystems, or be insecure.  Maybe some
probably-already-racy application gets a page of zeroes instead of live
data.  Or maybe not - I'd need to think about that some more.



  reply	other threads:[~2003-04-25  0:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-25  0:30 [PATCH 2.5.68 2/2] i_size atomic access Daniel McNeil
2003-04-25  1:05 ` Andrew Morton [this message]
2003-04-25  1:42   ` Andrea Arcangeli
2003-04-25 10:57     ` Andrew Morton
2003-04-25 23:17       ` Daniel McNeil
2003-04-30  0:40         ` Daniel McNeil

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=20030424180503.2c2a8bea.akpm@digeo.com \
    --to=akpm@digeo.com \
    --cc=andrea@suse.de \
    --cc=daniel@osdl.org \
    --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;
as well as URLs for NNTP newsgroup(s).