linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm+eric@npwt.net (Eric W. Biederman)
To: "Stephen C. Tweedie" <sct@dcs.ed.ac.uk>
Cc: linux-mm@kvack.org
Subject: Re: filemap_nopage is broken!!
Date: 23 Apr 1998 19:51:16 -0500	[thread overview]
Message-ID: <m1wwcgm48r.fsf@flinx.npwt.net> (raw)
In-Reply-To: "Stephen C. Tweedie"'s message of Thu, 23 Apr 1998 23:01:32 +0100

>>>>> "ST" == Stephen C Tweedie <sct@dcs.ed.ac.uk> writes:

ST> I don't think this is necessarily a problem.  The kernel simply does not
ST> guarantee full correspondance semantics between filesystem updates and
ST> the page cache for non-aligned pages, but then again, it is not required
ST> to --- it is not even required to support such mmaps, so I can live with
ST> an undefined behaviour in this case!

Ah, but suppose we have a mythological a.out programmer.
This programmer could run a program, doesn't like the result, compiles
a new version which overwrites the old, and attempts to execute the
new program.  And executes the old!

There may be a lock in there that I haven't spotted, and likely there
will be a truncation when the file is overwritten which would flush
the page cache but it is possible there isn't.

As the kernel internally uses these mappings for a.out executables
this is an undefined case which propogates.  It's undefined which
a.out program executes :(  That part is much harder to live with.

I guess what is I find most objectionable is 
a) There is no big fat warning anywhere.
b) The current implementation will pass simple tests so it will look
   like it works, and then fail at strange weird unpredictable times.

I doubt it will be anything like a show stopper for 2.2 but if this
code get's touched it should be fixed to do something consistent.  

Eric

  reply	other threads:[~1998-04-24  0:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-04-22 20:51 Eric W. Biederman
1998-04-23 22:01 ` Stephen C. Tweedie
1998-04-24  0:51   ` Eric W. Biederman [this message]
1998-04-24 20:32     ` Stephen C. Tweedie

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=m1wwcgm48r.fsf@flinx.npwt.net \
    --to=ebiederm+eric@npwt.net \
    --cc=linux-mm@kvack.org \
    --cc=sct@dcs.ed.ac.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox